Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization

The Border Gateway Protocol (BGP) was designed without mechanisms to validate BGP attributes. Two consequences are BGP Hijacks and BGP Route Leaks . BGP extensions are able to partially solve these problems. For example, ROA-based Origin Validation can be used to detect and filter accidental mis-originations, and can be used to detect accidental route leaks. While these upgrades to BGP are quite useful, they still rely on transitive BGP attributes, i.e. AS_PATH, that can be manipulated by attackers. BGPSec was designed to solve the problem of AS_PATH validation. Unfortunately, strict cryptographic validation brought expensive computational overhead for BGP routers. BGPSec also proved vulnerable to downgrade attacks that nullify the benefits of AS_PATH signing. As a result, to abuse the AS_PATH or any other signed transit attribute, an attacker merely needs to downgrade to 'old' BGP-4. An alternative approach was introduced with soBGP . Instead of strong cryptographic AS_PATH validation, it created an AS_PATH security function based on a shared database of ASN adjacencies. While such an approach has reasonable computational cost, the two side adjacencies don't provide a way to automate anomaly detection without high adoption rate - an attacker can easily create a one-way adjacency. SO-BGP transported data about adjacencies in new additional BGP messages, which was recursively complex thus significantly increasing adoption complexity and risk. In addition, the general goal to verify all AS_PATHs was not achievable given the indirect adjacencies at internet exchange points. Instead of checking AS_PATH correctness, this document focuses on solving real-world operational problems - automatic detection of malicious hijacks and route leaks. To achieve this a new AS_PATH verification procedure is defined which is able to automatically detect invalid (malformed) AS_PATHs in announcements that are received from customers and peers. This procedure uses a shared signed database of customer-to-provider relationships using a new RPKI object - Autonomous System Provider Authorization (ASPA). This technique provides benefits for participants even during early and incremental adoption.

Both route leaks and hijacks have similar effects on ISP operations - they redirect traffic, resulting in increased latency, packet loss, or possible MiTM attacks. But the level of risk depends significantly on the propagation of the anomalies. For example, a hijack that is propagated only to customers may concentrate traffic in a particular ISP's customer cone; while if the anomaly is propagated through peers, upstreams, or reaches Tier-1 networks, thus distributing globally, traffic may be redirected at the level of entire countries and/or global providers. The ability to constrain propagation of BGP anomalies to upstreams and peers, without requiring support from the source of the anomaly (which is critical if source has malicious intent), should significantly improve the security of inter-domain routing and solve the majority of problems.

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 , and to 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. ASPAs are digitally signed objects that bind, for a selected AFI, a Set of Provider AS numbers to a Customer AS number (in terms of BGP announcements not business), and are signed by the holder of the Customer AS. An ASPA attests that a Customer AS holder (CAS) has authorized Set of Provider ASes (SPAS) to propagate the Customer's IPv4/IPv6 announcements onward, e.g. to the Provider's upstream providers or peers. The ASPA record profile is described in .

This section describes an abstract procedure that checks that a pair of ASNs (AS1, AS2) is included in the set of signed ASPAs. The semantics of its use is defined in next section. The procedure takes (AS1, AS2, ROUTE_AFI) as input parameters and returns one of three results: "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 customer-provider verification procedure. Retrieve all cryptographically valid ASPAs in a selected AFI with a customer value of AS1. The union of SPAS 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 AS1 may have different set providers in different AFI, it should also have different PCAS in corresponding ASPAs. In this case, the output of this procedure with input (AS1, AS2, ROUTE_AFI) may have different output for different ROUTE_AFI values.

The AS_PATH attribute identifies the autonomous systems through which an UPDATE message has passed. AS_PATH may contain two types of components: ordered AS_SEQes and unordered AS_SETs, as defined in . The value of each concatenated value of AS_SEQ components can be described as set of pairs {(AS(I), prepend(I)), (AS(I-1), prepend(I-1))...}, where AS(0) stands for originating AS. In this case, the sequence {AS(I), AS(I-1),...} represents different ASNs, that packet should pass towards the destination. The bellow procedure is applicable only for 32-bit AS number compatible BGP speakers.

When a route is received from a customer, literal peer or by RS at IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider or sibling relationship. If there are other types of relationships, it means that the route was leaked or the AS_PATH attribute was malformed. The goal of the described bellow procedure is to check the correctness of this statement. The following diagram and procedure describes the procedure that MUST be applied on routes with ROUTE_AFI received from a customer, peer or RS-client:

