< draft-ietf-sidr-bgpsec-overview-05.txt		draft-ietf-sidr-bgpsec-overview-06.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: January 4, 2015 IECA		Expires: July 15, 2015 IECA
	July 4, 2014		January 15, 2015
	An Overview of BGPSEC		An Overview of BGPsec
	draft-ietf-sidr-bgpsec-overview-05		draft-ietf-sidr-bgpsec-overview-06
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	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 November 8, 2012.		This Internet-Draft will expire on July 15, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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........................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............................................8		6. IANA Considerations............................................8
	7. References.....................................................9		7. References.....................................................9
	7.1. Normative References......................................9		7.1. Normative References......................................9
	7.2. Informative References....................................9		7.2. Informative References....................................9
	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 [RFC 4271]. 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:
	. [I-D.sidr-bgpsec-threats]:		. [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.
	. [I-D.sidr-bgpsec-reqs]:		. [RFC7353]:
	A set of requirements for BGP path security, which BGPSEC is		A set of requirements for BGP path security, which BGPsec is
	intended to satisfy.		intended to satisfy.
	. [I-D.sidr-bgpsec-protocol]:		. [I-D.sidr-bgpsec-protocol]:
	A standards track document specifying the BGPSEC extension to		A standards track document specifying the BGPsec extension to
	BGP.		BGP.
			. [I-D.sidr-as-migration]:
			A standards track document describing how to implement an AS
			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.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 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.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.
	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, [RFC 4272]).
	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 [I-D.sidr-		AS authorized to originate that route (see [RFC6483] and [RFC7115]).
	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. 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 [I-
	D.sidr-bgpsec-threats] for a detailed discussion of the BGPSEC threat		D.sidr-bgpsec-threats] 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
	path data in 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 data 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. This attribute includes both AS Path data as well
	of digital signatures, one for each AS in the AS Path of a BGPSEC		as a sequence of digital signatures, one for each AS in the path.
	update message. (The use of this new attribute is formally specified		(The use of this new attribute is formally specified in [I-D.sidr-
	in [I-D.sidr-bgpsec-protocol].) A new signature is added to this		bgpsec-protocol].) A new signature is added to this sequence each
	sequence each time an update message leaves an AS. The signature is		time an update message leaves an AS. The signature is constructed so
	constructed so that any tampering with the AS path 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		[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
	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
	direction, for a given address family) then both BGPSEC update		If the use of BGPsec is negotiated in a BGP session (in a given
	messages (ones that contain the BGPSEC_Path_Signature attribute) and		direction, for a given address family) then both BGPsec update
			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 attribute from any update messages it sends to
	sends to this peer.		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 attribute containing a single signature. The signature
	signature protects the Network Layer Reachability Information (NLRI),		protects the Network Layer Reachability Information (NLRI), the AS
	the AS number of the originating AS, and the AS number of the peer AS		number of the originating AS, and the AS number of the peer AS to
	to whom the update message is being sent. Note that the NLRI in a		whom the update message is being sent. 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 attribute.
	attribute. This signature protects everything protected by the		This signature protects everything protected by the previous
	previous signature, plus the AS number of the new peer to whom the		signature, plus the AS number of the new peer to whom the update
	update message is being sent.		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 associated 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 data: 3 2 1
			. BGPsec_Path contains 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 AS path specified in the update		it received actually came via the AS path specified in the update
	message. Finally, the BGP speaker can check whether there exists a		message.
	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
	that the AS at the beginning of the validated path was authorized to
	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 do the following. First, it would look at the
	ROA authorizing AS 1 to originate advertisements for 192.0.2/24. It		SKI for the first signature and see if this corresponds to a valid
	would then look at the SKI for the first signature and see if this		BGPsec Router certificate for AS 1. Next, it would verify the first
	corresponds to a valid BGPSEC Router certificate for AS 1. Next, it		signature using the key found in this valid certificate. Finally, it
	would then verify the first signature using the key found in this		would repeat this process for the second and third signatures,
	valid certificate. Finally, it would repeat this process for the		checking to see that there are valid BGPsec router certificates for
	second and third signatures, checking to see that there are valid		AS 2 and AS 3 (respectively) and that the signatures can be verified
	BGPSEC router certificates for AS 2 and AS 3 (respectively) and that		with the keys found in these certificates. Note that the BGPsec
	the signatures can be verified with the keys found in these		speaker for AS 4 should additionally perform origin validation as per
	certificates.		RFC 6483 [RFC6483]. However, such origin validation is independent of
			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 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.
	4.2. BGPSEC router assumptions		4.2. BGPsec router assumptions
	In order to achieve its security goals, BGPSEC assumes additional		In order to achieve its security goals, BGPsec assumes additional
	capabilities in routers. In particular, BGPSEC involves adding		capabilities in routers. In particular, BGPsec involves adding
	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 large		routers to store (e.g., in ADJ RIBs) the data conveyed in these
	update messages. Additionally, the design of BGPSEC assumes that an		larger update messages. Additionally, the design of BGPsec assumes
	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 will likely require additional capability in these edge		verification may require additional capability in these edge 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
	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 larger 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
	autonomous system to have one peering session where it identifies		autonomous system to have one peering session where it identifies
	itself as AS 111 and a second peering session where it identifies		itself as AS 111 and a second peering session where it identifies
	itself as AS 222. In such a case, it might receive route		itself as AS 222. In such a case, it might receive route
	advertisements from the first peering session (as AS 111) and then		advertisements from the first peering session (as AS 111) and then
	add AS 222 (but not AS 111) to the AS-Path and propagate them within		add AS 222 (but not AS 111) to the AS-Path and propagate them within
	the second peering session.		the second peering session.
	Such behavior may very well be innocent and performed with the		Such behavior may very well be innocent and performed with the
	consent of the legitimate holder of both AS 111 and 222. However, it		consent of the legitimate holder of both AS 111 and 222. However, it
	is indistinguishable from the following man-in-the-middle attack		is indistinguishable from the following man-in-the-middle attack
	performed by a malicious AS 222. First, the malicious AS 222		performed by a malicious AS 222. First, the malicious AS 222
	impersonates AS 111 in the first peering session (essentially		impersonates AS 111 in the first peering session (essentially
	stealing a route advertisement intended for AS 111). The malicious AS		stealing a route advertisement intended for AS 111). The malicious AS
	222 then inserts itself into the AS path and propagates the update to		222 then inserts itself into the AS path and propagates the update to
	its peers.		its peers.
	Therefore, when BGPSEC is used, such an autonomous system would		Therefore, when BGPsec is used, such an autonomous system would
	either need to assert a consistent AS number in all external peering		either need to assert a consistent AS number in all external peering
	sessions, or else it would need to add both AS 111 and AS 222 to the		sessions, or else it would need to add both AS 111 and AS 222 to the
	AS-Path (along with appropriate signatures) for route advertisements		AS-Path (along with appropriate signatures) for route advertisements
	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.		the second peering session. See [I-D.sidr-as-migration] for a
			detailed discussion of how to reasonably manage AS number migrations
			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 [I-D.sidr-bgpsec-threats].
	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.
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 21 ¶
	[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.
	[I-D.sidr-origin-ops] Bush, R., "RPKI-Based Origin Validation		[RFC7132] Kent, S., and A. Chi, "Threat Model for BGP Path Security",
	Operation", draft-ietf-sidr-origin-ops, work-in-progress.		RFC 7132, February 2014.
	[I-D.sidr-bgpsec-threats] Kent, S., and A. Chi, "Threat Model for BGP		[RFC7115] Bush, R., "RPKI-Based Origin Validation Operation", RFC
	Path Security", draft-ietf-sidr-bgpsec-threats, work-in-progress.		7115, January 2014.
	[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.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, S., "A		[I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile
	Profile for BGPSEC Router Certificates, Certificate Revocation Lists,		for BGPsec Router Certificates, Certificate Revocation Lists, and
	and Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in-		Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in-
	progress.		progress.
			[I-D.sidr-as-migration] George, W. and S. Murphy, "BGPSec
			Considerations for AS Migration", draft-ietf-sidr-as-migration, work-
			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.
	[I-D.sidr-bgpsec-reqs] Bellovin, S., R. Bush, and D. Ward, "Security		[RFC7353] Bellovin, S., R. Bush, and D. Ward, "Security Requirements
	Requirements for BGP Path Validation", draft-ietf-sidr-bgpsec-reqs,		for BGP Path Validation", RFC 7353, August 2014.
	work-in-progress.
	Author's' 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.ietf@gmail.com		Email: mlepinski.ietf@gmail.com
End of changes. 74 change blocks.
	132 lines changed or deleted		141 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/