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

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

From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Hilarie Orman <hilarie@purplestreak.com>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Security review of draft-ietf-l2vpn-evpn-08
Thread-Index: AQHP2ZzNQDm9EfijqUqR9ZEBhxAXxpwYsQCA
Date: Tue, 30 Sep 2014 00:10:04 +0000
Message-ID: <D04F3EEA.F0C75%sajassi@cisco.com>
In-Reply-To: <201409261505.s8QF5A5g010543@sylvester.rhmr.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.8.130913
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C7AC571B0C8C414E8963F200FDA46459@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_E_0CkqNu9JFOIP40NAf-ur3Wg0
Cc: "draft-ietf-l2vpn-evpn@tools.ietf.org" <draft-ietf-l2vpn-evpn@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] Security review of draft-ietf-l2vpn-evpn-08
Precedence: list

Hi Hilarie,

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

On 9/26/14, 8:05 AM, "Hilarie Orman" <hilarie@purplestreak.com> 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
>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?

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 :-)

Thanks,
Ali

>
>Hilarie

[secdir] Security review of draft-ietf-l2vpn-evpn… Hilarie Orman
Re: [secdir] Security review of draft-ietf-l2vpn-… Ali Sajassi (sajassi)