RPKI on Junos is easy!

My friend Michael Fincham did a great presentation a few weeks ago at NZNOG on RPKI. I spent a fair bit of time helping him get said presentation ready to go – as we did a bunch of testing on the MX implementation of RPKI. He made a good argument that as a community we are horribly bad at the security of our prefixes. We need to be ensuring we do more than just blindly trust our peers and check that they actually have the right to send us the prefixes they advertise. Of course we are all at some level aware of this, but this verification stuff is hard right… right?….surely?!?…

Michael and I spent some time prior to him doing his presentation playing around with the RPKI on a MX80 in my lab. One of the things that came out of this is how truly easy it is to get a basic RPKI deployment going. To  turn on validation in Junos only requires the following single line of config;

set routing-options validation group some-awesome-rpki-server session

Of course there are a bunch of other options available, such as the priority of different RPKI servers, timeouts, port numbers, source address, etc – but this is not complex stuff to configure….

At this point, you’ll start to see prefixes looking like this (if they are valid);

[email protected]_RPKI_DEMO_MX80> show route
[output omitted]         *[BGP/170] 1w3d 03:59:37, localpref 100
                      AS path: 23655 4648 2914 5511 3215 I, validation-state: valid
                    > to via ge-1/1/8.0
[output omitted]

Or this (if they are not valid);

[email protected]_RPKI_DEMO_MX80> show route
[output omitted]      *[BGP/170] 1w3d 04:01:05, localpref 100
                      AS path: 23655 4648 4134 I, validation-state: invalid
                    > to via ge-1/1/8.0
[output omitted]

Then you can start writing policy that matches on the following;

[email protected]# set policy-options policy-statement abc from validation-database ?  
Possible completions:
  invalid              Match for invalid database validation-state
  unknown              Match for unknown database validation-state
  valid                Match for valid database validation-state

The cool thing about the JUNOS implementation of this is that you take action based on policy – so you can do anything at all with this! This might just be attaching an “untrusted” community, or it might be doing more.

Once concern I had that we spent some time playing around with before his presentation was that verifying each route with RPKI would make the MX take longer to process routes. So we did a bit of testing. We had a MX80 in my lab (and we all know that the MX80 does not have a particularly awesome CPU!) with a full BGP feed from my network. We measured the time it took for the route-table to be populated, plus the time for it to push these routes to the forwarding-table before and after implementing RPKI (with a route policy applied on import from the BGP feed inspecting RPKI attributes). The result was that the load time for the full table increased by 300-400%. This is bad, but not unmanageable – especially if you are not validating the full table – but just a few specific peers.

If you are going to set this up in your network, you are likely going to want to use a local RPKI server. A good place to start getting info on some of this stuff would be the slide deck from Michael’s talk, which can be found here; http://hotplate.co.nz/archive/nznog/2014/rpki/

Please also see the video of the talk here; http://www.r2.co.nz/20140130/michael-f.htm

Another bit of interesting reading is about the deployment of RPKI on the IX in Ecuador of all places! Read here; http://iepg.org/2013-11-ietf88/RPKI-Ecuador-Experience-v2b-1.pdf

One of the key things to note with RPKI is that while it is far from the final solution at this point (few have their routes signed yet), it’s a very good step in the right direction. And for that reason, I think we should all be looking into at least validating our routes, and perhaps assigning a better local-preference to validated routes. Like IPv6, it takes all of us ‘buying in’ to get this to the point where a large proportion of the internet routing table can be successfully validated!

A brief break…

As many of you will have already read, my JNCIE-ENT lab exam is scheduled for Friday 21 Feb 2014 – which is getting quite close now! For more info on what this involves, check out my blog post here; JNCIE-ENT beta exam booked.

I’m going to be travelling over to be in the San Francisco Bay Area from Monday 17 Feb – Saturday 22 Feb in order that I can catch up with various people in that time and recover from the jet lag in time for the exam (which is a tiring experience at the best of times).

As much as the JNCIE-ENT lab exam is a massive undertaking, I am feeling as prepared as I could be at this point – I’ve put in 270 hours of study so far, and will be aiming to put in a minimum of 40 hours per week from this point forward.

I’m also looking forward to attending the NZNOG (New Zealand Network Operators Group) conference in a couple of weeks – this is always a great opportunity to catch up with others in the industry and exchange ideas and thoughts.

Over this time, I doubt I will have sufficient time to post many (if any) blog posts (though I may try to fit a couple of new ones in). I will be attempting to rewrite/reword a couple of my earlier posts that I am not yet 100% happy with yet, plus just keeping my head down and focusing on study! Please forgive me for the lack of new content in these coming few weeks!

Thanks to all of those of you who have taken the time to read the various articles I have posted over the short time I have been blogging – particularly those of you who have been kind enough to provide feedback / encouragement / comments relating to these articles and/or my JNCIE-ENT study :).