< draft-ietf-sidr-bgpsec-overview-06.txt		draft-ietf-sidr-bgpsec-overview-07.txt >
	Network Working Group M. Lepinski		Network Working Group M. Lepinski
	Internet Draft BBN Technologies		Internet Draft BBN Technologies
	Intended status: Informational S. Turner		Intended status: Informational S. Turner
	Expires: July 15, 2015 IECA		Expires: December 17, 2015 IECA
	January 15, 2015		June 15, 2015
	An Overview of BGPsec		An Overview of BGPsec
	draft-ietf-sidr-bgpsec-overview-06		draft-ietf-sidr-bgpsec-overview-07
	Abstract		Abstract
	This document provides an overview of a security extension to the		This document provides an overview of a security extension to the
	Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec improves		Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec improves
	security for BGP routing.		security for BGP routing.
	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
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on July 15, 2015.		This Internet-Draft will expire on December 17, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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...................................................2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Background.....................................................3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. BGPsec Operation...............................................4		3. BGPsec Operation . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Negotiation of BGPsec.....................................4		3.1. Negotiation of BGPsec . . . . . . . . . . . . . . . . . . . 4
	3.2. Update signing and validation.............................5		3.2. Update signing and validation . . . . . . . . . . . . . . . 5
	4. Design and Deployment Considerations...........................6		4. Design and Deployment Considerations . . . . . . . . . . . . . 6
	4.1. Disclosure of topology information........................7		4.1. Disclosure of topology information . . . . . . . . . . . . 6
	4.2. BGPsec router assumptions.................................7		4.2. BGPsec router assumptions . . . . . . . . . . . . . . . . . 7
	4.3. BGPsec and consistency of externally visible data.........8		4.3. BGPsec and consistency of externally visible data . . . . . 7
	5. Security Considerations........................................8		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations............................................8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	7. References.....................................................9		7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References......................................9		7.2. Informative References . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References....................................9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	BGPsec (Border Gateway Protocol Security) is an extension to the		BGPsec (Border Gateway Protocol Security) is an extension to the
	Border Gateway Protocol (BGP) that provides improved security for BGP		Border Gateway Protocol (BGP) that provides improved security for BGP
	routing [RFC 4271]. This document contains a brief overview of BGPsec		routing [RFC4271]. This document contains a brief overview of BGPsec
	and its envisioned usage.		and its envisioned usage.
	A more detailed discussion of BGPsec is provided in the following set		A more detailed discussion of BGPsec is provided in the following set
	of documents:		of documents:
	. [RFC7132]:		. [RFC7132]:
	A threat model describing the security context in which BGPsec		A threat model describing the security context in which BGPsec
	is intended to operate.		is intended to operate.
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	. [I-D.sidr-as-migration]:		. [I-D.sidr-as-migration]:
	A standards track document describing how to implement an AS		A standards track document describing how to implement an AS
	Number migration while using BGPsec.		Number migration while using BGPsec.
	. [I-D.sidr-bgpsec-ops]:		. [I-D.sidr-bgpsec-ops]:
	An informational document describing operational considerations.		An informational document describing operational considerations.
	. [I-D.turner-sidr-bgpsec-pki-profiles]:		. [I-D.sidr-bgpsec-pki-profiles]:
	A standards track document specifying a profile for X.509		A standards track document specifying a profile for X.509
	certificates that bind keys used in BGPsec to Autonomous System		certificates that bind keys used in BGPsec to Autonomous System
	numbers, as well as associated Certificate Revocation Lists		numbers, as well as associated Certificate Revocation Lists
	(CRLs), and certificate requests.		(CRLs), and certificate requests.
	. [I-D.turner-sidr-bgpsec-algs]		. [I-D.sidr-bgpsec-algs]
	A standards track document specifying suites of signature and		A standards track document specifying suites of signature and
	digest algorithms for use in BGPsec.		digest algorithms for use in BGPsec.
	In addition to this document set, some readers might be interested in		In addition to this document set, some readers might be interested in
	[I-D.sriram-bgpsec-design-choices], an informational document		[I-D.sriram-bgpsec-design-choices], an informational document
	describing the choices that were made the by the author team prior to		describing the choices that were made the by the author team prior to
	the publication of the -00 version of draft-ietf-sidr-bgpsec-		the publication of the -00 version of draft-ietf-sidr-bgpsec-
	protocol. Discussion of design choices made since the publication of		protocol. Discussion of design choices made since the publication of
	the -00 can be found in the archives of the SIDR working group		the -00 can be found in the archives of the SIDR working group
	mailing list.		mailing list.
	2. Background		2. Background
	The motivation for developing BGPsec is that BGP does not include		The motivation for developing BGPsec is that BGP does not include
	mechanisms that allow an Autonomous System (AS) to verify the		mechanisms that allow an Autonomous System (AS) to verify the
	legitimacy and authenticity of BGP route advertisements (see for		legitimacy and authenticity of BGP route advertisements (see for
	example, [RFC 4272]).		example, [RFC4272]).
	The Resource Public Key Infrastructure (RPKI), described in		The Resource Public Key Infrastructure (RPKI), described in
	[RFC6480], provides a first step towards addressing the validation of		[RFC6480], provides a first step towards addressing the validation of
	BGP routing data. RPKI resource certificates are issued to the		BGP routing data. RPKI resource certificates are issued to the
	holders of AS number and IP address resources, providing a binding		holders of AS number and IP address resources, providing a binding
	between these resources and cryptographic keys that can be used to		between these resources and cryptographic keys that can be used to
	verify digital signatures. Additionally, the RPKI architecture		verify digital signatures. Additionally, the RPKI architecture
	specifies a digitally signed object, a Route Origination		specifies a digitally signed object, a Route Origination
	Authorization (ROA), that allows holders of IP address resources to		Authorization (ROA), that allows holders of IP address resources to
	authorize specific ASes to originate routes (in BGP) to these		authorize specific ASes to originate routes (in BGP) to these
	resources. Data extracted from valid ROAs can be used by BGP speakers		resources. Data extracted from valid ROAs can be used by BGP speakers
	to determine whether a received route was actually originated by an		to determine whether a received route was actually originated by an
	AS authorized to originate that route (see [RFC6483] and [RFC7115]).		AS authorized to originate that route (see [RFC6483] and [RFC7115]).
	By instituting a local policy that prefers routes with origins		By instituting a local policy that prefers routes with origins
	validated using RPKI data (versus routes to the same prefix that		validated using RPKI data (versus routes to the same prefix that
	cannot be so validated) an AS can protect itself from certain mis-		cannot be so validated) an AS can protect itself from certain mis-
	origination attacks. However, use of RPKI data alone provides little		origination attacks. However, use of RPKI data alone provides little
	or no protection against a sophisticated attacker. Such an attacker		or no protection against a sophisticated attacker. Such an attacker
	could, for example, conduct a route hijacking attack by appending an		could, for example, conduct a route hijacking attack by appending an
	authorized origin AS to an otherwise illegitimate AS path. (See [I-		authorized origin AS to an otherwise illegitimate AS path. (See
	D.sidr-bgpsec-threats] for a detailed discussion of the BGPsec threat		[RFC7132] for a detailed discussion of the BGPsec threat model.)
	model.)
	BGPsec extends the RPKI by adding an additional type of certificate,		BGPsec extends the RPKI by adding an additional type of certificate,
	referred to as a BGPsec router certificate, that binds an AS number		referred to as a BGPsec router certificate, that binds an AS number
	to a public signature verification key, the corresponding private key		to a public signature verification key, the corresponding private key
	of which is held by one or more BGP speakers within this AS. Private		of which is held by one or more BGP speakers within this AS. Private
	keys corresponding to public keys in such certificates can then be		keys corresponding to public keys in such certificates can then be
	used within BGPsec to enable BGP speakers to sign on behalf of their		used within BGPsec to enable BGP speakers to sign on behalf of their
	AS. The certificates thus allow a relying party to verify that a		AS. The certificates thus allow a relying party to verify that a
	BGPsec signature was produced by a BGP speaker belonging to a given		BGPsec signature was produced by a BGP speaker belonging to a given
	AS. The goal of BGPsec is to use such signatures to protect the AS		AS. The goal of BGPsec is to use such signatures to protect the AS
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 43 ¶
	(The use of this new attribute is formally specified in [I-D.sidr-		(The use of this new attribute is formally specified in [I-D.sidr-
	bgpsec-protocol].) A new signature is added to this sequence each		bgpsec-protocol].) A new signature is added to this sequence each
	time an update message leaves an AS. The signature is constructed so		time an update message leaves an AS. The signature is constructed so
	that any tampering with the AS path data or Network Layer		that any tampering with the AS path data or Network Layer
	Reachability Information (NLRI) in the BGPsec update message can be		Reachability Information (NLRI) in the BGPsec update message can be
	detected by the recipient of the message.		detected by the recipient of the message.
	3.1. Negotiation of BGPsec		3.1. Negotiation of BGPsec
	The use of BGPsec is negotiated using BGP capability advertisements		The use of BGPsec is negotiated using BGP capability advertisements
	[RFC 5492]. Upon opening a BGP session with a peer, BGP speakers who		[RFC5492]. Upon opening a BGP session with a peer, BGP speakers who
	support (and wish to use) BGPsec include a newly-defined capability		support (and wish to use) BGPsec include a newly-defined capability
	in the OPEN message.		in the OPEN message.
	The use of BGPsec is negotiated separately for each address family.		The use of BGPsec is negotiated separately for each address family.
	This means that a BGP speaker could, for example, elect to use BGPsec		This means that a BGP speaker could, for example, elect to use BGPsec
	for IPv6, but not for IPv4 (or vice versa). Additionally, the use of		for IPv6, but not for IPv4 (or vice versa). Additionally, the use of
	BGPsec is negotiated separately in the send and receive directions.		BGPsec is negotiated separately in the send and receive directions.
	This means that a BGP speaker could, for example, indicate support		This means that a BGP speaker could, for example, indicate support
	for sending BGPsec update messages but require that messages it		for sending BGPsec update messages but require that messages it
	receives be traditional (non-BGPsec) update message. (To see why such		receives be traditional (non-BGPsec) update message. (To see why such
	a feature might be useful, see Section 4.2.)		a feature might be useful, see Section 4.2.)
	If the use of BGPsec is negotiated in a BGP session (in a given		If the use of BGPsec is negotiated in a BGP session (in a given
	direction, for a given address family) then both BGPsec update		direction, for a given address family) then both BGPsec update
	messages (ones that contain the BGPsec_Path_Signature attribute) and		messages (ones that contain the BGPsec_Path_Signature attribute) and
	traditional BGP update messages (that do not contain this attribute)		traditional BGP update messages (that do not contain this attribute)
	can be sent within the session.		can be sent within the session.
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 44 ¶
	would repeat this process for the second and third signatures,		would repeat this process for the second and third signatures,
	checking to see that there are valid BGPsec router certificates for		checking to see that there are valid BGPsec router certificates for
	AS 2 and AS 3 (respectively) and that the signatures can be verified		AS 2 and AS 3 (respectively) and that the signatures can be verified
	with the keys found in these certificates. Note that the BGPsec		with the keys found in these certificates. Note that the BGPsec
	speaker for AS 4 should additionally perform origin validation as per		speaker for AS 4 should additionally perform origin validation as per
	RFC 6483 [RFC6483]. However, such origin validation is independent of		RFC 6483 [RFC6483]. However, such origin validation is independent of
	BGPsec.		BGPsec.
	4. Design and Deployment Considerations		4. Design and Deployment Considerations
	In this section we provide a brief overview of several additional topics that		In this section we provide a brief overview of several additional
	commonly arise in the discussion of BGPsec.		topics that commonly arise in the discussion of BGPsec.
	4.1. Disclosure of topology information		4.1. Disclosure of topology information
	A key requirement in the design of BGPsec was that BGPsec not		A key requirement in the design of BGPsec was that BGPsec not
	disclose any new information about BGP peering topology. Since many		disclose any new information about BGP peering topology. Since many
	ISPs feel peering topology data is proprietary, further disclosure of		ISPs feel peering topology data is proprietary, further disclosure of
	it would inhibit BGPsec adoption.		it would inhibit BGPsec adoption.
	In particular, the topology information that can be inferred from		In particular, the topology information that can be inferred from
	BGPsec update messages is exactly the same as that which can be		BGPsec update messages is exactly the same as that which can be
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 24 ¶
	digital signatures to BGP update messages, which will significantly		digital signatures to BGP update messages, which will significantly
	increase the size of these messages. Therefore, an AS that wishes to		increase the size of these messages. Therefore, an AS that wishes to
	receive BGPsec update messages will require additional memory in its		receive BGPsec update messages will require additional memory in its
	routers to store (e.g., in ADJ RIBs) the data conveyed in these		routers to store (e.g., in ADJ RIBs) the data conveyed in these
	larger update messages. Additionally, the design of BGPsec assumes		larger update messages. Additionally, the design of BGPsec assumes
	that an AS that elects to receive BGPsec update messages will do some		that an AS that elects to receive BGPsec update messages will do some
	cryptographic signature verification at its edge router. This		cryptographic signature verification at its edge router. This
	verification may require additional capability in these edge routers.		verification may require additional capability in these edge routers.
	Additionally, BGPsec requires that all BGPsec speakers will support		Additionally, BGPsec requires that all BGPsec speakers will support
	4-byte AS Numbers [RFC4893]. This is because the co-existence		4-byte AS Numbers [RFC6793]. This is because the co-existence
	strategy for 4-byte AS numbers and legacy 2-byte AS speakers that		strategy for 4-byte AS numbers and legacy 2-byte AS speakers that
	gives special meaning to AS 23456 is incompatible with the security		gives special meaning to AS 23456 is incompatible with the security
	the security properties that BGPsec seeks to provide.		the security properties that BGPsec seeks to provide.
	For this initial version of BGPsec, optimizations to minimize the		For this initial version of BGPsec, optimizations to minimize the
	size of BGPsec updates or the processing required in edge routers		size of BGPsec updates or the processing required in edge routers
	have not been considered. Such optimizations may be considered in the		have not been considered. Such optimizations may be considered in the
	future.		future.
	Note also that the design of BGPsec allows an AS to send BGPsec		Note also that the design of BGPsec allows an AS to send BGPsec
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 38 ¶
	that it receives from the first peering session and propagates within		that it receives from the first peering session and propagates within
	the second peering session. See [I-D.sidr-as-migration] for a		the second peering session. See [I-D.sidr-as-migration] for a
	detailed discussion of how to reasonably manage AS number migrations		detailed discussion of how to reasonably manage AS number migrations
	while using BGPsec.		while using BGPsec.
	5. Security Considerations		5. Security Considerations
	This document provides an overview of BPSEC; it does not define the		This document provides an overview of BPSEC; it does not define the
	BGPsec extension to BGP. The BGPsec extension is defined in [I-		BGPsec extension to BGP. The BGPsec extension is defined in [I-
	D.sidr-bgpsec-protocol]. The threat model for the BGPsec is		D.sidr-bgpsec-protocol]. The threat model for the BGPsec is
	described in [I-D.sidr-bgpsec-threats].		described in [RFC7132].
	6. IANA Considerations		6. IANA Considerations
	None.		None.
	7.1. Normative References		7.1. Normative References
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS		[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
	Numbers", RFC 4893, May 2007.		Numbers", RFC 6793, December 2012.
	[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement		[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
	with BGP-4", RFC 5492, February 2009.		with BGP-4", RFC 5492, February 2009.
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", February 2012.		Secure Internet Routing", February 2012.
	[RFC6483] Huston, G., and G. Michaelson, "Validation of Route		[RFC6483] Huston, G., and G. Michaelson, "Validation of Route
	Origination using the Resource Certificate PKI and ROAs", February		Origination using the Resource Certificate PKI and ROAs", February
	2012.		2012.
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 35 ¶
	Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress.		Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress.
	[I-D.sidr-bgpsec-ops] Bush, R., "BGPsec Operational Considerations",		[I-D.sidr-bgpsec-ops] Bush, R., "BGPsec Operational Considerations",
	draft-ietf-sidr-bgpsec-ops, work-in-progress.		draft-ietf-sidr-bgpsec-ops, work-in-progress.
	[I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, &		[I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, &
	Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress.		Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress.
	[I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile		[I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile
	for BGPsec Router Certificates, Certificate Revocation Lists, and		for BGPsec Router Certificates, Certificate Revocation Lists, and
	Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in-		Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles, work-
	progress.		in- progress.
	[I-D.sidr-as-migration] George, W. and S. Murphy, "BGPSec		[I-D.sidr-as-migration] George, W. and S. Murphy, "BGPSec
	Considerations for AS Migration", draft-ietf-sidr-as-migration, work-		Considerations for AS Migration", draft-ietf-sidr-as-migration, work-
	in-progress.		in-progress.
	7.2. Informative References		7.2. Informative References
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
	4272, January 2006		4272, January 2006
	[I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPsec Design Choices		[I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPsec Design Choices
	and Summary of Supporting Discussions", draft-sriram-bgpsec-design-		and Summary of Supporting Discussions", draft-sriram-bgpsec-design-
	choices, work-in-progress.		choices, work-in-progress.
	[RFC7353] Bellovin, S., R. Bush, and D. Ward, "Security Requirements		[RFC7353] Bellovin, S., R. Bush, and D. Ward, "Security Requirements
	for BGP Path Validation", RFC 7353, August 2014.		for BGP Path Validation", RFC 7353, August 2014.
	Author's' Addresses		Authors' Addresses
	Matt Lepinski		Matt Lepinski
	BBN Technologies		BBN Technologies
	10 Moulton Street		10 Moulton Street
	Cambridge MA 02138		Cambridge MA 02138
	Email: mlepinski.ietf@gmail.com		Email: mlepinski.ietf@gmail.com
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
End of changes. 17 change blocks.
	36 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/