[sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Wed, 04 January 2017 16:16 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D88A91295ED; Wed, 4 Jan 2017 08:16:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com>
Date: Wed, 04 Jan 2017 08:16:22 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/KERU9pxBcKM4zeo0nGf7PYktwvY>
Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org
Subject: [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
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: Wed, 04 Jan 2017 16:16:23 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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. 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) 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? 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?
- [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