Document: draft-ietf-bess-evpn-ipvpn-interworking Title: EVPN Interworking with IPVPN Reviewer: Renzo Navas Review result: Has Nits
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 is about BGP and Ethernet Virtual Private Network (EVPN) used as BGP control plane. BGP Tenant networks can span multiple BGP domains (e.g., EVPN, IPVPN, IP), and the goal of this document is to provide the mechanisms to achieve end-to-end tenant connectivity independently of those heterogeneous domains. The document also introduces a new BGP Path Attribute (Domain PATH) to support control loop prevention. Disclaimer: I am no BGP expert, and not acquainted with the EVPN/IPVPN BGP technologies. I did my best to read all the Security Considerations of all the referenced RFCs within this document (and ramifications like updated by other RFCs). My current detail of understanding does not allow me to identify potential overseen new security risks. However, I can give you suggestions to relevant security considerations on referenced RFCs that should be present maybe on this one (reference them in the Security Considerations section), ## Suggestions for Security Considerations Section These two RFC’s Security Consideration Sections I would recommend to cite : 1. RFC 9252 BGP Overlay Services Based on Segment Routing over IPv6 (SRv6): high level recommendations that apply to our use case. 2. RFC 4272 BGP Security Vulnerabilities Analysis : some fundamentals. On top of that, more optional suggestions to reference at least the reader to their Security Consideration Sections (from older RFC to newest): RFC4364 (BGP/MPLS IP Virtual Private Networks (VPNs)) Very Insightful to our setting, this one is already included in our sec. cons section! However, continuing its line of thought it states that "The use of cryptography on a PE-PE basis is for further study." Does this concern us? RFC4364 references RFC2385 (MD5 TCP Auth.) which is (of course...) obsoleted by RFC5925 TCP Authentication Option TCP-AO (RFC4271, Base BGP v4 itself, also suggests similar). In RFC6952, we will find some old (but not deprecated) recommendations for key distribution/crypto-agility for routing protocols including BGP. TO be honest, I would not know which are the best practices to end-to-end cryptography in this setting as of 18th of December 2025, there is something to reference? RC7606 (Revised Error Handling for BGP UPDATE Messages) , updates messages, an important vector of attack of the procedures (including ours). Will be relevant to reference its Sec. Considerations section? One of the recommendations: "to avoid such issues is to prefer use of Authenticated Encryption with Additional Data (AEAD) ciphers" (even in our setting, malicious actors can come into play, if not our document should state that is not possible---and why). RFC7432 (BGP MPLS-Based Ethernet VPN) sec. suggestions/considerations apply to the intra-subnet forwarding or communication ; also references the state of the art of BGP security considerations at the time of that writing (good!). (RFC8365 (A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)). Mildly relevant, generic) RFC9012 (The BGP Tunnel Encapsulation Attribute), referenced in Section 10, suggests that when crossing some boundaries "there exists a risk of misdelivery of traffic. If the traffic contains confidential data that's not otherwise protected (for example, by end-to-end encryption), then confidential information could be revealed.". Again the topic of end-to-end encryption. For the authors: I would not know the best way to integrate these suggestions, if you consider some of those sections are relevant just mentioning the RFC would be enough so the reader can go and see for itself. ## Nits (mostly acronyms definitions, really, but may impact references) Section 1 IP-VRF: Maybe on first mention of IP-VRF define the acronym (IP Virtual Routing and Forwarding ?) and reference [RFC4364] or other ? Section 3 MP-BGP Sub-Address --> Define acronym MP-BGP (is never defined in this document) and reference rfc4760 ? MPLS: I assume is a very well known acronym in the community but MPLS (Multiprotocol Label Switching) is not defined anywhere , maybe reference RFC8277 (not included currently) or other already included relevant reference ? Figure 4: RR acronym (route-reflector / route reflector ? you use both ) define it when you describe the Example or at first use (just paragraph before) (RFC4456 ?). IBGP/EBGP not defined. RFC4271, Base BGP... but shall we expand acronyms? Section 5.2 Item 4, end of first paragraph "SHOULD NOT be propagated::" two colons, should be one. A quick search revealed two colons also in the third bullet point of Section 10. "Include::". THE END _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
