Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018

Nick Hilliard <> Tue, 04 September 2018 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0322B131029 for <>; Tue, 4 Sep 2018 16:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TBVzxOg9sfk5 for <>; Tue, 4 Sep 2018 16:03:31 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86AAD13104D for <>; Tue, 4 Sep 2018 16:03:31 -0700 (PDT)
Received: from crumpet.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w84M3PCe062318 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2018 23:03:25 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be crumpet.local
To: Christopher Morrow <>
References: <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Wed, 05 Sep 2018 00:03:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Sep 2018 23:03:41 -0000

Christopher Morrow wrote on 04/09/2018 16:57:> I think restating an 
earlier conversation about this draft (which I
> think was the rpki-light draft name) is useful:
> "The draft aims to provide the ability for a third-party (IXP) to
> validate routes for me, because I can't do that myself"
rather than having a discussion about theoreticals, I set up an RPKI 
cache from scratch on a VM earlier this evening and tied it into an XR 
router connected to an IXP.  The RPKI cache ran on vanilla centos7 with 
the RIPE NCC RPKI validator v3 software.  Here are the installation 
instructions for the validator software:


Two minor additions were made to the 8 commands required to install the 
software and get it running: one to get the rpki-rtr process to bind to 
the public IP address of the server in question, and the second was to 
install the ARIN TAL.

The router was configured to tag and accept invalids.  It took 6 lines 
of copypasta config (3 policy and 3 bgp/rpki) pulled from a couple of 
quick internet searches to do this.

The result of this was a fully operational RPKI PoC which validated 
prefixes on the router immediately.  Embarrassingly, it took longer to 
beat the firewall into allowing access to the rpki-rtr server than it 
did either to configure the router or to set up the rpki validator 
service (this was due to a typo: udp/8323 instead of tcp/8323, oops).

In terms of router stack support, rpki validation has been there for 
years on Junos, IOS-XE, XR, SR-OS, vanilla IOS on some platforms and 
various other commonly-used router stacks.  It's not there on some kit, 
including, for example, vanilla IOS on older non-core-oriented legacy 
kit and Mikrotik RouterOS, which gets a mention mostly because it's 
widely used at IXPs, despite its shortcomings.

Obviously a PoC is not a production configuration, but the point of the 
exercise was to show that the bar for a basic rpki implementation has 
been lowered to the point of it requiring no more than a skeleton linux 
deployment and 8 lines of cut-n-paste from a wiki.  It isn't rocket 
science, and it is widely supported on the sorts of routers that people 
use in production environments, particularly IXPs, i.e. the pool of 
situations where people can't deploy rpki is continuing to shrink and 
there is no real operational need to create standardised hacks for 
situations where it can't be deployed.