< draft-ietf-geopriv-l7-lcp-ps-01.txt		draft-ietf-geopriv-l7-lcp-ps-02.txt >
	Network Working Group H. Tschofenig		Network Working Group H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Informational H. Schulzrinne		Intended status: Informational H. Schulzrinne
	Expires: October 8, 2007 Columbia U.		Expires: October 30, 2007 Columbia U.
	April 6, 2007		April 28, 2007
	GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and		GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
	Requirements		Requirements
	draft-ietf-geopriv-l7-lcp-ps-01.txt		draft-ietf-geopriv-l7-lcp-ps-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 8, 2007.		This Internet-Draft will expire on October 30, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document provides a problem statement, lists requirements and		This document provides a problem statement, lists requirements and
	captures discussions for a GEOPRIV Layer 7 Location Configuration		captures design aspects for a Geopriv Layer 7 Location Configuration
	Protocol (LCP). This protocol aims to allow an end host to obtain		Protocol L7 (LCP). This protocol aims to allow an end host to obtain
	location information, by value or by reference, from a Location		location information, by value or by reference, from a Location
	Server (LS) that is located in the access network. The obtained		Configuration Server (LCS) that is located in the access network.
	location information can then be used for a variety of different		The obtained location information can then be used for a variety of
	protocols and purposes. For example, it can be used as input to the		different protocols and purposes. For example, it can be used as
	Location-to-Service Translation Protocol (LoST) or to convey location		input to the Location-to-Service Translation Protocol (LoST) or to
	within SIP to other entities.		convey location within SIP to other entities.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5		3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5
	3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9		3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9
	4. Discovery of the Location Information Server . . . . . . . . . 11		4. Discovery of the Location Configuration Server . . . . . . . . 11
	5. Identifier for Location Determination . . . . . . . . . . . . 13		5. Identifier for Location Determination . . . . . . . . . . . . 13
	6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17		6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 23		11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	11.2. Informative References . . . . . . . . . . . . . . . . . . 23		11.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . . . 26		Intellectual Property and Copyright Statements . . . . . . . . . . 25
	1. Introduction		1. Introduction
	This document provides a problem statement, lists requirements and		This document provides a problem statement, lists requirements and
	captures discussions for a GEOPRIV Layer 7 Location Configuration		captures design aspects for a Geopriv Layer 7 Location Configuration
	Protocol (LCP). The protocol has two purposes:		Protocol L7 (LCP). The protocol has two purposes:
	o It is used to obtain location information from a special node,		o It is used to obtain location information (referred as "Location
	called the Location Server (LS).		by Value" or LbyV) from a dedicated node, called the Location
			Configuration Server (LCS).
	o It enables the end host to obtain a reference to location		o It enables the Target to obtain a reference to location
	information. This reference can take the form of a subscription		information (referred as "Location by Reference" or LbyR). This
	URI, such as a SIP presence URI, an HTTP/HTTPS URI, or any others.		reference can take the form of a subscription URI, such as a SIP
	The requirements related to the task of obtaining such a reference		presence URI, a HTTP/HTTPS URI, or another URI. The requirements
	are described in a separate document, see [4].		related to the task of obtaining a LbyR are described in a
			separate document, see [4].
	The need for these two functions can be derived from the scenarios		The need for these two functions can be derived from the scenarios
	presented in Section 3.		presented in Section 3.
	For this document we assume that the GEOPRIV Layer 7 LCP runs between		For this document we assume that the GEOPRIV Layer 7 LCP runs between
	the end host (i.e., the Target in [1] terminology) acting as the LCP		the end host (i.e., the Target in [1] terminology) acting as the LCP
	client and the Location Server acting as an LCP server.		client and the Location Configuration Server acting as an LCP server.
	This document splits the problem space into separate parts and		This document is structured as follows. Section 4 discusses the
	discusses them in separate subsections. Section 4 discusses the		challenge of discovering the LCS in the access network. Section 5
	challenge of discovering the Location Information Server in the		compares different types of identifiers that can be used to retrieve
	access network. Section 5 compares different types of identifiers		location information. A list of requirements for the L7 LCP can be
	that can be used to retrieve location information. A list of		found in Section 6.
	requirements for the GEOPRIV Layer 7 Location Configuration Protocol
	can be found in Section 6.
	This document does not describe how the access network provider		This document does not describe how the access network provider
	determines the location of the end host since this is largely a		determines the location of the end host since this is largely a
	matter of the capabilities of specific link layer technologies.		matter of the capabilities of specific link layer technologies or
			certain deployment environments.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [2],		and "OPTIONAL" are to be interpreted as described in RFC 2119 [2],
	with the qualification that unless otherwise stated these words apply		with the qualification that unless otherwise stated these words apply
	to the design of the GEOPRIV Layer 7 Location Configuration Protocol.		to the design of the GEOPRIV Layer 7 Location Configuration Protocol.
	We also use terminology from [1] and [3].		The term Location Configuration Server (LCS) refers to an entity
			capable of determining the location of the Target and of delivering
			that location information, a reference to it, or bot) to the Target
			via the L7 LCP.
			This document also uses terminology from [1] and [3].
	3. Scenarios		3. Scenarios
	This section describes a few network scenarios where the GEOPRIV		This section describes a few network scenarios where the L7 LCP may
	Layer 7 Location Configuration Protocol may be used. Note that this		be used. Note that this section does not aim to exhaustively list
	section does not aim to list all possible deployment environments		all possible deployment environments. Instead we focus on the
	exhaustively. We focus on the description of the following		following environments:
	environments:
	o DSL/Cable networks, WiMax-like fixed access		o DSL/Cable networks, WiMax-like fixed access
	o Airport, City, Campus Wireless Networks, such as 802.11a/b/g,		o Airport, City, Campus Wireless Networks, such as 802.11a/b/g,
	802.16e/Wimax		802.16e/Wimax
	o 3G networks		o 3G networks
	o Enterprise networks		o Enterprise networks
	We illustrate a few examples below.		We illustrate a few examples below.
	3.1. Fixed Wired Environment		3.1. Fixed Wired Environment
	The following figure shows a DSL network scenario with the Access		Figure 1 shows a DSL network scenario with the Access Network
	Network Provider and the customer premises. The Access Network		Provider and the customer premises. The Access Network Provider
	Provider operates link and network layer devices (represented as		operates link and network layer devices (represented as Node) and the
	Node) and the Location Server (LS).		LCS.
	+---------------------------+		+---------------------------+
	| |		| |
	| Access Network Provider |		| Access Network Provider |
	| |		| |
	| +--------+ |		| +--------+ |
	| | Node | |		| | Node | |
	| +--------+ +----------+ |		| +--------+ +----------+ |
	| | | | LS | |		| | | | LCS | |
	| | +---| | |		| | +---| | |
	| | +----------+ |		| | +----------+ |
	| | |		| | |
	+-------+-------------------+		+-------+-------------------+
	| Wired Network		| Wired Network
	<----------------> Access Network Provider demarc		<----------------> Access Network Provider demarc
	|		|
	+-------+-------------------+		+-------+-------------------+
	| | |		| | |
	| +-------------+ |		| +-------------+ |
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 18 ¶
	the same box, or for there to be no home router, or for the NTE and		the same box, or for there to be no home router, or for the NTE and
	end host to be in the same physical box (with no home router). An		end host to be in the same physical box (with no home router). An
	example of this last case is where Ethernet service is delivered to		example of this last case is where Ethernet service is delivered to
	customers' homes, and the Ethernet NIC in their PC serves as the NTE.		customers' homes, and the Ethernet NIC in their PC serves as the NTE.
	Current Customer Premises Network (CPN) deployments frequently show		Current Customer Premises Network (CPN) deployments frequently show
	the following characteristics:		the following characteristics:
	1. CPE = Single PC		1. CPE = Single PC
	1. with Ethernet NIC [PPPoE or DHCP on PC]; there may be a		1. with Ethernet NIC (PPPoE or DHCP on PC); there may be a
	bridged DSL or cable modem as NTE, or the Ethernet NIC might		bridged DSL or cable modem as NTE, or the Ethernet NIC might
	be the NTE		be the NTE
	2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC]		2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC]
	Note that the device with NAPT and DHCP of Figure 1 is not		Note that the device with NAPT and DHCP of Figure 1 is not
	present in such a scenario.		present in such a scenario.
	2. One or more hosts with at least one router [DHCP Client or PPPoE,		2. One or more hosts with at least one router (DHCP Client or PPPoE,
	DHCP server in router; VoIP can be soft client on PC, stand-alone		DHCP server in router; VoIP can be soft client on PC, stand-alone
	VoIP device, or Analog Terminal Adaptor (ATA) function embedded		VoIP device, or Analog Terminal Adaptor (ATA) function embedded
	in router]		in router)
	1. combined router and NTE		1. combined router and NTE
	2. separate router with NTE in bridged mode		2. separate router with NTE in bridged mode
	3. separate router with NTE [NTE/router does PPPoE or DHCP to		3. separate router with NTE (NTE/router does PPPoE or DHCP to
	WAN, router provides DHCP server for hosts in LAN; double NAT		WAN, router provides DHCP server for hosts in LAN; double
			NAT)
	The majority of fixed access broadband customers use a router. The		The majority of fixed access broadband customers use a router. The
	placement of the VoIP client is mentioned to describe what sorts of		placement of the VoIP client is mentioned to describe what sorts of
	hosts may need to be able to request location information. Soft		hosts may need to be able to request location information. Soft
	clients on PCs are frequently not launched until long after bootstrap		clients on PCs are frequently not launched until long after bootstrap
	is complete, and are not able to control any options that may be		is complete, and are not able to control any options that may be
	specified during bootstrap. They also cannot control whether a VPN		specified during bootstrap. They also cannot control whether a VPN
	client is operating on the PC.		client is running on the end host.
	3.2. Moving Network		3.2. Moving Network
	An example of a moving network is a "WIMAX-like fixed wireless"		An example of a moving network is a "WIMAX-like fixed wireless"
	scenario that is offered in several cities, like New Orleans, Biloxi,		scenario that is offered in several cities, like New Orleans, Biloxi,
	etc., where much of the communications infrastructure was destroyed		etc., where much of the communications infrastructure was destroyed
	due to a natural disaster. The customer-side antenna for this		due to a natural disaster. The customer-side antenna for this
	service is rather small (about the size of a mass market paperback		service is rather small (about the size of a mass market paperback
	book) and can be run off battery power. The output of this little		book) and can be run off battery power. The output of this little
	antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this		antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this
	skipping to change at page 8, line 23 ¶		skipping to change at page 8, line 24 ¶
	the core network, and from there to the same BRASs that serve regular		the core network, and from there to the same BRASs that serve regular
	DSL customers. These Broadband Remote Access Servers (BRASs)		DSL customers. These Broadband Remote Access Servers (BRASs)
	terminate the PPPoE sessions, just like they do for regular DSL.		terminate the PPPoE sessions, just like they do for regular DSL.
	The laptop and SIP client are, in this case, unaware that they are		The laptop and SIP client are, in this case, unaware that they are
	"mobile". All they see is an Ethernet connection, and the IP address		"mobile". All they see is an Ethernet connection, and the IP address
	they get from PPPoE does not change over the coverage area. Only the		they get from PPPoE does not change over the coverage area. Only the
	user and the network are aware of the laptop's mobility.		user and the network are aware of the laptop's mobility.
	Further examples of moving networks can be found in busses, trains,		Further examples of moving networks can be found in busses, trains,
	airplanes.		and airplanes.
	Figure 2 shows an example topology for a moving network.		Figure 2 shows an example topology for a moving network.
	+--------------------------+		+--------------------------+
	| Wireless |		| Wireless |
	| Access Network Provider |		| Access Network Provider |
	| |		| |
	| +----------+|		| +----------+|
	| +-------+ LS ||		| +-------+ LCS ||
	| | | ||		| | | ||
	| +---+----+ +----------+|		| +---+----+ +----------+|
	| | Node | |		| | Node | |
	| | | |		| | | |
	| +---+----+ |		| +---+----+ |
	| | |		| | |
	+------+-------------------+		+------+-------------------+
	| Wireless Interface		| Wireless Interface
	|		|
	+------+-------------------+		+------+-------------------+
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	|| A | \+ B | |		|| A | \+ B | |
	|+--------+ +--------+ |		|+--------+ +--------+ |
	+--------------------------+		+--------------------------+
	Figure 2: Moving Network		Figure 2: Moving Network
	3.3. Wireless Access		3.3. Wireless Access
	Figure 3 shows a wireless access network where a moving end host		Figure 3 shows a wireless access network where a moving end host
	obtains location information or references to location information		obtains location information or references to location information
	from the LS. The access equipment uses, in many cases, link layer		from the LCS. The access equipment uses, in many cases, link layer
	devices. This figure represents a hotspot network found in hotels,		devices. Figure 3 represents a hotspot network found, for example,
	airports, coffee shops. For editorial reasons we only describe a		in hotels, airports, and coffee shops. For editorial reasons we only
	single access point and do not depict how the LS obtains location		describe a single access point and do not depict how the LCS obtains
	information since this is very deployment specific.		location information since this is very deployment specific.
	+--------------------------+		+--------------------------+
	| Access Network Provider |		| Access Network Provider |
	| |		| |
	| +----------+|		| +----------+|
	| +-------| LS ||		| +-------| LC ||
	| | | ||		| | | ||
	| +--------+ +----------+|		| +--------+ +----------+|
	| | Access | |		| | Access | |
	| | Point | |		| | Point | |
	| +--------+ |		| +--------+ |
	| | |		| | |
	+------+-------------------+		+------+-------------------+
	|		|
	+------+		+------+
	| End |		| End |
	| Host |		| Host |
	+------+		+------+
	Figure 3: Wireless Access Scenario		Figure 3: Wireless Access Scenario
	4. Discovery of the Location Information Server		4. Discovery of the Location Configuration Server
	When an end host wants to retrieve location information from the LS		When a Target wants to retrieve location information from the LCS it
	it first needs to discover it. Based on the problem statement of		first needs to discover it. Based on the problem statement of
	determining the location of the end host, which is known best by		determining the location of the Target, which is known best by
	entities close to the end host itself, we assume that the LS is		entities close to the Target itself, we assume that the LCS is
	located in the access network. Several procedures have been		located in the access network. Several procedures have been
	investigated that aim to discovery the LS in such an access network.		investigated that aim to discovery the LCS in such an access network.
	DHCP-based Discovery:		DHCP-based Discovery:
	In some environments the Dynamic Host Configuration Protocol might		In some environments the Dynamic Host Configuration Protocol
	be a good choice for discovering the FQDN or the IP address of the		(DHCP) might be a good choice for discovering the FQDN or the IP
	LS. In environments where DHCP can be used it is also possible to		address of the LCS. In environments where DHCP can be used it is
	use the already defined location extensions. In environments with		also possible to use the already defined location extensions. In
	legacy devices, such as the one shown in Section 3.1, a DHCP based		environments with legacy devices, such as the one shown in
	discovery solution is not possible.		Section 3.1, a DHCP based discovery solution may not be possible.
	DNS-based Discovery:		DNS-based Discovery:
	With this idea the end host obtains its public IP address (e.g.,		With this idea the end host obtains its public IP address (e.g.,
	via STUN [5]) in order to obtain its domain name (via the usual		via STUN [5]) in order to obtain its domain name (via the usual
	reverse DNS lookup). Then, the SRV or NAPTR record for that		reverse DNS lookup). Then, the SRV or NAPTR record for that
	domain is retrieved. This relies on the user's public IP address		domain is retrieved. This relies on the user's public IP address
	having a DNS entry.		having a DNS entry.
	Redirect Rule:		Redirect Rule:
	A redirect rule at a device in the access network, for example at		A redirect rule at a device in the access network, for example at
	the AAA client, will be used to redirect the Geopriv-L7 signalling		the AAA client, will be used to redirect the L7 LCP signalling
	messages (destined to a specific port) to the LS. The end host		messages (destined to a specific port) to the LCS. The end host
	could then discover the LS by sending a packet to almost any		could then discover the LCS by sending a packet to almost any
	address (as long it is not in the local network). The packet		address (as long it is not in the user's home network behind a
	would be redirected to the respective LS being configured. The		NAT). The packet would be redirected to the respective LCS being
	same procedure is used by captive portals whereby any HTTP traffic		configured. The same procedure is used by captive portals whereby
	is intercepted and redirected.		any HTTP traffic is intercepted and redirected.
	Multicast Query:		Multicast Query:
	An end node could also discover a LS by sending a multicast		An end node could also discover a LCS by sending a multicast
	request to a well-known address. An example of such a mechanism		request to a well-known address. An example of such a mechanism
	is multicast DNS (see [6] and [7]).		is multicast DNS (see [6] and [7]).
	The LS discovery procedure raises deployment and security issues.		The LCS discovery procedure raises deployment and security issues.
	When an end host discovers a LS,		When an end host discovers a LCS it must be ensured that
	1. it does not talk to a man-in-the-middle adversary, and		1. it does not talk to a man-in-the-middle, and
	2. it needs to ensure that the discovered entity is indeed an		2. that the discovered entity is indeed an authorized LCS.
	authorized LS.
	5. Identifier for Location Determination		5. Identifier for Location Determination
	The LS returns location information to the end host when it receives		The LCS returns location information to the end host when it receives
	a request. Some form of identifier is therefore needed to allow the		a request. Some form of identifier is therefore needed to allow the
	LS to determine the current location of the target or a good		LCS to retrieve the Target's current location (or a good
	approximation of it.		approximation of it) from a database.
	The chosen identifier needs to have the following properties:		The chosen identifier needs to have the following properties:
	Ability for end host to learn or know the identifier:		Ability for Target to learn or know the identifier:
	The end host MUST know or MUST be able to learn the identifier		The Target MUST know or MUST be able to learn the identifier
	(explicitly or implicitly) in order to send it to the LS.		(explicitly or implicitly) in order to send it to the LCS.
	Implicitly refers to the situation where a device along the path		Implicitly refers to the situation where a device along the path
	between the end host and the LS modifies the identifier, as it is		between the end host and the LCS modifies the identifier, as it is
	done by a NAT when an IP address based identifier is used.		done by a NAT when an IP address based identifier is used.
	Ability to use the identifier for location determination:		Ability to use the identifier for location determination:
	The LS MUST be able to use the identifier (directly or indirectly)		The LCS MUST be able to use the identifier (directly or
	for location determination. Indirectly refers to the case where		indirectly) for location determination. Indirectly refers to the
	the LS uses other identifiers locally within the access network,		case where the LCS uses other identifiers internally for location
	in addition to the one provided by the end host, for location		determination, in addition to the one provided by the Target.
	determination.
	Security properties of the identifier:		Security properties of the identifier:
	Misuse needs to be minimized whereby off-path adversary MUST NOT		Misuse needs to be minimized whereby off-path adversary MUST NOT
	be able to obtain location information of other hosts. A on-path		be able to obtain location information of other Targets. A on-
	adversary in the same subnet SHOULD NOT be able to spoof the		path adversary in the same subnet SHOULD NOT be able to spoof the
	identifier of another host in the same subnet.		identifier of another Target in the same subnet.
	The problem is further complicated by the requirement that the end
	host should not be aware of the network topology and the LS must be
	placed in such a way that it can determine location information with
	the available information. As shown in Figure 1 the host behind the
	NTE/NAPT-DHCP device is not visible to the access network and the LS
	itself. In the DSL network environment some identifier used at the
	NTE is observable for by the LS/access network.
	The following list discusses frequently mentioned identifiers and		The following list discusses frequently mentioned identifiers and
	their properties:		their properties:
	Host MAC address:		Host MAC Address:
	The host MAC address is known to the end system, but not carried		The Target's MAC address is known to the end host, but not carried
	over an IP hop.		over an IP hop and therefore not accessible to the LCS in most
			deployment environments (unless carried in the L7 LCP itself).
	ATM VCI/VPI:		ATM VCI/VPI:
	The VPI/VCI is generally only seen by the DSL modem. Almost all		The VPI/VCI is generally only seen by the DSL modem. Almost all
	routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35.		routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35.
	This VC is terminated at the DSLAM, which uses a different VPI/VCI		This VC is terminated at the DSLAM, which uses a different VPI/VCI
	(per end customer) to connect to the ATM switch. Only the network		(per end customer) to connect to the ATM switch. Only the network
	provider is able to map VPI/VCI values through its network. With		provider is able to map VPI/VCI values through its network. With
	the arrival of VDSL, ATM will slowly be phased out in favor of		the arrival of VDSL, ATM will slowly be phased out in favor of
	Ethernet.		Ethernet.
	Switch/Port Number:		Switch/Port Number:
	This identifier is available only in certain networks, such as		This identifier is available only in certain networks, such as
	enterprise networks, typically available via proprietary protocols		enterprise networks, typically available via proprietary protocols
	like CDP or, in the future, 802.1ab.		like CDP or, in the future, 802.1ab.
	Cell ID:		Cell ID:
	This identifier is available in cellular data networks and the		This identifier is available in cellular data networks and the
	cell ID might not be visible to the end host.		cell ID may not be visible to the end host.
	Authenticated User Identity:
	In DSL networks the user credentials are, in many cases, only
	known by the router and not to the end host. To the network, the
	authenticated user identity is only available if a network access
	authentication procedure is executed. In case of roaming it still
	might not be available to the access network since security
	protocols might provide user identity confidentiality and thereby
	hide the real identity of the user allowing the access network to
	only see a pseudonym or a randomized string.
	Host Identifier:		Host Identifier:
	The Host Identifier introduced by the Host Identity Protocol [8]		The Host Identifier introduced by the Host Identity Protocol [8]
	allows identification of a particular host. Unfortunately, the		allows identification of a particular host. Unfortunately, the
	network can only use this identifier for location determination if		network can only use this identifier for location determination if
	the operator already stores an mapping of host identities to		the operator already stores an mapping of host identities to
	location information. Furthermore, there is a deployment problem		location information. Furthermore, there is a deployment problem
	since the host identities are not used in todays networks.		since the host identities are not used in todays networks.
	Cryptographically Generated Address (CGA):		Cryptographically Generated Address (CGA):
	The concept of a Cryptographically Generated Address (CGA) was		The concept of a Cryptographically Generated Address (CGA) was
	introduced by [9]. The basic idea is to put the truncated hash of		introduced by [9]. The basic idea is to put the truncated hash of
	a public key into the interface identifier part of an IPv6		a public key into the interface identifier part of an IPv6
	address. In addition to the properties of an IP address it allows		address. In addition to the properties of an IP address it allows
	a proof of ownership. Hence, a return routability check can be		a proof of ownership. Hence, a return routability check can be
	omitted.		omitted. It is only available for IPv6 addresses.
	Network Access Identifiers:		Network Access Identifiers:
	A Network Access Identifier [10] is only used during the network		A Network Access Identifier [10] is used during the network access
	access authentication procedure in RADIUS [11] or Diameter [12].		authentication procedure, for example in RADIUS [11] and Diameter
	Furthermore, in a roaming scenario it does not help the access		[12]. In DSL networks the user credentials are, in many cases,
	network to make meaningful decisions since the username part might		only known by the home router and not configured at the Target
	be a pseudonym and there is no relationship to the end host's		itself. To the network, the authenticated user identity is only
	location.		available if a network access authentication procedure is
			executed. In case of roaming the user's identity might not be
			available to the access network since security protocols might
			offer user identity confidentiality and thereby hiding the real
			identity of the user allowing the access network to only see a
			pseudonym or a randomized string.
	Unique Client Identifier		Unique Client Identifier
	The DSL Forum has defined that all devices that expect to be		The DSL Forum has defined that all devices that expect to be
	managed by the TR-069 interface be able to generate an identifier		managed by the TR-069 interface be able to generate an identifier
	as described in DSL Forum TR-069v2 Section 3.4.4. It also has a		as described in Section 3.4.4 of the TR-069v2 DSL Forum document.
	requirement that routers that use DHCP to the WAN use RFC 4361		It also has a requirement that routers that use DHCP to the WAN
	[13] to provide the DHCP server with a unique client identifier.		use RFC 4361 [13] to provide the DHCP server with a unique client
	This identifier is, however, not visible to the end host with the		identifier. This identifier is, however, not visible to the
	assumption of a legacy device like the NTE. If we assume that the		Target when legacy NTE device are used.
	LTE can be modified then a number of solutions come to mind
	including DHCP based location delivery.
	IP Address:		IP Address:
	The end host's IP address may be used for location determination.		The Target's IP address may be used for location determination.
	This IP address is not visible to the LS if the end host is behind		This IP address is not visible to the LCS if the end host is
	one or multipel NATs. This is, however, not a problem since the		behind one or multiple NATs. This may not be a problem since the
	location of a host that is located behind a NAT cannot be		location of a host that is located behind a NAT cannot be
	determined by the access network. The LS would in this case only		determined by the access network. The LCS would in this case only
	see the public IP address of the NAT binding allocated by the NAT,		see the public IP address of the NAT binding allocated by the NAT,
	which is the correct behavior. The property of the IP address for		which is the expected behavior. The property of the IP address
	a return routability check is attractive as well to return		for a return routability check is attractive to return location
	location information only to a device that transmitted the		information only to the address that submitted the request. If an
	request. The LS receives the request and provides location		adversary wants to learn the location of a Target (as identified
	information back to the same IP address. If an adversary wants to		by a particular IP address) then it does not see the response
	learn location information from an IP address other than its own		message (unless he is on the subnetwork or at a router along the
	IP address then it would not see the response message (unless he		path towards the LCS).
	is on the subnetwork or at a router along the path towards the LS)
	since the LS would return the message to the address where it came
	from.
	On a shared medium an adversary could ask for location information		On a shared medium an adversary could ask for location information
	of another host using its IP address. The adversary would be able		of another Target. The adversary would be able to see the
	to see the response message since he is sniffing on the shared		response message since it is sniffing on the shared medium unless
	medium unless security mechanisms (such as link layer encryption)		security mechanisms (such as link layer encryption) is in place.
	is in place. With a network deployment as shown in Section 3.1		With a network deployment as shown in Section 3.1 with multiple
	with multiple hosts in the Customer Premise being behind a NAT the		hosts in the Customer Premise being behind a NAT the LCS is unable
	LS is unable to differentiate the individual end points. For WLAN		to differentiate the individual end points. For WLAN deployments
	deployments as found in hotels, as shown in as shown in		as found in hotels, as shown in Section 3.3, it is possible for an
	Section 3.3, it is possible for an adversary to eavesdrop data		adversary to eavesdrop data traffic and subsequently to spoof the
	traffic and subsequently to spoof the IP address in a query to the		IP address in a query to the LCS to learn more detailed location
	LS to learn more detailed location information (e.g., specific		information (e.g., specific room numbers). Such an attack might,
	room numbers). Such an attack might, for example, compromise the		for example, compromise the privacy of hotel guests.
	privacy of hotel guests. Note that DHCP would suffer from the
	same problem here unless each node uses link layer security
	mechanism.
	Return routability checks are useful only if the adversary does
	not see the response message and if the goal is to delay state
	establishment. If the adversary is in a broadcast network then a
	return routability check alone is not sufficient to prevent the
	above attack since the adversary will observe the response.
	6. Requirements		6. Requirements
	The following requirements and assumptions have been identified:		The following requirements and assumptions have been identified:
	Requirement L7-1: Identifier Choice		Requirement L7-1: Identifier Choice
	The LS MUST be presented with a unique identifier of its own		The L7 LCP MUST be able to carry different identifiers or MUST
	addressing realm associated directly or indirectly (i.e., linked		define an identifier that is mandatory to implement. Regarding
	through other identifiers) with the physical location of the end		the latter aspect, such an identifier is only appropriate if it is
	host.		from the same realm as the one for which the location information
			service maintains identifier to location mapping.
	An identifier is only appropriate if it is from the same realm as
	the one for which the location information service maintains
	identifier to location mapping.
	Requirement L7-2: Mobility Support		Requirement L7-2: Mobility Support
	The GEOPRIV Layer 7 Location Configuration Protocol MUST support a		The L7 LCP MUST support a broad range of mobility from devices
	broad range of mobility from devices that can only move between		that can only move between reboots, to devices that can change
	reboots, to devices that can change attachment points with the		attachment points with the impact that their IP address is
	impact that their IP address is changed, to devices that do not		changed, to devices that do not change their IP address while
	change their IP address while roaming, to devices that		roaming, to devices that continuously move by being attached to
	continuously move by being attached to the same network attachment		the same network attachment point.
	point.
	Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship		Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship
	The design of the GEOPRIV Layer 7 Location Configuration Protocol		The design of the L7 LCP MUST NOT assume a business or trust
	MUST NOT assume a business or trust relationship between the		relationship between the VSP and the ISP/ASP. Requirements for
	provider of application layer (e.g., SIP, XMPP, H.323) provider		resolving a reference to location information are not discussed in
	and the access network provider operating the LS.		this document.
	Requirement L7-4: Layer 2 and Layer 3 Provider Relationship		Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
	The design of the GEOPRIV Layer 7 Location Configuration Protocol		The design of the L7 LCP MUST assume that there is a trust and
	MUST assume that there is a trust and business relationship		business relationship between the L2 and the L3 provider. The L3
	between the L2 and the L3 provider. The L3 provider operates the		provider operates the LCS and needs to obtain location information
	LS and needs to obtain location information from the L2 provider		from the L2 provider since this one is closest to the end host.
	since this one is closest to the end host. If the L2 and L3		If the L2 and L3 provider for the same host are different
	provider for the same host are different entities, they cooperate		entities, they cooperate for the purposes needed to determine end
	for the purposes needed to determine end system locations.		system locations.
	Requirement L7-5: Legacy Device Considerations		Requirement L7-5: Legacy Device Considerations
	The design of the GEOPRIV Layer 7 Location Configuration Protocol		The design of the L7 LCP MUST consider legacy devices, such as
	MUST consider legacy residential NAT devices and NTEs in an DSL		residential NAT devices and NTEs in an DSL environment, that
	environment that cannot be upgraded to support additional		cannot be upgraded to support additional protocols, for example,
	protocols, for example to pass additional information through		to pass additional information towards the Target.
	DHCP.
	Requirement L7-6: VPN Awareness		Requirement L7-6: VPN Awareness
	The design of the GEOPRIV Layer 7 Location Configuration Protocol		The design of the L7 LCP MUST assume that at least one end of a
	MUST assume that at least one end of a VPN is aware of the VPN		VPN is aware of the VPN functionality. In an enterprise scenario,
	functionality. In an enterprise scenario, the enterprise side		the enterprise side will provide the LCS used by the client and
	will provide the LS used by the client and can thereby detect		can thereby detect whether the LCS request was initiated through a
	whether the LS request was initiated through a VPN tunnel.		VPN tunnel.
	Requirement L7-7: Network Access Authentication		Requirement L7-7: Network Access Authentication
	The design of the GEOPRIV Layer 7 Location Configuration Protocol		The design of the L7 LCP MUST NOT assume prior network access
	MUST NOT assume prior network access authentication.		authentication.
	Requirement L7-8: Network Topology Unawareness		Requirement L7-8: Network Topology Unawareness
	The design of the GEOPRIV Layer 7 Location Configuration Protocol		The design of the L7 LCP MUST NOT assume end systems being aware
	MUST NOT assume end systems being aware of the access network		of the access network topology. End systems are, however, able to
	topology. End systems are, however, able to determine their		determine their public IP address(es) via mechanisms, such as STUN
	public IP address(es) via mechanisms such as STUN [5] or NSIS		[5] or NSIS NATFW NSLP [14] .
	NATFW NSLP [14] .
	Requirement L7-9: Discovery Mechanism		Requirement L7-9: Discovery Mechanism
	The GEOPRIV Layer 7 Location Configuration Protocol MUST provide a		The L7 LCP MUST define a single mandatory-to-implement discovery
	mandatory-to-implement discovery mechanism.		mechanism.
	7. Security Considerations		7. Security Considerations
	This document addresses security aspect throughout the document.		A discussion about security aspects can be found in another document.
			[Editor's Note: The security related content was previously in this
			document and will be published in a separate document soon.]
	8. IANA Considerations		8. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	9. Contributors		9. Contributors
	This contribution is a joint effort of the GEOPRIV Layer 7 Location		This contribution is a joint effort of the GEOPRIV Layer 7 Location
	Configuration Requirements Design Team of the IETF GEOPRIV Working		Configuration Requirements Design Team of the IETF GEOPRIV Working
	Group. The contributors include Henning Schulzrinne, Barbara Stark,		Group. The contributors include Henning Schulzrinne, Barbara Stark,
	Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson,		Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson,
	Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig.		Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig.
			We would like to thank the GEOPRIV working group chairs, Andy Newton,
			Randy Gellens and Allison Mankin, for creating the design team.
	The design team members can be reached at:		The design team members can be reached at:
	Marc Linsner: mlinsner@cisco.com		Marc Linsner: mlinsner@cisco.com
	Rohan Mahy: rohan@ekabal.com		Rohan Mahy: rohan@ekabal.com
	Andrew Newton: andy@hxr.us		Andrew Newton: andy@hxr.us
	Jon Peterson: jon.peterson@neustar.biz		Jon Peterson: jon.peterson@neustar.biz
	skipping to change at page 23, line 31 ¶		skipping to change at page 22, line 31 ¶
	[4] Marshall, R., "Requirements for a Location-by-Reference		[4] Marshall, R., "Requirements for a Location-by-Reference
	Mechanism used in Location Configuration and Conveyance",		Mechanism used in Location Configuration and Conveyance",
	draft-marshall-geopriv-lbyr-requirements-01 (work in progress),		draft-marshall-geopriv-lbyr-requirements-01 (work in progress),
	March 2007.		March 2007.
	[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN		[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
	- Simple Traversal of User Datagram Protocol (UDP) Through		- Simple Traversal of User Datagram Protocol (UDP) Through
	Network Address Translators (NATs)", RFC 3489, March 2003.		Network Address Translators (NATs)", RFC 3489, March 2003.
	[6] Aboba, B., "Link-local Multicast Name Resolution (LLMNR)",		[6] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
	draft-ietf-dnsext-mdns-47 (work in progress), August 2006.		Name Resolution (LLMNR)", RFC 4795, January 2007.
	[7] Cheshire, S. and M. Krochmal, "Multicast DNS",		[7] Cheshire, S. and M. Krochmal, "Multicast DNS",
	draft-cheshire-dnsext-multicastdns-06 (work in progress),		draft-cheshire-dnsext-multicastdns-06 (work in progress),
	August 2006.		August 2006.
	[8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07		[8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07
	(work in progress), February 2007.		(work in progress), February 2007.
	[9] Aura, T., "Cryptographically Generated Addresses (CGA)",		[9] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
	skipping to change at page 25, line 14 ¶		skipping to change at page 24, line 14 ¶
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Phone: +49 89 636 40390		Phone: +49 89 636 40390
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@nsn.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
End of changes. 64 change blocks.
	225 lines changed or deleted		201 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/