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 …”