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

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Fri, 16 October 2015 16: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 CE3C61B2B05 for <sidr@ietfa.amsl.com>; Fri, 16 Oct 2015 09:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hi3LPmJOjDfh for <sidr@ietfa.amsl.com>; Fri, 16 Oct 2015 09:09:02 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6F01B32B7 for <sidr@ietf.org>; Fri, 16 Oct 2015 09:09:02 -0700 (PDT)
Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 16:09:00 +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; Fri, 16 Oct 2015 16:09:00 +0000
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Matthew Lepinski <mlepinski.ietf@gmail.com>
Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt
Thread-Index: AQHRCCz4wwoZaaJjcUiLCIPytNy8pQ==
Date: Fri, 16 Oct 2015 16:09:00 +0000
Message-ID: <CY1PR09MB0793A1FDB2C6AE9FE72114EC843D0@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>
In-Reply-To: <CANTg3aCvdCKY+BfJ9G0dtJpQth=ckud=pmYyY4rKJh_V2A+7fQ@mail.gmail.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.219.252]
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0795; 5:L2gfuNy9XT6L0XQKI1wcE9UEN3d1APar+aB0CEEFLEyPasH5AtSwpdZhlL/igKSliSNqTiyS7Vt6AoQZC1RPlbnmkJ/kGe4KMZLAUXQfXSwL3Yb6R6XzOVfyzx1wjryWC8O4b4YKGpnYRiX6wo6vmA==; 24:IZ5o7IiK85xJzTZu3BSK7b6616wfbO3YLtK1qR+1CUzVs0eEj34auRG5a+DhPc9o24QrtVbFEDAS3SNvkJQUdBfVhjGAOVpDhuusaCEPyo8=; 20:XsoKlueEuCe9Dr+ZA4MRfHuja898sCF/Lt6HueAMn7iFAkpH8DSp3SQNzSqdMt8rA/Q/DbWQsubadDgSYyNIBw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0795;
x-microsoft-antispam-prvs: <CY1PR09MB079526653DB5C42D2D512DD8843D0@CY1PR09MB0795.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795;
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(19627405001)(122556002)(5008740100001)(5001960100002)(110136002)(101416001)(64706001)(74316001)(5007970100001)(92566002)(230783001)(11100500001)(5004730100002)(46102003)(76576001)(54356999)(106356001)(40100003)(19625215002)(2900100001)(5003600100002)(87936001)(77096005)(189998001)(99286002)(93886004)(76176999)(19580395003)(2950100001)(10400500002)(86362001)(66066001)(50986999)(33656002)(15975445007)(81156007)(19617315012)(106116001)(97736004)(5002640100001)(105586002)(102836002)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; 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: multipart/alternative; boundary="_000_CY1PR09MB0793A1FDB2C6AE9FE72114EC843D0CY1PR09MB0793namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 16:09:00.5436 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/UmFHKtJP_Ztc70n5rpkuEFofBlw>
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: Fri, 16 Oct 2015 16:09:09 -0000

Hi Matt,


A few notes below (one editorial and one substantive).
There is a typo in this sentence (page 11):
In particular, the BGPsec
   attribute SHOULD NOT be removed even in the case where the BGPsec
   update message *has not* been that *has not* successfully validated.
Repeat of 'has not' above. May be the sentence was meant to read as follows?
In particular, the BGPsec
   attribute SHOULD NOT be removed even in the case where the BGPsec
   update message has not been validated (not attempted) or has not been successfully validated.
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<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-13#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<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-13#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).
Sriram