Skip to main content

Last Call Review of draft-ietf-6man-flow-3697bis-
review-ietf-6man-flow-3697bis-secdir-lc-barnes-2011-08-01-00

Request Review of draft-ietf-6man-flow-3697bis
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-07-12
Requested 2011-06-30
Authors Shane Amante , Jarno Rajahalme , Brian E. Carpenter , Sheng Jiang
I-D last updated 2011-08-01
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Request Last Call review on draft-ietf-6man-flow-3697bis by Security Area Directorate Assigned
Completed 2011-08-01
review-ietf-6man-flow-3697bis-secdir-lc-barnes-2011-08-01-00
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.  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.

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 ... "

--Richard