Skip to main content

Last Call Review of draft-ietf-l2vpn-evpn-08

Request Review of draft-ietf-l2vpn-evpn
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-09-29
Requested 2014-09-18
Authors John Drake , Wim Henderickx , Ali Sajassi , Rahul Aggarwal , Dr. Nabil N. Bitar , Aldrin Isaac , Jim Uttaro
I-D last updated 2014-10-02
Completed reviews Genart Telechat review of -10 by Martin Thomson (diff)
Secdir Last Call review of -08 by Hilarie Orman (diff)
Opsdir Last Call review of -08 by Dan Romascanu (diff)
Assignment Reviewer Hilarie Orman
State Completed
Review review-ietf-l2vpn-evpn-08-secdir-lc-orman-2014-10-02
Reviewed revision 08 (document currently at 11)
Result Has Issues
Completed 2014-10-02
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?

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?