Re: [sidr] route leaks message to IDR

Eric Osterweil <eosterweil@verisign.com> Wed, 14 March 2012 18:38 UTC

Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAADE21F87AB for <sidr@ietfa.amsl.com>; Wed, 14 Mar 2012 11:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.497
X-Spam-Level:
X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgYt0zsB-t1F for <sidr@ietfa.amsl.com>; Wed, 14 Mar 2012 11:38:20 -0700 (PDT)
Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6ED21F8657 for <sidr@ietf.org>; Wed, 14 Mar 2012 11:38:17 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKT2DlkoHCKBKgGF1XFkaFDNETmPHElUAi@postini.com; Wed, 14 Mar 2012 11:38:20 PDT
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2EIc6HN003418; Wed, 14 Mar 2012 14:38:06 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.34]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 14:38:06 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD465693779173BA12C3E@PRVPEXVS03.corp.twcable.com>
Date: Wed, 14 Mar 2012 19:38:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <DCC302FAA9FE5F4BBA4DCAD465693779173BA12C3E@PRVPEXVS03.corp.twcable.com>
To: "George, Wes" <wesley.george@twcable.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 14 Mar 2012 18:38:06.0428 (UTC) FILETIME=[98C3C9C0:01CD0211]
Cc: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] route leaks message to IDR
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2012 18:38:21 -0000

I'd also like to add that (if I'm not mistaken) much of the BGPSEC work is _already_ proposing to "add information to BGP updates."  For example, I'm pretty sure there aren't any signatures in BGP right now, right?  I don't think this text is completely on the level, because my recollection of many of the sidr drafts is that they _ARE_ proposing to add data, semantics, and processes to the current operation of BGP.  By my reading of the text below, it sounds like we would only add these things if we were going to add route leak protection, and that sentiment seems wrong to me.  Moreover, the text below conflates the need for leak protection with some as-yet-unspecified approach that must use inline protocol changes.  I don't know that this has been openly agreed to by all (which is fine at this stage), but in reaching out to grow w/ this as a starting point I think we present both a problem and an unratified straw-man.  I think the text needs to be clarified.  

Also, I'd like to request in the 5th para (or the 6th sentence?):
	s/The consensus in the room was/The consensus in the room (though it is not clear what portion of the wg agrees) was/

Thanks,

Eric

On Mar 14, 2012, at 5:49 PM, George, Wes wrote:

> I'm basically fine with the wording below. The only thing I might add would be some mention of the reason why we're talking about route leaks, why they're considered a problem that should be solved in the context of SIDR, etc - mainly that there are those among the WG and operator community that believe BGPSec as currently proposed is incomplete without a method to prevent route leaks, and given the costs to deploy and manage BGPSec, the inability to protect against this problem limits its attractiveness for deployment.
> 
> This is covered in detail in the referenced drafts, but is worth including in the summary text.
> 
> Thanks,
> 
> Wes
> 
> 
>> -----Original Message-----
>> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
>> Murphy, Sandra
>> Sent: Tuesday, March 13, 2012 10:23 AM
>> To: sidr@ietf.org
>> Subject: [sidr] route leaks message to IDR
>> 
>> In the interim meeting, the consensus was that we needed idr to be involved in
>> any definition and solution for route leaks.  It was decided to discuss a
>> message to the idr wg on the sidr list.
>> 
>> Brian Dickson has submitted drafts about route leaks, as he offered in the
>> meeting.
>> 
>> So here is a first draft at a messate to idr.  Comments please.
>> 
>> ==============
>> 
>> The sidr interim meeting in February discussed the problem of route leaks.
>> 
>> While those in the room could recognize route leaks in a diagram, they could
>> not determine a way to determine that from information communicated in BGP.
>> 
>> Proposals to stop route leaks add information to BGP updates that would be
>> used to restrict the propagation of those updates by the neighbor onward to
>> providers, customers, peers, etc.
>> 
>> This is a change to BGP behavior, which now relies on local configuration only
>> to choose a best path and advertise it.  Adding features to stop route leaks
>> would restrict that advertisement and restrict what local policy could choose.
>> 
>> The consensus in the room was that adding a new feature to a protocol as part
>> of a security protection  (i.e., not just ensuring an already defined behavior
>> but producing brand new behavior) is unwise and leads to problems.
>> 
>> The sidr working group requests that idr discuss the route leaks problem with
>> sidr and determine the best path forward.
>> 
>> The idr wg should also be aware that drafts have been submitted about route
>> leaks, so work is underway.
>> 
>> http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01
>> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01
>> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02
>> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01
>> 
>> ===================
>> 
>> --Sandy
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr