Narayanan, Vidya wrote:
Hi Henrik,
The discussion I had with Dave on this topic was something I wanted to
write to the Monami6 list about a while ago, so that the group can also
think about that. However, that somehow never happened and now that Jari
brought up this thread, I wanted to throw the idea out to see what
people think about it. I admit that I have not extensively thought about
it - so, this is not an attempt to promote any views. This is just a
discussion point. Dave mentioned it and on the surface, it seemed like
an idea worth exploring.
I understand where you stand on the topic now and I would agree with
some of it and disagree with some other parts of it. Mainly,
irrespective of whether a transport protocol or extension headers or
mobility options are used to carry this information, I do not think we
should be aiming at a single solution for host-to-router and
router-to-router exchanges of filter rules, as I do believe the
And router to host? I'm afraid that it is fairly common for IPsec VPN
clients to have filtering policy thrust upon them from the tunnel
concentrator (e.g., whether split tunneling and such is permitted or not).
- Mark
requirements and security models are quite different in the two cases.
So, I think setting the scope at this level will be useful for starters.
I hope to continue an objective technical discussion and would also like
to see if others have any thoughts on this.
Regards,
Vidya
-----Original Message-----
From: Henrik Levkowetz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 11:47 PM
To: Narayanan, Vidya
Cc: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6
on 2007-02-15 04:57 Narayanan, Vidya said the following:
Hi Henrik,
Sorry, due to some intermittent connectivity issues, it turned out
that even though my application had sent the email before receiving
the other responses, it was actually only sent out later.
-----Original Message-----
From: Henrik Levkowetz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 3:09 PM
To: Internet Area
Subject: Re: [Int-area] Lifting up a filter discussion from Monami6
on 2007-02-14 23:20 Narayanan, Vidya said the following:
I would be sympathetic to developing something generic that
works for
multiple protocols instead of just Mobile IP, while also
keeping in
mind the issue of mobility and latency concerns associated
with that.
One thing to take into account is that this exchange is not
necessarily a one-time exchange and policies and filters
may change
over time, based on the current connection capabilities
of an end
host. In such cases, some of this signaling may potentially
be bound
to handoffs and in the context of Mobile IP or MOBIKE-like
protocols,
if this means separate signaling exchanges before the flow
changes can
happen, it could be less than useful.
I don't know if you read my recent post, but we've
analysed this and
found that there is very little correlation (basically
none) between
the time when a filter rule update is needed, and the time of
handover.
I went through your other email. I see that there may be little
correlation between filter rule updates and the time of handover in
one model of doing this. In other words, I think you are
referring to
a model where there a bunch of rules set up in advance,
say, with an
ID that maps to each rule and upon handoffs, it is the mapping of
those IDs to interfaces or IP addresses that needs to
happen and not
the actual setting up or update of the rules itself. The
rules could
be updated at any time (and perhaps somewhat infrequently),
while the
rule-to-interface mapping is rather dynamic.
Yes.
I can subscribe to that
notion, although, the question I then have is whether we
need to have
a certain protocol to set up the rules and other protocols
to do the
rule-to-interface mapping. Having a separate protocol that
sets up the
filter rules and updates the mapping would lead to the problem of
having to run that protocol separately at the time of handoff to
update the mapping. More notes below.
This isn't a problem, it's what you want to do. You want to
de-couple these two actions in time. And that does not force
you to define two different protocols for it, although if
there is some advantage to doing so, as seems to be the case
for monami6/mip6, you certainly can do so.
You probably should read the monami6 documents covering this
if you're not familiar with them, to show an example both of
how and why this could be the case.
I had briefly discussed this with Dave Thaler in San Diego
and we had
talked about defining the flow information in a generic format,
perhaps as an IPv6 extension header or as a Destination
Option. If
such an approach were to be taken, this information
could then be
carried in any protocol, which would get rid of additional
signaling
and latency concerns associated with it. So, from this
point of view,
a couple of different things would need to happen - an
independent
specification needs to define such an extension header or
destination
option and the fields that go into it; a different
specification would
then describe how this is carried in a given protocol (say,
Mobile IP)
and how the information is secured within that context.
Thoughts on something like this?
First, this cannot simply be described as 'flow
information', so if
that was the context of your discussion, I don't think it is quite
relevant for this discussion.
No, that was a terminology issue - I was still referring to filter
rules exchange as well.
Secondly, this assumes that the filter rules would consistently be
communicated to the end host at the other end of your regular
traffic, which is an assumption that doesn't generally hold for
filter rules.
We have to scope the problem here. As to what Monami6 is
chartered to
solve, it is only the flow/binding policies exchange
to/from the MN/MR
to the HA, very much in the context of MIP6 (and its
variants) and NEMO.
Strictly from this perspective, tying this exchange to MIP6
signaling
should be acceptable. However, it seems fair to see if this can be
done a bit more generically in a way that allows this work to be
useful for something like MOBIKE, where the same kind of
end hosts may
be participating in the exchange and the requirements and scope are
quite similar.
?? I see no argument for placing this in an extension header here.
However, if this were to be extended to an any-to-any
policies/rules
exchange protocol, the scope and requirements become quite
different.
That seems to fall under the scope of something that NSIS might be
doing. For instance, if this exchange is between two routers, the
information involved in this exchange and the timing and binding of
the information to interfaces or addresses become very different.
Handoffs are no longer a topic for consideration, for e.g. OTOH,
batching of information/rules, granularity of that and even the
security models are quite different.
?? I still don't see any argument for placing this in and
extension header here.
I don't think it is good to solve the router-to-router and
host-to-router/server/agent exchanges with the same approach.
Oh? Not that anyone has argued that either way, but as a
general statement, that would lead you to separate IP
protocols, UDP protocols, TCP, etc., etc., for these
exchanges. I don't thing this statement is valid or fruitful.
Thirdly, extension headers are for optional internet-layer
information (RFC 2460), and I'm not sure this is a fair
categorization of such filter rules as we're discussing here.
I don't know how much people care about proper layering
these days,
though ...
It depends on whether this is viewed as a layer violation or
cross-layer optimization :)
No, it doesn't.
I'm typically not a fan of layer violation. However, in
this case, I
see the filter rules and policies as something that permits
QoS-aware
IP routing. So, I don't particularly see a problem with
this, although
I would like to hear more thoughts on this.
Even if there may be a relationship between filter rules and
QoS, they aren't the same thing, and mixing them together
won't aid clear thinking.
Finally, although filter rules wouldn't necessarily be
very large in
size, I doubt that the size constraints associated with extension
headers make it appropriate to put filter rules in an extension
header.
Remember that extension headers belong to the
unfragmentable part of
an IPv6 packet, so there's a variable maximum size for
such a header,
(depending on the presence of other extension extension
headers); it
seems as if it would create a silly size constraint for
filter rules
to define their default transport to be an IPv6 extension header.
>From RFC2460:
" The Unfragmentable Part consists of the IPv6 header plus any
extension headers that must be processed by nodes en
route to the
destination, that is, all headers up to and including
the Routing
header if present, else the Hop-by-Hop Options header
if present,
else no extension headers.
The Fragmentable Part consists of the rest of the
packet, that is,
any extension headers that need be processed only by the final
destination node(s), plus the upper-layer header and data."
The extension header under discussion here is only to be
processed by
the final destination node and hence, falls under the Fragmentable
Part
- so, size is not an issue.
In that case, I'd like to point out, again, that the
assumption that the filter rules would consistently be
communicated to the final destination node at the other end
of your regular traffic doesn't generally hold, and also
wonder why you feel the need to use the IP extension headers
as a replacement for UDP (or TCP/SCTP/DCCP). What's the motivation?
This is a bad idea, not only from the viewpoint of layer
violations, but also from the viewpoint of not having any of
the services built on top of the transport protocols
available, and from the point of view of the implementor who
can't then use the regular socket mechanism to handle the
communication of filters from one node to another.
Henrik.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
