Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Fri, 13 January 2017 00:08 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 49370129546; Thu, 12 Jan 2017 16:08:14 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com
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 14-KKXV5-B6K; Thu, 12 Jan 2017 16:08:11 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0116.outbound.protection.outlook.com [23.103.200.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCEE1294F1; Thu, 12 Jan 2017 16:08:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cATlEuUhjlZTeDewhMBmCa0GphOgOptsb7bEYYlf8QA=; b=ubhBE85+x7N5cEvwOmOuDuhtjr1lBfIm3OnXxJFhG2YFfbqzilaY9r651ciThXrZ8YAu3QC/KgvrRNfgbtqwcHnb6ZDTU+J885VxcjicCDzlMdvtt4Ng5h3/OKT7IrIt/6Ej/bmXIwIKCEQqr72mUsRXP1nLO0wxBGsWscqfpxo=
Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Fri, 13 Jan 2017 00:08:08 +0000
Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Fri, 13 Jan 2017 00:08:08 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
Thread-Index: AQHSZqXltReTUHCj80yY3nhxkKtF8KE1k1Xw
Date: Fri, 13 Jan 2017 00:08:08 +0000
Message-ID: <DM2PR09MB04461FA2EC8F5538D6DC03C184780@DM2PR09MB0446.namprd09.prod.outlook.com>
References: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com>
In-Reply-To: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.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.140.122]
x-ms-office365-filtering-correlation-id: a75058cb-a673-4b24-5a17-08d43b484146
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0445;
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:GyEkEZYEk6yiWDreCx2RsisqU6zeJ3zw5APMW6eR7pJ00z1Gjr9VW40rXA0hhYkDE+FCWMevdMAQ5Znab9yeMUwFZl7bnzLXSqXm0CgGww+PoiKcpV9u7D5G6I5J/aDrTmggfPDegMImnZRNzUl0ln0LdBwjdjHR+dycFwXhBwAmN6Yj1yOStq8qLbcIlugAGP38OQIzbTqXjkIVCSumkLWxYuAX3xGha3ouXTlt17RGibOgrvYen9AuSUXuFGsQgj4EO7CsLnrIdKt6zpn5i6lyPqI6Rwtq44AC7Dbjh4jzr1qRUo/rAXKAagZgd3sbYjUmTm7f0lDagojmfY4eMwBRfI2pXO8vBOW15c+Rlchqo/k3HRlQ3nbQizWfqWlBHETNAV730G82y41N/CHN8oIBAHS5t6Ximj2YONyA5KMTNjp2Q9iNVIa6ZLhShQMQJu+4Z7ikEhyYsPvkY7iyRA==
x-microsoft-antispam-prvs: <DM2PR09MB0445BC53B23C1D194AF51C0E84780@DM2PR09MB0445.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445;
x-forefront-prvs: 018632C080
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(199003)(189002)(229853002)(77096006)(54906002)(106116001)(86362001)(39060400001)(2950100002)(6116002)(106356001)(74316002)(101416001)(99286003)(54356999)(105586002)(2906002)(4326007)(92566002)(7696004)(3846002)(9686003)(55016002)(6506006)(6436002)(102836003)(25786008)(38730400001)(2900100001)(5660300001)(97736004)(68736007)(50986999)(3280700002)(8676002)(3660700001)(76176999)(122556002)(81156014)(81166006)(7736002)(33656002)(8936002)(230783001)(5001770100001)(305945005)(66066001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.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:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 00:08:08.1773 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/4MqOAk4o0ZN2xYair0m4OfUx80g>
Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, Matthias Waehlisch <m.waehlisch@fu-berlin.de>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Jan 2017 00:08:14 -0000
Hi Spencer, Please see my comments inline below marked with [Sriram]. I have made changes in the document in response to your comments. You’ll see them in version-22 (to be uploaded in the next few days). >Perhaps I'm just having a good day, but this is >one of the clearest BGP-related specifications >I can remember reviewing. Thanks for that, >and especially for the background on design decisions. [Sriram] Very kind of you. Thank you. > > I did have questions on two points >(which are spread across multiple sections). > > I started out wondering why > > Note that BGPsec update messages can be quite large, therefore any > BGPsec speaker announcing the capability to receive BGPsec messages > SHOULD also announce support for the capability to receive BGP > extended messages [I-D.ietf-idr-bgp-extended-messages]. > > isn't a MUST, but Section 7 explains this > > In Section 2.2, is was stated that a BGPsec speaker SHOULD announce > support for the capability to receive BGP extended messages. Lack of > negotiation of this capability is not expected to pose a problem in > the early years of BGPsec deployment. However, as BGPsec is deployed > more and more, the BGPsec update messages would grow in size and some > messages may be dropped due to their size exceeding the current 4K > bytes limit. Therefore, it is strongly RECOMMENDED that all BGPsec > speakers negotiate the extended message capability within a > reasonable period of time after initial deployment of BGPsec. > > Perhaps that's worth a forward pointer? >(or maybe even dragging this paragraph forward from Section 7) [Sriram] I have put in a forward pointer in Section 2.2. It reads, “Please see related operational guidance in Section 7.” > > I'm looking at > > BGPsec speakers SHOULD drop > incoming update messages with pCount set to zero in cases where the > BGPsec speaker does not expect its peer to set pCount to zero. > (That > is, pCount is only to be set to zero in cases such as route servers > or AS Number Migration where the BGPsec speaker's peer expects pCount > to be set to zero.) > > and wondering why that's not a MUST. If I'm understanding this >correctly (which is theoretically possible), the BGPsec speaker >is telling its peer that it's not participating as a transit AS, >but the peer thinks it should be. Is there anything intelligent >that the peer can do with the update? [Sriram] You are absolutely right: MUST makes sense. Because later in Section 5.2 check list, we say: 7. If the update message was received from a peer that is not expected to set pCount equal to zero (see Section 4.2 and Section 4.3) then check to ensure that the pCount field in the most-recently added Secure_Path Segment is not equal to zero. (See router configuration guidance related to this in Section 7.) [Sriram] In Section 5.2, we also say: If any of these checks fail, it is an error in the BGPsec_Path attribute. [Sriram] Since the receiver action is clearly stated in Section 5.2, I have dropped the two sentences you cited beginning with “BGPsec speakers SHOULD drop incoming update messages with pCount set to zero…” from Section 4.2 which is all about sender actions. That particular paragraph now reads: A route server that participates in the BGP control plane, but does not act as a transit AS in the data plane, may choose to set pCount to 0. This option enables the route server to participate in BGPsec and obtain the associated security guarantees without increasing the length of the AS path. (Note that BGPsec speakers compute the length of the AS path by summing the pCount values in the BGPsec_Path attribute, see Section 5.) However, when a route server sets the pCount value to 0, it still inserts its AS number into the Secure_Path Segment, as this information is needed to validate the signature added by the route server. See [I-D.ietf-sidr-as-migration] for a discussion of setting pCount to 0 to facilitate AS Number Migration. Also see Section 4.3 for the use of pCount=0 in the context of an AS confederation. See Section 7 for operational guidance for configuring a BGPsec router for setting pCount=0 and/or accepting pCount=0 from a peer. > > Section 7 refers to this SHOULD, while adding a few more SHOULDs. > > A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) > with a transparent AS is expected to set pCount = 0 in its > Secure_Path Segment while forwarding an update to a peer (see > Section 4.2). Clearly, such an IXP SHOULD configure itself to set > its own pCount = 0. As stated in Section 4.2, "BGPsec speakers > SHOULD drop incoming update messages with pCount set to zero in cases > where the BGPsec speaker does not expect its peer to set pCount to > zero." This means that a BGPsec speaker SHOULD be configured so that > it permits pCount =0 from an IXP peer and never permits pCount = 0 > from a peer that is not an IXP. > > Again, I'm curious about why a BGPsec speaker >wouldn't do this. Is that obvious, to those skilled in the art? > > I'm looking at Section 8.4, which adds some more background. > > The mechanism of setting the pCount field to zero is included in this > specification to enable route servers in the control path to > participate in BGPsec without increasing the length of the AS path. > However, entities other than route servers could conceivably use this > mechanism (set the pCount to zero) to attract traffic (by reducing > the length of the AS path) illegitimately. This risk is largely > mitigated if every BGPsec speaker drops incoming update messages that > set pCount to zero but come from a peer that is not a route server. > However, note that a recipient of a BGPsec update message within > which an upstream entity two or more hops away has set pCount to zero > is unable to verify for themselves whether pCount was set to zero > legitimately. > > So, the reason this is a SHOULD, and not a MUST, is because >a recipient two or more hops away can't be sure pCount was >set appropriately? But doesn't the SHOULD increase the >chances to propagate an update with an inappropriate pCount? > [Sriram] I light of what I said above, I have revised the paragraph in Section 7 to read: A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) with a transparent AS is expected to set pCount=0 in its Secure_Path Segment while forwarding an update to a peer (see Section 4.2). Clearly, such an IXP must configure its BGPsec router to set pCount=0 in its Secure_Path Segment. This also means that a BGPsec speaker MUST be configured so that it permits pCount=0 from an IXP peer. Two other cases where pCount is set to zero are in the context AS confederation (see Section 4.2) and AS migration [I-D.ietf-sidr-as-migration]. In these two cases, pCount=0 is set and accepted within the same AS (albeit the AS has two different identities). Note that if a BGPsec speaker does not expect a peer AS to set its pCount=0, and if an update received from that peer violates this, then the update MUST be considered to be in error (see the list of checks in Section 5.2). See Section 8.4 for a discussion of security considerations concerning pCount=0. [Sriram] I light of what I said above, I have also revised the paragraph in Section 8.4 to read: The mechanism of setting the pCount field to zero is included in this specification to enable route servers in the control path to participate in BGPsec without increasing the length of the AS path. Two other scenarios where pCount=0 is utilized are in the context AS confederation (see Section 4.2) and AS migration [I-D.ietf-sidr-as-migration]. In these two scenarios, pCount=0 is set and also accepted within the same AS (albeit the AS has two different identities). However, entities other than route servers, confederation ASes or migrating ASes could conceivably use this mechanism (set the pCount to zero) to attract traffic (by reducing the length of the AS path) illegitimately. This risk is largely mitigated if every BGPsec speaker follows the operational guidance in Section 7 for configuration for setting pCount=0 and/or accepting pCount=0 from a peer. However, note that a recipient of a BGPsec update message within which an upstream entity two or more hops away has set pCount to zero is unable to verify for themselves whether pCount was set to zero legitimately. Sriram
- [sidr] Spencer Dawkins' No Objection on draft-iet… Spencer Dawkins
- Re: [sidr] Spencer Dawkins' No Objection on draft… Sriram, Kotikalapudi (Fed)
- Re: [sidr] Spencer Dawkins' No Objection on draft… Randy Bush
- Re: [sidr] Spencer Dawkins' No Objection on draft… Spencer Dawkins at IETF