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

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 26 Sep 2014 09:05:10 -0600

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 30 Sep 2014 00:10:04 +0000

Hi Hilarie,

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

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

>   EVPN network from the other Ethernet Segments.

Corrected both of them.

>advertisements.  By flashing a red light?

Something like that :-)

Thanks,
Ali