Fernando, Thanks for the comments. About the non-editorial points:
On 2010-12-16 09:39, Fernando Gont wrote: ... > Section 2 states: > >> Also, it could be used as a covert data channel, since apparently >> pseudo-random flow label values could in fact consist of encrypted >> data. > > Actually, an attacker willing to exploit this field for a covert channel > would *not* set it to a pseudo-random value, but simply to the data > bytes it is meaning to transfer over the covert channel. Yes, that is what the text is supposed to mean. When you look at dbeef, you can't tell whether it's a perfectly good random number, part of a cleartext message about steak, or part of a cyphertext. Would it be more general to say Also, it could be used as a covert data channel, since apparently pseudo-random flow label values could in fact consist of useful data. > > > Section 2: > >> In this >> sense, any use of the flow label must be viewed as an optimisation on >> a best effort basis; a packet with a changed (or zero) flow label >> value should never cause a hard failure. > > If a packet with a changed flow label should not cause malfunction, and > as you correctly note the Flow Label is not even covered by a checksum, > the requirement of "A forwarding node MUST NOT change the flow label > value in an arriving packet if it is non-zero" (in Section 4, page 7) is > bogus. If anything, it should be a "SHOULD NOT". I understood the WG preference to be for stating the *requirement* as MUST NOT. Conformance is another matter. > > > >> o The flow label is no longer unrealistically asserted to be >> strictly immutable; it is recognised that it may, incorrectly, be >> changed en route. In some circumstances this will break end-to- >> end usage, e.g. potential detection of third-party spoofing >> attacks [I-D.gont-6man-flowlabel-security]. > > end-to-end usage is already broken by the fact that the Flow Label is > not protected in any way. e.g., you cannot reliably use the Flow Label > to protect against off-path spoofing attacks. (This is also exacerbated > by some implementations not even setting the Flow Label consistently). Well, if you make that argument, every nonce-based security solution is broken, because there is always a finite chance that an attacker can guess the nonce. Again, my reading of the WG discussion is to accept the situation as described in the draft. > > > Section 4 (page 7): > >> 3. A forwarding node MUST NOT change the flow label value in an >> arriving packet if it is non-zero. > > See above. See above ;-) Regards Brian > > Thanks! > > Kind regards, -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------