Return-Path: 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 12E6E120727; Tue, 26 Apr 2016 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cxTS5zO-m1y; Tue, 26 Apr 2016 14:27:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4E512D0F2; Tue, 26 Apr 2016 14:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13566; q=dns/txt; s=iport; t=1461706065; x=1462915665; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z8F1+sJZgHBRD4lNUdhG8v05rZUAW+WXQDHS4oPre+g=; b=ezCxpVfc51TOFGx9qhvnv2cH6qczlQlP5FocB8LQLigefMH/XRFTVC4D vxtWFETBe6NlD+rL+LCjKQIa8FfD71/vJfpo4Y7PPh2Gm+KsheaL2Pi7N PNZ5yQOhmj6Arnsq4L/v6BXYSQ9JOq2zbY8tjvlUXeMSPvJn3EV3j5OlI k=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAgBI3B9X/5RdJa1egzhTfQauG4Zqg?= =?us-ascii?q?mSCDw6BdB6CQIMxAoFAOBQBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCBIGKgICIRE?= =?us-ascii?q?XDgIEDgUODYd6AwoIDrM4jCINhGEBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASGI?= =?us-ascii?q?YF1CIJOgkGCK4JTK4IrBZMfhEAxAYMngWdthiWBdo8Rh1GHXgEeAUOCBRuBS2y?= =?us-ascii?q?IL38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,538,1454976000"; d="asc'?scan'208,217";a="101611183" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2016 21:27:43 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3QLRh6J002162 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Apr 2016 21:27:43 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Apr 2016 17:27:42 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 26 Apr 2016 17:27:42 -0400 From: "Carlos Pignataro (cpignata)" To: Phillip Hallam-Baker Thread-Topic: SECDIR review of draft-ietf-pals-seamless-vccv-02 Thread-Index: AQHRn7noe7HtbKiJG0u+NZfEBeLzNZ+ckJsAgAAJNACAAG64gA== Date: Tue, 26 Apr 2016 21:27:42 +0000 Message-ID: <274768D8-88B0-4290-AEFF-463C3AD02CF6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.239] Content-Type: multipart/signed; boundary="Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" , "Andrew G. Malis" , "iesg@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 21:27:48 -0000 --Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F Content-Type: multipart/alternative; boundary="Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6" --Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phillip, > rather than action on this particular draft. OK. Thanks. > On Apr 26, 2016, at 10:51 AM, Phillip Hallam-Baker = wrote: >=20 > Yes, I think that what is needed is IAB review of what is going on > rather than action on this particular draft. >=20 > In particular, I don't consider a protocol suitable to be considered > an IETF standard unless people can buy devices from multiple vendors > and configure them to work together securely. >=20 > The security approach outlined in 5085 is mix and match with a large > dose of handwaving. It desperately needs to be reconsidered and a > security architecture written up. To add further context, RFC 5085 describes, at a high level, OAM for = PWs. To understand your point, do you mean there=E2=80=99s a need for a = security architecture for OAM for PWs? Some of your comments are generic = (see below for an example), and somewhat hard for me to parse if you = mean the infrastructure itself, the PWs, the L2VPNs, the OAM on top, or = something else. > I don't think that you can expect > interoperability on the basis of that description. >=20 https://tools.ietf.org/html/rfc7079 = (I=E2=80=99ve not contributed to that RFC, but seems to imply the only = interop hiccup has been the optional CW with Ethernet PWs, not OAM) > The Snowden documents demonstrate that 'well managed enterprise > networks' are attacked on a daily basis and that this is the basis for > mass surveillance. >=20 > I do not consider IPSEC to be a suitable security mechanism for this > type of system. If I was given the design brief, I would insist that > every message be authenticated by digital signature rather than a MAC > and the control messages logged. I might use a MAC for > pre-authentication to prevent DoS attack on the control plane. But the > control messages should be fixed in non repudiable fashion. >=20 > That is the only way I could be confident that PRISM class attack > against the network had not been performed. >=20 This exemplifies my earlier point: =E2=80=9Cagainst the network=E2=80=9D = seems quite generic. You have control message exchange without RFC 5085 = and without this draft. Thanks! =E2=80=94 Carlos. >=20 > On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis = wrote: >> Phillip, >>=20 >> On behalf of the PALS WG, thanks for your review. >>=20 >> To be clear, this sounds like more a comment on RFC 5085 than it does = a >> comment on the draft in question. So is there any action requested = regarding >> the draft? >>=20 >> Also, you many not be aware that pseudowires are almost exclusively = used in >> well-managed private enterprise services networks, usually either = physically >> or logically separated from the public Internet for reasons of both = traffic >> management and assurance to enterprise customers that their private = traffic >> is well separated from the Internet. Thus interception is less a = threat than >> it may be for protocols that are used in the public Internet. >>=20 >> Thanks, >> Andy >>=20 >>=20 >> On Tue, Apr 26, 2016 at 8:48 AM, Phillip Hallam-Baker >> 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. >>=20 >>=20 --Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Phillip,

