draft-ietf-sidr-bgpsec-threats-09.txt   rfc7132.txt 
Secure Inter-Domain Routing S. Kent Internet Engineering Task Force (IETF) S. Kent
Internet-Draft BBN Request for Comments: 7132 BBN
Intended status: Informational A. Chi Category: Informational A. Chi
Expires: June 14, 2014 UNC-CH ISSN: 2070-1721 UNC-CH
December 11, 2013 February 2014
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-09
Abstract Abstract
This document describes a threat model for the context in which This document describes a threat model for the context in which
Exterior Border Gateway Protocol (EBGP) path security mechanisms will External Border Gateway Protocol (EBGP) path security mechanisms will
be developed. The threat model includes an analysis of the Resource be developed. The threat model includes an analysis of the Resource
Public Key Infrastructure (RPKI), and focuses on the ability of an Public Key Infrastructure (RPKI) and focuses on the ability of an
autonomous system (AS) to verify the authenticity of the AS path info 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 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 BGP path security technology that makes use of the RPKI. PATHSEC
will secure BGP, consistent with the inter-AS security focus of the will secure BGP, consistent with the inter-AS security focus of the
RPKI. RPKI.
The document characterizes classes of potential adversaries that are The document characterizes classes of potential adversaries that are
considered to be threats, and examines classes of attacks that might considered to be threats and examines classes of attacks that might
be launched against PATHSEC. It does not revisit attacks against be launched against PATHSEC. It does not revisit attacks against
unprotected BGP, as that topic has already been addressed in the unprotected BGP, as that topic has already been addressed in the
BGP-4 standard. It concludes with brief discussion of residual BGP-4 standard. It concludes with a brief discussion of residual
vulnerabilities. vulnerabilities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on June 14, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7132.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6
4. Attack Characterization . . . . . . . . . . . . . . . . . . . 8 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 8
4.1. Active wiretapping of sessions between routers . . . . . 8 4.1. Active Wiretapping of Sessions between Routers . . . . . 8
4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 9 4.2. Attacks on a BGP Router . . . . . . . . . . . . . . . . . 9
4.3. Attacks on network operator management computers (non-CA 4.3. Attacks on Network Operator Management Computers (Non-CA
computers) . . . . . . . . . . . . . . . . . . . . . . . 10 Computers) . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Attacks on a repository publication point . . . . . . . . 12 4.4. Attacks on a Repository Publication Point . . . . . . . . 12
4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 14 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 14
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Informative References . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document describes the security context in which PATHSEC is This document describes the security context in which PATHSEC is
intended to operate. The term "PATHSEC" (for path security) refers intended to operate. The term "PATHSEC" (for path security) refers
to any design used to preserve the integrity and authenticity of the to any design used to preserve the integrity and authenticity of the
AS_PATH attribute carried in a BGP update message [RFC4271]. The AS_PATH attribute carried in a BGP update message [RFC4271]. The
security context used throughout this document is established by the security context used throughout this document is established by the
SIDR charter [SIDR-CH]. The charter requires that solutions that Secure Inter-Domain Routing (SIDR) working group charter [SIDR-CH].
afford PATHSEC make use of the Resource Public Key Infrastructure The charter requires that solutions that afford PATHSEC make use of
(RPKI) [RFC6480]. It also calls for protecting only the information the Resource Public Key Infrastructure (RPKI) [RFC6480]. It also
required to verify that a received route traversed the Autonomous calls for protecting only the information required to verify that a
Systems (ASes) in question, and that the Network Layer Reachability received route traversed the Autonomous Systems (ASes) in question,
Information (NLRI) in the route is what was advertised. and that the Network Layer Reachability Information (NLRI) in the
route is what was advertised.
Thus the goal of PATHSEC is to enable a BGP speaker to verify that Thus, the goal of PATHSEC is to enable a BGP speaker to verify that
the ASes enumerated in this path attribute represent the sequence of the ASes enumerated in this path attribute represent the sequence of
ASes that the NLRI traversed. The term PATHSEC is thus consistent ASes that the NLRI traversed. The term "PATHSEC" is thus consistent
with the goal described above. (Other SIDR documents use the term with the goal described above. (Other SIDR documents use the term
"BGPSEC" to refer to a specific design, thus we avoid use of that "BGPSEC" to refer to a specific design; we avoid use of that term
term here.) here.)
This document discusses classes of potential adversaries that are This document discusses classes of potential adversaries that are
considered to be threats, and classes of attacks that might be considered to be threats, and classes of attacks that might be
launched against PATHSEC. Because PATHSEC will rely on the RPKI, launched against PATHSEC. Because PATHSEC will rely on the RPKI,
threats and attacks against the RPKI are included. This model also threats and attacks against the RPKI are included. This model also
takes into consideration classes of attacks that are enabled by the takes into consideration classes of attacks that are enabled by the
use of PATHSEC (e.g., based on use of the RPKI). use of PATHSEC (e.g., based on use of the RPKI).
The motivation for developing PATHSEC, i.e., residual security The motivation for developing PATHSEC, i.e., residual security
concerns for BGP, is well described in several documents, including concerns for BGP, is well described in several documents, including
"BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and
Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000]. Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000].
All of these documents note that BGP does not include mechanisms that All of these documents note that BGP does not include mechanisms that
allow an Autonomous System (AS) to verify the legitimacy and allow an AS to verify the legitimacy and authenticity of BGP route
authenticity of BGP route advertisements. (BGP now mandates support advertisements. (BGP now mandates support for mechanisms to secure
for mechanisms to secure peer-peer communication, i.e., for the links peer-to-peer communication, i.e., for the links that connect BGP
that connect BGP routers. There are several secure protocol options routers. There are several secure protocol options to address this
to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO security concern, e.g., IPsec [RFC4301] and TCP Authentication Option
[RFC5925]. This document briefly notes the need to address this (TCP-AO) [RFC5925]. This document briefly notes the need to address
aspect of BGP security, but focuses on application layer BGP security this aspect of BGP security, but focuses on application layer BGP
issues that must be addressed by PATHSEC.) security issues that must be addressed by PATHSEC.)
RFC 4272 [RFC4272] succinctly notes: RFC 4272 [RFC4272] succinctly notes:
"BGP speakers themselves can inject bogus routing information, BGP speakers themselves can inject bogus routing information,
either by masquerading as any other legitimate BGP speaker, or by either by masquerading as any other legitimate BGP speaker, or by
distributing unauthorized routing information as themselves. distributing unauthorized routing information as themselves.
Historically, misconfigured and faulty routers have been Historically, misconfigured and faulty routers have been
responsible for widespread disruptions in the Internet. The responsible for widespread disruptions in the Internet. The
legitimate BGP peers have the context and information to produce legitimate BGP peers have the context and information to produce
believable, yet bogus, routing information, and therefore have the believable, yet bogus, routing information, and therefore have the
opportunity to cause great damage. The cryptographic protections opportunity to cause great damage. The cryptographic protections
of [TCPMD5] and operational protections cannot exclude the bogus of [TCPMD5] and operational protections cannot exclude the bogus
information arising from a legitimate peer. The risk of information arising from a legitimate peer. The risk of
disruptions caused by legitimate BGP speakers is real and cannot disruptions caused by legitimate BGP speakers is real and cannot
be ignored." be ignored.
PATHSEC is intended to address the concerns cited above, to provide PATHSEC is intended to address the concerns cited above, to provide
significantly improved path security, building upon the route significantly improved path security, which builds upon the route
origination validation capability offered by use of the RPKI origination validation capability offered by use of the RPKI
[RFC6810]. Specifically, the RPKI enables relying parties (RPs) to [RFC6810]. Specifically, the RPKI enables relying parties (RPs) to
determine if the origin AS for a path was authorized to advertise the determine if the origin AS for a path was authorized to advertise the
prefix contained in a BGP update message. This security feature is prefix contained in a BGP update message. This security feature is
enabled by the use of two types of digitally signed data: a PKI 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) [RFC6487] that associates one or more prefixes with the public key(s)
of an address space holder, and Route Origination Authorizations of an address space holder, and Route Origin Authorizations (ROAs)
(ROAs) [RFC6482] that allows a prefix holder to specify the AS(es) [RFC6482] that allow a prefix holder to specify one or more ASes that
that are authorized to originate routes for a prefix. are authorized to originate routes for a prefix.
The security model adopted for PATHSEC does not assume an "oracle" The security model adopted for PATHSEC does not assume an "oracle"
that can see all of the BGP inputs and outputs associated with every 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 AS or every BGP router. Instead, the model is based on a local
notion of what constitutes legitimate, authorized behavior by the BGP notion of what constitutes legitimate, authorized behavior by the BGP
routers associated with an AS. This is an AS-centric model of secure routers associated with an AS. This is an AS-centric model of secure
operation, consistent with the AS-centric model that BGP employs for operation, consistent with the AS-centric model that BGP employs for
routing. This model forms the basis for the discussion that follows. routing. This model forms the basis for the discussion that follows.
This document begins with a brief set of definitions relevant to the This document begins with a brief set of definitions relevant to the
subsequent sections. It then discusses classes of adversaries that subsequent sections. It then discusses classes of adversaries that
are perceived as viable threats against routing in the public are perceived as viable threats against routing in the public
Internet. It continues to explore a range of attacks that might be Internet. It continues to explore a range of attacks that might be
effected by these adversaries, against both path security and the effected by these adversaries against both path security and the
infrastructure upon which PATHSEC relies. It concludes with a brief infrastructure upon which PATHSEC relies. It concludes with a brief
review of residual vulnerabilities, i.e., vulnerabilities that are review of residual vulnerabilities, i.e., vulnerabilities that are
not addressed by use of the RPKI and that appear likely to be outside not addressed by use of the RPKI and that appear likely to be outside
the scope of PATHSEC mechanisms. the scope of PATHSEC mechanisms.
2. Terminology 2. Terminology
The following security and routing terminology definitions are The following security and routing terminology definitions are
employed in this document. employed in this document.
Adversary - An adversary is an entity (e.g., a person or an Adversary: An adversary is an entity (e.g., a person or an
organization) perceived as malicious, relative to the security policy organization) that is perceived as malicious, relative to the
of a system. The decision to characterize an entity as an adversary security policy of a system. The decision to characterize an
is made by those responsible for the security of a system. Often one entity as an adversary is made by those responsible for the
describes classes of adversaries with similar capabilities or security of a system. Often, one describes classes of adversaries
motivations, rather than specific individuals or organizations. with similar capabilities or motivations rather than specific
individuals or organizations.
Attack - An attack is an action that attempts to violate the security Attack: An attack is an action that attempts to violate the security
policy of a system, e.g., by exploiting a vulnerability. There is policy of a system, e.g., by exploiting a vulnerability. There is
often a many to one mapping of attacks to vulnerabilities, because often a many-to-one mapping of attacks to vulnerabilities because
many different attacks may be used to exploit a vulnerability. many different attacks may be used to exploit a vulnerability.
Autonomous System (AS) - An AS is a set of one or more IP networks Autonomous System (AS): An AS is a set of one or more IP networks
operated by a single administrative entity. operated by a single administrative entity.
AS Number (ASN) - An ASN is a 2 or 4 byte number issued by a registry AS Number (ASN): An ASN is a 2- or 4-byte number issued by a
to identify an AS in BGP. registry to identify an AS in BGP.
Certification Authority (CA) - An entity that issues digital Certification Authority (CA): An entity that issues digital
certificates (e.g., X.509 certificates) and vouches for the binding certificates (e.g., X.509 certificates) and vouches for the
between the data items in a certificate. binding between the data items in a certificate.
Countermeasure - A countermeasure is a procedure or technique that Countermeasure: A countermeasure is a procedure or technique that
thwarts an attack, preventing it from being successful. Often thwarts an attack, preventing it from being successful. Often,
countermeasures are specific to attacks or classes of attacks. countermeasures are specific to attacks or classes of attacks.
Border Gateway Protocol (BGP) - A path vector protocol used to convey Border Gateway Protocol (BGP): A path vector protocol used to convey
"reachability" information among autonomous systems, in support of "reachability" information among ASes in support of inter-domain
inter-domain routing. routing.
False (Route) Origination - If a network operator originates a route False (Route) Origination: If a network operator originates a route
for a prefix that the operator does not hold (and that it has not for a prefix that the operator does not hold (and that has not
been authorized to originate by the prefix holder, this is termed been authorized to originate by the prefix holder), this is termed
false route origination. false route origination.
Internet Service Provider (ISP) - An organization managing (and, Internet Service Provider (ISP): An organization managing (and
typically, selling,) Internet services to other organizations or typically selling) Internet services to other organizations or
individuals. individuals.
Internet Number Resources (INRs) - IPv4 or IPv6 address space and Internet Number Resources (INRs): IPv4 or IPv6 address space and
ASNs ASNs.
Internet Registry - An organization that manages the allocation or Internet Registry: An organization that manages the allocation or
distribution of INRs. This encompasses the Internet Assigned Number distribution of INRs. This encompasses the Internet Assigned
Authority (IANA), Regional Internet Registries (RIRs), National Number Authority (IANA), Regional Internet Registries (RIRs),
Internet Registries (NIRs), and Local Internet Registries (LIRs, National Internet Registries (NIRs), and Local Internet Registries
network operators). (LIRs) (network operators).
Man in the Middle (MITM) - A MITM is an entity that is able to 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 examine and modify traffic between two (or more) parties on a
communication path. communication path.
Network Operator - An entity that manages an AS and thus emits (E)BGP Network Operator: An entity that manages an AS and thus emits (E)BGP
updates, e.g., an ISP. updates, e.g., an ISP.
NOC (Network Operations Center) - A network operator employs a set Network Operations Center (NOC): A network operator employs a set of
equipment and a staff to manage a network, typically on a 24/7 basis. equipment and a staff to manage a network, typically on a 24/7
The equipment and staff are often referred to as the NOC for the basis. The equipment and staff are often referred to as the NOC
network. for the network.
Prefix - A prefix is an IP address and a mask used to specify a set 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. of addresses that are grouped together for purposes of routing.
Public Key Infrastructure (PKI) - A PKI is a collection of hardware, Public Key Infrastructure (PKI): A PKI is a collection of hardware,
software, people, policies, and procedures used to create, manage, software, people, policies, and procedures used to create, manage,
distribute, store, and revoke digital certificates. distribute, store, and revoke digital certificates.
Relying Parties (RPs) - An RP is an entity that makes use of signed 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 products from a PKI, i.e., it relies on signed data that is
using certificates and Certificate Revocation Lists (CRLs) from a verified using certificates and Certificate Revocation Lists
PKI. (CRLs) from a PKI.
RPKI Repository System - The RPKI repository system consists of a RPKI Repository System: The RPKI repository system consists of a
distributed set of loosely synchronized databases. distributed set of loosely synchronized databases.
Resource PKI (RPKI) - A PKI operated by the entities that manage Resource PKI (RPKI): A PKI operated by the entities that manage INRs
INRs, and that issues X.509 certificates (and CRLs) that attest to and that issue X.509 certificates (and CRLs) that attest to the
the holdings of INRs. holdings of INRs.
RPKI Signed Object - An RPKI signed object is a Cryptographic Message RPKI Signed Object: An RPKI signed object is a data object
Syntax (CMS)-encapsulated data object complying with the format and encapsulated with Cryptographic Message Syntax (CMS) that complies
semantics defined in [RFC6488]. with the format and semantics defined in [RFC6488].
Route - In the Internet, a route is a prefix and an associated Route: In the Internet, a route is a prefix and an associated
sequence of ASNs that indicates a path via which traffic destined for sequence of ASNs that indicates a path via which traffic destined
the prefix can be directed. (The route includes the origin AS.) 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 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 routes that it has received from AS-B to the neighbors of AS-A,
AS-A is not viewed as a transit provider for the prefixes in the but AS-A is not viewed as a transit provider for the prefixes in
route. the route.
Threat - A threat is a motivated, capable adversary. An adversary Threat: A threat is a motivated, capable adversary. An adversary
that is not motivated to launch an attack is not a threat. An that is not motivated to launch an attack is not a threat. An
adversary that is motivated but not capable of launching an attack adversary that is motivated but not capable of launching an attack
also is not a threat. also is not a threat.
Vulnerability - A vulnerability is a flaw or weakness in a system's Vulnerability: A vulnerability is a flaw or weakness in a system's
design, implementation, or operation and management that could be design, implementation, or operation and management that could be
exploited to violate the security policy of a system. exploited to violate the security policy of a system.
3. Threat Characterization 3. Threat Characterization
As noted in Section 2 above, a threat is defined as a motivated, As noted in Section 2 above, a threat is defined as a motivated,
capable, adversary. The following classes of threats represent capable adversary. The following classes of threats represent
classes of adversaries viewed as relevant to this environment. classes of adversaries viewed as relevant to this environment.
Network Operators - A network operator may be a threat. An operator Network Operators: A network operator may be a threat. An
may be motivated to cause BGP routers it controls to emit update operator may be motivated to cause BGP routers it controls to emit
messages with inaccurate routing info, e.g., to cause traffic to flow update messages with inaccurate routing info, e.g., to cause
via paths that are economically advantageous for the operator. Such traffic to flow via paths that are economically advantageous for
updates might cause traffic to flow via paths that would otherwise be the operator. Such updates might cause traffic to flow via paths
rejected as less advantageous by other network operators. Because an that would otherwise be rejected as less advantageous by other
operator controls the BGP routers in its network, it is in a position network operators. Because an operator controls the BGP routers
to modify their operation in arbitrary ways. Routers managed by a in its network, it is in a position to modify their operation in
network operator are vehicles for mounting MITM attacks on both arbitrary ways. Routers managed by a network operator are
control and data plane traffic. If an operator participates in the vehicles for mounting MITM attacks on both control and data plane
RPKI, it will have at least one CA resource certificate and may be traffic. If an operator participates in the RPKI, it will have at
able to generate an arbitrary number of subordinate CA certificates least one CA resource certificate and may be able to generate an
and ROAs. It will be authorized to populate (and may even host) its arbitrary number of subordinate CA certificates and ROAs. It will
own repository publication point. If it implements PATHSEC, and if be authorized to populate (and may even host) its own repository
PATHSEC makes use of certificates associated with routers or ASes, it publication point. If it implements PATHSEC, and if PATHSEC makes
will have the ability to issue such certificates for itself. If use of certificates associated with routers or ASes, it will have
PATHSEC digitally signs updates, it will be able to do so in a the ability to issue such certificates for itself. If PATHSEC
fashion that will be accepted by PATHSEC-enabled neighbors. 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 Hackers: Hackers are considered a threat. A hacker might assume
control of network management computers and routers controlled by control of network management computers and routers controlled by
operators, including operators that implement PATHSEC. In such operators, including operators that implement PATHSEC. In such
cases, hackers would be able to act as rogue network operators (see cases, hackers would be able to act as rogue network operators
above). It is assumed that hackers generally do not have the (see above). It is assumed that hackers generally do not have the
capability to effect MITM attacks on most links between networks capability to effect MITM attacks on most links between networks
(links used to transmit BGP and subscriber traffic). A hacker might (links used to transmit BGP and subscriber traffic). A hacker
be recruited, without his/her knowledge, by criminals or by nations, might be recruited, without his/her knowledge, by criminals or by
to act on their behalf. Hackers may be motivated by a desire for nations, to act on their behalf. Hackers may be motivated by a
"bragging rights" or for profit or to express support for a cause desire for "bragging rights", for profit, or to express support
("hacktivists" [Sam04]). We view hackers as possibly distinct from for a cause ("hacktivists" [Sam04]). We view hackers as possibly
criminals in that the former are presumed to effect attacks only distinct from criminals in that the former are presumed to effect
remotely (not via a physical presence associated with a target) and attacks only remotely (not via a physical presence associated with
not necessarily for monetary gain. Some hackers may commit criminal a target) and not necessarily for monetary gain. Some hackers may
acts (depending on the jurisdiction), and thus there is a potential commit criminal acts (depending on the jurisdiction), and thus
for overlap between this adversary group and criminals. there is a potential for overlap between this adversary group and
criminals.
Criminals - Criminals may be a threat. Criminals might persuade (via Criminals: Criminals may be a threat. Criminals might persuade
threats or extortion) a network operator to act as a rogue operator (via threats or extortion) a network operator to act as a rogue
(see above), and thus be able to effect a wide range of attacks. operator (see above) and thus be able to effect a wide range of
Criminals might persuade the staff of a telecommunications provider attacks. Criminals might persuade the staff of a
to enable MITM attacks on links between routers. Motivations for telecommunications provider to enable MITM attacks on links
criminals may include the ability to extort money from network between routers. Motivations for criminals may include the
operators or network operator clients, e.g., by adversely affecting ability to extort money from network operators or network operator
routing for these network operators or their clients. Criminals also clients, e.g., by adversely affecting routing for these network
may wish to manipulate routing to conceal the sources of spam, DoS operators or their clients. Criminals also may wish to manipulate
attacks, or other criminal activities. 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 Registries: Any registry in the RPKI could be a threat. Staff at
the registry are capable of manipulating repository content or the registry are capable of manipulating repository content or
mismanaging the RPKI certificates that they issue. These actions mismanaging the RPKI certificates that they issue. These actions
could adversely affect a network operator or a client of a network could adversely affect a network operator or a client of a network
operator. The staff could be motivated to do this based on political operator. The staff could be motivated to do this based on
pressure from the nation in which the registry operates (see below) political pressure from the nation in which the registry operates
or due to criminal influence (see above). (see below) or due to criminal influence (see above).
Nations - A nation may be a threat. A nation may control one or more Nations: A nation may be a threat. A nation may control one or
network operators that operate in the nation, and thus can cause them more network operators that operate in the nation, and thus can
to act as rogue network operators. A nation may have a technical cause them to act as rogue network operators. A nation may have a
active wiretapping capability (e.g., within its territory) that technical active wiretapping capability (e.g., within its
enables it to effect MITM attacks on inter-network traffic. (This territory) that enables it to effect MITM attacks on inter-network
capability may be facilitated by control or influence over a traffic. (This capability may be facilitated by control or
telecommunications provider operating within the nation.) It may influence over a telecommunications provider operating within the
have an ability to attack and take control of routers or management nation.) It may have an ability to attack and take control of
network computers of network operators in other countries. A nation routers or management network computers of network operators in
may control a registry (e.g., an RIR) that operates within its other countries. A nation may control a registry (e.g., an RIR)
territory, and might force that registry to act in a rogue capacity. that operates within its territory and might force that registry
National threat motivations include the desire to control the flow of to act in a rogue capacity. National threat motivations include
traffic to/from the nation or to divert traffic destined for other the desire to control the flow of traffic to/from the nation or to
nations (for passive or active wiretapping, including DoS). divert traffic destined for other nations (for passive or active
wiretapping, including DoS).
4. Attack Characterization 4. Attack Characterization
This section describes classes of attacks that may be effected This section describes classes of attacks that may be effected
against Internet routing (relative to the context described in against Internet routing (relative to the context described in
Section 1). Attacks are classified based on the target of the Section 1). Attacks are classified based on the target of the
attack, as an element of the routing system, or the routing security attack, an element of the routing system, or the routing security
infrastructure on which PATHSEC relies. In general, attacks of infrastructure on which PATHSEC relies. In general, attacks of
interest are ones that attempt to violate the integrity or interest are ones that attempt to violate the integrity or
authenticity of BGP traffic, or which violate the authorizations authenticity of BGP traffic or that violate the authorizations
associated with entities participating in the RPKI. Attacks that associated with entities participating in the RPKI. Attacks that
violate the implied confidentiality of routing traffic, e.g., passive violate the implied confidentiality of routing traffic, e.g., passive
wiretapping attacks, are not considered a requirement for BGP wiretapping attacks, are not considered a requirement for BGP
security (see [RFC4272]). security (see [RFC4272]).
4.1. Active wiretapping of sessions between routers 4.1. Active Wiretapping of Sessions between Routers
An adversary may attack the BGP (TCP) session that connects a pair of 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 BGP speakers. An active attack against a BGP (TCP) session can be
effected by directing traffic to a BGP speaker from some remote 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 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 session traffic. Remote attacks can be effected by any adversary. A
MITM attack requires access to the link. Modern transport networks MITM attack requires access to the link. Modern transport networks
may be as complex as the packet networks that utilize them for inter- may be as complex as the packet networks that utilize them for inter-
AS links. Thus these transport networks may present significant AS links. Thus, these transport networks may present significant
attack surfaces. Nonetheless, only some classes of adversaries are attack surfaces. Nonetheless, only some classes of adversaries are
assumed to be capable of MITM attacks against a BGP session. MITM assumed to be capable of MITM attacks against a BGP session. MITM
attacks may be directed against BGP, PATHSEC-protected BGP, or attacks may be directed against BGP and PATHSEC-protected BGP, or
against TCP or IP. Such attacks include replay of selected BGP against TCP or IP. Such attacks include replay of selected BGP
messages, selective modification of BGP messages, and DoS attacks messages, selective modification of BGP messages, and DoS attacks
against BGP routers. [RFC4272] describes several countermeasures for against BGP routers. [RFC4272] describes several countermeasures for
such attacks, and thus this document does not further address such such attacks, and thus this document does not further address such
attacks. attacks.
4.2. Attacks on a BGP router 4.2. Attacks on a BGP Router
An adversary may attack a BGP router, whether it implements PATHSEC An adversary may attack a BGP router, whether or not it implements
or not. Any adversary that controls routers legitimately, or that PATHSEC. Any adversary that controls routers legitimately, or that
can assume control of a router, is assumed to be able to effect the 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 types of attacks described below. Note that any router behavior that
can be ascribed to a local routing policy decision is not considered 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 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 a result of local policy settings and thus is beyond the scope of
what PATHSEC can detect as unauthorized behavior. Thus, for example, what PATHSEC can detect as unauthorized behavior. Thus, for example,
a router may fail to propagate some or all route withdrawals or a router may fail to propagate some or all route withdrawals or
effect "route leaks". (These behaviors are not precluded by the effect "route leaks". (These behaviors are not precluded by the
specification for BGP, and might be the result of a local policy that specification for BGP and might be the result of a local policy that
is not publicly disclosed. As a result, they are not considered is not publicly disclosed. As a result, they are not considered
attacks. See Section 5 for additional discussion.) attacks. See Section 5 for additional discussion.)
Attacks on a router are equivalent to active wiretapping attacks (in Attacks on a router are equivalent to active wiretapping attacks (in
the most general sense) that manipulate (forge, tamper with, or the most general sense) that manipulate (forge, tamper with, or
suppress) data contained in BGP updates. The list below illustrates suppress) data contained in BGP updates. The list below illustrates
attacks of this type. attacks of this type.
AS Insertion: A router might insert one or more ASNs, other than AS Insertion: A router might insert one or more ASNs, other than
its own ASN, into an update message. This violates the BGP spec its own ASN, into an update message. This violates the BGP spec
and thus is considered an attack. and thus is considered an attack.
False (Route) Origination: A router might originate a route for a False (Route) Origination: A router might originate a route for a
prefix, when the AS that the router represents is not authorized prefix when the AS that the router represents is not authorized to
to originate routes for that prefix. This is an attack, but it is originate routes for that prefix. This is an attack, but it is
addressed by the use of the RPKI [RFC6480]. addressed by the use of the RPKI [RFC6480].
Secure Path Downgrade: A router might remove AS_PATH data from a Secure Path Downgrade: A router might remove AS_PATH data from a
PATHSEC-protected update that it receives, when forwarding this PATHSEC-protected update that it receives when forwarding this
update to a PATHSEC-enabled neighbor. This behavior violates the update to a PATHSEC-enabled neighbor. This behavior violates the
PATHSEC security goals and thus is considered an attack. PATHSEC security goals and thus is considered an attack.
Invalid AS_PATH Data Insertion: A router might emit a PATHSEC- Invalid AS_PATH Data Insertion: A router might emit a PATHSEC-
protected update with "bad" data (such as a signature), i.e., protected update with "bad" data (such as a signature), i.e.,
PATHSEC data that cannot be validated by other PATHSEC routers. PATHSEC data that cannot be validated by other PATHSEC routers.
Such behavior is assumed to violate the PATHSEC goals and thus is Such behavior is assumed to violate the PATHSEC goals and thus is
considered an attack. considered an attack.
Stale Path Announcement: If PATHSEC-secured announcements can Stale Path Announcement: If PATHSEC-secured announcements can
skipping to change at page 10, line 25 skipping to change at page 10, line 33
enable an adversary to effect MITM attacks on the link(s) where enable an adversary to effect MITM attacks on the link(s) where
the key is used. Use of specific security mechanisms to protect the key is used. Use of specific security mechanisms to protect
inter-router links between ASes is outside the scope of PATHSEC. inter-router links between ASes is outside the scope of PATHSEC.
Compromised Router Private Key: If PATHSEC mechanisms employ Compromised Router Private Key: If PATHSEC mechanisms employ
public key cryptography, e.g., to digitally sign data in an public key cryptography, e.g., to digitally sign data in an
update, then a private key associated with a router or an AS might update, then a private key associated with a router or an AS might
be compromised by an attack against the router. An adversary with be compromised by an attack against the router. An adversary with
access to this key would be able to generate updates that appear access to this key would be able to generate updates that appear
to have passed through the AS that this router represents. Such to have passed through the AS that this router represents. Such
updates might be in injected on a link between the compromised updates might be injected on a link between the compromised router
router and its neighbors, if that link is accessible to the and its neighbors if that link is accessible to the adversary. If
adversary. If the adversary controls another network, it could the adversary controls another network, it could use this key to
use this key to forge signatures that appear to come from the AS forge signatures that appear to come from the AS or router(s) in
or router(s) in question, with some constraints. So, for example, question, with some constraints. So, for example, an adversary
an adversary that controls another AS could use a compromised that controls another AS could use a compromised router/AS key to
router/AS key to issue PATHSEC-signed data that include the issue PATHSEC-signed data that includes the targeted router/AS.
targeted AS/router. (Neighbors of the adversary's AS ought not (Neighbors of the adversary's AS ought not accept a route that
accept a route that purports to emanate directly from the targeted purports to emanate directly from the targeted AS. So, an
AS. So, an adversary could take a legitimate, protected route adversary could take a legitimate, protected route that passes
that passes through the compromised AS, add itself as the next through the compromised AS, add itself as the next hop, and then
hop, and then forward the resulting route to neighbors.) forward the resulting route to neighbors.)
Withdrawal Suppression Attack: A PATHSEC-protected update may be Withdrawal Suppression Attack: A PATHSEC-protected update may be
signed and announced, and later withdrawn. An adversary signed and announced, and later withdrawn. An adversary
controlling intermediate routers could fail to propagate the controlling intermediate routers could fail to propagate the
withdrawal. BGP is already vulnerable to behavior of this sort, withdrawal. BGP is already vulnerable to behavior of this sort,
so withdrawal suppression is not characterized as an attack, under so withdrawal suppression is not characterized as an attack under
the assumptions upon which this mode is based (i.e., no oracle). the assumptions upon which this mode is based (i.e., no oracle).
4.3. Attacks on network operator management computers (non-CA 4.3. Attacks on Network Operator Management Computers (Non-CA
computers) Computers)
An adversary may choose to attack computers used by a network An adversary may choose to attack computers used by a network
operator to manage its network, especially its routers. Such attacks operator to manage its network, especially its routers. Such attacks
might be effected by an adversary who has compromised the security of might be effected by an adversary who has compromised the security of
these computers. This might be effected via remote attacks, these computers. This might be effected via remote attacks,
extortion of network operations staff, etc. If an adversary extortion of network operations staff, etc. If an adversary
compromises NOC computers, he can execute any management function compromises NOC computers, he can execute any management function
that authorized network operations staff would have performed. Thus that authorized network operations the staff would have performed.
the adversary could modify local routing policy to change Thus, the adversary could modify the local routing policy to change
preferences, to black-hole certain routes, etc. This type of preferences, to black-hole certain routes, etc. This type of
behavior cannot be externally detected as an attack. Externally, behavior cannot be externally detected as an attack. Externally,
this appears as a form of rogue operator behavior. (Such behavior this appears as a form of rogue operator behavior. (Such behavior
might be perceived as accidental or malicious by other operators.) might be perceived as accidental or malicious by other operators.)
If a network operator participates in the RPKI, an adversary could If a network operator participates in the RPKI, an adversary could
manipulate the RP tools that extract data from the RPKI, causing the manipulate the RP tools that extract data from the RPKI, causing the
output of these tools to be corrupted in various ways. For example, 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 an attack of this sort could cause the operator to view valid routes
as not validated, which could alter its routing behavior. as not validated, which could alter its routing behavior.
skipping to change at page 11, line 29 skipping to change at page 11, line 37
If an adversary invoked the tool used to manage the repository If an adversary invoked the tool used to manage the repository
publication point for this operator, it could delete any objects publication point for this operator, it could delete any objects
stored there (certificates, CRLs, manifests, ROAs, or subordinate CA stored there (certificates, CRLs, manifests, ROAs, or subordinate CA
certificates). This could affect the routing status of entities that certificates). This could affect the routing status of entities that
have allocations/assignments from this network operator (e.g., by have allocations/assignments from this network operator (e.g., by
deleting their CA certificates). deleting their CA certificates).
An adversary could invoke the tool used to request certificate An adversary could invoke the tool used to request certificate
revocation, causing router certificates, ROAs, or subordinate CA revocation, causing router certificates, ROAs, or subordinate CA
certificates to be revoked. An attack of this sort could affect not certificates to be revoked. An attack of this sort could affect not
only this operator, but also any operators that receive allocations/ only this operator but also any operators that receive allocations/
assignments from it, e.g., because their CA certificates were assignments from it, e.g., because their CA certificates were
revoked. revoked.
If an operator is PATHSEC-enabled, an attack of this sort could cause If an operator is PATHSEC-enabled, an attack of this sort could cause
the affected operator to be viewed as not PATHSEC-enabled, possibly the affected operator to be viewed as not PATHSEC-enabled, possibly
making routes it emits be less preferred by other operators. making routes it emits less preferable to other operators.
If an adversary invoked a tool used to request ROAs, it could If an adversary invoked a tool used to request ROAs, it could
effectively re-allocate some of the prefixes allocated/assigned to effectively reallocate some of the prefixes allocated/assigned to the
the network operator (e.g., by modifying the origin AS in ROAs). network operator (e.g., by modifying the origin AS in ROAs). This
This might cause other PATHSEC-enabled networks to view the affected might cause other PATHSEC-enabled networks to view the affected
network as no longer originating routes for these prefixes. Multi- network as no longer originating routes for these prefixes. Multi-
homed subscribers of this operator who received an allocation from homed subscribers of this operator who received an allocation from
the operator might find their traffic was now routed via other the operator might find that their traffic was routed via other
connections. connections.
If the network operator is PATHSEC-enabled, and make use of If the network operator is PATHSEC-enabled, and makes use of
certificates associated with routers/ASes, an adversary could invoke certificates associated with routers/ASes, an adversary could invoke
a tool used to request such certificates. The adversary could then a tool used to request such certificates. The adversary could then
replace valid certificates for routers/ASes with ones that might be replace valid certificates for routers/ASes with ones that might be
rejected by PATHSEC-enabled neighbors. rejected by PATHSEC-enabled neighbors.
4.4. Attacks on a repository publication point 4.4. Attacks on a Repository Publication Point
A critical element of the RPKI is the repository system. An A critical element of the RPKI is the repository system. An
adversary might attack a repository, or a publication point within a adversary might attack a repository, or a publication point within a
repository, to adversely affect routing. repository, to adversely affect routing.
This section considers only those attacks that can be launched by any This section considers only those attacks that can be launched by any
adversary who controls a computer hosting one or more repository adversary who controls a computer hosting one or more repository
publication points, without access to the cryptographic keys needed publication points, without access to the cryptographic keys needed
to generate valid RPKI signed products. Such attacks might be to generate valid RPKI-signed products. Such attacks might be
effected by an insider or an external threat. Because all repository effected by an insider or an external threat. Because all repository
objects are digitally signed, attacks of this sort translate into DoS 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 against the RPKI RPs. There are a few distinct forms of such
attacks, as described below. attacks, as described below.
Note first that the RPKI calls for RPs to cache the data they acquire Note first that the RPKI calls for RPs to cache the data they acquire
and verify from the repository system [RFC6480][RFC6481]. Attacks and verify from the repository system [RFC6480][RFC6481]. Attacks
that delete signed products, that insert products with "bad" that delete signed products, insert products with "bad" signatures,
signatures, that tamper with object signatures, or that replace newer tamper with object signatures, or replace newer objects with older
objects with older (valid) ones, can be detected by RPs (with a few (valid) ones, can be detected by RPs (with a few exceptions). RPs
exceptions). RPs are expected to make use of local caches. If are expected to make use of local caches. If repository publication
repository publication points are unavailable or the retrieved data points are unavailable or the retrieved data is corrupted, an RP can
is corrupted, an RP can revert to using the cached data. This revert to using the cached data. This behavior helps insulate RPs
behavior helps insulate RPs from the immediate effects of DoS attacks from the immediate effects of DoS attacks on publication points.
on publication points.
Each RPKI data object has an associated date at which it expires, or Each RPKI data object has an associated date on which it expires or
is considered stale. (Certificates expire, CRLs become stale.) When is considered stale (certificates expire and CRLs become stale).
an RP uses cached data it is a local decision how to deal with stale When an RP uses cached data, how to deal with stale or expired data
or expired data. It is common in PKIs to make use of stale is a local decision. It is common in PKIs to make use of stale
certificate revocation status data, when fresher data is not certificate revocation status data when fresher data is not
available. Use of expired certificates is less common, although not available. Use of expired certificates is less common, although not
unknown. Each RP will decide, locally, whether to continue to make unknown. Each RP will decide, locally, whether to continue to make
use of or ignore cached RPKI objects that are stale or expired. use of or ignore cached RPKI objects that are stale or expired.
If an adversary inserts an object into a publication point, and the If an adversary inserts an object into a publication point, and the
object has a "bad" signature, the object will not be accepted and object has a "bad" signature, the object will not be accepted and
used by RPs. used by RPs.
If an adversary modifies any signed product at a publication point, If an adversary modifies any signed product at a publication point,
the signature on the product will fail, causing RPs to not accept it. the signature on the product will fail, causing RPs to not accept it.
This is equivalent to deleting the object, in many respects. This is equivalent to deleting the object, in many respects.
If an adversary deletes one or more CA certificates, ROAs or the CRL If an adversary deletes one or more CA certificates, ROAs, or the CRL
for a publication point, the manifest for that publication point will 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 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), last valid instance of the deleted object (as a local policy option),
thus minimizing the impact of such an attack. thus minimizing the impact of such an attack.
If an adversary deletes a manifest (and does not replace it with an If an adversary deletes a manifest (and does not replace it with an
older instance), that is detectable by RPs. Such behavior should older instance), RPs are able to detect this action. Such behavior
result in the CA (or publication point maintainer) being notified of should result in the CA (or publication point maintainer) being
the problem. An RP can continue to use the last valid instance of notified of the problem. An RP can continue to use the last valid
the deleted manifest (a local policy option), thus minimizing the instance of the deleted manifest (a local policy option), thus
impact of such an attack. minimizing the impact of such an attack.
If an adversary deletes newly added CA certificates or ROAs, and If an adversary deletes newly added CA certificates or ROAs, and
replaces the current manifest with the previous manifest, the replaces the current manifest with the previous manifest, the
manifest (and the CRL that it matches) will be "stale" (see manifest (and the CRL that it matches) will be "stale" (see
[RFC6486]). This alerts an RP that there may be a problem. The RP [RFC6486]). This alerts an RP that there may be a problem. The RP
should use the information from a Ghostbuster record [RFC6493] to should use the information from a Ghostbuster Record [RFC6493] to
contact the entity responsible for the publication point, requesting contact the entity responsible for the publication point and request
that entity to remedy the problem (e.g., republish the missing CA a remedy to the problem (e.g., republish the missing CA certificates
certificates and/or ROAs). An RP cannot know the content of the new and/or ROAs). An RP cannot know the content of the new certificates
certificates or ROAs that are not present, but it can continue to use or ROAs that are not present, but it can continue to use what it has
what it has cached. An attack of this sort will, at least cached. An attack of this sort will, at least temporarily, cause RPs
temporarily, cause RPs to be unaware of the newly published objects. to be unaware of the newly published objects. INRs associated with
INRs associated with these objects will be treated as these objects will be treated as unauthenticated.
unauthenticated.
If a CA revokes a CA certificate or a ROA (via deleting the If a CA revokes a CA certificate or a ROA (via deleting the
corresponding EE certificate), and the adversary tries to reinstate corresponding End Entity (EE) certificate), and the adversary tries
that CA certificate or ROA, the adversary would have to rollback the to reinstate that CA certificate or ROA, the adversary would have to
CRL and the manifest to undo this action by the CA. As above, this rollback the CRL and the manifest to undo this action by the CA. As
would make the CRL and manifest stale, and this is detectable by RPs. above, this would make the CRL and manifest stale, and this is
An RP cannot know which CA certificates or ROAs were deleted. detectable by RPs. An RP cannot know which CA certificates or ROAs
Depending on local policy, the RP might use the cached instances of were deleted. Depending on local policy, the RP might use the cached
the affected objects, and thus be tricked into making decisions based instances of the affected objects and thus be tricked into making
on these revoked objects. Here too the goal is that the CA will be decisions based on these revoked objects. Here too, the goal is that
notified of the problem (by RPs) and will remedy the error. 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 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 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 has passed. Until the next issue date, an RP will not detect the
attack. Thus it behooves CAs to select CRL/manifest lifetimes (the attack. Thus, it behooves CAs to select CRL/manifest lifetimes (the
two are linked) that represent an acceptable trade-off between risk two are linked) that represent an acceptable trade-off between risk
and operational burdens. and operational burdens.
Attacks effected by adversaries that are legitimate managers of Attacks effected by adversaries that are legitimate managers of
publication points can have much greater effects, and are discussed publication points can have much greater effects and are discussed
below under attacks on or by CAs. below under attacks on or by CAs.
4.5. Attacks on an RPKI CA 4.5. Attacks on an RPKI CA
Every entity to which INRs have been allocated/assigned is a CA in Every entity to which INRs have been allocated/assigned is a CA in
the RPKI. Each CA is nominally responsible for managing the the RPKI. Each CA is nominally responsible for managing the
repository publication point for the set of signed products that it repository publication point for the set of signed products that it
generates. (An INR holder may choose to outsource the operation of generates. (An INR holder may choose to outsource the operation of
the RPKI CA function, and the associated publication point. In such the RPKI CA function and the associated publication point. In such
cases, the organization operating on behalf of the INR holder becomes cases, the organization operating on behalf of the INR holder becomes
the CA, from an operational and security perspective. The following the CA from an operational and security perspective. The following
discussion does not distinguish such outsourced CA operations.) discussion does not distinguish such outsourced CA operations.)
Note that attacks attributable to a CA may be the result of malice by 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 the CA (i.e., the CA is the adversary), or they may result from a
compromise of the CA. compromise of the CA.
All of adversaries listed in Section 2 are presumed to be capable of All of the adversaries listed in Section 2 are presumed to be capable
launching attacks against the computers used to perform CA functions. of launching attacks against the computers used to perform CA
Some adversaries might effect an attack on a CA by violating functions. Some adversaries might effect an attack on a CA by
personnel or physical security controls as well. The distinction violating personnel or physical security controls as well. The
between CA as adversary vs. CA as an attack victim is important. distinction between the CA as an adversary versus the CA as an attack
Only in the latter case should one expect the CA to remedy problems victim is important. Only in the latter case should one expect the
caused by a attack once the attack has been detected. (If a CA does CA to remedy problems caused by an attack once the attack has been
not take such action, the effects are the same as if the CA is an detected. (If a CA does not take such action, the effects are the
adversary.) same as if the CA is an adversary.)
Note that most of the attacks described below do not require Note that most of the attacks described below do not require
disclosure of a CA's private key to an adversary. If the adversary 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 can gain control of the computer used to issue certificates, it can
effect these attacks, even though the private key for the CA remains effect these attacks, even though the private key for the CA remains
"secure" (i.e., not disclosed to unauthorized parties). However, if "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 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 compromised, then recovery from these attacks is much easier. This
motivates use of hardware security modules to protect CA keys, at motivates use of hardware security modules to protect CA keys, at
least for higher tiers in the RPKI. least for higher tiers in the RPKI.
An attack by a CA can result in revocation or replacement of any of 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 the certificates that the CA has issued. Revocation of a certificate
should cause RPs to delete the (formerly) valid certificate (and should cause RPs to delete the (formerly) valid certificate (and
associated signed object, in the case of a revoked EE certificate) associated signed object, in the case of a revoked EE certificate)
that they have cached. This would cause repository objects (e.g., CA that they have cached. This would cause repository objects (e.g., CA
certificates and ROAs) that are verified under that certificate to be certificates and ROAs) that are verified under that certificate to be
considered invalid, transitively. As a result, RPs would not considered invalid, transitively. As a result, RPs would not
consider as valid any ROAs or PATHSEC-protected updates based on consider any ROAs or PATHSEC-protected updates to be valid based on
these certificates, which would make routes dependent on them to be these certificates, which would make routes dependent on them less
less preferred. Because a CA that revokes a certificate is preferred. Because a CA that revokes a certificate is authorized to
authorized to do so, this sort of attack cannot be detected, do so, this sort of attack cannot be detected, intrinsically, by most
intrinsically, by most RPs. However, the entities affected by the RPs. However, the entities affected by the revocation or replacement
revocation or replacement of CA certificates can be expected to of CA certificates can be expected to detect the attack and contact
detect the attack and contact the CA to effect remediation. If the the CA to effect remediation. If the CA was not the adversary, it
CA was not the adversary, it should be able to issue new certificates should be able to issue new certificates and restore the publication
and restore the publication point. point.
An adversary that controls the CA for a publication point can publish An adversary that controls the CA for a publication point can publish
signed products that create more subtle types of DoS attacks against signed products that create more subtle types of DoS attacks against
RPs. For example, such an attacker could create subordinate CA RPs. For example, such an attacker could create subordinate CA
certificates with Subject Information Access (SIA) pointers that lead certificates with Subject Information Access (SIA) pointers that lead
RPs on a "wild goose chase" looking for additional publication points RPs on a "wild goose chase" looking for additional publication points
and signed products. An attacker could publish certificates with and signed products. An attacker could publish certificates with
very brief validity intervals, or CRLs and manifests that become very brief validity intervals or CRLs and manifests that become
"stale" very quickly. This sort of attack would cause RPs to access "stale" very quickly. This sort of attack would cause RPs to access
repositories more frequently, and that might interfere with repositories more frequently, and that might interfere with
legitimate accesses by other RPs. legitimate accesses by other RPs.
An attacker with this capability could create very large numbers of An attacker with this capability could create very large numbers of
ROAs to be processed (with prefixes that are consistent with the ROAs to be processed (with prefixes that are consistent with the
allocation for the CA), and correspondingly large manifests. An allocation for the CA) and correspondingly large manifests. An
attacker could create very deep subtrees with many ROAs per attacker could create very deep subtrees with many ROAs per
publication point, etc. All of these types of DoS attacks against publication point, etc. All of these types of DoS attacks against
RPs are feasible within the syntactic and semantic constraints RPs are feasible within the syntactic and semantic constraints
established for RPKI certificates, CRLs, and signed objects. established for RPKI certificates, CRLs, and signed objects.
An attack that results in revocation and replacement (e.g., key An attack that results in revocation and replacement (e.g., key
rollover or certificate renewal) of a CA certificate would cause RPs rollover or certificate renewal) of a CA certificate would cause RPs
to replace the old, valid certificate with the new one. This new to replace the old, valid certificate with the new one. This new
certificate might contain a public key that does not correspond to certificate might contain a public key that does not correspond to
the private key held by the certificate subject. That would cause the private key held by the certificate subject. That would cause
objects signed by that subject to be rejected as invalid, and prevent objects signed by that subject to be rejected as invalid, and prevent
the affected subject from being able to sign new objects. As above, 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 RPs would not consider any ROAs issued under the affected CA
certificate, and updates based on router certificates issued by the certificate to be valid, and updates based on router certificates
affected CA would be rejected. This would make routes dependent on issued by the affected CA would be rejected. This would make routes
these signed products to be less preferred. However, the constraints dependent on these signed products less preferred. However, the
imposed by the use of RFC 3779 [RFC3779] extensions do prevent a constraints imposed by the use of extensions detailed in [RFC3779]
compromised CA from issuing (valid) certificates with INRs outside prevent a compromised CA from issuing (valid) certificates with INRs
the scope of the CA, thus limiting the impact of the attack. outside the scope of the CA, thus limiting the impact of the attack.
An adversary that controls a CA could issue CA certificates with An adversary that controls a CA could issue CA certificates with
overlapping INRs to different entities, when no transfer of INRs is overlapping INRs to different entities when no transfer of INRs is
intended. This could cause confusion for RPs as conflicting ROAs intended. This could cause confusion for RPs as conflicting ROAs
could be issued by the distinct (subordinate) CAs. could be issued by the distinct (subordinate) CAs.
An adversary could replace a CA certificate, use the corresponding An adversary could replace a CA certificate, use the corresponding
private key to issue new signed products, and then publish them at a private key to issue new signed products, and then publish them at a
publication point controlled by the attacker. This would effectively publication point controlled by the attacker. This would effectively
transfer the affected INRs to the adversary, or to a third party of 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 his choosing. The result would be to cause RPs to view the entity
that controls the private key in question as the legitimate INR that controls the private key in question as the legitimate INR
holder. Again the constraints imposed by the use of RFC 3779 holder. Again, the constraints imposed by the use of the extensions
extensions prevent a compromised CA from issuing (valid) certificates in RFC 3779 prevent a compromised CA from issuing (valid)
with INRs outside the scope of the CA, thus limiting the impact of certificates with INRs outside the scope of the CA, thus limiting the
the attack. impact of the attack.
Finally, an entity that manages a repository publication point can Finally, an entity that manages a repository publication point can
inadvertently act as an attacker (an example of Walt Kelly's most inadvertently act as an attacker (an example of Walt Kelly's most
famous "Pogo" quote [Kelly70]). For example, a CA might fail to famous "Pogo" quote [Kelly70]). For example, a CA might fail to
replace its own certificate in a timely fashion (well before it replace its own certificate in a timely fashion (well before it
expires). If might fail to issue its CRL and manifest prior to expires). It might fail to issue its CRL and manifest prior to
expiration, creating stale instances of these products that cause expiration, creating stale instances of these products that cause
concern for RPs. A CA with many subordinate CAs (e.g., an RIR or 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 NIR) might fail to distribute the expiration times for the CA
certificates that it issues. A network with many ROAs might do the certificates that it issues. A network with many ROAs might do the
same for the EE certificates associated with the ROAs it generates. same for the EE certificates associated with the ROAs it generates.
A CA could rollover its key, but fail to reissue subordinate CA A CA could rollover its key but fail to reissue subordinate CA
certificates under its new key. Poor planning with regard to rekey certificates under its new key. Poor planning with regard to rekey
intervals for managed CAs could impose undue burdens for RPs, despite intervals for managed CAs could impose undue burdens for RPs, despite
a lack of malicious intent. All of these example of mismanagement a lack of malicious intent. All of these examples of mismanagement
could adversely affect RPs, despite the absence of malicious intent. could adversely affect RPs, despite the absence of malicious intent.
5. Residual Vulnerabilities 5. Residual Vulnerabilities
The RPKI, upon which PATHSEC relies, has several residual The RPKI, upon which PATHSEC relies, has several residual
vulnerabilities that were discussed in the preceding text vulnerabilities that were discussed in the preceding text (Sections
(Section 4.4 and Section 4.5). These vulnerabilities are of two 4.4 and 4.5). These vulnerabilities are of two principle forms:
principle forms:
o the RPKI repository system may be attacked in ways that make its o The RPKI repository system may be attacked in ways that make its
contents unavailable, not current, or inconsistent. The principle contents unavailable, not current, or inconsistent. The principle
defense against most forms of DoS attacks is the use of a local defense against most forms of DoS attacks is the use of a local
cache by each RP. The local cache ensures availability of cache by each RP. The local cache ensures availability of
previously-acquired RPKI data, in the event that a repository is previously acquired RPKI data in the event that a repository is
inaccessible or if repository contents are deleted (maliciously). inaccessible or if the repository contents are deleted
Nonetheless, the system cannot ensure that every RP will always (maliciously). Nonetheless, the system cannot ensure that every
have access to up-to-date RPKI data. An RP, when it detects a RP will always have access to up-to-date RPKI data. An RP, when
problem with acquired repository data has two options: it detects a problem with acquired repository data, has two
options:
1. The RP may choose to make use of its local cache, employing 1. The RP may choose to make use of its local cache, employing
local configuration settings that tolerate expired or stale local configuration settings that tolerate expired or stale
objects. (Such behavior is, nominally, always within the objects. (Such behavior is, nominally, always within the
purview of an RP in PKI.) Using cached, expired or stale data purview of an RP in PKI.) Using cached, expired, or stale
subjects the RP to attacks that take advantage of the RP's data subjects the RP to attacks that take advantage of the
ignorance of changes to this data. RP's ignorance of changes to this data.
2. The RP may chose to purge expired objects. Purging expired 2. The RP may chose to purge expired objects. Purging expired
objects removes the security info associated with the real objects removes the security information associated with the
world INRs to which the objects refer. This is equivalent to real-world INRs to which the objects refer. This is
the affected INRs not having been afforded protection via the equivalent to the affected INRs not having been afforded
RPKI. Since use of the RPKI (and PATHSEC) is voluntary, there protection via the RPKI. Since use of the RPKI (and PATHSEC)
may always be set of INRs that are not protected by these is voluntary, there may always be a set of INRs that are not
mechanisms. Thus purging moves the affected INRs to the set protected by these mechanisms. Thus, purging moves the
of non-participating INR holders. This more conservative affected INRs to the set of non-participating INR holders.
response enables an attacker to move INRs from the protected This more conservative response enables an attacker to move
to the unprotected set. INRs from the protected set to the unprotected set.
o any CA in the RPKI may misbehave within the bounds of the INRs o Any CA in the RPKI may misbehave within the bounds of the INRs
allocated to it, e.g., it may issue certificates with duplicate allocated to it, e.g., it may issue certificates with duplicate
resource allocations or revoke certificates inappropriately. This resource allocations or revoke certificates inappropriately. This
vulnerability is intrinsic in any PKI, but its impact is limited vulnerability is intrinsic in any PKI, but its impact is limited
in the RPKI because of the use of RFC 3779 extensions. It is in the RPKI because of the use of extensions in RFC 3779. It is
anticipated that RPs will deal with such misbehavior through anticipated that RPs will deal with such misbehavior through
administrative means, once it is detected. administrative means once it is detected.
PATHSEC has a separate set of residual vulnerabilities: PATHSEC has a separate set of residual vulnerabilities:
o It has been stated that "route leaks" are viewed as a routing o It has been stated that "route leaks" are viewed as a routing
security problem by many operators. However, BGP itself does not security problem by many operators. However, BGP itself does not
include semantics that preclude what many perceive as route leaks, include semantics that preclude what many perceive as route leaks,
and there is no definition of the term in any RFC. This makes it and there is no definition of the term in any RFC. This makes it
inappropriate to address route leaks in this document. inappropriate to address route leaks in this document.
Additionally, route leaks are outside the scope of PATHSEC, Additionally, route leaks are outside the scope of PATHSEC,
consistent with the security context noted in Section 1 of this consistent with the security context noted in Section 1 of this
document. If, at a later time, the SIDR security context is document. If, at a later time, the SIDR security context is
revised to include route leaks, and an appropriate definition revised to include route leaks, and an appropriate definition
exists, this document should be revised. exists, this document should be revised.
o PATHSEC is not required to protect all attributes associated with o PATHSEC is not required to protect all attributes associated with
an AS_PATH, even though some of these attributes may be employed an AS_PATH, even though some of these attributes may be employed
as inputs to routing decisions. Thus attacks that modify (or as inputs to routing decisions. Thus, attacks that modify (or
strip) these other attributes are not prevented/detected by strip) these other attributes are not prevented/detected by
PATHSEC. As noted in Section 1, the SIDR security context calls PATHSEC. As noted in Section 1, the SIDR security context calls
for protecting only the info needed to verify that a received for protecting only the information needed to verify that a
route traversed the ASes in question, and that the NLRI in the received route traversed the ASes in question, and that the NLRI
route is what was advertised. (The AS_PATH data also may have in the route is what was advertised. (The AS_PATH data also may
traversed ASes within a confederation that are not represented. have traversed ASes within a confederation that are not
However, these ASes are not externally visible, and thus do not represented. However, these ASes are not externally visible and
influence route selection, so their omission in this context is thus do not influence route selection, so their omission in this
not a security concern.) Thus, protection of other attributes is context is not a security concern.) Thus, protection of other
outside the scope of this document, as described in Section 1. attributes is outside the scope of this document, as described in
If, at a later time, the SIDR security context is revised to Section 1. If, at a later time, the SIDR security context is
include protection of additional BGP attributes, this document revised to include protection of additional BGP attributes, this
should be revised. document should be revised.
o PATHSEC cannot ensure that an AS will withdraw a route when the AS o PATHSEC cannot 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. no longer has a route for a prefix, as noted in Section 4.2.
PATHSEC may incorporate features to limit the lifetime of an PATHSEC may incorporate features to limit the lifetime of an
advertisement. Such lifetime limits provide an upper bound on the advertisement. Such lifetime limits provide an upper bound on the
time that the failure to withdraw a route will remain effective. time that the failure to withdraw a route will remain effective.
6. Security Considerations 6. Security Considerations
A threat model is, by definition, a security-centric document. A threat model is, by definition, a security-centric document.
Unlike a protocol description, a threat model does not create Unlike a protocol description, a threat model does not create
security problems nor purport to address security problems. This security problems nor does it purport to address security problems.
model postulates a set of threats (i.e., motivated, capable This model postulates a set of threats (i.e., motivated, capable
adversaries) and examines classes of attacks that these threats are adversaries) and examines classes of attacks that these threats are
capable of effecting, based on the motivations ascribed to the capable of effecting, based on the motivations ascribed to the
threats. It describes the impact of these types of attacks on threats. It describes the impact of these types of attacks on
PATHSEC, including on the RPKI on which PATHSEC relies. It describes PATHSEC, including the RPKI on which PATHSEC relies. It describes
how the design of the RPKI (and the PATHSEC design goals) address how the design of the RPKI (and the PATHSEC design goals) address
classes of attacks, where applicable. It also notes residual classes of attacks, where applicable. It also notes residual
vulnerabilities. vulnerabilities.
7. IANA Considerations 7. Acknowledgements
[Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this version of the document.]
8. Acknowledgements
TBD The authors with to thank the members of the SIDR working group for
the extensive feedback provided during the development of this
document.
9. Informative References 8. Informative References
[Kelly70] Kelly, W., "'We Have Met the Enemy, and He is Us': Pogo [Kelly70] Kelly, W., "We Have Met The Enemy and He Is Us: Pogo Earth
Earth Day Poster", April 1970. Day Poster", April 1970.
[Kent2000] [Kent2000]
Kent, S., Lynn, C., and K. Seo, "Design and Analysis of Kent, S., Lynn, C., and K. Seo, "Design and Analysis of
the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX
Conference, June 2000. Conference, June 2000.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
skipping to change at page 19, line 46 skipping to change at page 19, line 43
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, Infrastructure (RPKI) to Router Protocol", RFC 6810,
January 2013. January 2013.
[SIDR-CH] "Secure Inter-Domain Routing: Charter for Working Group", [SIDR-CH] "Secure Inter-Domain Routing: Charter for Working Group",
September 2013, <http://tools.ietf.org/wg/sidr/ September 2013, <http://tools.ietf.org/wg/sidr/
charters?item=charter-sidr-2013-09-20.txt>. charters?item=charter-sidr-2013-09-20.txt>.
[Sam04] Samuel, A., "Hacktivism and the Future of Political [Sam04] Samuel, A., "Hacktivism and the Future of Political
Participation", Ph.D. dissertation, Harvard University, Participation", Ph.D. dissertation, Harvard University,
August 2004. September 2004, <http://www.alexandrasamuel.com/
dissertation/pdfs/Samuel-Hacktivism-entire.pdf>.
Authors' Addresses Authors' Addresses
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
US USA
Email: kent@bbn.com EMail: kent@bbn.com
Andrew Chi Andrew Chi
University of North Carolina - Chapel Hill University of North Carolina - Chapel Hill
c/o Department of Computer Science c/o Department of Computer Science
CB 3175, Sitterson Hall CB 3175, Sitterson Hall
Chapel Hill, NC 27599 Chapel Hill, NC 27599
US USA
Email: achi@cs.unc.edu EMail: achi@cs.unc.edu
 End of changes. 118 change blocks. 
373 lines changed or deleted 373 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/