[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