ietf
[Top] [All Lists]

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

2011-07-11 15:55:28
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.

Regards
   Brian Carpenter
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>