Hi Hilarie, Thank you for the review. In response to your comment, we expanded Section 15 in revision 12 (draft-ietf-bess-evpn-mvpn-seamless-interop-12) to analyze the security risks associated with the EVPN/MVPN interworking procedures and describe the corresponding mitigations. We also reviewed the cited Hares GenART review. The revised section addresses the security concerns from that review that are directly applicable to this document.
In response to your question about recursively extracting Security Considerations from the reference tree, we summarized the applicability of the referenced documents and analyzed the additional security implications of the interworking procedures defined in this document. The revised section addresses: * the fact that this document defines no new cryptographic mechanism; * forged or mis-scoped EVPN, VPN-IP, and MCAST-VPN routing information; * incorrect or inconsistent Route Targets, VRF Route Import Extended Communities, PMSI Tunnel Attributes, next hops, tunnel endpoints, labels, VNIs, and capability flags; * traffic duplication/loop and blackholing; * risks arising from malicious or misconfigured SEMGs and interconnection gateways; * control-plane state exhaustion and traffic impact; * authorization of BGP peers and tunnel endpoints, routing policy, tenant-mapping validation, state and rate limits, monitoring, and data-plane validation; and * the lack of payload confidentiality and the need for an appropriate encryption mechanism when confidentiality is required. Please let us know, if there any other comments/suggestion. Best Regards, The authors. From: Hilarie Orman via Datatracker <[email protected]> Date: Tuesday, July 21, 2026 at 9:14 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: draft-ietf-bess-evpn-mvpn-seamless-interop-11 early Secdir review Document: draft-ietf-bess-evpn-mvpn-seamless-interop Title: Seamless Multicast Interoperability between EVPN and MVPN PEs Reviewer: Hilarie Orman Review result: Has Issues Do not be alarmed. I generated this review of 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. The abstract of the draft says that it presents a method for seamless interoperability of Multicast VPN between Ethernet VPNs and Multicast VPNs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN provider edges. VPNs and multicast are the subject of a long history of IETF drafts, and anyone building a system as described in this draft would have to be familiar with those drafts in order to understand the architecture. Presumably they would also be familiar with all the security considerations as well. The security considerations for the draft in question are limited to referring the reader to the security considerations in prior RFCs: RFC7432, RFC6513, RFC6514 and RFC9251. The last of these itself references RFC7432 which in turn references RFC6513 and RFC6514. RFC7432 also has a discussion of the importance of protecting the control plane and the rationale for using BGP. It also recommends RFC6952 Keying, Authentication, etc and RFC4761 "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling". RFC6513 recommends MPLS-IP, RFC4797, MPLS-HDR, PIM-SM, BGP [MVPN-BGP], mLDP [MLDP],RSVP-TE [RSVP-P2MP] and MVPN-BGP. It also has guidance about specific scenarios requiring caution. This barely touches the surface of security considerations in the underlying architectures. Is there an IETF tool for extracting all the security considerations from the tree of references? It might be helpful. Is it necessary in this case? It's hard to say, and the security considerations shed no light on it. The usual reason for basing a security review solely on mention of a few prior RFCs is that the RFC under review relies on security mechanisms of the prior RFCs and does not add new uses or change them. If that is true of this evpn-mvpn draft, then the authors should state that rationale. I see reason to think that there are interactions in this protocol that might raise security issues, particularly in this GENART review: https://datatracker.ietf.org/doc/review-ietf-bess-evpn-mvpn-seamless-interop-06-genart-early-hares-2024-01-09/ Until there is a non-trivial security considerations section for review, the document appears deficient. Hilarie
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
