Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker
Nick Hilliard <nick@foobar.org> Thu, 15 February 2018 22:48 UTC
Return-Path: <nick@foobar.org>
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 05E9412D96C for <sidrops@ietfa.amsl.com>; Thu, 15 Feb 2018 14:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 27hvr3l0RjZm for <sidrops@ietfa.amsl.com>; Thu, 15 Feb 2018 14:48:47 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70DA127871 for <sidrops@ietf.org>; Thu, 15 Feb 2018 14:48:46 -0800 (PST)
X-Envelope-To: sidrops@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w1FMmfF6063509 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2018 22:48:42 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A860E47.1010003@foobar.org>
Date: Thu, 15 Feb 2018 22:48:39 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.22 (Macintosh/20171208)
MIME-Version: 1.0
To: Aris Lambrianidis <aris.lambrianidis@ams-ix.net>
CC: Jeff Wheeler <jsw@inconcepts.biz>, sidrops@ietf.org
References: <CAPWAtbJJ3mWXP-d314CbY7n9LSh4KmNjXBCP93Ag_i=0gcAd8Q@mail.gmail.com> <5A84B6B8.50207@ams-ix.net>
In-Reply-To: <5A84B6B8.50207@ams-ix.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/YV1WfoxQNiwfOjtKIY1d6YJjRxM>
Subject: Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 15 Feb 2018 22:48:50 -0000
Aris Lambrianidis wrote: > I see two prongs in your email, a technical one (signalling method) and > a "political" one (for > lack of a better term), i.e. whether this draft is misguided in principle. >From the bigger picture point of view, this draft is about trying to make rpki accessible to operators, and builds on ideas first presented in draft-ietf-sidr-origin-validation-signaling / RFC8097, which applies to iBGP-only routing environments. Stepping back a bit and looking at this problem, on almost every bgp routing platform, rpki policy hooks have been implemented in a way which makes deployment of rpki quite straightforward. These hooks rarely constitute more than a couple of lines for cache configuration, and simple grammatical constructions for rpki policy matching. In other words, the router side of things is pretty easy. The single item which makes rpki deployment troublesome is operating an rpki cache or set of caches. If you want to deploy RPKI validation caches, there are several options available: some of the RIRs already provide a hosted rpki validator service, and RIPE NCC provides open source software with a GUI. rpki-validator v2 is available now, and v3 is in the works with a planned release date some time this month. I.e. this is software which is used already in operational environments, and which is under full development support. This means that the bar for pushing out a full rpki deployment using actual caches is not very high in practice. In the one case, all you need is to create an online account and the whole lot is done for you, albeit using an infrastructure which you probably wouldn't want to use as a long term arrangement due to the fragility of depending on off-net infrastructure (conversely noting that the rpki cache validation mechanism is designed to be tolerant of situations where the cache is unavailable). In the other case, you need a VM or a deployment of VMs and an amount of time and patience which is going to end up being directly proportional to the scale of the deployment that you want to build out. Neither option involves rocket science, but both will provide real RPKI, bells and whistles attached. draft-ietf-sidrops-validating-bgp-speaker proposes to replace actual RPKI with a synthetic flagging mechanism. What's lost here is: cryptographic authenticity, all the rpki validation policy hooks on routers, and because this draft addresses ebgp rather than ibgp, we have the extra complication that any upstream processing which involves multiple bgp paths will also involve bgp best path selection, i.e. the upstream is necessarily getting into the business of making implicit routing decisions for the downstream without providing any of the hooks that the downstream bgp speaker might want to use. In one sense, this draft is not even about making rpki more accessible: it's about how to translate a subset of rpki features into existing policy methodologies, so that the operator doesn't need to use an rpki cache. The proposals in draft-ietf-sidrops-validating-bgp-speaker need to be broken out into two separate sub-cases of multilateral ebgp (i.e. route servers), and bilateral ebgp (i.e. normal bgp interconnection). For all ebgp implementations, the moment you examine a community that comes in over ebgp, you're implicitly trusting your peer to sanitise that community for you. In other words, because there is no cryptographic authentication of the rpki state of the prefix, you're depending on something which is no more or less reliable than hearsay and which can be easily faked by tacking on an illegitimate community and depending on misconfigured routers to forward the attribute. Route servers present a particular complication because they are a 90% solution to the problem of how to interconnect with lots of other organisations at an ixp, with all the massive simplifications that a 90% solution implies. The conceptual difficulty with route servers is that unless they provide add-path tx support (i.e. forward all prefixes to rsclients so that the clients can make their own decisions about what to do), they will perform bgp best path selection on behalf of their clients, i.e. forward a single prefix, losing information in the process. Job suggests that RPKI invalids should be dropped. There might be sound reasons to hold this opinion, but someone else might demand that RPKI invalids be depreffed instead. This outlines a fundamental difficulty: without add-path tx support, the route server is touching the RPKI problem and making explicit policy decisions on the basis of RPKI validation results. The problem with this is that rpki is subtle enough that if you're going to want to deploy rpki at all, you probably want enough policy manipulation hooks to get it to do what you want, not what someone else decides for you. These hooks would ideally need to specify what to do with invalids, and unknowns and how to apply various different attributes to them (e.g. tag, change localpref, change metric, drop, keep, etc). This sort of policy management needs to be handled from the route server provisioning system, ideally dynamically so that client operators don't need to prod the route server operator to make updates whenever they want their policy changed. If this is not present, then the route server is cooking up a bunch of results based on a stated / implicit policy, but where the rsclient has no means of inspecting all possible paths to make their own decision about what to do with them. As a further complication, the community mechanism proposed in this draft requires code changes on the rsclient to make it work at all. This is because generic extcomm support on routers doesn't usually exist. This can't really be fixed by moving to bilateral peering because if you move to bilateral, you're going to lose the community support proposed by this draft, i.e. your peer at the IXP or on PNI probably isn't going to support this draft. This means that if you want RPKI, you're back to square one: you will need to set up your own cache anyway. The comments in this email https://www.ietf.org/mail-archive/web/sidrops/current/msg00035.html (text search term "tl;dr: route servers and rpki are an uncomfortable fit", date Sat, 14 Jan 2017) are still relevant. In summary, this draft provides a partial workaround for operators who don't want to go to the effort of installing and configuring off-the-shelf RPKI validator software, using a mechanism which will provide arguably incorrect policy decisions in real world situations using systems which they have no control over, which requires code changes on client implementations, which doesn't provide a hook mechanism to allow the operator to use their router's RPKI grammar, and which in the best deployment scenario is only ever going to be possible on a limited set of bgp peering sessions. I can't reconcile this with either good quality protocol definition or sound networking operational procedures. Regarding the argument that this already exists and that standardisation is better than everyone doing their own thing: > Signalling ROA status in route servers is already happening (France IX, > AMS-IX), for better or worse. > The question then now becomes, does the community want to consolidate > into one way of doing things or not. Standardising different implementations of a bad idea doesn't make it a better idea. If some IXPs are tagging prefixes on their route server with rpki assessment information, then that's a decision for them to make. I'm sorry if this assessment comes across as being harsh, but given the limitations of what's being proposed, it would probably be more constructive to use the time and effort that would otherwise be spent working on this draft to educate operators about how relatively easy it is to implement native rpki, and that if operators are serious about rpki on route servers, then they will need either add path tx on the route server or else use bilateral peering. Nick
- [Sidrops] Comments on draft-ietf-sidrops-validati… Jeff Wheeler
- Re: [Sidrops] Comments on draft-ietf-sidrops-vali… Aris Lambrianidis
- Re: [Sidrops] Comments on draft-ietf-sidrops-vali… Job Snijders
- Re: [Sidrops] Comments on draft-ietf-sidrops-vali… Job Snijders
- Re: [Sidrops] Comments on draft-ietf-sidrops-vali… Jeff Wheeler
- Re: [Sidrops] Comments on draft-ietf-sidrops-vali… Nick Hilliard