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.

This ID describes adapts Multicast Virtual Private Network (MVPN) procedures and protocols described in

RFC’s 6513, 6514 to non-VPN specific multicast, referred to as Global Table Multicast (GTM)  in this document.

MVPN is typically used by a service provider that provides VPN service to its customers.  In this architecture

one or more customer routers attach to a single Provider Edge (PE) router, that may support one or more

VPNs.  Each PE contains a separate Virtual Routing and Forwarding Table (VRF) for each VPN to which it is attached.

The main difference between MVPN and the new GTM procedures described in this document is that in GTM the routing

information is stored in a global table.  The document describes changes in procedures that need to be made when using

a GTM instead of an MVPN.

I have some issues with the Security Considerations section of this documents.  It describes security issues

that the authors have identified, but it is hard to figure out exactly what features of the proposed GTM procedure give rise to them and what

can be done to address them.  

In particular:

This document makes use of a BGP SAFI (MCAST-VPN routes) that was
   originally designed for use in VPN contexts only.  It also makes use
   of various BGP path attributes and extended communities (VRF Route
   Import Extended Community, Source AS Extended Community, Route Target
   Extended Community) that were originally intended for use in VPN
   contexts.  If these routes and/or attributes leak out into "the
   wild", multicast data flows may be distributed in an unintended and/
   or unauthorized manner.

What is not clear here is what is additional risk of information leaking out into the wild  the use of the GTM procedures proposed

in this document would incur.  Does the use in a wider context mean that the information is more widely distributed and thus has

more chance of leaking?  Or does it mean that an incorrectly implemented GTM procedure might confuse sensitive routes with nonsensitive ones,

and distribute them inappropriately?  Or both?  A sample scenario would be useful here.    It would also be helpful to see suggestions for mitigation.

Internet providers often make extensive use of BGP communities (ie,
   adding, deleting, modifying communities throughout a network).  As
   such, care should be taken to avoid deleting or modifying the VRF
   Route Import Extended Community and Source AS Extended Community.
   Incorrect manipulation of these ECs may result in multicast streams
   being lost or misrouted.

I’m not sure how this is related to the document.  Could you show how this becomes more of a risk as a result of using the new GTM procedures?

The procedures of this document require certain BGP routes to carry
   IP multicast group addresses.  Generally such group addresses are
   only valid within a certain scope.  If a BGP route containing a group
   address is distributed outside the boundaries where the group address
   is meaningful, unauthorized distribution of multicast data flows may
   occur.

Is this a new requirement or is this one that is incurred by other types of procedures as well?  Again, can you suggest any mitigations?

Also a few nits:

First line, second paragraph of Security Considerations Section Section:

This document makes use of a BGP SAFI (MCAST-VPN routes) that was
   originally designed for use in VPN contexts only.

I assume you mean to say:  “The protocols and procedures described in this document make use …”

First line, second paragraph, Section 2.3.4

The SFS procedure works in VPN context as along the following
   assumption holds

That should be “as long as”, not “as along”.

I consider this ready with issues, in that the Security Considerations section needs to give a much clearer

account of the security risks that may be incurred, and mitigations need to be suggested whenever possible.

Cathy Meadows

 




Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email: 

catherine.meadows at nrl.navy.mil