draft-ietf-sidr-bgpsec-threats-00.txt   draft-ietf-sidr-bgpsec-threats-01.txt 
Secure Inter-Domain Routing S. Kent Secure Inter-Domain Routing S. Kent
Internet-Draft BBN Internet-Draft A. Chi
Intended status: Standards Track Intended status: Standards Track BBN
Expires: December 24, 2011 Expires: August 6, 2012 February 3, 2012
June 24, 2011
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-00.txt draft-ietf-sidr-bgpsec-threats-01
Abstract Abstract
This document describes a threat model for BGP path security This document describes a threat model for BGP path security
(BGPSEC). BGPSEC is assumed to make use of the Resource Public Key (BGPSEC). It assumes the context established by the SIDR WG charter,
Infrastructure (RPKI) already developed in the SIDR WG [I-D.ietf- as of April 19, 2011. The charter established two goals for the SIDR
sidr-arch], and thus threats and attacks against the RPKI are part of work:
this model. The model assumes that BGP path security is achieved
through the application of digital signatures to AS_Path Info. The o Enabling an AS to verify the authorization of an origin AS to
document characterizes classes of potential adversaries that are originate a specified set of prefixes
considered to be threats, and examines classes of attacks that might
be launched against BGPSEC. It concludes with brief discussion of o Enabling an AS to verify that the AS-PATH represented in a route
residual vulnerabilities. matches the path travelled by the NLRI for the route
The charter further mandates that SIDR build upon the Resource Public
Key Infrastructure (RPKI), the first product of the WG. Consistent
with the charter, this threat model includes an analysis of the RPKI,
and focuses on the ability of an AS to verify the authenticity of the
AS path info received in a BGP update.
The model assumes that BGP path security is achieved through the
application of digital signatures to AS_Path Info. The document
characterizes classes of potential adversaries that are considered to
be threats, and examines classes of attacks that might be launched
against BGPSEC. It concludes with brief discussion of residual
vulnerabilities.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 24, 2011. This Internet-Draft will expire on August 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Threat Characterization . . . . . . . . . . . . . . . . . . . 4 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 9
4. Attack Characterization . . . . . . . . . . . . . . . . . . . 5 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 11
4.1. Active wiretapping of links between routers . . . . . . . . 5 4.1. Active wiretapping of links between routers . . . . . . . 11
4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . . 5 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 11
4.3. Attacks on ISP management computers (non-CA computers) . . 7 4.3. Attacks on network operator management computers
4.4. Attacks on a repository publication point . . . . . . . . . 7 (non-CA computers) . . . . . . . . . . . . . . . . . . . . 13
4.5 Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . . 8 4.4. Attacks on a repository publication point . . . . . . . . 14
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 7 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document describes the security context in which BGPSEC is This document describes the security context in which BGPSEC is
intended to operate. It discusses classes of potential adversaries intended to operate. It discusses classes of potential adversaries
that are considered to be threats, and classes of attacks that might that are considered to be threats, and classes of attacks that might
be launched against BGPSEC. Because BGPSEC depends on the Resource be launched against BGPSEC. Because BGPSEC depends on the Resource
Public Key Infrastructure (RPKI), threats and attacks against the Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch], threats and
RPKI also are discussed. attacks against the RPKI are included. This model also takes into
consideration classes of attacks that are enabled by the use of
BGPSEC (based on the current BGPSEC design.)
The motivation for developing BGPSEC, i.e., residual security The motivation for developing BGPSEC, 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 papers note that BGP does not include mechanisms that All of these papers note that BGP does not include mechanisms that
allow an Autonomous System (AS) to verify the legitimacy and allow an Autonomous System (AS) to verify the legitimacy and
authenticity of BGP route advertisements. (BGP now mandates support authenticity of BGP route advertisements. (BGP now mandates support
for mechanisms to secure peer-peer communication, i.e., for the links for mechanisms to secure peer-peer communication, i.e., for the links
that connect BGP routers. There are several secure protocol options that connect BGP routers. There are several secure protocol options
to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO
[RFC5925]. This document briefly notes the need to address this [RFC5925]. This document briefly notes the need to address this
aspect of BGP security, but focuses on application layer BGP security aspect of BGP security, but focuses on application layer BGP security
issues that are addressed by BGPSEC.) issues that are addressed by BGPSEC.)
RFC 4272 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 be disruptions caused by legitimate BGP speakers is real and cannot
ignored. be ignored.
BGPSEC is intended to address the concerns cited above, to provide BGPSEC is intended to address the concerns cited above, to provide
significantly improved path security, and to build upon the secure significantly improved path security, building upon the secure route
route origination foundation offered by use of the RPKI. origination foundation offered by use of the RPKI. Specifically, the
Specifically, the RPKI enables relying parties (RPs) to determine of RPKI enables relying parties (RPs) to determine if the origin AS for
the origin AS for a path was authorized to advertise the prefix a path was authorized to advertise the prefix contained in a BGP
contained in a BGP update message. This security feature is enabled update message. This security feature is enabled by the use of two
by the use of two types of digitally signed data: a PKI [I-D.sidr- types of digitally signed data: a PKI [I-D.ietf-sidr-res-certs] that
res-certs] that associates one or more prefixes with the public associates one or more prefixes with the public key(s) of an address
key(s) of an address space holder, and Route Origination space holder, and Route Origination Authorizations (ROAs)
Authorizations (ROAs) [I-D.roa-format] that allows a prefix holder to [I-D.ietf-sidr-roa-format] that allows a prefix holder to specify the
specify the AS(es) that are authorized to originate routes for a AS(es) that are authorized to originate routes for a prefix.
prefix.
The security model adopted for BGPSEC does not assume an "oracle" The security model adopted for BGPSEC 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 notion AS or every BGP router. Instead, the model is based on a local
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 BGPSEC relies. It concludes with a brief infrastructure upon which BGPSEC relies. It concludes with a brief
review of residual vulnerabilities. review of residual vulnerabilities.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in [RFC2119].
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) perceived as malicious, relative to the security policy
of a system. The decision to characterize an entity as an adversary 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 is made by those responsible for the security of a system. Often one
describes classes of adversaries with similar capabilities or describes classes of adversaries with similar capabilities or
motivations, rather than specific individuals or organizations. 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 - 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 (ANS) - 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 registry
to identify an AS in BGP. 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 binding
between the data items in a certificate. 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 autonomous systems, in support of
inter-domain routing. inter-domain routing.
False (Route) Origination - If an ISP originates a route for a prefix False (Route) Origination - If a network operator originates a route
that the ISP does not hold (and that it has not been authorized to for a prefix that the network operator does not hold (and that it has
originate by the prefix holder, this is termed false route not been authorized to originate by the prefix holder, this is termed
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 Number
Authority (IANA), Regional Internet Registries (RIRs), National Authority (IANA), Regional Internet Registries (RIRs), National
Internet Registries (NIRs), and Local Internet registries (LIRs, Internet Registries (NIRs), and Local Internet Registries (LIRs,
ISPs). 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.
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 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., relies on signed data that is verified
using certificates, and CRLs from a PKI. using certificates, and 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, and that issues X509 certificates (and CRLs) that attest to the INRs, and that issues X509 certificates (and CRLs) that attest to 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 Cryptographic Message
Syntax (CMS)-encapsulated data object complying with the format and Syntax (CMS)-encapsulated data object complying with the format and
semantics defined in [draft-ietf-sidr-signed-object-02.txt]. semantics defined in [I-D.ietf-sidr-signed-object].
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 for
the prefix can be directed. 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 AS- routes that it has received from an AS-B to AS-A's neighbors, but
A is not viewed as a transit provider for the prefixes in the route. 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 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
The following classes of threats are addressed in this document. The following classes of threats are addressed in this document.
BGP speakers - A BGP speaker, e.g., an ISP or a multi-homed non-ISP Network Operators - A network operator may be a threat. A network
subscriber, may be a threat. (For simplicity, the remainder of this operator may be motivated to cause BGP routers it controls to emit
document refers to BGP speakers as ISPs.) An ISP may be motivated to update messages with inaccurate routing info, e.g. to cause traffic
cause BGP routers controlled by the ISP to emit update messages with to flow via paths that are economically advantageous for the
inaccurate routing info. Such updates might cause traffic to flow via operator. Such updates might cause traffic to flow via paths that
paths that would otherwise be rejected as less advantageous by other would otherwise be rejected as less advantageous by other network
ISPs. Because the ISP controls the BGP routers that it operates, it operators. Because a network operator controls the BGP routers in
is in a position to modify their operation. Routers operated by the its network, it is in a position to modify their operation in
ISP are vehicles for mounting MITM attacks on both control and data arbitrary ways. Routers managed by a network operator are vehicles
plane traffic. If the ISP participates in the RPKI, it will have at for mounting MITM attacks on both control and data plane traffic. If
least CA resource certificate and may be able to generate an a network operator participates in the RPKI, it will have at least CA
arbitrary number of subordinate CA certificates and ROAs. It will be resource certificate and may be able to generate an arbitrary number
authorized to populate (and may even host) its own repository of subordinate CA certificates and ROAs. It will be authorized to
publication point. If it implements BGPSEC, it will have the ability populate (and may even host) its own repository publication point.
to issue certificates for its routers, and to sign updates in a If it implements BGPSEC, it will have the ability to issue
fashion that will be recognized by BGPSEC-enabled ISP neighbors. certificates for its routers, and to sign updates in a fashion that
will be recognized by BGPSEC-enabled neighbors.
Hackers - Hackers are considered a threat. Hackers might assume Hackers - Hackers are considered a threat. A hacker might assume
control of network management computers and routers operated by ISPs, control of network management computers and routers controlled by
including ISPs that implement BGPSEC. In such cases, hackers would be network operators, including network operators that implement BGPSEC.
able to act as a rogue ISP (see above). It is assumed that hackers In such cases, hackers would be able to act as a rogue network
generally do not have the capability to effect MITM attacks on most operators (see above). It is assumed that hackers generally do not
links between ISPs. Hackers might be recruited, without their have the capability to effect MITM attacks on most links between
knowledge, by criminals or by nations, to act on their behalf. 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.
Criminals - Criminals may be a threat. Criminals might persuade (via Criminals - Criminals may be a threat. Criminals might persuade (via
threats or extortion) an ISP to act as rogue ISP (see above), and threats or extortion) a network operator to act as a rogue network
thus be able to effect a wide range of attacks. Criminals might operator (see above), and thus be able to effect a wide range of
persuade telecom staff to enable MITM attacks on links between attacks. Criminals might persuade the staff of a telecommunications
routers. The motivation for criminals may include the ability to provider to enable MITM attacks on links between routers.
extort money from other ISPs or ISP clients, e.g., by adversely Motivations for criminals may include the ability to extort money
affecting routing for these ISPs or clients. They may wish to from network operators or network operator clients, e.g., by
manipulate routing to conceal the sources of spam or of DoS attacks. 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 Registries - Any registry in the RPKI could be a threat. Staff at
registry are capable of manipulating repository content or the registry are capable of manipulating repository content or
mismanaging RPKI certificates. These actions could adversely affect mismanaging the RPKI certificates that they issue. These actions
the operation of an ISP or a client of an ISP. The staff could be could adversely affect a network operator or a client of a network
motivated to do this based on political pressure from the nation in operator. The staff could be motivated to do this based on political
which it operates (see below). 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 Nations - A nation may be a threat. A nation may control one or more
ISPs that operate in the nation, and thus can cause them to act as network operators that operate in the nation, and thus can cause them
rogue ISPs. A nation may have a technical active wiretapping to act as rogue network operators. A nation may have a technical
capability (e.g., within its territory) that enables it to effect active wiretapping capability (e.g., within its territory) that
MITM attacks on inter-ISP traffic. It may have an ability to attack enables it to effect MITM attacks on inter-network traffic. (This
and take control of routers or management network computers of ISPs capability may be facilitated by control or influence over a
in other countries. A nation may control a registry that operates telecommunications provider operating within the nation.) It may
within its territory, and might force the registry to act as a rogue have an ability to attack and take control of routers or management
capacity. National threat motivations include the desire to control network computers of network operators in other countries. A nation
the flow of traffic to/from the nation or to divert traffic destined may control a registry (e.g., an RIR) that operates within its
for other nations (for passive or active wiretapping, including DoS). territory, and might force that registry to act in a rogue capacity.
A manifest associated with a CA's repository publication point National threat motivations include the desire to control the flow of
contains a list of: traffic to/from the nation or to divert traffic destined for other
nations (for passive or active wiretapping, including DoS).
4. Attacks 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. Attacks are classified based on the target against Internet routing (relative to the context described in
of the attack, as an element of the routing system, or the routing Section 1). Attacks are classified based on the target of the
security infrastructure on which BGPSEC relies. In general, attacks attack, as an element of the routing system, or the routing security
of interest are ones that attempt to violate the integrity or infrastructure on which BGPSEC relies. In general, attacks of
interest are ones that attempt to violate the integrity or
authenticity of BGP traffic, or which violate the authorizations authenticity of BGP traffic, or which 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 are not violate the implied confidentiality of routing traffic are not
considered significant (see 4.1 below). considered significant (see Section 4.1 below).
4.1. Active wiretapping of links between routers 4.1. Active wiretapping of links between routers
An adversary may attack the links that connect BGP routers. Passive An adversary may attack the links that connect BGP routers. Passive
attacks are not considered, because it is assumed that most of the attacks are not considered, because it is assumed that most of the
info carried by BGP will otherwise be accessible to adversaries. info carried by BGP will otherwise be accessible to adversaries.
Several classes of adversaries are assumed to be capable of MITM Several classes of adversaries are assumed to be capable of MITM
effecting attacks against the control plane traffic. MITM attacks may effecting attacks against the control plane traffic. MITM attacks
be directed against BGP, BGPSEC, or against TCP or IP. Such attacks may be directed against BGP, BGPSEC, or against TCP or IP. Such
include replay of selected BGP messages, selective modification of attacks include replay of selected BGP messages, selective
BGP messages, and DoS attacks against BGP routers. modification of BGP messages, and DoS attacks against BGP routers.
4.2. Attacks on a BGP router 4.2. Attacks on a BGP router
An adversary may attack a BGP router, whether it implements BGPSEC or An adversary may attack a BGP router, whether it implements BGPSEC or
not. Any adversary that controls routers legitimately, or that can not. Any adversary that controls routers legitimately, or that can
assume control of a router, is assumed to be able to effect the types 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 of attacks described below. Note that any router behavior that can
ascribed to a local routing policy decision is not considered to be be ascribed to a local routing policy decision is not considered to
an attack. This is because such behavior could be explained as a 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 result of local policy settings, and thus is beyond the scope of what
BGPSEC can detect as unauthorized behavior. Thus, for example, a BGPSEC can detect as unauthorized behavior. Thus, for example, a
router may fail to propagate some or all route withdrawals or effect router may fail to propagate some or all route withdrawals or effect
"route leaks". (These behaviors are not precluded by the "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.) attacks. See Section 5 for additional discussion.)
AS Insertion: A router might insert one or more ASNs, other than Attacks on a router are active wiretapping attacks (in the most
its own ASN, into an update message. This violates the BGP spec general sense) that manipulate (forge, tamper with, or suppress) data
and thus is considered an attack. contained in BGP updates. The list below illustrates attacks of this
type.
False (route) Origination: A router might originate a route for AS Insertion: A router might insert one or more ASNs, other than
a prefix, when the AS that the router represents is not its own ASN, into an update message. This violates the BGP spec
authorized to originate routes for that prefix. This is an and thus is considered an attack.
attack.
Secure Path Downgrade: A router might remove signatures from a False (Route) Origination: A router might originate a route for a
BGPSEC update that it receives, when forwarding this update to a prefix, when the AS that the router represents is not authorized
BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec to originate routes for that prefix. This is an attack.
and thus is considered an attack.
Invalid Signature Insertion: A router might emit a signed update Secure Path Downgrade: A router might remove signatures from a
with a "bad" signature, i.e., a signature that cannot be BGPSEC update that it receives, when forwarding this update to a
validated by other BGPSEC routers. (This might occur due to use BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec
of a revoked or expired certificate, a computational error, or a and thus is considered an attack.
syntactic error.) This behavior violates the BGPSEC spec and
thus is considered an attack.
Stale Path Announcement: An announcement may be propagated with Invalid Signature Insertion: A router might emit a signed update
an origination signature segment expiry value that is not with a "bad" signature, i.e., a signature that cannot be validated
current. This behavior violates the BGPSEC spec and is by other BGPSEC routers. This might be an intentional act, or it
considered a possible replay attack. might occur due to use of a revoked or expired certificate, a
computational error, or a syntactic error. Such behavior violates
the BGPSEC spec and thus is considered an attack.
Premature Path Announcement Expiration: A router might emit a Stale Path Announcement: An announcement may be propagated with an
signed update with an origin expiry time that is very short. The origination signature segment that has expired. This behavior
BGPSEC protocol specification does not mandate a minimum expiry violates the BGPSEC spec and is considered a possible replay
time. However, an immediate neighbor of a route originator attack.
should expect to see an expiry time that not substantially less
than XX in the future. Later routers along a path generally
cannot determine if a shorter expiry time is "suspicious" since
they cannot know how long a route may have been held by an
earlier AS, prior to being released. Thus this consideration
applies only to an immediate neighbor of a route originator.
MITM Attack: A cryptographic key used for point-to-point Premature Path Announcement Expiration: A router might emit a
security (e.g., TCP-AO or IPsec) between two BGP routers might signed update with an origin expiry time that is very short.
be compromised (e.g., by extraction from a router). This would Unless the BGPSEC protocol specification mandates a minimum expiry
enable an adversary to effect MITM attacks on the link(s) where time, this is not an attack. However, if such a time is mandates,
the key is used. this behavior becomes an attack. BGP speakers along a path
generally cannot determine if an expiry time is "suspiciously
short" since they cannot know how long a route may have been held
by an earlier AS, prior to being released. Thus only an immediate
neighbor of a route originator could be expected to detect this
type of attack.
Compromised Private Key: The private key associated with an RPKI MITM Attack: A cryptographic key used for point-to-point security
EE certificate issued to a router might be compromised by an (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be
attack against the router. An adversary with access to this key compromised (e.g., by extraction from a router). This would
would be able to generate updates that appear to be from this enable an adversary to effect MITM attacks on the link(s) where
router (or from any routers that share this key and the key is used. Use of specific security mechanisms to protect
certificate). If the adversary controlled another ISP, it could inter-router links between ASes is outside the scope of BGPSEC.
use this key to forge signatures that appear to come from the However, XXX
router(s) in question, thus making it appear that those routers
were misbehaving.
Replay Attack: An update may be signed and announced, and later Compromised Router Private Key: The private key associated with an
withdrawn. The adversary controlling intermediate routers does RPKI EE certificate issued to a router might be compromised by an
not propagate the withdrawal but instead re-announces (i.e., attack against the router. An adversary with access to this key
replays) the previous announcement within its expiry time if it would be able to generate updates that appear to be from this
has not yet expired. router (or from any routers that share this key and certificate).
If the adversary controlled another network operator, it could use
this key to forge signatures that appear to come from the
router(s) in question, thus making it appear that those routers
were misbehaving.
4.3. Attacks on ISP management computers (non-CA computers) Replay Attack: A BGPSEC-protected update may be signed and
announced, and later withdrawn. An adversary controlling
intermediate routers could fail to propagate the withdrawal, and
instead re-announce (i.e., replay) a previous announcement (that
has not yet expired). BGP is already vulnerable to behavior of
this sort; re-announcement cannot be characterized as an attack,
under the assumptions upon which this mode is based (i.e., no
oracle).
An adversary may choose to attack computers used by an ISP to manage 4.3. Attacks on network operator management computers (non-CA
its network, especially its routers. Such attacks might be effected computers)
by an adversary that has compromised the security of these computers.
This might be effected via remote attacks, extortion of selected ISP
staff, etc. If an adversary compromises NOC computers, it can execute
any management function that authorized ISP 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.
If the ISP participates in the RPKI, the adversary could manipulate An adversary may choose to attack computers used by a network
the RP tools that extract data from the RPKI, causing the output of operator to manage its network, especially its routers. Such attacks
these tools to be corrupted in various ways. For example, an attack might be effected by an adversary that has compromised the security
of this sort could cause the ISP to view valid routes as not of these computers. This might be effected via remote attacks,
validated, which could alter its routing behavior. extortion of selected network operations staff, etc. If an adversary
compromises NOC computers, it 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 network operator behavior.
If the adversary invoked the tool used to manage the repository If a network operator participates in the RPKI, an adversary could
publication point for this ISP, it could delete any objects stored manipulate the RP tools that extract data from the RPKI, causing the
there (certificates, CRLs, manifests, ROAs, or subordinate CA output of these tools to be corrupted in various ways. For example,
certificates). This could affect the routing status of entities that an attack of this sort could cause the network operator to view valid
have allocations/assignments from this ISP (e.g., by deleting their routes as not validated, which could alter its routing behavior.
CA certificates).
An attacker could invoke the tool used to request certificate If an adversary invoked the tool used to manage the repository
publication point for this network 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 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 ISP, but also any ISPs that receive allocations/assignments only this network operator, but also any network operators that
from it, e.g., because their CA certificates were revoked. receive allocations/assignments from it, e.g., because their CA
certificates were revoked.
It the ISP is BGPSEC-enabled, an attack of this sort could cause the If a network operator is BGPSEC-enabled, an attack of this sort could
affected ISP to be viewed as not BGPSEC-enabled, possibly making cause the affected network operator to be viewed as not BGPSEC-
routes it emits be less preferred. enabled, possibly making routes it emits be less preferred by other
network 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 re-allocate some of the prefixes allocated/assigned to
the ISP (e.g., by modifying the origin AS in ROAs). This might cause the network operator (e.g., by modifying the origin AS in ROAs).
other BGPSEC-enabled ISPs, and other RPKI-enabled ISPs, to view the This might cause other BGPSEC-enabled networks to view the affected
ISP as no longer originating routes for these prefixes. Multi-homed network as no longer originating routes for these prefixes. Multi-
subscribers of this ISP who received a PA allocation from the ISP homed subscribers of this network operator who received an allocation
might find their traffic was now routed via other connections. from the network operator might find their traffic was now routed via
other connections.
If the ISP is BGPSEC-enabled, and the adversary invoked a tool used If the network operator is BGPSEC-enabled, and the adversary invoked
to request certificates, it could replace valid certificates for a tool used to request certificates, it could replace valid
routers with ones that might be rejected by BGPSEC-enabled certificates for routers with ones that might be rejected by BGPSEC-
neighbors. 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 adversary A critical element of the RPKI is the repository system. An
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 inside or an external threat. Because all repository effected by an inside 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. Attacks that delete signed and verify from the repository system. Attacks that delete signed
products, that insert products with "bad" signatures, that tamper products, that insert products with "bad" signatures, that tamper
with object signatures, or that replace newer objects with older with object signatures, or that replace newer objects with older
(valid) ones, can be detected by RPs (with a few exceptions). RPs are (valid) ones, can be detected by RPs (with a few exceptions). RPs
expected to make use of the cached repository data until attacks that are expected to make use of local caches. If repository publication
violate the integrity of publication points (and which are detected) points are unavailable or the retrieved data is corrupted, an RP can
are resolved. Thus the impact of such attacks is mitigated in part by revert to using the cached data. This behavior helps insulate RPs
the design of the repository system. 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 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, and cause RPs to not accept the signature on the product will fail, causing RPs to not accept it.
it. This is equivalent to deleting the object, on many respects. This is equivalent to deleting the object, in many respects.
If an adversary deletes one or more CA certificates, ROAs or the CA's If an adversary deletes one or more CA certificates, ROAs or the CRL
CRL at a publication point, the manifest for that publication point for a publication point, the manifest for that publication point will
will allow an RP to detect this attack. (The RP would be very unhappy allow an RP to detect this attack. (The RP would be very unhappy if
if there is no CRL for the CA instance anyway.) An RP can continue to there is no CRL for the CA instance anyway.) An RP can continue to
use the last valid instance of the deleted object as a local policy use the last valid instance of the deleted object as a local policy
option), thus minimizing the impact of such an attack. option), 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 an RP, and should result in older instance), that is detectable by RPs. Such behavior should
the CA being notified of the problem. An RP can continue to use the result in the CA (or publication point maintainer) being notified of
last valid instance of the deleted object as a local policy option), the problem. An RP can continue to use the last valid instance of
thus minimizing the impact of such an attack. 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 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 [ietf- manifest (and the CRL that it matches) will be "stale" (see
sidr-manifest]). This alerts an RP that there may be a problem, and, [I-D.ietf-sidr-rpki-manifests]). This alerts an RP that there may be
hopefully, the CA responsible for the publication point will be asked a problem, and, hopefully, the entity responsible for the publication
to remedy the problem (republish the missing CA certificates and/or point will be asked to remedy the problem (e.g., republish the
ROAs). An RP cannot know the content of the new certificates or ROAs missing CA certificates and/or ROAs). An RP cannot know the content
that are not present, but it can continue to use what it has cached. 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 un aware 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 If a CA revokes a CA certificate or a ROA (via deleting the
corresponding EE certificate), and the adversary tries to reinstate corresponding EE certificate), and the adversary tries to reinstate
that CA certificate or ROA, the adversary would have to rollback the 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 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. would make the CRL and manifest stale, and this is detectable by RPs.
An RP cannot know which CA certificates or ROAs were deleted, and so An RP cannot know which CA certificates or ROAs were deleted.
it would use the cached instances of the affected objects. Here too Depending on local policy, the RP might use the cached instances of
one hopes that the CA will be notified of the problem and will the affected objects, and thus be tricked into making decisions based
attempt to remedy the error. on these revoked objects. Here too the hope 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 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 be detect the has passed. Until the next issue date, an RP will not be 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 tradeoff between risk two are linked) that represent an acceptable tradeoff 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 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 adversaries listed in Section 2 are presumed to be capable of
launching attacks against the computers used to perform CA functions. launching attacks against the computers used to perform CA functions.
Some adversaries might effect an attack on a CA by violating Some adversaries might effect an attack on a CA by violating
personnel or physical security controls as well. The distinction personnel or physical security controls as well. The distinction
between CA as adversary vs. CA as an attack victim is important. Only between CA as adversary vs. CA as an attack victim is important.
in the latter case should one expect the CA to remedy problems caused Only in the latter case should one expect the CA to remedy problems
by a attack once the attack has been detected. Note that most of the caused by a attack once the attack has been detected. (If a CA does
attacks described below do not require disclosure of a CA's private not take such action, the effects are the same as if the CA is an
key to an adversary. If the adversary can gain control of the adversary.)
computer used to issue certificates, it can effect these attacks,
even though the private key for the CA remains "secure" (i.e., not Note that most of the attacks described below do not require
disclosed to unauthorized parties). However, if the CA is not the disclosure of a CA's private key to an adversary. If the adversary
adversary, and if the CA's private key is not compromised, then can gain control of the computer used to issue certificates, it can
recovery from these attacks is much easier. This motivates use of effect these attacks, even though the private key for the CA remains
hardware security modules to protect CA keys, at least for higher "secure" (i.e., not disclosed to unauthorized parties). However, if
tiers in the RPKI. 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 An attack by a CA can result in revocation or replacement of any of
the certificates that the CA 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 consider considered invalid, transitively. As a result, RPs would not
as valid any ROAs or signed updates based on these certificates, consider as valid any ROAs or BGPSEC-signed updates based on these
which would make routes dependent on them to be less preferred. certificates, which would make routes dependent on them to be less
Because a CA that revokes a certificate is authorized to do so, this preferred. Because a CA that revokes a certificate is authorized to
sort of attack cannot be detected, intrinsically, by most RPs. do so, this sort of attack cannot be detected, intrinsically, by most
However, the entities affected by the revocation or replacement of CA RPs. However, the entities affected by the revocation or replacement
certificates can be expected to detect the attack and contact the CA of CA certificates can be expected to detect the attack and contact
to effect remediation. If the CA was not the adversary, it should be the CA to effect remediation. If the CA was not the adversary, it
able to issue new certificates and restore the publication point. should be able to issue new certificates and restore the publication
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 very and signed products. An attacker could publish certificates with
brief validity intervals, or CRLs and manifests that become "stale" very brief validity intervals, or CRLs and manifests that become
very quickly. This sort of attack would cause RPs to have 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 RPs publication point, etc. All of these types of DoS attacks against
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 as valid any ROAs issued under the affected CA
certificate, and updates based on router certificates issued by the certificate, and updates based on router certificates issued by the
affected CA would be rejected. This would make routes dependent on affected CA would be rejected. This would make routes dependent on
these signed products to be less preferred. However, the constraints these signed products to be less preferred. However, the constraints
imposed by the use of RFC 3779 [RFC3779] extensions do prevent a imposed by the use of RFC 3779 [RFC3779] extensions do prevent a
compromised CA from issuing (valid) certificates with INRs outside compromised CA from issuing (valid) certificates with INRs outside
the scope of the CA, thus limiting the impact of the attack. 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 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 RFC 3779
extensions do prevent a compromised CA from issuing (valid) extensions prevent a compromised CA from issuing (valid) certificates
certificates with INRs outside the scope of the CA, thus limiting the with INRs outside the scope of the CA, thus limiting the impact of
impact of the attack. 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 (as first noted by Pogo). For inadvertently act as an attacker (as first noted by Pogo). For
example, a CA might fail to replace its own certificate in a timely 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 fashion (well before it expires). If might fail to issue its CRL and
manifest prior to expiration, creating stale instances of these manifest prior to expiration, creating stale instances of these
products that cause concern for RPs. A CA with many subordinate CAs 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 (e.g., an RIR or NIR) might fail to distribute the expiration times
for the CA certificates that it issues. An ISP with many ROAs might for the CA certificates that it issues. A network with many ROAs
do the same for the EE certificates associated with the ROAs it might do the same for the EE certificates associated with the ROAs it
generates. A CA could rollover its key, but fail to reissue generates. A CA could rollover its key, but fail to reissue
subordinate CA certificates under its new key. Poor planning with subordinate CA certificates under its new key. Poor planning with
regard to rekey intervals for managed CAs could impose undue burdens regard to rekey intervals for managed CAs could impose undue burdens
for RPs, despite a lack of malicious intent. All of these example of for RPs, despite a lack of malicious intent. All of these example of
mismanagement could adversely affect RPs, despite the absence of mismanagement could adversely affect RPs, despite the absence of
malicious intent. malicious intent.
5. Residual Vulnerabilities 5. Residual Vulnerabilities
The RPKI, upon which BGPSEC relies, has several residual The RPKI, upon which BGPSEC relies, has several residual
vulnerabilities that were been discussed in the preceding text vulnerabilities that were discussed in the preceding text
(Sections 4.4 and 4.5). These vulnerabilities are of two principle (Section 4.4 and Section 4.5). These vulnerabilities are of two
forms: principle forms:
- the RPKI repository system may be attacked in ways that make o the RPKI repository system may be attacked in ways that make its
its contents unavailable, or not current. It is anticipated that contents unavailable, not current, or inconsistent. The principle
RPs will cope with this vulnerability through local caching of defense against most forms of DoS attacks is the use of a local
repository data, and through local settings that tolerate cache by RPs. The local cache ensures availability of previously-
expired or stale repository data. acquired RPKI data, in the event that a repository is inaccessible
or if repository contents are deleted (maliciously). Nonetheless,
the system cannot ensure that every RP will always have access to
up-to-date RPKI data. An RP, when it detects a problem with
acquired repository data has two options:
- any CA in the RPKI may misbehave within the bounds of the 1. The RP may choose to make use of its local cache, employing
resources allocated to it, e.g., it may issue certificates with local configuration settings that tolerate expired or stale
duplicate resource allocations or revoke certificates objects. (Such behavior is, nominally, always within the
inappropriately. This vulnerability is intrinsic in any PKI. It purview of an RP in PKI.) Using cached, expired or stale data
is anticipated that RPs will deal with this through subjects the RP to attacks that take advantage of the RP's
ignorance of changes to this data.
BGPSEC has a separate set of residual vulnerabilities: 2. The RP may chose to purge expired objects. Purging expired
objects removes the security info associated with the real
world INRs to which the objects refer. This is equivalent to
the affected INRs not having been afforded protection via the
RPKI. Since use of the RPKI (and BGPSEC) is voluntary, there
may always be set of INRs that are not protected by these
mechanisms. Thus purging moves the affected INRs to the set
of non-participating INR holders. This more conservative
response enables an attacker to move INRs from the protected
to the unprotected set.
- BGPSEC is not able to prevent what is usually referred to as o any CA in the RPKI may misbehave within the bounds of the INRs
route leaks, because BGP itself does not distinguish between allocated to it, e.g., it may issue certificates with duplicate
transit and non-transit ASes- BGPSEC signatures do not protect resource allocations or revoke certificates inappropriately. This
all attributes associated with an AS_path. Some of these vulnerability is intrinsic in any PKI, but its impact is limited
attributes are employed as inputs to routing decisions. Thus in the RPKI because of the use or RFC 3779 extensions. It is
attacks that modify (or strip) these other attributes are not anticipated that RPs will deal with such misbehavior through
detected by BGPSEC. administrative means, once it is detected.
BGPSEC has a separate set of residual vulnerabilities:
o BGPSEC is not able to prevent what is usually referred to as route
leaks, because BGP itself does not distinguish between transit and
non-transit ASes. It might be possible to address this
vulnerability if every AS were required to publish its status as a
transit or non-transit AS, relative to its peers. However, route
leaks are outside the scope of the SIDR charter at the time this
document was prepared.
o BGPSEC signatures do not protect all attributes associated with an
AS_path. Some of these attributes are employed as inputs to
routing decisions. Thus attacks that modify (or strip) these
other attributes are not detected by BGPSEC. The SIDR charter
calls for protecting only the info needed to verify that a
received route traversed the ASes on question, and that the NLRI
in the route is what was advertised. Thus, protection of other
attributes is outside the scope of the charter, at the time this
document was prepared.
6. Security Considerations 6. Security Considerations
A threat model is, by definition, a security-centric document. Unlike A threat model is, by definition, a security-centric document.
a protocol description, a threat model does not create security Unlike a protocol description, a threat model does not create
problems nor purport to address security problems. This model security problems nor purport to address security problems. This
postulates a set of threats (i.e., motivated, capable adversaries) model postulates a set of threats (i.e., motivated, capable
and examines classes of attacks that these threats are capable of adversaries) and examines classes of attacks that these threats are
effecting, based on the motivations ascribed to the threats. It capable of effecting, based on the motivations ascribed to the
describes the impact of these types of attacks on BGPSEC, including threats. It describes the impact of these types of attacks on
on the RPKI on which BGPSEC relies. BGPSEC, including on the RPKI on which BGPSEC relies. It describes
how the design of the RPKI (and the current BGPSEC design) address
classes of attacks, where applicable. It also notes residual
vulnerabilities.
7. IANA Considerations 7. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA [Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this version of the document.] considerations stated in this version of the document.]
8. Acknowledgements 8. Acknowledgements
The author wishes to thank . . . The author wishes to thank...
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[RFC4272] [I-D.ietf-sidr-arch]
Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, Lepinski, M. and S. Kent, "An Infrastructure to Support
June 2006 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011.
[RFC4301] [I-D.ietf-sidr-res-certs]
Kent, S. and Seo, K., "Security Architecture for the Internet Huston, G., Michaelson, G., and R. Loomans, "A Profile for
Protocol", RFC 4301, December, 2005. X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-22 (work in progress), May 2011.
[RFC3779] [I-D.ietf-sidr-roa-format]
Lynn, C., Kent, S., Seo, K., X.509 Extensions for IP Addresses Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
and AS Identifiers, RFC 3779, June 2004. Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-12 (work in progress),
May 2011.
[I-D.ietf-sidr-rpki-manifests]
Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure",
draft-ietf-sidr-rpki-manifests-16 (work in progress),
July 2011.
[I-D.ietf-sidr-signed-object]
Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-signed-object-04 (work in progress),
May 2011.
[Kent2000] [Kent2000]
Kent, S., Lynn, C., and Seo, K., "Design and Analysis of the Kent, S., Lynn, C., and K. Seo, "Design and Analysis of
Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX Conference, the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX
June, 2000. Conference, June 2000.
[RFC5925] [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Touch, J., et al., "The TCP Authentication Option", Addresses and AS Identifiers", RFC 3779, June 2004.
RFC 5925, June 2010.
[I-D.ietf-sidr-arch] [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
Lepinski, M. and S. Kent, "An Infrastructure to Support RFC 4272, January 2006.
Secure Internet Routing", draft-ietf-sidr-arch-11.txt
(work in progress), September 2010.
[I-D.sidr.signed-object] [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Lepinski, M, Chi, A., and Kent, S., "Signed Object Template for Internet Protocol", RFC 4301, December 2005.
the Resource Public Key Infrastructure", draft-ietf-sidr-signed-
object-01.txt, (work in progress), December 2010.
[I-D.sidr-res-certs] [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Huston, G., Michaelson, G., and Loomans, R. "A Profile for X.509 Authentication Option", RFC 5925, June 2010.
PKIX Resource Certificates", draft-ietf-sidr-res-certs-21.txt
(work in progress), December 2010.
[I-D.roa-format] [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Lepinski, M., Kent, S., and Kong, D., "A Profile for Route Origin Signature Option", RFC 2385, August 1998.
Authorizations (ROAs)", draft-ietf-sidr-roa-format-09.txt,
(work in progress), November 2010.
Author's Address Authors' Addresses
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
US
Email: kent@bbn.com Email: kent@bbn.com
Andrew Chi
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
US
Email: achi@bbn.com
 End of changes. 130 change blocks. 
412 lines changed or deleted 524 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/