< draft-cao-hip-geolocation-00.txt		draft-cao-hip-geolocation-01.txt >
	HIP F. Cao		HIP F. Cao
	Internet-Draft D. Ward		Internet-Draft Cisco Systems
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track H. Deng
	Expires: April 23, 2009 H. Deng		Expires: April 26, 2009 China Mobile
	China Mobile		October 23, 2008
	October 20, 2008
	Delivering Geographic Location in Host Identity Protocol (HIP)		Delivering Geographic Location in Host Identity Protocol (HIP)
	draft-cao-hip-geolocation-00		draft-cao-hip-geolocation-01
	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 35 ¶
	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 April 23, 2009.		This Internet-Draft will expire on April 26, 2009.
	Abstract		Abstract
	This document defines a new parameter for delivering geographic		This document defines a new parameter for delivering geographic
	location in Host Identity Protocol (HIP). For mobile users using		location in Host Identity Protocol (HIP). For mobile users using
	HIP, one generic mechanism is proposed to share or update their geo-		HIP, one generic mechanism is proposed to share or update their geo-
	location information with either rendezvous servers or their peers.		location information with either rendezvous servers or their peers.
	In addition, geo-location privacy is also protected with the help of		In addition, geo-location privacy is also protected with the help of
	the ENCRPTED parameter.		the ENCRYPTED parameter.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. New GEOLOC Parameter . . . . . . . . . . . . . . . . . . . 4		3.2. GEOLOC Parameter . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Privacy Protection . . . . . . . . . . . . . . . . . . . . 5		3.3. Privacy Protection . . . . . . . . . . . . . . . . . . . . 5
	3.4. Request for obtaining geo-location . . . . . . . . . . . . 6		3.4. Request for obtaining geo-location . . . . . . . . . . . . 6
	4. Use cases with HIP flows . . . . . . . . . . . . . . . . . . . 7		4. Use cases with HIP flows . . . . . . . . . . . . . . . . . . . 7
	4.1. Setting up peer connection . . . . . . . . . . . . . . . . 7		4.1. Setting up peer connection . . . . . . . . . . . . . . . . 8
	4.2. Registration in rendevous services . . . . . . . . . . . . 8		4.2. Registration in rendezvous services . . . . . . . . . . . 8
	4.3. Distribution from rendevous servers . . . . . . . . . . . 8		4.3. Distribution from rendezvous servers . . . . . . . . . . . 9
	4.4. Updates in peer connections . . . . . . . . . . . . . . . 9		4.4. Updates in peer connections . . . . . . . . . . . . . . . 9
	4.5. Updates to rendevous servers . . . . . . . . . . . . . . . 9		4.5. Updates to rendezvous servers . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	8.2. Informational References . . . . . . . . . . . . . . . . . 11		8.2. Informational References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction		1. Introduction
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	This document defines a new extension for delivering geographic		This document defines a new extension for delivering geographic
	location in Host Identity Protocol (HIP) [RFC4423]. For some mobile		location in Host Identity Protocol (HIP) [RFC4423]. For some mobile
	users using HIP, their geo-location information can play an important		users using HIP, their geo-location information can play an important
	role for some new location-based services.		role for some new location-based services.
	For example, if a roaming user using HIP enters into a different		For example, if a roaming user using HIP enters into a different
	location, his latest geo-location can be shared with his peers for		location, his latest geo-location can be shared with his peers for
	various services, such as localized advertisements, social		various services, such as localized advertisements, social
	networking, and emergency services.		networking, and emergency services.
			Another example is that rendezvous server may use geographic
			locations of its rendezvous clients for better services.
	Additionally, location privacy has been a big concern for many mobile		Additionally, location privacy has been a big concern for many mobile
	users, and must be addressed so that such geo-location information		users, and must be addressed so that such geo-location information
	can be securely protected from end to end in HIP.		can be securely protected from end to end in HIP.
	In this document, a new generic mechanism is proposed to share or		In this document, a new generic mechanism is proposed to share or
	update the geo-location information in HIP. Both the centralized		update the geo-location information in HIP. Both the centralized
	approach based on rendezvous servers, or the distributed approach		approach based on rendezvous servers, or the distributed approach
	based on the peers, are discussed and demonstrated. Furthermore,		based on the peers, are discussed and demonstrated. Furthermore,
	geo-location privacy is also considered with the help of the ENCRPTED		geo-location privacy is also considered with the help of the ENCRPTED
	parameter.		parameter.
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 46 ¶
	Host Identity Tag (HIT): the hashed 128-bit value from host		Host Identity Tag (HIT): the hashed 128-bit value from host
	identifier in HIP		identifier in HIP
	Rendezvous Server (RVS): A HIP registrar providing rendezvous		Rendezvous Server (RVS): A HIP registrar providing rendezvous
	service		service
	Geo-location: Geographic location that may be presented in various		Geo-location: Geographic location that may be presented in various
	formats, such as civil address, geodetic-2d, and geodetic-3d.		formats, such as civil address, geodetic-2d, and geodetic-3d.
	Peer connection: the relationship set up between initiator and		Peer connection: the relationship set up directly between initiator
	responder in HIP.		and responder in HIP.
	Location-by-Reference (LbyR): the presentation of location		Location-by-Reference (LbyR): the presentation of location
	information is the reference link where the actual value can be		information is the reference link where the actual value can be
	obtained.		obtained.
	Location-by-Value (LbyV): the presentation of location information		Location-by-Value (LbyV): the presentation of location information
	is the actual value in one of the known formats describing the		is the actual value in one of the known formats describing the
	location.		location.
	3. Overview		3. Overview
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 29 ¶
	definitions and satisfying the related location privacy guidelines.		definitions and satisfying the related location privacy guidelines.
	The following requirements should be addressed:		The following requirements should be addressed:
	o The mechanism must be extensible for carrying current various geo-		o The mechanism must be extensible for carrying current various geo-
	location formats and potential future formats		location formats and potential future formats
	o The distributed model as peer connections must be outlined		o The distributed model as peer connections must be outlined
	o The centralized model as rendezvous services must be outlined		o The centralized model as rendezvous services must be outlined
	o The security mechanism for protecting geo-location privacy must be		o The security mechanism for protecting geo-location privacy must be
	addressed		addressed
	3.2. New GEOLOC Parameter		3.2. GEOLOC Parameter
	When the initiator or the responder wants to share its geo-location		When the initiator or the responder wants to share its geo-location
	with either rendezvous servers or its peers in HIP, the most		with either rendezvous servers or its peers in HIP, the most
	efficient mechanism is to use a new geo-location parameter. Inside		efficient mechanism is to use a new geo-location parameter. Inside
	such a new geo-location extension, the information about geo-location		such a geo-location extension, the information about geo-location can
	can be inserted and delivered along with HIP messages.		be inserted and delivered along with HIP messages.
	Similarly, in some centralized scenarios, the rendezvous servers may		Similarly, in some centralized scenarios, the rendezvous servers may
	also distribute or update the geo-location information about some		also distribute or update the geo-location information about some
	registered HIP clients by using this geo-location parameter.		registered HIP clients by using this geo-location parameter.
	The new GEOLOC parameter are defined as follows:		The GEOLOC parameter are defined as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| HIT |		| HIT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LocationFormat | |		| LocationFormat | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| LocationPayload |		| LocationPayload |
	| |		| |
	| |		| |
	| +----------------------+		| +----------------------+
	| | Padding |		| | Padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type 16 [TBD by IANA]		Type 16 [TBD by IANA]
	Length 16		Length 16 [length in octets, excluding Type, length, padding]
	HIT Host Identity Tag		HIT Host Identity Tag
	LocationFormat 16		LocationFormat 16 [type of geo-location formats]
	LocationPayload the presentation of location in the indicated		LocationPayload the presentation of location in the indicated
	format		format
			Figure 1: GEOLOC parameter format
	"LocationFormat" specifies the exact format for presenting geo-		"LocationFormat" specifies the exact format for presenting geo-
	location. Note that there are two categories in LocationFormat: one		location. Note that there are two categories in LocationFormat: one
	is LbyV, and the other LbyR.		is LbyV, and the other LbyR.
	In order to clarify the difference, the first bit, I, in		In order to clarify the difference, the first bit, I, in
	LocationFormat is used as the indicator. If I is set to be 0, it		LocationFormat is used as the indicator. If I is set to be 0, it
	means LbyV is presented. Otherwise, LbyR is presented when I is set		means LbyV is presented. Otherwise, LbyR is presented when I is set
	to be 1.		to be 1.
	All the current formats for geo-location can be included by assigning		All the current formats for geo-location can be included by assigning
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 9 ¶
	3.3. Privacy Protection		3.3. Privacy Protection
	Location privacy is among the top concerns in Location-based		Location privacy is among the top concerns in Location-based
	services. Whenever mobile users like to share or receive the		services. Whenever mobile users like to share or receive the
	location information, the secure mechanism must be available for		location information, the secure mechanism must be available for
	addressing location privacy.		addressing location privacy.
	The secure mechanism can be fully built upon another exising HIP		The secure mechanism can be fully built upon another exising HIP
	exention, by embedding geo-location GEOLOC into "Encrypted" parameter		exention, by embedding geo-location GEOLOC into "Encrypted" parameter
	in HIP header.		in HIP header (See Section 5.2.15 in RFC 5201).
	The new GEOLOC parameter can be embedded as follows:		The GEOLOC parameter can be embedded as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 641 | Length |		| 641 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IV /		| IV /
	/ /		/ /
	/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
	/ Encrypted GEOLOC parameter /		/ Encrypted GEOLOC parameter /
	/ /		/ /
	/ +-------------------------------+		/ +-------------------------------+
	/ | Padding |		/ | Padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2: Encrypted GEOLOC parameter
	"Encrypted GEOLOC parameter" is created by following the procedures		"Encrypted GEOLOC parameter" is created by following the procedures
	defined in "Encrypted" parameter.		defined in "Encrypted" parameter.
	With the help of "Encrypted" parameter, GEOLOC parameter can be fully		With the help of "Encrypted" parameter, GEOLOC parameter can be fully
	protected without any disclosure to other parties that are not		protected without any disclosure to other parties that are not
	involved in this HIP connection.		involved in this HIP connection.
	3.4. Request for obtaining geo-location		3.4. Request for obtaining geo-location
	This provides an option for allowing the HIP parties to ask for the		This provides an option for allowing the HIP parties to ask for the
	geo-location information of others. Then it is up to location		geo-location information of others. Then it is up to location
	policies for granting or denying the permission to the requestor.		policies for granting or denying the permission to the requestor.
	requestor.		requestor.
	The new GEOLOC_REQ parameter are defined as follows:		The GEOLOC_REQ parameter is defined as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| type | Length |		| type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LocationFormat_NUM | Reserved |		| LocationFormat_NUM | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| HIT |		| HIT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LocationFormat-1 | ............. |		| LocationFormat-1 | ............. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| .................... |		| .................... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LocationFormat-m | padding |		| LocationFormat-m | padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type 16 [TBD by IANA]		Type 16 [TBD by IANA]
	Length 16		Length 16 [length in octets, excluding Type, length, padding]
	LocationFormat-NUM 16		LocationFormat-NUM 16 [type of geo-location formats]
			Figure 3: GEOLOC_REQ parameter format
	LocationFormat_NUM lists the number of the preferred geo-location		LocationFormat_NUM lists the number of the preferred geo-location
	format(s) when GEOLOC parameters are returned back.		format(s) when GEOLOC parameters are returned back.
	With the help of GEOLOC_REQ parameter, each HIP party can indicate		With the help of GEOLOC_REQ parameter, each HIP party can indicate
	its interest of acquiring the geo-location information of others.		its interest of acquiring the geo-location information of others.
	But the receiver of such a GEOLOC_REQ parameter needs to check the		But the receiver of such a GEOLOC_REQ parameter needs to check the
	location policy before granting such a request (To be discussed more		location policy before granting such a request (To be discussed more
	in the following section).		in the following section).
			[Open question: how RVS can provide the error codes for GEOLOC_REQ?]
	4. Use cases with HIP flows		4. Use cases with HIP flows
	There are multiple ways to use this new Geo-location parameter in		There are multiple ways to use this new Geo-location parameter in
	various scenarios. In this section, some major use cases are		various scenarios. In this section, some major use cases are
	demonstrated, including		demonstrated, including
	o sharing geo-location in setting up peer connections		o sharing geo-location in setting up peer connections
	o carrying geo-location in the registration with rendezvous servers		o carrying geo-location in the registration with rendezvous servers
	o distributing geo-location from rendezvous servers		o distributing geo-location from rendezvous servers
	o updating geo-location in peer connections		o updating geo-location in peer connections
	o updating geo-location to rendezvous servers		o updating geo-location to rendezvous servers
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 30 ¶
	I2: GEOLOC		I2: GEOLOC
	---------------------------------->		---------------------------------->
	R2: GEOLOC		R2: GEOLOC
	<----------------------------------		<----------------------------------
	When location privacy is desired, the initiator or the responder must		When location privacy is desired, the initiator or the responder must
	embed the GEOLOC parameter into Encrypted parameter and then send the		embed the GEOLOC parameter into Encrypted parameter and then send the
	finalized HIP packet in I2 or R2.		finalized HIP packet in I2 or R2.
	4.2. Registration in rendevous services		4.2. Registration in rendezvous services
	Rendezvous clients can inform Rendezvous Server of their geo-		Rendezvous clients can inform Rendezvous Server of their geo-
	locations during their registrations.		locations during their registrations.
	RV Client RVS		RV Client RVS
	I1		I1
	---------------------------------->		---------------------------------->
	R1: REG_INFO, GEOLOC_REQ		R1: REG_INFO, GEOLOC_REQ
	<----------------------------------		<----------------------------------
	I2: REG_REQ, GEOLOC		I2: REG_REQ, GEOLOC
	---------------------------------->		---------------------------------->
	R2: REG_RES		R2: REG_RES
	<----------------------------------		<----------------------------------
	It is similar that GEOLOC can be embedded into ENCRYPTED parameter		4.3. Distribution from rendezvous servers
	for location privacy protection.
	4.3. Distribution from rendevous servers
	RVS can server as Location Server (LS) (See [RFC3693]) for sharing		RVS can serve as Location Server (LS) (See [RFC3693]) for sharing the
	the location information with HIP clients, with the help of Rule		location information with HIP clients, with the help of Rule Holder
	Holder (RH) for location policies.		(RH) for location policies.
	RV Client RVS		RV Client RVS
	....................................		....................................
	UPDATE: GEOLOC_REQ		UPDATE: GEOLOC_REQ
	---------------------------------->		---------------------------------->
	NOTIFY: GEOLOC		NOTIFY: GEOLOC
	<----------------------------------		<----------------------------------
	It is similar that GEOLOC can be embedded into ENCRYPTED parameter
	for location privacy protection.
	4.4. Updates in peer connections		4.4. Updates in peer connections
	For mobile users, they can update their geo-location when their		For mobile users, they can update their geo-location when their
	positions have been changed.		positions have been changed.
	Initiator Responder		Initiator Responder
	....................................		....................................
	UPDATE: GEOLOC		UPDATE: GEOLOC
	---------------------------------->		---------------------------------->
	UPDATE: GEOLOC		UPDATE: GEOLOC
	<----------------------------------		<----------------------------------
	It is similar that GEOLOC can be embedded into ENCRYPTED parameter		4.5. Updates to rendezvous servers
	for location privacy protection.
	4.5. Updates to rendevous servers
	For rendevous clients, they can update their rendevous servers with		For rendevous clients, they can update their rendevous servers with
	their latest geo-locations.		their latest geo-locations.
	RV Client RVS		RV Client RVS
	....................................		....................................
	UPDATE: GEOLOC		UPDATE: GEOLOC
	---------------------------------->		---------------------------------->
	It is similar that GEOLOC can be embedded into ENCRYPTED parameter		It is similar that GEOLOC can be embedded into ENCRYPTED parameter
	for location privacy protection.		for location privacy protection.
	5. Security Considerations		5. Security Considerations
	This document provides the new HIP parameters for sharing geo-		This document provides the HIP parameters for sharing geo-location
	location information among HIP parties.		information among HIP parties.
	Some existing work on geo-location privacy (see [RFC3693, RFC3694])		Some existing work on geo-location privacy (see [RFC3693, RFC3694])
	should be carefully integrated so that the secure models can help to		should be carefully integrated so that the secure models can help to
	address the potential threats.		address the potential threats.
	For example, RVS may include the functions of Location Information		For example, RVS may include the functions of Location Information
	Server (LIS) and the Rule Holder (RH). The desired policies can be		Server (LIS) and the Rule Holder (RH). The desired policies can be
	enforced when the geo-location information is exchanged through RVS		enforced when the geo-location information is exchanged through RVS
	among rendevous clients.		among rendezvous clients.
	On the other hand, RVS may become the target for disturbing the		On the other hand, RVS may become the target for disturbing the
	desired geo-location services.		desired geo-location services.
	The frequency of geo-location updates may also be used by the hackers		The frequency of geo-location updates may also be used by the hackers
	as another way for generating DoS attacks.		as another way for generating DoS attacks.
	[More to be added ...]		[More to be added, such as rate limit on control packets with
			GEOLOC_REQ, frequency limit on geo-location update, ...]
	6. IANA Considerations		6. IANA Considerations
	This document updates the IANA registry for HIP parameters Types by		This document updates the IANA registry for HIP parameters Types by
	assigning new values for the following new HIP parameter types:		assigning new values for the following new HIP parameter types:
	o GEOLOC (defined in Overview Section)		o GEOLOC (defined in Overview Section)
	o GEOLOC_REQ (defined in Overview Section)		o GEOLOC_REQ (defined in Overview Section)
	7. Acknowledgments		7. Acknowledgments
	The editor and the contributors would like to acknowledge the		The editor and the contributors would like to acknowledge the
	constructive feedback and input provided by ......		constructive feedback and input provided by David Ward, Varjonen
			Samu, and Suping Zhai.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,		[1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
	"Host Identity Protocol", RFC 5201, April 2008.		"Host Identity Protocol", RFC 5201, April 2008.
	[2] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)		[2] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
	Architecture", RFC 4423, May 2006.		Architecture", RFC 4423, May 2006.
	skipping to change at page 11, line 41 ¶		skipping to change at page 12, line 4 ¶
	Authors' Addresses		Authors' Addresses
	Feng Cao		Feng Cao
	Cisco Systems		Cisco Systems
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: fcao at cisco dot com		Email: fcao at cisco dot com
	David Ward
	Cisco Systems
	170 West Tasman Drive
	San Jose, CA 95134
	USA
	Email: wardd at cisco dot com
	Hui Deng		Hui Deng
	China Mobile		China Mobile
	53A Xibianmennei Ave.		53A Xibianmennei Ave.
	Beijing 100053		Beijing 100053
	China		China
	Email: denghui at chinamobile dot com		Email: denghui at chinamobile dot com
	Full Copyright Statement		Full Copyright Statement
End of changes. 32 change blocks.
	56 lines changed or deleted		52 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/