rather than action on = this particular draft.

OK. Thanks.

On = Apr 26, 2016, at 10:51 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

Yes, = I think that what is needed is IAB review of what is going on
rather than action on this particular draft.

In particular, I don't consider a protocol suitable to be = considered
an IETF standard unless people can buy devices = from multiple vendors
and configure them to work together = securely.

The security approach outlined in = 5085 is mix and match with a large
dose of handwaving. It = desperately needs to be reconsidered and a
security = architecture written up.

To add further context, RFC 5085 describes, at a high = level, OAM for PWs. To understand your point, do you mean there=E2=80=99s = a need for a security architecture for OAM for PWs? Some of your = comments are generic (see below for an example), and somewhat hard for = me to parse if you mean the infrastructure itself, the PWs, the L2VPNs, = the OAM on top, or something else.

 I don't think that you can expect
interoperability on the basis of that description.



(I=E2=80=99ve not contributed to that RFC, but = seems to imply the only interop hiccup has been the optional CW with = Ethernet PWs, not OAM)

The Snowden documents = demonstrate that 'well managed enterprise
networks' are = attacked on a daily basis and that this is the basis for
mass surveillance.

I do not = consider IPSEC to be a suitable security mechanism for this
type of system. If I was given the design brief, I would = insist that
every message be authenticated by digital = signature rather than a MAC
and the control messages = logged. I might use a MAC for
pre-authentication to = prevent DoS attack on the control plane. But the
control = messages should be fixed in non repudiable fashion.

That is the only way I could be confident that PRISM class = attack
against the network had not been performed.


This exemplifies my earlier point: = =E2=80=9Cagainst the network=E2=80=9D seems quite generic. You have = control message exchange without RFC 5085 and without this = draft.

Thanks!

=E2=80=94 Carlos.


On Tue, Apr = 26, 2016 at 10:18 AM, Andrew G. Malis <agmalis@gmail.com> = wrote:
Phillip,

On behalf of the PALS WG, thanks for your = review.

To be clear, this sounds like more = a comment on RFC 5085 than it does a
comment on the draft = in question. So is there any action requested regarding
the = draft?

Also, you many not be aware that = pseudowires are almost exclusively used in
well-managed = private enterprise services networks, usually either physically
or logically separated from the public Internet for reasons = of both traffic
management and assurance to enterprise = customers that their private traffic
is well separated = from the Internet. Thus interception is less a threat than
it may be for protocols that are used in the public = Internet.

Thanks,
Andy


On Tue, Apr 26, 2016 at 8:48 = AM, Phillip Hallam-Baker
<phill@hallambaker.com> 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.



= --Apple-Mail=_949C6DE8-0432-44A9-9FE3-3E36A3FEEFC6-- --Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F 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 iQIcBAEBCAAGBQJXH91MAAoJEIXgpQGOZny9BPoQAIfsG5ZK3UoK75QfPueLduSF 3VQvqoD80eDt0mT+8prV2BEIXmtrgTr5Z6sDFd8//+Of5dIoc9L1I6wT+4UhnyX2 doWK+W/5fw3xILHdafr0PXgCOCW7Sx9HlpBjQBwJpyzqNBJi2NKsP0LPUxh5Nl0T urfwUk09cmahjJcQdLVHVfmkGzFFHT5Oc0E2V8dcPP4EVLvbrLBfkPYGjwspIQqJ sOoj/Wla34symh3MktFxr1/gfyjEa/ra9UhvOam9rtkdd1FY3rzY10ZxLxumCwM+ cOd3LNt/DfWD+Wy5ItRUpHLIXOViPzPfeovnPmCG5IYP8gvUYT7IuIAPcXWD5KI0 wZ/82Wi2WmDozCk8CfeW0/LrGdxoxB4TsDCK+EmliSP57YlznOmUG98tWY5ck9RQ purYNTnWwziVtL+LWy6kBmmuoXHyIidKxLfIyyyh/ilCiwHLgGp0W7nAsJBeRKQy o4SttX+zfPjr0kXpkvHg6myrznfXy9veqRCvZWLL3lxKEpdPu5vOVhbnNxv7EKOe IfLjojEswloXR1XoWjCPV3w81+IF76hxaLsE0RzUjPDk6ZAGJcC9xktW8IGpwANv uPG/GtCyx6UflMzqdyHDRMf8ycrPljdQL3KpLym6jnWI9bq6usDON4MW3NK8AjLr Sa3t4F9glZ3ZQhIOawCm =9nSv -----END PGP SIGNATURE----- --Apple-Mail=_A1969861-7133-4F2F-8FA2-62DE500FF49F--