Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt
Job Snijders <job@ntt.net> Wed, 30 September 2020 14:10 UTC
Return-Path: <job@ntt.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F713A09EF for <sidrops@ietfa.amsl.com>; Wed, 30 Sep 2020 07:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0r8faZ13BTjt for <sidrops@ietfa.amsl.com>; Wed, 30 Sep 2020 07:10:40 -0700 (PDT)
Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592033A09EC for <sidrops@ietf.org>; Wed, 30 Sep 2020 07:10:40 -0700 (PDT)
Received: from bench.sobornost.net (sobornost.connected.by.freedominter.net [45.155.156.99]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id CE46F22012E; Wed, 30 Sep 2020 14:10:38 +0000 (UTC)
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id af600535; Wed, 30 Sep 2020 14:10:36 +0000 (UTC)
Date: Wed, 30 Sep 2020 14:10:36 +0000
From: Job Snijders <job@ntt.net>
To: sidrops@ietf.org
Message-ID: <20200930141036.GD13264@bench.sobornost.net>
References: <160108675080.9506.12588124331364773763@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <160108675080.9506.12588124331364773763@ietfa.amsl.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5-sFl3RCzn7xQ0YFOD31C56Ko4o>
Subject: Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 14:10:42 -0000
Dear all, I have reviewed the document and would like to offer some feedback. The title probably should read "BGPsec Validation State Signaling via Internal BGP" Furthermore the document probably benefits replacing "BGP neighbor" with "IBGP neighbor", similarly "BGP peer" and "peer" should be replaced with "IBGP neighbor" and "neighbor" for more consistent reading. Emphasis on IBGP is important as this document outlines non-transitive extended communities. (Let's park discussion about EBGP vs CONFED vs IBGP for the sake of progressing conversation about the substance of this draft) Internal inconsistency in draft-sidrops-bgpsec-validation-signaling ------------------------------------------------------------------- RFC 8205 section 5.1 states "BGPsec validation need only be performed at the eBGP edge.", and also "a BGPsec speaker MAY temporarily defer validation of incoming UPDATE messages." With the above in mind, in section 4 of draft-sidrops-bgpsec-validation-signaling the first paragraph references an EBGP speaker that received a BGPsec UPDATE from a neighbor outside the administrative domain. If one follows the logical outcomes of temporarily deferment of validation, the EBGP node was unable to perform BGPsec path validation, thus MUST set validation state 'Unverified'. Consequently the BGP UPDATE is distributed to IBGP speakers, which all have to perform full BGPsec path validation in order to confirm that the validation state is indeed "Unverified". One might as well not attach any community at all because speaker A doesn't signal of note - because it doesn't know. If the EBGP edge device that (temporarily or forever) is unable to do BGPsec validation, it will for the duration of that event be unable to set the appropriate community, as it cannot validate. Whatever communities it sets, other nodes in the network still need to verify whether or not the community is true. As such, the communities are merely overhead. Imagine a two node network (ascii art, mind your MUA): +--------+ |AS 65123| +----+---+ | +------+----+ +--EBGP1---+ AS 650001 +----------------EBGP2------+ | +-----------+ | | | | +-----------------------------------+ | | | AS 65666 running draft-signaling | | | | | | | | +---------------+ | | +----------+ BGP speaker A |****IBGP | | | +---------------+ * | | | * | | | +-------*-------+ | | | | BGP Speaker B +---------+ | +---------------+ | | | +-----------------------------------+ If BGP speaker A cannot perform BGPsec validation on EBGP1, it can't confirm whether _65001_65123$ is a valid BGPSec_PATH or not. But whatever conclusion speaker A draws, speaker B receives the _650001_65123$ path via its own EBGP2 session with 650001. Whatever validation (and signaling) happens via the IBGP session, it does not in any way positively impact speaker B's decisions, as speaker B can't use IBGP information as input into its decision making process regarding the BGP UPDATE received via EBGP2. Draft-sidrops-bgpsec-validation-signaling is not a replacement or alternative to the RPKI-To-Router protocol. If the meaning of the 'unverified' state is 'maybe I will do validation later, maybe not', I don't see any practical application. If the meaning of 'valid' is to be taken at face value, again, there is no value in a standardized community, see RFC 3514. If the meaning of 'invalid' is that following BGPsec path validation the route is deemed invalid, then why was it propagated in the first place? If Speaker B is not able to do Path Validation, whatever 'invalid' signal it receives on its IBGP session does not and cannot override or influence what was received via EBGP2. The text in the abstract and introduction about 'temporarily deferment of validation' should probably be removed as it is hard to see how in the situation of temporarily deferment the existence of these communities makes sense. Undeployability --------------- An architectural choice to use BGP communities for any purpose oftentimes stems from an operator's ability to deploy 'a new thing' in a network where (part of) the nodes have not yet been upgraded. Good useful examples of this mechanism are GRACEFUL_SHUTDOWN and NO_EXPORT. The document states in section 3 "If the router supports the extension as defined in this document" ... which implies that all nodes in an administrative domain must be upgraded, which in turn somewhat nullifies the justification to use communities in the first place. This doesn't allow a brownfield upgrade! Section 3.1 "Error Handling at Peers" reads as a simple paragraph, but is brittle and error-prone to implement in routing policy. Most network operators are accustomed to implementing a 'test & branch' procedure by positive community matching and then taking some action. RFC 1997 defines communities as "A community is a group of destinations which share some common property." The implication is that when multiple communities are attached to a route, the route simply has multiple properties. However, this document outlines a mechanism where specific combinations of communities are invalid input: "(0x43,TBD,0) ∩ (0x43,TBD,1)", or "(0x43,TBD,1) ∩ (0x43,TBD,2)", or "(0x43,TBD,2) ∩ (0x43,TBD,0)". In currently available commercial|free-of-the-shelf BGP implementations implementing adequate error handling is error-prone. RFC 8097 shares this weakness. The Introduction proposes that a reduction of path validation processing load can be achieved, however Section 4 states that if there is a discrepancy between the locally computed validation state and the community, the locally computed state takes precedence. Thus, no load processing reduction can be achieved because a BGPsec capable node must compute the validation state before it can compare it to the community. Not analogous to RFC 8097 ------------------------- To many this draft may appear as 'for sure, we need something similar for bgpsec as we have for route origin validation' - but I think no such equivalence exists, or needs to exist. RFC 8097 defines a set of BGP communities which can optionally be associated with a prefix *after* the Origin Validation procedure (RFC 6811) *successfully* is executed. This in contrast to draft-bgpsec-validation-signaling, where a node is *unable* to path validation, thus can never set the appropriate communities. RFC 8097 does not describe a situation where Origin Validation is temporarily deferred. Reject don't tag (do, don't talk about doing it) ------------------------------------------------ If a route is considered invalid (for whatever reason, beauty is in the eye of the beholder), the route should be rejected. Merely tagging an invalid route with a specific community and propagating it further, is a useless excercise. Such designs hampers deployment of actual security measures. If an operator wants to tag invalid routes for analytical purposes, they can easily do so and can choose from milions of values using any of the flavors of communities that are available. If you *are* propagating an invalid route, you are propagating an invalid route - in which case it does not matter whatever communities are attached to it. Conclusion ---------- At this point in time I don't think this draft can proceed to publication, from the document itself it is not clear to me what benefits can be achieved and how this benefits Internet operations. The draft requires new code on devices in addition to what a BGPsec capable implementation would require. And in today's world there aren't off-the-shelf BGPsec implementations to start with, so piling on additional code requirements is too early in the innovation cycle anyhow. Using communities is no substitute for BGPsec validation or for RTR, this document may subtly lead people to believe otherwise. It is possible I misunderstood things, I look forward to feedback from the group. Kind regards, Job ps. nitpick: one of the author's company names seems misspelled. On Fri, Sep 25, 2020 at 07:19:10PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : BGPsec Validation State Signaling > Authors : Oliver Borchert > Doug Montgomery > Daniel Kopp > Filename : draft-sidrops-bgpsec-validation-signaling-05.txt > Pages : 8 > Date : 2020-09-25 > > Abstract: > This document defines a new BGP non-transitive extended community to > carry the BGPsec path validation state. BGP speakers that receive > this community string can use the embedded BGPsec validation state in > conjunction with configured local policies to influence their > decision process. The ability to accept and act on BGPsec path > validation state from a neighbor allows for a reduction of path > validation processing load and/or increased resilience in the event > that a router is temporarily unable to perform local path validation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-sidrops-bgpsec-validation-signaling/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-05 > https://datatracker.ietf.org/doc/html/draft-sidrops-bgpsec-validation-signaling-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-sidrops-bgpsec-validation-signaling-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops
- [Sidrops] I-D Action: draft-sidrops-bgpsec-valida… internet-drafts
- Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-va… Job Snijders
- Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-va… Borchert, Oliver (Fed)
- Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-va… Job Snijders
- Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-va… Borchert, Oliver (Fed)
- Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-va… Borchert, Oliver (Fed)