draft-ietf-sidr-bgpsec-threats-06.txt   draft-ietf-sidr-bgpsec-threats-07.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: March 10, 2014 UNC-CH Expires: April 11, 2014 UNC-CH
September 06, 2013 October 08, 2013
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-06 draft-ietf-sidr-bgpsec-threats-07
Abstract Abstract
This document describes a threat model for the context in which This document describes a threat model for the context in which
(E)BGP path security mechanisms will be developed. The threat model (E)BGP path security mechanisms will be developed. The threat model
includes an analysis of the RPKI, and focuses on the ability of an AS 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 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 update. We use the term PATHSEC to refer to any BGP path security
technology that makes use of the RPKI. PATHSEC will secure BGP technology that makes use of the RPKI. PATHSEC will secure BGP
[RFC4271], consistent with the inter-AS security focus of the RPKI [RFC4271], consistent with the inter-AS security focus of the RPKI
skipping to change at page 1, line 45 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 March 10, 2014. This Internet-Draft will expire on April 11, 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 29 skipping to change at page 2, line 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6
4. Attack Characterization . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . 11 4.4. Attacks on a repository publication point . . . . . . . . 11
4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 13 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 13
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 15 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
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. (The term "PATHSEC" is employed in this
that are considered to be threats, and classes of attacks that might document to refer to any design used to achieve the path security
be launched against PATHSEC. Because PATHSEC will rely on the goal described in the SIDR WG charter. The charter focuses on
Resource Public Key Infrastructure (RPKI) [RFC6480], threats and mechanisms that will enable an AS to determine if the AS_PATH
attacks against the RPKI are included. This model also takes into represented in a route represents the path via which the Network
consideration classes of attacks that are enabled by the use of Layer Reachability Information traveled. Other SIDR documents use
PATHSEC (based on the current PATHSEC design.) the term "BGPSEC" to refer to a specific design.) It discusses
classes of potential adversaries that are considered to be threats,
and classes of attacks that might be launched against PATHSEC.
Because PATHSEC will rely on the Resource Public Key Infrastructure
(RPKI) [RFC6480], threats and attacks against the RPKI are included.
This model also takes into consideration classes of attacks that are
enabled by the use of 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
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
to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO
skipping to change at page 11, line 47 skipping to change at page 12, line 6
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 insider 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 [RFC6480][RFC6481]. Attacks
products, that insert products with "bad" signatures, that tamper that delete signed products, that insert products with "bad"
with object signatures, or that replace newer objects with older signatures, that tamper with object signatures, or that replace newer
(valid) ones, can be detected by RPs (with a few exceptions). RPs objects with older (valid) ones, can be detected by RPs (with a few
are expected to make use of local caches. If repository publication exceptions). RPs are expected to make use of local caches. If
points are unavailable or the retrieved data is corrupted, an RP can repository publication points are unavailable or the retrieved data
revert to using the cached data. This behavior helps insulate RPs is corrupted, an RP can revert to using the cached data. This
from the immediate effects of DoS attacks on publication points. behavior helps insulate RPs from the immediate effects of DoS attacks
on publication points.
Each RPKI data object has an associated date at which it expires, or Each RPKI data object has an associated date at which it expires, or
is considered stale. (Certificates expire, CRLs become stale.) When is considered stale. (Certificates expire, CRLs become stale.) When
an RP uses cached data it is a local decision how to deal with stale an RP uses cached data it is a local decision how to deal with stale
or expired data. It is common in PKIs to make use of stale or expired data. It is common in PKIs to make use of stale
certificate revocation status data, when fresher data is not certificate revocation status data, when fresher data is not
available. Use of expired certificates is less common, although not available. Use of expired certificates is less common, although not
unknown. Each RP will decide, locally, whether to continue to make unknown. Each RP will decide, locally, whether to continue to make
use of or ignore cached RPKI objects that are stale or expired. use of or ignore cached RPKI objects that are stale or expired.
If an adversary inserts an object into a publication point, and the If an adversary inserts an object into a publication point, and the
object has a "bad" signature, the object will not be accepted and object has a "bad" signature, the object will not be accepted and
used by RPs. used by RPs.
If an adversary modifies any signed product at a publication point, If an adversary modifies any signed product at a publication point,
the signature on the product will fail, 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. An RP can continue to use the
there is no CRL for the CA instance anyway.) An RP can continue to last valid instance of the deleted object (as a local policy option),
use the last valid instance of the deleted object (as a local policy 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
skipping to change at page 18, line 37 skipping to change at page 18, line 42
[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.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481,
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, February X.509 PKIX Resource Certificates", RFC 6487, February
2012. 2012.
 End of changes. 9 change blocks. 
26 lines changed or deleted 35 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/