Re: [secdir] Security review of draft-ietf-l2vpn-evpn-08

"Ali Sajassi (sajassi)" <> Tue, 30 September 2014 00:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86BD91ACD5F; Mon, 29 Sep 2014 17:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mwoI4k-yaLfk; Mon, 29 Sep 2014 17:10:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC5441A874D; Mon, 29 Sep 2014 17:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3500; q=dns/txt; s=iport; t=1412035807; x=1413245407; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VynwUG2+LtSfA+D+GatIOPcEfxCMV5I/32PBoimXnHQ=; b=Lng3f9SsS4GEPPItVk2z/LXCpuJyNX5RYIv8mHOTsrtQxDVDE8qiKxa0 qnJY66kDVJrYegaTd2NpQ/Sd7WgF1v4tAfVAUuHamaRyMD0xIdcmF/Bfi cH4zZejDk9yq8lugPEpDUnhWhGgR1lkLwJPoQA3AZInAReQJEpU/DkDpY Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAKj0KVStJV2S/2dsb2JhbABggmsjgSoE0WkCgRAWAXuEBAIEbQwSAQgSZhcOAgQBDQUbiCMBvysBF5AeB4RLAQSLE4Q4ghqLQ5VdgXIYgVlsgUiBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,624,1406592000"; d="scan'208";a="359291769"
Received: from ([]) by with ESMTP; 30 Sep 2014 00:10:06 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s8U0A6nt026022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 00:10:06 GMT
Received: from ([fe80::5404:b599:9f57:834b]) by ([]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 19:10:06 -0500
From: "Ali Sajassi (sajassi)" <>
To: Hilarie Orman <>, "" <>
Thread-Topic: Security review of draft-ietf-l2vpn-evpn-08
Thread-Index: AQHP2ZzNQDm9EfijqUqR9ZEBhxAXxpwYsQCA
Date: Tue, 30 Sep 2014 00:10:04 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>
Subject: Re: [secdir] Security review of draft-ietf-l2vpn-evpn-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Sep 2014 00:10:14 -0000

Hi Hilarie,

Thanks for your review and your comments. Please refer to my reply inline

On 9/26/14, 8:05 AM, "Hilarie Orman" <> wrote:

>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
>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?

That¹s a valid question. EVPN service is very analogous to an IP-VPN
service and basically all the security consideration in [RFC4364] also
applies to this document. That¹s why instead of re-intrating the entire
security section of [RFC4364], we just stated:
"Security considerations discussed in [RFC4364]
   apply to this document for MAC learning in control-plane over the
MPLS/IP core. This section describes additional considerations."
>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.

When I wrote that sentence, what I had in mind was that besides all the
security consideration of [RFC4364], [RFC4761], and [4762], what other
requirements should be listed and after some considerations (analysis), we
identified two additional requirements that were captured in the [RFC7209]
and addressed in this draft. If there were any other requirements, then we
would have captured them in the [RFC7209].

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

Corrected both of them.

>15.2 has an "alert the operator" mechanism for dealing with double
>advertisements.  By flashing a red light?

Something like that :-)