RPKI in 6WIND Border vRouter

The main idea behind the Internet Protocol is to route datagrams – packets – from source to destination one hop at a time. As the Internet kept on growing, the « next hop » for an outgoing packet soon had to be calculated dynamically. This means for a router to dynamically « learn » and « advertise » routes from and to its neighbors.

Dynamic routing – with BGP being its embodiment as far as the Internet is concerned – allowed for over a million-entry routing tables to be shared between routers across the globe and, most importantly, updated whenever a change occurs somewhere on the topology. However, it left the door open for some misuses…

For instance, what if a router advertises a prefix that it is not supposed to?

Whether due to a misconfiguration or because the ID of the router was impersonated by a malicious third party, the result will be that traffic targeted at the prefix in question will go through a route it is not intended to. Although this may sound not so dramatic – especially because the Internet Protocol follows the end-to-end principle and doesn’t impose a unique path, even for packets belonging to the same communication – the consequences may be drastic and range from performance loss to Denial of Service, as well as exposure to man-in-the-middle attacks.

To address these concerns a solution exists and is documented in the RFC6480; RPKI- An Infrastructure to Support Secure Internet Routing.

Resource Public Key Infrastructure (RPKI)

This specialized PKI framework is designed to authenticate routes’ origins via cryptographic certificates, thus allowing to create a set of certified authorizations (Route Origination Authorizations – ROA) where it is stated, for each allocated AS, which IP prefixes it is authorized to originate.

A Border Router, or generally any BGP router, can then refer to these ROAs in order to determine a route announcement validity, and make a routing decision. The route announcement validity is « VALID » when the couple <AS – Prefix> is covered by an ROA; « INVALID » when the announced <AS – Prefix> violates an ROA, or when the prefix is more specific than the maximum length declared in an ROA; and « UNKNOWN » when the prefix is not covered by any ROA.

RPKI Support in 6WIND vRouter 3.0 for Border Router Use Cases

6WIND vRouter 3.0, which is our Virtual Border Router software product, comes with a new set of CLI commands allowing it to seamlessly integrate RPKI into the BGP routing process.

It implements RTR (RPKI To Router) protocol allowing it to automatically obtain up-to-date ROAs from cache servers. It also offers the possibility to communicate with SSH-capable cache servers over a secure channel.

Routing decisions related to RPKI can simply be taken using a route map; a set of new keywords is added in order to take actions following the validity of an announcement.

Let’s further explore these features in the below CLI examples.

Referencing RPKI Cache Servers

RPKI is configured per VRF, under the BGP context. The rpki sub-context, allows it to reference one or multiple cache servers – indexed by order of preference – to synchronize with:

The benefit of referencing multiple cache servers is to keep on receiving ROAs even when the main cache server experiences an outage.

Configuring RPKI timers

It is possible to configure the retry interval triggered when a server becomes unreachable. By default, retries are issued every 300 seconds. It is possible to modify this value using the following command:

It is also possible to configure an expiration interval for unreachable servers. The interval is set, by default, to 7200 seconds. It can be modified as follows:

Similarly, it is possible to configure the polling period between two consecutive refreshes, to update the list of prefixes. Default is 3600 seconds. It can be modified using the following command:

The resulting configuration looks like this:

Securing Connections to RPKI Cache Servers

6WIND vRouter 3.0 offers the possibility to secure an RTR connection to a cache server using SSH. For that, the cache server must be set as an SSH server, with the appropriate authorizations and users; and the client (the vRouter) must have a public/private pair of keys in order to authenticate to the server without interactively typing a password.

The 6WIND vRouter 3.0 CLI provides a set of commands to generate, list, or delete the cryptographic keys needed to establish a secure RTR connection. These commands can be leveraged as follows:

The public key of the server can be fetched and, if needed, deleted with:

Finally, in order to reference the SSH cache server, the command line is similar to the one used for regular cache servers, with the addition of references to the private key and SSH user that we intend to use:

Making Routing Decisions Based on RPKI

The 6WIND vRouter CLI offers a rich set of commands to debug BGP services. The “show bgp” command through its different supported options can be used to dump the prefix tables the router handles. It is possible, for instance, to dump the prefix table received by a cache server as follows:

If the vRouter has correctly received the ROAs from the cache server, we can start implementing the routing decisions depending on the route announcement validity.
Let’s say we want to accept VALID route announcements, reject INVALID ones, and accept, while setting a low local preference to, UNKNOWN route announcements.

First, we need to create a route map using the RPKI keywords:

Then, we have to apply this route map to the relevant BGP neighbors, in the ingress direction:

Conclusion

These were the RPKI key features implemented in our new 6WIND Virtual Border Router. With RPKI support, you can secure your routing infrastructure without having to introduce significant changes to your BGP configuration. The multi-cache-referencing mechanism allows for simple editing and redundancy. Fine tuning of cache parameters and adding an encryption layer to RTR communications are available with one idea in mind: they should be as simple as possible for rapid deployment and ease of use. Please visit our website for full documentation; and register here to enter our obligation-free Evaluation Portal to test Virtual Border Router for yourself.

This blog is written by Adonis Baazaoui from 6WIND’s Support Team