Pekka, Please send text for what you think we should add to the security considerations.
Personally, I see no reason why the ISP's trust model changes here. Most IP header fields potentially used for QOS classification are forgeable. This isn't a flow label problem, or an IPv6 problem, or even an IP problem. It's a characteristic of connectionless datagrams. All your other points really are not new issues, and we have been working on the draft for more than a year to make it fit around the various perspectives expressed in the WG. Brian Pekka Savola wrote: > > 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] --------------------------------------------------------------------
