• Securing Inter Domain Routing with RPKI

 
 
Print Friendly, PDF & Email

Problem definition

The debate over challenges and solutions for Secure Interdomain Traffic Exchange is hot as ever these days. The obstacle lies in the fundamental principle of BGP – mutual trust between network operators. Unfortunately, though this principle has led to a number of incidents in the industry, to the public eye only the tip of the iceberg is visible. The results of these incidents are traffic redirection, eavesdropping, DoS attacks and black-holing, to name a few. While incidents number in thousands, the underlying issues are only a few, and vary between accidental route leak through intentional prefix hijack and sophisticated attacks as demonstrated by Kapela and Pilosov. All of these attacks are possible because BGP does not have a default mechanism for its own control-plane protection.

Norms, Standards and Propositions

To mitigate this issue the best practices for secure operating of BGP has been developed and published in vendor-neutral resources: Mutually Agreed Norms for Routing Security (MANRS) and Special Publication on SIDR by NIST. These useful materials describe everything included in current BGP standard from prefix filtering and communities, to policy enforcement best practices. Along with the traditionally available tools, there are a number of new propositions which are in IETF draft state at present:

  • Introduction of BGP roles which are negotiated during BGP session establishment
  • Optional non-transitive attributes to prevent route leaking
  • Optional transitive attributes for route leaking detection

As regards route leak prevention there is a huge gap in efforts to authorize the origin of a prefix. While Secure Origin BGP was proposed to address this more than 15 years ago, it involved publishing  information about BGP connections and verifying that a peer has a valid path to the advertised prefix. However, some drawbacks like a problem with implementation on Internet exchange (IX) points did not allow this to be deployed in production.

Another recent proposition involves introducing to RPKI a new object. This object would attest which ISPs a given customer has authorized to propagate its prefixes. However, this does not work for announcements from a provider to a customer. This leaves the door half open for route hijacks.

RPKI

We touched on RPKI, what is that?  It is nothing else but a hierarchical system of public keys based on x.509 with extensions. The basis of this technology is Route Origin Authorization (ROA) – a signed statement about which AS is authorized to originate the prefix in BGP. These ROAs are populated in the databases of all Regional Internet Registries (RIRs). RPKI helps with route leaks but malicious hijacks are still possible: anyone can prepend a valid AS to forge the route announcements. Since databases are populated manually, there is also a human factor playing role here which affects database consistency. There are also some legal issues affecting the deployment of the feature in some parts of the world.

Malicious hijacks as a Service

Prefix propagation and AS-path validation BGPSec RFC8205 was introduced and became a standard in 2018. It works the following way:

  • A prefix has to have a signed ROA in the RPKI database
  • AS1 which originates the prefix signs the advertisement with its own private key and puts a stamp that it is intended for AS2
  • Every consecutive AS on the path will validate the ROA, signature and sign the further advertisement
  • When AS5 receives the advertisement checks the ROA, i.e. validates AS1 as a source and also validates the entire AS path
  • If AS6 decides to fake the connection to AS1 and forge the advertisement from it and announce it to AS5
  • AS5 will be able to determine that AS1 has never signed the advertisement to AS6 and AS6 will drop the forged announcement

Unfortunately, up to this point this technology didn’t start adoption cycle for a number of reasons, the most important being:

  • Computational burden on route processor
  • As each NLRI has to be carried in it’s own update, the update message has to traverse the same AS sequence as contained in the message
  • De-peering, legal challenges, private key per-AS or per-Router handling and likely some others

Fixing RPKI

To address the challenges of RPKI, another approach was introduced: DISCO – Decentralized Infrastructure for Securing and Certifying Origins. It is based on an automated approach of de-facto verification of reachability of the prefix via the announcing AS. An entirely new infrastructure is being utilized here including vantage points, registrars and repositories.

However, this approach has at list one flaw – an adversary may interrupt the certification cycle by simply starting announcing the same prefix. This will prevent legal owner of the prefix to obtain certification, which in fact is a DoS.

Conclusion

To conclude on the review of the existing and newly proposed tools which help with current BGP control-plane attacks and incidents: none of the existing tools separately can address all of the issues and all of them have pros and cons. We will likely have to implement some combination of them in the network to keep it stable and safe.

However, the core technology for all of the tools is common – RPKI. Major players in the field are already not only populating the RPKI database, but also verifying the announcements based on ROA and enforcing policies based on the results. RIPE NCC held the RPKI deployathon back in March 2018 and there is very good learning material online from this effort.

From Words to Action

Let’s take a look at how you can deploy RPKI on your network with Arista EOS. For example, consider two ASs peering and exchanging routing information of their own networks only, and to keep it simple let’s consider only one router per AS. Only one peer will perform ROA validation with the Routinator – the open source RPKI Relying Party software.

Disclaimer: all prefixes, ASNs and names of the objects are used just for demonstration purposes and have nothing to do with real life

Peer in the first AS:

