[secdir] Security review of draft-ietf-l2vpn-evpn-08
"Hilarie Orman" <hilarie@purplestreak.com> Fri, 26 September 2014 15:15 UTC
Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968CC1A8991; Fri, 26 Sep 2014 08:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.009
X-Spam-Level:
X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_FROM_12LTRDOM=0.01] autolearn=ham
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 SFiqoXMM264m; Fri, 26 Sep 2014 08:15:54 -0700 (PDT)
Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A7D1A87B8; Fri, 26 Sep 2014 08:15:53 -0700 (PDT)
Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1XXXFQ-00065B-7f; Fri, 26 Sep 2014 09:15:52 -0600
Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1XXXFN-00039o-HD; Fri, 26 Sep 2014 09:15:52 -0600
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id s8QF5BTB010545; Fri, 26 Sep 2014 09:05:11 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id s8QF5A5g010543; Fri, 26 Sep 2014 09:05:10 -0600
Date: Fri, 26 Sep 2014 09:05:10 -0600
Message-Id: <201409261505.s8QF5A5g010543@sylvester.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
To: secdir@ietf.org
X-XM-AID: U2FsdGVkX19dGeaCgpV8n3WE7dghVvT+
X-SA-Exim-Connect-IP: 72.250.219.84
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: *;secdir@ietf.org
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/zzysjXWGaMaGuyu_sYKQXeFW42I
Cc: draft-ietf-l2vpn-evpn@tools.ietf.org, iesg@ietf.org
Subject: [secdir] Security review of draft-ietf-l2vpn-evpn-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: Fri, 26 Sep 2014 15:15:55 -0000
Security review of BGP MPLS Based Ethernet VPN, draft-ietf-l2vpn-evpn-08 Do not be alarmed. 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. BGP MPLS based Ethernet VPN = EVPN. "An EVPN instance comprises CEs that are connected to PEs that form the edge of the MPLS infrastructure. A CE may be a host, a router or a switch. The PEs provide virtual Layer 2 bridged connectivity between the CEs. There may be multiple EVPN instances in the provider's network." There are a lot of security considerations because BGP has no security architecture, and one can only hope that the "valid interfaces" can be identified and that the assumption of "trusted nodes/links" is justified. I can see that the draft authors actually have given a lot of thought to consistency, if not security, but the list of do's and dont's adds up to something less than a compelling argument for trustworthiness. What I would question as a customer requesting EVPN is what, if any, security assurances there are for EVPN. Should all traffic on a EVPN be encrypted and authenticated? What risks am I taking on? Understanding this requires mastering hundreds of pages of RFCs, and I have not undertaken the task. I will note that the requirements for EVPNs as described in RFC7209 state that "Any protocol extensions developed for the EVPN solution shall include the appropriate security analysis." Someone should do that. The final sentence of the Security Considerations has some grammatical problems. The first comma is likely superfluous. Is "be prevented" supposed to be "can be prevented"? The mechanism described in section 15.2, shows how MAC addresses can be pinned to a given Ethernet Segment, such that if they appear behind any other Ethernet Segments, the traffic for those MAC addresses be prevented from entering the EVPN network from the other Ethernet Segments. 15.2 has an "alert the operator" mechanism for dealing with double advertisements. By flashing a red light? Hilarie
- [secdir] Security review of draft-ietf-l2vpn-evpn… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-l2vpn-… Ali Sajassi (sajassi)