Last Call Review of draft-ietf-rtgwg-cl-requirement-10
review-ietf-rtgwg-cl-requirement-10-secdir-lc-yu-2013-06-20-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 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?

Editorial:

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.