Remi, On Aug 3, 2010, at 02:53 MDT, Rémi Després wrote: > Le 30 juil. 2010 à 14:42, Pascal Thubert (pthubert) a écrit : > >> Hi Mohacsi: >> >> >>> - applications relying on 20 bits flow bits should be sought and >> fixed. I believe >>> they assumed the flow field is immutable >> >> That was the second point I made at the mike. We'll have to have a >> deprecation path if we change anything. We faced that with RH0, we faced >> that with site local. The sooner that happens the less it will hurt. >> >> Let's face it, the current status is that we have 20 bits in every >> header that are mostly wasted. > > >> Providing rules restricts the freedom of >> what we could have done with those bits, but at least they become >> useful. > Full agreement on this point. > > > What about this combination (not documented yet, it seems) > - Hosts that send non 0 FLs, MUST do it with a value that: > . is common to all packets of their flow > . generally is different from one flow to another > - non 0 FLs MUST be preserved e2e. > - 0 FLs may be changed anywhere, but with the same constraints as in hosts. > > In addition, > - A flow is specified by its 5-tuple, if it exists, or its 3-tuple otherwise. > - The FL value assigned to a flow MAY be EITHER: > . a hash of the flow identification (simple because stateless), OR > . a pseudo random number (more complex because stateful, but providing an > utmost privacy protection > The choice between hash or randomness is made where the FL is set. Other > nodes don't need to know what has been chosen.
Because of your last two bullets I have to ask the following. How would a receiving host deterministically distinguish (1) flow-labels that were created by network devices (just a 5-tuple was put into a flow-label) vs. (2) flow-labels that were created by a source-host w/ a pseudo-random number + 5-tuple[1]? (Please read on before answering :-) If flow-labels were only created by source hosts (scenario #2), then a recv'ing host wouldn't necessarily care how the flow-label was constructed, it would just have to compare recv'd flow-labels over some period of time and/or number of packets to ensure an off-path attack is (most likely) not occurring. OTOH, if you try to combine scenario #1 and #2, then would a recv'ing host have to first check to see if the flow-label was a 5-tuple hash? Assuming it is just based off a 5-tuple, then it ignores checking for off-path attacks (since there is no pseudo-random number in it known only by a source host). Of course, if the recv'd flow-label is determined not to be a 5-tuple hash, then the recv'ing host has to make a leap of faith it's a pseudo-random number + 5-tuple hash and can proceed with using it to verify that no off-path attack is occurring. This is certainly more work on the part of the recv'ing host for every recv'd packet, but perhaps not impossible. (Of course, I may be under-thinking this and would welcome any thoughts you have on if the aforementioned checks I described are necessary or better ways to perform them). Some other potential things to consider by combining scenarios #1 and #2 are as follows: a) We'd need to be very precise in terms of the precise hash algorithm used, so that a recv'ing host could consistently check the recv'd flow-label is a hash of the 5-tuple. It may be the case that different classes of devices (e.g.: mobile phones, desktop/server-class PC's, etc.) may have different reqmt's for an optimal hash algorithm they could use. b) <asbestos-suit-on>If NAT66 were to be adopted and deployed on middleboxes, then the IP addresses in packets would change in-flight in the network. If the middlebox receives a packet with a non-zero flow-label (perhaps because a source host set it to a 5-tuple + pseudo-random number), what happens then?<asbestos-suit-off> So, in summary, it may be that we have to consider EITHER scenario #1 OR #2 as a path forward for the flow-label while acknowledging the associated limitations with both scenarios when doing so. -shane [1] Perhaps along the lines of the following draft? http://tools.ietf.org/html/draft-blake-ipv6-flow-label-nonce-02 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
