Last Call Review of draft-ietf-l2vpn-evpn-08
review-ietf-l2vpn-evpn-08-secdir-lc-orman-2014-10-02-00

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