< draft-murphy-bgp-vuln-01.txt		draft-murphy-bgp-vuln-02.txt >
	Network Working Group Sandra Murphy		Network Working Group Sandra Murphy
	INTERNET DRAFT NAI Labs		INTERNET DRAFT NAI Labs
	draft-murphy-bgp-vuln-01.txt October 2002		draft-murphy-bgp-vuln-02.txt March 2003
	BGP Security Vulnerabilities Analysis		BGP Security Vulnerabilities Analysis
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions of		This document is an Internet-Draft and is subject to all provisions of
	Section 10 of RFC2026.		Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	skipping to change at page 1, line 29 ¶		skipping to change at page 1, line 29 ¶
	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 material		time. It is inappropriate to use Internet- Drafts as reference material
	or to cite them other than as "work in progress."		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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
			Specification of Requirements
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC2119.
	Abstract		Abstract
	BGP, along with a host of other infrastructure protocols designed before		BGP, along with a host of other infrastructure protocols designed before
	the Internet environment became perilous, is designed with little		the Internet environment became perilous, was originally designed with
	consideration for protection of the information it carries. There are		little consideration for protection of the information it carries.
	no mechanisms in BGP to protect against attacks that modify, delete,		There are no mechanisms internal to the BGP protocol to protect against
	forge, or replay data, any of which has the potential to disrupt overall		attacks that modify, delete, forge, or replay data, any of which has the
	network routing behavior.		potential to disrupt overall network routing behavior.
	This internet draft discusses some of the security issues with BGP		This internet draft discusses some of the security issues with BGP
	routing data dissemination. A companion work, [5], discusses possible		routing data dissemination. This internet draft does not discuss
	security solutions and the costs of those solutions. This internet		security issues with forwarding of packets.
	draft does not discuss security issues with forwarding of packets.
	Table of Contents		Table of Contents
	Status of this Memo .............................................. 1		Status of this Memo .............................................. 1
			Specification of Requirements .................................... 1
	Abstract ......................................................... 1		Abstract ......................................................... 1
	1 Introduction .................................................... 3		1 Introduction .................................................... 4
	2 Vulnerabilities and Risks ....................................... 5		2 Attacks ......................................................... 6
	2.1 OPEN .......................................................... 5		3 Vulnerabilities and Risks ....................................... 7
	2.2 KEEPALIVE ..................................................... 6		3.1 Vulnerabilities in BGP messages ............................... 8
	2.3 NOTIFICATION .................................................. 6		3.1.1 Message Header .............................................. 8
	2.4 UPDATE ........................................................ 6		3.1.2 OPEN ........................................................ 8
	2.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 6		3.1.3 KEEPALIVE ................................................... 9
	2.4.2 Withdrawn Routes ............................................ 6		3.1.4 NOTIFICATION ................................................ 9
	2.4.3 Path Attributes ............................................. 7		3.1.5 UPDATE ...................................................... 10
	Attribute Flags, Attribute Type Codes, Attribute Length .......... 7		3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length ..... 10
	ORIGIN ........................................................... 7		3.1.5.2 Withdrawn Routes .......................................... 10
	AS_PATH .......................................................... 7		3.1.5.3 Path Attributes ........................................... 11
	Originating Routes ............................................... 8		Attribute Flags, Attribute Type Codes, Attribute Length .......... 11
	NEXT_HOP ......................................................... 9		ORIGIN ........................................................... 11
	MULTI_EXIT_DISC .................................................. 9		AS_PATH .......................................................... 11
	LOCAL_PREF ....................................................... 9		Originating Routes ............................................... 12
	ATOMIC_AGGREGATE ................................................. 9		NEXT_HOP ......................................................... 12
	AGGREGATOR ....................................................... 10		MULTI_EXIT_DISC .................................................. 13
	2.4.4 NLRI ........................................................ 10		LOCAL_PREF ....................................................... 13
	2.5 BGP Extensions ................................................ 10		ATOMIC_AGGREGATE ................................................. 13
	2.5.1 Communities ................................................. 10		AGGREGATOR ....................................................... 14
	2.5.2 Confederations .............................................. 11		3.1.5.4 NLRI ...................................................... 14
	3 Security Considerations ......................................... 11		3.2 Vulnerabilities through Other Protocols ....................... 14
	4 References ...................................................... 11		3.2.1 TCP messages ................................................ 14
	5 Author's Address ................................................ 12		3.2.1.1 TCP SYN ................................................... 14
			3.2.1.2 TCP SYN ACK ............................................... 15
			3.2.1.3 TCP ACK ................................................... 15
			3.2.1.4 TCP RST/FIN/FIN-ACK ....................................... 15
			3.2.2 Other supporting protocols .................................. 16
			3.2.2.1 Manual stop ............................................... 16
			3.2.2.2 Timer events .............................................. 16
			4 Security Considerations ......................................... 16
			4.1 Residual Risk ................................................. 16
			5 References ...................................................... 17
			6 Author's Address ................................................ 18
	1. Introduction		1. Introduction
	The inter-domain routing protocol BGP was created when the Internet		The inter-domain routing protocol BGP was created when the Internet
	environment had not yet reached the present contentious state.		environment had not yet reached the present contentious state.
	Consequently, the BGP protocol was not designed with protection against		Consequently, the BGP protocol was not designed with protection against
	deliberate or accidental errors causing disruptions of routing behavior.		deliberate or accidental errors causing disruptions of routing behavior.
	We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and		We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and
	on [2]. Readers are expected to be familiar with the BGP RFC and the		on [2]. Readers are expected to be familiar with the BGP RFC and the
	behavior of BGP. A companion work, [5], proposes several different		behavior of BGP.
	security solutions to protect these vulnerabilities and discuss the
	benefits derived from each solution and its cost.
	It is clear that the Internet is vulnerable to attack through its		It is clear that the Internet is vulnerable to attack through its
	routing protocols and BGP is no exception. Faulty, misconfigured or		routing protocols and BGP is no exception. Faulty, misconfigured or
	deliberately malicious sources can disrupt overall Internet behavior by		deliberately malicious sources can disrupt overall Internet behavior by
	injecting bogus routing information into the BGP distributed routing		injecting bogus routing information into the BGP distributed routing
	database (by modifying, forging, or replaying BGP packets). The same		database (by modifying, forging, or replaying BGP packets). The same
	methods can also be used to disrupt local and overall network behavior		methods can also be used to disrupt local and overall network behavior
	by breaking the distributed communication of information between BGP		by breaking the distributed communication of information between BGP
	peers. The sources of bogus information can be either outsiders or true		peers. The sources of bogus information can be either outsiders or true
	BGP peers.		BGP peers.
	Under the present BGP design, cryptographic authentication of the peer-		Cryptographic authentication of the peer-peer communication is not an
	peer communication is not mandated. As a TCP/IP protocol, BGP is		integral part of the BGP protocol. As a TCP/IP protocol, BGP is subject
	subject to all the TCP/IP attacks, like IP spoofing, session stealing,		to all the TCP/IP attacks, like IP spoofing, session stealing, etc. Any
	etc. Any outsider can inject believable BGP messages into the		outsider can inject believable BGP messages into the communication
	communication between BGP peers and thereby inject bogus routing		between BGP peers and thereby inject bogus routing information or break
	information or break the peer to peer connection. Any break in the peer		the peer to peer connection. Any break in the peer to peer
	to peer communication has a ripple effect on routing that can be wide		communication has a ripple effect on routing that can be wide spread.
	spread. Furthermore, outsider sources can also disrupt communications		Furthermore, outsider sources can also disrupt communications between
	between BGP peers by breaking their TCP connection with spoofed RST		BGP peers by breaking their TCP connection with spoofed packets.
	packets. Outsider sources of bogus BGP information can reside anywhere		Outsider sources of bogus BGP information can reside anywhere in the
	in the world.		world.
			Consequently, the current BGP specification requires that a BGP
			implementation must support the authentication mechanism specified in
			[6]. However, the requirement for support of that authentication
			mechanism cannot ensure that the mechanism is configured for use. As
			the current BGP specification also allows for implementations that would
			accept connections from unconfigured peers ([2] Section 8), the
			authentication mechanism of [6] must be a configurable option. This is
			necessary because [6] is based on a pre-installed shared secret that
			could not be available for an unconfigured peer. The mechanism of [6]
			does not have the capability of IPSEC ([5]) to agree on a shared secret
			dynamically.
	BGP speakers themselves can inject bogus routing information, either by		BGP speakers themselves can inject bogus routing information, either by
	masquerading as information from any other legitimate BGP speaker, or by		masquerading as any other legitimate BGP speaker, or by distributing
	distributing unauthentic routing information as themselves.		unauthentic routing information as themselves. Historically,
	Historically, misconfigured and faulty routers have been responsible for		misconfigured and faulty routers have been responsible for widespread
	widespread disruptions in the Internet.		disruptions in the Internet.
	Bogus routing information can have many different effects on routing		Bogus routing information can have many different effects on routing
	behavior. If the bogus information removes routing information for a		behavior. If the bogus information removes routing information for a
	particular network, that network can become unreachable for the portion		particular network, that network can become unreachable for the portion
	of the Internet that accepts the bogus information. If the bogus		of the Internet that accepts the bogus information. If the bogus
	information changes the route to a network, then packets destined for		information changes the route to a network, then packets destined for
	that network may be forwarded by a sub-optimal path, or a path that does		that network may be forwarded by a sub-optimal path, or a path that does
	not follow the expected policy, or a path that will not forward the		not follow the expected policy, or a path that will not forward the
	traffic. As a consequence, traffic to that network could be delayed by		traffic. As a consequence, traffic to that network could be delayed by
	a longer than necessary path. The network could become unreachable from		a longer than necessary path. The network could become unreachable from
	skipping to change at page 4, line 37 ¶		skipping to change at page 6, line 4 ¶
	blackhole: large amounts of traffic are directed to be forwarded		blackhole: large amounts of traffic are directed to be forwarded
	through one router that cannot handle the increased level of		through one router that cannot handle the increased level of
	traffic and drops many/most/all packets,		traffic and drops many/most/all packets,
	delay: data traffic destined for a node is forwarded along a path		delay: data traffic destined for a node is forwarded along a path
	that is in some way inferior to the path it would otherwise take,		that is in some way inferior to the path it would otherwise take,
	looping: data traffic is forwarded along a path that loops, so that		looping: data traffic is forwarded along a path that loops, so that
	the data is never delivered,		the data is never delivered,
	eavesdrop: data traffic is forwarded through some router or network		eavesdrop: data traffic is forwarded through some router or network
	that would otherwise not see the traffic, affording an opportunity		that would otherwise not see the traffic, affording an opportunity
	to see the data,		to see the data,
	partition: some portion of the network believes that it is		partition: some portion of the network believes that it is
	partitioned from the rest of the network when it is not,		partitioned from the rest of the network when it is not,
	cut: some portion of the network believes that it has no route to		cut: some portion of the network believes that it has no route to
	some network that is in fact connected,		some network that is in fact connected,
	churn: the forwarding in the network changes at a rapid pace,		churn: the forwarding in the network changes at a rapid pace,
	resulting in large variations in the data delivery patterns (and		resulting in large variations in the data delivery patterns (and
	adversely affecting congestion control techniques),		adversely affecting congestion control techniques),
	instability: BGP become unstable so that convergence on a global		instability: BGP become unstable so that convergence on a global
	forwarding state is not achieved, and		forwarding state is not achieved, and
	overload: the BGP messages themselves become a significant portion		overload: the BGP messages themselves become a significant portion
	of the traffic the network carries.		of the traffic the network carries.
	2. Vulnerabilities and Risks		resource exhaustion: the BGP messages themselves cause exhaustion
			of critical router resources, such as table space.
			These consequences can fall exclusively on one end system prefix or may
			effect the operation of the network as a whole.
			2. Attacks
			The BGP protocol, in and of itself, is subject to the following attacks
			(list taken from the IAB Internet-Draft providing guideline for the
			security considerations section of Internet-Drafts [8]):
			eavesdropping: The routing data carried in BGP is carried in
			cleartext, so eavesdropping is a possible attack against routing
			data confidentiality. (Routing data confidentiality is not a
			common requirement.)
			replay: BGP does not provide for replay protection of its messages.
			message insertion: BGP does not provide protection against
			insertion of messages. However, because BGP uses TCP, when the
			connection is fully established, message insertion by an outsider
			would require accurate sequence number prediction (not entirely out
			of the question, but more difficult with mature TCP
			implementations) or session stealing attacks.
			message deletion: BGP does not provide protection against deletion
			of messages. Again, more difficult against a mature TCP
			implementation but not entirely out of the question
			message modification: BGP does not provide protection against
			modification of messages. A modification that did not change the
			length of the TCP payload would in general not be detectable.
			man-in-the-middle: BGP does not provide protection agains man-in-
			the-middle attacks. As BGP does no peer entity authentication, a
			man-in-the-middle attack is childs-play.
			denial of service: While bogus routing data can present a denial
			of service attack on the end systems that are trying to transmit
			data through the network and on the network infrastructure itself,
			certain bogus information can represent a denial of service on the
			BGP routing protocol. For example, advertising large numbers of
			more specific routes (longer prefixes) can cause BGP traffic and
			router table size to increase, even explode.
			The mandatory-to-support mechanism of [6] will counter the message
			insertion, deletion, and modification, man-in-the-middle attacks and the
			denial of service attacks from outsiders. The use of [6] does not
			protect against eavesdropping attacks, but routing data confidentiality
			is not a goal of BGP. The mechanism of [6] does not protect against
			replay attacks, so the only protection against replay is provided by the
			TCP sequence number processing. A replay attack could be mounted
			against a BGP connection protected with [6] but only in very carefully
			timed circumstances.
			3. Vulnerabilities and Risks
	The risks in BGP arise from three fundamental vulnerabilities:		The risks in BGP arise from three fundamental vulnerabilities:
	no mechanism has been mandated that provides strong protection of		BGP has no internal mechanism that provides strong protection of
	the integrity, freshness and source authenticity of the messages in		the integrity, freshness and peer entity authenticity of the
	peer-peer BGP communications.		messages in peer-peer BGP communications.
	no mechanism has been specified to validate the authority of an AS		no mechanism has been specified within BGP to validate the
	to announce NLRI information.		authority of an AS to announce NLRI information.
	no mechanism has been specified to ensure the authenticity of the		no mechanism has been specified within BGP to ensure the
	AS_PATH announced by an AS.		authenticity of the path attributes announced by an AS.
			The first basic vulnerability motivated the mandated support of [6] in
			the BGP specification. When that is employed, message integrity and
			peer entity authentication is provided. The mechanism of [6] assumes
			that the MD5 algorithm is secure and that the shared secret is protected
			and chosen to be difficult to guess.
			3.1. Vulnerabilities in BGP messages
	There are four different BGP message types - OPEN, KEEPALIVE,		There are four different BGP message types - OPEN, KEEPALIVE,
	NOTIFICATION, and UPDATE. This section contains a discussion of the		NOTIFICATION, and UPDATE. This section contains a discussion of the
	vulnerabilities arising from each message and the ability of outsiders		vulnerabilities arising from each message and the ability of outsiders
	or BGP peers to exploit the vulnerabilities. To summarize, outsiders		or BGP peers to exploit the vulnerabilities. To summarize, outsiders
	can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the		can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the
	BGP peer-peer connections and can use bogus UPDATE messages to disrupt		BGP peer-peer connections and can use bogus UPDATE messages to disrupt
	routing. Outsiders can also disrupt BGP peer-peer connections by		routing. Outsiders can also disrupt BGP peer-peer connections by
	inserting bogus TCP RST packets. BGP peers themselves are permitted to		inserting bogus TCP packets. BGP peers themselves are permitted to
	break peer-peer connections at any time, and so they cannot be said to		break peer-peer connections at any time, and so they cannot be said to
	be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However,		be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However,
	BGP peers can disrupt routing by issuing bogus UPDATE messages. In		BGP peers can disrupt routing by issuing bogus UPDATE messages. In
	particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI		particular, bogus ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and
	in UPDATE messages can disrupt routing.		bogus NLRI in UPDATE messages can disrupt routing.
	Each message introduces certain different vulnerabilities and risks.		Each message introduces certain different vulnerabilities and risks.
	2.1. OPEN		3.1.1. Message Header
	Because receipt of a new OPEN message in the Established state will		Event 21: Each BGP message starts with a standard header. In all cases,
	cause the close of the BGP peering session and thereby induce the		syntactic errors in the message header will cause the BGP speaker to
	release of all resources and deletion of all associated routes, the		close the connection, release all associated BGP resources, delete all
	ability to spoof this message can lead to a severe disruption of		routes learned through that connection and run its decision process to
	routing.		decide on new routes.
	2.2. KEEPALIVE		3.1.2. OPEN
	Receipt of a KEEPALIVE message when the peering connection is in the		Event 19: Receipt of an OPEN message in state Connect, Active or
	OpenSent state can lead to a failure to establish a connection. The		Established will cause the cause the BGP speaker to bring down the
			connection, release all associated BGP resources, delete all associated
			routes, run its decision process and cause the state to return to Idle.
			The deletion of routes can cause a cascading effect of routing changes
			propogating through other peers. Also, optionally, an implementation
			specific peer oscillation damping may be performed. The peer
			oscillation damping process can affect how soon the connection can be
			restarted. In state OpenSent, the arrival of an OPEN message will cause
			the BGP speaker to transition to the OpenConfirm state. The later
			arrival of the legitimate peer's OPEN message will lead the BGP speaker
			to declare a connection collision. The collision detection procedure
			may cause the legitimate connection to be dropped. Consequently, the
			ability to spoof this message can lead to a severe disruption of routing
			over a wide area.
			Event 20: If an OPEN message arrives when the OpenDelay timer is running
			when the connection is in state OpenSent or Established, the BGP speaker
			will bring down the connection, release all associated BGP resources,
			delete all associated routes, run its decision process and cause the
			state to return to Idle. The deletion of routes can cause a cascading
			effect of routing changes propogating through other peers. Also,
			optionally, an implementation specific peer oscillation damping may
			performed. The peer oscillation damping process can affect how soon the
			connection can be restarted. However, as the OpenDelay timer should
			never be running in the state OpenSent, this could only be caused by an
			error in the implementation (which is why the error code is "Finite
			State Machine Error"). It would be difficult, if not impossible, for an
			outsider to induce this error.
			Event 22: Errors in the OPEN message (e.g., unacceptable Hold state,
			malformed Optional Parameter, unsupported version, etc.) will cause the
			BGP speaker to bring down the connection, release all associated BGP
			resources, delete all associated routes, run its decision process and
			cause the state to return to Idle. The deletion of routes can cause a
			cascading effect of routing changes propogating through other peers.
			Also, optionally, an implementation specific peer oscillation damping
			may performed. The peer oscillation damping process can affect how soon
			the connection can be restarted. Consequently, the ability to spoof
			this message can lead to a severe disruption of routing over a wide
			area.
			3.1.3. KEEPALIVE
			Event 26: Receipt of a KEEPALIVE message when the peering connection is
			in the Connect, Active, and OpenSent states would cause the BGP speaker
			to transition to the Idle state and fail to establish a connection. The
	ability to spoof this message is a vulnerability. To exploit this		ability to spoof this message is a vulnerability. To exploit this
	vulnerability deliberately, the KEEPALIVE must be carefully timed in the		vulnerability deliberately, the KEEPALIVE must be carefully timed in the
	sequence of messages exchanged between the peers; otherwise, it causes		sequence of messages exchanged between the peers; otherwise, it causes
	no damage.		no damage.
	2.3. NOTIFICATION		3.1.4. NOTIFICATION
	Receipt of a NOTIFICATION message will cause the close of the BGP		Event 25: Receipt of a NOTIFICATION message in any state will cause the
	peering session and thereby induce the release of all resources and		BGP speaker to bring down the connection, release all associated BGP
	deletion of all associated routes. Therefore, the ability to spoof this		resources, delete all associated routes, run its decision process and
	message can lead to a severe disruption of routing.		cause the state to return to Idle. The deletion of routes can cause a
			cascading effect of routing changes propogating through other peers.
			Also, optionally, an implementation specific peer oscillation damping
			may performed. The peer oscillation damping process can affect how soon
			the connection can be restarted. Consequently, the ability to spoof
			this message can lead to a severe disruption of routing over a wide
			area.
	2.4. UPDATE		Event 24: A NOTIFICATION message carrying an error code of "Version
			Error" behaves the same as in Event 25, with the exception that the
			optional peer oscillation damping is not performed (in states Connect
			and Active, only when the OpenDelay timer is running). The damage
			caused is therefore one small bit less, in that restarting the
			connection is not affected.
	The Update message carries the routing information. The ability to		3.1.5. UPDATE
	spoof any part of this message can lead to a disruption of routing.
	2.4.1. Unfeasible Routes Length, Total Path Attribute Length		Event 27: The Update message carries the routing information. The
			ability to spoof any part of this message can lead to a disruption of
			routing.
			3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length
	There is a vulnerability arising from the ability to modify these		There is a vulnerability arising from the ability to modify these
	fields. If a length is modified, the message is not likely to parse		fields. If a length is modified, the message is not likely to parse
	properly, resulting in an error, the transmission of a NOTIFICATION		properly, resulting in an error, the transmission of a NOTIFICATION
	message and the close of the connection. As a true BGP speaker is		message and the close of the connection (see Event 28, below). As a
	always able to close a connection at any time, this vulnerability		true BGP speaker is always able to close a connection at any time, this
	represents an additional risk only when the source is a non-BGP speaker,		vulnerability represents an additional risk only when the source is not
	i.e., it presents no additional risk from BGP sources.		the configured BGP peer, i.e., it presents no additional risk from BGP
			sources.
	2.4.2. Withdrawn Routes		3.1.5.2. Withdrawn Routes
	An outsider could cause the elimination of existing legitimate routes by		An outsider could cause the elimination of existing legitimate routes by
	forging or modifying this field. An outsider could also cause the		forging or modifying this field. An outsider could also cause the
	elimination of reestablished routes by replaying this withdrawal		elimination of reestablished routes by replaying this withdrawal
	information from earlier packets.		information from earlier packets.
	A BGP speaker could "falsely" withdraw feasible routes using this field.		A BGP speaker could "falsely" withdraw feasible routes using this field.
	However, as the BGP speaker is authoritative for the routes it will		However, as the BGP speaker is authoritative for the routes it will
	announce, it is allowed to withdraw any previously announced routes that		announce, it is allowed to withdraw any previously announced routes that
	it wants. As the receiving BGP speaker will only withdraw routes		it wants. As the receiving BGP speaker will only withdraw routes
	associated with the sending BGP speaker, there is no opportunity for a		associated with the sending BGP speaker, there is no opportunity for a
	BGP speaker to withdraw another BGP speaker's routes. Therefore, there		BGP speaker to withdraw another BGP speaker's routes. Therefore, there
	is no additional risk from BGP peers via this field.		is no additional risk from BGP peers via this field.
	2.4.3. Path Attributes		3.1.5.3. Path Attributes
	The path attributes present many different vulnerabilities and risks.		The path attributes present many different vulnerabilities and risks.
	Attribute Flags, Attribute Type Codes, Attribute Length		Attribute Flags, Attribute Type Codes, Attribute Length
	A BGP peer or an outsider could modify the attribute length or attribute		A BGP peer or an outsider could modify the attribute length or attribute
	type (flags and type codes) so they did not reflect the attribute values		type (flags and type codes) so they did not reflect the attribute values
	that followed. If the flags were modified, the flags and type code		that followed. If the flags were modified, the flags and type code
	could become incompatible (i.e., a mandatory attribute marked as		could become incompatible (i.e., a mandatory attribute marked as
	partial), or a optional attribute could be interpreted as a mandatory		partial), or a optional attribute could be interpreted as a mandatory
	attribute or vice versa. If the type code were modified, the attribute		attribute or vice versa. If the type code were modified, the attribute
	value could be interpreted as if it were the data type and value of a		value could be interpreted as if it were the data type and value of a
	different attribute.		different attribute.
	The most likely result from modifying the attribute length, flags, or		The most likely result from modifying the attribute length, flags, or
	type code would be a parse error of the UPDATE message. A parse error		type code would be a parse error of the UPDATE message. A parse error
	would cause the transmission of a NOTIFICATION message and the close of		would cause the transmission of a NOTIFICATION message and the close of
	the connection. As a true BGP speaker is always able to close a		the connection (see Event 28, below). As a true BGP speaker is always
	connection at any time, this vulnerability represents an additional risk		able to close a connection at any time, this vulnerability represents an
	only when the source is an outsider, i.e., it presents no additional		additional risk only when the source is an outsider, i.e., it presents
	risk from a BGP peer.		no additional risk from a BGP peer.
	ORIGIN		ORIGIN
	This field indicates whether the information was learned from IGP or EGP		This field indicates whether the information was learned from IGP or EGP
	information. If the route is used in inter-AS multicast routing, a		information. This field is used in making routing decisions, so there
	value of INCOMPLETE may be used. This field is not used in making		is some small vulnerability in being able to affect the receiving BGP
	routing decisions, so there are no vulnerabilities arising from this		speaker's routing decision by modifying this field.
	field, either from BGP peers or outsiders.
	AS_PATH		AS_PATH
	A BGP peer or outsider could announce an AS_PATH that was not accurate		A BGP peer or outsider could announce an AS_PATH that was not accurate
	for the associated NLRI. Forwarding for the NLRI associated with the		for the associated NLRI.
	AS_PATH could potentially be induced to follow a sub-optimal path, a
	path that did not follow some intended policy, or even a path that would
	not forward the traffic. If the path would not forward the traffic, the
	NLRI would become unreachable for that portion of the Internet that
	accepted the false path. If much traffic is mis-directed, some routers
	and transit networks along the announced route could become flooded with
	the mis-directed traffic.
	It is not clear how far an inaccurate AS_PATH could deviate from the		As it is legitimate for a BGP peer not to verify that a received AS_PATH
	true AS_PATH. It may be that the first AS in the AS_PATH, at least,		begins with the AS number of its peer, a malicious BGP peer could
	must be a legal hop. The RFC states that a BGP speaker prepends its own		announce a path that begins with the AS of any BGP speaker with little
	AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker		impact on itself. This could affect the receiving BGP speaker's
	must prepend its own AS, then a BGP speaker that produced a bogus		decision procedure and choice of installed route. The malicious peer
	AS_PATH could end up receiving the traffic for the associated NLRI.		could considerably shorten the AS_PATH, which will increase that route's
	This could be desirable if the error was deliberate and the intent was		chances of being chosen, possibly giving the malicious peer access to
	to receive traffic that would not otherwise be received. Receiving the		traffic it would otherwise not receive. The shortened AS_PATH also
	mis-routed traffic could be undesirable for the faulty BGP speaker if it		could result in routing loops, as it does not contain the information
	were not prepared to handle the extra (mis-routed) traffic. So,		needed to prevent loops.
	requiring a BGP peer to prepend its own AS to the AS_PATH, might
	encourage or discourage it from inventing an arbitrary AS_PATH,
	depending on its resources and intent.
	If BGP peers need not prepend its own AS (or implementations do not		It is possible for a BGP speaker to be configured to accept routes with
	ensure that this is done), then a malicious BGP peer could announce a		its own AS number in the AS path. Such operational considerations are
	path that begins with the AS of any BGP speaker with little impact on		defined to be "outside the scope" of the BGP specification, but the fact
	itself.		that AS_PATHs can have loops means that implementations cannot
			automatically reject routes with loops. Each BGP speaker verifies only
			that its own AS number does not appear in the AS_PATH.
	Whether such an arbitrary AS_PATH is a vulnerability would depend on		Coupled with the ability to use any value for the NEXT_HOP, this gives a
	whether BGP implementations check the AS_PATH (to see if the first AS is		malicious BGP speaker considerable control over the path traffic will
	the neighbor) and would catch the error. If there are legitimate		take.
	situations in which a BGP speaker could pass an AS_PATH to a neighbor
	without putting its own AS at the head of the AS_PATH, then there is no
	way for implementations to detect totally bogus AS_PATHs.
	Originating Routes		Originating Routes
	A special case of announcing a false AS_PATH occurs when the AS_PATH		A special case of announcing a false AS_PATH occurs when the AS_PATH
	advertises a direct connection to a specific network address. An BGP		advertises a direct connection to a specific network address. An BGP
	peer or outsider could disrupt routing to the network(s) listed in the		peer or outsider could disrupt routing to the network(s) listed in the
	NLRI field by falsely advertising a direct connection to the network.		NLRI field by falsely advertising a direct connection to the network.
	The NLRI would become unreachable to the portion of the network that		The NLRI would become unreachable to the portion of the network that
	accepted this false route, unless the ultimate AS on the AS_PATH		accepted this false route, unless the ultimate AS on the AS_PATH
	undertook to tunnel the packets it was forwarded for this NLRI on toward		undertook to tunnel the packets it was forwarded for this NLRI on toward
	skipping to change at page 9, line 21 ¶		skipping to change at page 13, line 8 ¶
	recipient and the NEXT_HOP address must share a subnet. It is clear		recipient and the NEXT_HOP address must share a subnet. It is clear
	that an outsider modifying this field could disrupt the forwarding of		that an outsider modifying this field could disrupt the forwarding of
	traffic between the two AS's.		traffic between the two AS's.
	In the case that the recipient of the message is an external peer of an		In the case that the recipient of the message is an external peer of an
	AS and the route was learned from another peer AS (this is one of two		AS and the route was learned from another peer AS (this is one of two
	forms of "third party" NEXT_HOP), then the BGP speaker advertising the		forms of "third party" NEXT_HOP), then the BGP speaker advertising the
	route has the opportunity to direct the recipient to forward traffic to		route has the opportunity to direct the recipient to forward traffic to
	a BGP speaker at the NEXT_HOP address. This affords the opportunity to		a BGP speaker at the NEXT_HOP address. This affords the opportunity to
	direct traffic at a router that may not be able to continue forwarding		direct traffic at a router that may not be able to continue forwarding
	the traffic. It is unclear whether this would also require the		the traffic. A malicious BGP speaker can also use this technique to
	advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP		force another AS to carry traffic it would otherwise not have to carry.
	external peer's AS.		In some cases, this could be to the malicious BGP speaker's benefit, as
			it could cause traffic to be carried long-haul by the victim AS to some
			other peering point it shared with the victim.
	MULTI_EXIT_DISC		MULTI_EXIT_DISC
	The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted		The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted
	between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an		between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an
	inter-AS peer may be propagated within an AS, it may not be propagated		inter-AS peer may be propagated within an AS, it may not be propagated
	to other AS's. Consequently, this field is only used in making routing		to other AS's. Consequently, this field is only used in making routing
	decisions internal to one AS. Modifying this field, whether by an		decisions internal to one AS. Modifying this field, whether by an
	outsider or an BGP peer, could influence routing within an AS to be sub-		outsider or an BGP peer, could influence routing within an AS to be sub-
	optimal, but the effect should be limited in scope.		optimal, but the effect should be limited in scope.
	skipping to change at page 9, line 48 ¶		skipping to change at page 13, line 37 ¶
	peers and excluded from messages with external peers. Consequently,		peers and excluded from messages with external peers. Consequently,
	modification of the LOCAL_PREF could effect the routing process within		modification of the LOCAL_PREF could effect the routing process within
	the AS only. Note that there is no requirement in the BGP RFC that the		the AS only. Note that there is no requirement in the BGP RFC that the
	LOCAL_PREF be consistent among the internal BGP speakers of an AS. As		LOCAL_PREF be consistent among the internal BGP speakers of an AS. As
	BGP peers are free to choose the LOCAL_PREF as they wish, modification		BGP peers are free to choose the LOCAL_PREF as they wish, modification
	of this field is a vulnerability with respect to outsiders only.		of this field is a vulnerability with respect to outsiders only.
	ATOMIC_AGGREGATE		ATOMIC_AGGREGATE
	The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way		The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way
	has received a more specific and a less specific route to the NLRI and		has aggregated several routes and advertised the aggregate NLRI without
	installed the aggregated route. This route cannot be de-aggregated		the AS_SET formed as usual from the AS's in the aggregated routes'
	because it is not certain that the route to more specific prefixes will		AS_PATHs. BGP speakers receiving a route with ATOMIC_AGGREGATE are
	follow the listed AS_PATH. Consequently, BGP speakers receiving a route		restricted from making the NLRI any more specific. Removing the
	with ATOMIC_AGGREGATE are restricted from making the NLRI any more		ATOMIC_AGGREGATE attribute would remove the restriction, possibly
	specific. Removing the ATOMIC_AGGREGATE attribute would remove the		causing traffic intended for the more specific NLRI to be routed
	restriction, possibly causing traffic intended for the more specific		incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation
	NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute		was done would have little effect, beyond restricting the un-aggregated
	when no aggregation was done would have little effect, beyond		NLRI from being made more specific. This vulnerability exists whether
	restricting the un-aggregated NLRI from being made more specific. This		the source is a BGP peer or an outsider.
	vulnerability exists whether the source is a BGP peer or an outsider.
	AGGREGATOR		AGGREGATOR
	This field may be included by a BGP speaker who has computed the routes		This field may be included by a BGP speaker who has computed the routes
	represented in the UPDATE message from aggregation of other routes. The		represented in the UPDATE message from aggregation of other routes. The
	field contains the AS number and IP address of the last aggregator of		field contains the AS number and IP address of the last aggregator of
	the route. It is not used in making any routing decisions, so it does		the route. It is not used in making any routing decisions, so it does
	not represent a vulnerability.		not represent a vulnerability.
	2.4.4. NLRI		3.1.5.4. NLRI
	By modifying or forging this field, either an outsider or BGP peer		By modifying or forging this field, either an outsider or BGP peer
	source could cause disruption of routing to the announced network,		source could cause disruption of routing to the announced network,
	overwhelm a router along the announced route, cause data loss when the		overwhelm a router along the announced route, cause data loss when the
	announced route will not forward traffic to the announced network, route		announced route will not forward traffic to the announced network, route
	traffic by a sub-optimal route, etc.		traffic by a sub-optimal route, etc.
	2.5. BGP Extensions		Event 28: If the UPDATE message is mal-formed (Withdrawn Routes Length,
			Total Attribute Length, or Attribute Length that are improper, missing
			mandatory well-known attributes, Attribute Flags that conflict with the
			Attribute Type Codes, syntactic errors in the ORIGIN, NEXT_HOP or
			AS_PATH, etc.), then the BGP speaker will bring down the connection,
			release all associated BGP resources, delete all associated routes, run
			its decision process and cause the state to return to Idle. The
			deletion of routes can cause a cascading effect of routing changes
			propogating through other peers. Also, optionally, an implementation
			specific peer oscillation damping may be performed. The peer
			oscillation damping process can affect how soon the connection can be
			restarted. Consequently, the ability of an outsider to spoof this
			message could cause wide-spread disruption of routing. As a BGP speaker
			has the authority to close a connection whenver it wants, this message
			gives BGP speakers no opportunity to cause damage than they already had.
	Several standards track extensions have been defined for BGP, e.g., [3],		3.2. Vulnerabilities through Other Protocols
	[4]. Some have present additional vulnerabilities.
	2.5.1. Communities		3.2.1. TCP messages
	An optional transitive path attribute called COMMUNITIES, [3], provides		BGP runs over TCP, listening on port 179. Therefore, BGP is subject to
	for more flexible and scalable configuration of routing policies and for		attack through attacks on TCP.
	control of configuration by the service provider customer. Routing
	UPDATEs may now include a communities attribute that is used by the
	receiver in deciding to accept, prefer, or distribute the UPDATE route.
	An outsider could forge values in this field to affect the routing		3.2.1.1. TCP SYN
	behavior of the receiver. In particular, the defined values for this
	attribute of NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED offer the
	opportunity to affect the distribution of those routes.
	Depending on the use the receiver makes of the communities attribute, a		SYN flooding: BGP is as subject to the effects on the TCP implementation
	BGP peer who had knowledge of the routing decision process of the		of SYN flooding attacks as other protocols, and must rely on the
	receiver could misuse communities to which it was not authorized to its		implementation's protections against this attack.
	own benefit or to the harm of others.
	2.5.2. Confederations		Event 14: If an attacker were able to send a SYN to the BGP speaker,
			then the legitimate peer's SYN would appear to be a second connection.
			If the attacker were able to continue with a sequence of packets
			resulting in a BGP connection (guessing the BGP speaker's choice for
			sequence number on the SYN ACK, for example), then, the attacker's
			connection and the legitimate peer's connection would appear to be a
			connection collision. Depending on the outcome of the collision
			detection (i.e., the attacker chose a BGP identifier so as to win the
			race), the legitimate peer's true connection could be destroyed. The
			use of [6] will counter this attack.
	New types for AS_PATH segments called AS_CONFED_SEQUENCE and		3.2.1.2. TCP SYN ACK
	AS_CONFED_SET, [4], offer an alternative to ful mesh IBGP sessions. A
	confederation is a collection of autonomous systems advertised to BGP
	speaker outside the confederation as a single AS but within the
	confederation as if they were distinct AS's.
	An outsider who was able to forge this segment type could affect routing		Event 16: If an attacker were able to respond to a BGP speaker's SYN
	within the confederation and consequently routing with peers as well.		before the legitimate peer, then the legitimate peer's SYN-ACK would
			receive a empty ACK reply, causing the legitimate peer to issue a RST
			that would break the connection. The BGP speaker would bring down the
			connection, release all associated BGP resources, delete all associated
			routes and run its decision process. This attack requires that the
			attacker be able to predict the sequence number used in the SYN. The
			use of [6] will counter this attack.
	The specification [4] makes no distinction between the values for		This attack has no corollary from the legitimate BGP peer.
	Member-AS numbers used within a confederation and AS numbers used
	outside a confederation. The possibility exists for a BGP speaker to
	include a segment type of AS_CONFED_SEQUENCE or AS_CONFED_SET and use
	the same Member-AS value as used in its peer's own confederation. This
	presents an opportunity to considerably affect routing between the two
	confederations and inside the peer's confederation.
	3. Security Considerations		3.2.1.3. TCP ACK
			Event 17: If an attacker were able to spoof an ACK at the appropriate
			time, then the BGP speaker would consider the connection complete, send
			an OPEN (Event 17) and transition to the OpenSent state. The arrival of
			the legitimate peer's ACK would not be delivered to the BGP process, as
			it would look like a duplicate packet. This message, then, presents no
			particular vulnerability to BGP.
			3.2.1.4. TCP RST/FIN/FIN-ACK
			Event 18: If an attacker were able to spoof a RST, the BGP speaker would
			bring down the connection, release all associated BGP resources, delete
			all associated routes and run its decision process. If an attacker were
			able to spoof a FIN, then data could still be transmitted, but any
			attempt to receive would receive a notification that the connection is
			closing. In most cases, this results in the connection being placed in
			an Idle state, but if the connection is in the OpenSent state at the
			time, the connection returns to an Active state. Spoofing a RST in this
			situation requires an attacker to guess a sequence number that is in the
			proper half of the sending window, generally an easier task than
			guessing the exact sequence number so as to spoof a FIN. The use of [6]
			will counter this attack.
			3.2.2. Other supporting protocols
			3.2.2.1. Manual stop
			Event 2: A manual stop event causes the BGP speaker to bring down the
			connection, release all associated BGP resources, delete all associated
			routes and run its decision process. If the mechanism by which a BGP
			speaker was informed of a manual stop were not carefully protected, the
			BGP connection could be destroyed by an attacker. Consequently, BGP
			security is secondarily dependent on the security of whatever protocols
			are used to operate the platform.
			3.2.2.2. Timer events
			Events 9-13: The Keepalive, Hold, and Open Delay timers are critical to
			BGP operation. For example, if the Hold timer value were changed, the
			remote peer might consider the connection unresponsive and bring the
			connection down, releasing resources, deleting associated routes, etc.
			Consequently, BGP security is secondarily dependent on the security of
			the protocols by which the platform is managed and configured.
			4. Security Considerations
	This entire memo is about security, describing an analysis of the		This entire memo is about security, describing an analysis of the
	vulnerabilities that exist in the BGP protocol. A companion work, [5],		vulnerabilities that exist in the BGP protocol.
	describes possible security solutions and their costs.
	4. References		Use of the mandatory-to-support mechanisms of [6] counter the message
			insertion, deletion, and modification attacks and man-in-the-middle
			attacks from outsiders. In cases where a BGP implementation accepts
			connections from unconfigured hosts, the use of IPSEC AH would couter
			these threats as well as replay attacks and would permit key agreement
			and roll-over. If routing data confidentiality were desired, IPSEC ESP
			would provide that service.
			4.1. Residual Risk
			As cryptographic-based mechanisms, both [6] and IPSEC assume that the
			cyrptographic algorithms are secure, that secrets used are protected
			from exposure and are chosen well so as not to be guessable, that the
			platforms are securely managed and operated to prevent break-ins, etc.
			These mechanisms do not prevent attacks that arise from a router's
			legitimate BGP peers. There are several possible solutions to prevent a
			BGP speaker from inserting bogus information in its advertisements to
			its peers, i.e., from mounting an attack on a network's origination or
			AS-PATH.
			(1) Origination Protection: sign the originating AS.
			(2) Origination and Adjacency Protection: sign the originating AS and
			predecessor information ([3])
			(3) Origination and Route Protection: sign the originating AS, and
			nest signatures of AS_PATHs to the number of consecutive bad
			routers you want to prevent from causing damage. ([7])
			(4) Filtering: rely on a registry to verify the AS_PATH and NLRI
			originating AS ([4]).
			Filtering is in use near some customer attachment points, but is not
			effective near the Internet center. The other mechanisms are still
			controversial and are not yet in common use.
			5. References
	[1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)",		[1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
	RFC1771, March 1995.		RFC1771, March 1995.
	[2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work		[2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work
	in progress, November 2001. available as		in progress, March 2003. available as
	<<draft-ietf-idr-bgp4-17.txt>> at Internet-Draft shadow sites.		<<draft-ietf-idr-bgp4-19.txt>> at Internet-Draft shadow sites.
	[3] R. Chandra, P. Traina, and T. Li, "BGP Communities Attribute",		[3] B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway
	RFC1997, August 1996.		Routing Protocol", Proc. Global Internet'96, London, UK, 20-21
			November 1996.
	[4] P. Traina, D. McPherson, and J. Scudder, "Autonomous System		[4] C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange,
	Confederations for BGP", RFC3065, February 2001.		"Routing Policy System Security", RFC 2725, December, 1999.
	[5] S. Murphy, "BGP Security Protections", work in progress, October,		[5] S. Kent and R.Atkinson, "Security Architecture for the Internet
	2002. available as		Protocol", RFC2401, November 1998.
	<<draft-murphy-bgp-protect-01.txt>> at Internet-Draft shadow sites.
	5. Author's Address		[6] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature
			Option", RFC2385, August 1998.
			[7] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol
			(Secure-BGP)", IEEE Journal on Selected Areas in Communications,
			Vol. 18, No. 4, April 2000, pp. 582-592.
			[8] E. Rescorla and B. Korver, "Guidelines for Writing RFC Text on
			Security Considerations", work in progress, January 2003.
			available as
			<<draft-iab-sec-cons-03.txt>> at Internet-Draft shadow sites.
			6. Author's Address
	Sandra Murphy		Sandra Murphy
	Network Associates, Inc.		Network Associates, Inc.
	NAI Labs		NAI Labs
	3060 Washington Road		3060 Washington Road
	Glenwood, MD 21738		Glenwood, MD 21738
	EMail: Sandy@tislabs.com		EMail: Sandy@tislabs.com
End of changes. 56 change blocks.
	188 lines changed or deleted		431 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/