Jump to content

Resource Public Key Infrastructure

From Wikipedia, the free encyclopedia
(Redirected from BGPsec)

Resource Public Key Infrastructure (RPKI), also known as Resource Certification, is a specialized public key infrastructure (PKI) framework to support improved security for the Internet's BGP routing infrastructure.

RPKI provides a way to connect Internet number resource information (such as Autonomous System numbers and IP addresses) to a trust anchor. The certificate structure mirrors the way in which Internet number resources are distributed. That is, resources are initially distributed by the IANA to the regional Internet registries (RIRs), who in turn distribute them to local Internet registries (LIRs), who then distribute the resources to their customers. RPKI can be used by the legitimate holders of the resources to control the operation of Internet routing protocols to prevent route hijacking and other attacks. In particular, RPKI is used to secure the Border Gateway Protocol (BGP) through BGP Route Origin Validation (ROV) and Autonomous System Provider Authorization (ASPA), as well as Neighbor Discovery Protocol (ND) for IPv6 through the Secure Neighbor Discovery protocol (SEND).

The RPKI architecture is documented in RFC 6480. The RPKI specification is documented in a spread out series of RFCs: RFC 6481, RFC 6484, RFC 6485, RFC 6486, RFC 6487, RFC 6488, RFC 6489, RFC 6490, RFC 6491, RFC 6492, and RFC 6493. ROV is documented in RFC 6482 and RFC 6483, and SEND in RFC 6494 and RFC 6495. These RFCs are a product of the IETF's SIDR ("Secure Inter-Domain Routing") working group,[1] and are based on a threat analysis which was documented in RFC 4593. Several implementations for prefix origin validation already exist.[2]

Resource Certificates and child objects

[edit]

RPKI uses X.509 PKI certificates (RFC 5280) with extensions for IP addresses and AS identifiers (RFC 3779). It allows the members of regional Internet registries, known as local Internet registries (LIRs), to obtain a resource certificate listing the Internet number resources they hold. This offers them validatable proof of holdership, though the certificate does not contain identity information. Using the resource certificate, LIRs can create cryptographic attestations about the route announcements they authorise to be made with the prefixes and ASNs they hold. These attestations are described below.

Route Origin Authorizations

[edit]

A Route Origin Authorization (ROA)[3] states which autonomous system (AS) is authorised to originate certain IP prefixes, used for Route Origin Validation (ROV). In addition, it can enforce the maximum length of the prefix that the AS is authorised to advertise. An ROA that was cryptographically verified is referred to as a Validated ROA Payload (VRP), which is then typically transferred to a router to perform route filtering.

Maximum prefix length

[edit]

The maximum prefix length is an optional field. When not defined, the AS is only authorised to advertise exactly the prefix specified. Any more specific announcement of the prefix will be considered invalid. This is a way to enforce aggregation and prevent hijacking through the announcement of a more specific prefix.

When present, this specifies the length of the most specific IP prefix that the AS is authorised to advertise. For example, if the IP address prefix is 10.0.0.0/16 and the maximum length is 22, the AS is authorised to advertise any prefix under 10.0.0.0/16, as long as it is no more specific than /22. So, in this example, the AS would be authorised to advertise 10.0.0.0/16, 10.0.128.0/20 or 10.0.252.0/22, but not 10.0.255.0/24.

RPKI route announcement validity

[edit]

When a ROA is created for a certain combination of origin AS and prefix, this will have an effect on the RPKI validity[4] of one or more route announcements. They can be:

  • VALID
    • The route announcement is covered by at least one ROA
  • INVALID
    • The prefix is announced from an unauthorised AS. This means:
      • There is a ROA for this prefix for another AS, but no ROA authorising this AS; or
      • This could be a hijacking attempt
    • The announcement is more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS
  • UNKNOWN
    • The prefix in this announcement is not covered (or only partially covered) by an existing ROA

Note that invalid BGP updates may also be due to incorrectly configured ROAs.[5]

Autonomous System Provider Authorizations

[edit]

An Autonomous System Provider Authorization (ASPA)[6] states which networks are permitted to appear as direct upstream adjacencies of an autonomous system in BGP AS_PATHs. This provides a simpler way of BGP path validation compared to BGPsec described below.

