Last Call Review of draft-ietf-bess-mvpn-expl-track-11

Request Review of draft-ietf-bess-mvpn-expl-track
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-09
Requested 2018-09-25
Authors Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang
Draft last updated 2018-10-05
Completed reviews Rtgdir Last Call review of -09 by Carlos Pignataro (diff)
Secdir Last Call review of -11 by Christian Huitema (diff)
Genart Last Call review of -10 by Brian Carpenter (diff)
Genart Telechat review of -12 by Brian Carpenter (diff)
Assignment Reviewer Christian Huitema 
State Completed
Review review-ietf-bess-mvpn-expl-track-11-secdir-lc-huitema-2018-10-05
Reviewed rev. 11 (document currently at 13)
Review result Has Nits
Review completed: 2018-10-05


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.