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 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
