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

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Hilarie,

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

On 9/26/14, 8:05 AM, "Hilarie Orman" <[e-mail]> 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