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]
