Subject: [secdir] Secdir review of draft-ietf-bess-mvpn-global-table-mcast-02

From: Catherine Meadows <[email-masked]>
Date: Wed, 12 Aug 2015 18:19:50 -0400

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: [email-masked]

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 19 Aug 2015 13:18:54 -0400

Thank you for your review.

I have fixed the nits you've pointed out.

With regard to your substantive comments about the Security 
Considerations section, here is my perspective.  The VPN and MVPN 
procedures that have been developed and deployed over the past couple of 
decades do pretty well at constraining the distribution of routes, such 
that a given route stays within its own VPN (unless the service provider 
has explicitly configured a policy allowing the route to be further 
distributed as part of an "extranet").  But GTM makes use of routes that 
are in the "global" Internet routing tables, rather than routes that are 
in a VPN-specific routing table (VRF).  It also creates multicast flow 
state that is "global", rather than being associated with a particular 
VPN.  Some of the infrastructure that constrains the distribution of 
routes just is not present when one is manipulating global tables rather 
than VRFs.  It seemed worthwhile to point this out in the Security 
Considerations section, rather than just saying something like "the 
security considerations are the same as for MVPN".

However, I do not think it is necessary to create a number of 
hypothetical scenarios, describe them in detail, and then say "don't do 
this".  So I don't think it is necessary to add any material to the 
Security Considerations section.

Following are some more specific responses.

[From the draft] 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.

[Cathy] 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?

When L3VPN/MVPN is provisioned, each VRF is configured with import RTs 
and export RTs.  These RTs constrain the distribution and the import of 
L3VPN/MVPN routes, making it difficult to cause a route to be 
distributed to and imported by a VRF (or a global table) that is not 
authorized to import that route.  Additionally, VPN routes do not go 
into the "global table" with the "ordinary Internet routes" (i.e., 
non-VPN routes), and non-VPN routes do not impact the flow of multicast 
data within a VPN.

In GTM, some of these protections against improper distribution/import 
of the routes is lost.  Import of the routes is not restricted to VRFs, 
and the RT infrastructure that controls the distribution of routes among 
the VRFs is not present when routes are exported from and imported into 
global tables.  But I don't think this needs to be explained in detail 
to the intended audience of the draft, who will already be familiar with 
VPN and MVPN technology.

[Cathy] 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.

When using VPN procedures without the RT infrastructure that controls 
the distribution of VPN routes, one has to give a bit of extra thought 
to the way the distribution of the routes is controlled.

[From the draft] 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.

[Cathy] 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?

Routes affecting GTM may be carried on BGP sessions that typically do 
not carry VPN routes.  Generally service providers know which attributes 
are important for VPN, and do not mess with those attributes on BGP 
sessions that carry VPN routes.  With GTM, some of those attributes are 
carried on BGP sessions that do not carry VPN routes.  Thus it seemed 
worthwhile to give a caution about it.  Again, I don't think this is 
something that needs to be explained to the intended audience of the draft.

[From the draft] 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.

[Cathy] 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?

In MVPN, the group addresses are assigned by the customer of the service 
provider.  The procedures constraining route distribution prevent a 
route containing a given group address from being distributed outside 
that customer's VPN.  If the address is not unique within the VPN, 
that's not the sevice provider's fault.  In GTM, however, the 
distribution of the group addresses is not constrained by VPN 
boundaries, so it is the service provider's responsibility to understand 
the group address scope and to ensure that there are no conflicts in the 
way that a group address is used.  This is a classic problem in 
multicast, and it is not within the scope of this document to address 
that problem.  But again, it seemed worthwhile to point out that some of 
the protections that are built into MVPN are lacking when GTM is used.