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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 26 April 2016 21:27 UTC

Return-Path: <cpignata@cisco.com>
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: A0DvAgBI3B9X/5RdJa1egzhTfQauG4ZqgmSCDw6BdB6CQIMxAoFAOBQBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCBIGKgICIREXDgIEDgUODYd6AwoIDrM4jCINhGEBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASGIYF1CIJOgkGCK4JTK4IrBZMfhEAxAYMngWdthiWBdo8Rh1GHXgEeAUOCBRuBS2yIL38BAQE
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)" <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+ckJsAgAAJNACAAG64gA==
Date: Tue, 26 Apr 2016 21:27:42 +0000
Message-ID: <274768D8-88B0-4290-AEFF-463C3AD02CF6@cisco.com>
References: <CAMm+Lwho5C8JzQ92Nk4mQjjhwKG0gvus=xH5G0e6s9smEg=DNg@mail.gmail.com> <CAA=duU3uvJ+HOMvmgkCdn4dVQRHQus5XHSQd+RhDJTVpF1O5nw@mail.gmail.com> <CAMm+Lwi18cg66Yy_XY7QAOr0fBfC8oRY_2WTM_+NKu0xj08_Dw@mail.gmail.com>
In-Reply-To: <CAMm+Lwi18cg66Yy_XY7QAOr0fBfC8oRY_2WTM_+NKu0xj08_Dw@mail.gmail.com>
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: <http://mailarchive.ietf.org/arch/msg/secdir/rNau5BKoFoLpVj7NJvLtpmjTZNk>
Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" <draft-ietf-pals-seamless-vccv.all@ietf.org>, "Andrew G. Malis" <agmalis@gmail.com>, "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 21:27:48 -0000

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’s 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.
> 

https://tools.ietf.org/html/rfc7079 <https://tools.ietf.org/html/rfc7079>

(I’ve 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: “against the network” seems quite generic. You have control message exchange without RFC 5085 and without this draft.

Thanks!

— 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.
>> 
>>