draft-ietf-grow-ix-bgp-route-server-operations-00.txt		draft-ietf-grow-ix-bgp-route-server-operations-01.txt
	GROW Working Group N. Hilliard		GROW Working Group N. Hilliard
	Internet-Draft INEX		Internet-Draft INEX
	Intended status: Informational E. Jasinska		Intended status: Informational E. Jasinska
	Expires: February 23, 2014 Microsoft Corporation		Expires: March 01, 2014 Microsoft Corporation
	R. Raszuk		R. Raszuk
	NTT I3		NTT I3
	N. Bakker		N. Bakker
	AMS-IX B.V.		AMS-IX B.V.
	August 22, 2013		August 28, 2013
	Internet Exchange Route Server Operations		Internet Exchange Route Server Operations
	draft-ietf-grow-ix-bgp-route-server-operations-00		draft-ietf-grow-ix-bgp-route-server-operations-01
	Abstract		Abstract
	The popularity of Internet exchange points (IXPs) brings new		The popularity of Internet exchange points (IXPs) brings new
	challenges to interconnecting networks. While bilateral eBGP		challenges to interconnecting networks. While bilateral eBGP
	sessions between exchange participants were historically the most		sessions between exchange participants were historically the most
	common means of exchanging reachability information over an IXP, the		common means of exchanging reachability information over an IXP, the
	overhead associated with this interconnection method causes serious		overhead associated with this interconnection method causes serious
	operational and administrative scaling problems for IXP participants.		operational and administrative scaling problems for IXP participants.
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on February 23, 2014.		This Internet-Draft will expire on March 01, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 30		skipping to change at page 2, line 30
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3		2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3
	3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4		3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4
	4. Operational Considerations for Route Server Installations . . 5		4. Operational Considerations for Route Server Installations . . 5
	4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6		4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6
	4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 6		4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 6
	4.2.1.1. View Merging and Decomposition . . . . . . . . . 6		4.2.1.1. View Merging and Decomposition . . . . . . . . . 7
	4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 7		4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 7
	4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8		4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8
	4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8		4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8
	4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8		4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8
	4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9		4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9
	4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9		4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9
	4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9		4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9
	4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9		4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9
	4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10		4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10
	4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10		4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Internet exchange points (IXPs) provide IP data interconnection		Internet exchange points (IXPs) provide IP data interconnection
	facilities for their participants, typically using shared Layer-2		facilities for their participants, typically using shared Layer-2
	networking media such as Ethernet. The Border Gateway Protocol (BGP)		networking media such as Ethernet. The Border Gateway Protocol (BGP)
	[RFC4271] is normally used to facilitate exchange of network		[RFC4271] is normally used to facilitate exchange of network
	reachability information over these media.		reachability information over these media.
	As bilateral interconnection between IXP participants requires		As bilateral interconnection between IXP participants requires
	operational and administrative overhead, BGP route servers		operational and administrative overhead, BGP route servers
	[I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP		[I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP
	operators to provide a simple and convenient means of interconnecting		operators to provide a simple and convenient means of interconnecting
	skipping to change at page 10, line 41		skipping to change at page 10, line 41
	routing control path between the two hosts is usually (but not		routing control path between the two hosts is usually (but not
	always, due to IXP inter-switch connectivity load balancing		always, due to IXP inter-switch connectivity load balancing
	algorithms) the same as the data path between them.		algorithms) the same as the data path between them.
	Problems of this form can be dealt with using [RFC5881] bidirectional		Problems of this form can be dealt with using [RFC5881] bidirectional
	forwarding detection. However, as this is a bilateral protocol		forwarding detection. However, as this is a bilateral protocol
	configured between routers, and as there is currently no means for		configured between routers, and as there is currently no means for
	automatic configuration of BFD between route server clients, BFD does		automatic configuration of BFD between route server clients, BFD does
	not currently provide an optimal means of handling the problem.		not currently provide an optimal means of handling the problem.
	5. Security Considerations		4.8. BGP NEXT_HOP Hijacking
			Section 5.1.3(2) of [RFC4271] allows eBGP speakers to change the
			NEXT_HOP address of an NLRI update to be a different internet address
			on the same subnet. This is the mechanism which allows route servers
			to operate on a shared layer 2 IXP network. However, the mechanism
			can be abused by route server clients to redirect traffic for their
			prefixes to other IXP participant routers.
			____
			/ \
			| AS99 |
			\____/
			/ \
			/ \
			__/ \__
			/ \ / \
			..| AS1 |..| AS2 |..
			: \___/ \___/ :
			: \ / :
			: \ / :
			: \__/ :
			: IXP / \ :
			: | RS | :
			: \____/ :
			: :
			....................
			Figure 3: BGP NEXT_HOP Hijacking using a Route Server
			For example in Figure 3, if AS1 and AS2 both announce prefixes for
			AS99 to the route server, AS1 could set the NEXT_HOP address for
			AS99's prefixes to be the address of AS2's router, thereby diverting
			traffic for AS99 via AS2. This may override the routing policies of
			AS99 and AS2.
			Worse still, if the route server operator does not use inbound prefix
			filtering, AS1 could announce any arbitrary prefix to the route
			server with a NEXT_HOP address of any other IXP participant. This
			could be used as a denial of service mechanism against either the
			users of the address space being announced by illicitly diverting
			their traffic, or the other IXP participant by overloading their
			network with traffic which would not normally be sent there.
			This problem is not specific to route servers and it can also be
			implemented using bilateral peering sessions. However, the potential
			damage is amplified by route servers because a single BGP session can
			be used to affect many networks simultaneously.
			Route server operators SHOULD check that the BGP NEXT_HOP attribute
			for NLRIs received from a route server client matches the interface
			address of the client. If the route server receives an NLRI where
			these addresses are different and where the announcing route server
			client is in a different autonomous system to the route server client
			which uses the next hop address, the NLRI SHOULD be dropped.
			5. Security Considerations
	On route server installations which do not employ path hiding		On route server installations which do not employ path hiding
	mitigation techniques, the path hiding problem outlined in section		mitigation techniques, the path hiding problem outlined in section
	Section 4.1 can be used in certain circumstances to proactively block		Section 4.1 can be used in certain circumstances to proactively block
	third party prefix announcements from other route server clients.		third party prefix announcements from other route server clients.
			If the route server operator does not implement prefix leakage
			mitigation as described in section Section 4.3, it is trivial for
			route server clients to implement denial of service attacks against
			arbitrary Internet networks using a route server.
			Route server installations SHOULD be secured against BGP NEXT_HOP
			hijacking, as described in section Section 4.8.
	6. IANA Considerations		6. IANA Considerations
	There are no IANA considerations.		There are no IANA considerations.
	7. Acknowledgments		7. Acknowledgments
	The authors would like to thank Chris Hall, Ryan Bickhart and Steven		The authors would like to thank Chris Hall, Ryan Bickhart, Steven
	Bakker for their valuable input.		Bakker and Eduardo Ascenco Reis for their valuable input.
	In addition, the authors would like to acknowledge the developers of		In addition, the authors would like to acknowledge the developers of
	BIRD, OpenBGPD and Quagga, whose open source BGP implementations		BIRD, OpenBGPD and Quagga, whose open source BGP implementations
	include route server capabilities which are compliant with this		include route server capabilities which are compliant with this
	document.		document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
End of changes. 11 change blocks.
	16 lines changed or deleted		80 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/