service routing protocols model multi-agent
!
router bgp 1
no bgp default ipv4-unicast
neighbor 5.5.5.5 remote-as 6805
neighbor 5.5.5.5 maximum-routes 12000
neighbor 2a02:3031::1 remote-as 6805
neighbor 2a02:3031::1 update-source Ethernet32/4
neighbor 2a02:3031::1 maximum-routes 12000
!
address-family ipv4
neighbor 5.5.5.5 activate
!
address-family ipv6
neighbor 2a02:3031::1 activate
!
rpki cache 10.92.62.23
host 10.92.62.23 port 3323
!
rpki origin-validation
ebgp local
ebgp send

Peer in the second AS:

router bgp 6805
no bgp default ipv4-unicast
neighbor 5.5.5.6 remote-as 1
neighbor 5.5.5.6 maximum-routes 12000
neighbor 2a02:3031::2 remote-as 1
neighbor 2a02:3031::2 maximum-routes 12000
redistribute connected
!
address-family ipv4
neighbor 5.5.5.6 activate
network 5.4.0.0/14
network 89.199.0.0/17
!
address-family ipv6
neighbor 2a02:3031::2 activate
network 2a02:3031::/38
network 2a0d:e680::/29

Since we configured RPKI cache and ROA validator, let’s see what’s the status of the session:

R1(config-router-bgp)#show bgp rpki cache
10.92.62.23:
Host: 10.92.62.23 port 3323
VRF: default
Refresh interval: 3600 seconds
Retry interval: 1 seconds
Expire interval: 7200 seconds
Preference: 5
State: synced
Last update sync: never
Last full sync: 0:01:15 ago
Last serial query: never
Last reset query: 0:01:26 ago
Last config change: 0:06:51 ago
Total entries: 118841

We are in sync, perfect, let’s see what routes received from R2 are valid, which are not valid and which are unknown:

R1(config-router-bgp)#sh ip bgp
BGP routing table information for VRF default
Router identifier 1.0.0.1, local AS number 1
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI Origin Validation codes: V - valid, I - invalid, U - unknown
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

Network Next Hop Metric LocPref Weight Path
* > V 5.4.0.0/14 5.5.5.5 0 100 0 6805 ?
* > I 5.5.5.0/24 5.5.5.5 0 100 0 6805 i
* > U 10.31.100.0/24 5.5.5.5 0 100 0 6805 i
* > U 10.31.253.249/32 5.5.5.5 0 100 0 6805 i
* > U 10.83.13.0/24 5.5.5.5 0 100 0 6805 i
* > I 89.199.0.0/17 5.5.5.5 0 100 0 6805 ?

Let’s see why some of the received prefixes are not valid:

R1(config)#sh bgp rpki roa ipv4 89.199.0.0/17
Prefix Max Length ASN
------------------ ----------- -----------
89.199.0.0/17 17 197207
89.199.0.0/16 16 197207
89.198.0.0/15 17 197207

Here we see that the origin of the prefix 89.199.0.0/17 is not matching with data in RPKI DB, i.e. originator of the advertisement is AS6805 while the real owner is AS197207

R1(config)#sh bgp rpki roa ipv4 5.5.5.0/24
Prefix Max Length ASN
------------------ ----------- -----------
5.4.0.0/14 14 6805

Here we see that AS6805 is signed to advertise only prefix /14, hence more specific advertisement /24 is not valid.

What about IPv6?

R1(config-router-bgp)#sh ipv6 bgp
BGP routing table information for VRF default
Router identifier 1.0.0.1, local AS number 1
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI Origin Validation codes: V - valid, I - invalid, U - unknown
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

Network Next Hop Metric LocPref Weight Path
* > V 2a02:3031::/38 2a02:3031::1 0 100 0 6805 i
* > U 2a0d:e680::/29 2a02:3031::1 0 100 0 6805 ?

R1(config)#sh bgp rpki roa ipv6 2a0d:e680::/29
Prefix                                            Max Length  ASN
------------------------------------------------- ----------- -----------

In this case, we see that the prefix 2a0d:e680::/29 is not signed, hence route-origin validation status is – Unknown.

Great, we are able to distinguish between the routes based on the validity of the received BGP updates and data in RPKI database. What can we do about routes with invalid or unknown origins? We can deprioritize these routes or not accept them at all, for example. Let’s take a look at the example of an inbound route-map which will deny invalid routes:

route-map sk deny 1
match origin-as validity invalid
!
route-map sk permit 2
match origin-as validity not-found
!
route-map sk permit 3
set origin-as validity valid

BGP RIB output looks if we apply this route-map on inbound to our peer on R1:

R1(config)#sh ip bgp
BGP routing table information for VRF default
Router identifier 1.0.0.1, local AS number 1
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI Origin Validation codes: V - valid, I - invalid, U - unknown
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

Network Next Hop Metric LocPref Weight Path
* > V 5.4.0.0/14 5.5.5.5 0 100 0 6805 ?
* > U 10.31.100.0/24 5.5.5.5 0 100 0 6805 i
* > U 10.31.253.249/32 5.5.5.5 0 100 0 6805 i
* > U 10.83.13.0/24 5.5.5.5 0 100 0 6805 i

As expected, invalid routes are not accepted – validation is done successfully.

Note: Functionality of RPKI ROA and RPKI cache on Arista EOS is scheduled for a release in the near future.


Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: