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.
- [secdir] Secdir review of draft-ietf-bess-mvpn-gl… Catherine Meadows
- Re: [secdir] Secdir review of draft-ietf-bess-mvp… Eric C Rosen