RFC 7132

Threat Model for BGP Path Security

📅 published February 2014, from ietf

Threat Model for BGP Path Security 🦋

okay so this is RFC 7132 🎀 and it's Informational, which means it's not a standards track spec (more on that below) 💅. The authors are S. Kent (BBN) and A. Chi (UNC-CH), it's from February 2014, and the ISSN is 2070-1721 ✨. The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own 🌸

Abstract 🌈

this doc lays out the threat model for the world where External Border Gateway Protocol (EBGP) path security mechanisms get built 🔍 it includes an analysis of the Resource Public Key Infrastructure (RPKI), and it's super focused on whether an Autonomous System (AS) can verify that the AS path info it gets in a BGP update is legit 🫶 we use "PATHSEC" to mean any BGP path security tech that makes use of the RPKI. PATHSEC will secure BGP, and that fits the inter-AS security focus of the RPKI 🧚

the doc describes the classes of potential adversaries that count as threats and looks at the classes of attacks that might be thrown at PATHSEC ⚔️ it does not revisit attacks on unprotected BGP, because the BGP-4 standard already covered that 📚 it wraps up with a quick look at residual vulnerabilities 💀

Status of This Memo ✨

so this is not an Internet Standards Track specification, it's published for informational purposes 🍓

it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🎀 not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 💅

for the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7132 🦋

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🔍 code components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Threat Characterization . . . . . . . . . . . . . . . . . . .   6
4.  Attack Characterization . . . . . . . . . . . . . . . . . . .   8
  4.1.  Active Wiretapping of Sessions between Routers  . . . . .   8
  4.2.  Attacks on a BGP Router . . . . . . . . . . . . . . . . .   9
  4.3.  Attacks on Network Operator Management Computers (Non-CA
        Computers)  . . . . . . . . . . . . . . . . . . . . . . .  11
  4.4.  Attacks on a Repository Publication Point . . . . . . . .  12
  4.5.  Attacks on an RPKI CA . . . . . . . . . . . . . . . . . .  14
5.  Residual Vulnerabilities  . . . . . . . . . . . . . . . . . .  16
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
8.  Informative References  . . . . . . . . . . . . . . . . . . .  18

1. Introduction 🎀

this doc describes the security context PATHSEC is meant to work in 💖 the term "PATHSEC" (short for path security) refers to any design used to preserve the integrity and authenticity of the AS_PATH attribute carried in a BGP update message [RFC4271] 🦋 the security context used all through this doc is set by the Secure Inter-Domain Routing (SIDR) working group charter [SIDR-CH] ✨ that charter requires that solutions which afford PATHSEC make use of the Resource Public Key Infrastructure (RPKI) [RFC6480] 🫶 it also calls for protecting only the info needed to verify that a received route traversed the Autonomous Systems (ASes) in question, and that the Network Layer Reachability Information (NLRI) in the route is what was advertised 🔍

