[secdir] SECDIR review of draft-ietf- bess-evpn-usage-07

[Stephen Kent <[e-mail]>]

SECDIR review of draft-ietf- bess-evpn-usage-07

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 with the intent of improving security 
requirements and considerations in IETF drafts.Comments not addressed in 
last call may be included in AD reviews during the IESG review.Document 
editors and WG chairs should treat these comments just like any other 
last call comments.

This document describes the applicability of an Ethernet VPN (EVPN) 
enabled via BGP MPLS, in what the authors say is a “fairly common 
deployment scenario.” It intended status is INFORMATIONAL. The document 
complements RFC 7432, which already defines BGP MPLS-based EVPN technology.

Section 2 (Terminology)

The acronym PE (provider edge?) is used here, but not defined.

Section 3

This section describes the common deployment scenario that is the focus 
of this document. The scenario involves three customer sites; one 
requires multi-homing to two provider access points, while the other two 
sites are single-homed. The goal is to make all three sites appear to be 
on the same Ethernet.

Section 3.2 describes rationale (motivation) for using this technology 
(vs. VPLS) to satisfy the service and redundancy requirements. That’s 
not exactly an “applicability” discussion, but …

Section 4 describes the provisioning model for the chosen deployment 
scenario. Section 5 describes what route update processing capabilities 
are needs by the provider equipment, in support of this deployment 
scenario. Section 6 is rather long; it describes the EVPN initialization 
procedures in detail for MAC-based forwarding. Section 7 provides a 
similar description for MPLS-based forwarding. Section 8 compares the 
two approaches and Section 9 discuss traffic flow optimization (to avoid 
flooding traffic to all sites when such flooding is not needed).

Section 10 (Security Considerations) consists of only one sentence, 
which refers to the corresponding discussion in RFC 7432. Additional 
text should be provided here to explain why this document does not add 
any new security considerations. Presumably the rationale is that the 
provisioning model and initialization procedures described here are a 
subset of the more general discussion in 7432 and thus no new security 
concerns arise as a result of this more detailed information. I am not 
in a position to judge whether that potential rationale is true.

I reviewed the Security Considerations section of RFC 7432. It contains 
about 1.5 pages of text. The first paragraph there cites security 
considerations text in RFCs 4761, 4762, and 4364 and the text there is 
generally well-written. However, there is a significant omission, one 
that should have been noted in the SECDIR review of that document. 
Specifically, 7432 cites NONE of the BGP security RFCs produced by the 
SIDR WG (e.g., RFCs 6480-93 et al), even though they preceded 
publication of that RFC. Since those documents represented the latest 
proposals for improving BGP security at the time, they ought to have 
been cited and a very brief discussion of their relevance to EVPN BGP 
MPLS deployments. I suggest that this document rectify this omission, 
i.e., cite several of the BGP secure origin authentication RFCs, and the 
recent BGPSec RFCs (8205-11), and note the relevance of those standards 
to EVPN BGP MPLS deployments.




Comments on Grammar/Typos

There are a several places in the text where sentences are 
un-grammatical. For example:

“… irrespectively of the number of affected services… “

->

“…irrespective of the number of affected services …”

“ … we can use ingress replication for on EVI100 …”

->

“…we can use ingress replication for EVI100 and …”

“In regards to service interfaces …”

->

“With regard to service interfaces …”

“…(and even suppress) the ARP-flooding.”

->

“…(and even suppress) ARP-flooding.”

“…certain parameters which are not service-specific…”

->

“certain parameters that are not service-specific..”

“In our use-case, besides the above parameters, the same LACP

parameters will be configured in PE1 and PE2 for the ESI, so that CE2

can send different flows to PE1 and PE2 for the same CE-VID as though

they were forming a single system from the CE2 perspective.”

Sentence too long

“E.g.: PE1 and PE2 CE-VID binding …”

->

“For example, PE1 and PE2 CE-VID binding …”

“PE3 is only required to export MAC …”

->

“PE3 is required to export only MAC …”