Donate
RIRs Enhance Support for Routing Security Thumbnail
‹ Back
Improving Technical Security 25 February 2019

RIRs Enhance Support for Routing Security

Kevin Meynell
By Kevin MeynellManager, Technical and Operational Engagements
Aftab Siddiqui
Aftab SiddiquiTechnical Engagement Manager for Asia-Pacific

BGP hijacking and route leaks represent significant problems in the global Internet routing systems, along with source address spoofing. BGP hijacks are where allocated or unallocated address space is announced by entities who are not holders and are not authorized to use it.

The announcement of allocated address space often creates big news, such as when 53 route prefixes of Amazon were hijacked, but the announcement of unallocated address space (whether IPv4, IPv6 or AS numbers) which are also known as ‘bogons’ often does not generate much publicity as it does not cause immediate disruptions to service or business. With depletion of the IPv4 address space though, the announcement of bogons are on the rise with miscreants scraping the unallocated address space from all RIRs and abusing it.

Resource Public Key Infrastructure (RPKI) was therefore developed to try to solve these problems, and APNIC (the Routing Internet Registry for the Asia-Pacific region) recently announced it will honour the creation of AS0 ROA objects. They join ARIN, AfriNIC and the RIPE NCC in supporting AS0 ROA objects, with only LACNIC yet to implement this.

APNIC members can create AS0 ROAs for the prefixes they manage using the MyAPNIC platform.

So, what is the significance of AS0 ROAs? A quick overview of ROA is in order before explaining the importance of AS0 ROA. According to RFC6483:

A “route” is a unit of information that associates a set of destinations described by an IP address prefix with a set of attributes of a path to those destinations.

The Border Gateway Protocol (BGP) relies on the assumption that the Autonomous System (AS) that originates routes for a particular prefix, is authorized to do so by the holder of that prefix. A Route Origination Authorization (ROA) is used to verifiably assert that the holder of IP address space is authorized to originate routes from a given set of prefixes.

A ROA identifies a single AS that has been authorized by the address space holder to originate routes, and provides a list of one or more IP address prefixes that will be advertised. If the address space holder needs to authorize multiple ASes to advertise the same set of address prefixes, the holder issues multiple ROAs, one per AS number.

The information in the ROAs can be used by networks using BGPto perform Route Origin Validation (ROV) on incoming BGP advertisements. ROV allows BGP speakers to determine if they should accept the routes being advertised to them as real, and is based on the state of a received announcement which can be Valid, NotFound, or Invalid.

  • Valid – The announcement is covered by at least one ROA
  • NotFound – The announcement is not covered by any ROA
  • Invalid – Announcement that contradicts ROA information. It can be an AS of unauthorised origin AS, or that the announcement is more specific than is allowed by the maximum length set even if it originates from a valid AS number.

What must be remembered is that RPKI validation relies on the availability of RPKI data, and therefore RPKI caches should be located close to routers that require this data (we are not going to discuss Relying Party-RP or RTR Protocol here).

Up until September 2012, AS0 was listed in the IANA Autonomous System Number Registry as “Reserved – May be used to identifying non-routed networks”. This status was updated with RFC7607 which redefined AS0 in line with RFC6491 “Resource Public Key Infrastructure (RPKI) Objects Issued by IANA”:

AS0 ROA: A ROA containing a value of 0 in the ASID field. “Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origination Authorizations (ROAs)”

Whereas, RFC6483 defines the term “Disavowal of Routing Origination”.

“A ROA is a positive attestation that a prefix holder has authorized an AS to originate a route for this prefix into the inter-domain routing system.  It is possible for a prefix holder to construct an authorization where no valid AS has been granted any such authority to originate a route for an address prefix.  This is achieved by using a ROA where the ROA’s subject AS is one that must not be used in any routing context.  Specifically, AS0 is reserved by the IANA such that it may be used to identify non-routed networks

A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context. The route validation procedure will provide a “valid” outcome if any ROA matches the address prefix and origin AS even if other valid ROAs would provide an “invalid” validation outcome if used in isolation.  Consequently, an AS0 ROA has a lower relative preference than any other ROA that has a routable AS, as its subject.  This allows a prefix holder to use an AS0 ROA to declare a default condition that any route that is equal to or more specific than the prefix to be considered “invalid”, while also allowing other concurrently issued ROAs to describe valid origination authorizations for more specific prefixes.”

This means that AS0 in a ROA can be used to mark a prefix and all its more specific prefixes as Invalid and not to be used in a routing context. By publishing a ROA that lists AS0 as the only origin, it allows a resource holder to signal that a prefix (including its more specific prefixes) should not be routed. In other words, a BGP speaker should not accept or propagate routes containing AS0.

RFC7607 codifies the BGP speaker behaviour to handle AS0.

“A BGP speaker MUST NOT originate or propagate a route with an AS number of zero in the AS_PATH, AS4_PATH, AGGREGATOR, or AS4_AGGREGATOR attributes. 

An UPDATE message that contains the AS number of zero in the AS_PATH or AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in RFC7606 “treat-as-withdraw”

An UPDATE message that contains the AS number of zero in the AS4_PATH or AS4_AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in RFC6793 “attribute discard”

If a BGP speaker receives zero as the peer AS in an OPEN message, it MUST abort the connection and send a NOTIFICATION with Error Code “OPEN Message Error” and subcode “Bad Peer AS” (see Section 6 of RFC4271).  A router MUST NOT initiate a connection claiming to be AS0.”

Returning to RFC6491, this ‘Recommends’ that IANA issue an AS0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed, to all Unallocated Resources – namely Resources that have not yet been allocated for special purposes to Regional Internet Registries (RIRs) – or to other resources that are not intended to be globally routed.

This measure can greatly enhance the effectiveness of RPKI and routing security in general, but network operators should also take a look at the MANRS initiative – which is supported by the Internet Society. This specifies additional actions including filtering, anti-spoofing, coordination, as well as support for global validation mechanisms such as RPKI and currently encompasses over 200 Autonomous Systems around the world, including some of the largest ISPs.

If you’re a network operator or IXP, then please see how you can help contribute towards improving the security and resilience of the global routing system.

Further Information

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Fruitful discussions at APRICOT
Deploy36029 February 2016

Fruitful discussions at APRICOT

The Internet Society including Deploy360 was in attendance at APRICOT 2016 which was held from 15-26 February 2016 at the...

BGPSec - A reality now
BGPSec - A reality now
Deploy36016 October 2017

BGPSec – A reality now

The Secure Inter Domain Routing (SIDR) initiative held its first BoF at IETF 64 back in November 2005, and was...

Rough Guide to IETF 102: Internet Infrastructure Resilience
IETF10 July 2018

Rough Guide to IETF 102: Internet Infrastructure Resilience

As usual, in this post I’ll focus on important work the IETF is doing that helps improve the security and...

Join the conversation with Internet Society members around the world