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

Request Review of draft-ietf-l2vpn-evpn-req
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-11-27
Requested 2013-10-31
Authors Wim Henderickx, Jim Uttaro, Ali Sajassi, Rahul Aggarwal, Nabil Bitar, Aldrin Isaac
Draft last updated 2013-11-28
Completed reviews Genart Last Call review of -05 by Vijay Gurbani (diff)
Genart Telechat review of -06 by Vijay Gurbani (diff)
Secdir Last Call review of -05 by Tina Tsou (diff)
Assignment Reviewer Tina Tsou
State Completed
Review review-ietf-l2vpn-evpn-req-05-secdir-lc-tsou-2013-11-28
Reviewed rev. 05 (document currently at 07)
Review result Has Nits
Review completed: 2013-11-28

Review
review-ietf-l2vpn-evpn-req-05-secdir-lc-tsou-2013-11-28

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