On Thu, 6 Mar 2003, Brian E Carpenter wrote: > Pekka Savola wrote: > > > > 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. > > The flow label has been a forgeable field since IPSEC decided to leave > it outside the crypto calculation. I'd be very happy if this decision > could be reversed, since the field is immutable, but I don't think that > is realistic. IMHO the IESG would have no grounds for raising this now; > it derives automatically from ancient decsions.
The use of IPsec seems irrelevant for the *ISP* as they can't verify it -- no help there. The problem is of trying to make untrusted end-nodes trusted to label the flows properly. Changing IPsec will not help (except if you assume communication is to e.g. ISP's own servers, middleboxes etc.). > I agree that we should get a security person to look at your comments, but > unless anyone else supports your concern, it's my impression that you are > worrying about something we cannot change anyway. There are two most major issues here: 1) something we should change 2) something we must document if we cannot change I'm requiring at least 2). > The security considerations > simply document facts of life. Unfortunately, the security considerations as of now *does not* document these facts of life. This is the biggest concern. Of course, I strongly also want to change the model slightly (e.g. the MUST requirement for nodes not to send out used flow lables), to make it the restrictions of the model clearer. This does not yet fix the core problem, how the ISP can make anything of these labels -- trust them -- but at least now the starting assumptions are closer to correct. The extreme case would be taking a full halt here for all of the flow label draft, working out the details, and only then publishing it. I don't think this is correct approach for now. > > 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 > -- 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] --------------------------------------------------------------------
