Le 8 sept. 2010 à 14:52, Christopher Morrow a écrit :

> On Wed, Sep 8, 2010 at 5:23 AM, Rémi Després <[email protected]> wrote:
>> 
>> Le 8 sept. 2010 à 03:18, Brian E Carpenter a écrit :
>> 
>>> Hi,
>>> 
>>> The authors of draft-carpenter-6man-flow-update (now also
>>> including Shane Amante) are working on a new version. One
>>> fundamental issue that has come up is about the (lack of)
>>> security properties of the flow label. The most brutal
>>> expression of this is:
>>> 
>>> The flow label field is always unprotected (no IP header
>>> checksum, not included in transport checksums, not included in
>>> IPsec checksum). It cannot be verified and can be used as a
>>> covert channel, so it will never pass a security analysis.

<<<
>>> Thus
>>> some firewalls *will* decide to clear it, whatever the IETF
>>> wants.
>>>

>>> This is inevitable, for exactly the same reason that the
>>> diffserv code point is rewriteable at domain boundaries.
>>> 
>>> If this is correct, it is futile to assert that the flow label
>>> MUST be delivered unchanged to the destination, because we
>>> cannot rely on this in the real world.
>>> 
>>> Are we ready to accept this analysis?
>> 
>> IMHO,yes.
>> 
>> The consequence could be that a FL:
>> - SHOULD be set by the packet source to a value that generally differs from 
>> a flow to another (e.g. a 5-tuple hash)
>> - MAY be reset to zero in intermediate nodes, but only for security reasons
> 
> clarifying question: "only for security reasons"
> which are? (some examples at least here, perhaps not in the end-text)

This was simply in reference to the isolated sentence above (between <<< and 
>>>).
Regards,
RD


> 
> -chris
> 
>> - MAY be reset to a non-zero value in intermediate nodes, provided this 
>> value generally differs from a flow to another.
>> An intermediate node that can identify 3-tuples but not 5-tuples SHOUL NOT 
>> reset FLs to non-zero values.
>> 
>> RD
>> 
>>> 
>>> --
>>> Regards
>>>   Brian Carpenter
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [email protected]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email protected]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to