BGP AS_PATH Verification Based on Resource Public Key Infrastructure (RPKI) Autonomous System Provider Authorization (ASPA) Objects
Yandex
a.e.azimov@gmail.com
Qrator Labs
eb@qrator.net
Internet Initiative Japan & Arrcus
randy@psg.com
Arrcus
keyur@arrcus.com
Fastly
Amsterdam
NL
job@fastly.com
USA National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg
MD
20899
United States of America
ksriram@nist.gov
BGP
Route leak
Hijacks
This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes.
This type of AS_PATH verification is primarily intended for detection and mitigation of route leaks.
It also to some degree provides protection against forged-origin prefix hijacks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
The Border Gateway Protocol (BGP) originally was designed without mechanisms to validate whether the contents of attributes in BGP UPDATEs conform to wishes of the involved Internet Number resource holders.
As a consequence BGP hijacks and BGP route leaks exist.
Some existing BGP extensions are able to partially solve these problems; for example, ROA-based Route Origin Validation (ROV) can be used to detect and filter accidental mis-originations, and or can be used to detect and mitigate accidental route leaks.
This specification focuses on solving a number of real-world operational problems: the automatic detection of route leaks and improbable BGP paths.
To achieve this, new AS_PATH verification procedures are described to automatically detect invalid AS_PATHs in announcements that are received from customers, lateral peers (defined in ), transit providers, Route Servers (RSes), and RS-clients.
These procedures use a shared database of cryptographically signed customer-to-provider relationships using a new Resource Public Key Infrastructure (RPKI) Signed Object: Autonomous System Provider Authorization (ASPA) .
This incrementally deployable technique provides benefits to early adopters in context of limited deployment.
Both route leaks and hijacks have similar effects on ISP operations - they redirect traffic which can result in denial of service (DoS), eavesdropping, increased latency, and packet loss.
But the level of risk depends significantly on the extent of propagation of the anomalies.
For example, a hijack that is propagated only to customers may cause bottlenecking within a particular ISP's customer cone, but if the anomaly propagates through lateral (i.e., non-transit) peers and transit providers, or reaches global distribution through transit-free networks, then the ill effects will likely be experienced across continents.
The ability to constrain propagation of BGP anomalies to transit providers and lateral peers - without requiring support from the source of the anomaly (which is critical if the source has malicious intent) - should significantly improve the security of global inter-domain routing system.
As described in , the RPKI is based on a hierarchy of resource certificates that are aligned to the Internet Number Resource allocation structure.
Resource certificates are X.509 certificates that conform to the PKIX profile , carrying the extensions for IP addresses and AS identifiers .
A resource certificate is a binding by an issuer of IP address blocks and Autonomous System (AS) numbers to the subject of a certificate, identified by the unique association of the subject's private key with the public key contained in the resource certificate.
The RPKI is structured so that each current resource certificate matches a current resource allocation or assignment.
ASPA is a digitally signed object that binds, for a selected AFI, a Set of Provider AS numbers to a Customer AS number (in terms of BGP announcements, not business relationship), and are signed by the holder of the Customer AS.
An ASPA attests that a Customer AS holder (CAS) has authorized a Set of Provider ASes (SPAS) to propagate the Customer's IPv4 or IPv6 announcements onward, e.g., to the Provider's upstream providers or lateral peers.
The ASPA object profile is described in .
In this document, the notation (AS1, AFI, [AS2,...]) is used to represent the ASPA object for AS1 in the selected AFI. In this example, AS2 and any other ASes listed in the square brackets represent the transit provider ASes.
This section describes a procedure for checking that an ordered pair of AS numbers (ASNs), e.g., (AS1, AS2), has the property that AS2 is an attested provider of AS1 per ASPA.
This procedure is used in ASPA-based AS_PATH validation as described in .
The procedure takes (AS1, AS2, AFI) as input parameters and returns one of three possible results, which are "Valid", "Invalid", and "Unknown".
A relying party (RP) must have access to a local cache of the complete set of cryptographically valid ASPAs when performing the customer-provider verification procedure.
The following algorithm describes the customer-provider verification procedure for a selected AFI:
Retrieve all cryptographically valid ASPAs with the selected AFI that have a customer value of AS1.
The union of SPAS from these ASPAs forms the set of Candidate Providers.
If the set of Candidate Providers is empty, then the procedure exits with an outcome of "Unknown".
If AS2 is included in the set of Candidate Providers, then the procedure exits with an outcome of "Valid".
Otherwise, the procedure exits with an outcome of "Invalid".
Since an AS may have different sets of providers for different AFI, accordingly it may have different SPAS in the corresponding ASPAs.
Therefore, the above procedure with the input (AS1, AS2, AFI) may have different outputs for different AFI values.
The AS_PATH attribute identifies the autonomous systems through which an UPDATE message has passed.
It may contain two types of components: AS_SEQUENCEs and AS_SETs, as defined in .
(Note: The consideration of AS Confederations is discussed in .)
If the AS_PATH contains an AS_SET in any position, then it is marked by the verification algorithm as Invalid.
(Note: AS_SETs are expected to be deprecated soon .)
If the AS_PATH does not contain an AS_SET but only AS_SEQUENCE(s), then it is represented for simplicity in the verification algorithm as a sequence of unique AS numbers: AS(1), AS(2),..., AS(I-1), AS(I), AS(I+1),..., AS(N), where AS(1) is the rightmost (i.e., origin) AS and AS(N) is the leftmost, i.e., the neighbor of the validating AS.
N is the AS_PATH length in terms of the number of unique ASNs. (Note: see for the consideration of a special case.)
An Invalid Pair Index is determined as a minimal I such that the customer-provider validation procedure () with parameters (AS(I), AS(I+1), AFI) returns Invalid.
If there is no such minimal I, then the Invalid Pair Index value is set equal to N.
The Reverse Invalid Pair Index is determined as the Invalid Pair Index calculated for the reversed version of the sequence AS(1), AS(2),..., AS(I-1), AS(I), AS(I+1),..., AS(N).
An Unknown Pair Index is determined as a minimal I such that the customer-provider validation procedure () with parameters (AS(I), AS(I+1), AFI) returns Unknown.
If there is no such minimal I or the minimal I value is greater than the Invalid Pair Index, then the Unknown Pair Index value is set equal to the Invalid Pair Index.
The Reverse Unknown Pair Index is determined as the Unknown Pair Index calculated for the reversed version of the sequence AS(1), AS(2),..., AS(I-1), AS(I), AS(I+1),..., AS(N).
The procedures described in and make use of the four Indices defined above. Also, those procedures are applicable only to 32-bit AS number compatible BGP speakers.
A special consideration is given to the case when the validating AS is an RS-client of a non-transparent Route Server (RS).
In this case, when the indices described are computed, the ASN of the RS is removed from the AS_PATH only for the purpose generating the sequence AS(1), AS(2),... , AS(I-1), AS(I), AS(I+1),..., AS(N) that was defined in .
Thus, AS(N) would equal the AS number of the AS added just before the RS. Also, N would be one less than the AS_PATH length.
Note that when an UPDATE is received from an IX RS, it is equivalent to coming from a lateral peer regardless of whether the RS is transparent or not.
Hence, the Upstream path validation procedure () can be applied at the receiving RS-client in both cases (i.e., transparent and non-transparent) provided the non-transparent RS AS is removed as described above (preceding paragraph).
The upstream verification algorithm described here is applied when a route is received from a customer or a lateral peer, or by an RS-client at an IX RS.
Each hop AS(I) to AS(I+1)in the unique ASN sequence AS(1), AS(2),... , AS(N) must be Valid per the customer-provider validation procedure () for the AS_PATH to be Valid.
If at least one of those hops is Invalid, then the AS_PATH would be Invalid.
If the AS_PATH verification outcome is neither Valid nor Invalid, then it would be evaluated as Unknown.
If an attacker creates a route leak intentionally, they may try to strip their AS from the AS_PATH.
To partly guard against that, a check is performed to match the most recently added AS in the AS_PATH to the BGP neighbor's ASN.
To further strengthen route leak detection against malicious activity, a check is performed to make sure that the AS_PATH is not empty.
The upstream path verification procedure is specified as follows:
If the AS_PATH has an AS_SET or zero length, then the procedure halts with the outcome "Invalid".
If the most recently added AS in the AS_PATH has a value not equal to the receiver's neighbor ASN, then the procedure halts with the outcome "Invalid".
If the Invalid Pair Index is less than N, then the procedure halts with the outcome "Invalid".
If the Unknown Pair Index is less than N, then the procedure halts with the outcome "Unknown".
Else, the procedure halts with the outcome "Valid".
The downstream verification algorithm described here is applied when a route is received from a transit provider.
Consider an UPDATE with the AS sequence AS(1), AS(2),... , AS(N) as defined in .
When the UPDATE is received from a provider, it may have both an upstream ramp and a downstream ramp, where the downstream ramp follows the upstream ramp (both ramps are ASPA valid hop-by-hop).
A ramp stops when an ASPA validation to check customer-to-provider relationship of the next hop is unsuccessful (i.e., verification of the pair of ASes gives Invalid or Unknown result).
If there is an upstream ramp but no downstream ramp or vice versa, then clearly the UPDATE is valid (i.e., not a route leak).
However, if both ramps exist, then the UPDATE is Valid if and only if either one or no AS hops exist between the apexes of the two ramps, i.e., there is no AS between the apexes (see for formal proof).
If there are one or more ASes between the upstream and downstream ramps, then the UPDATE is a route leak (Invalid) or the presence of a leak cannot be known using available ASPAs (Unknown) .
The determination of a route leak (Invalid) UPDATE can be done with the use of the Invalid Pair Index and Reverse Invalid Pair Index.
The rule for Invalid determination is as follows: if the sum of Invalid Pair Index and Reverse Invalid Pair Index is less than N, then route was leaked or the AS_PATH attribute was malformed.
As was done in the case of upstream paths , the checks regarding empty AS_PATH and match between the most recently added AS and the BGP neighbor AS are performed here also.
The downstream path verification procedure is specified as follows:
If the AS_PATH has an AS_SET or zero length, then the procedure halts with the outcome "Invalid".
If the most recently added AS in the AS_PATH has a value not equal to the receiver's neighbor ASN, then the procedure halts with the outcome "Invalid".
If the sum of the Invalid Pair Index and the Reverse Invalid Pair Index is less than N, then the procedure halts with the outcome "Invalid".
If the sum of the Unknown Pair Index and the Reverse Unknown Pair Index is less than N, then the procedure halts with the outcome "Unknown".
Else, the procedure halts with the outcome "Valid".
An ASPA is a positive attestation that an AS holder has authorized its providers to redistribute received routes to the provider's providers and lateral peers.
This does not preclude the provider AS from redistribution to its other customers.
An AS number resource holder in its role as Customer, MUST register each of its transit provider ASes in its ASPA record.
Operators SHOULD endeavour to register all providers in a single ASPA object at any time.
Registration of an ASPA (AS, AFI, [0]) and no other ASPAs is meant to be a statement by the registering AS that it has no transit providers.
An RS AS MUST register an AS 0 ASPA and MUST NOT register any other ASPAs.
Normally, so-called "Tier-1" ASes do not have transit providers.
However, if a Tier-1 AS is present at an IX RS as an RS-client, then it MUST register an ASPA showing the RS AS as a provider.
An ASPA (AS, AFI, [0]) SHOULD be the only ASPA registered by an AS that wishes declare that it is provider-free in the selected AFI.
If AS 0 coexists with other provider ASes in the same ASPA (or other ASPA records in the same AFI), then the presence of the AS 0 has no effect on the AS_PATH verification procedures.
The validation procedures simply consider the other (distinct from AS 0) providers as the authorized providers of the AS in consideration.
A compliant AS MUST apply the upstream and downstream AS path validation algorithms ( and , respectively) in principle producing outcomes as specified though the implementation details may differ.
If the output of the AS_PATH verification procedure is "Invalid", then the route MUST be rejected.
The above AS_PATH verification procedures ( and ) are able to check routes received from customers, lateral peers, transit providers, RSes, and RS-clients.
The ASPA-based path verification mechanism combined with BGP Roles and ROA-based Origin Validation can provide a fully automated solution to detect and filter hijacks and route leaks, including malicious ones (e.g., forged-origin hijacks).
There are peering relationships which cannot be described as strictly simple peer-to-peer (i.e., lateral peers) or customer-to-provider.
An example is when both parties (ASes) treat each other as a customer, i.e., the customer-to-provider relationship applies in each direction.
That is called a sibling relationship, and in such case, an ASPA (AS1, AFI, [AS2, ...]) must be created by AS1 and another ASPA (AS2, AFI, [AS1, ...]) must be created by AS2.
The ASes on the boundary of an AS Confederation MUST register ASPAs using the Confederation's global ASN and the procedures for ASPA-based AS path validation in this document are NOT RECOMMENDED for use on eBGP links internal to the Confederation.
While the described upgrades to BGP are quite useful, they still rely on an unsigned transitive BGP attributes, e.g., AS_PATH, which can be manipulated by on-path attackers.
BGPsec was designed to solve the problem of AS_PATH validation using cryptographic signatures contained in BGP UPDATE messages.
While BGPsec offers protection against unauthorized path modifications, BGPsec by design does not protect against route leaks.
BGPsec and ASPA are complementary technologies.
The Peerlock mechanism has a similar objective as the APSA-based route leak protection mechanism described in this document.
It is commonly deployed by large Internet carriers to protect each other from route leaks.
Peerlock depends on a laborious manual process in which operators coordinate the distribution of unstructured Provider Authorizations through out-of-band means in a many-to-many fashion.
On the other hand, ASPA's use of the RPKI allows for automated, scalable, and ubiquitous deployment, making the protection mechanism available to a wider range of network operators.
The ASPA mechanism implemented in router code versus Peerlock's AS_PATH regular expressions also provides a way to detect anomalies propagated from transit providers and IX route servers.
ASPA is intended to be a complete solution and replacement for existing Peerlock deployments.
This document includes no request to IANA.
The proposed mechanism is compatible only with BGP implementations that can process 32-bit ASNs in the AS_PATH.
This limitation should not have a real effect on operations since legacy BGP routers are rare and it is highly unlikely that they support integration with the RPKI.
ASPA issuers should be aware of the implications of the ASPA-based AS path verification. A downstream AS can apply the verification mechanism and possibly invalidate and reject all routes passed to upstream providers other than the provider ASes listed in the ASPA record.
It is the responsibility of each compliant AS to maintain a correct set of providers in its ASPA record(s).
It is highly recommended that a compliant AS should maintain a single ASPA object that covers all its providers.
Such a practice will help prevent race conditions during ASPA updates that might affect prefix propagation.
The software that provides hosting for ASPA records SHOULD support enforcement of this practice.
During a transition process between different certificate authority (CA) registries, the ASPA records SHOULD be kept identical in all registries.
While the ASPA-based mechanism is able to generally detect both mistakes and malicious activity affecting routes received from customers, RS-clients, or lateral peers, it might fail to detect some malicious path modifications for routes that are received from upstream providers.
Since an upstream provider becomes a trusted point, in theory it might be able to propagate without detection some instances of hijacked prefixes of its customers or routes with malformed AS_PATHs.
While it may happen in theory, it does not seem to be a realistic scenario. Normally a customer and its transit provider have a signed agreement and such a policy violation should have legal consequences or customer can just drop the relationship with such a provider and remove the corresponding ASPA record.
The authors wish to thank the authors of since its text was used as an example while writing in this document. Thanks are also due to Jakob Heitz, Ben Maddison, Jeff Haas, and Nick Hilliard for comments and discussion about the algorithms. The authors wish to thank Iljitsch van Beijnum for providing a suggestion about downstream paths.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
BGP Prefix Origin Validation
To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]
An Infrastructure to Support Secure Internet Routing
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
A Border Gateway Protocol 4 (BGP-4)
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.
This document obsoletes RFC 1771. [STANDARDS-TRACK]
Problem Definition and Classification of BGP Route Leaks
A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
X.509 Extensions for IP Addresses and AS Identifiers
This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]
Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP
This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. This memo documents an Internet Best Current Practice.
BGPsec Protocol Specification
This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.
Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)
This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.
Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.
Methods for Detection and Mitigation of BGP Route Leaks
USA National Institute of Standards and Technology
Yandex
Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a new well- known Large Community that provides a way for route-leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in ietf-idr-bgp-open-policy draft.
A Profile for Autonomous System Provider Authorization
Yandex
JetLend
Internet Initiative Japan
Fastly
Vigil Security, LLC
Workonline
This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of validating that a Customer Autonomous System holder has authorized members of Provider set to be its upstream providers or provide route server service at internet exchange point. For the Providers it means that they are legal to send prefixes received from the Customer Autonomous System in all directions including providers and peers.
Deprecation of AS_SET in BGP
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
AS_CONFED_SET in the Border Gateway Protocol. This document advances
this recommendation to a standards requirement in BGP; it proscribes
the use of the AS_SET type of path segments in the AS_PATH. This is
done to simplify the design and implementation of BGP and to make the
semantics of the originator of a route clearer. This will also
simplify the design, implementation, and deployment of various BGP
security mechanisms. This document (if approved) updates RFC 4271
and RFC 5065, and obsoletes RFC 6472.
Peerlock
NTT Communications
Flexsealing BGP Against Route Leaks: Peerlock Active Measurement and Analysis
University of Tennesse
University of Tennesse
University of Tennesse
On the Accuracy of Algorithms for ASPA Based Route Leak Detection