Hi, Brian et al., (I was meaning to send this one more than a week ago... but apparently this one got stuck in my "Drafts" folder)
In general, the document looks good. However, there are IMO a few issues that should probably be fixed. In the Abstract, one gets the impression that this document actually updates RFC 3697. I think this should be more clear in the abstract, and also possibly in the Introduction. In Section 1, this paragraph is duplicated: > RFC 2460 mandates only that "Hosts or routers that do not support the > functions of the Flow Label field are required to set the field to > zero when originating a packet, pass the field on unchanged when > forwarding a packet, and ignore the field when receiving a packet." I'd remove the second instance of it. 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. 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". > 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). 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. Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
