Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening

"Murphy, Sandra" <Sandra.Murphy@sparta.com> Mon, 09 April 2012 18:12 UTC

Return-Path: <Sandra.Murphy@sparta.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 01C0D21F87B3; Mon, 9 Apr 2012 11:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 dpR7RA2X-2-x; Mon, 9 Apr 2012 11:12:36 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D9DFB21F8764; Mon, 9 Apr 2012 11:12:35 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q39ICYrM014152; Mon, 9 Apr 2012 13:12:34 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q39ICXUq028551; Mon, 9 Apr 2012 13:12:33 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 14:12:33 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "robert@raszuk.net" <robert@raszuk.net>
Thread-Topic: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: AQHNFnVVP+4RrE3i6E+YFR9dt0xcTpaSxY54
Date: Mon, 9 Apr 2012 18:12:32 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2586@Hermes.columbia.ads.sparta.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>, <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>, <4F831ACE.8090903@raszuk.net>
In-Reply-To: <4F831ACE.8090903@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] 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 18:12:37 -0000

still speaking as regular ol' member

by "no reverse direction",  it was in answer to your question "What happens in the opposite direction ? ".  I should have used your words exactly.

I meant what I said in the second line I wrote.  "Incoming paths that are unsigned are not propagated by bgpsec speakers as signed paths.".    They are propagated as unsigned paths.

So there's no need to try to produce signatures for unsigned paths.  Routes that come in unsigned, stay unsigned.

There is no loss of reachability, because the routes are propagated.

--Sandy, speaking as regular ol' member

________________________________________
From: Robert Raszuk [robert@raszuk.net]
Sent: Monday, April 09, 2012 1:22 PM
To: Murphy, Sandra
Cc: Sriram, Kotikalapudi; idr@ietf.org List; sidr@ietf.org
Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &  lengthening

Hi Sandy,

> There is no reverse direction.

What do you mean there is no reverse direction ?

Sriram said:

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

That means that there is EBGP peering at the two ASes which on one side
supports BGPSEC on the other does not.

In order to establish any form of bidirectional communication sites on
the left need to know how to reach sites on the right and vice versa.

So your below "Don't worry, no problem" directly means "no
reachability". I am afraid there is slight problem with that.

Best regards,
R.


> speaking as regular ol' member
>
> There is no reverse direction.
>
> Incoming paths that are unsigned are not propagated by bgpsec
> speakers as signed paths.
>
> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
>
> And AS4_PATH is not needed in bgpsec speakers - who are assumed to be
> 4-byte aware.
>
> So no need to worry about ASBRs, flag days, etc.  Don't worry, no
> problem.
>
> --Sandy, speaking as regular ol' member.
>
>
> ________________________________________ From: sidr-bounces@ietf.org
> [sidr-bounces@ietf.org] on behalf of Robert Raszuk
> [robert@raszuk.net] Sent: Monday, April 09, 2012 12:29 PM To: Sriram,
> Kotikalapudi Cc: idr@ietf.org List; sidr@ietf.org Subject: Re: [sidr]
> [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&
> lengthening
>
> Hi Sriram,
>
>> 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.
>
> What happens in the opposite direction ? How AS_PATH/AS4_PATH can be
> converted to BGPSEC_Path_Signatures without all necessary
> information present at the ASBR at any arbitrary Autonomous System ?
> Are you going to propose NULL signatures ?
>
> How are you planning on a flag date where all ASBRs in the Internet
> are BGPSEC complaint ?
>
> Why one needs to upgrade also all P routers (intra domain BGP
> speakers) to be BGPSEC complaint provided he is not using BGP as an
> overlay today?
>
> If you think removal of AS_PATH/AS4_PATH is helpful in any way the
> much simpler would be to define new set of AFIs and call it "SECURED"
> leaving current AFI 1 and AFI 2 unchanged BGP protocol wise.
>
> Thx, R.
>
>
>> 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.