draft-ietf-sidr-bgpsec-threats-08.txt   draft-ietf-sidr-bgpsec-threats-09.txt 
Secure Inter-Domain Routing S. Kent Secure Inter-Domain Routing S. Kent
Internet-Draft BBN Internet-Draft BBN
Intended status: Informational A. Chi Intended status: Informational A. Chi
Expires: May 26, 2014 UNC-CH Expires: June 14, 2014 UNC-CH
November 22, 2013 December 11, 2013
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-08 draft-ietf-sidr-bgpsec-threats-09
Abstract Abstract
This document describes a threat model for the context in which This document describes a threat model for the context in which
Exterior Border Gateway Protocol (EBGP) path security mechanisms will Exterior Border Gateway Protocol (EBGP) path security mechanisms will
be developed. The threat model includes an analysis of the Resource be developed. The threat model includes an analysis of the Resource
Public Key Infrastructure (RPKI), and focuses on the ability of an Public Key Infrastructure (RPKI), and focuses on the ability of an
autonomous system (AS) to verify the authenticity of the AS path info autonomous system (AS) to verify the authenticity of the AS path info
received in a BGP update. We use the term PATHSEC to refer to any received in a BGP update. We use the term PATHSEC to refer to any
BGP path security technology that makes use of the RPKI. PATHSEC BGP path security technology that makes use of the RPKI. PATHSEC
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 May 26, 2014. This Internet-Draft will expire on June 14, 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6
4. Attack Characterization . . . . . . . . . . . . . . . . . . . 8 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 8
4.1. Active wiretapping of sessions between routers . . . . . 8 4.1. Active wiretapping of sessions between routers . . . . . 8
4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 8 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 9
4.3. Attacks on network operator management computers (non-CA 4.3. Attacks on network operator management computers (non-CA
computers) . . . . . . . . . . . . . . . . . . . . . . . 10 computers) . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Attacks on a repository publication point . . . . . . . . 11 4.4. Attacks on a repository publication point . . . . . . . . 12
4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 13 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 14
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document describes the security context in which PATHSEC is This document describes the security context in which PATHSEC is
intended to operate. The term "PATHSEC" (for path security) refers intended to operate. The term "PATHSEC" (for path security) refers
to any design used to preserve the integrity and authenticity of the to any design used to preserve the integrity and authenticity of the
AS_PATH attribute carried in a BGP update message [RFC4271]. The AS_PATH attribute carried in a BGP update message [RFC4271]. The
goal of PATHSEC is to enable a BGP speaker to verify that the security context used throughout this document is established by the
Autonomous Systems (ASes) enumerated in this path attribute represent SIDR charter [SIDR-CH]. The charter requires that solutions that
the sequence of ASes that the Network Layer Reachability Information afford PATHSEC make use of the Resource Public Key Infrastructure
(NLRI) traversed. The term PATHSEC is thus consistent with the goal (RPKI) [RFC6480]. It also calls for protecting only the information
described in the SIDR WG charter. (Other SIDR documents use the term required to verify that a received route traversed the Autonomous
Systems (ASes) in question, and that the Network Layer Reachability
Information (NLRI) in the route is what was advertised.
Thus the goal of PATHSEC is to enable a BGP speaker to verify that
the ASes enumerated in this path attribute represent the sequence of
ASes that the NLRI traversed. The term PATHSEC is thus consistent
with the goal described above. (Other SIDR documents use the term
"BGPSEC" to refer to a specific design, thus we avoid use of that "BGPSEC" to refer to a specific design, thus we avoid use of that
term here.) term here.)
This document discusses classes of potential adversaries that are This document discusses classes of potential adversaries that are
considered to be threats, and classes of attacks that might be considered to be threats, and classes of attacks that might be
launched against PATHSEC. The SIDR charter requires that solutions launched against PATHSEC. Because PATHSEC will rely on the RPKI,
that afford PATHSEC must make use of the Resource Public Key threats and attacks against the RPKI are included. This model also
Infrastructure (RPKI) [RFC6480]. Because PATHSEC will rely on the takes into consideration classes of attacks that are enabled by the
RPKI, threats and attacks against the RPKI are included. This model use of PATHSEC (e.g., based on use of the RPKI).
also takes into consideration classes of attacks that are enabled by
the use of PATHSEC (e.g., based on use of the RPKI).
The motivation for developing PATHSEC, i.e., residual security The motivation for developing PATHSEC, i.e., residual security
concerns for BGP, is well described in several documents, including concerns for BGP, is well described in several documents, including
"BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and
Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000]. Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000].
All of these documents note that BGP does not include mechanisms that All of these documents note that BGP does not include mechanisms that
allow an Autonomous System (AS) to verify the legitimacy and allow an 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
skipping to change at page 17, line 17 skipping to change at page 17, line 28
anticipated that RPs will deal with such misbehavior through anticipated that RPs will deal with such misbehavior through
administrative means, once it is detected. administrative means, once it is detected.
PATHSEC has a separate set of residual vulnerabilities: PATHSEC has a separate set of residual vulnerabilities:
o It has been stated that "route leaks" are viewed as a routing o It has been stated that "route leaks" are viewed as a routing
security problem by many operators. However, BGP itself does not security problem by many operators. However, BGP itself does not
include semantics that preclude what many perceive as route leaks, include semantics that preclude what many perceive as route leaks,
and there is no definition of the term in any RFC. This makes it and there is no definition of the term in any RFC. This makes it
inappropriate to address route leaks in this document. inappropriate to address route leaks in this document.
Additionally, route leaks are outside the scope of PATHSEC, based Additionally, route leaks are outside the scope of PATHSEC,
on the SIDR charter. That charter focuses on the integrity and consistent with the security context noted in Section 1 of this
authenticity of the data contained in the AS_path. If, at a later document. If, at a later time, the SIDR security context is
time, the SIDR charter is amended to include route leaks, and an revised to include route leaks, and an appropriate definition
appropriate definition exists, this document should be revised. exists, this document should be revised.
o PATHSEC is not required to protect all attributes associated with o PATHSEC is not required to protect all attributes associated with
an AS_PATH, even though some of these attributes may be employed an AS_PATH, even though some of these attributes may be employed
as inputs to routing decisions. Thus attacks that modify (or as inputs to routing decisions. Thus attacks that modify (or
strip) these other attributes are not prevented/detected by strip) these other attributes are not prevented/detected by
PATHSEC. The SIDR charter calls for protecting only the info PATHSEC. As noted in Section 1, the SIDR security context calls
needed to verify that a received route traversed the ASes in for protecting only the info needed to verify that a received
question, and that the NLRI in the route is what was advertised. route traversed the ASes in question, and that the NLRI in the
(The AS_PATH data also may have traversed ASes within a route is what was advertised. (The AS_PATH data also may have
confederation that are not represented. However, these ASes are traversed ASes within a confederation that are not represented.
not externally visible, and thus do not influence route selection, However, these ASes are not externally visible, and thus do not
so their omission in this context is not a security concern.) influence route selection, so their omission in this context is
Thus, protection of other attributes is outside the scope of the not a security concern.) Thus, protection of other attributes is
charter, at the time this document was prepared. If, at a later outside the scope of this document, as described in Section 1.
time, the SIDR charter is amended to include protection of If, at a later time, the SIDR security context is revised to
additional BGP attributes, this document should be revised. 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.
skipping to change at page 19, line 27 skipping to change at page 19, line 40
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.
[SIDR-CH] "Secure Inter-Domain Routing: Charter for Working Group",
September 2013, <http://tools.ietf.org/wg/sidr/
charters?item=charter-sidr-2013-09-20.txt>.
[Sam04] Samuel, A., "Hacktivism and the Future of Political [Sam04] Samuel, A., "Hacktivism and the Future of Political
Participation", Ph.D. dissertation, Harvard University, Participation", Ph.D. dissertation, Harvard University,
August 2004. August 2004.
Authors' Addresses Authors' Addresses
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
 End of changes. 12 change blocks. 
36 lines changed or deleted 46 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/