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

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Sun, 18 October 2015 03:09 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 3783A1A87F0 for <sidr@ietfa.amsl.com>; Sat, 17 Oct 2015 20:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 OpwZNnHldr8Z for <sidr@ietfa.amsl.com>; Sat, 17 Oct 2015 20:09:52 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E841A87D9 for <sidr@ietf.org>; Sat, 17 Oct 2015 20:09:51 -0700 (PDT)
Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) with Microsoft SMTP Server (TLS) id 15.1.300.14; Sun, 18 Oct 2015 03:09:47 +0000
Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0300.010; Sun, 18 Oct 2015 03:09:48 +0000
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Sandra Murphy <sandy@tislabs.com>
Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt
Thread-Index: AQHRCCz4wwoZaaJjcUiLCIPytNy8pZ5v0UuAgADBklI=
Date: Sun, 18 Oct 2015 03:09:47 +0000
Message-ID: <CY1PR09MB0793422D9283EF98031B05E1843B0@CY1PR09MB0793.namprd09.prod.outlook.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>, <A2062B52-F6E8-4C8D-B1B9-02C5DD57E548@tislabs.com>
In-Reply-To: <A2062B52-F6E8-4C8D-B1B9-02C5DD57E548@tislabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov;
x-originating-ip: [129.6.218.148]
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0796; 5:FGHac2p43/M7sviYd8YvrsUN+kEiToTYMUYg3VeZ7mioyK97nKvP6HYx2I+Pac3KcOGQg0W9U83+E9J3olPsdjo6krTRxQhag0PtsWkjh8LGP2SQHjS1fBiTQ3gLhN8neAbafh+Rv2nUSNW3SYHvHA==; 24:GopBw5WyaK/uTadlNsQg30YMYsrSrXhElU7eFqn75GHUkB6b1lqVKOtl7B4ElOBNituDlgVNXpqvStLTkUYh+TMKf7PWstJPm+h/1YaJuWg=; 20:mulBntgvlBj9Eeb8WjrmMsg4/FWhMGjN0ZuOJuhAqNSkpaX0lC7NLP4tVAzLwYugGmmt/T3NLAhBhcXWKtKDbg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0796;
x-microsoft-antispam-prvs: <CY1PR09MB0796CFF86E2F2A62C335F406843B0@CY1PR09MB0796.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796;
x-forefront-prvs: 07334CBCCD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(24454002)(377454003)(97736004)(76176999)(5008740100001)(102836002)(189998001)(5003600100002)(92566002)(86362001)(81156007)(106356001)(74316001)(19580395003)(5002640100001)(77096005)(5001960100002)(105586002)(10400500002)(230783001)(2900100001)(2950100001)(40100003)(110136002)(76576001)(5001920100001)(50986999)(106116001)(64706001)(66066001)(93886004)(87936001)(122556002)(99286002)(19580405001)(46102003)(101416001)(5007970100001)(33656002)(5004730100002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2015 03:09:47.0329 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/4U9Ky6oZ2XkuNFmuAvNIlUHD7wA>
Cc: sidr wg list <sidr@ietf.org>
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: Sun, 18 Oct 2015 03:09:54 -0000

Ah, I see. I agree your interpretation is the correct one. So no change is necessary. 
Thank you.

Sriram

________________________________________
From: Sandra Murphy <sandy@tislabs.com>
Sent: Saturday, October 17, 2015 11:30 AM
To: Sriram, Kotikalapudi
Cc: Sandra Murphy; Matthew Lepinski; sidr wg list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt

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