draft-ietf-sidr-bgpsec-threats-04.txt   draft-ietf-sidr-bgpsec-threats-05.txt 
Secure Inter-Domain Routing S. Kent Secure Inter-Domain Routing S. Kent
Internet-Draft A. Chi Internet-Draft A. Chi
Intended status: Informational BBN Intended status: Informational BBN
Expires: July 21, 2013 January 17, 2013 Expires: September 27, 2013 March 26, 2013
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-04 draft-ietf-sidr-bgpsec-threats-05
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 BGP
path security mechanisms will be developed. It assumes the context path security mechanisms will be developed. It assumes the context
established by the SIDR WG charter, as of April 19, 2011. The established by the SIDR WG charter, as of April 19, 2011. The
charter established two goals for the SIDR 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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
security focus of the RPKI [RFC6480]. References to "BGP" in this security focus of the RPKI [RFC6480]. References to "BGP" in this
document are to be interpreted as references to EBGP. 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
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 July 21, 2013. This Internet-Draft will expire on September 27, 2013.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Threat Characterization . . . . . . . . . . . . . . . . . . . 9 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6
4. Attack Characterization . . . . . . . . . . . . . . . . . . . 11 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 8
4.1. Active wiretapping of sessions between routers . . . . . . 11 4.1. Active wiretapping of sessions between routers . . . . . 8
4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 11 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 9
4.3. Attacks on network operator management computers 4.3. Attacks on network operator management computers (non-CA
(non-CA computers) . . . . . . . . . . . . . . . . . . . . 13 computers) . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Attacks on a repository publication point . . . . . . . . 14 4.4. Attacks on a repository publication point . . . . . . . . 12
4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 16 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 14
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 19 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . . 24 9. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 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 4, line 40 skipping to change at page 3, line 37
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 [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
skipping to change at page 9, line 13 skipping to change at page 7, line 7
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 16, line 49 skipping to change at page 14, line 24
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
skipping to change at page 20, line 12 skipping to change at page 17, line 34
security problem by many operators. However, BGP itself does not security problem by many operators. However, BGP itself does not
include semantics that preclude what many perceive as route leaks, include semantics that preclude what many perceive as route leaks,
and there is no definition of the term in any RFC. This makes it and there is no definition of the term in any RFC. This makes it
inappropriate to address route leaks in this document. inappropriate to address route leaks in this document.
Additionally, route leaks are outside the scope of PATHSEC, based Additionally, route leaks are outside the scope of PATHSEC, based
on the SIDR charter. That charter focuses on the integrity and on the SIDR charter. That charter focuses on the integrity and
authenticity of the data contained in the AS_path. If, at a later authenticity of the data contained in the AS_path. If, at a later
time, the SIDR charter is amended to include route leaks, and an time, the SIDR charter is amended to include route leaks, and an
appropriate definition exists, this document should be revised. appropriate definition exists, this document should be revised.
o PATHSEC is not planned to protect all attributes associated with o PATHSEC is not required to protect all attributes associated with
an AS_PATH. Some of these attributes are employed as inputs to an AS_PATH, even though some of these attributes may be employed
routing decisions. Thus attacks that modify (or strip) these as inputs to routing decisions. Thus attacks that modify (or
other attributes are not prevented/detected by PATHSEC. The SIDR strip) these other attributes are not prevented/detected by
charter calls for protecting only the info needed to verify that a PATHSEC. The SIDR charter calls for protecting only the info
received route traversed the ASes in question, and that the NLRI needed to verify that a received route traversed the ASes in
in the route is what was advertised. Thus, protection of other question, and that the NLRI in the route is what was advertised.
attributes is outside the scope of the charter, at the time this (The AS_PATH data also may have traversed ASes within a
document was prepared. confederation that are not represented. However, these ASes are
not externally visible, and thus do not influence route selection,
so their omission in this context is not a security concern.)
Thus, protection of other attributes is outside the scope of the
charter, at the time this document was prepared. If, at a later
time, the SIDR charter is amended to include protection of
additional BGP attributes, this document should be revised.
o PATHSEC cannot ensure that an AS will withdraw a route when the AS o PATHSEC cannot ensure that an AS will withdraw a route when the AS
no longer has a route for a prefix, as noted in Section 4.2. no longer has a route for a prefix, as noted in Section 4.2.
PATHSEC may incorporate features to limit the lifetime of an PATHSEC may incorporate features to limit the lifetime of an
advertisement. Such lifetime limits provide an upper bound on the advertisement. Such lifetime limits provide an upper bound on the
time that the failure to withdraw a route will remain effective. time that the failure to withdraw a route will remain effective.
6. Security Considerations 6. Security Considerations
A threat model is, by definition, a security-centric document. A threat model is, by definition, a security-centric document.
Unlike a protocol description, a threat model does not create Unlike a protocol description, a threat model does not create
security problems nor purport to address security problems. This security problems nor 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
skipping to change at page 24, line 21 skipping to change at page 18, line 48
Kent, S., Lynn, C., and K. Seo, "Design and Analysis of Kent, S., Lynn, C., and K. Seo, "Design and Analysis of
the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX
Conference, June 2000. Conference, June 2000.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
RFC 4272, January 2006. 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
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012. Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(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
February 2012. 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) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, February 2012. Ghostbusters Record", RFC 6493, February 2012.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, Infrastructure (RPKI) to Router Protocol", RFC 6810,
January 2013. January 2013.
[Sam04] Samuel, A., "Hacktivism and the Future of Political [Sam04] Samuel, A., "Hacktivism and the Future of Political
Participation", Ph.D. dissertation, Harvard University, Participation", Ph.D. dissertation, Harvard University,
August 2004. August 2004.
[TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
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
Email: kent@bbn.com Email: kent@bbn.com
Andrew Chi Andrew Chi
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
US US
Email: achi@bbn.com Email: achi@bbn.com
 End of changes. 15 change blocks. 
41 lines changed or deleted 43 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/