Subject: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt

From: "Hilarie Orman" <[email-masked]>
Date: Sun, 23 Feb 2014 17:35:27 -0700

Security review of draft-ietf-mpls-tp-psc-itu-02.txt
MPLS Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of SDH, OTN and Ethernet Transport Network
Operators 

Do not be alarmed.  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.

The abstract for this document states:
   This document describes alternate mechanisms to perform some of the
   sub-functions of MPLS Transport Profile (MPLS-TP) linear protection
   defined in RFC 6378, and also defines additional mechanisms.  The
   purpose of these alternate and additional mechanisms is to provide
   operator control and experience that more closely models the behavior
   of linear protection seen in other transport networks.

The security considerations are the timeworn statement that

   No specific security issue is raised in addition to those ones
   already documented in RFC 6378 [RFC6378]

In RFC 6378 we find:    
   MPLS networks make the assumption that it is very hard to inject
   traffic into a network and equally hard to cause traffic to be
   directed outside the network.  The control-plane protocols utilize
   hop-by-hop security and assume a "chain-of-trust" model such that
   end-to-end control-plane security is not used.  For more
   information on the generic aspects of MPLS security, see [RFC5920].

To my great astonishment I found that "RFC5920 Security Framework for
MPLS and GMPLS Networks" is an excellent document, and it is my
suggestion that the current draft reference it directly in section 13
"Security Considerations".

Barring any surprises in the extensive state diagrams, I otherwise am
inclined to accept the "no new issues" handwave.

Hilarie

---

From: "Hilarie Orman" <[email-masked]>
Date: Sun, 23 Feb 2014 22:51:41 -0700

Something like:

"This document introduces no new security risks.  RFC 6378 points out
that MPLS relies on assumptions about traffic injection difficulty and
assumes the the control plane does not have end-to-end security.
RFC520 describes MPLS security issues and generic methods for securing
traffic privacy and integrity.  MPLS use should conform such advice."

Hilarie

>  From: "Ryoo, Jeong-dong" <[email-masked]>
>  Date: Mon, 24 Feb 2014 04:35:08 +0000
Dear Hilarie,

Thanks for your comment.

I am not sure about what text has actually to be put in the Section 13 to reflect your suggestion.
Do you have any text in mind?

Best regards,

Jeong-dong

________________________________
>From : "Hilarie Orman" <[email-masked]>
Sent : 2014-02-24 09:36:04 ( +09:00 )
To : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Cc : [email-masked] <[email-masked]>
Subject : Security review of draft-ietf-mpls-tp-psc-itu-02.txt

In RFC 6378 we find:

Hilarie

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Feb 2014 08:51:31 -0000

Perfect.
 
A
 
From: iesg [mailto:[email-masked]] On Behalf Of Ryoo, Jeong-dong
Sent: 24 February 2014 06:24
To: Hilarie Orman
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Security review of draft-ietf-mpls-tp-psc-itu-02.txt
 
Hilarie, thanks for the text.
 
If there is no objection from others, 
I will add [RFC5920] in the Informative reference section 
and replace current text in Section 13 with the following text:
---
   This document introduces no new security risks.  [RFC6378] points out
   that MPLS relies on assumptions about traffic injection difficulty
   and assumes that the control plane does not have end-to-end security.
   [RFC5920] describes MPLS security issues and generic methods for
   securing traffic privacy and integrity.  MPLS use should conform such
   advice.
---
 
Again, thanks for your help.
 
Jeong-dong

  _____  

>From : "Hilarie Orman" <[email-masked]>
Sent : 2014-02-24 14:51:55 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>
Cc : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject : RE: Security review of draft-ietf-mpls-tp-psc-itu-02.txt

Something like:

Hilarie

> From: "Ryoo, Jeong-dong" 
Dear Hilarie,

Thanks for your comment.

Best regards,

Jeong-dong

>From : "Hilarie Orman" 
Sent : 2014-02-24 09:36:04 ( +09:00 )
To : [email-masked] , [email-masked] 
Cc : [email-masked] 
Subject : Security review of draft-ietf-mpls-tp-psc-itu-02.txt

In RFC 6378 we find:

Hilarie

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 24 Feb 2014 04:35:08 +0000

Dear Hilarie,

Thanks for your comment.

Best regards,

Jeong-dong

In RFC 6378 we find:

Hilarie

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 24 Feb 2014 06:23:49 +0000

Jeong-dong

Something like:

Hilarie

Dear Hilarie,

Thanks for your comment.

Best regards,

Jeong-dong

In RFC 6378 we find:

Hilarie