From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
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: <01160F37-0C73-42CE-AA8C-A09F876080A8@cisco.com>
References: <CAMm+Lwho5C8JzQ92Nk4mQjjhwKG0gvus=xH5G0e6s9smEg=DNg@mail.gmail.com>
In-Reply-To: <CAMm+Lwho5C8JzQ92Nk4mQjjhwKG0gvus=xH5G0e6s9smEg=DNg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.115.58]
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: <http://mailarchive.ietf.org/arch/msg/secdir/s6kSp_e_opODuao5AzA-fUZ29tM>
Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org"
 <draft-ietf-pals-seamless-vccv.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, 
 "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 26 Apr 2016 14:26:44 -0000

--Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Phillip,

Many thanks for your review.

As you rightly call out, this is indeed an incremental addition =E2=80=94 =
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=E2=80=99 security =
considerations are addressed in RFC 5085. This is not 'IPsec pixy-dust' =
=E2=80=94 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=E2=80=99ll 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=E2=80=99ll 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 =E2=80=94 =
perhaps not in a single document, but throughout.

Thanks!

=E2=80=94 Carlos.


> On Apr 26, 2016, at 8:48 AM, Phillip Hallam-Baker =
<phill@hallambaker.com> wrote:
>=20
> 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.
>=20
>=20
> This document is an incremental change to a layer 2 virtualization
> layer (Software Defined Networking). As such it properly references
> RFC5085 for security considerations.
>=20
> 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.
>=20
> 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.
>=20
> 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.


--Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJXH3qfAAoJEIXgpQGOZny9ITUP/i49rfun5vJkz6mKocnx78pp
AMc69Kzly/Ejvztdwow+iCWjcnHVSdjlBqpjZ7napj8VztdvtZ+6Apm9O6V17/Z/
lhFzbG5QrT4ThQO23APvvlbffy5dXVwHc9zjhsJ98hLmZgcBjSY5bu29Q0qI3Fq9
Lz4cHI/uReo8NLZTuFEaoqNUzNVZSTITp9u3LtdIS3drEjyYS6NVRR3rjY6MVTJ7
pIFvU4bLdtdB+tXU3fytWBAJmahrQiLgAJGx5ynBprQSeYz85GXhk3lbS6GTJPEd
bgUdHTrG3/6hPMYoNk+UEb91rIUvG24OjUCtf2NGVuMzlPSY9cowQ4AFeMZdUqWO
2vbo5jLpjwIqDHt3ZsJnJJ0yYQVy3djo5tPuzdYOaFqaf4ZoeTbv/2aKoz9yNzhb
VpKobKIL0KdP7drN5g63Es1ayrBrRUtBUfEo4qmC/x/ebJ0MHUjUuFXlJNqqzFMt
Obr35ejL9mHeLlo8yQg7Ywrujjo9d9j4HDGaQPJLFGffHsQY5b+Rsv2ISJ11dLKl
qfe+RBBlP67IV6YPV4uQ0t8tGrc/MzezsqeJWvYRGtUdpq9kZeB5auchxLDx4iuM
2Poiy32bv40TTuK7Y5PEUatPPosLbvzGdWjSRX2L3f+FWftmTRoJuKqUDdm39VjQ
P84n0vvKQIy/FMI2He8h
=0I7Y
-----END PGP SIGNATURE-----

--Apple-Mail=_5D68EDFC-7C68-4A45-8454-FEE22B9374BA--