Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09191A012A; Mon, 24 Feb 2014 00:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.148 X-Spam-Level: ** X-Spam-Status: No, score=2.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-Gq_A_pSKkM; Mon, 24 Feb 2014 00:51:49 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D52F41A008B; Mon, 24 Feb 2014 00:51:48 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1O8pXbl030851; Mon, 24 Feb 2014 08:51:33 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1O8pTus030804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 08:51:31 GMT From: "Adrian Farrel" To: "'Ryoo, Jeong-dong'" , "'Hilarie Orman'" References: Yourmessage <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563@SMTP2.etri.info>, <201402240551.s1O5pfrm000621@sylvester.rhmr.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60B@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60B@SMTP2.etri.info> Date: Mon, 24 Feb 2014 08:51:31 -0000 Message-ID: <06f501cf313d$9e5a5540$db0effc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06F6_01CF313D.9E5F3740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHW0a4HhHgkCdJLabRfOPDJVH+0HgG+Wc8TAbiYCxuamSBCcA== Content-Language: en-gb X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/XLIYHPQt7oOgGivCNmJN9Uc_k1g Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 08:51:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06F6_01CF313D.9E5F3740 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Perfect. =20 A =20 From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Ryoo, Jeong-dong Sent: 24 February 2014 06:24 To: Hilarie Orman Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org; iesg@ietf.org; = secdir@ietf.org Subject: RE: Security review of draft-ietf-mpls-tp-psc-itu-02.txt =20 Hilarie, thanks for the text. =20 If there is no objection from others,=20 I will add [RFC5920] in the Informative reference section=20 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. --- =20 Again, thanks for your help. =20 Jeong-dong =20 _____ =20 >From : "Hilarie Orman" Sent : 2014-02-24 14:51:55 ( +09:00 ) To : Ryoo, Jeong-dong Cc : secdir@ietf.org , iesg@ietf.org , = draft-ietf-mpls-tp-psc-itu@tools.ietf.org = Subject : RE: Security review of draft-ietf-mpls-tp-psc-itu-02.txt 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"=20 > 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"=20 Sent : 2014-02-24 09:36:04 ( +09:00 ) To : iesg@ietf.org , secdir@ietf.org=20 Cc : draft-ietf-mpls-tp-psc-itu@tools.ietf.org=20 Subject : Security review of draft-ietf-mpls-tp-psc-itu-02.txt 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 ------=_NextPart_000_06F6_01CF313D.9E5F3740 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Perfect.

 

A

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Ryoo, = Jeong-dong
Sent: 24 February 2014 06:24
To: Hilarie = Orman
Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org; = iesg@ietf.org; secdir@ietf.org
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" = <ho@alum.mit.edu>
Sent : 2014-02-24 14:51:55 ( +09:00 = )
To : Ryoo, Jeong-dong <ryoo@etri.re.kr>
Cc : = secdir@ietf.org <secdir@ietf.org>, iesg@ietf.org = <iesg@ietf.org>, draft-ietf-mpls-tp-psc-itu@tools.ietf.org = <draft-ietf-mpls-tp-psc-itu@tools.ietf.org>
Subject : = RE: Security review of = draft-ietf-mpls-tp-psc-itu-02.txt

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"
> 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"
Sent : 2014-02-24 09:36:04 ( = +09:00 )
To : iesg@ietf.org , secdir@ietf.org
Cc : = draft-ietf-mpls-tp-psc-itu@tools.ietf.org
Subject : Security review = of draft-ietf-mpls-tp-psc-itu-02.txt

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


------=_NextPart_000_06F6_01CF313D.9E5F3740--