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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
