Last Call Review of draft-ietf-rtgwg-cl-requirement-10

Request Review of draft-ietf-rtgwg-cl-requirement
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-19
Requested 2013-06-07
Authors Curtis Villamizar, Dave McDysan, Ning So, Andrew Malis, Lucy Yong
Draft last updated 2013-06-20
Completed reviews Genart Last Call review of -10 by Francis Dupont (diff)
Genart Last Call review of -13 by Francis Dupont (diff)
Genart Telechat review of -15 by Francis Dupont (diff)
Secdir Last Call review of -10 by Taylor Yu (diff)
Secdir Last Call review of -13 by Taylor Yu (diff)
Opsdir Last Call review of -13 by Tina Tsou (diff)
Assignment Reviewer Taylor Yu
State Completed
Review review-ietf-rtgwg-cl-requirement-10-secdir-lc-yu-2013-06-20
Reviewed rev. 10 (document currently at 16)
Review result Has Issues
Review completed: 2013-06-20


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 states many requirements on properties of proposed
solutions, but it seems that none of these requirements is a security
requirement.  If nodes need to send new information that existing
routing or signaling protocols do not currently send, what level of
protection does that information require?

In the Security Considerations section, I'm not sure what the intent
is in using the phrasing "man-in-the-middle confidentiality breach".
I generally consider "man-in-the-middle" to mean an active attacker
(one that can receive, suppress, modify, and transmit arbitrary data);
this type of attacker primarily has consequences for integrity.  (An
active attacker could also compromise the confidentiality of a channel
that is secure against passive attackers).  A passive attack is often
sufficient to compromise confidentiality, especially if a protocol
sends information in the clear.

What scope of compromise does "provider breach" designate?


This document uses many acronyms without expanding them -- almost all
of them, from what I can see.  Some of the more prominent ones include
DSCP, LDP, LSP, PW, RSVP-TE.  Arguably terms such as MPLS, VLAN, and
VPN count as well-known acronyms in the IETF community.