We may be treading into a very difficult situation (in some ways similar to why MIPv6 got pushback from the IESG, IMO), and to be pre-emptive, I'd really appreciate if folks would have a look at the particular issue (at the end of the mail) and think whether it is a problem or not.
On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > The 3-tuple of the Flow Label and the Source and Destination Address > > fields enables efficient IPv6 flow classification, where only IPv6 > > main header fields in fixed positions are used. > > > > ==> this might require some extra analysis somewhere (not in that > > particular place, I think). In particular, this seems to say that once > > this is published people can happily move to using the three-tuple > > classification. The reality is probably quite different, and one must > > also consider the big portion of nodes which do not mark the flows. > > The goal of this document is not to describe use cases. It is > to set the minimum conditions hosts and routers must meet. I do > not believe we should add use cases to this document. I believe the original text does not give a realistic picture of the situation. For the purpose of minimum conditions, the text could be removed altogether, of course -- that would be fine by me. I could also live with (by a thread :-) the current version, but I really believe it should be changed slightly. > > To enable applications and transport protocols to define what packets > > constitute a flow, the source node MUST provide means for the > > applications and transport protocols to specify the Flow Label values > > to be used with their flows. > > > > ==> this requirement seems unacceptable at the moment. This clearly > > requires (at least) de-facto API so applications could set Flow Label > > values -- and as such does not exist. If it did (and I believe there's > > work in progress), there would *have to be* a normative reference to it). > > So, clearly a MUST seems to a big no-no. > > But this is a statement about what hosts must do to make the flow label > useful. No, that's not correct, or either of us is misunderstanding the paragraph above (if so, a wording change is needed). The nodes (kernel, in particular) are able to mark flows by itself, without any interaction from the applications -- so having apps have a MUST possibility to influence the flow labeling is undoubtedly useful, but certainly not something requiring MUST, considering the current situation. Note: I'd argue for MUST myuself if we had had a standard (or even de-facto standard!) mechanism specified (and hopefully implemented) for 1 year before this being sent to the IESG. > If you want to standardize a socket API extension that's fine, > the Open Group exists for that. However, I believe a MUST is needed. A MUST without a means is bad practise, IMO. > > A source node MUST ensure that it does not reuse Flow Label values it > > is currently using or has recently used when creating new flows. Flow > > Label values previously used with a specific pair of source and > > destination addresses MUST NOT be assigned to new flows with the same > > address pair within 120 seconds of the termination of the previous > > flow. > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > value which was previously used, and send the packet, the operating system > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > s/reuse/unintentionally reuse/, or some other rewording? > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > we included an algorithm, but the WG wanted it removed, so we removed it. Yes, the stack can do it easily -- no doubt about that -- but it's *wrong*; this is connected to the security issue, below. > > To enable co-existence of different methods in IPv6 nodes, the > > methods MUST meet the following basic requirements: > > > > ==> this and the following points seem a little oddly placed in this memo: > > they seem out-of-place, as the rest of the memo seems to concentrate on > > entirely different issues. Personally I view specifying how source nodes > > should label flows one thing, and the rest entirely another. But I can > > live with these, even though I think they're more fit to a non-standards > > track document. > > Then you don't want a change here? I can live without it -- waiting to hear others' opinions -- but I think the source node behaviour is entirely different issue from the network treatment. > > 5.1 Theft and Denial of Service > > > > ==> this section mainly deals with issues relating to forging all of the > > source,destination,label three-tuple (exception is the last paragraph, > > which deals with a trusted-node-but-untrusted-user/application case), > > which protects mainly against a DoS attack (resource depletion). > > > > This seems to overlook the most important part: the typical model today is > > that operators perform differentiation of flows *themselves*: this > > document proposes to shift that, *over an administrative boundary*, to the > > source nodes, which suddenly become trusted to do the right thing. > > No, it adds the *labelling* of flows to the source, as a new capability. The labeling with current "service model" leads to differentiation. I'll try to reword it again below. If the "service model" would be such that the source node is *not* expected to label flows correctly, I'd certainly agree. > It says *nothing* about how differentiation is done. That is indeed > a separate and quite complex discussion, that will keep the QOS > community busy for years. I believe a bit similar arguments were on the table when mobileip working group proposed MIPv6 to the IESG, and it got pushed down, as "doesn't work, be more specific". That was some 2-3 years ago, and only now MIPv6 is nearing completion. I'd rather handle these kind of issues before IESG, if possible. The problems are different, but there seem to be some dangerous common elements. > The idea is to keep that discussion out > of the IPv6 WG, by defining the boundary conditions here, so that > the flow label becomes a viable tool for differentiation downstream. My fear is that false assumptions lead to wrong conclusions and broken tools, and wasted effort (both from IPv6 wg and especially from the follow-up wgs). > I think this was clear in the previous WG discussions. Unfortunately, the flood was so huge at a point that I couldn't keep up (because I didn't really even care, except whether WG would go on a course which seems really problematic, like now) > > This would be equivalent to replacing network ingress filtering (to drop > > packets with forged source addresses) to a requirement for nodes to allow > > out only packets which include their own source address. > > > (By the way, do > you think nodes *should* be allowed to forge the source address?) I'll answer this first. The nodes certainly should be allowed (in the kernel level) to forge the source addresses: any model which forces this is broken. The reason for breakage is that such a model assumes that the nodes behave "properly". For most cases, that is correct. But because there is still a huge number of systems behaving differently, you cannot depend on it, and assuming it is being done would be wrong. The right (my humble POV, of course :-) answers to your question are: - no, the user privileged process on a node should not be able to set the source address (no problem today) - no, the *network* where the node is attached to should not allow the user to forge the source address (note: different administrative entity) > No. The checks can perfectly well be applied at ISP ingress. Yes, but as the first comment seems to show, in practise this checking would be de-facto removed for performance etc. reasons. > I did want to include more aggressive text about ingress > filtering, but in fact it would be out of place. I'm not sure which kind of text you're referring to, but IMO ingress filtering misses the biggest point. > > Needless to say this seems to indicate a major oversight of the > > security/operational reality. I'd be very surprised if this was not > > pushed back in the IESG unless this caveat is very explicitly documented. > > I think your interpretation is quite wrong, but we can certainly ask a > security expert or two. Ok. To try to clarify what I meant, let me try to explain it again. Any model that requires that source nodes prevent the root/administrator from willingly doing something, and more or less *depending on that* is broken. Let me try to give an example. When Windows XP was being published, some very popular magazines were writing about their belief that adding "raw sockets" functionality would be catastrophic for the Internet, degrade security as people could "now" send any kind of packets they'd want etc. The reality was entirely different. Such can be done *anyway*, using other implementations, using different mechanisms to achieve the same goal, etc. This is a similar issue. Given an *untrusted* node, specifying mechanisms which try to make the *untrusted* node do something you'd like to trust (to a rather full extent) seems *completely* bogus.. Certainly, one should specify checks that user-mode applications MUST NOT be able to re-use flow labels within a lifetime, but that's entirely different from the approach in the draft. Certainly, this is a very problematic issue (which was thought to be solved later, in some other w.g.). I'm not requiring it be solved here. But I'm requiring that we don't pass the problem on without stating *very* explicitly the issues why it might/might not work properly -- so that any followup efforts that might start to build QoS mechanisms on this would not start with an entirely different set of assumptions (easily leading to wrong conclusions and broken tools). I'm not sure if I managed to make the point any clearer, I hope so. I'd also really appreciate comment on this viewpoint (for or against :-) from everybody. Especially those with (ISP) operator [the "customer of the IETF" in this instance] or security background would be encouraged to speak up. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
