[secdir] Security Directorate review of draft-ietf-pwe3-dynamic-ms-pw-20

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Mon, 06 January 2014 09:51 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 CC2871AD69E; Mon, 6 Jan 2014 01:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.039
X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, 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 FPCSBWXDNC7k; Mon, 6 Jan 2014 01:51:39 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 97FC61AD603; Mon, 6 Jan 2014 01:51:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1521; q=dns/txt; s=iport; t=1389001890; x=1390211490; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3KW4jb3ULUmLnmQgR/px/SKCDIFr4LI9g0y4r922m8I=; b=RGUDmJ4OJsKfqxEObKP4CGaddIf9K8zv7/pR8nXspKypEAjp9t1x9usB LgLKtMW/1TuyNgbls/Lw6tTewjDntg+Guko3f4bXKkPg9tcEf20c5m70L hpzKdn0wTJGHBjrWsZFts3q91jGb6QIqDggBFkoDS+tRKtJfqDEFsBQmg 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANh7ylKtJXHA/2dsb2JhbABYgwuBDbpWFnSCLDpRAT5CJwQBiBbDYxeSOoETBJgXkhWDLYIq
X-IronPort-AV: E=Sophos;i="4.95,611,1384300800"; d="scan'208";a="295490476"
Received: from rcdn-core2-5.cisco.com ([]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jan 2014 09:51:30 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com []) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s069pUiF013620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 09:51:30 GMT
Received: from xmb-aln-x12.cisco.com ([]) by xhc-aln-x10.cisco.com ([]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 03:51:30 -0600
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pwe3-dynamic-ms-pw.all@tools.ietf.org" <draft-ietf-pwe3-dynamic-ms-pw.all@tools.ietf.org>
Thread-Topic: Security Directorate review of draft-ietf-pwe3-dynamic-ms-pw-20
Thread-Index: AQHPCsTfytZKjSSLZEyTvepq9ynOww==
Date: Mon, 6 Jan 2014 09:51:29 +0000
Message-ID: <5784D17B-CADE-4298-953C-37423DF6A66F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FB4C32B89010274984D85FE2A43FD4FB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] Security Directorate review of draft-ietf-pwe3-dynamic-ms-pw-20
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: <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: Mon, 06 Jan 2014 09:51:41 -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.

The draft describes extensions to the pseudowire control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers.

The draft is relatively straightforward and clear, but from a security PoV I did take issue with the statement in the security considerations that goes:

"This document specifies only extensions to the protocols already defined in [RFC4447], and [RFC6073]. The extensions defined in this document do not affect the security considerations for those protocols."

When you essentially propose a mechanism to insert dynamically men in the middle you can imo not just state that nothing changes. In the meanwhile I have talked to some people that are much more cognisant about pseudowires than I am, and I have let myself be convinced that this indeed not introducing new attack vectors (as compared to static PW and normal MPLS networks), and that existing threats can be mitigated by doing end to end connection verification, but I believe that others, like me would be helped by a short discussion pertaining to this.

Hope this helps,