Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Mon, 09 April 2012 16:15 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 0BD3021F876A; Mon, 9 Apr 2012 09:15:20 -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=[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 MCdc+QxR3wly; Mon, 9 Apr 2012 09:15:19 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id CC34A21F8659; Mon, 9 Apr 2012 09:15:18 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 12:15:15 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Apr 2012 12:15:17 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: "robert@raszuk.net" <robert@raszuk.net>, "sidr@ietf.org" <sidr@ietf.org>
Date: Mon, 09 Apr 2012 12:15:15 -0400
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: Ac0WIP7poYzIWIsYQjeyKyGlcjPvLQAQ5cwg
Message-ID: <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net>
In-Reply-To: <4F828D6D.10907@raszuk.net>
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
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
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: Mon, 09 Apr 2012 16:15:20 -0000
The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e., unsigned). In either case, the update necessarily has AS-path info. If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Path" in it. The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k, pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris. The Secure Path is semantically equivalent to the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to go to a BGP-4 only AS, then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN that was collapsed in BGPSEC will be repeated pCount number of times, and any transparent route server ASN (with pCount=0) in BGPSEC will be removed. Is this semantic equivalence (of the Secure Path) and the guarantee of convertibility to BGP-4 AS_PATH not enough? Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in a pristine way) in addition to the Secure Path, albeit at the cost of duplication and associated processing cost/confusion? Just a honest question seeking people's opinion. Sriram >-----Original Message----- >From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Robert >Raszuk >Sent: Monday, April 09, 2012 3:19 AM >To: sidr@ietf.org >Cc: idr@ietf.org List >Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening > > >> Your analysis assumes that there a conventional BGP-4 AS_PATH field >> and then there is is BGPSEC_Path_Signatures from which AS path info >> can be inferred separately. This is not true in the latest BGPSEC >> update format as Matt presented it in Paris. > >How an optional attribute replace well-known mandatory one ? > >Sorry but for such step formal IDR WG approval is necessary if you choose to >propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP >protocol change. > >Documentation of partial deployment is required as well as two interoperable >implementations ;). > >RFC4271: > >5.1.2. AS_PATH > > AS_PATH is a well-known mandatory attribute. This attribute > identifies the autonomous systems through which routing information > carried in this UPDATE message has passed. The components of this > list can be AS_SETs or AS_SEQUENCEs. > > >draft-ietf-sidr-bgpsec-protocol-02.txt > > This document specifies a new optional (non-transitive) BGP path > attribute, BGPSEC_Path_Signatures. > > >Best regards, >R.
- [sidr] draft-ietf-sidr-bgpsec-threats-02: Path sh… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Stephen Kent
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Jakob Heitz
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Shane Amante
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Murphy, Sandra
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Andrew Chi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Sriram, Kotikalapudi
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Robert Raszuk
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Jakob Heitz
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Sriram, Kotikalapudi
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Murphy, Sandra
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Montgomery, Douglas
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Murphy, Sandra
- [sidr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-0… Stephen Kent
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Stephen Kent
- Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pat… Stephen Kent
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] No BGPSEC intradomain ? Warren Kumari
- Re: [sidr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Warren Kumari
- Re: [sidr] [Idr] No BGPSEC intradomain ? Montgomery, Douglas
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jakob Heitz
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jakob Heitz
- Re: [sidr] [Idr] No BGPSEC intradomain ? Randy Bush
- Re: [sidr] [Idr] No BGPSEC intradomain ? Randy Bush
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Paul Jakma
- [sidr] iBGP, BGPSEC and incremental deployment (w… Jeffrey Haas
- Re: [sidr] [Idr] No BGPSEC intradomain ? Christopher Morrow
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jakob Heitz
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? Brian Dickson
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Christopher Morrow
- Re: [sidr] [Idr] No BGPSEC intradomain ? George, Wes
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… George, Wes
- Re: [sidr] [Idr] No BGPSEC intradomain ? George, Wes
- Re: [sidr] [Idr] No BGPSEC intradomain ? Robert Raszuk
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Christopher Morrow
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jeffrey Haas
- Re: [sidr] [Idr] No BGPSEC intradomain ? George, Wes
- Re: [sidr] [Idr] No BGPSEC intradomain ? Jeffrey Haas
- Re: [sidr] [Idr] No BGPSEC intradomain ? Paul Jakma
- Re: [sidr] iBGP, BGPSEC and incremental deploymen… Jakob Heitz
- Re: [sidr] [Idr] iBGP, BGPSEC and incremental dep… Brian Dickson