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

Eric C Rosen <erosen@juniper.net> Wed, 19 August 2015 17:19 UTC

Return-Path: <erosen@juniper.net>
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 87FDE1A21C7; Wed, 19 Aug 2015 10:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 45k-igBkIGJt; Wed, 19 Aug 2015 10:19:02 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBF71A1B23; Wed, 19 Aug 2015 10:19:02 -0700 (PDT)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net;
Received: from [172.29.37.3] (66.129.241.11) by BY1PR0501MB1093.namprd05.prod.outlook.com (10.160.103.139) with Microsoft SMTP Server (TLS) id 15.1.231.21; Wed, 19 Aug 2015 17:19:01 +0000
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>, secdir@ietf.org, iesg@ietf.org
References: <BD4CE8DD-EFF5-43DF-BD3A-714FD8865627@nrl.navy.mil>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <55D4BA7E.4080405@juniper.net>
Date: Wed, 19 Aug 2015 13:18:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <BD4CE8DD-EFF5-43DF-BD3A-714FD8865627@nrl.navy.mil>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.11]
X-ClientProxiedBy: BY1PR14CA0028.namprd14.prod.outlook.com (25.161.91.38) To BY1PR0501MB1093.namprd05.prod.outlook.com (25.160.103.139)
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 2:gdnAXDC1o0CcgPxJ6Kdr6iTRote67qozhkH6GkCxdVhnRs0sFpdfjb1hBhHhW/bVU0JV8SGrk36d6wmG0c7JYjCXZ9oG9qQS/YR+wXueqJA9lFezfyFf3yE9Hyn0qtrn5OKMe9RP8WCXk0sNeyrFcoQF/b0IEtuxqr+d+MCvjFo=; 3:PXKmuKWxIU/290xb+ow3fDhHfSEPp4EDeBCQWHnIXAo9QbJ0EOIiaZrz0QhVzkc5UtZ99ZByvJwatrlKeKzq5DlAmlqIxp9cs6YrsC1FNQQ5c5h38s0RPfhWjtp6UnI4BSXcOJo6pT01bq8WJUkrjg==; 25:uTQ6UDJiVlITnhq5CErqUwCcsqqPWTdlsC7iIQlZ957Dd+fGzTMdSTtyF5SpdCmLJQrfwK/IO1O5aOWGuEalvwGQ2b6lTO6f+sc9vSdmZ1LEJAbFvCCC6+6Ivix2zUUZXwUacHQAlF8bFWzlTb76k9YfDbhF2ucu4gwuwfmiPegdR7+kkYIvinEZ0gKRBbLu2eMhgOQTEv+gkpSof6ZxHkxJAgVqV9RFmGh5lt5+oJ9Q042Ae0M3Ui3cRkhAkDxqIIUSt9mKAZnHatbPvLAAAA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1093;
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 20:dbSAvcVGG2Um+xy91lthvMN1/jltnscmcq0yaOUUPKyo2vt4VGMEHd8wegMyrhLvfYmBiMUdpi1JcjRvDYTH35szwBnqdzLRtg7Pl7N7rSMRZioCAnMslMKIxxpJD2BOp3fJrN7Q+U9xxdZdjZeGeSDUz61cVT400jrgc9XCNW8TrvtwLHBlK4nF+TftaOEsFxK/iTfKnx3Syd43zvXm3y53M/yFg3Zn341E/ZpLZDAkgLwL1lnYWbEWbm6XHSjvVN5AaLgnd04xjNJY3+7bQMiHDBeYPFRtq/mvfPYTOZLAMvco28jMDT8yEczUvb8sXe2jqMft/gJptrcyhKli9EzjLz3pk5OSI7k7J0sTwGPMNcMtSPTfRnHIwj1pNWKuTQFKPdr2+CxC9Lpd150SelgGam5Oa7b9ZTRt3anl1XU/mzd2fUPhGgFK9uiORf4ZkmEfB44zkaJvJYOeOGCWEMdU1WaWGhNmdXryUXglP6okd7kZ11qy7erbvnSotMlI; 4:7l/0myJ2s1oyHL8D6/yDH2+3nudu/nGmm2I1f7ZB7YMHMEUsYEgXMaYLnSmYhWXOKhpEwDTYq/LTuJ6EU4ykGW7pwPW+kOmLp1Xsjxi6etNgSS79xCY4IJw7gK9xIUogEiCs0qvpyTFHfHLBjJjESKdIzYzAv03GF3cwRbxb1FGmv6DioUzcmdCxIegJA/NK/3BagnKlpWbl95dZ7NL7cXzJlla9//me48ovkKCOlFX1iuXabzLfhRqNv6wOux79P3+nEhmXvSdXfsXEOr4VVSRh9hfOZWeOLi3FYFWuSduEwC3gDLezHYj39K3aqvRR
X-Microsoft-Antispam-PRVS: <BY1PR0501MB109313515ED81380D4A76635D4670@BY1PR0501MB1093.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BY1PR0501MB1093; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1093;
X-Forefront-PRVS: 0673F5BE31
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(189002)(66066001)(47776003)(65956001)(230783001)(106356001)(59896002)(101416001)(77156002)(105586002)(64706001)(65806001)(87266999)(76176999)(65816999)(54356999)(50986999)(40100003)(77096005)(68736005)(122386002)(33656002)(64126003)(92566002)(2950100001)(23746002)(83506001)(50466002)(62966003)(80316001)(42186005)(46102003)(81156007)(4001350100001)(86362001)(87976001)(2201001)(5001960100002)(189998001)(36756003)(97736004)(5001860100001)(5001830100001)(5001770100001)(4001540100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1093; H:[172.29.37.3]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 23:FwTL9NhDpWboiXhUm4eoMGbvoz1Gf56KHirfkU5BBjk3DqWU6PSdJc20hg0kgLqqr46HO1f8b/j41tJMnI2Fs6MA/XyBB4V6ngbvl7SLbNb9byY2ujYMnabGqJ3CIlCKtsiGXAY588+UwVl+Z9dhR/rwg6NAdf5iant9b3XBgCYgx0eRoFyYb5CRLZayJZOExfOjONgWr2ACCXPhu8ZLz1jJgnVbfza8ccXNri3jK6N9K/tPOvAT9TB+V/hUulozSO3l2uNZE91kwOgUchJHGILgyBrpmghIbln1G1ZB55XpyaN7hc6deYyjh6nH+MNqn1H0GleTZkPyQGoY3bM9C0HYhM2o3lJq5z5iHBxUoc1HDLevOxbwtX/r0zi8Klji9NHNSBwYPStR60KvpGmCvdPVTqddgOCkSj26qW2f1y68sohILeLFoxE0i8JrFEyI/4CjkVofOiaVZ/bPeY/glMeGgLzS+5QVKpljiUB3Z4D2R/g8xDWEXbSIOnDylv5RI8GFDN43gT+Bvj3JHK7jEbJoRd9EQx1LgBSV2RXPcwSnlkWYoYUpR19S161i5U3IR0Z7DgUqI0CdTVO/TwE2CK8lTwcDwRbauxt/DrdenQI1KcQPz8S2uQ4lk9obSRidBKe+tEqy4BPbdqf4sRaEaU+TCc2e15WdZi4CgLYuquFe7cdxPqMB1SlUPzkXLBQ8IBL/3kFArLs3/LUHTx/r2vOMVr/wijEf7YcB810UKbItFH6ZVoSDRYVlu0ikFRak68xBxLzon96nN83fRU5QqA7JS90/XEqLfy0zWp5G+ur7afTmYu1RuN/YQvQDHY7LxBq3e4UYewO62X9iNM6b2fMdgkeqqMuAGjU4FZzBaDfQ7awd1LbV7ejJ/tA9kLgvB0AIPQiYEwk4F9EH0pqN5J0eWin9MnYlVDx4yP0jdwBTRv51fCQDe0M+rWzsrfkikXyraa8imO6vfBZmKiSulwjqDdQPM88kscQNvxdsM8goJEpLJkqhi55FQOGbcEC+v0HUd92MP6LFpKTWzR9sYFPbLuu0mDw3Qt7x1wFJOH9HgmZ2I2SCCnS28DcHc+gqooxCqrI494VwURxjCMARJmJa12puVcVH+WkHGkP2YZyXUGWzFnPfi1bB/rDgLl1J/9zVtk8c0O3/jJcb+a8IIsKRCYM9e1E6wP1bH9e6X1DzqqJvj9sC6lZw9yDadMOXr77Umz67kp4tXw6WD9v3Ws5Vqs/CnFyMoJhAK7wi2Zg=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 5:/olB/OPJ3MFJqUEgOkcZKVeCgpkr9k166Iv/ZmQbkm6EwPj+0pNrbITDhA3iZd/eWApOJ7pONYtV8z4qDq8KZ2p7OFLFDpu/qvV4RWuShznPpUKtAiOTTBvY5ny+zuBbaoIZEAZsycQ+f9xgImRC/A==; 24:w6FtGz/7aj1MvISgfQoUxQ76CEMLh5PCuEEmfPLZH4f67BjTxSxjC5c157o1C4bjiFcDT6KlTojLMQ6tJpOLpFq1Q7/UhEBZClAsG1AxNlI=; 20:22iV5L4r6Q9CigcuPen5M8CO9s1ZpYtdF4LWXhH+qCwixdvkoA2XIsDeHqdLVwcUd9Nq0Jq13/29yTdJyRbnQA==
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2015 17:19:01.3323 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1093
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/cXeuOX4nOO2kFP-1eJ7sI9pashA>
X-Mailman-Approved-At: Thu, 20 Aug 2015 08:20:20 -0700
Cc: draft-ietf-bess-mvpn-global-table-mcast.all@tools.ietf.org
Subject: Re: [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, 19 Aug 2015 17:19:04 -0000

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.