Last Call Review of draft-ietf-mpls-tp-itu-t-identifiers-06
review-ietf-mpls-tp-itu-t-identifiers-06-secdir-lc-harkins-2013-01-10-00

Request Review of draft-ietf-mpls-tp-itu-t-identifiers
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-01-04
Requested 2012-12-20
Draft last updated 2013-01-10
Completed reviews Genart Last Call review of -06 by Christer Holmberg (diff)
Genart Telechat review of -07 by Christer Holmberg (diff)
Secdir Last Call review of -06 by Dan Harkins (diff)
Assignment Reviewer Dan Harkins
State Completed
Review review-ietf-mpls-tp-itu-t-identifiers-06-secdir-lc-harkins-2013-01-10
Reviewed rev. 06 (document currently at 08)
Review result Has Nits
Review completed: 2013-01-10

Review
review-ietf-mpls-tp-itu-t-identifiers-06-secdir-lc-harkins-2013-01-10

  Hello, and happy new year,

  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 draft creates a new globally unique identifier for the Transport
Profile of MPLS. RFC 6370, which created identifiers for MPLS-TP,
uses the operator's AS as a globally unique identifier but this draft
proposes an alternative: use the ITU-T Carrier Codes. It then goes
about changing the identifiers created by RFC 6370 by substituting
the ITU-T Carrier Code for the AS.

  The security considerations state that the draft merely extends an
information model and does not propose any protocol changes and
therefore it does not introduce any new security concerns. This seems
acceptable except that this extension relies on the global uniqueness
of the ITU-T Carrier Codes (as RFC 6370 relies on the AS to be
globally unique). Apparently "national regulatory authorities"
ensure that they are unique in their regulatory domain (which is an
ISO 3166-1 identified code) so as long as they don't screw up
anything all is well. I think it might be worth mentioning the
assumption that the "national regulatory authorities" will not make a
mistake and what happens if they do. RFC 6370 relied on IANA to
not make a mistake; this draft relies on all 249 entities that have an
official code in ISO 3166-1 to not make a mistake.

  Also, there is a normative reference to a "Corrigendum" of an ITU-T
recommendation on "OAM functions and mechanisms for Ethernet
based networks". I have never encountered such a document. Is it
a stable reference?

  regards,

  Dan.