[secdir] review of draft-ietf-pce-pcep-domain-sequence-09

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Mon, 09 November 2015 15:40 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 12AF01B2E2D; Mon, 9 Nov 2015 07:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vgTeqhvxuDf7; Mon, 9 Nov 2015 07:40:53 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F211B2D84; Mon, 9 Nov 2015 07:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2756; q=dns/txt; s=iport; t=1447083653; x=1448293253; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zAYK1jcvooQ1vGSgF4z4/qiVDzmk7KBdGYVWtAOZ1Ug=; b=jDgPTonouJYhTISaJhqxVLL7Cx/KzH2fYxPs4I6xOQke3fmHZ8fRSJZ4 Km0olnkmhGHLkTn3JlYngZ1EDR7YVtxCNb+/YSOOigMNFYJlXx5rzUdjl SnMSeApzAujd7dVkmF6FbJmUHC2LOXD6Pd6H6+2Me2xg1gIhEtLH/mwT0 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.20,266,1444694400"; d="scan'208";a="43344392"
Received: from alln-core-1.cisco.com ([]) by rcdn-iport-8.cisco.com with ESMTP; 09 Nov 2015 15:40:52 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com []) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tA9FeqU7014372 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2015 15:40:52 GMT
Received: from xch-aln-004.cisco.com ( by XCH-RCD-002.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 Nov 2015 09:40:51 -0600
Received: from xch-aln-004.cisco.com ([]) by XCH-ALN-004.cisco.com ([]) with mapi id 15.00.1104.000; Mon, 9 Nov 2015 09:40:52 -0600
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pce-pcep-domain-sequence.all@ietf.org" <draft-ietf-pce-pcep-domain-sequence.all@ietf.org>
Thread-Topic: review of draft-ietf-pce-pcep-domain-sequence-09
Thread-Index: AQHRGwUD9OAYpOIf9kWtChw4jaJrVg==
Date: Mon, 9 Nov 2015 15:40:52 +0000
Message-ID: <0424E22D-879D-4F05-B474-DE421FF1FADB@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <75F4D9188A24B64C889B2B44B5655B8E@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Eqw3RLdHlpTIr1dbGe9KGl267-4>
Subject: [secdir] review of draft-ietf-pce-pcep-domain-sequence-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 09 Nov 2015 15:40:55 -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.

I consider the document “ready with issues”, see below for detailed comments:

* 4.1 Inter-Area Path Computation

you write: "This could be represented in the IRO as:” and then a number of diagrams. It is unclear to me whether those different option are functionally equivalent. The text suggests so to me, but that doesn’t seem to make sense….. (or I completely misunderstand the text)

To me it seems that the three sequences you give are all possible sequences for the given topology not equivalent, I think the text needs some clarification in that case.

The same goes for 4.2, 4.3 etc.

* 4.5 P2MP

I am guessing that the tree you show is the result of the three paths you give before, but some explanation would be good.

7 security considerations

I think these are a bit weak. Especially compared to what RFC5440 provides. I consider an attacker gaining fine grained control over the network path a very serious risk. The flippant comment about “routing around trouble” doesn’t really do it for me. I would encourage you to take a good look at the security considerations in 5440 and assess how those considerations change given the finer grained control you provide. Some or even most may remain the same, and it is fine to say so, but I can imagine that some risks are higher because of the fine-grained control, and you seem to suggest so too given the “the security techniques in rfc5440 are considered more important”. So I really think this draft would benefit from a better security considerations section.

Hope this helps,


Klaas Wierenga
Identity Architect
Cisco Cloud Services