draft-ietf-lisp-alt-09.txt		draft-ietf-lisp-alt-10.txt
	Network Working Group V. Fuller		Network Working Group V. Fuller
	Internet-Draft D. Farinacci		Internet-Draft D. Farinacci
	Intended status: Experimental D. Meyer		Intended status: Experimental D. Meyer
	Expires: March 23, 2012 D. Lewis		Expires: June 8, 2012 D. Lewis
	Cisco		Cisco
	September 20, 2011		December 6, 2011
	LISP Alternative Topology (LISP+ALT)		LISP Alternative Topology (LISP+ALT)
	draft-ietf-lisp-alt-09.txt		draft-ietf-lisp-alt-10.txt
	Abstract		Abstract
	This document describes a simple distributed index system to be used		This document describes a simple distributed index system to be used
	by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router		by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
	(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)		(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
	which holds the mapping information for a particular Endpoint		which holds the mapping information for a particular Endpoint
	Identifier (EID). The MR can then query that ETR to obtain the		Identifier (EID). The MR can then query that ETR to obtain the
	actual mapping information, which consists of a list of Routing		actual mapping information, which consists of a list of Routing
	Locators (RLOCs) for the EID. Termed the Alternative Logical		Locators (RLOCs) for the EID. Termed the Alternative Logical
	Topology (ALT), the index is built as an overlay network on the		Topology (ALT), the index is built as an overlay network on the
	public Internet using the Border Gateway Protocol (BGP) and the		public Internet using the Border Gateway Protocol (BGP) and the
	Generic Routing Encapsulation (GRE). Using these proven protocols,		Generic Routing Encapsulation (GRE).
	the ALT can be built and deployed relatively quickly without any
	changes to the existing routing infrastructure.
	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). 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 March 23, 2012.		This Internet-Draft will expire on June 8, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 18		skipping to change at page 2, line 25
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6		2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
	3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 9		3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 9		3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 9
	3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 10		3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 10
	3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10		3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10
	3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10		3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10
	3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10		3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
	3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11		3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11
	4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12		4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13		4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
	4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13		4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 14
	4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15		4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15
	5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16		5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16
	5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16		5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16
	5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17		5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17
	5.3. ALT Datagram forwarding falure . . . . . . . . . . . . . . 17		5.3. ALT Datagram forwarding falure . . . . . . . . . . . . . . 17
	6. BGP configuration and protocol considerations . . . . . . . . 19		6. BGP configuration and protocol considerations . . . . . . . . 19
	6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19		6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19
	6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 19		6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 19
	7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20		7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20
	7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 20		7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 20
	skipping to change at page 6, line 20		skipping to change at page 6, line 20
	Alternative Logical Topology (ALT): The virtual overlay network		Alternative Logical Topology (ALT): The virtual overlay network
	made up of tunnels between LISP+ALT Routers. The Border Gateway		made up of tunnels between LISP+ALT Routers. The Border Gateway
	Protocol (BGP) runs between ALT Routers and is used to carry		Protocol (BGP) runs between ALT Routers and is used to carry
	reachability information for EID-prefixes. The ALT provides a way		reachability information for EID-prefixes. The ALT provides a way
	to forward Map-Requests (and, if supported, Data Probes) toward		to forward Map-Requests (and, if supported, Data Probes) toward
	the ETR that "owns" an EID-prefix. As a tunneled overlay, its		the ETR that "owns" an EID-prefix. As a tunneled overlay, its
	performance is expected to be quite limited so use of it to		performance is expected to be quite limited so use of it to
	forward high-bandwidth flows of Data Probes is strongly		forward high-bandwidth flows of Data Probes is strongly
	discouraged (see Section 3.3 for additional discussion).		discouraged (see Section 3.3 for additional discussion).
	Legacy Internet: The portion of the Internet which does not run
	LISP and does not participate in LISP+ALT.
	ALT Router: The devices which run on the ALT. The ALT is a static		ALT Router: The devices which run on the ALT. The ALT is a static
	network built using tunnels between ALT Routers. These routers		network built using tunnels between ALT Routers. These routers
	are deployed in a roughly-hierarchical mesh in which routers at		are deployed in a roughly-hierarchical mesh in which routers at
	each level in the topology are responsible for aggregating EID-		each level in the topology are responsible for aggregating EID-
	prefixes learned from those logically "below" them and advertising		prefixes learned from those logically "below" them and advertising
	summary prefixes to those logically "above" them. Prefix learning		summary prefixes to those logically "above" them. Prefix learning
	and propagation between ALT Routers is done using BGP. An ALT		and propagation between ALT Routers is done using BGP. An ALT
	Router at the lowest level, or "edge" of the ALT, learns EID-		Router at the lowest level, or "edge" of the ALT, learns EID-
	prefixes from its "client" ETRs. See Section 3.1 for a		prefixes from its "client" ETRs. See Section 3.1 for a
	description of how EID-prefixes are learned at the "edge" of the		description of how EID-prefixes are learned at the "edge" of the
	skipping to change at page 8, line 6		skipping to change at page 8, line 6
	EID-to-RLOC Mapping: A binding between an EID-prefix and the set of		EID-to-RLOC Mapping: A binding between an EID-prefix and the set of
	RLOCs that can be used to reach it; sometimes referred to simply		RLOCs that can be used to reach it; sometimes referred to simply
	as a "mapping".		as a "mapping".
	EID-prefix Reachability: An EID-prefix is said to be "reachable" if		EID-prefix Reachability: An EID-prefix is said to be "reachable" if
	at least one of its locators is reachable. That is, an EID-prefix		at least one of its locators is reachable. That is, an EID-prefix
	is reachable if the ETR that is authoritative for a given EID-to-		is reachable if the ETR that is authoritative for a given EID-to-
	RLOC mapping is reachable.		RLOC mapping is reachable.
	Default Mapping: A Default Mapping is a mapping entry for EID-		Default Mapping: A Default Mapping is a mapping entry for EID-
	prefix 0.0.0.0/0 (0::/0 for ipv6). It maps to a locator-set used		prefix 0.0.0.0/0 (::/0 for ipv6). It maps to a locator-set used
	for all EIDs in the Internet. If there is a more specific EID-		for all EIDs in the Internet. If there is a more specific EID-
	prefix in the mapping cache it overrides the Default Mapping		prefix in the mapping cache it overrides the Default Mapping
	entry. The Default Mapping can be learned by configuration or		entry. The Default Mapping can be learned by configuration or
	from a Map-Reply message.		from a Map-Reply message.
	ALT Default Route: An EID-prefix value of 0.0.0.0/0 (or 0::/0 for		ALT Default Route: An EID-prefix value of 0.0.0.0/0 (or ::/0 for
	ipv6) which may be learned from the ALT or statically configured		ipv6) which may be learned from the ALT or statically configured
	on an edge ALT Router. The ALT-Default Route defines a forwarding		on an edge ALT Router. The ALT-Default Route defines a forwarding
	path for a packet to be sent into the ALT on a router which does		path for a packet to be sent into the ALT on a router which does
	not have a full ALT forwarding database.		not have a full ALT forwarding database.
	3. The LISP+ALT model		3. The LISP+ALT model
	The LISP+ALT model uses the same basic query/response protocol that		The LISP+ALT model uses the same basic query/response protocol that
	is documented in [LISP]. In particular, LISP+ALT provides two types		is documented in [LISP]. In particular, LISP+ALT provides two types
	of packet that an ITR can originate to obtain EID-to-RLOC mappings:		of packet that an ITR can originate to obtain EID-to-RLOC mappings:
	skipping to change at page 12, line 23		skipping to change at page 12, line 23
	The basic idea embodied in LISP+ALT is to use BGP, running on a		The basic idea embodied in LISP+ALT is to use BGP, running on a
	tunneled overlay network (the ALT), to establish reachability between		tunneled overlay network (the ALT), to establish reachability between
	ALT Routers. The ALT BGP Route Information Base (RIB) is comprised		ALT Routers. The ALT BGP Route Information Base (RIB) is comprised
	of EID-prefixes and associated next hops. ALT Routers interconnect		of EID-prefixes and associated next hops. ALT Routers interconnect
	using BGP and propagate EID-prefix updates among themselves. EID-		using BGP and propagate EID-prefix updates among themselves. EID-
	prefix information is learned from ETRs at the "edge" of the ALT		prefix information is learned from ETRs at the "edge" of the ALT
	either through the use of the Map Server interface (the commmon		either through the use of the Map Server interface (the commmon
	case), static configuration, or by BGP-speaking ETRs.		case), static configuration, or by BGP-speaking ETRs.
	An ITR uses the ALT to learn the best path for forwarding an ALT		Map Resolvers learns paths through the ALT to Map Servers for EID-
	Datagram destined to a particular EID-prefix. An ITR will normally		prefixes. An ITR will normally use a Map Resolver to send its ALT
	use a Map Resolver to send its ALT Datagrams on to the ALT but may,		Datagrams on to the ALT but may, in unusual cases (see
	in unusual circumstances, use a static ALT Default Route or connect		Section 3.1.2), use a static ALT Default Route or connect to the ALT
	to the ALT using BGP.		using BGP. Likewise, an ETR will normally register its prefixes in
			the mapping database using a Map Server can sometimes (see
			Section 3.1.1) connect directly to the ALT using BGP. See [LISP-MS]
			for details on Map Servers and Map Resolvers.
	Note that while this document specifies the use of Generic Routing		Note that while this document specifies the use of Generic Routing
	Encapsulation (GRE) as a tunneling mechanism, there is no reason that		Encapsulation (GRE) as a tunneling mechanism, there is no reason that
	parts of the ALT cannot be built using other tunneling technologies,		parts of the ALT cannot be built using other tunneling technologies,
	particularly in cases where GRE does not meet security, management,		particularly in cases where GRE does not meet security, management,
	or other operational requirements. References to "GRE tunnel" in		or other operational requirements. References to "GRE tunnel" in
	later sections of this document should therefore not be taken as		later sections of this document should therefore not be taken as
	prohibiting or precluding the use of other tunneling mechanisms.		prohibiting or precluding the use of other tunneling mechanisms.
	Note also that two ALT Routers that are directly adjacent (with no		Note also that two ALT Routers that are directly adjacent (with no
	layer-3 router hops between them) need not use a tunnel between them;		layer-3 router hops between them) need not use a tunnel between them;
	skipping to change at page 13, line 50		skipping to change at page 14, line 7
	Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.		Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.
	Map-Requests and Data Probes (if supported). Given the relatively		Map-Requests and Data Probes (if supported). Given the relatively
	low performance expected of a tunneled topology, ALT Routers (and Map		low performance expected of a tunneled topology, ALT Routers (and Map
	Resolvers) should aggressively rate-limit the ingress of ALT		Resolvers) should aggressively rate-limit the ingress of ALT
	Datagrams from ITRs and, if possible, should be configured to not		Datagrams from ITRs and, if possible, should be configured to not
	accept packets that are not ALT Datagrams.		accept packets that are not ALT Datagrams.
	4.2. EID Assignment - Hierarchy and Topology		4.2. EID Assignment - Hierarchy and Topology
	EID-prefixes are expected to be allocated to a LISP site by Internet		The ALT database is organized in a herarchical manner with EID-
	Registries. Where a site has multiple allocations which are aligned		prefixs aggregated on power-of-2 block boundaries. Where a LISP site
	on a power-of-2 block boundary, they should be aggregated into a		has multiple EID-prefixes that are aligned on apower-of-2 block
	single EID-prefix for advertisement. The ALT network is built in a		boundary, they should be aggregated into a single EID-prefix for
	roughly hierarchical, partial mesh which is intended to allow		advertisement. The ALT network is built in a roughly hierarchical,
	aggregation where clearly-defined hierarchical boundaries exist.		partial mesh which is intended to allow aggregation where clearly-
	Building such a structure should minimize the number of EID-prefixes		defined hierarchical boundaries exist. Building such a structure
	carried by LISP+ALT nodes near the top of the hierarchy.		should minimize the number of EID-prefixes carried by LISP+ALT nodes
			near the top of the hierarchy.
	Routes on the ALT do not need to respond to changes in policy,		Routes on the ALT do not need to respond to changes in policy,
	subscription, or underlying physical connectivity, so the topology		subscription, or underlying physical connectivity, so the topology
	can remain relatively static and aggregation can be sustained.		can remain relatively static and aggregation can be sustained.
	Because routing on the ALT uses BGP, the same rules apply for		Because routing on the ALT uses BGP, the same rules apply for
	generating aggregates; in particular, a ALT Router should only be		generating aggregates; in particular, a ALT Router should only be
	configured to generate an aggregate if it is configured with BGP		configured to generate an aggregate if it is configured with BGP
	sessions to all of the originators of components (more-specific		sessions to all of the originators of components (more-specific
	prefixes) of that aggregate. Not all of the components of need to be		prefixes) of that aggregate. Not all of the components of need to be
	present for the aggregate to be originated (some may be holes in the		present for the aggregate to be originated (some may be holes in the
	skipping to change at page 22, line 4		skipping to change at page 22, line 4
	There are major open questions regarding how the ALT will be deployed		There are major open questions regarding how the ALT will be deployed
	and what organization(s) will operate it. In a simple, non-		and what organization(s) will operate it. In a simple, non-
	distributed world, centralized administration of EID prefix		distributed world, centralized administration of EID prefix
	assignment and ALT network design would facilitate a well- aggregated		assignment and ALT network design would facilitate a well- aggregated
	ALT routing system. Business and other realities will likely result		ALT routing system. Business and other realities will likely result
	in a more complex, distributed system involving multiple levels of		in a more complex, distributed system involving multiple levels of
	prefix delegation, multiple operators of parts of the ALT		prefix delegation, multiple operators of parts of the ALT
	infrastructure, and a combination of competition and cooperation		infrastructure, and a combination of competition and cooperation
	among the participants. In addition, re-use of existing IP address		among the participants. In addition, re-use of existing IP address
	assignments, both "PI" and "PA", to avoid renumbering when sites		assignments, both provider-independent ("PI") and provider-assigned
	transition to LISP will further complicate the processes of building		("PA"), to avoid renumbering when sites transition to LISP will
	and operating the ALT.		further complicate the processes of building and operating the ALT.
	A number of conflicting considerations need to be kept in mind when		A number of conflicting considerations need to be kept in mind when
	designing and building the ALT. Among them are:		designing and building the ALT. Among them are:
	1. Target ALT routing state size and level of aggregation. As		1. Target ALT routing state size and level of aggregation. As
	described in Section 7.1, the ALT should not suffer from some of		described in Section 7.1, the ALT should not suffer from some of
	the performance constraints or stability issues as the Internet		the performance constraints or stability issues as the Internet
	global routing system, so some reasonable level of deaggregation		global routing system, so some reasonable level of deaggregation
	and increased number of EID prefixes beyond what might be		and increased number of EID prefixes beyond what might be
	considered ideal should be acceptable. That said, measures, such		considered ideal should be acceptable. That said, measures, such
	skipping to change at page 26, line 18		skipping to change at page 26, line 18
	security mechanisms are comprised of existing technologies in wide		security mechanisms are comprised of existing technologies in wide
	operational use today, so securing the ALT should be mostly a matter		operational use today, so securing the ALT should be mostly a matter
	of applying the same technology that is used to secure the BGP-based		of applying the same technology that is used to secure the BGP-based
	global routing system (see Section 10.3 below).		global routing system (see Section 10.3 below).
	10.1. Apparent LISP+ALT Vulnerabilities		10.1. Apparent LISP+ALT Vulnerabilities
	This section briefly lists the known potential vulnerabilities of		This section briefly lists the known potential vulnerabilities of
	LISP+ALT.		LISP+ALT.
	Mapping Integrity: Can an attacker insert bogus mappings to black-		Mapping Integrity: Potential for an attacker to insert bogus
	hole (create Denial-of-Service, or DoS attack) or intercept LISP		mappings to black-hole (create Denial-of-Service, or DoS attack)
	data-plane packets?		or intercept LISP data-plane packets.
	ALT Router Availability: Can an attacker DoS the ALT Routers		ALT Router Availability: Can an attacker DoS the ALT Routers
	connected to a given ETR? If a site's ETR cannot advertise its		connected to a given ETR? If a site's ETR cannot advertise its
	EID-to-RLOC mappings, the site is essentially unavailable.		EID-to-RLOC mappings, the site is essentially unavailable.
	ITR Mapping/Resources: Can an attacker force an ITR or ALT Router to		ITR Mapping/Resources: Can an attacker force an ITR or ALT Router to
	drop legitimate mapping requests by flooding it with random		drop legitimate mapping requests by flooding it with random
	destinations for which it will generate large numbers of Map-		destinations for which it will generate large numbers of Map-
	Requests and fill its mapping cache? Further study is required to		Requests and fill its mapping cache? Further study is required to
	see the impact of admission control on the overlay network.		see the impact of admission control on the overlay network.
	skipping to change at page 27, line 7		skipping to change at page 27, line 7
	prepared to rate-limit traffic (ALT Datagrams) that could be		prepared to rate-limit traffic (ALT Datagrams) that could be
	received across the ALT.		received across the ALT.
	UDP Map-Reply from ETR: Since Map-Replies are sent directly from the		UDP Map-Reply from ETR: Since Map-Replies are sent directly from the
	ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various		ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various
	types of DoS attacks (this is a general property of LISP, not an		types of DoS attacks (this is a general property of LISP, not an
	LISP+ALT vulnerability).		LISP+ALT vulnerability).
	More-specific prefix leakage: Because EID-prefixes on the ALT are		More-specific prefix leakage: Because EID-prefixes on the ALT are
	expected to be fairly well-aggregated and EID-prefixes propagated		expected to be fairly well-aggregated and EID-prefixes propagated
	out to the global Internet (see [LISP-IW] much more so, accidental		out to the global Internet (see [LISP-IW]) much more so,
	leaking or malicious advertisement of an EID-prefix into the		accidental leaking or malicious advertisement of an EID-prefix
	global routing system could cause traffic redirection away from a		into the global routing system could cause traffic redirection
	LISP site. This is not really a new problem, though, and its		away from a LISP site. This is not really a new problem, though,
	solution can only be achieved by much more strict prefix filtering		and its solution can only be achieved by much more strict prefix
	and authentication on the global routing system.		filtering and authentication on the global routing system.
			Section Section 10.3 describes an existingapproach to solving this
			problem.
	10.2. Survey of LISP+ALT Security Mechanisms		10.2. Survey of LISP+ALT Security Mechanisms
	Explicit peering: The devices themselves can both prioritize		Explicit peering: The devices themselves can both prioritize
	incoming packets, as well as potentially do key checks in hardware		incoming packets, as well as potentially do key checks in hardware
	to protect the control plane.		to protect the control plane.
	Use of TCP to connect elements: This makes it difficult for third		Use of TCP to connect elements: This makes it difficult for third
	parties to inject packets.		parties to inject packets.
	Use of HMAC Protected BGP/TCP Connections: HMAC is used to verify		Use of HMAC to protect BGP/TCP connections: HMAC [RFC5925] is used
	message integrity and authenticity, making it nearly impossible		to verify the integrity and authenticity of TCP connections used
	for third party devices to either insert or modify messages.		to exchange BGP messages, making it nearly impossible for third
			party devices to either insert or modify messages.
	Message Sequence Numbers and Nonce Values in Messages: This allows		Message sequence numbers and nonce values in messages: This allows
	an ITR to verify that the Map-Reply from an ETR is in response to		an ITR to verify that the Map-Reply from an ETR is in response to
	a Map-Request originated by that ITR (this is a general property		a Map-Request originated by that ITR (this is a general property
	of LISP; LISP+ALT does not change this behavior).		of LISP; LISP+ALT does not change this behavior).
	10.3. Use of new IETF standard BGP Security mechanisms		10.3. Use of new IETF standard BGP Security mechanisms
	LISP+ALT's use of BGP allows the ALT to take advantage of BGP		LISP+ALT's use of BGP allows it to take advantage of BGP security
	security features designed for existing Internet BGP use. Should the		features designed for existing Internet BGP use. This means that
	Internet community converge on the work currently being done in the		LISP+ALT can and should use technology developed for adding security
	IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr]		to BGP (in the IETF SIDR working group or elsewhere) to provide
	or soBGP [I-D.white-sobgparchitecture] be implemented and widely-
	deployed, LISP+ALT can readily use these mechanisms to provide
	authentication of EID-prefix origination and EID-to-RLOC mappings.		authentication of EID-prefix origination and EID-to-RLOC mappings.
	11. Acknowledgments		11. Acknowledgments
	The authors would like to specially thank J. Noel Chiappa who was a		The authors would like to specially thank J. Noel Chiappa who was a
	key contributer to the design of the LISP-CONS mapping database (many		key contributer to the design of the LISP-CONS mapping database (many
	ideas from which made their way into LISP+ALT) and who has continued		ideas from which made their way into LISP+ALT) and who has continued
	to provide invaluable insight as the LISP effort has evolved. Others		to provide invaluable insight as the LISP effort has evolved. Others
	who have provided valuable contributions include John Zwiebel, Hannu		who have provided valuable contributions include John Zwiebel, Hannu
	Flinck, Amit Jain, John Scudder, Scott Brim, and Jari Arkko.		Flinck, Amit Jain, John Scudder, Scott Brim, and Jari Arkko.
	skipping to change at page 29, line 15		skipping to change at page 29, line 15
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-15.txt (work in progress), July 2011.		draft-ietf-lisp-15.txt (work in progress), July 2011.
	[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",		[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",
	draft-ietf-lisp-ms-12.txt (work in progress),		draft-ietf-lisp-ms-12.txt (work in progress),
	September 2011.		October 2011.
	[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.		[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
	Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,		Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
	March 2000.		March 2000.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, August 2006.		Plan", BCP 122, RFC 4632, August 2006.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760,
	January 2007.		January 2007.
	12.2. Informative References		12.2. Informative References
	[I-D.murphy-bgp-secr]
	Murphy, S., "BGP Security Analysis",
	draft-murphy-bgp-secr-04 (work in progress),
	November 2001.
	[I-D.white-sobgparchitecture]
	White, R., "Architecture and Deployment Considerations for
	Secure Origin BGP (soBGP)",
	draft-white-sobgparchitecture-00 (work in progress),
	May 2004.
	[LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		[LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking LISP with IPv4 and ipv6",		"Interworking LISP with IPv4 and ipv6",
	draft-ietf-lisp-interworking-02.txt (work in progress),		draft-ietf-lisp-interworking-02.txt (work in progress),
	March 2011.		March 2011.
			[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
			Authentication Option", RFC 5925, June 2010.
	Authors' Addresses		Authors' Addresses
	Vince Fuller		Vince Fuller
	Cisco		Cisco
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: vaf@cisco.com		Email: vaf@cisco.com
End of changes. 20 change blocks.
	60 lines changed or deleted		52 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/