RPKI In BGP

As BGP plays an important role in the backbone infrastructure, it is important to secure it, so as to ensure for every router the validity of learned prefixes.

There are different methods to secure exchanged BGP prefixes. The one that is presented here is a method that relies on a server/client model. The server is part of an RPKI, as it stands for a trusted cache server. The client is a BGP device that initiates a specific connection to the server, where Route Origin Authorizations (ROA) are stored, and downloads them. Subsequently, any device can do prefix origin validation by referring to that server storage.

The specific connection done between a BGP device and the server cache uses a standard mechanism that maintains the exchange of the prefix/origin AS mapping between the cache server and routers. This is the RPKI protocol defined by RFC 6810.

RPKI Cache Configuration

RPKI/RTR cache configuration is made up of a list of servers indexed in order of preference; the lowest index representing the most preferred connection that will be tried to sync with. If the server is not reachable, then the next server with the closest preference is tested; and so on, until the connection succeeds and the resync mechanism applies.

RPKI/RTR protocol may optionally run over a secure connection. For that, an encryption protocol should be set on both ends (on the server and the client), with the appropriate keying material and authorizations.

An example of cache-server configuration for RPKI looks like the following:

vsr> show config nodefault / vrf customer1 routing bgp rpki
rpki
    cache-server 1 address XXX.XXX.XXX.XXX tcp port xxxxx
    ..

To check if the RPKI/RTR connection did succeed, use the following command:

vsr> show bgp rpki cache-connection vrf customer1
Connected to group 1
rpki tcp cache XXX.XXX.XXX.XXX xxxxx pref 1

It is possible to dump the prefix table by using the following command:

vsr> show bgp rpki prefix-table vrf customer1
host: XXX.XXX.XXX.XXX port: xxxxx
RPKI/RTR prefix table
Prefix                                   Prefix Length  Origin-AS
1.180.0.0                                   14 -  14         4134
[..]
2a01:c000::                                 19 -  48         5511
2003::                                      19 -  19         3320
Number of IPv4 Prefixes: 90631
Number of IPv6 Prefixes: 15573

vsr> show bgp rpki prefix-table 91.223.245.0/24 vrf customer1
Prefix                                   Prefix Length  Origin-AS
91.223.245.0                                24 -  24        48415

It is also possible to remove the RPKI/RTR synchronization either by removing the cache server entry, or by removing the whole RPKI configuration:

vsr running config# del vrf customer1 routing bgp rpki

It is possible to set a specific source address for the RPKI cache server access.

vsr> show config nodefault / vrf main routing bgp rpki
rpki
    cache-server 1 address 1.1.1.1 source 2.2.2.2 tcp port 1234

RPKI Crypto Material

The Virtual Service Router offers the possibility to secure an RPKI/RTR connection using SSH. For that, the cache server must be set as an SSH server, with the appropriate authorizations and users; and the client must have a public/private key in order to authenticate to the server without interactively typing a password.

The cryptographic keys can be generated from the CLI as follows:

vsr> cmd bgp rpki ssh-key create name keyfor_rpki type rsa-4096

Asymmetric key can either be RSA, ECDSA or EDDSA, and are indexed by a keyword. It is possible to configure some parameters like key length for RSA (1024, 2048 or 4096 bits), or ECDSA (256, 384, or 512 bits). However, EDDSA is not customizable, and its key length is automatically set to 25519 bits.

Keys stored in the system can be listed with:

vsr> cmd bgp rpki ssh-key list
keyfor_rpki

Public keys stored in the system can be displayed with:

