Reviewer: Christian Huitema 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. I have reviewed version 11 of draft-ietf-bess-mvpn-expl-track. From a security point of view this draft is almost ready, except for the small issue that no mitigation is proposed for the one vulnerability discussed in the security section. Multicast VPN (MVPN) operates by setting a routing tree between the ingress site and the egress sites. In MVPN, that tree is built by the network provider, and includes multicast nodes inside the network as well as the customer facing "provider edge" routers. Ingress nodes do not necessarily know how many egress nodes have joined the multicast tree at a given time. The purpose of Explicit Tracking is to provide that information. Explicit tracking procedures are defined by RFC 6513, RFC 6514, and RFC 6625. They rely on MVPN tunnel attributes to trigger the setup of Selective Provider Multicast Service Interface Auto-Discovery routes. The current draft complements these procedures to cover a number of cases not yet covered, in particular when the multicast groups for which information is desired are indentified by wild cards instead of the full combination of source and group identifiers. This is done by defining an additional flag (LIR-pF) in the tunnel attributes. The security considerations list only one issue: that abuse of wild card definitions in large networks could trigger a large amount of explicit tracking traffic, which might affect the performance of the control plane. Otherwise, this draft does not change the security properties of MVPN discussed in RFC 6513 and RFC 6514. That seems fair, but the draft then says that studying mitigations for the potential abuse is out of scope, which leaves me a bit puzzled. I can think of a variety of techniques to either spread the explicit tracking traffic over time, rate limit it, or aggregate it in intermediate nodes. Some of those techniques could probably be proposed as a basic mitigation.