(AS(I-1),AS(I))=Valid +-----+ | | v | +---------+ | | (AS(I-1),AS(I))=Invalid | Valid +----------------------------+ | | | +---------+ | | +----v----+ | | | |(AS(I-1),AS(I))=Unknown | Invalid | | | | | +---------+ +----v----+ ^ | | | | Unknown +----------------------------+ | | (AS(I-1),(AS(I))=Invalid +---------+ ^ | | | +-----+ (AS(I-1),AS(I))!=Invalid If the closest AS in the AS_PATH is not the receiver's neighbor ASN then procedure halts with the outcome "invalid"; If there is a pair (AS(I-1), AS(I)), and customer-provider verification procedure () with parameters (AS(I-1), AS(I), ROUTE_AFI) returns "invalid" then the procedure also halts with the outcome "invalid"; If the AS_PATH has at least one AS_SET segment then procedure halts with the outcome "unverifiable"; If there is a pair (AS(I-1), AS(I)), and customer-provider verification procedure () with parameters (AS(I-1), AS(I), ROUTE_AFI) returns "unknown" then the procedure also halts with the outcome "unknown"; Otherwise, the procedure halts with an outcome of "valid".

When route is received from provider or RS it may have both Upstream and Downstream paths, where Downstream follows Upstream path. If the path differs from this rule, e.g. the Downstream path is followed by Upstream path it means that the route was leaked or the AS_PATH attribute was malformed. The first pair (AS(I-1), AS(I)) that has "invalid" outcome of customer-provider verification procedure indicates the end of Upstream path. All subsequent reverse pairs (AS(I), AS(I-1)) MUST belong to customer-provider or sibling relationship, thus can be also verified with ASPA objects. Additional caution should be done while processing prefixes that are received from transparent IXes since they don't add their ASN in the ASPATH. The following diagram and procedure describes the procedure that MUST be applied on routes with ROUTE_AFI received from a provider or RS:

(AS(I-1),AS(I))=Valid (AS(I),AS(I-1))=Valid +-----+ +-----+ | | | | v | v | +-+-----+-+ +-+-----+-+ | |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid | Valid +-----------------------> Valid +---------+ | | | | | +----+----+ +----+----+ | | | +---v-----+ |(AS(I-1),AS(I))=Unknown | | | | | | Invalid | | (AS(I),AS(I-1)=Unknown| | | | | +---+-----+ +----v----+ +----v----+ ^ | | | | | | Unknown +-----------------------> Unknown +---------+ | |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid +-+-----+-+ +-+-----+-+ ^ | ^ | | | | | +-----+ +-----+ (AS(I-1),AS(I))!=Invalid (AS(I),AS(I-1))!=Invalid If route is received from provider and the closest AS in the AS_PATH is not the receiver's neighbor ASN then procedure halts with the outcome "invalid"; If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J > I, and customer-provider verification procedure () returns "invalid" for both (AS(I-1), AS(I), ROUTE_AFI) and (AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts with the outcome "invalid"; If the AS_PATH has at least one AS_SET segment then procedure halts with the outcome "unverifiable"; If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J > I, and customer-provider verification procedure () returns "invalid" for (AS(I-1), AS(I), ROUTE_AFI) and "unknown" for (AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts with the outcome "unknown"; If customer-provider verification procedure () doesn't return "invalid" for any (AS(I-1), AS(I)), but at least for one (AS(I-1), AS(I)) returns "unknown", then the procedure also halts with the outcome "unknown"; Otherwise, the procedure halts with an outcome of "valid".

If the output of the AS_PATH verification procedure is "invalid" the route MUST be rejected. If the output of the AS_PATH verification procedure is 'unverifiable' it means that AS_PATH can't be fully checked. Such routes should be treated with caution and SHOULD be processed the same way as "invalid" routes. This policy goes with full correspondence to . The above AS_PATH verification procedure is able to check routes received from customers and peers. The ASPA mechanism combined with BGP Roles and ROA-based Origin Validation provide a fully automated solution to detect and filter hijacks and route leaks, including malicious ones.

An ASPA is a positive attestation that an AS holder has authorized its providers to redistribute received routes to the provider's providers and peers. This does not preclude the provider ASes from redistribution to its other customers. By creating an ASPA with providers set of {0}, the customer indicates that no provider should further announce its routes. Specifically, AS 0 is reserved to identify provider-free networks, Internet exchange meshes, etc. An ASPA with a providers set of {0} is a statement by the customer AS that its routes should not be received by any relying party AS from any of its customers or peers. By convention, an ASPA with providers set of {0} should be the only ASPA issued by a given AS holder; although this is not a strict requirement. A provider AS 0 may coexist with other provider ASes in the same ASPA (or other ASPA records); though in such cases, the presence or absence of the provider AS 0 in ASPA does not alter the AS_PATH verification procedure.

There are peering relationships which can not be described as strictly simple peer-peer or customer-provider; e.g. when both parties are intentionally sending prefixes received from each other to their peers and/or upstreams. In this case, two corresponding ASPA records (AS1, {AS2, ...}), (AS2, {AS1, ...}) must be created by AS1 and AS2 respectively.

The proposed mechanism is compatible only with BGP implementations that can process 32-bit ASNs in the ASPATH. This limitation should not have a real effect on operations - such legacy BGP routers a rare and it's highly unlikely that they do support integration with RPKI. ASPA issuers should be aware of the verification implication in issuing an ASPA - an ASPA implicitly invalidates all routes passed to upstream providers other than the provider ASs listed in the collection of ASPAs. It is the Customer AS's duty to maintain a correct set of providers in ASPA. While it's not restricted, but it's highly recommended maintaining for selected Customer AS a single ASPA object that covers all its providers. Such policy should prevent race conditions during ASPA updates that might affect prefix propagation. While the ASPA is capable to detect both mistake and malicious activity for routes received from customers, RS-clients or peers, it provides only detection of mistakes for routes that are received from upstream providers and RS(s). Since upstream provider becomes a trusted point, it will be able to send hijacked prefixes of its customers or send hijacked prefixes with malformed AS_PATHs back. While it may happen in theory, it's doesn't seem to be a real scenario: normally customer and provider have a signed agreement and such policy violation should have legal consequences or customer can just drop relation with such provider and remove corresponding ASPA record.

The authors wish to thank authors of since its text was used as an example while writing this document. The also authors wish to thank Iljitsch van Beijnum for giving a hint about Downstream paths.