AS operators publish attestations specifying which other ASNs may appear as an upstream in any AS_PATH received through BGP. There are two variants of ASPA validation, depending on where the BGP announcement was received from:[7]

  • Announcement was received from a customer or lateral peer: Here, every AS adjacency is assumed to be a customer-provider relationship. If all customer ASes publish a valid ASPA record including the corresponding provider ASN seen in the given path, the announcement is considered valid. If any AS appearing in the path does not have any ASPA records (for example, because it has not yet deployed ASPA), the announcement validity is unknown, in which case it should still be accepted to support the incremental deployment of ASPA, similar to route origin validation. Otherwise, if neither applies, the announcement is considered invalid and should be rejected.
  • Announcement was received from an upstream provider: This case is more complex than the previous, as the AS_PATH may contain several types of AS relationships. Since BGP does not encode the relationship of two adjacent ASes and otherwise determining these relationships is impossible without prior information, ASPA validation relies on the attested information itself to determine whether a received AS_PATH is plausible. The validation algorithm starts from both ends of the AS path and counts the number of adjacencies that are valid customer-provider relationships according to the ASPA data. The longest valid path starting from the origin AS, the last one in the AS_PATH, is called the up ramp, while the down ramp starts from the verifying AS. If up and down are separated by at most one adjacency, indicating a lateral peering connection at the top of the AS hierarchy, the announcement is considered valid (note that the up and down paths may also overlap, indicating a common provider for one of the other ASes). This process also ensures that the valley-free property of BGP paths is fulfilled. Similarly as before, if any AS does not have any ASPA records, the announcement validity is unknown, and if neither is the case, the announcement is invalid.

BGP AS path prepending has no effect on the validation process, as consecutive duplicate ASNs in the AS_PATH are collapsed to one before the validation process.

Tier 1 ISPs publish an ASPA record containing the single entry AS0, indicating that these networks have no upstreams and any announcements suggesting otherwise are invalid.[8]

Border Gateway Protocol Security

[edit]

Border Gateway Protocol Security (BGPsec) is a security extension of the Border Gateway Protocol defined in RFC 8205, along with additional RFCs 8206 to 8209, published in September 2017. BGPsec provides security by allowing receivers of BGPsec UPDATE messages to cryptographically verify the received AS path.[9] BGPsec replaces the BGP AS_PATH attribute with a new BGPsec_Path attribute.[10]

BGPsec uses router certificates, defined in RFC 8209 and published through RPKI, which are fetched by validators to verify a BGPsec signature received in an UPDATE message. Signatures are created by routers using their private key, and verifiable using the public key contained in the corresponding router certificate.

The use of cryptographic signing significantly increases the resource overhead in routers when sending and receiving BGP announcements. Further, to serve a significant security benefit, BGPsec must be deployed on a large portion of routers, in contrast to ROV and ASPA, which provides immediate security benefits to early deployments. These are the major reasons why BGPsec is practically not in use in the Internet, and working implementations for it are sparse.[11] As of June 2026, zero valid router certificates are published in the Internet's RPKI, compared to over 375 thousand ROAs and several thousand ASPAs, even though ASPA has not even been fully standardized at this time.

Management

[edit]

There are open source tools[12] available to run the certificate authority and manage the resource certificate and child objects such as ROAs. In addition, the RIRs have a hosted RPKI platform available in their member portals. This allows LIRs to choose to rely on a hosted system, or run their own software.

Publication

[edit]

The system does not use a single repository publication point to publish RPKI objects. Instead, the RPKI repository system consists of multiple distributed and delegated repository publication points. Each repository publication point is associated with one or more RPKI certificates' publication points. In practice this means that when running a certificate authority, an LIR can either publish all cryptographic material themselves, or they can rely on a third party for publication. When an LIR chooses to use the hosted system provided by the RIR, in principle publication is done in the RIR repository.

Validation

[edit]

Relying party software will fetch, cache, and validate repository data using rsync or the RPKI Repository Delta Protocol (RFC 8182).[13] It is important for a relying party to regularly synchronize with all the publication points to maintain a complete and timely view of repository data. Incomplete or stale data can lead to erroneous routing decisions.[14][15]

Routing decisions

[edit]

After validation of attestations such as ROAs, they can be compared to BGP routing state and aid network operators in their decision-making process. This can be done manually, but the validated prefix origin data can also be sent to a supported router using the RPKI to Router Protocol (RFC 6810).[16] Cisco Systems offers native support on many platforms[17] for fetching the RPKI data set and using it in the router configuration.[18] Juniper offers support on all platforms[19] that run version 12.2 or newer. BIRD natively supports the RPKI-to-Router Protocol through the "RPKI" protocol in the configuration, and is able to do ROV and ASPA based on this. Quagga obtains this functionality through BGP Secure Routing Extensions (BGP-SRx)[20] or a RPKI implementation[21] fully RFC-compliant based on RTRlib. The RTRlib[22] provides an open source C implementation of the RTR protocol and prefix origin verification. The library is useful for developers of routing software but also for network operators.[23] Developers can integrate the RTRlib into the BGP daemon to extend their implementation towards RPKI. Network operators may use the RTRlib to develop monitoring tools (e.g., to check the proper operation of caches or to evaluate their performance).