so the goal of PATHSEC is to let a BGP speaker verify that the ASes listed in this path attribute are the sequence of ASes the NLRI actually traversed 🧚 the name "PATHSEC" fits that goal perfectly 💅 (other SIDR docs use the term "BGPSEC" for a specific design, but we're avoiding that term here 🙈)

this doc talks about classes of potential adversaries that count as threats, plus classes of attacks that might be launched against PATHSEC 🌸 because PATHSEC will rely on the RPKI, threats and attacks against the RPKI are included too 🍓 the model also covers classes of attacks that become possible because PATHSEC is in use (e.g., attacks based on use of the RPKI) 👑

the motivation for PATHSEC, meaning the residual security concerns for BGP, is well explained in a few docs, including "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000] 📚 all of those docs point out that BGP has no mechanisms that let an AS verify the legitimacy and authenticity of BGP route advertisements 😭 (BGP now mandates support for mechanisms that secure peer-to-peer communication, i.e., for the links connecting BGP routers. There are several secure protocol options for that concern, e.g., IPsec [RFC4301] and TCP Authentication Option (TCP-AO) [RFC5925]. This doc briefly notes the need to address this aspect of BGP security, but it focuses on application layer BGP security issues that must be addressed by PATHSEC.) 🫶

RFC 4272 [RFC4272] puts it super succinctly 💅

BGP speakers themselves can inject bogus routing information, either by masquerading as any other legitimate BGP speaker, or by distributing unauthorized routing information as themselves. Historically, misconfigured and faulty routers have been responsible for widespread disruptions in the Internet. The legitimate BGP peers have the context and information to produce believable, yet bogus, routing information, and therefore have the opportunity to cause great damage. The cryptographic protections of [TCPMD5] and operational protections cannot exclude the bogus information arising from a legitimate peer. The risk of disruptions caused by legitimate BGP speakers is real and cannot be ignored.

PATHSEC is meant to address those concerns and deliver much better path security, and it builds on the route origination validation the RPKI already offers [RFC6810] 🔥 specifically, the RPKI lets relying parties (RPs) figure out whether the origin AS for a path was authorized to advertise the prefix in a BGP update message 🎀 that works because of two kinds of digitally signed data: a PKI [RFC6487] that ties one or more prefixes to the public key(s) of an address space holder, and Route Origin Authorizations (ROAs) [RFC6482] that let a prefix holder say which ASes are allowed to originate routes for a prefix 💖

the security model for PATHSEC doesn't assume an "oracle" that can see all the BGP inputs and outputs for every AS or every BGP router 🔮 instead, it's based on a local idea of what counts as legit, authorized behavior by the BGP routers in an AS 🧚 that's an AS-centric model of secure operation, which matches the AS-centric model BGP uses for routing 🦋 this model is the basis for everything that comes next ✨

the doc starts with a short set of definitions for the sections after it 🌸 then it covers the classes of adversaries seen as viable threats to routing on the public Internet 👑 it keeps going with a range of attacks those adversaries might pull off against both path security and the infrastructure PATHSEC depends on 🔍 and it ends with a quick review of residual vulnerabilities, meaning the vulns that the RPKI doesn't address and that look likely to be outside the scope of PATHSEC mechanisms 💀🫶

2. Terminology 💅

okay bestie, before we get into the spicy stuff we need to agree on what words mean 🫶 these are the security and routing terms this doc uses, and they're the foundation for everything else ✨

Adversary: an adversary is an entity (like a person or an organization) that's seen as malicious, relative to a system's security policy 😈 whoever is responsible for a system's security is the one who decides who counts as an adversary 🙈 people often talk about classes of adversaries with similar capabilities or motivations instead of naming specific individuals or orgs, which is very smart 🧠

Attack: an attack is an action that tries to break a system's security policy, like by exploiting a vulnerability 💀 there's usually a many-to-one vibe between attacks and vulnerabilities, since lots of different attacks can exploit the same vulnerability 🌸

Autonomous System (AS): an AS is a set of one or more IP networks run by a single administrative entity 🌈

AS Number (ASN): an ASN is a 2- or 4-byte number that a registry issues to identify an AS in BGP 🔢

Certification Authority (CA): an entity that issues digital certificates (like X.509 certificates) and vouches for the binding between the data items in a certificate 🎀

Countermeasure: a countermeasure is a procedure or technique that thwarts an attack so it doesn't succeed 🛡️ countermeasures are often tailored to specific attacks or classes of attacks, which is giving precision 💅

Border Gateway Protocol (BGP): a path vector protocol used to share "reachability" information among ASes to support inter-domain routing 🌐✨

False (Route) Origination: if a network operator originates a route for a prefix that they don't hold (and haven't been authorized to originate by the prefix holder), that's called false route origination 🚩 not it, sis 🙅‍♀️

Internet Service Provider (ISP): an organization that manages (and usually sells) Internet services to other organizations or individuals 📡

Internet Number Resources (INRs): IPv4 or IPv6 address space, plus ASNs 🔑

Internet Registry: an organization that manages the allocation or distribution of INRs 🗂️ this umbrella includes the Internet Assigned Number Authority (IANA), Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs), which are network operators 👑

Man in the Middle (MITM): a MITM is an entity that can examine and modify traffic between two (or more) parties on a communication path 👀 very intrusive energy 😭

Network Operator: an entity that manages an AS and therefore emits (E)BGP updates, like an ISP 📣

Network Operations Center (NOC): a network operator uses a set of equipment and a staff to manage a network, usually 24/7 🌙 the equipment and staff are often just called "the NOC" for that network 🫡 the people never sleep, periodt 😴

Prefix: a prefix is an IP address plus a mask, used to specify a set of addresses grouped together for routing purposes 🧩

Public Key Infrastructure (PKI): a PKI is a collection of hardware, software, people, policies, and procedures used to create, manage, distribute, store, and revoke digital certificates 🔐 it's a whole ecosystem, bestie 🥹

Relying Parties (RPs): an RP is an entity that makes use of signed products from a PKI. In other words, it relies on signed data that's verified using certificates and Certificate Revocation Lists (CRLs) from a PKI 🤝

