> -----Original Message----- > From: Mark Townsley [mailto:[EMAIL PROTECTED] > Sent: Monday, February 19, 2007 3:07 PM > To: Narayanan, Vidya > Cc: Henrik Levkowetz; Internet Area > Subject: Re: [Int-area] Lifting up a filter discussion from Monami6 > > 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). >
True. When I mentioned host-to-router, I had implicitly included the other direction as well. I would imagine the filter specifications for MOBIKE to fall under that category. I do think that the approaches for MIP6, MOBIKE and perhaps SHIM6 (I'm less sure of this) share similar requirements and having one solution may make sense. Would this cover the VPN scenario that you have mentioned above? Vidya > - 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
