Routing, Trust & RPKI.

by Leo Vegoda

Above: Francis Greenway on the front of Australia’s $10 banknote, circulated from 1966 to 1994

Issuers have given important documents, like paper money, more security measures over time. There’s a constant battle against forgers like Francis Greenway. Issuers face the risk that people will reject legitimate documents when they cannot distinguish them from fakes. Users face the risk that they accept a forgery or reject a real document, losing value in both situations.

Banknotes are a mechanism for communicating value between participants in a transaction. They are one set of identifiers used in the baking system. Traders might decide to reject customers who regularly supply fake banknotes.

That said, recent research notes that “people accept banknotes […] without consciously verifying authenticity.” Checking the validity of each dollar bill given in change might not be necessary. But as Suzanne Massie explained to Ronald Reagan, we can, “trust but verify.”

That’s why cashiers will sometimes run a banknote under a UV light or mark it with a special pen. Modern banknotes have a variety of security features that allow users to check that they are real.

But it’s not practical to check every banknote in a fast-paced retail environment. Low denomination banknotes arriving in the morning are likely to go out as change that same day. The cost of verifying each note manually means that retailers often have policies to only check banknotes above a certain value.

Forged Letterhead?

For many years it was standard practice to require a Letter of Authorization when announcing IP address space for someone else. For instance, researchers measured the unauthorized use of unallocated IPv4 addresses in the runup to the last IANA allocations. They asked for Letters of Authorization (LOA) to use the addresses they would use for the research.

The researchers, the RIRs, and the networks announcing the addresses knew each other. But networks don’t always know their customers. They have to trust the paperwork.

The paperwork for a LOA is much easier to forge than a banknote. No-one expects security features like a hologram. In 2016, APNIC’s Chief Scientist, Geoff Huston described the process as, “a matter of ASCII artwork.” He went on to say that it is, “no surprise that this practice is being abused by address hijackers.”

Verifying legitimate control of IP addresses was hard to do. But the impact of not verifying is significant.

People notice both hijackings and ‘fat fingers’ events – i.e. errors. Most of the time, the authorized user of the resources notices: they get less traffic. But the rest of the internet notices, too. These events get written up by non-profits and multiple commercial services.

Why Do We Have a Problem?

The routing protocols we rely on today were developed in a much friendlier environment. NSFNET, which grew into the internet, allowed commercial traffic in 1991. This is the same year the initial BGP protocol description stated that “Security issues are not discussed in this memo.” BGP is the routing protocol that ties the internet together.

Its protocol developers probably did not anticipate that their designs would still be in use more than 30 years later. But they did anticipate that networks would want some level of control. In an accompanying document they noted that political, security, or economic considerations might influence interconnection policy. And that “policies are provided to BGP in the form of configuration information.”

We now have 18 routing registries where organizations can publish their policies in a standard format. This proliferation creates a complex environment. People ask for advice on discussion forums when they get confused. When they get things wrong, they can end up disappearing from the internet or attracting traffic they don’t want.

Some of this can be fixed by automating verification.

Cryptographic Security

We’ve talked about the slow deployment of the Resource Public Key Infrastructure (RPKI) before. This is the technology that allows network operators to sign digital certificates that communicate very simple policy statements about IP addresses. At the moment, these have three elements:

  • This block of IP addresses
  • Can be announced by this Autonomous System Number
  • And smaller parts can or cannot be announced

Each of the RIRs has a portal for managing certificates and the objects they sign, along with places to publish them.

Because RPKI uses cryptographic certificates, organizations now have a much better tool than old fashioned LOAs. No amount of ASCII artwork can trick software into validating a bogus certificate. And because RPKI uses standard cryptography, validation can be automated.

If LOAs are the equivalent of paper banknotes, RPKI is like Chip-and-PIN card payments.

We call the object that connects a block of IP addresses with a network’s Autonomous System Number (ASN) a ROA. That is a Route Origin Authorization. It also allows the network to communicate if it will announce a smaller part of the address block, known as a more specific route.

An ROA certifies the link between IP addresses and the network that can use them.

Address holders can create ROAs authorizing their transit provider to announce their address space. They can also create a ROA for a big block of addresses while allowing announcements of smaller parts of the address block – the more specific route.

Other network operators can automatically validate these certificates and the objects they sign. They can use the results of the automatic validation when implementing policy in their router configuration. This automated validation limits the risk posed by both address hijackers and fat fingers incidents.

The Future

RPKI can be a part of increasing trust on the internet because it enables automation and is chained back to the IP address registries.

One element is implementing what we already have: ROAs. These let you validate that the network announcing addresses is authorized to do so. Another part of it is updating the routing protocol itself. BGPSec is an extension to BGP that validates the whole path a packet takes.

Implementing BGPSec will take years because it requires routers to get new cryptographic certificates. Large networks have thousands of routers and that’s a lot to manage.

It will also require significant development by the RIRs as most organizations rely on their hosted RPKI services.

In the meantime, the RIRs are planning to implement RSC. This is a technology that will let you sign any file with your RPKI digital certificate. It will make it easier for partners, suppliers, and customers to validate that the organization controlling the IP addresses is also the organization buying transit, connecting to an IXP, or agreeing to peer with you.

As we move away from trusting beautifully designed pieces of paper and towards cryptography, we also need to put more trust in the organizations that issue the new digital certificates. Their management of the trust anchors must be verified. That’s why the RIRs are investing in audits.

This is the manual element our automated trust architecture is chained back to.

What Can You Do?

You can watch the RIPE NCC’s free webinar on BGP and RPKI. This will introduce you to the technology.

You can also look at implementing tools to reject BGP announcements that don’t match up with RPKI certificates. APNIC has published a guide to doing this. And the shared RPKI documentation site lists relying party software tools and when they were last updated, so you know the tool you choose is being maintained.