RPKI Repository System: the RPKI repository system is made up of a distributed set of loosely synchronized databases 🗄️ "loosely" is doing a lot of work here 😌

Resource PKI (RPKI): a PKI operated by the entities that manage INRs, which issues X.509 certificates (and CRLs) that attest to who holds which INRs 🎟️

RPKI Signed Object: an RPKI signed object is a data object wrapped in Cryptographic Message Syntax (CMS) that follows the format and semantics defined in [RFC6488] 📦✨

Route: in the Internet, a route is a prefix plus an associated sequence of ASNs that shows a path traffic destined for that prefix can take 🛣️ the route includes the origin AS too 🏁

Route Leak: a route leak happens when AS-A advertises routes it got from AS-B to AS-A's neighbors, but AS-A is not viewed as a transit provider for the prefixes in that route 💧 oops, leaky 🫣

Threat: a threat is a motivated, capable adversary 🎯 an adversary that isn't motivated to attack isn't a threat, and an adversary that's motivated but not capable of attacking also isn't a threat 🙅‍♀️ both ingredients are needed, no cap 🧁

Vulnerability: a vulnerability is a flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy 🕳️

3. Threat Characterization 🎀

okay so, like I said in Section 2, a threat is a motivated, capable adversary 💅 this section goes through the classes of threats that are considered relevant to this environment, aka the classes of adversaries that matter here 👀

Network Operators: a network operator may be a threat 😬 an operator might be motivated to make the BGP routers it controls emit update messages with inaccurate routing info, like to push traffic onto paths that are economically good for the operator 💸 those updates could send traffic over paths that other network operators would otherwise reject as less advantageous 🙃 since an operator controls the BGP routers in its network, it's in a position to change how they operate in arbitrary ways 🕹️ routers managed by a network operator can be used to launch MITM attacks on both control plane and data plane traffic 🚨 if an operator participates in the RPKI, it will have at least one CA resource certificate and may be able to generate an arbitrary number of subordinate CA certificates and ROAs 📜 it will be authorized to populate (and may even host) its own repository publication point 🗃️ if it implements PATHSEC, and if PATHSEC uses certificates tied to routers or ASes, it will be able to issue those certificates for itself 🪪 and if PATHSEC digitally signs updates, it will be able to do that in a way that PATHSEC-enabled neighbors will accept ✍️ the audacity 😤

Hackers: hackers are considered a threat 🧑‍💻 a hacker might take control of network management computers and routers controlled by operators, including operators that implement PATHSEC 💻 in those cases, hackers would be able to act as rogue network operators (see above) 😈 it's assumed that hackers generally can't pull off MITM attacks on most links between networks (links used to carry BGP and subscriber traffic) 🙌 a hacker might be recruited, without their knowledge, by criminals or by nations to act on their behalf 🫠 hackers may be motivated by a desire for "bragging rights," by profit, or to express support for a cause ("hacktivists" [Sam04]) 📢 we see hackers as possibly distinct from criminals, because the former are presumed to carry out attacks only remotely (not through a physical presence at a target) and not necessarily for money 💜 some hackers may commit criminal acts (depending on the jurisdiction), so there's potential overlap between this adversary group and criminals 🌀

Criminals: criminals may be a threat 🕴️ criminals might persuade (through threats or extortion) a network operator to act as a rogue operator (see above), which lets them pull off a wide range of attacks 🎭 criminals might also persuade the staff of a telecommunications provider to enable MITM attacks on links between routers 📞 criminals may be motivated by the ability to extort money from network operators or their clients, like by messing with routing for those operators or their clients 💰 they may also want to manipulate routing to hide the sources of spam, DoS attacks, or other criminal activities 🥷

Registries: any registry in the RPKI could be a threat 🏛️ staff at a registry are capable of manipulating repository content or mismanaging the RPKI certificates they issue 📂 these actions could negatively affect a network operator or a client of a network operator 😵 the staff could be motivated to do this because of political pressure from the nation where the registry operates (see below) or because of criminal influence (see above) 🫤

Nations: a nation may be a threat 🌍 a nation may control one or more network operators operating within it, and so can make them act as rogue network operators 🚩 a nation may have technical active wiretapping capability (for example, within its territory) that lets it carry out MITM attacks on inter-network traffic 📡 (this capability may be made possible through control of or influence over a telecommunications provider operating within the nation) 🗼 a nation may also have the ability to attack and take control of routers or management network computers of network operators in other countries 🌐 a nation may control a registry (like an RIR) that operates within its territory and might force that registry to act in a rogue capacity 🫥 national threat motivations include wanting to control the flow of traffic to and from the nation, or divert traffic destined for other nations (for passive or active wiretapping, including DoS) 🕵️‍♀️

