Skip to main content

Last Call Review of draft-ietf-mpls-tp-framework-
review-ietf-mpls-tp-framework-secdir-lc-nystrom-2010-05-03-00

Request Review of draft-ietf-mpls-tp-framework
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-04-26
Requested 2010-04-09
Authors Dan Frost , Lieven Levrau , Lou Berger , Stewart Bryant , Matthew Bocci
I-D last updated 2010-05-03
Completed reviews Secdir Last Call review of -?? by Magnus Nyström
Assignment Reviewer Magnus Nyström
State Completed
Request Last Call review on draft-ietf-mpls-tp-framework by Security Area Directorate Assigned
Completed 2010-05-03
review-ietf-mpls-tp-framework-secdir-lc-nystrom-2010-05-03-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 the architectural framework for applying MPLS to
transport networks. It is joint work with the ITU-T.

The document does not contain any normative statements in the RFC 2119 sense;
presumably this is because the framework nature of the document and/or the
coupling to ITU-T, but it is a little concerning as there are a number of
"must", "should" and "may" statements in the document that do look normative to
me (e.g. "In cases   where a MAC address is needed, the sending node must set
the   destination MAC address to an address that ensures delivery to the  
adjacent node.").

The security considerations section is very brief and consists mainly of
references to other, related documents' security considerations sections. I
think it could have been beneficial if it had covered security aspects stemming
from the architectural framework and not only force the reader to turn to the
component documents. For example, since G-ACh traffic is indistinguishable at
the server layer from data traffic, is it possible to craft data traffic
messages that confuse a server to believe it is G-ACh? Or, does the bandwidth
sharing between control traffic and user data traffic have any security
implications? Also, the NNI traffic may involve signaling over the same channel
as user data traverse which may cause similar concerns (I am not an expert on
MPLS or TP so these threats may well not be realistic, however they serve only
as examples).

(A minor editorial suggestion: Perhaps better if the list of acronyms in
Section 1.3 would be in alphabetical order?)

-- Magnus