draft-ietf-sidr-bgpsec-threats-05.txt   draft-ietf-sidr-bgpsec-threats-06.txt 
Secure Inter-Domain Routing S. Kent Secure Inter-Domain Routing S. Kent
Internet-Draft A. Chi Internet-Draft BBN
Intended status: Informational BBN Intended status: Informational A. Chi
Expires: September 27, 2013 March 26, 2013 Expires: March 10, 2014 UNC-CH
September 06, 2013
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-05 draft-ietf-sidr-bgpsec-threats-06
Abstract Abstract
This document describes a threat model for the context in which BGP This document describes a threat model for the context in which
path security mechanisms will be developed. It assumes the context (E)BGP path security mechanisms will be developed. The threat model
established by the SIDR WG charter, as of April 19, 2011. The includes an analysis of the RPKI, and focuses on the ability of an AS
charter established two goals for the SIDR work: to verify the authenticity of the AS path info received in a BGP
update. We use the term PATHSEC to refer to any BGP path security
o Enabling an AS to verify the authorization of an origin AS to technology that makes use of the RPKI. PATHSEC will secure BGP
originate a specified set of prefixes [RFC4271], consistent with the inter-AS security focus of the RPKI
[RFC6480].
o Enabling an AS to verify that the AS-PATH [sic] represented in a
route matches the path traveled 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. 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 document characterizes classes of potential adversaries that are The document characterizes classes of potential adversaries that are
considered to be threats, and examines classes of attacks that might considered to be threats, and examines classes of attacks that might
be launched against PATHSEC. It does not revisit attacks against be launched against PATHSEC. It does not revisit attacks against
unprotected BGP, as that topic has already been addressed in unprotected BGP, as that topic has already been addressed in
[RFC4271]. 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
skipping to change at page 2, line 15 skipping to change at page 1, line 45
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 September 27, 2013. This Internet-Draft will expire on March 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 37 skipping to change at page 2, line 22
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6
4. Attack Characterization . . . . . . . . . . . . . . . . . . . 8 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 7
4.1. Active wiretapping of sessions between routers . . . . . 8 4.1. Active wiretapping of sessions between routers . . . . . 8
4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 9 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 8
4.3. Attacks on network operator management computers (non-CA 4.3. Attacks on network operator management computers (non-CA
computers) . . . . . . . . . . . . . . . . . . . . . . . 10 computers) . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Attacks on a repository publication point . . . . . . . . 12 4.4. Attacks on a repository publication point . . . . . . . . 11
4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 14 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 13
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document describes the security context in which PATHSEC is This document describes the security context in which PATHSEC is
intended to operate. 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 PATHSEC. Because PATHSEC will rely on the be launched against PATHSEC. Because PATHSEC will rely on the
Resource Public Key Infrastructure (RPKI) [RFC6480], threats and Resource Public Key Infrastructure (RPKI) [RFC6480], threats and
attacks 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
PATHSEC (based on the current PATHSEC design.) PATHSEC (based on the current PATHSEC design.)
The motivation for developing PATHSEC, i.e., residual security The motivation for developing PATHSEC, i.e., residual security
skipping to change at page 3, line 29 skipping to change at page 3, line 15
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 must be addressed by PATHSEC.) 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
[TCPMD5] and operational protections cannot exclude the bogus of [TCPMD5] and operational protections cannot exclude the bogus
information arising from a legitimate peer. The risk of information arising from a legitimate peer. The risk of
disruptions caused by legitimate BGP speakers is real and cannot disruptions caused by legitimate BGP speakers is real and cannot
be ignored. be ignored."
PATHSEC is intended to address the concerns cited above, to provide PATHSEC is intended to address the concerns cited above, to provide
significantly improved path security, building upon the route significantly improved path security, building upon the route
origination validation capability offered by use of the RPKI origination validation capability offered by use of the RPKI
[RFC6810]. Specifically, the RPKI enables relying parties (RPs) to [RFC6810]. Specifically, the RPKI enables relying parties (RPs) to
determine if the origin AS for a path was authorized to advertise the determine if the origin AS for a path was authorized to advertise the
prefix contained in a BGP update message. This security feature is prefix contained in a BGP update message. This security feature is
enabled by the use of two types of digitally signed data: a PKI enabled by the use of two types of digitally signed data: a PKI
[RFC6487] that associates one or more prefixes with the public key(s) [RFC6487] that associates one or more prefixes with the public key(s)
of an address space holder, and Route Origination Authorizations of an address space holder, and Route Origination Authorizations
skipping to change at page 7, line 7 skipping to change at page 6, line 31
exploited to violate the security policy of a system. exploited to violate the security policy of a system.
3. Threat Characterization 3. Threat Characterization
As noted in Section 2 above, a threat is defined as a motivated, As noted in Section 2 above, a threat is defined as a motivated,
capable, adversary. The following classes of threats represent capable, adversary. The following classes of threats represent
classes of adversaries viewed as relevant to this environment. classes of adversaries viewed as relevant to this environment.
Network Operators - A network operator may be a threat. An operator Network Operators - A network operator may be a threat. An operator
may be motivated to cause BGP routers it controls to emit update may be motivated to cause BGP routers it controls to emit update
messages with inaccurate routing info, e.g. to cause traffic to flow messages with inaccurate routing info, e.g., to cause traffic to flow
via paths that are economically advantageous for the operator. Such via paths that are economically advantageous for the operator. Such
updates might cause traffic to flow via paths that would otherwise be updates might cause traffic to flow via paths that would otherwise be
rejected as less advantageous by other network operators. Because an rejected as less advantageous by other network operators. Because an
operator controls the BGP routers in its network, it is in a position operator controls the BGP routers in its network, it is in a position
to modify their operation in arbitrary ways. Routers managed by a to modify their operation in arbitrary ways. Routers managed by a
network operator are vehicles for mounting MITM attacks on both network operator are vehicles for mounting MITM attacks on both
control and data plane traffic. If an operator participates in the control and data plane traffic. If an operator participates in the
RPKI, it will have at least one CA resource certificate and may be RPKI, it will have at least one CA resource certificate and may be
able to generate an arbitrary number of subordinate CA certificates able to generate an arbitrary number of subordinate CA certificates
and ROAs. It will be authorized to populate (and may even host) its and ROAs. It will be authorized to populate (and may even host) its
skipping to change at page 8, line 48 skipping to change at page 8, line 17
violate the implied confidentiality of routing traffic, e.g., passive violate the implied confidentiality of routing traffic, e.g., passive
wiretapping attacks, are not considered a requirement for BGP wiretapping attacks, are not considered a requirement for BGP
security (see [RFC4272]). security (see [RFC4272]).
4.1. Active wiretapping of sessions between routers 4.1. Active wiretapping of sessions between routers
An adversary may attack the BGP (TCP) session that connects a pair of An adversary may attack the BGP (TCP) session that connects a pair of
BGP speakers. An active attack against a BGP (TCP) session can be BGP speakers. An active attack against a BGP (TCP) session can be
effected by directing traffic to a BGP speaker from some remote effected by directing traffic to a BGP speaker from some remote
point, or by being positioned as a MITM on the link that carries BGP point, or by being positioned as a MITM on the link that carries BGP
session traffic. Remote attacks can be effected by any adversary. session traffic. Remote attacks can be effected by any adversary. A
However, a MITM attack requires access to the link, and only a few MITM attack requires access to the link. Modern transport networks
classes of adversaries are assumed to be capable of MITM attacks may be as complex as the packet networks that utilize them for inter-
against a BGP session. MITM attacks may be directed against BGP, AS links. Thus these transport networks may present significant
PATHSEC-protected BGP, or against TCP or IP. Such attacks include attack surfaces. Nonetheless, only some classes of adversaries are
replay of selected BGP messages, selective modification of BGP assumed to be capable of MITM attacks against a BGP session. MITM
messages, and DoS attacks against BGP routers. [RFC4272] describes attacks may be directed against BGP, PATHSEC-protected BGP, or
several countermeasures for such attacks, and thus this document does against TCP or IP. Such attacks include replay of selected BGP
not further address such attacks. 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 PATHSEC An adversary may attack a BGP router, whether it implements PATHSEC
or not. Any adversary that controls routers legitimately, or that or not. Any adversary that controls routers legitimately, or that
can assume control of a router, is assumed to be able to effect the can assume control of a router, is assumed to be able to effect the
types of attacks described below. Note that any router behavior that types of attacks described below. Note that any router behavior that
can be ascribed to a local routing policy decision is not considered can be ascribed to a local routing policy decision is not considered
to be an attack. This is because such behavior could be explained as to be an attack. This is because such behavior could be explained as
a result of local policy settings, and thus is beyond the scope of a result of local policy settings, and thus is beyond the scope of
skipping to change at page 14, line 24 skipping to change at page 13, line 46
discussion does not distinguish such outsourced CA operations.) discussion does not distinguish such outsourced CA operations.)
Note that attacks attributable to a CA may be the result of malice by Note that attacks attributable to a CA may be the result of malice by
the CA (i.e., the CA is the adversary) or they may result from a the CA (i.e., the CA is the adversary) or they may result from a
compromise of the CA. compromise of the CA.
All of adversaries listed in Section 2 are presumed to be capable of All of 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. between CA as adversary vs. CA as an attack victim is important.
Only in the latter case should one expect the CA to remedy problems Only in the latter case should one expect the CA to remedy problems
caused by a attack once the attack has been detected. (If a CA does caused by a attack once the attack has been detected. (If a CA does
not take such action, the effects are the same as if the CA is an not take such action, the effects are the same as if the CA is an
adversary.) adversary.)
Note that most of the attacks described below do not require Note that most of the attacks described below do not require
disclosure of a CA's private key to an adversary. If the adversary disclosure of a CA's private key to an adversary. If the adversary
can gain control of the computer used to issue certificates, it can can gain control of the computer used to issue certificates, it can
effect these attacks, even though the private key for the CA remains effect these attacks, even though the private key for the CA remains
"secure" (i.e., not disclosed to unauthorized parties). However, if "secure" (i.e., not disclosed to unauthorized parties). However, if
the CA is not the adversary, and if the CA's private key is not the CA is not the adversary, and if the CA's private key is not
compromised, then recovery from these attacks is much easier. This compromised, then recovery from these attacks is much easier. This
motivates use of hardware security modules to protect CA keys, at motivates use of hardware security modules to protect CA keys, at
least for higher tiers in the RPKI. least for higher tiers in the RPKI.
skipping to change at page 18, line 30 skipping to change at page 18, line 7
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... TBD
9. Informative References 9. Informative References
[Kelly70] Kelly, W., "'We Have Met the Enemy, and He is Us': Pogo [Kelly70] Kelly, W., "'We Have Met the Enemy, and He is Us': Pogo
Earth Day Poster", April 1970. 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.
skipping to change at page 20, line 4 skipping to change at page 19, line 25
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
Email: kent@bbn.com Email: kent@bbn.com
Andrew Chi Andrew Chi
BBN Technologies University of North Carolina - Chapel Hill
10 Moulton St. c/o Department of Computer Science
Cambridge, MA 02138 CB 3175, Sitterson Hall
Chapel Hill, NC 27599
US US
Email: achi@bbn.com Email: achi@cs.unc.edu
 End of changes. 20 change blocks. 
55 lines changed or deleted 45 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/