4. Attack Characterization 🔥

this section describes the classes of attacks that may be carried out against Internet routing (in the context described in Section 1) ✨ attacks are classified by their target: either an element of the routing system, or the routing security infrastructure that PATHSEC relies on 🧱 in general, the attacks we care about are the ones that try to violate the integrity or authenticity of BGP traffic, or that violate the authorizations of entities participating in the RPKI 🔒 attacks that violate the implied confidentiality of routing traffic, like passive wiretapping attacks, aren't considered a requirement for BGP security (see [RFC4272]) 👁️ not the focus, bestie 🙅‍♀️

4.1. Active Wiretapping of Sessions between Routers 🦋

an adversary may attack the BGP (TCP) session that connects a pair of BGP speakers 🎯 an active attack against a BGP (TCP) session can be carried out by directing traffic at a BGP speaker from some remote point, or by sitting as a MITM on the link that carries the BGP session traffic 🕷️ remote attacks can be carried out by any adversary 🌍 a MITM attack requires access to the link 🔌 modern transport networks can be as complex as the packet networks that use them for inter-AS links 🧶 so these transport networks may present significant attack surfaces 😳 still, only some classes of adversaries are assumed to be capable of MITM attacks against a BGP session 🫣 MITM attacks may be aimed at BGP and PATHSEC-protected BGP, or at TCP or IP 🎀 these attacks include replay of selected BGP messages, selective modification of BGP messages, and DoS attacks against BGP routers 💥 [RFC4272] describes several countermeasures for such attacks, so this document doesn't address them any further 🫶

4.2. Attacks on a BGP Router 🦋

okay bestie, so an adversary can totally go after a BGP router, whether or not that router does PATHSEC 💅. Anyone who legit controls routers, or who can take over one, is assumed to be able to pull off the types of attacks below ✨. Quick but important: any router behavior that can be chalked up to a local routing policy decision is not considered to be an attack 🙈. That's because it could just be explained by local policy settings, so it's beyond what PATHSEC can detect as unauthorized. So, for example, a router may fail to propagate some or all route withdrawals, or do "route leaks" 🌸. (These behaviors aren't ruled out by the BGP spec and might come from a local policy nobody publicly disclosed, so they're not counted as attacks. See Section 5 for more tea on this 🍓.)

