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

Catherine Meadows <catherine.meadows@nrl.navy.mil> Wed, 12 August 2015 22:19 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE51ACE8A; Wed, 12 Aug 2015 15:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmRikANGkOLQ; Wed, 12 Aug 2015 15:19:53 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724841ACE68; Wed, 12 Aug 2015 15:19:52 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t7CMJolF017023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2015 18:19:51 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9E48C52-B313-4BFD-8174-5A14DE4FB106"
Date: Wed, 12 Aug 2015 18:19:50 -0400
Message-Id: <BD4CE8DD-EFF5-43DF-BD3A-714FD8865627@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/zgPr-bUWyGLsAFvDNP3u8Y8pGgo>
Cc: draft-ietf-bess-mvpn-global-table-mcast.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-bess-mvpn-global-table-mcast-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2015 22:19:56 -0000


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@nrl.navy.mil