Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02

"Carlos Pignataro (cpignata)" <> Tue, 26 April 2016 14:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32B8C12D1D7; Tue, 26 Apr 2016 07:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 53CClAQ6LK61; Tue, 26 Apr 2016 07:26:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7226712D1D4; Tue, 26 Apr 2016 07:26:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4334; q=dns/txt; s=iport; t=1461680802; x=1462890402; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FLibItUMerfTnsYLmZV8dDYqQq4oGnpJSCygrXxB1yA=; b=Wu+lDc3mmuz0Ta9B33qoT/3CAg4vXIo2Z+v2OQwvh7ylCegk/44fOq7N loAVd3/Ulti3w/csH03/zaexwcTtVpuZ7Lc4gfYjb0W5i4qCQ/hPXbGcF DdOsFRKbp8tSj+ac7A+9AdDh+ywnr8shuXSc5QGid1LGQGr9DGLJr628C 0=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAgCbeR9X/5FdJa1egziBUAa3Z4IPD?= =?us-ascii?q?oF0gl6DMAKBNjgUAQEBAQEBAWUnhEEBAQEDASNWBQsCAQgSBioCAjIXDgIEDgU?= =?us-ascii?q?ODYgHCLJqkTUBAQEBAQEBAQEBAQEBAQEBAQEBAQ4IhiGBdYJWhz8rgisFkx+Ec?= =?us-ascii?q?QGDJ4FniQiBZ4RNiF2PLwEeAUOCBRuBS2yIAX8BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,536,1454976000"; d="asc'?scan'208";a="265600419"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2016 14:26:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u3QEQf5Y025952 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Apr 2016 14:26:41 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Apr 2016 10:26:40 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Tue, 26 Apr 2016 10:26:40 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Phillip Hallam-Baker <>
Thread-Topic: SECDIR review of draft-ietf-pals-seamless-vccv-02
Thread-Index: AQHRn7noe7HtbKiJG0u+NZfEBeLzNZ+ckuUA
Date: Tue, 26 Apr 2016 14:26:40 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Apr 2016 14:26:44 -0000


Many thanks for your review.

As you rightly call out, this is indeed an incremental addition — I might add for emphasis a very incremental change.

One point of clarification, however, is that this solution as defined does _not_ use BGP. The relevant control protocols’ security considerations are addressed in RFC 5085. This is not 'IPsec pixy-dust' — if you follow the pointers, you will get to the control connection (endpoint and message) security as well as protection for data plane spoofing.

In re-reading the Security Considerations section (thanks again for the review), I do believe there is an area of improvement: from RFC 5885, since these PWs specify single-hop adjacencies, the document ought to specify the use of GTSM for the IP/UDP encapsulations.

I’ll be happy to add that in. Please let me know if you have any concerns with it.

Phillip, Andy, Stewart,

Lastly, Phillip, you are suggesting or recommending the development of a comprehensive security architecture (scoped for L2VPNs? or PWs? or VCCV?). Since that is clearly beyond the scope of this (incremental) doc, I’ll let Andy and Stewart (PALS chairs) answer that one.

My personal opinion as individual participant is that all the different security considerations for each architectural building block and modules (control planes, data plane, attacks, etc) are in place — perhaps not in a single document, but throughout.


— Carlos.

> On Apr 26, 2016, at 8:48 AM, Phillip Hallam-Baker <> wrote:
> 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.
> This document is an incremental change to a layer 2 virtualization
> layer (Software Defined Networking). As such it properly references
> RFC5085 for security considerations.
> That said, I am a bit surprised at the security considerations in
> RFC5085 which points out that denial of service is an issue but not
> the introduction of a new set of opportunities for interception. This
> is surprising given that BGP interception had already been used in
> international hostilities when the RFC was published.
> Further the proposed solution is to sprinkle on some magic IPSEC dust
> or equivalent. While that might be an appropriate approach in an
> experimental protocol, it is hardly adequate for a production protocol
> with implications for Internet security as a whole.
> Given the critical function of this layer and the date of its
> inception, I would expect to see a comprehensive security architecture
> developed as part of the overall scheme.