Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt

Sandra Murphy <sandy@tislabs.com> Sat, 17 October 2015 15:30 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202B81A9117 for <sidr@ietfa.amsl.com>; Sat, 17 Oct 2015 08:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ACNij_tEj0NP for <sidr@ietfa.amsl.com>; Sat, 17 Oct 2015 08:30:55 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F54E1A9111 for <sidr@ietf.org>; Sat, 17 Oct 2015 08:30:55 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D178928B0046; Sat, 17 Oct 2015 11:30:54 -0400 (EDT)
Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 80C211F8035; Sat, 17 Oct 2015 11:30:54 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D03705CD-1289-4BD3-B6AE-E2BA5E80E1FF"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <CY1PR09MB0793A1FDB2C6AE9FE72114EC843D0@CY1PR09MB0793.namprd09.prod.outlook.com>
Date: Sat, 17 Oct 2015 11:30:59 -0400
Message-Id: <A2062B52-F6E8-4C8D-B1B9-02C5DD57E548@tislabs.com>
References: <SN1PR09MB079938B1A44171328C0B16CA846A0@SN1PR09MB0799.namprd09.prod.outlook.com> <D20B8CAC.45839%dougm@nist.gov> <CY1PR09MB079376AC097FDDB73531814184690@CY1PR09MB0793.namprd09.prod.outlook.com> <m2613ca3kf.wl%randy@psg.com> <0F44566E-2054-4ECA-83AF-EE39585E841E@tislabs.com>, <CANTg3aCvdCKY+BfJ9G0dtJpQth=ckud=pmYyY4rKJh_V2A+7fQ@mail.gmail.com> <CY1PR09MB0793A1FDB2C6AE9FE72114EC843D0@CY1PR09MB0793.namprd09.prod.outlook.com>
To: Sriram Kotikalapudi <kotikalapudi.sriram@nist.gov>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/e59vHmSa87DTAbWQ5Ung9EGHiyw>
Cc: sidr wg list <sidr@ietf.org>, Sandra Murphy <sandy@tislabs.com>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 17 Oct 2015 15:30:57 -0000

speaking as a regular ol’ member

On Oct 16, 2015, at 12:09 PM, Sriram, Kotikalapudi <kotikalapudi.sriram@nist.gov> wrote:

> 
> 
> Substantive comment ....
> 
> Looking at this on page 23,
> 
> "BGPsec update messages do not contain an AS_PATH attribute.
>    Therefore, a BGPsec speaker MUST utilize the AS path information in
>    the BGPsec_Path attribute in all cases where it would otherwise use
>    the AS path information in the AS_PATH attribute.  The only exception
>    to this rule is when AS path information must be updated in order to
>    propagate a route to a peer (in which case the BGPsec speaker follows
>    the instructions in Section 4)."
> 
> What is being said in the second sentence above is not clear.
> 
> No exception applies if the peer is BGPsec capable and negotiated BGPsec.
> 
> So is the exception for the case when the peer is non-BGPsec?
> 
> May the fix is to replace this (current):
> 
> "The only exception
>    to this rule is when AS path information must be updated in order to
>    propagate a route to a peer (in which case the BGPsec speaker follows
>    the instructions in Section 4)."
> 
> with the following (proposed):
> 
> The only exception
>    to this rule is when AS path information must be re-formatted to AS_PATH in order to
>    propagate a route to a non-BGPsec peer (in which case the BGPsec speaker follows
>    the instructions in Section 4.4).
> 


I read that sentence differently.

When BGP is propagating a route to a neighbor, it ordinarily appends its AS to the AS_PATH.

The “in all cases” would imply the same would happen in BPGsec, whether the neighbor is bpgsec capable or not.

The exception is that, in the propagating case, BGPsec will instead follow section 4 - which covers bgpsec capable neighbors (embed AS in BGPsec_Path) and bgpsec incapable neighbors (reconstruct AS_PATH).

I think your statement is correct, but I don’t think it is what is meant here.

—Sandy, speaking as a regular ol’ member