Re: [sidr] route leaks message to IDR

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Tue, 13 March 2012 14:39 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 2BD5D21F88C5 for <sidr@ietfa.amsl.com>; Tue, 13 Mar 2012 07:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 VBtORfzqYS18 for <sidr@ietfa.amsl.com>; Tue, 13 Mar 2012 07:39:38 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 273B521F8857 for <sidr@ietf.org>; Tue, 13 Mar 2012 07:39:38 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Mar 2012 10:39:33 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 13 Mar 2012 10:39:37 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <sidr@ietf.org>
Date: Tue, 13 Mar 2012 10:39:36 -0400
Thread-Topic: route leaks message to IDR
Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IAABwudQ
Message-ID: <D7A0423E5E193F40BE6E94126930C4930B94FEA3B1@MBCLUSTER.xchange.nist.gov>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
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: Tue, 13 Mar 2012 14:39:39 -0000

I think your message reads good.

Should Brian be encouraged to present his route-leak drafts in the IDR WG meeting?
Do we know if he is he planning to?

Sriram


>-----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