draft-ietf-sidr-bgpsec-threats-03.txt   draft-ietf-sidr-bgpsec-threats-04.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: March 18, 2013 September 14, 2012 Expires: July 21, 2013 January 17, 2013
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-03 draft-ietf-sidr-bgpsec-threats-04
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 2, line 13 skipping to change at page 2, line 13
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 18, 2013. This Internet-Draft will expire on July 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 4, line 48 skipping to change at page 4, line 48
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.
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
[I-D.ietf-sidr-rpki-rtr]. Specifically, the RPKI enables relying [RFC6810]. Specifically, the RPKI enables relying parties (RPs) to
parties (RPs) to determine if the origin AS for a path was authorized determine if the origin AS for a path was authorized to advertise the
to advertise the prefix contained in a BGP update message. This prefix contained in a BGP update message. This security feature is
security feature is enabled by the use of two types of digitally enabled by the use of two types of digitally signed data: a PKI
signed data: a PKI [RFC6487] that associates one or more prefixes [RFC6487] that associates one or more prefixes with the public key(s)
with the public key(s) of an address space holder, and Route of an address space holder, and Route Origination Authorizations
Origination Authorizations (ROAs) [RFC6482] that allows a prefix (ROAs) [RFC6482] that allows a prefix holder to specify the AS(es)
holder to specify the AS(es) that are authorized to originate routes that are authorized to originate routes for a prefix.
for a prefix.
The security model adopted for PATHSEC 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
skipping to change at page 19, line 50 skipping to change at page 19, line 50
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 of 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.
PATHSEC 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 It has been stated that "route leaks" are viewed as a routing
operators, even though there is no IETF-codified definition of a security problem by many operators. However, BGP itself does not
route leak. BGP itself does not include semantics that preclude include semantics that preclude what many perceive as route leaks,
what many perceive as route leaks. Moreover, route leaks are and there is no definition of the term in any RFC. This makes it
outside the scope of PATHSEC, at this time, based on the SIDR inappropriate to address route leaks in this document.
charter. Thus route leaks are not addressed in this threat model. Additionally, route leaks are outside the scope of PATHSEC, based
on the SIDR charter. That charter focuses on the integrity and
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
appropriate definition exists, this document should be revised.
o PATHSEC is not planned to protect all attributes associated with o PATHSEC is not planned to protect all attributes associated with
an 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 prevented/detected by PATHSEC. The SIDR other attributes are not prevented/detected by PATHSEC. The SIDR
charter 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 in 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.
skipping to change at page 24, line 7 skipping to change at page 24, line 7
[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. Informative References 9. Informative References
[I-D.ietf-sidr-rpki-rtr]
Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ietf-sidr-rpki-rtr-26 (work in progress),
February 2012.
[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.
[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.
skipping to change at page 25, line 8 skipping to change at page 24, line 51
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) [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
Infrastructure (RPKI) to Router Protocol", RFC 6810,
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 [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
 End of changes. 8 change blocks. 
24 lines changed or deleted 26 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/