Last Call Review of draft-ietf-bess-mvpn-expl-track-11
review-ietf-bess-mvpn-expl-track-11-secdir-lc-huitema-2018-10-05-00

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.