| Secure Inter-Domain Routing | S. Kent |
| Internet-Draft | BBN |
| Intended status: Informational | A. Chi |
| Expires: May 26, 2014 | UNC-CH |
| November 22, 2013 |
Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-08
This document describes a threat model for the context in which Exterior Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI), and focuses on the ability of an autonomous system (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI.
The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with brief discussion of residual vulnerabilities.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 26, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes the security context in which PATHSEC is intended to operate. The term "PATHSEC" (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 goal of PATHSEC is to enable a BGP speaker to verify that the Autonomous Systems (ASes) enumerated in this path attribute represent the sequence of ASes that the Network Layer Reachability Information (NLRI) traversed. The term PATHSEC is thus consistent with the goal described in the SIDR WG charter. (Other SIDR documents use the term "BGPSEC" to refer to a specific design, thus we avoid use of that term here.)
This document discusses classes of potential adversaries that are considered to be threats, and classes of attacks that might be launched against PATHSEC. The SIDR charter requires that solutions that afford PATHSEC must make use of the Resource Public Key Infrastructure (RPKI) [RFC6480]. Because PATHSEC will rely on the RPKI, threats and attacks against the RPKI are included. This model also takes into consideration classes of attacks that are enabled by the use of PATHSEC (e.g., based on use of the RPKI).
The motivation for developing PATHSEC, i.e., residual security concerns for BGP, is well described in several documents, including "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000]. All of these documents note that BGP does not include mechanisms that allow an Autonomous System (AS) to verify the legitimacy and authenticity of BGP route advertisements. (BGP now mandates support for mechanisms to secure peer-peer communication, i.e., for the links that connect BGP routers. There are several secure protocol options to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO [RFC5925]. This document briefly notes the need to address this aspect of BGP security, but focuses on application layer BGP security issues that must be addressed by PATHSEC.)
RFC 4272 [RFC4272] succinctly notes:
PATHSEC is intended to address the concerns cited above, to provide significantly improved path security, building upon the route origination validation capability offered by use of the RPKI [RFC6810]. Specifically, the RPKI enables relying parties (RPs) to determine if the origin AS for a path was authorized to advertise the prefix contained in a BGP update message. This security feature is enabled by the use of two types of digitally signed data: a PKI [RFC6487] that associates one or more prefixes with the public key(s) of an address space holder, and Route Origination Authorizations (ROAs) [RFC6482] that allows a prefix holder to specify the AS(es) that are authorized to originate routes for a prefix.
The security model adopted for PATHSEC does not assume an "oracle" that can see all of the BGP inputs and outputs associated with every AS or every BGP router. Instead, the model is based on a local notion of what constitutes legitimate, authorized behavior by the BGP routers associated with an AS. This is an AS-centric model of secure operation, consistent with the AS-centric model that BGP employs for routing. This model forms the basis for the discussion that follows.
This document begins with a brief set of definitions relevant to the subsequent sections. It then discusses classes of adversaries that are perceived as viable threats against routing in the public Internet. It continues to explore a range of attacks that might be effected by these adversaries, against both path security and the infrastructure upon which PATHSEC relies. It concludes with a brief review of residual vulnerabilities, i.e., vulnerabilities that are not addressed by use of the RPKI and that appear likely to be outside the scope of PATHSEC mechanisms.
The following security and routing terminology definitions are employed in this document.
Adversary - An adversary is an entity (e.g., a person or an organization) perceived as malicious, relative to the security policy of a system. The decision to characterize an entity as an adversary is made by those responsible for the security of a system. Often one describes classes of adversaries with similar capabilities or motivations, rather than specific individuals or organizations.
Attack - An attack is an action that attempts to violate the security policy of a system, e.g., by exploiting a vulnerability. There is often a many to one mapping of attacks to vulnerabilities, because many different attacks may be used to exploit a vulnerability.
Autonomous System (AS) - An AS is a set of one or more IP networks operated by a single administrative entity.
AS Number (ASN) - An ASN is a 2 or 4 byte number issued by a registry to identify an AS in BGP.
Certification Authority (CA) - An entity that issues digital certificates (e.g., 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, preventing it from being successful. Often countermeasures are specific to attacks or classes of attacks.
Border Gateway Protocol (BGP) - A path vector protocol used to convey "reachability" information among autonomous systems, in support of inter-domain routing.
False (Route) Origination - If a network operator originates a route for a prefix that the operator does not hold (and that it has not been authorized to originate by the prefix holder, this is termed false route origination.
Internet Service Provider (ISP) - An organization managing (and, typically, selling,) Internet services to other organizations or individuals.
Internet Number Resources (INRs) - IPv4 or IPv6 address space and ASNs
Internet Registry - An organization that manages the allocation or distribution of INRs. This encompasses the Internet Assigned Number Authority (IANA), Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs, network operators).
Man in the Middle (MITM) - A MITM is an entity that is able to examine and modify traffic between two (or more) parties on a communication path.
Network Operator - An entity that manages an AS and thus emits (E)BGP updates, e.g., an ISP.
NOC (Network Operations Center) – A network operator employs a set equipment and a staff to manage a network, typically on a 24/7 basis. The equipment and staff are often referred to as the NOC for the network.
Prefix - A prefix is an IP address and a mask used to specify a set of addresses that are grouped together for purposes of routing.
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.
Relying Parties (RPs) - An RP is an entity that makes use of signed products from a PKI, i.e., relies on signed data that is verified using certificates and Certificate Revocation Lists (CRLs) from a PKI.
RPKI Repository System - The RPKI repository system consists of a distributed set of loosely synchronized databases.
Resource PKI (RPKI) - A PKI operated by the entities that manage INRs, and that issues X.509 certificates (and CRLs) that attest to the holdings of INRs.
RPKI Signed Object - An RPKI signed object is a Cryptographic Message Syntax (CMS)-encapsulated data object complying with the format and semantics defined in [RFC6488].
Route - In the Internet, a route is a prefix and an associated sequence of ASNs that indicates a path via which traffic destined for the prefix can be directed. (The route includes the origin AS.)
Route leak - A route leak is said to occur when AS-A advertises routes that it has received from an AS-B to AS-A's neighbors, but AS-A is not viewed as a transit provider for the prefixes in the route.
Threat - A threat is a motivated, capable adversary. An adversary that is not motivated to launch an attack is not a threat. An adversary that is motivated but not capable of launching an attack also is not a threat.
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 security policy of a system.
As noted in Section 2 above, a threat is defined as a motivated, capable, adversary. The following classes of threats represent classes of adversaries viewed as relevant to this environment.
Network Operators - A network operator may be a threat. An operator may be motivated to cause BGP routers it controls to emit update messages with inaccurate routing info, e.g., to cause traffic to flow via paths that are economically advantageous for the operator. Such updates might cause traffic to flow via paths that would otherwise be rejected as less advantageous by other network operators. Because an operator controls the BGP routers in its network, it is in a position to modify their operation in arbitrary ways. Routers managed by a network operator are vehicles for mounting MITM attacks on both control 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 makes use of certificates associated with routers or ASes, it will have the ability to issue such certificates for itself. If PATHSEC digitally signs updates, it will be able to do so in a fashion that will be accepted by PATHSEC-enabled neighbors.
Hackers - Hackers are considered a threat. A hacker might assume control of network management computers and routers controlled by operators, including operators that implement PATHSEC. In such cases, hackers would be able to act as rogue network operators (see above). It is assumed that hackers generally do not have the capability to effect MITM attacks on most links between networks (links used to transmit BGP and subscriber traffic). A hacker might be recruited, without his/her knowledge, by criminals or by nations, to act on their behalf. Hackers may be motivated by a desire for "bragging rights" or for profit or to express support for a cause ("hacktivists" [Sam04]). We view hackers as possibly distinct from criminals in that the former are presumed to effect attacks only remotely (not via a physical presence associated with a target) and not necessarily for monetary gain. Some hackers may commit criminal acts (depending on the jurisdiction), and thus there is a potential for overlap between this adversary group and criminals.
Criminals - Criminals may be a threat. Criminals might persuade (via threats or extortion) a network operator to act as a rogue operator (see above), and thus be able to effect a wide range of attacks. Criminals might persuade the staff of a telecommunications provider to enable MITM attacks on links between routers. Motivations for criminals may include the ability to extort money from network operators or network operator clients, e.g., by adversely affecting routing for these network operators or their clients. Criminals also may wish to manipulate routing to conceal the sources of spam, DoS attacks, or other criminal activities.
Registries - Any registry in the RPKI could be a threat. Staff at the registry are capable of manipulating repository content or mismanaging the RPKI certificates that they issue. These actions could adversely affect a network operator or a client of a network operator. The staff could be motivated to do this based on political pressure from the nation in which the registry operates (see below) or due to criminal influence (see above).
Nations - A nation may be a threat. A nation may control one or more network operators that operate in the nation, and thus can cause them to act as rogue network operators. A nation may have a technical active wiretapping capability (e.g., within its territory) that enables it to effect MITM attacks on inter-network traffic. (This capability may be facilitated by control or influence over a telecommunications provider operating within the nation.) It may have an ability to attack and take control of routers or management network computers of network operators in other countries. A nation may control a registry (e.g., an RIR) that operates within its territory, and might force that registry to act in a rogue capacity. National threat motivations include the desire to control the flow of traffic to/from the nation or to divert traffic destined for other nations (for passive or active wiretapping, including DoS).
This section describes classes of attacks that may be effected against Internet routing (relative to the context described in Section 1). Attacks are classified based on the target of the attack, as an element of the routing system, or the routing security infrastructure on which PATHSEC relies. In general, attacks of interest are ones that attempt to violate the integrity or authenticity of BGP traffic, or which violate the authorizations associated with entities participating in the RPKI. Attacks that violate the implied confidentiality of routing traffic, e.g., passive wiretapping attacks, are not considered a requirement for BGP security (see [RFC4272]).
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 effected by directing traffic to a BGP speaker from some remote point, or by being positioned as a MITM on the link that carries BGP session traffic. Remote attacks can be effected by any adversary. A MITM attack requires access to the link. Modern transport networks may be as complex as the packet networks that utilize them for inter-AS links. Thus these transport networks may present significant attack surfaces. Nonetheless, only some classes of adversaries are assumed to be capable of MITM attacks against a BGP session. MITM attacks may be directed against BGP, PATHSEC-protected BGP, or against TCP or IP. Such 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, and thus this document does not further address such attacks.
An adversary may attack a BGP router, whether it implements PATHSEC or not. Any adversary that controls routers legitimately, or that can assume control of a router, is assumed to be able to effect the types of attacks described below. Note that any router behavior that can be ascribed to a local routing policy decision is not considered to be an attack. This is because such behavior could be explained as a result of local policy settings, and thus is beyond the scope of what PATHSEC can detect as unauthorized behavior. Thus, for example, a router may fail to propagate some or all route withdrawals or effect "route leaks". (These behaviors are not precluded by the specification for BGP, and might be the result of a local policy that is not publicly disclosed. As a result, they are not considered attacks. See Section 5 for additional discussion.)
Attacks on a router are equivalent to active wiretapping attacks (in the most general sense) that manipulate (forge, tamper with, or suppress) data contained in BGP updates. The list below illustrates attacks of this type.
An adversary may choose to attack computers used by a network operator to manage its network, especially its routers. Such attacks might be effected by an adversary who has compromised the security of these computers. This might be effected via remote attacks, extortion of network operations staff, etc. If an adversary compromises NOC computers, he can execute any management function that authorized network operations staff would have performed. Thus the adversary could modify local routing policy to change preferences, to black-hole certain routes, etc. This type of behavior cannot be externally detected as an attack. Externally, this appears as a form of rogue operator behavior. (Such behavior might be perceived as accidental or malicious by other operators.)
If a network operator participates in the RPKI, an adversary could manipulate the RP tools that extract data from the RPKI, causing the output of these tools to be corrupted in various ways. For example, an attack of this sort could cause the operator to view valid routes as not validated, which could alter its routing behavior.
If an adversary invoked the tool used to manage the repository publication point for this operator, it could delete any objects stored there (certificates, CRLs, manifests, ROAs, or subordinate CA certificates). This 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 be revoked. An attack of this sort could affect not only this operator, but also any operators that receive allocations/assignments from it, e.g., because their CA certificates were revoked.
If an operator is PATHSEC-enabled, an attack of this sort could cause the affected operator to be viewed as not PATHSEC-enabled, possibly making routes it emits be less preferred by other operators.
If an adversary invoked a tool used to request ROAs, it could effectively re-allocate 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 received an allocation from the operator might find their traffic was now routed via other connections.
If the network operator is PATHSEC-enabled, and make use of 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.
A critical element of the RPKI is the repository system. An adversary might attack a repository, or a publication point within a repository, to adversely affect routing.
This section considers only those 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. Such attacks might be effected by an insider or an external threat. Because all repository objects are digitally signed, attacks of this sort translate into DoS attacks against the RPKI RPs. There are a few distinct forms of such attacks, as described below.
Note first that the RPKI calls for RPs to cache the data they acquire and verify from the repository system [RFC6480][RFC6481]. Attacks that delete signed products, that insert products with "bad" signatures, that tamper with object signatures, or that 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 using 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 at which it expires, or is considered stale. (Certificates expire, CRLs become stale.) When an RP uses cached data it is a local decision how to deal with stale or expired data. It is common in PKIs to make use of stale certificate revocation status data, when fresher data is not available. Use of expired certificates is less common, although not unknown. Each RP will decide, locally, whether to continue to make use of 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. This is equivalent to deleting the object, in many respects.
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 continue to use the last valid instance of the deleted object (as a local policy option), thus minimizing the impact of such an attack.
If an adversary deletes a manifest (and does not replace it with an older instance), that is detectable by RPs. Such behavior should result in the CA (or publication point maintainer) being notified of the problem. An RP can continue to use the last valid instance of the deleted manifest (a local policy option), thus minimizing the impact of such an 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, requesting that entity to remedy the problem (e.g., republish the missing CA certificates and/or ROAs). An RP cannot know the content of the new certificates or ROAs that are not present, but it can continue to use what it has cached. An attack of this sort will, at least temporarily, cause RPs to be 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 (via deleting the corresponding EE certificate), and the adversary tries to reinstate that CA certificate or ROA, the adversary would have to rollback the CRL and the manifest to undo this action by the CA. As above, this would make the CRL and manifest stale, and this is detectable by RPs. An RP cannot know which CA certificates or ROAs were deleted. Depending on local policy, the RP might use the cached instances of the affected objects, and thus be tricked into making decisions based on these revoked objects. Here too the goal is that the CA will be notified of the problem (by RPs) and will remedy the error.
In the attack scenarios above, when a CRL or manifest is described as stale, this means that the next issue date for the CRL or manifest has passed. Until the next issue date, an RP will not detect the attack. Thus it behooves CAs to select CRL/manifest lifetimes (the two are linked) that represent an acceptable trade-off between risk and operational burdens.
Attacks effected by adversaries that are legitimate managers of publication points can have much greater effects, and are discussed below under attacks on or by CAs.
Every entity to which INRs have been allocated/assigned is a CA in the RPKI. Each CA is nominally responsible for managing the repository publication point for the set of signed products that it generates. (An INR holder may choose to outsource the operation of the RPKI CA function, and the associated publication point. In such cases, the organization operating on behalf of the INR holder becomes the CA, from an operational and security perspective. The following discussion does not distinguish such outsourced CA operations.)
Note that attacks attributable to a CA may be the result of malice by the CA (i.e., the CA is the adversary) or they may result from a compromise of the CA.
All of adversaries listed in Section 2 are presumed to be capable of launching attacks against the computers used to perform CA functions. Some adversaries might effect an attack on a CA by violating personnel or physical security controls as well. The distinction between CA as adversary vs. CA as an attack victim is important. Only in the latter case should one expect the CA to remedy problems caused by a attack once the attack has been detected. (If a CA does not take such action, the effects are the same as if the CA is an adversary.)
Note that most of the attacks described below do not require disclosure of a CA's private key to an adversary. If the adversary can gain control of the computer used to issue certificates, it can effect these attacks, even though the private key for the CA remains "secure" (i.e., not disclosed to unauthorized parties). However, if the CA is not the adversary, and if the CA's private key is not compromised, then recovery from these attacks is much easier. This motivates use of hardware security modules 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 that the CA has issued. Revocation of a certificate should cause RPs to delete the (formerly) valid certificate (and associated signed object, in the case of a revoked EE certificate) that they have cached. This would cause repository objects (e.g., CA certificates and ROAs) that are verified under that certificate to be considered invalid, transitively. As a result, RPs would not consider as valid any ROAs or PATHSEC-protected updates based on these certificates, which would make routes dependent on them to be less preferred. Because a CA that revokes a certificate is authorized to do so, this sort of attack cannot be detected, intrinsically, by most RPs. However, the entities affected by the revocation or replacement of CA certificates can be expected to detect the attack and contact the CA to effect remediation. If the CA was not 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 publish certificates with very brief validity intervals, or CRLs and manifests that become "stale" very quickly. This sort of attack would cause RPs to 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 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 does not 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 being able to sign new objects. As above, RPs would not consider as valid any ROAs issued under the affected CA certificate, and updates based on router certificates issued by the affected CA would be rejected. This would make routes dependent on these signed products to be less preferred. However, the constraints imposed by the use of RFC 3779 [RFC3779] extensions do prevent a compromised CA from issuing (valid) certificates with INRs outside the scope of the CA, thus limiting 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 cause confusion for RPs as 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 controlled by the attacker. This would effectively transfer the affected INRs to the adversary, or to a third party of his choosing. The result would be to cause RPs to view the entity that controls the private key in question as the legitimate INR holder. Again the constraints imposed by the use of RFC 3779 extensions prevent a compromised CA from issuing (valid) certificates with INRs outside the scope of the CA, thus limiting 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). If might fail to issue its CRL and manifest prior to 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 that it issues. A network with many ROAs might do the same for the EE certificates associated with the ROAs it generates. A CA could rollover 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 for RPs, despite a lack of malicious intent. All of these example of mismanagement could adversely affect RPs, despite the absence of malicious intent.
The RPKI, upon which PATHSEC relies, has several residual vulnerabilities that were discussed in the preceding text (Section 4.4 and Section 4.5). These vulnerabilities are of two principle forms:
PATHSEC has a separate set of residual vulnerabilities:
A threat model is, by definition, a security-centric document. Unlike a protocol description, a threat model does not create security problems nor purport to address security problems. This model postulates a set of threats (i.e., motivated, capable adversaries) and examines classes of attacks that these threats are capable of effecting, based on the motivations ascribed to the threats. It describes the impact of these types of attacks on PATHSEC, including on the RPKI on which PATHSEC relies. It describes how the design of the RPKI (and the PATHSEC design goals) address classes of attacks, where applicable. It also notes residual vulnerabilities.
[Note to IANA, to be removed prior to publication: there are no IANA considerations stated in this version of the document.]
TBD