RFC 6494 updates the certificate validation method of the Secure Neighbor Discovery protocol (SEND) security mechanisms for Neighbor Discovery Protocol (ND) to use RPKI for use in IPv6. It defines a SEND certificate profile utilizing a modified RFC 6487 RPKI certificate profile which must include a single RFC 3779 IP address delegation extension.

References

[edit]
  1. ^ "Secure Inter-Domain Routing (SIDR)". datatracker.ietf.org.
  2. ^ Resource Public Key Infrastructure (RPKI) Router Implementation Report (RFC 7128), R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch, February, 2014
  3. ^ A Profile for Route Origin Authorizations (ROAs), J. Snijders, B. Maddison, M. Lepinski, S. Kent, D. Kong, May, 2024
  4. ^ Huston, Geoff; Michaelson, George G. (Feb 2012). Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) (Report). Internet Engineering Task Force.
  5. ^ Wählisch, Matthias; Maennel, Olaf; Schmidt, Thomas C. (13 August 2012). "Towards detecting BGP route hijacking using the RPKI". Proceedings of the ACM SIGCOMM. New York, NY, USA: Association for Computing Machinery. pp. 103–104. doi:10.1145/2342356.2342381.
  6. ^ Azimov, Alexander; Bogomazov, Eugene; Bush, Randy; Patel, Keyur; Snijders, Job; Sriram, Kotikalapudi (29 August 2023). "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects". Internet Engineering Task Force.
  7. ^ "Autonomous System Provider Authorization (ASPA)". RIPE NCC. Retrieved 2026-06-18.
  8. ^ "RPKI from AS3320 - Cloudflare Radar". Retrieved 2026-06-18.
  9. ^ Lepinski, Matthew; Sriram, Kotikalapudi (September 2017). BGPsec Protocol Specification. IETF. doi:10.17487/RFC8205. RFC 8205.
  10. ^ "BGP security: the BGPsec protocol". 30 April 2015.
  11. ^ Lisa Bruder (2025-05-23). "BGPsec — could you run it if you wanted to?". Retrieved 2026-06-18.
  12. ^ "GitHub - dragonresearch/rpki.net: Dragon Research Labs rpki.net RPKI toolkit". November 23, 2019 – via GitHub.
  13. ^ Bruijnzeels, Tim; Muravskiy, Oleg; Weber, Bryan; Austein, Rob (July 2017). "RFC 8182 - The RPKI Repository Delta Protocol". datatracker.ietf.org.
  14. ^ Kristoff, John; Bush, Randy; Kanich, Chris; Michaelson, George; Phokeer, Amreesh; Schmidt, Thomas C.; Wählisch, Matthias (2020-10-27). "On Measuring RPKI Relying Parties". Proceedings of the ACM Internet Measurement Conference. IMC '20. New York, NY, USA: Association for Computing Machinery. pp. 484–491. doi:10.1145/3419394.3423622. ISBN 978-1-4503-8138-3. S2CID 225042016.
  15. ^ Kristoff, John; Bush, Randy; Kanich, Chris; Michaelson, George; Phokeer, Amreesh; Schmidt, Thomas C.; Wählisch, Matthias (2020-10-27). "On Measuring RPKI Relying Parties". Proceedings of the ACM Internet Measurement Conference. ACM. pp. 484–491. doi:10.1145/3419394.3423622. ISBN 978-1-4503-8138-3. S2CID 225042016.
  16. ^ Bush, Randy; Austein, Rob (January 2013). "RFC 6810 - The Resource Public Key Infrastructure (RPKI) to Router Protocol". datatracker.ietf.org.
  17. ^ "RPKI Configuration with Cisco IOS". RIPE. Archived from the original on 2015-03-24. Retrieved 2014-03-24.
  18. ^ "Cisco IOS IP Routing: BGP Command Reference - BGP Commands: M through N [Support]". Cisco.
  19. ^ "Example: Configuring Origin Validation for BGP - Technical Documentation - Support - Juniper Networks". www.juniper.net.
  20. ^ "BGP Secure Routing Extension (BGP‑SRx) Prototype". NIST. August 15, 2016.
  21. ^ "Quagga with RPKI-RTR prefix origin validation support: rtrlib/quagga-rtrlib". May 10, 2019 – via GitHub.
  22. ^ "RTRlib - The RPKI RTR Client C Library". rpki.realmv6.org.
  23. ^ M. Wählisch, F. Holler, T.C. Schmidt, J.H. Schiller: "RTRlib: An Open-Source Library in C for RPKI-based Prefix Origin Validation, Proc. of USENIX Security Workshop CSET'13, Berkeley, CA, USA:USENIX Assoc., 2013.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Resource_Public_Key_Infrastructure&oldid=1359979872#Border_Gateway_Protocol_Security"