< draft-ietf-sidr-bgpsec-overview-01.txt		draft-ietf-sidr-bgpsec-overview-02.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: April 30, 2012 IECA		Expires: November 8, 2012 IECA
	October 31, 2011		May 8, 2012
	An Overview of BGPSEC		An Overview of BGPSEC
	draft-ietf-sidr-bgpsec-overview-01.txt		draft-ietf-sidr-bgpsec-overview-02.txt
	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 38 ¶		skipping to change at page 1, line 38 ¶
	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 April 30, 2012.		This Internet-Draft will expire on November 8, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 23 ¶
	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...........................7		4. Design and Deployment Considerations...........................7
	4.1. Disclosure of topology information........................7		4.1. Disclosure of topology information........................7
	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.........8
	5. Security Considerations........................................8		5. Security Considerations........................................8
	6. IANA Considerations............................................9		6. IANA Considerations............................................8
	7. References.....................................................9		7. References.....................................................9
	7.1. Normative References......................................9		7.1. Normative References......................................9
	7.2. Informative References...................................10		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].		routing [RFC 4271].
	A comprehensive discussion of BGPSEC is provided in the following set		A comprehensive discussion of BGPSEC is provided in the following set
	of documents:		of documents:
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	. [I-D.sidr-bgpsec-ops]:		. [I-D.sidr-bgpsec-ops]:
	An informational document describing operational considerations		An informational document describing operational considerations
	for BGPSEC deployment.		for BGPSEC deployment.
	. [I-D.turner-sidr-bgpsec-pki-profiles]		. [I-D.turner-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 Certificate Revocation Lists (CRLs),		numbers, as well as associated Certificate Revocation Lists
	certificate requests.		(CRLs), and certificate requests.
	. [I-D.turner-sidr-bgpsec-algs]		. [I-D.turner-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.
	. [I-D.sriram-bgpsec-design-choices]		. [I-D.sriram-bgpsec-design-choices]
	An informational document describing the choices that were made		An informational document describing the choices that were made
	by the author team prior to the publication of the -00 version		by the author team prior to the publication of the -00 version
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	The remainder of this document contains a brief overview of BGPSEC		The remainder of this document contains a brief overview of BGPSEC
	and its envisioned usage.		and its envisioned usage.
	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, [RFC 4272]).
	The Resource Public Key Infrastructure (RPKI), described in [I-		The Resource Public Key Infrastructure (RPKI), described in
	D.sidr-arch], provides a first step towards addressing the validation		[RFC6480], provides a first step towards addressing the validation of
	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 originated by an AS		to determine whether a received route was originated by an AS
	authorized to originate that route (see [I-D.sidr-roa-validation] and		authorized to originate that route (see [RFC6483] and [I-D.sidr-
	[I-D.sidr-origin-ops]).		origin-ops]).
	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. For example, if a BGP speaker accidently (due to		origination attacks. For example, if a BGP speaker accidently (due to
	misconfiguration) originates routes to the wrong prefixes, ASes		misconfiguration) originates routes to the wrong prefixes, ASes
	utilizing RPKI data could detect this error and decline to select		utilizing RPKI data could detect this error and decline to select
	these mis-originated routes. However, use of RPKI data alone provides		these mis-originated routes. However, use of RPKI data alone provides
	little or no protection against a sophisticated attacker. Such an		little or no protection against a sophisticated attacker. Such an
	attacker could, for example, conduct a route hijacking attack by		attacker could, for example, conduct a route hijacking attack by
	appending an authorized origin AS to an otherwise illegitimate AS		appending an authorized origin AS to an otherwise illegitimate AS
	Path. (See [I-D.kent-security-threats] for a detailed discussion of		Path. (See [I-D.sidr-bgpsec-threats] for a detailed discussion of the
	the BGPSEC threat model.)		BGPSEC threat 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 signatures to protect the AS Path		AS. The goal of BGPSEC is to use signatures to protect the AS Path
	attribute of BGP update messages so that a BGP speaker can assess the		attribute of BGP update messages so that a BGP speaker can assess the
	validity of the AS Path in update messages that it receives.		validity of the AS Path in update messages that it receives.
	3. BGPSEC Operation		3. BGPSEC Operation
	The core of BGPSEC is a new optional (non-transitive) attribute,		The core of BGPSEC is a new optional (non-transitive) attribute,
	called BGPSEC_Path_Signatures. This attribute consists of a sequence		called BGPSEC_Path_Signatures. This attribute consists of a sequence
	of digital signatures, one for each AS in the AS Path of a BGPSEC		of digital signatures, one for each AS in the AS Path of a BGPSEC
	update message. (The use of this new attribute is formally specified		update message. (The use of this new attribute is formally specified
	in [I-D.lepinski-bgpsec-protocol].) A new signature is added to this		in [I-D.sidr-bgpsec-protocol].) A new signature is added to this
	sequence each time an update message leaves an AS. The signature is		sequence each time an update message leaves an AS. The signature is
	constructed so that any tampering with the AS path or Network Layer		constructed so that any tampering with the AS path or Network Layer
	Reachability Information (NLRI) in the BGPSEC update message will		Reachability Information (NLRI) in the BGPSEC update message will
	result in the recipient being able to detect that the update is		result in the recipient being able to detect that the update is
	invalid.		invalid.
	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		[RFC 5492]. Upon opening a BGP session with a peer, BGP speakers who
	skipping to change at page 6, line 4 ¶		skipping to change at page 5, line 50 ¶
	by a recipient to select the public key (and selected router		by a recipient to select the public key (and selected router
	certificate data) needed for validation.		certificate data) needed for validation.
	As an example, consider the following case in which an advertisement		As an example, consider the following case in which an advertisement
	for 192.0.2/24 is originated by AS 1, which sends the route to AS 2,		for 192.0.2/24 is originated by AS 1, which sends the route to AS 2,
	which sends it to AS 3, which sends it to AS 4. When AS 4 receives a		which sends it to AS 3, which sends it to AS 4. When AS 4 receives a
	BGPSEC update message for this route, it will contain the following		BGPSEC update message for this route, it will contain the following
	data:		data:
	. NLRI : 192.0.2/24		. NLRI : 192.0.2/24
	. AS_Path : 3 2 1
			. AS_Path : 3 2 1
	. BGPSEC_Path_Signatures Attribute with 3 signatures :		. BGPSEC_Path_Signatures Attribute with 3 signatures :
	o Signature from AS 1 protecting		o Signature from AS 1 protecting
	192.0.2/24, AS 1 and AS 2		192.0.2/24, AS 1 and AS 2
	o Signature from AS 2 protecting		o Signature from AS 2 protecting
	Everything AS 1's signature protected, and AS 3		Everything AS 1's signature protected, and AS 3
	skipping to change at page 7, line 43 ¶		skipping to change at page 7, line 43 ¶
	routers.		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 [RFC4893]. 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
	were NOT 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
	update messages (thus obtaining protection for routes it originates)		update messages (thus obtaining protection for routes it originates)
	without receiving BGPSEC update messages. An AS that only sends, and		without receiving BGPSEC update messages. An AS that only sends, and
	does not receive, BGPSEC update messages will require much less		does not receive, BGPSEC update messages will require much less
	capability in its edge routers to deploy BGPSEC. In particular, a		capability in its edge routers to deploy BGPSEC. In particular, a
	router that only sends BGPSEC update messages does not need		router that only sends BGPSEC update messages does not need
	additional memory to store large updates and requires only minimal		additional memory to store large updates and requires only minimal
	cryptographic capability (as generating one signature per outgoing		cryptographic capability (as generating one signature per outgoing
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 18 ¶
	[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		[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
	Numbers", RFC 4893, May 2007.		Numbers", RFC 4893, May 2007.
	[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.
	[I-D.sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Support Secure Internet Routing", draft-ietf-sidr-arch, work-in-		Secure Internet Routing", February 2012.
	progress.
	[I-D.sidr-roa-validation] Huston, G., and G. Michaelson, "Validation		[RFC6483] Huston, G., and G. Michaelson, "Validation of Route
	of Route Origination using the Resource Certificate PKI and ROAs",		Origination using the Resource Certificate PKI and ROAs", February
	draft-ietf-sidr-roa-validation, work-in-progress.		2012.
	[I-D.sidr-origin-ops] Bush, R., "RPKI-Based Origin Validation		[I-D.sidr-origin-ops] Bush, R., "RPKI-Based Origin Validation
	Operation", draft-ietf-sidr-origin-ops, work-in-progress.		Operation", draft-ietf-sidr-origin-ops, work-in-progress.
	[I-D.sidr-bgpsec-threats] Kent, S., "Threat Model for BGP Path		[I-D.sidr-bgpsec-threats] Kent, S., "Threat Model for BGP Path
	Security", draft-ietf-sidr-bgpsec-threats, work-in-progress.		Security", draft-ietf-sidr-bgpsec-threats, work-in-progress.
	[I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol		[I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol
	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.turner-sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key		[I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, &
	Formats, & Signature Formats", draft-turner-sidr-bgpsec-algs, work-		Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress.
	in-progress.
	[I-D.turner-sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, S.,		[I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, S., "A
	"A Profile for BGPSEC Router Certificates, Certificate Revocation		Profile for BGPSEC Router Certificates, Certificate Revocation Lists,
	Lists, and Certification Requests", draft-turner-sidr-bgpsec-pki-		and Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in-
	profiles, work-in-progress.		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.
	Authors' Addresses		Author's' Addresses
	Matt Lepinski		Matt Lepinski
	BBN Technologies		BBN Technologies
	10 Moulton Street		10 Moulton Street
	Cambridge MA 02138		Cambridge MA 02138
	Email: mlepinski@bbn.com		Email: mlepinski@bbn.com
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
End of changes. 18 change blocks.
	32 lines changed or deleted		31 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/