Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt
"Borchert, Oliver (Fed)" <oliver.borchert@nist.gov> Fri, 16 October 2020 01:49 UTC
Return-Path: <oliver.borchert@nist.gov>
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 ABCD43A0E55 for <sidrops@ietfa.amsl.com>; Thu, 15 Oct 2020 18:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.998, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 I-QYWUJ_kiE4 for <sidrops@ietfa.amsl.com>; Thu, 15 Oct 2020 18:49:31 -0700 (PDT)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2108.outbound.protection.outlook.com [40.107.91.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614EC3A0E37 for <sidrops@ietf.org>; Thu, 15 Oct 2020 18:49:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I+NJwOlW0Zluc+55lp3ljDnbaA03FigS46dBfIfBGAf6m+wDPZ6hzT2YUCGbBZ2uKNMmmvcLL6t8poDEma+mIm235L0QqrI4ehC8DzdPt5Bjc8RSEjkpQgVOoRFtjzvzg5FMnCbLmngJUfQ8Wc4kVs+YzlgRB/QcNyMhM5Nx+Etg8j0GkOiOl0mjHG244FHDpTqIobmHpqmGV7S3uc7pZjmMGD+0dGoc4Vu4CTJJCQXoVnZttz4tRCVTC2p/3hDl25tuJemnflFxoDw8t/2wTJiovAeS/6d1bE8y9TL3OrUFOKniITa2GfEz+XY1RXxoHg3OyI1xv1xtq4K1s7Amrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JmzWoov3+PqxqvEqqwpYUeQENNbIrfZwF99MUufBr80=; b=X7qqu8cLNE8q33RQf5PPx7nqk8oVKPJm7kvBzeUSQvRva8fvmtlp28GEPp6VbfElfA2ZPVpigxyyfKAC6/3L30EzWcBhTc1f5nblQ6OtN2X2N8sWl1LF8a1KltLEy2rCPHi3Afq3vK/p/zfL4L3HNHhk5AToO3GLIXSnfTAvf+apGDNfKEpE+MC4xpH3oI74rqSBt9HC0sKbeAOaA0La9A8+EW97IffA3hL1jR3q1h8N3FvmX8TqK7zbSRLLFuwsx6ebCvK+8yHCLQJ0P9YqDm8fRG3QGQHyYXci7U1PEef5+oOaLijHFIl/BgUjFWMjt9H2dZPm7H99W3JcTPnVyA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JmzWoov3+PqxqvEqqwpYUeQENNbIrfZwF99MUufBr80=; b=D7uf/Hk+UdJqPdpr59QQlx+n55G8ZdRyBAAU3sN+9v9W14mYNSw3mHfTgxr8OIQhLuKj23JLOARzJOzKFsRJKxz4eEML1a8JEJrqNRYey7XSVjqFVcZLge+m0BcOESvrsvhV3aEh3cUv0A3d/m2riR7xYI2lFehXTr6ngIJ3pRk=
Received: from SA0PR09MB6636.namprd09.prod.outlook.com (2603:10b6:806:ac::19) by SA0PR09MB7115.namprd09.prod.outlook.com (2603:10b6:806:7d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.23; Fri, 16 Oct 2020 01:49:28 +0000
Received: from SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d]) by SA0PR09MB6636.namprd09.prod.outlook.com ([fe80::d1b8:7820:b990:b39d%4]) with mapi id 15.20.3477.021; Fri, 16 Oct 2020 01:49:28 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Job Snijders <job@ntt.net>, "sidrops@ietf.org" <sidrops@ietf.org>
CC: "Montgomery, Douglas C. (Fed)" <dougm@nist.gov>, "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
Thread-Topic: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt
Thread-Index: AQHWk6uXSmv2SdqdjUWDbieQ3efDvqmBP5gAgBekxwCAAG5CAA==
Date: Fri, 16 Oct 2020 01:49:28 +0000
Message-ID: <3C7E14C8-9200-4991-8E8D-BE821F3A1D06@nist.gov>
References: <160108675080.9506.12588124331364773763@ietfa.amsl.com> <20200930141036.GD13264@bench.sobornost.net> <A77802CA-8914-469C-8BE7-904DA7E235FD@nist.gov>
In-Reply-To: <A77802CA-8914-469C-8BE7-904DA7E235FD@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
authentication-results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [2610:20:6005:165::78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a1eef5f5-10ef-4a3a-c775-08d87175b82e
x-ms-traffictypediagnostic: SA0PR09MB7115:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <SA0PR09MB711523FB27B08B3D5F4586AA98030@SA0PR09MB7115.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hMq24J9XdEBSFUjdHp5VNpny2fhqSu54dOYJ3Syi1v1kuZcWAzsPktue0riKZCsPoll3uLwj9YSui7is3lUkT9B99wvmtqJAccKihmeRUt864h3h3tNUDU82sZkYmUHhzwCoJV9UTAaktTceV6Nx03I0AeHcZ5kUTOIpUbut+CSgP0ceSTlIZ8Xk0Aji7LxU/d2LRtYrQuxq3zQy86z466UPXYa8TcohScc+E7ZU3jb4Z9dE2M3ggGsgjKJvjA3KPuVhbzbaOQC3UYRfnIOhkDAGA349hb/UchE0bLprOwkuoiJ92kNnHw3h2Hsa++KIpyW+zVjz569G7l4nA4PWZQgsyYZiRbrQxc5KPwErJ6sn3aIoz44lkC9TQMA79qjtcNRaolgdQmDWTe0gSHqydg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR09MB6636.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(376002)(366004)(39860400002)(110136005)(54906003)(2616005)(6486002)(478600001)(30864003)(33656002)(966005)(5660300002)(186003)(66574015)(316002)(8676002)(64756008)(2906002)(71200400001)(107886003)(86362001)(6512007)(83380400001)(76116006)(66556008)(91956017)(66446008)(66476007)(66946007)(8936002)(6506007)(36756003)(4326008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: rddGJmb74XpkQsst1CJxYuGZ4lPjIUniQpkys07e9Ki9n2Npk1AoqAvSZ9lZNbjJEyWMPBA3nupU8YE2tgvMNQrihWrrU9SbbEFF/koqyonLl5knzafx3y6Lv6TqvA/0p1mA+b2qJ7rlxv4rUvY4cC2dvxh+zKblvYDEhqtS/+8l3EJR7kuOuUl4/kpYz7YIpnnAfosNxf1rxG5OmnTR7dv+3gZ7UNjkXZ/UiGN1iOvnZAvaRCnu42CZDFV+tfeZzxvDzjFkKwjXJaQ4EdqTyc8COjfypAj0F39vyjU7bF9/vET/NNs3IvdeKsGXsu7C923tusoduyUUDiuDVkVuh5FU3yLeSE5mpLkE3zYWMD/jln4CPE122m7724mPgXz+C5MT16lY5SZQlErKJBRn8+PdK8fMM3XZNqmGKSADCSMLVV0zLxbIksNHXo8SYOuU/D8fOnHs4GZRnrvMN70AeZb/VUILY+Y2U/oHgYeyBWh//4oBMzQaX8nTbI8dmV550EfqUQnXT1yecj4tcwXO2phtmG7s5gCVVZ9R1noX+Py6dPw+tb5bHSLEE2kn+vLyN9YkEj9g7DTOP+pmeRaE2UdhCyPlkfd6VLaqAjlZ4Rq1ZubJw3fG5WDsGN/rkhiAHDWgN87WKUXDfEecueZK74OyvaRk9EMrx8njRcSrCFE=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4EBEC770F0D3AA4B9D715C3C32B6D199@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB6636.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a1eef5f5-10ef-4a3a-c775-08d87175b82e
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 01:49:28.7135 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nOO/y1PxBmnMxORBauI4V5dXRZxvrdEP2LnxDQdvXzFkRZP0k9K0NC/Og2zfvs8YKvcAUDZ2Wo4IaEYDSxVEeQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR09MB7115
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/X06LE7aK6FC53ieHFNu1K974HJk>
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: Fri, 16 Oct 2020 01:49:41 -0000
Hi Job, Thanks for your comments, I removed some overhead to only focus on your technical review. I added [ob] in front of all my inline comments. 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. [ob] You are correct that in this example, B does not gain anything from A. Said [ob] that, once B validates and selects the route for instance using the EBGP2 path [ob] and not the route it learned from A, it then will forward the route to A [ob] and A can receive and use the validation state it learned from B. [ob] Here the operator also has a means of analyzing what happened. Draft-sidrops-bgpsec-validation-signaling is not a replacement or alternative to the RPKI-To-Router protocol. [ob] We never said that draft-sidrops-bgpsec-validation-signaling is a [ob] replacement for rpki-to-router. In fact both have a completely different [ob] task to perform. This draft only signals the validation state a router [ob] calculated to its peer. RPKI-to-router provides ROA information and BGPsec [ob] public keys to the router. Two completely different tasks. If the meaning of the 'unverified' state is 'maybe I will do validation later, maybe not', I don't see any practical application. [ob] If the router is overloaded it might perform lazy evaluation "defer the validation" [ob] See RFC 8205. If the meaning of 'valid' is to be taken at face value, again, there is no value in a standardized community, see RFC 3514. [ob] The meaning of the validation state 'valid' is defined in RFC 8205 which we [ob] defer too in this draft. 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? [ob] Dropping an invalid route is local policy so one might decide to not drop an [ob] invalid route but low-pref it instead and select if no other path is available. [ob] Also, there are still the two other situations left, 'unverified' and 'valid'. 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. [ob] In this case you would have a 'invalid' compared to an 'unverified' route. [ob] I believe this is local policy. One could 'low-pref' the route. See it [ob] from the other side. Let's say A received the route, validated and the [ob] result is 'invalid', now it receives the route via IBGP from B, this time [ob] as 'unverified' because as you mention B defers validation. Now A does [ob] perform validation and validates it as 'valid'. In this case A send a [ob] withdrawal to B for the A(EBGP) route and both A and B will use B's route. [ob] Even though only A knows it is valid. 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. [ob] I know, the receiver does not know why a route was not verified. And the [ob] reason does not change anything on the outcome. Said that, 'temporarily deferment' [ob] would be a most likely reason for not validating in the first place as [ob] mentioned in RFC 8205. The important part here is to signal that it was [ob] not validated at all. 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! [ob] I disagree with your "implication" statement. Not every router is required [ob] to support this extension and as stated in the draft, the usage of this [ob] attribute is configurable on a per peer basis. 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. [ob] The draft clearly states to have no combinations of this community string [ob] in the same UPDATE, so I do not follow your point here. If more than one [ob] instances of the attribute are found then all MUST be discarded. The argument [ob] that implementations have issues with error handling does not hold. I'm sorry [ob] but as someone who worked on many software implementations over the years [ob] this is not really a very convincing argument...... 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. [ob] Not necessarily, using your topology from above, B receives the update from A. [ob] Let's assume for a moment A did validate and B is low on resources and decides [ob] to defer the validation. Here, it receives a validation result from A and uses [ob[ it until B gains back resources and starts validating all remaining routes it [ob] did defer earlier. It eventually will validate the UPDATE it learned from A and [ob] B will use its own validation state, going forward. [ob] Regardless that the end goal is that every single router performs its own [ob] BGPsec path validation, there are moments, where a router will defer this task. [ob] That is why also RFC 8205 added that section. [ob] Next to load processing, this attribute also allows validation analysis. It [ob] makes it easier when analyzing the traffic to see the validation result of each [ob] router. Here a well-defined attribute allows early integration into third party [ob] tools such as Wireshark or others. 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. [ob] As developer of one of the reference implementations I think differently. 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. [ob] I don't really want to talk about RFC 8097 here but where you bring this up, [ob] let me say that your statement of "successful execution" which I think you [ob] mean in regards to performing the validation algorithm is incorrect. [ob] RFC 6811 clearly states that in case a router chooses not perform origin validation [ob] the router SHOULD assign "not-found" to the route, which in my opinion [ob] contradicts the definition of "not-found". Out of that reason, I proposed at [ob] IETF 103 in Bangkok the introduction of the validation state "unverified" to RFC 6811. [ob] But this discussion is out of scope for this draft. [ob] Nevertheless, in case I can interest you: https://www.ietf.org/proceedings/103/slides/slides-103-sidrops-proposing-validation-state-unverified-00 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. [ob] Consider the following two received routes: [ob] Both routers peer with 1 & 8 [ob] R1 {1,2,3,4,5,6,7,p1} [ob] R2 {8,9,p1} [ob] BPV(A,R1) means BGPsec Path Validation for route R1 at router A. [ob] Policy: Drop 'invalid'. [ob] Validation: [ob] BPV(A,R1) = deferred [ob] BPV(A,R2) = deferred [ob] BPV(B,R1) = valid [ob] BPV(B,R2) = invalid [ob] A defers BPV and selects R2 (shortest path). [ob] B on the other hand does perform path validation and selects the [ob] longer valid route R1 over the shorter and invalid route R2. In fact [ob] B ignores R2. [ob] Now without the validation state communicated from B to A, A never [ob] will know that it selected an invalid route - or more important with [ob] R2 being valid and therefore more desirable, if A in case of the validation [ob] signaled would learn of the validation state for R2 could use policies [ob] that selects 'valid' over 'unverified'. [ob] And yes, there are plenty of values available to craft custom community [ob] values. And if this draft will not proceed that is what might happen. [ob] But that would be a big loss, wouldn't it. Why do we standardize, so that [ob] we do not need to hand craft each and every thing. I strongly believe, [ob] mechanisms like BGPsec, same as RPKI do need standardized communities. [ob] They not only allow the vendor to provide an interoperable operator [ob] friendly functionality, they also allow third party vendors to create [ob] generalized filters in monitoring software without the need to always [ob] creating hacks. And as I understood from your earlier comments, communities [ob] are a good tool for early adopters - Especially like BGPsec. Even more [ob] if commercial available monitoring software can filter for them and [ob] provide useful functionality to operators. [ob] Even though, BGPsec itself only provides the validation results 'valid' and [ob] 'invalid' - actually it is "Not Valid" but let's stay with 'invalid', [ob] what does this mean in a BGPsec world with drop invalid. We only see valid [ob] updates? Of course not - especially if the router needs to defer validation [ob] due to heavy load. Then what? There is no binary 'valid' or 'invalid'. [ob] Every time a router receives a route and defer validation, NO assumption [ob] assumption on the validation state must be made. You said that yourself! [ob] So the more knowledge is communicated, the better. [ob] So, In my opinion, I do see a very big value in this community attribute. [ob] It provides an additional data point for route selection - especially during [ob] heavy loads. [ob] Again, this community attribute not only communicates "valid" and "invalid", [ob] it also communicates "unverified". And that in itself is a very good mechanism [ob] to prevent incorrect assumptions about the validation state of a received [ob] route. 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 [ob] I hope my explanations above helped to clarify your concerns and helped changing [ob] your view on it. Others did show value and I hope you can join. 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 [ob] The argument that this attribute has no place because there are not [ob] enough implementations out there does not make sense to me at all, [ob] especially as implementer of one of the open source reference implementations [ob] of BGPsec. anyhow. Using communities is no substitute for BGPsec validation or for RTR, this document may subtly lead people to believe otherwise. [ob] RTR? Do you mean RPKI-to-router as mentioned above? In that case, it has [ob] nothing to do with that. [ob] This document is in no form a replacement of BGPsec path validation - I [ob] completely agree with you on that. It is a very helpful tool to allow [ob] routers to not break down during heavy loads, make usage of deferring [ob] validation until the load on the router goes down but still make usage [ob] validation state it learned from its peer until own validation can be [ob] performed. It is possible I misunderstood things, I look forward to feedback from the group. [ob] I hope I could clarify some misunderstandings and concerns, Kind regards, Job ps. nitpick: one of the author's company names seems misspelled. [ob] Thanks, [ob] I will fix that, [ob] Oliver 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. > >
- [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)