draft-ietf-sidr-bgpsec-threats-02.txt   draft-ietf-sidr-bgpsec-threats-03.txt 
Secure Inter-Domain Routing S. Kent Secure Inter-Domain Routing S. Kent
Internet-Draft A. Chi Internet-Draft A. Chi
Intended status: Standards Track BBN Intended status: Informational BBN
Expires: August 25, 2012 February 22, 2012 Expires: March 18, 2013 September 14, 2012
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-02 draft-ietf-sidr-bgpsec-threats-03
Abstract Abstract
This document describes a threat model for BGP path security This document describes a threat model for the context in which BGP
(BGPSEC). It assumes the context established by the SIDR WG charter, path security mechanisms will be developed. It assumes the context
as of April 19, 2011. The charter established two goals for the SIDR established by the SIDR WG charter, as of April 19, 2011. The
work: charter established two goals for the SIDR work:
o Enabling an AS to verify the authorization of an origin AS to o Enabling an AS to verify the authorization of an origin AS to
originate a specified set of prefixes originate a specified set of prefixes
o Enabling an AS to verify that the AS-PATH represented in a route o Enabling an AS to verify that the AS-PATH [sic] represented in a
matches the path travelled by the NLRI for the route route matches the path traveled by the NLRI for the route
The charter further mandates that SIDR build upon the Resource Public The charter further mandates that SIDR build upon the Resource Public
Key Infrastructure (RPKI), the first product of the WG. Consistent Key Infrastructure (RPKI), the first product of the WG. Consistent
with the charter, this threat model includes an analysis of the RPKI, 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 and focuses on the ability of an AS to verify the authenticity of the
AS path info received in a BGP update. AS path info received in a BGP update. This document does not assume
a specific path security solution approach. However, the model does
assume that any solution approach will make use of the RPKI, at least
for route origin validation. We use the term PATHSEC to refer to any
BGP path security technology that makes use of the RPKI. PATHSEC
will secure EBGP (see [RFC4271]), consistent with the inter-AS
security focus of the RPKI [RFC6480]. References to "BGP" in this
document are to be interpreted as references to EBGP.
The model assumes that BGP path security is achieved through the The document characterizes classes of potential adversaries that are
application of digital signatures to AS_Path Info. The document considered to be threats, and examines classes of attacks that might
characterizes classes of potential adversaries that are considered to be launched against PATHSEC. It does not revisit attacks against
be threats, and examines classes of attacks that might be launched unprotected BGP, as that topic has already been addressed in
against BGPSEC. It concludes with brief discussion of residual [RFC4271]. It concludes with 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 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 August 25, 2012. This Internet-Draft will expire on March 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Threat Characterization . . . . . . . . . . . . . . . . . . . 9 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 9
4. Attack Characterization . . . . . . . . . . . . . . . . . . . 11 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 11
4.1. Active wiretapping of links between routers . . . . . . . 11 4.1. Active wiretapping of sessions between routers . . . . . . 11
4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 11 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 11
4.3. Attacks on network operator management computers 4.3. Attacks on network operator management computers
(non-CA computers) . . . . . . . . . . . . . . . . . . . . 13 (non-CA computers) . . . . . . . . . . . . . . . . . . . . 13
4.4. Attacks on a repository publication point . . . . . . . . 14 4.4. Attacks on a repository publication point . . . . . . . . 14
4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 16 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 16
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 19 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Informative References . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document describes the security context in which BGPSEC is This document describes the security context in which PATHSEC 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 PATHSEC. Because PATHSEC will rely on the
Public Key Infrastructure (RPKI) [RFC6480], threats and attacks Resource Public Key Infrastructure (RPKI) [RFC6480], threats and
against the RPKI are included. This model also takes into attacks against the RPKI are included. This model also takes into
consideration classes of attacks that are enabled by the use of consideration classes of attacks that are enabled by the use of
BGPSEC (based on the current BGPSEC design.) PATHSEC (based on the current PATHSEC design.)
The motivation for developing BGPSEC, 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 papers 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 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 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.
BGPSEC 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 secure route significantly improved path security, building upon the route
origination foundation offered by use of the RPKI. Specifically, the origination validation capability offered by use of the RPKI
RPKI enables relying parties (RPs) to determine if the origin AS for [I-D.ietf-sidr-rpki-rtr]. Specifically, the RPKI enables relying
a path was authorized to advertise the prefix contained in a BGP parties (RPs) to determine if the origin AS for a path was authorized
update message. This security feature is enabled by the use of two to advertise the prefix contained in a BGP update message. This
types of digitally signed data: a PKI [RFC6487] that associates one security feature is enabled by the use of two types of digitally
or more prefixes with the public key(s) of an address space holder, signed data: a PKI [RFC6487] that associates one or more prefixes
and Route Origination Authorizations (ROAs) [RFC6482] that allows a with the public key(s) of an address space holder, and Route
prefix holder to specify the AS(es) that are authorized to originate Origination Authorizations (ROAs) [RFC6482] that allows a prefix
routes for a prefix. holder to specify the AS(es) that are authorized to originate routes
for a prefix.
The security model adopted for BGPSEC 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 BGPSEC relies. It concludes with a brief infrastructure upon which PATHSEC relies. It concludes with a brief
review of residual vulnerabilities. review of residual vulnerabilities, i.e., vulnerabilities that are
not addressed by use of the RPKI and that appear likely to be outside
the scope of PATHSEC mechanisms.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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.
skipping to change at page 6, line 45 skipping to change at page 6, line 41
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 a network operator originates a route False (Route) Origination - If a network operator originates a route
for a prefix that the network operator does not hold (and that it has for a prefix that the operator does not hold (and that it has not
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 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,
network operators). 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
updates, e.g., an ISP.
NOC (Network Operations Center) - A network operator employs a set NOC (Network Operations Center) - A network operator employs a set
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 basis.
The equipment and staff are often referred to as the NOC for the The equipment and staff are often referred to as the NOC for the
network. 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 Certificate Revocation Lists (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 X.509 certificates (and CRLs) that attest to
holdings of INRs. the 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 [RFC6488]. 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 for
the prefix can be directed. (The route includes the origin AS.) 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
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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. As noted in Section 2 above, a threat is defined as a motivated,
capable, adversary. The following classes of threats represent
classes of adversaries viewed as relevant to this environment.
Network Operators - A network operator may be a threat. A network Network Operators - A network operator may be a threat. An operator
operator may be motivated to cause BGP routers it controls to emit may be motivated to cause BGP routers it controls to emit update
update messages with inaccurate routing info, e.g. to cause traffic messages with inaccurate routing info, e.g. to cause traffic to flow
to flow via paths that are economically advantageous for the via paths that are economically advantageous for the operator. Such
operator. Such updates might cause traffic to flow via paths that updates might cause traffic to flow via paths that would otherwise be
would otherwise be rejected as less advantageous by other network rejected as less advantageous by other network operators. Because an
operators. Because a network operator controls the BGP routers in operator controls the BGP routers in its network, it is in a position
its network, it is in a position to modify their operation in to modify their operation in arbitrary ways. Routers managed by a
arbitrary ways. Routers managed by a network operator are vehicles network operator are vehicles for mounting MITM attacks on both
for mounting MITM attacks on both control and data plane traffic. If control and data plane traffic. If an operator participates in the
a network operator participates in the RPKI, it will have at least CA RPKI, it will have at least one CA resource certificate and may be
resource certificate and may be able to generate an arbitrary number able to generate an arbitrary number of subordinate CA certificates
of subordinate CA certificates and ROAs. It will be authorized to and ROAs. It will be authorized to populate (and may even host) its
populate (and may even host) its own repository publication point. own repository publication point. If it implements PATHSEC, and if
If it implements BGPSEC, it will have the ability to issue PATHSEC makes use of certificates associated with routers or ASes, it
certificates for its routers, and to sign updates in a fashion that will have the ability to issue such certificates for itself. If
will be recognized by BGPSEC-enabled neighbors. PATHSEC digitally signs updates, it will be able to do so in a
fashion that will be accepted by PATHSEC-enabled neighbors.
Hackers - Hackers are considered a threat. A hacker might assume 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
network operators, including network operators that implement BGPSEC. operators, including operators that implement PATHSEC. In such
In such cases, hackers would be able to act as a rogue network cases, hackers would be able to act as rogue network operators (see
operators (see above). It is assumed that hackers generally do not above). It is assumed that hackers generally do not have the
have the capability to effect MITM attacks on most links between capability to effect MITM attacks on most links between networks
networks (links used to transmit BGP and subscriber traffic). A (links used to transmit BGP and subscriber traffic). A hacker might
hacker might be recruited, without his/her knowledge, by criminals or be recruited, without his/her knowledge, by criminals or by nations,
by nations, to act on their behalf. Hackers may be motivated by a to act on their behalf. Hackers may be motivated by a desire for
desire for "bragging rights" or for profit. "bragging rights" or for profit or to express support for a cause
("hacktivists" [Sam04]).
Criminals - Criminals may be a threat. Criminals might persuade (via Criminals - Criminals may be a threat. Criminals might persuade (via
threats or extortion) a network operator to act as a rogue network threats or extortion) a network operator to act as a rogue operator
operator (see above), and thus be able to effect a wide range of (see above), and thus be able to effect a wide range of attacks.
attacks. Criminals might persuade the staff of a telecommunications Criminals might persuade the staff of a telecommunications provider
provider to enable MITM attacks on links between routers. to enable MITM attacks on links between routers. Motivations for
Motivations for criminals may include the ability to extort money criminals may include the ability to extort money from network
from network operators or network operator clients, e.g., by operators or network operator clients, e.g., by adversely affecting
adversely affecting routing for these network operators or their routing for these network operators or their clients. Criminals also
clients. Criminals also may wish to manipulate routing to conceal may wish to manipulate routing to conceal the sources of spam, DoS
the sources of spam, DoS attacks, or other criminal activities. 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 political
pressure from the nation in which the registry operates (see below) pressure from the nation in which the registry operates (see below)
or due to criminal influence (see above). 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
skipping to change at page 11, line 11 skipping to change at page 11, line 11
National threat motivations include the desire to control the flow of National threat motivations include the desire to control the flow of
traffic to/from the nation or to divert traffic destined for other traffic to/from the nation or to divert traffic destined for other
nations (for passive or active wiretapping, including DoS). 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, as an element of the routing system, or the routing security
infrastructure on which BGPSEC 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 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, e.g., passive
considered significant (see Section 4.1 below). wiretapping attacks, are not considered a requirement for BGP
security (see [RFC4272]).
4.1. Active wiretapping of links between routers 4.1. Active wiretapping of sessions between routers
An adversary may attack the links that connect BGP routers. Passive An adversary may attack the BGP (TCP) session that connects a pair of
attacks are not considered, because it is assumed that most of the BGP speakers. An active attack against a BGP (TCP) session can be
info carried by BGP will otherwise be accessible to adversaries. effected by directing traffic to a BGP speaker from some remote
Several classes of adversaries are assumed to be capable of MITM point, or by being positioned as a MITM on the link that carries BGP
effecting attacks against the control plane traffic. MITM attacks session traffic. Remote attacks can be effected by any adversary.
may be directed against BGP, BGPSEC, or against TCP or IP. Such However, a MITM attack requires access to the link, and only a few
attacks include replay of selected BGP messages, selective classes of adversaries are assumed to be capable of MITM attacks
modification of BGP messages, and DoS attacks against BGP routers. against a BGP session. MITM attacks may be directed against BGP,
PATHSEC-protected BGP, or against TCP or IP. Such attacks include
replay of selected BGP messages, selective modification of BGP
messages, and DoS attacks against BGP routers. [RFC4272] describes
several countermeasures for such attacks, and thus this document does
not further address such attacks.
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 PATHSEC
not. Any adversary that controls routers legitimately, or that can or not. Any adversary that controls routers legitimately, or that
assume control of a router, is assumed to be able to effect the types can assume control of a router, is assumed to be able to effect the
of attacks described below. Note that any router behavior that can types of attacks described below. Note that any router behavior that
be ascribed to a local routing policy decision is not considered to can be ascribed to a local routing policy decision is not considered
be an attack. This is because such behavior could be explained as a to be an attack. This is because such behavior could be explained as
result of local policy settings, and thus is beyond the scope of what a result of local policy settings, and thus is beyond the scope of
BGPSEC can detect as unauthorized behavior. Thus, for example, a what PATHSEC can detect as unauthorized behavior. Thus, for example,
router may fail to propagate some or all route withdrawals or effect a router may fail to propagate some or all route withdrawals or
"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 active wiretapping attacks (in the most Attacks on a router are equivalent to active wiretapping attacks (in
general sense) that manipulate (forge, tamper with, or suppress) data the most general sense) that manipulate (forge, tamper with, or
contained in BGP updates. The list below illustrates attacks of this suppress) data contained in BGP updates. The list below illustrates
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 originate routes for that prefix. This is an attack. to originate routes for that prefix. This is an attack, but it is
addressed by the use of the RPKI [RFC6480].
Secure Path Downgrade: A router might remove signatures from a Secure Path Downgrade: A router might remove AS_PATH data from a
BGPSEC update that it receives, when forwarding this update to a PATHSEC-protected update that it receives, when forwarding this
BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec update to a PATHSEC-enabled neighbor. This behavior violates the
and thus is considered an attack. PATHSEC security goals and thus is considered an attack.
Invalid Signature Insertion: A router might emit a signed update Invalid AS_PATH Data Insertion: A router might emit a PATHSEC-
with a "bad" signature, i.e., a signature that cannot be validated protected update with "bad" data (such as a signature), i.e.,
by other BGPSEC routers. This might be an intentional act, or it PATHSEC data that cannot be validated by other PATHSEC routers.
might occur due to use of a revoked or expired certificate, a Such behavior is assumed to violate the PATHSEC goals and thus is
computational error, or a syntactic error. Such behavior violates considered an attack.
the BGPSEC spec and thus is considered an attack.
Stale Path Announcement: An announcement may be propagated with an Stale Path Announcement: If PATHSEC-secured announcements can
origination signature segment that has expired. This behavior expire, such an announcement may be propagated with PATHSEC data
violates the BGPSEC spec and is considered a possible replay that is "expired". This behavior would violate the PATHSEC goals
attack. and is considered a type of replay attack.
Premature Path Announcement Expiration: A router might emit a Premature Path Announcement Expiration: If a PATHSEC-secured
signed update with an origin expiry time that is very short. announcement has an associated expiration time, a router might
Unless the BGPSEC protocol specification mandates a minimum expiry emit a PATHSEC-secured announcement with an expiry time that is
time, this is not an attack. However, if such a time is mandates, very short. Unless the PATHSEC protocol specification mandates a
this behavior becomes an attack. BGP speakers along a path minimum expiry time, this is not an attack. However, if such a
generally cannot determine if an expiry time is "suspiciously time is mandated, this behavior becomes an attack. BGP speakers
short" since they cannot know how long a route may have been held along a path generally cannot determine if an expiry time is
by an earlier AS, prior to being released. Thus only an immediate "suspiciously short" since they cannot know how long a route may
neighbor of a route originator could be expected to detect this have been held by an earlier AS, prior to being released.
type of attack.
MITM Attack: A cryptographic key used for point-to-point security MITM Attack: A cryptographic key used for point-to-point security
(e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be
compromised (e.g., by extraction from a router). This would compromised (e.g., by extraction from a router). This would
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 BGPSEC. inter-router links between ASes is outside the scope of PATHSEC.
Compromised Router Private Key: The private key associated with an Compromised Router Private Key: If PATHSEC mechanisms employ
RPKI EE certificate issued to a router might be compromised by an public key cryptography, e.g., to digitally sign data in an
attack against the router. An adversary with access to this key update, then a private key associated with a router or an AS might
would be able to generate updates that appear to have passed be compromised by an attack against the router. An adversary with
through the AS that this router represents. Such updates might be access to this key would be able to generate updates that appear
in injected on a link between the compromised router and its to have passed through the AS that this router represents. Such
neighbors, if that link is accessible to the adversary. If the updates might be in injected on a link between the compromised
adversary controls another network, it could use this key to forge router and its neighbors, if that link is accessible to the
signatures that appear to come from the AS or router(s) in adversary. If the adversary controls another network, it could
question, with some contraints. So, for example, an adversary use this key to forge signatures that appear to come from the AS
that controls another AS could use a compromised router key to or router(s) in question, with some constraints. So, for example,
issue signed routes that include the targeted AS/router, with an adversary that controls another AS could use a compromised
limits. (Neighbors of the adversary's AS ought not accept a route router/AS key to issue PATHSEC-signed data that include the
that purports to emanate directly from the targeted AS. So, an targeted AS/router. (Neighbors of the adversary's AS ought not
adversary can take a legitimate route that passes through the accept a route that purports to emanate directly from the targeted
compromised AS, add itself as the next hop, and then forward the AS. So, an adversary could take a legitimate, protected route
resulting route to neighbors.) that passes through the compromised AS, add itself as the next
hop, and then forward the resulting route to neighbors.)
Replay Attack: A BGPSEC-protected update may be signed and Withdrawal Suppression Attack: A PATHSEC-protected update may be
announced, and later withdrawn. An adversary controlling signed and announced, and later withdrawn. An adversary
intermediate routers could fail to propagate the withdrawal, and controlling intermediate routers could fail to propagate the
instead re-announce (i.e., replay) a previous announcement (that withdrawal. BGP is already vulnerable to behavior of this sort,
has not yet expired). BGP is already vulnerable to behavior of so withdrawal suppression is not characterized as an attack, under
this sort; re-announcement cannot be characterized as an attack, the assumptions upon which this mode is based (i.e., no oracle).
under 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 that has compromised the security might be effected by an adversary who has compromised the security of
of these computers. This might be effected via remote attacks, these computers. This might be effected via remote attacks,
extortion of selected network operations staff, etc. If an adversary extortion of network operations staff, etc. If an adversary
compromises NOC computers, it 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 staff would have performed. Thus
the adversary could modify local routing policy to change the adversary could modify 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 network operator behavior. this appears as a form of rogue operator behavior. (Such behavior
might be perceived as accidental or malicious by other operators.)
If a network operator participates in the RPKI, an adversary could 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 network operator to view valid an attack of this sort could cause the operator to view valid routes
routes as not validated, which could alter its routing behavior. as not validated, which could alter its routing behavior.
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 network operator, it could delete any publication point for this operator, it could delete any objects
objects stored there (certificates, CRLs, manifests, ROAs, or stored there (certificates, CRLs, manifests, ROAs, or subordinate CA
subordinate CA certificates). This could affect the routing status certificates). This could affect the routing status of entities that
of entities that have allocations/assignments from this network have allocations/assignments from this network operator (e.g., by
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 network operator, but also any network operators that only this operator, but also any operators that receive allocations/
receive allocations/assignments from it, e.g., because their CA assignments from it, e.g., because their CA certificates were
certificates were revoked. revoked.
If a network operator is BGPSEC-enabled, an attack of this sort could If an operator is PATHSEC-enabled, an attack of this sort could cause
cause the affected network operator to be viewed as not BGPSEC- the affected operator to be viewed as not PATHSEC-enabled, possibly
enabled, possibly making routes it emits be less preferred by other making routes it emits be less preferred by other operators.
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 network operator (e.g., by modifying the origin AS in ROAs). the network operator (e.g., by modifying the origin AS in ROAs).
This might cause other BGPSEC-enabled networks to view the affected This 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 network operator who received an allocation homed subscribers of this operator who received an allocation from
from the network operator might find their traffic was now routed via the operator might find their traffic was now routed via other
other connections. connections.
If the network operator is BGPSEC-enabled, and the adversary invoked If the network operator is PATHSEC-enabled, and make use of
a tool used to request certificates, it could replace valid certificates associated with routers/ASes, an adversary could invoke
certificates for routers with ones that might be rejected by BGPSEC- a tool used to request such certificates. The adversary could then
enabled neighbors. replace valid certificates for routers/ASes with ones that might be
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 inside 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. 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 (valid) ones, can be detected by RPs (with a few exceptions). RPs
are expected to make use of local caches. If repository publication are expected to make use of local caches. If repository publication
skipping to change at page 15, line 26 skipping to change at page 15, line 32
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. (The RP would be very unhappy if allow an RP to detect this attack. (The RP would be very unhappy 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 RPs. Such behavior should older instance), that is detectable by RPs. Such behavior should
result in the CA (or publication point maintainer) being notified of result in the CA (or publication point maintainer) being notified of
the problem. An RP can continue to use the last valid instance of the problem. An RP can continue to use the last valid instance of
the deleted manifest (a local policy option), thus minimizing the the deleted manifest (a local policy option), thus minimizing the
impact of such an attack. 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, and, [RFC6486]). This alerts an RP that there may be a problem. The RP
hopefully, the entity responsible for the publication point will be should use the information from a Ghostbuster record [RFC6493] to
asked to remedy the problem (e.g., republish the missing CA contact the entity responsible for the publication point, requesting
that entity to remedy the problem (e.g., republish the missing CA
certificates and/or ROAs). An RP cannot know the content of the new certificates and/or ROAs). An RP cannot know the content of the new
certificates or ROAs that are not present, but it can continue to use 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 what it has cached. An attack of this sort will, at least
temporarily, cause RPs to be un aware of the newly published objects. temporarily, cause RPs to be unaware of the newly published objects.
INRs associated with these objects will be treated as INRs associated with 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 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. An RP cannot know which CA certificates or ROAs were deleted.
Depending on local policy, the RP might use the cached instances of Depending on local policy, the RP might use the cached instances of
the affected objects, and thus be tricked into making decisions based the affected objects, and thus be tricked into making decisions based
on these revoked objects. Here too the hope is that the CA will be on these revoked objects. Here too the goal is that the CA will be
notified of the problem (by RPs) and will remedy the error. 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 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 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
skipping to change at page 17, line 16 skipping to change at page 17, line 24
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 BGPSEC-signed updates based on these consider as valid any ROAs or PATHSEC-protected updates based on
certificates, which would make routes dependent on them to be less these certificates, which would make routes dependent on them to be
preferred. Because a CA that revokes a certificate is authorized to less preferred. Because a CA that revokes a certificate is
do so, this sort of attack cannot be detected, intrinsically, by most authorized to do so, this sort of attack cannot be detected,
RPs. However, the entities affected by the revocation or replacement intrinsically, by most RPs. However, the entities affected by the
of CA certificates can be expected to detect the attack and contact revocation or replacement of CA certificates can be expected to
the CA to effect remediation. If the CA was not the adversary, it detect the attack and contact the CA to effect remediation. If the
should be able to issue new certificates and restore the publication CA was not the adversary, it should be able to issue new certificates
point. 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 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
skipping to change at page 18, line 29 skipping to change at page 18, line 37
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 prevent a compromised CA from issuing (valid) certificates extensions prevent a compromised CA from issuing (valid) certificates
with INRs outside the scope of the CA, thus limiting the impact of with INRs outside the scope of the CA, thus limiting the 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 (an example of Walt Kelly's most
example, a CA might fail to replace its own certificate in a timely famous "Pogo" quote [Kelly70]). For example, a CA might fail to
fashion (well before it expires). If might fail to issue its CRL and replace its own certificate in a timely fashion (well before it
manifest prior to expiration, creating stale instances of these expires). If might fail to issue its CRL and manifest prior to
products that cause concern for RPs. A CA with many subordinate CAs expiration, creating stale instances of these products that cause
(e.g., an RIR or NIR) might fail to distribute the expiration times concern for RPs. A CA with many subordinate CAs (e.g., an RIR or
for the CA certificates that it issues. A network with many ROAs NIR) might fail to distribute the expiration times for the CA
might do the same for the EE certificates associated with the ROAs it certificates that it issues. A network with many ROAs might do the
generates. A CA could rollover its key, but fail to reissue same for the EE certificates associated with the ROAs it generates.
subordinate CA certificates under its new key. Poor planning with A CA could rollover its key, but fail to reissue subordinate CA
regard to rekey intervals for managed CAs could impose undue burdens certificates under its new key. Poor planning with regard to rekey
for RPs, despite a lack of malicious intent. All of these example of intervals for managed CAs could impose undue burdens for RPs, despite
mismanagement could adversely affect RPs, despite the absence of a lack of malicious intent. All of these example of mismanagement
malicious intent. could adversely affect RPs, despite the absence of malicious intent.
5. Residual Vulnerabilities 5. Residual Vulnerabilities
The RPKI, upon which BGPSEC 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
(Section 4.4 and Section 4.5). These vulnerabilities are of two (Section 4.4 and Section 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 repository contents are deleted (maliciously).
skipping to change at page 19, line 33 skipping to change at page 19, line 33
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 data
subjects the RP to attacks that take advantage of the RP's subjects the RP to attacks that take advantage of the RP's
ignorance of changes to this data. 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 info associated with the real
world INRs to which the objects refer. This is equivalent to world INRs to which the objects refer. This is equivalent to
the affected INRs not having been afforded protection via the the affected INRs not having been afforded protection via the
RPKI. Since use of the RPKI (and BGPSEC) is voluntary, there RPKI. Since use of the RPKI (and PATHSEC) is voluntary, there
may always be set of INRs that are not protected by these may always be set of INRs that are not protected by these
mechanisms. Thus purging moves the affected INRs to the set mechanisms. Thus purging moves the affected INRs to the set
of non-participating INR holders. This more conservative of non-participating INR holders. This more conservative
response enables an attacker to move INRs from the protected response enables an attacker to move INRs from the protected
to the unprotected 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 or RFC 3779 extensions. It is in the RPKI because of the use of RFC 3779 extensions. 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.
BGPSEC has a separate set of residual vulnerabilities: PATHSEC has a separate set of residual vulnerabilities:
o "Route leaks" are viewed as a routing security problem by many o "Route leaks" are viewed as a routing security problem by many
network operators, even though there is no IETF-codified operators, even though there is no IETF-codified definition of a
definition of a route leak. BGP itself does not include semantics route leak. BGP itself does not include semantics that preclude
that preclude what many perceive as route leaks. Moreover, route what many perceive as route leaks. Moreover, route leaks are
leaks are outside the scope of BGPSEC, at this time, based on the outside the scope of PATHSEC, at this time, based on the SIDR
SIDR charter. Thus route leaks are not addressed in this threat charter. Thus route leaks are not addressed in this threat model.
model.
o BGPSEC signatures do not protect all attributes associated with an o PATHSEC is not planned to protect all attributes associated with
AS_path. Some of these attributes are employed as inputs to an AS_PATH. Some of these attributes are employed as inputs to
routing decisions. Thus attacks that modify (or strip) these routing decisions. Thus attacks that modify (or strip) these
other attributes are not detected by BGPSEC. The SIDR charter other attributes are not prevented/detected by PATHSEC. The SIDR
calls for protecting only the info needed to verify that a charter calls for protecting only the info needed to verify that a
received route traversed the ASes on question, and that the NLRI received route traversed the ASes in question, and that the NLRI
in the route is what was advertised. Thus, protection of other in the route is what was advertised. Thus, protection of other
attributes is outside the scope of the charter, at the time this attributes is outside the scope of the charter, at the time this
document was prepared. document was prepared.
o BGPSEC 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.
BGPSEC 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 purport to address security problems. This
model postulates a set of threats (i.e., motivated, capable 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
BGPSEC, including on the RPKI on which BGPSEC relies. It describes PATHSEC, including on the RPKI on which PATHSEC relies. It describes
how the design of the RPKI (and the current BGPSEC design) 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. 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. Informative References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-sidr-rpki-rtr]
Requirement Levels", BCP 14, RFC 2119, March 1997. Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ietf-sidr-rpki-rtr-26 (work in progress),
February 2012.
9.2. Informative References [Kelly70] Kelly, W., "'We Have Met the Enemy, and He is Us': Pogo
Earth 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
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006. RFC 4272, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
skipping to change at page 24, line 49 skipping to change at page 25, line 5
(RPKI)", RFC 6486, February 2012. (RPKI)", RFC 6486, February 2012.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
February 2012. February 2012.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, February 2012. (RPKI)", RFC 6488, February 2012.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, February 2012.
[Sam04] Samuel, A., "Hacktivism and the Future of Political
Participation", Ph.D. dissertation, Harvard University,
August 2004.
[TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
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 US
 End of changes. 74 change blocks. 
248 lines changed or deleted 276 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/