Attacks on a router are basically active wiretapping attacks (in the most general sense) that mess with data in BGP updates, by forging, tampering with, or suppressing it 😭. Here's the list of attacks of this type 👑.

  • AS Insertion: A router might insert one or more ASNs, other than its own ASN, into an update message. This violates the BGP spec, so it's considered an attack 💀.
  • False (Route) Origination: A router might originate a route for a prefix when the AS that the router represents isn't authorized to originate routes for that prefix. This is an attack, but it's handled by the use of the RPKI [RFC6480] 🫶.
  • Secure Path Downgrade: A router might remove AS_PATH data from a PATHSEC-protected update that it receives when it forwards that update to a PATHSEC-enabled neighbor. This breaks the PATHSEC security goals, so it's considered an attack 🔥.
  • Invalid AS_PATH Data Insertion: A router might emit a PATHSEC-protected update with "bad" data (like a signature), i.e., PATHSEC data that other PATHSEC routers can't validate. This is assumed to violate the PATHSEC goals, so it's considered an attack 💅.
  • Stale Path Announcement: If PATHSEC-secured announcements can expire, such an announcement may get propagated with PATHSEC data that is "expired". This would violate the PATHSEC goals and is considered a type of replay attack 🕰️.
  • Premature Path Announcement Expiration: If a PATHSEC-secured announcement has an associated expiration time, a router might emit one with an expiry time that's super short. Unless the PATHSEC protocol specification mandates a minimum expiry time, this is not an attack. But if such a time is mandated, this behavior becomes an attack ✨. BGP speakers along a path generally can't tell if an expiry time is "suspiciously short", since they can't know how long a route may have been held by an earlier AS before it got released 🙈.
  • MITM Attack: A cryptographic key used for point-to-point security (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might get compromised (e.g., by being extracted from a router). That would let an adversary pull off MITM attacks on the link(s) where the key is used 😭. Using specific security mechanisms to protect inter-router links between ASes is outside the scope of PATHSEC 🌈.
  • Compromised Router Private Key: If PATHSEC mechanisms use public key cryptography (e.g., to digitally sign data in an update), then a private key tied to a router or an AS might get compromised by an attack against the router 💜. An adversary with access to that key could generate updates that look like they passed through the AS this router represents. Those updates might get injected on a link between the compromised router and its neighbors, if that link is accessible to the adversary 👀. If the adversary controls another network, they could use the key to forge signatures that appear to come from the AS or router(s) in question, with some constraints. So, for example, an adversary that controls another AS could use a compromised router/AS key to issue PATHSEC-signed data that includes the targeted router/AS 🧚. (Neighbors of the adversary's AS ought not accept a route that purports to come directly from the targeted AS. So an adversary could take a legit, protected route that passes through the compromised AS, add itself as the next hop, and then forward the resulting route to neighbors 🕷️.)
  • Withdrawal Suppression Attack: A PATHSEC-protected update may be signed and announced, and later withdrawn. An adversary controlling intermediate routers could fail to propagate that withdrawal 🙃. BGP is already vulnerable to this sort of behavior, so withdrawal suppression isn't characterized as an attack under the assumptions this mode is based on (i.e., no oracle) 🫠.

4.3. Attacks on Network Operator Management Computers (Non-CA Computers) 🖥️

okay now the attacks on the computers a network operator uses to manage its network, especially its routers 👀. An adversary might do this by compromising the security of those computers. It could happen via remote attacks, extortion of network operations staff, etc. 😬 If an adversary compromises NOC computers, they can execute any management function that the authorized network operations staff would have performed 💅. So the adversary could change the local routing policy to shift preferences, black-hole certain routes, and so on. This type of behavior can't be detected externally as an attack 🙈. From the outside, it looks like rogue operator behavior. (Other operators might see it as accidental or as malicious 🤷‍♀️.)

If a network operator participates in the RPKI, an adversary could mess with the RP tools that extract data from the RPKI, so the output of those tools gets corrupted in various ways 🌀. For example, this kind of attack could make the operator view valid routes as not validated, which could change its routing behavior 😭.

If an adversary invoked the tool used to manage the repository publication point for this operator, they could delete any objects stored there (certificates, CRLs, manifests, ROAs, or subordinate CA certificates) 💀. That could affect the routing status of entities that have allocations/assignments from this network operator (e.g., by deleting their CA certificates) 🥲.

An adversary could invoke the tool used to request certificate revocation, causing router certificates, ROAs, or subordinate CA certificates to get revoked 🚫. An attack like this could affect not only this operator but also any operators that receive allocations/assignments from it, e.g., because their CA certificates got revoked 🌪️.

If an operator is PATHSEC-enabled, an attack like this could make the affected operator look like it's not PATHSEC-enabled, which might make the routes it emits less preferable to other operators 📉.

If an adversary invoked a tool used to request ROAs, they could effectively reallocate some of the prefixes allocated/assigned to the network operator (e.g., by modifying the origin AS in ROAs) 🎭. This might cause other PATHSEC-enabled networks to view the affected network as no longer originating routes for these prefixes. Multi-homed subscribers of this operator who got an allocation from it might find their traffic routed via other connections 🛣️.

If the network operator is PATHSEC-enabled and uses certificates associated with routers/ASes, an adversary could invoke a tool used to request such certificates 🎀. The adversary could then replace valid certificates for routers/ASes with ones that might be rejected by PATHSEC-enabled neighbors 💔.

4.4. Attacks on a Repository Publication Point ✨

okay so the repository system is the critical piece of the RPKI 🗂️💅. An adversary might go after a repository, or a publication point inside one, to mess with routing 💀

This section only covers attacks that can be launched by any adversary who controls a computer hosting one or more repository publication points, without access to the cryptographic keys needed to generate valid RPKI-signed products 🔐. It could be an insider or an external threat 👀. Because every repository object is digitally signed, these attacks basically turn into DoS attacks against the RPKI RPs 🙈. There are a few distinct forms, and we'll go through them below 🫶.

First, the big thing to know: the RPKI calls for RPs to cache the data they acquire and verify from the repository system [RFC6480][RFC6481] 🧠. Attacks that delete signed products, insert products with "bad" signatures, tamper with object signatures, or replace newer objects with older (valid) ones can be detected by RPs (with a few exceptions) 🚨. RPs are expected to make use of local caches 🍓. If repository publication points are unavailable or the retrieved data is corrupted, an RP can revert to the cached data. This behavior helps insulate RPs from the immediate effects of DoS attacks on publication points 🛡️✨.

Each RPKI data object has an associated date on which it expires or is considered stale (certificates expire and CRLs become stale) ⏰. When an RP uses cached data, how to deal with stale or expired data is a local decision 🤷‍♀️. It's common in PKIs to make use of stale certificate revocation status data when fresher data isn't available. Use of expired certificates is less common, although not unknown 👀. Each RP will decide, locally, whether to keep using or ignore cached RPKI objects that are stale or expired 💅.

If an adversary inserts an object into a publication point and the object has a "bad" signature, the object will not be accepted and used by RPs 🚫.

If an adversary modifies any signed product at a publication point, the signature on the product will fail, causing RPs to not accept it. In many respects this is equivalent to deleting the object 🗑️.

If an adversary deletes one or more CA certificates, ROAs, or the CRL for a publication point, the manifest for that publication point will allow an RP to detect this attack 🕵️‍♀️. An RP can keep using the last valid instance of the deleted object (as a local policy option), which minimizes the impact of the attack 🫧.

If an adversary deletes a manifest (and doesn't replace it with an older instance), RPs are able to detect this action 🔍. Such behavior should result in the CA (or publication point maintainer) being notified of the problem 📣. An RP can keep using the last valid instance of the deleted manifest (a local policy option), which minimizes the impact of the attack 🌸.

If an adversary deletes newly added CA certificates or ROAs and replaces the current manifest with the previous manifest, the manifest (and the CRL that it matches) will be "stale" (see [RFC6486]). This alerts an RP that there may be a problem 🚩. The RP should use the information from a Ghostbuster Record [RFC6493] to contact the entity responsible for the publication point and request a remedy (e.g., republish the missing CA certificates and/or ROAs) 📞. An RP can't know the content of the new certificates or ROAs that aren't present, but it can keep using what it has cached 🧠. This kind of attack will, at least temporarily, leave RPs unaware of the newly published objects. INRs associated with these objects will be treated as unauthenticated 😭.

If a CA revokes a CA certificate or a ROA (by deleting the corresponding End Entity (EE) certificate), and the adversary tries to reinstate that CA certificate or ROA, the adversary would have to roll back the CRL and the manifest to undo the CA's action 🔄. As above, this would make the CRL and manifest stale, and RPs can detect that 🚨. An RP can't know which CA certificates or ROAs were deleted. Depending on local policy, the RP might use the cached instances of the affected objects and get tricked into making decisions based on revoked objects 🥀. Here too, the goal is that the CA gets notified of the problem by RPs and fixes the error 🫶.

In the attack scenarios above, when a CRL or manifest is described as stale, this means that its next issue date has passed ⌛. Until the next issue date, an RP won't detect the attack 😶. So it behooves CAs to select CRL/manifest lifetimes (the two are linked) that represent an acceptable trade-off between risk and operational burdens ⚖️💖.

Attacks carried out by adversaries who are legitimate managers of publication points can have much greater effects, and those are discussed below under attacks on or by CAs 👑.

4.5. Attacks on an RPKI CA ✨

Okay bestie, so every entity that has INRs allocated or assigned to it is a CA in the RPKI 🏛️ Each CA is nominally responsible for managing the repository publication point for the set of signed products it generates. (An INR holder may choose to outsource the operation of the RPKI CA function and the associated publication point. In that case, the organization operating on behalf of the INR holder becomes the CA from an operational and security perspective. The discussion below doesn't distinguish outsourced CA operations.)

Note that attacks attributable to a CA may come from malice by the CA (i.e., the CA is the adversary), or they may result from a compromise of the CA. 🙈

All of the adversaries listed in Section 2 are presumed to be capable of launching attacks against the computers used to perform CA functions. Some adversaries might also attack a CA by violating personnel or physical security controls 😭 The difference between the CA as an adversary and the CA as an attack victim is super important. Only in the latter case should one expect the CA to fix problems caused by an attack once the attack has been detected. (If a CA doesn't take that action, the effects are the same as if the CA is an adversary.)

Note that most of the attacks described below don't require disclosing a CA's private key to an adversary. If the adversary can gain control of the computer used to issue certificates, it can carry out these attacks even though the private key for the CA stays "secure" (i.e., not disclosed to unauthorized parties). 💀 However, if the CA isn't the adversary and the CA's private key isn't compromised, then recovering from these attacks is much easier 🎀 This is why hardware security modules are used to protect CA keys, at least for higher tiers in the RPKI. 🔐

An attack by a CA can result in revocation or replacement of any of the certificates the CA has issued. Revoking a certificate should cause RPs to delete the (formerly) valid certificate (and the associated signed object, in the case of a revoked EE certificate) that they have cached. This would make repository objects (e.g., CA certificates and ROAs) that were verified under that certificate invalid, transitively. As a result, RPs wouldn't consider any ROAs or PATHSEC-protected updates to be valid based on these certificates, which would make routes that depend on them less preferred. 😩 Because a CA that revokes a certificate is authorized to do so, most RPs can't detect this sort of attack intrinsically. However, the entities affected by the revocation or replacement of CA certificates can be expected to detect the attack and contact the CA to get it fixed. If the CA wasn't the adversary, it should be able to issue new certificates and restore the publication point. 🦋

An adversary that controls the CA for a publication point can publish signed products that create more subtle types of DoS attacks against RPs. For example, such an attacker could create subordinate CA certificates with Subject Information Access (SIA) pointers that lead RPs on a "wild goose chase" looking for additional publication points and signed products. 🧚 An attacker could also publish certificates with very brief validity intervals, or CRLs and manifests that become "stale" very quickly. This sort of attack would make RPs access repositories more frequently, and that might interfere with legitimate accesses by other RPs.

An attacker with this capability could create very large numbers of ROAs to be processed (with prefixes that are consistent with the allocation for the CA) and correspondingly large manifests. An attacker could also create very deep subtrees with many ROAs per publication point, etc. 😵 All of these types of DoS attacks against RPs are feasible within the syntactic and semantic constraints established for RPKI certificates, CRLs, and signed objects.

An attack that results in revocation and replacement (e.g., key rollover or certificate renewal) of a CA certificate would cause RPs to replace the old, valid certificate with the new one. This new certificate might contain a public key that doesn't correspond to the private key held by the certificate subject. That would cause objects signed by that subject to be rejected as invalid, and prevent the affected subject from signing new objects. As above, RPs wouldn't consider any ROAs issued under the affected CA certificate to be valid, and updates based on router certificates issued by the affected CA would be rejected. This would make routes that depend on these signed products less preferred. 🙃 However, the constraints imposed by the use of extensions detailed in [RFC3779] prevent a compromised CA from issuing (valid) certificates with INRs outside the scope of the CA, which limits the impact of the attack. 👑

An adversary that controls a CA could issue CA certificates with overlapping INRs to different entities when no transfer of INRs is intended. This could confuse RPs, since conflicting ROAs could be issued by the distinct (subordinate) CAs. 🌀

An adversary could replace a CA certificate, use the corresponding private key to issue new signed products, and then publish them at a publication point the attacker controls. This would effectively transfer the affected INRs to the adversary or to a third party of his choosing. The result would be that RPs view the entity controlling the private key in question as the legitimate INR holder. Again, the constraints imposed by the use of the extensions in RFC 3779 prevent a compromised CA from issuing (valid) certificates with INRs outside the scope of the CA, which limits the impact of the attack. 🔥

Finally, an entity that manages a repository publication point can inadvertently act as an attacker (an example of Walt Kelly's most famous "Pogo" quote [Kelly70]) 🐸 For example, a CA might fail to replace its own certificate in a timely fashion (well before it expires). It might fail to issue its CRL and manifest before expiration, creating stale instances of these products that cause concern for RPs. A CA with many subordinate CAs (e.g., an RIR or NIR) might fail to distribute the expiration times for the CA certificates it issues. A network with many ROAs might do the same for the EE certificates associated with the ROAs it generates. A CA could roll over its key but fail to reissue subordinate CA certificates under its new key. Poor planning with regard to rekey intervals for managed CAs could impose undue burdens on RPs, despite a lack of malicious intent. All of these examples of mismanagement could adversely affect RPs, even without any malicious intent. 🥺

5. Residual Vulnerabilities 🩷

The RPKI, which PATHSEC relies on, has several residual vulnerabilities that were discussed in the preceding text (Sections 4.4 and 4.5). These vulnerabilities come in two principle forms:

  • The RPKI repository system may be attacked in ways that make its contents unavailable, not current, or inconsistent. The principle defense against most forms of DoS attacks is the use of a local cache by each RP. The local cache ensures availability of previously acquired RPKI data in the event that a repository is inaccessible or if the repository contents are deleted (maliciously). Nonetheless, the system can't ensure that every RP will always have access to up-to-date RPKI data. When an RP detects a problem with acquired repository data, it has two options:
    1. The RP may choose to make use of its local cache, employing local configuration settings that tolerate expired or stale objects. (Such behavior is, nominally, always within the purview of an RP in PKI.) Using cached, expired, or stale data subjects the RP to attacks that take advantage of the RP's ignorance of changes to this data.
    2. The RP may chose to purge expired objects. Purging expired objects removes the security information associated with the real-world INRs to which the objects refer. This is equivalent to the affected INRs not having been afforded protection via the RPKI. Since use of the RPKI (and PATHSEC) is voluntary, there may always be a set of INRs that aren't protected by these mechanisms. Thus, purging moves the affected INRs to the set of non-participating INR holders. This more conservative response enables an attacker to move INRs from the protected set to the unprotected set. 😬
  • Any CA in the RPKI may misbehave within the bounds of the INRs allocated to it, e.g., it may issue certificates with duplicate resource allocations or revoke certificates inappropriately. This vulnerability is intrinsic to any PKI, but its impact is limited in the RPKI because of the use of extensions in RFC 3779. It is anticipated that RPs will deal with such misbehavior through administrative means once it is detected. 📋

PATHSEC has a separate set of residual vulnerabilities:

  • It has been stated that "route leaks" are viewed as a routing security problem by many operators. However, BGP itself doesn't include semantics that preclude what many perceive as route leaks, and there is no definition of the term in any RFC. This makes it inappropriate to address route leaks in this document. Additionally, route leaks are outside the scope of PATHSEC, consistent with the security context noted in Section 1 of this document. If, at a later time, the SIDR security context is revised to include route leaks, and an appropriate definition exists, this document should be revised. 🌷
  • PATHSEC isn't required to protect all attributes associated with an AS_PATH, even though some of these attributes may be used as inputs to routing decisions. Thus, attacks that modify (or strip) these other attributes aren't prevented or detected by PATHSEC. As noted in Section 1, the SIDR security context calls for protecting only the information needed to verify that a received route traversed the ASes in question, and that the NLRI in the route is what was advertised. (The AS_PATH data also may have traversed ASes within a confederation that aren't represented. However, these ASes aren't externally visible and thus don't influence route selection, so their omission in this context isn't a security concern.) Thus, protection of other attributes is outside the scope of this document, as described in Section 1. If, at a later time, the SIDR security context is revised to include protection of additional BGP attributes, this document should be revised. 🧩
  • PATHSEC can't ensure that an AS will withdraw a route when the AS no longer has a route for a prefix, as noted in Section 4.2. PATHSEC may incorporate features to limit the lifetime of an advertisement. Such lifetime limits provide an upper bound on the time that the failure to withdraw a route will remain effective. ⏳

6. Security Considerations ✨

Okay, bestie, this one is the security section, so it's a whole vibe. A threat model is basically a security-centric doc by definition 🔒 It doesn't create security problems, and it doesn't claim to fix them either. What it does is lay out a set of threats (motivated, capable adversaries 😈), look at the kinds of attacks those threats could pull off based on what they're trying to achieve, and explain how those attacks would hit PATHSEC, including the RPKI that PATHSEC leans on 🫶 It also explains how the RPKI design (and the PATHSEC design goals) handle those attack classes where that applies, and it calls out the residual vulnerabilities that are still hanging around 🥀

7. Acknowledgements 💜

We wish to thank the members of the SIDR working group for all the super thorough feedback they gave while this document was being built 🙌 Iconic of them honestly.

8. Informative References 📚

  • [Kelly70] Kelly, W., "We Have Met The Enemy and He Is Us: Pogo Earth Day Poster", April 1970. 🌍
  • [Kent2000] Kent, S., Lynn, C., and K. Seo, "Design and Analysis of the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX Conference, June 2000. 🛡️
  • [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. 🎀
  • [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 🌐
  • [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006. 🔍
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 🏰
  • [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. 🔐
  • [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. 🧩
  • [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012. 🗂️
  • [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012. 📜
  • [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012. 📋
  • [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012. 🪪
  • [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012. ✍️
  • [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012. 👻
  • [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, January 2013. 🔁
  • [SIDR-CH] "Secure Inter-Domain Routing: Charter for Working Group", September 2013, http://tools.ietf.org/wg/sidr/charters?item=charter-sidr-2013-09-20.txt. 🗺️
  • [Sam04] Samuel, A., "Hacktivism and the Future of Political Participation", Ph.D. dissertation, Harvard University, September 2004, http://www.alexandrasamuel.com/dissertation/pdfs/Samuel-Hacktivism-entire.pdf. 🎓

Authors' Addresses 🦋

Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA  02138
USA

EMail: kent@bbn.com


Andrew Chi
University of North Carolina - Chapel Hill
c/o Department of Computer Science
CB 3175, Sitterson Hall
Chapel Hill, NC  27599
USA

EMail: achi@cs.unc.edu
📦 where this page comes from