Re: [secdir] secdir review of draft-ietf-6man-flow-3697bis

[Sean Turner <[e-mail]>]

On 7/11/11 4:54 PM, Brian E Carpenter wrote:
> Richard,
>
> Thanks for the review.
>
> On 2011-07-12 01:17, Richard L. Barnes wrote:
>> I have reviewed this document as part of the security
>> directorate's ongoing effort to review all IETF documents
>> being processed by the IESG.  These comments were written
>> primarily for the benefit of the security area directors.
>> Document editors and WG chairs should treat these comments
>> just like any other last call comments.
>>
>> This document describes how end hosts and intermediate nodes
>> should populate and handle the IPv6 flow label field.  The
>> document spends a fair bit of time discussing security
>> considerations related to the flow label and its relation to
>> IPsec in particular.  Overall, the document does a thorough
>> job of discussing security considerations, and I don't think
>> there's anything they've clearly missed.
>>
>> The only request I would have would be for the authors to add
>> a little more discussion around the "theft of service"
>> threat.  It would be helpful to detail the
>> assumptions/circumstances under which this threat aries --
>> namely that networks provide resources based on flow label
>> and flow label values are set by end hosts.
>
> The difficulty about doing this is that (as the WG wanted) we
> have dropped almost all of the discussion of flow state
> establishment methods, which is really where these risks arise.
> To be frank I think that anything we could add would be
> hand-waving.
>
>> Given the risks
>> that this document discusses, it might be worth considering a
>> recommendation that networks SHOULD NOT make resource
>> allocation decisions based on flow labels without some
>> external means of assurance.  Or some similar warning against
>> making resource decisions on a completely unsecured field.
>
> Yes, that makes sense when *not* in the stateless load
> distribution scenario.
>
>>
>> Also, purely from a terminology perspective, I found the
>> phrase "unintended service" confusing and less accurate than
>> the "better service" phrase used in RFC 3697.  It might be
>> better to spell this out: " ... an adversary may be able to
>> obtain a class of service that the network did not intend to
>> provide ... "
>
> Agreed.
>
> However - the I-D cutoff is upon us, so although I will post an
> update in the next few minutes, I'm afraid these changes will
> not be made before the IESG telechat.

Plan B, which some people hate, is to write up an RFC editor note (i.e., 
OLD/NEW) for Jari.

spt