< draft-ietf-sidr-bgpsec-overview-04.txt		draft-ietf-sidr-bgpsec-overview-05.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: June 16, 2014 IECA		Expires: January 4, 2015 IECA
	December 16, 2013		July 4, 2014
	An Overview of BGPSEC		An Overview of BGPSEC
	draft-ietf-sidr-bgpsec-overview-04.txt		draft-ietf-sidr-bgpsec-overview-05
	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 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	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 originated by an AS		to determine whether a received route was actually originated by an
	authorized to originate that route (see [RFC6483] and [I-D.sidr-		AS authorized to originate that route (see [RFC6483] and [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-
	utilizing RPKI data could detect this error and decline to select		origination attacks. However, use of RPKI data alone provides little
	these mis-originated routes. However, use of RPKI data alone provides		or no protection against a sophisticated attacker. Such an attacker
	little or no protection against a sophisticated attacker. Such an		could, for example, conduct a route hijacking attack by appending an
	attacker could, for example, conduct a route hijacking attack by		authorized origin AS to an otherwise illegitimate AS path. (See [I-
	appending an authorized origin AS to an otherwise illegitimate AS		D.sidr-bgpsec-threats] for a detailed discussion of the BGPSEC threat
	Path. (See [I-D.sidr-bgpsec-threats] for a detailed discussion of the		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 such signatures to protect the AS
	attribute of BGP update messages so that a BGP speaker can assess the		path data in 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.sidr-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 can be
	result in the recipient being able to detect that the update is		detected by the recipient of the message.
	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
	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
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 4 ¶
	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.
	If a BGPSEC-capable BGP speaker finds that its peer does not support		If a BGPSEC-capable BGP speaker finds that its peer does not support
	receiving BGPSEC update messages, then the BGP speaker must remove		receiving BGPSEC update messages, then the BGP speaker must remove
	existing BGPSEC_Path_Signatures attribute from any update messages it		existing BGPSEC_Path_Signatures attribute from any update messages it
	sends to this peer.		sends to this peer.
	3.2. Update signing and validation		3.2. Update signing and validation
	When a BGP speaker originates a BGPSEC update message, it creates a		When a BGP speaker originates a BGPSEC update message, it creates a
	BGPSEC_Path_Signatures attribute containing a single signature. The		BGPSEC_Path_Signatures attribute containing a single signature. The
	signature protects the Network Layer Reachability Information (NLRI),		signature protects the Network Layer Reachability Information (NLRI),
	the AS number of the originating AS, the AS number of the peer AS to		the AS number of the originating AS, and the AS number of the peer AS
	whom the update message is being sent, and a few other pieces of data		to whom the update message is being sent. Note that the NLRI in a
	necessary for security guarantees. Note that the NLRI in a BGPSEC		BGPSEC update message is restricted to contain only a single prefix.
	update message is restricted to contain only a single prefix.
	When a BGP speaker receives a BGPSEC update message and wishes to		When a BGP speaker receives a BGPSEC update message and wishes to
	propagate the route advertisement contained in the update to an		propagate the route advertisement contained in the update to an
	external peer, it adds a new signature to the BGPSEC_Path_Signatures		external peer, it adds a new signature to the BGPSEC_Path_Signatures
	attribute. This signature protects everything protected by the		attribute. This signature protects everything protected by the
	previous signature, plus the AS number of the new peer to whom the		previous signature, plus the AS number of the new peer to whom the
	update message is being sent.		update message is being sent.
	Each BGP speaker also adds a reference, called a Subject Key		Each BGP speaker also adds a reference, called a Subject Key
	Identifier (SKI), to its BGPSEC Router certificate. The SKI is used		Identifier (SKI), to its BGPSEC Router certificate. The SKI is used
	by a recipient to select the public key (and selected router		by a recipient to select the public key (and associated 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
	o Signature from AS 3 protecting		o Signature from AS 3 protecting
	Everything AS 2's signature protected, and AS 4		Everything AS 2's signature protected, and AS 4
	When a BGPSEC update message is received by a BGP speaker, the BGP		When a BGPSEC update message is received by a BGP speaker, the BGP
	speaker can validate the message as follows. For each signature, the		speaker can validate the message as follows. For each signature, the
	BGP speaker first needs to determine if there is a valid RPKI Router		BGP speaker first needs to determine if there is a valid RPKI Router
	certificate matching the SKI and containing the appropriate AS		certificate matching the SKI and containing the appropriate AS
	number. (This would typically be done by looking up the SKI in a		number. (This would typically be done by looking up the SKI in a
	cache of data extracted from valid RPKI objects. A cache allows		cache of data extracted from valid RPKI objects. A cache allows
	certificate validation to be handled via an asynchronous process,		certificate validation to be handled via an asynchronous process,
	which might execute on another device.)		which might execute on another device.)
	The BGP speaker then verifies the signature using the public key from		The BGP speaker then verifies the signature using the public key from
	this BGPSEC router certificate. If all the signatures can be verified		this BGPSEC router certificate. If all the signatures can be verified
	in this fashion, the BGP speaker is assured that the update message		in this fashion, the BGP speaker is assured that the update message
	it received actually came via the path specified in the AS_Path		it received actually came via the AS path specified in the update
	attribute. Finally, the BGP speaker can check whether there exists a		message. Finally, the BGP speaker can check whether there exists a
	valid ROA in the RPKI linking the origin AS to the prefix in the		valid ROA in the RPKI linking the origin AS to the prefix in the
	NLRI. If such a valid ROA exists the BGP speaker is further assured		NLRI. If such a valid ROA exists the BGP speaker is further assured
	that the AS at the beginning of the validated path was authorized to		that the AS at the beginning of the validated path was authorized to
	originate routes to the given prefix.		originate routes to the given prefix.
	In the above example, upon receiving the BGPSEC update message, a BGP		In the above example, upon receiving the BGPSEC update message, a BGP
	speaker for AS 4 would first check to make sure that there is a valid		speaker for AS 4 would first check to make sure that there is a valid
	ROA authorizing AS 1 to originate advertisements for 192.0.2/24. It		ROA authorizing AS 1 to originate advertisements for 192.0.2/24. It
	would then look at the SKI for the first signature and see if this		would then look at the SKI for the first signature and see if this
	corresponds to a valid BGPSEC Router certificate for AS 1. Next, it		corresponds to a valid BGPSEC Router certificate for AS 1. Next, it
	would then verify the first signature using the key found in this		would then verify the first signature using the key found in this
	valid certificate. Finally, it would repeat this process for the		valid certificate. Finally, it would repeat this process for the
	second and third signatures, checking to see that there are valid		second and third signatures, checking to see that there are valid
	BGPSEC router certificates for AS 2 and AS 3 (respectively) and that		BGPSEC router certificates for AS 2 and AS 3 (respectively) and that
	the signatures can be verified with the keys found in these		the signatures can be verified with the keys found in these
	certificates.		certificates.
	4. Design and Deployment Considerations		4. Design and Deployment Considerations
	In this section we briefly discuss several additional topics that		In this section we provide a brief overview of several additional topics that
	commonly arise in the discussion of BGPSEC.		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
	inferred from equivalent (non-BGPSEC) BGP update messages.		inferred from equivalent (non-BGPSEC) BGP update messages.
	skipping to change at page 7, line 39 ¶		skipping to change at page 7, line 36 ¶
	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
	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
	update requires less computation than verifying multiple signatures		update requires less computation than verifying multiple signatures
	on each incoming update message). See [I-D.sidr-bgpsec-ops] for		on each incoming update message). See [I-D.sidr-bgpsec-ops] for
	further discussion related to Edge ASes that do not provide transit.)		further discussion related to Edge ASes that do not provide transit.
	4.3. BGPSEC and consistency of externally visible data		4.3. BGPSEC and consistency of externally visible data
	Finally note that, by design, BGPSEC prevents parties that propagate		Finally note that, by design, BGPSEC prevents parties that propagate
	route advertisements from including inconsistent or erroneous		route advertisements from including inconsistent or erroneous
	information within the AS-Path (without detection). In particular,		information within the AS-Path (without detection). In particular,
	this means that any deployed scenarios in which a BGP speaker		this means that any deployed scenarios in which a BGP speaker
	constructs such an inconsistent or erroneous AS Path attribute will		constructs such an inconsistent or erroneous AS Path attribute will
	break when BGPSEC is used.		break when BGPSEC is used.
	For example, when BGPSEC is not used, it is possible for a single		For example, when BGPSEC is not used, it is possible for a single
End of changes. 17 change blocks.
	31 lines changed or deleted		29 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/