vsr> cmd bgp rpki ssh-key list detail
keyfor_rpki
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDM3lBagZttpcBmZUNsoaka4/WigSgZkAj5msHhqV4f/95e/6GCFzCi/1EyTxRWk+eNPJfQb8lHh/+edLqHpmSOzwyV9qjf2y09vbAODkhoHhH23UBBu3KvweUpvXnfj4aQlqdssHLE9td1MtlNBrPXvzA1aKzzGQ1lFeNvN5z4YswgQfVWPCZFV6yyHdUgTICIAVmT6Pjpdk1YjkT4IKvQegJe90iJRtQI8jIeUDzrMpoa0iTvDh1tClLr81yJcUf2idzQ79b9B865Z0ieHyxgXuTbD+wcmHfGkTzUy4XpbUC8W6pSL/CSKFSl6RUHN3esPVV8I+tZT3MVYxRP91NRutESabuahyif+v2CxVngaqhjcrGlIiVK7BuZBpXTHUit7fKMfwx9XxIhhls+ufAyIlGDmmPb3J6oqP7xgoivxgN2Jkl425+XCd3LpOozo9wRpcfOQeLhfVHT/eo5EN0RN8lpN+fFCyVuI8V3r2Qds80lwVP03GHEzNc+gsKEbnp5ghM543ChfjoUtTGIbzN5fW/Nf0m+VLV6nWmZ7890Zx6d5qFqShLCPZ3GEenzJ/R5wZA9U+l/LbtnWJW9jwPYUfMbzsm0BeAKl5KiHhhOQMRnc/HOc1shD+R6zgQdMn35kdjapXSnFK2yBqb/4xw5tlP8GbOAslP9yewpq4qjTw== root@vrouter

And can be deleted using:

vsr> cmd bgp rpki ssh-key delete keyfor_rpki

The public key should then be copied to the SSH server’s list of authorized_keys, under a user account created for RPKI/RTR connections.

In addition to forging local key material, it may be necessary to learn the public keys of remote servers. This can be done using the following command that populates the database with the keys of all the SSH hosts:

vsr> cmd bgp rpki ssh-host add XXX.XXX.XXX.XXX port xxxxx vrf customer1

In case it is necessary to flush entries associated to a particular host from the local database, the following command can be used:

vsr> cmd bgp rpki ssh-host delete XXX.XXX.XXX.XXX

Once the underlying SSH connection can be established from client to server using the newly generated keys, the secure RPKI/RTR connection can be set like below:

vsr running config# / vrf customer1 routing bgp rpki
vsr running rpki# cache-server 1 address XXX.XXX.XXX.XXX ssh port 22 key keyfor_rpki user-name rpki-user
vsr running rpki# commit
Configuration committed.
vsr running rpki# show bgp rpki cache-server
host: XXX.XXX.XXX.XXX port: 22 username: rpki-user server_hostkey_path: /var/lib/yams/routing/known_hosts client_privkey_path: /var/lib/yams/routing/keyfor_rpki
vsr running rpki# show bgp rpki cache-connection
Connected to group 1
rpki ssh cache XXX.XXX.XXX.XXX 22 pref 1

RPKI Miscellaneous

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

vsr running config# vrf customer1 routing bgp rpki retry-interval 400

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 by issuing the following command:

vsr running config# vrf customer1 routing bgp rpki expire-interval 7500

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 by issuing the following command:

vsr running config# vrf customer1 routing bgp rpki polling-period 3700

RPKI Validation

Routing decisions can be made based on RPKI route announcement validity. They are implemented at BGP neighbor level, by the means of a route-map, applied to the ingress direction. The keywords rpki valid, rpki invalid or rpki notfound can be invoked in a given route-map sequence, thus triggering a policy when matched.

The below example depicts what can be done in order to accept valid prefixes; reject invalid prefixes; and set a low local preference to unknown prefixes, as they cannot be fully trusted.

routing
   route-map rmap
      seq 1
         policy permit
         match rpki valid
         ..
      seq 2
         policy deny
         match rpki invalid
         ..
      seq 3
         policy permit
         match rpki notfound
         set local-preference 20
         ..
/ vrf customer1
   routing bgp
      as 1
      neighbor 10.1.1.11 address-family ipv4-unicast route-map in route-map-name rmap