[secdir] Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt

"Moriarty, Kathleen" <kathleen.moriarty@emc.com> Sun, 03 November 2013 23:28 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B321E80DC; Sun, 3 Nov 2013 15:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.188
X-Spam-Level:
X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5Fi3NsptGAA; Sun, 3 Nov 2013 15:28:07 -0800 (PST)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4243411E8251; Sun, 3 Nov 2013 15:28:04 -0800 (PST)
Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA3NRP0O009874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 18:27:25 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA3NRP0O009874
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383521247; bh=eDKbkvBWKimuO+JqwjcpxvhZgms=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=b6T0xDJf+9ZITfTjRRiTN4mPynEADsQ0IfbBSSRHw0m6/Z5NZAjMN955qaAFDMUNJ NSUKUruJd9xpSTes2Xjbx9fK6sojKUdIci2+pcie20C0LB5KWa3aHt4QNSCIfBrdhb nkdIpETZdyBIiqyaBooogDUOJnccFmfi7nU4O87s=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA3NRP0O009874
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Sun, 3 Nov 2013 18:27:15 -0500
Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA3NRDE4030103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Nov 2013 18:27:13 -0500
Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Sun, 3 Nov 2013 18:27:12 -0500
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org" <draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org>
Date: Sun, 3 Nov 2013 18:27:12 -0500
Thread-Topic: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt
Thread-Index: AQHO2OwspRhWMDZGTEewZuLZvdGEBQ==
Message-ID: <F5063677821E3B4F81ACFB7905573F240653E7FE11@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public
Cc: "rtorvi@juniper.net" <rtorvi@juniper.net>, "daniel@olddog.co.uk" <daniel@olddog.co.uk>, "lichenyj@chinamobile.com" <lichenyj@chinamobile.com>, "huaimochen@huawei.com" <huaimochen@huawei.com>, "zhenbin.li@huawei.com" <zhenbin.li@huawei.com>, "huanglu@chinamobile.com" <huanglu@chinamobile.com>, "ning.so@tatacommunications.com" <ning.so@tatacommunications.com>, "emily.chen220@gmail.com" <emily.chen220@gmail.com>
Subject: [secdir] Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Nov 2013 23:28:12 -0000

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.

Review:
It is unclear to me how there could not be any security considerations.  The draft introduces the ability to segregate traffic, allowing for the MT capability to be supported and then transitioned to equipment where the capability is not supported.  See section 3.2:

If an LSR is changed from IGP-MT capable to non-MT capable, it may
      wait until the routes update to withdraw FEC and release the label
      mapping for existing LSPs of specific MT.

The introduction states this feature may be used to segregate traffic for different purposes, including the use of management traffic.  Typically, management traffic requires security protections such as session encryption.  The labeling also appears to allow for labels to change in addition to the feature support disappearing.  The security considerations should at least mention that no additional protections are offered through this mechanism of segregating traffic, so that the reader is informed of this risk.  The advantages may be limited to QoS and other possible benefits.  Users should be aware that the segregation offers no security advantage over MPLS without MT.


Editorial nits:

In Introduction, change from isolated to isolate:
Separate routing and MPLS domains may be used to isolated
      multicast and IPv6 islands within the backbone network.

To: Separate routing and MPLS domains may be used to isolate
      multicast and IPv6 islands within the backbone network.

Change Carries to carry:
 Management traffic could be separated from customer traffic using
      multiple MTs, where the management traffic MT does not use links
      that carries customer traffic.
To:  Management traffic could be separated from customer traffic using
      multiple MTs, where the management traffic MT does not use links
      that carry customer traffic.

Section 3.6: Change "imply" to "simply":
Since using different label spaces for different topologies would
   imply significant changes to the data plane, a single global label
   space is supported in this solution. 
Change "peer" to "peers":
There will be one session
   supported for each pair of peer, even there are multiple topologies
   supported between these two peers.

Section 4.3.4:
Change from:
For the case that the LSP ping with return path not specified , the
   reply packet must go through the default topology instead of the
   topology where the Echo Request goes through.
To: For the case that the LSP ping with return path is not specified, the
   reply packet must go through the default topology instead of the
   topology where the Echo Request goes through.

Section 5.1:
Recommend breaking this text into multiple sentences.

Section 6:
Change from:
In case the bad things does happen, according
   to [RFC5036], processing of such message should be aborted.
To: In case the bad things happen, according
   to [RFC5036], processing of such messages should be aborted.

Section 7: I recommend breaking the second paragraph into multiple sentences.


Best regards,
Kathleen