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

[Nick Hilliard <[e-mail]>]

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:

> https://github.com/RIPE-NCC/rpki-validator-3/wiki/RIPE-NCC-RPKI-Validator-3-Production

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.

Nick