Last Call Review of draft-ietf-l2vpn-evpn-req-05
review-ietf-l2vpn-evpn-req-05-secdir-lc-tsou-2013-11-28-00

Dear all,
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.

This document specify the requirement for an Ethernet VPN (EVPN) solution, to
address the issues mentioned in this draft.

Some comments are below.

1. In Section 4.2, it says:
 "The solution MUST also be able to leverage
 work in the MPLS WG that is in progress to improve the load balancing
 capabilities of the network based on entropy labels [RFC6790]."

 Since this work is already published as RFC, the sentence should be rewritten
 as: "The solution MUST also be able to leverage the MPLS load balancing
 capabilities based on entropy labels [RFC6790]."

2. In Section 4.2, it says:
 "For example consider a scenario in which CE1 is multi-homed to PE1
 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active
 mode. Furthermore, consider that there exist three ECMPs between any
 of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can
 be forwarded on twelve different paths over MPLS/IP core as follow:
 CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and
 PE2 have three ECMPs to PE3 and PE4 for the total of twelve paths.
 Finally, when traffic arrives at PE3 and PE4, it gets forwarded to
 CE2 over the Ethernet channel (aka link bundle)."

 It seems "ECMP", "ECMP path" and "path" are messed up in this paragraph. To
 make it straight, the following is suggested: "For example consider a scenario
 in which CE1 is multi-homed to PE1 and PE2, and CE2 is multi-homed to PE3 and
 PE4 running in all-active mode. Furthermore, consider that there exist three
 ECMP paths between any of the CE1's and CE2's multi-homed PEs. Traffic from
 CE1 to CE2 can be forwarded on twelve different paths over MPLS/IP core as
 follow: CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and PE2
 have three paths to PE3 and PE4 for the total of twelve paths. Finally, when
 traffic arrives at PE3 and PE4, it gets forwarded to CE2 over the Ethernet
 channel (aka link bundle)."

3. In Section 12 "Security Considerations", it says:
 "...The requirement is to introduce no
 new vulnerabilities beyond those of [RFC4761] and [RFC4762] when MAC
 learning is performed in data-plane and beyond that of [RFC4364] when
 MAC learning is performed in control plane."

Though BGP is used similarly in E-VPN, some new vulnerabilities will inevitably
be introduced, such as MAC forgery in BGP, and how to protect against
individual MACs may pose a challenge.

4.  Section 12 "Security Considerations"
It is very brief. It does not mention when using multi-homing.

Thank you,
Tina