< draft-manyfolks-hip-sturn-00.txt		draft-manyfolks-hip-sturn-01.txt >
	Network Working Group P. Nikander		Network Working Group P. Nikander
	Internet-Draft J. Melen		Internet-Draft J. Melen
	Intended status: Informational Ericsson Research Nomadic Lab		Intended status: Informational Ericsson Research Nomadic Lab
	Expires: May 15, 2008 M. Komu		Expires: May 22, 2008 M. Komu
	Helsinki Institute for Information		Helsinki Institute for
	Technology		Information Technology
	M. Bagnulo		M. Bagnulo
	Universidad Carlos III de Madrid		Universidad Carlos III de Madrid
	November 12, 2007		November 19, 2007
	Mapping STUN and TURN messages on HIP		Mapping STUN and TURN messages on HIP
	draft-manyfolks-hip-sturn-00		draft-manyfolks-hip-sturn-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 39 ¶		skipping to change at page 1, line 39 ¶
	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 May 15, 2008.		This Internet-Draft will expire on May 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This memo defines how one can map the STUN and TURN functionality, as		This memo defines how one can map the STUN and TURN functionality, as
	used by ICE, to HIP.		used by ICE, to HIP.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Message foramts . . . . . . . . . . . . . . . . . . . . . . 3		2. Message formats . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. HIP parameter format . . . . . . . . . . . . . . . . . . . . 3		2.1. HIP parameter format . . . . . . . . . . . . . . . . . . . . 3
	2.2. STUN attribute format . . . . . . . . . . . . . . . . . . . 3		2.2. STUN attribute format . . . . . . . . . . . . . . . . . . . 3
	2.3. Mapping STUN attribute format to HIP parameter format . . . 4		2.3. Mapping STUN, TURN and ICE attributes to HIP parameters . . 4
	2.4. Mapping STUN attribute Types to HIP parameter Types . . . . 4		2.4. Mapping STUN attribute Types to HIP parameter Types . . . . 4
	2.5. Mapping of STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS . . . 5		3. Mapping STUN attribute Types defined in the STUN
	2.6. Mapping of STUN SERVER parameter . . . . . . . . . . . . . . 5		specification . . . . . . . . . . . . . . . . . . . . . . . 5
	2.7. Mapping of STUN security mechanisms . . . . . . . . . . . . 5		3.1. Mapping of STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS . . . 5
	2.8. Mapping of STUN error attributes . . . . . . . . . . . . . . 5		3.2. Mapping of STUN SERVER parameter . . . . . . . . . . . . . . 5
	2.9. Mapping of STUN ALTERNATE-SERVER . . . . . . . . . . . . . . 6		3.3. Mapping of STUN security mechanisms . . . . . . . . . . . . 5
	3. Mapping STUN attribute Types defined in the TURN		3.4. Mapping of STUN error attributes . . . . . . . . . . . . . . 5
			3.5. Mapping of STUN ALTERNATE-SERVER . . . . . . . . . . . . . . 6
			4. Mapping STUN attribute Types defined in the TURN
	specification . . . . . . . . . . . . . . . . . . . . . . . 6		specification . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Mapping of TURN error codes . . . . . . . . . . . . . . . . 7		4.1. Mapping of TURN error codes . . . . . . . . . . . . . . . . 7
	4. Mapping STUN protocol operations to HIP . . . . . . . . . . 7		5. Mapping STUN attribute Types defined in the ICE
	4.1. Forming a Request or an Indication and sending it . . . . . 7		specification . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Mapping TURN protocol operations to HIP . . . . . . . . . . 8		5.1. Mapping of ICE error codes . . . . . . . . . . . . . . . . . 7
	5.1. Allocate . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.2. Mapping of PRIORITY attribute . . . . . . . . . . . . . . . 7
	5.2. Set Active Destination, Connect, and Connect Status		5.3. Mapping of USE-CANDIDATE attribute . . . . . . . . . . . . . 8
	Indication . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.4. Mapping of ICE-CONTROLLING and ICE-CONTROLLED attributes . . 8
	5.3. Send and Data indications . . . . . . . . . . . . . . . . . 8		6. Mapping STUN protocol operations to HIP . . . . . . . . . . 8
	6. Security considerations . . . . . . . . . . . . . . . . . . 9		6.1. Forming a Request or an Indication and sending it . . . . . 8
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . 9		7. Mapping TURN protocol operations to HIP . . . . . . . . . . 9
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9		7.1. Allocate . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. Informative references . . . . . . . . . . . . . . . . . . . 9		7.2. Set Active Destination, Connect, and Connect Status
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10		Indication . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . 11		7.3. Send and Data indications . . . . . . . . . . . . . . . . . 10
			8. Mapping ICE protocol operations to HIP . . . . . . . . . . . 10
			8.1. Connectivity checks . . . . . . . . . . . . . . . . . . . . 10
			8.2. Controlling and controlled host election . . . . . . . . . . 10
			9. Security considerations . . . . . . . . . . . . . . . . . . 11
			10. IANA considerations . . . . . . . . . . . . . . . . . . . . 11
			11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
			12. Informative references . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
			Intellectual Property and Copyright Statements . . . . . . . 14
	1. Introduction		1. Introduction
	The HIP protocol defines a number of messages and parameters [1].		The HIP protocol defines a number of messages and parameters [1].
	The parameters are encoded as TLVs, as shown in Section 2.1.		The parameters are encoded as TLVs, as shown in Section 2.1.
	The STUN specification defines a number of messages and attributes		The STUN specification defines a number of messages and attributes
	[5]. The attributes are encoded as TLVs, as shown in Section 2.2.		[5]. The attributes are encoded as TLVs, as shown in Section 2.2.
	As it turn out that the HIP parameter format and the STUN attribute		As it turn out that the HIP parameter format and the STUN attribute
	format are almost the same, this document provides a trivial mapping		format are almost the same, this document provides a trivial mapping
	for encoding STUN attributes as HIP parameters. Additionally, this		for encoding STUN attributes as HIP parameters. Additionally, this
	document specifies a number of options how one can use HIP messages		document specifies a number of options how one can use HIP messages
	to carry the equivalent of STUN messages.		to carry the equivalent of STUN messages.
	2. Message foramts		2. Message formats
	2.1. HIP parameter format		2.1. HIP parameter format
	The HIP parameter format is defined in Section 5.2.1 of [1], and		The HIP parameter format is defined in Section 5.2.1 of [1], and
	copied below.		copied below.
	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 |C| Length |		| Type |C| Length |
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 17 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value (variable) ....		| Value (variable) ....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Length contains the length of the Value part, prior to padding,		The Length contains the length of the Value part, prior to padding,
	measured in bytes. Since STUN attributes are aligned in 32 bit		measured in bytes. Since STUN attributes are aligned in 32 bit
	boundaries, there may be 0-3 bytes of padding.		boundaries, there may be 0-3 bytes of padding.
	2.3. Mapping STUN attribute format to HIP parameter format		2.3. Mapping STUN, TURN and ICE attributes to HIP parameters
	As the only difference between the HIP parameter and STUN attribute		As the only difference between the HIP parameter and STUN attribute
	format is alignment, which is 64 bits for HIP and 32 bits for STUN,		format is alignment, which is 64 bits for HIP and 32 bits for STUN,
	it becomes trivial to map TURN attribute formats to HIP parameter		it becomes trivial to map STUN attribute formats to HIP parameter
	formats. All that is needed is to pad them according to the HIP		formats. All that is needed is to pad them according to the HIP
	format, to 64 bits, and we are done.		format, to 64 bits, and we are done.
	2.4. Mapping STUN attribute Types to HIP parameter Types		2.4. Mapping STUN attribute Types to HIP parameter Types
	Table 1 maps the currently defined STUN attribute types to HIP		Table 1 maps the currently defined STUN attribute types [5] to HIP
	parameter types. For attributes not discussed below, the method to		parameter types. Table 3 maps the currently defined TURN attribute
	define the corresponding HIP parameter is as follows:		types [6] to HIP parameter types. Table 5 maps the currently defined
			ICE attribute types [7] to HIP parameter types.
			For attributes not discussed below, the method to define the
			corresponding HIP parameter is as follows:
	Try to find a HIP parameter that has exactly the same semantics.		Try to find a HIP parameter that has exactly the same semantics.
	If so, figure out how to do the conceptual, semantic level		If so, figure out how to do the conceptual, semantic level
	mapping. This method was used to map the STUN MESSAGE-INTEGRITY		mapping. This method was used to map the STUN MESSAGE-INTEGRITY
	to HIP HMAC below.		to HIP HMAC below.
	Try to find a HIP parameter that encodes semantically similar data		Try to find a HIP parameter that encodes semantically similar data
	(but has otherwise different semantics). If so, create a new HIP		(but has otherwise different semantics). If so, create a new HIP
	parameter using the format from the existing HIP parameter, and		parameter using the format from the existing HIP parameter, and
	define the new semantics. This method was used to map the STUN		define the new semantics. This method was used to map the STUN
	MAPPED-ADDRESS and XOR-MAPPED-ADDRESS parameters to the new HIP		MAPPED-ADDRESS and XOR-MAPPED-ADDRESS parameters to the new HIP
	RLOCATOR parameter below.		RLOCATOR parameter below.
	Otherwise, define a new HIP parameter that has the same value		Otherwise, define a new HIP parameter that has the same value
	syntax and semantics as the STUN attribute. This method was used		syntax and semantics as the STUN attribute. This method was used
	to map the STUN SERVER parameter to a new HIP parameter below.		to map the STUN SERVER parameter to a new HIP parameter below.
			3. Mapping STUN attribute Types defined in the STUN specification
	+--------------------+---------------+------------------------------+		+--------------------+---------------+------------------------------+
	| STUN Type | STUN Encoding | HIP Encoding |		| STUN Type | STUN Encoding | HIP Encoding |
	+--------------------+---------------+------------------------------+		+--------------------+---------------+------------------------------+
	| MAPPED-ADDRESS | 0x0001 | A new HIP RLOCATOR parameter |		| MAPPED-ADDRESS | 0x0001 | A new HIP RLOCATOR parameter |
	| USERNAME | 0x0006 | Replaced by HIP identities |		| USERNAME | 0x0006 | Replaced by HIP identities |
	| MESSAGE-INTEGRITY | 0x0008 | Replaced by HIP HMAC |		| MESSAGE-INTEGRITY | 0x0008 | Replaced by HIP HMAC |
	| ERROR-CODE | 0x0009 | Mapped to HIP NOTIFICATION |		| ERROR-CODE | 0x0009 | Mapped to HIP NOTIFICATION |
	| UNKNOWN-ATTRIBUTES | 0x000A | Mapped to HIP NOTIFICATION |		| UNKNOWN-ATTRIBUTES | 0x000A | Mapped to HIP NOTIFICATION |
	| REALM | 0x0014 | Replaced by HIP identities |		| REALM | 0x0014 | Replaced by HIP identities |
	| NONCE | 0x0015 | Replaced by HIP base |		| NONCE | 0x0015 | Replaced by HIP base |
	| | | protocol |		| | | protocol |
	| XOR-MAPPED-ADDRESS | 0x0020 | A new HIP RLOCATOR parameter |		| XOR-MAPPED-ADDRESS | 0x0020 | A new HIP RLOCATOR parameter |
	| SERVER | 0x8022 | A new HIP SERVER parameter |		| SERVER | 0x8022 | A new HIP SERVER parameter |
	| ALTERNATE-SERVER | 0x8023 | For future study |		| ALTERNATE-SERVER | 0x8023 | For future study |
	| FINGERPRINT | 0x8028 | Not needed in HIP |		| FINGERPRINT | 0x8028 | Not needed in HIP |
	+--------------------+---------------+------------------------------+		+--------------------+---------------+------------------------------+
	Table 1: Type mapping		Table 1: Type mapping
	2.5. Mapping of STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS		3.1. Mapping of STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS
	The STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes are both		The STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes are both
	replaced by a new HIP parameter, RLOCATOR (for Reverse Locator),		replaced by a new HIP parameter, RLOCATOR (for Reverse Locator),
	which has a format identical to the LOCATOR parameter as defined in		which has a format identical to the LOCATOR parameter as defined in
	[2]. This parameter carries the STUN reflexive and other transport		[2]. This parameter carries the STUN reflexive and other transport
	addresses.		addresses.
	2.6. Mapping of STUN SERVER parameter		3.2. Mapping of STUN SERVER parameter
	The STUN SERVER parameter is mapped to a new HIP SERVER parameter.		The STUN SERVER parameter is mapped to a new HIP SERVER parameter.
	The syntax of the value is identical.		The syntax of the value is identical.
	2.7. Mapping of STUN security mechanisms		3.3. Mapping of STUN security mechanisms
	When HIP is used, the HIP security mechanisms completely replace the		When HIP is used, the HIP security mechanisms completely replace the
	STUN security mechanisms. Hence, the STUN USERNAME, MESSAGE-		STUN security mechanisms. Hence, the STUN USERNAME, MESSAGE-
	INTEGRITY, REALM, and NONCE parameters are not needed at all.		INTEGRITY, REALM, and NONCE parameters are not needed at all.
	2.8. Mapping of STUN error attributes		3.4. Mapping of STUN error attributes
	The STUN error indication attributes ERROR-CODE and UNKNOWN-		The STUN error indication attributes ERROR-CODE and UNKNOWN-
	ATTRIBUTES are mapped into HIP NOTIFICATION payload as follows:		ATTRIBUTES are mapped into HIP NOTIFICATION payload as follows:
	The STUN UNKNOWN-ATTRIBUTE is mapped to HIP		The STUN UNKNOWN-ATTRIBUTE is mapped to HIP
	UNSUPPORTED_CRITICAL_PARAMETER_TYPE NOTIFICATION. Since the STUN		UNSUPPORTED_CRITICAL_PARAMETER_TYPE NOTIFICATION. Since the STUN
	parameter allows listing multiple unknown attributes, the		parameter allows listing multiple unknown attributes, the
	corresponding HIP message may contain multiple parameters instead		corresponding HIP message may contain multiple parameters instead
	of one.		of one.
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 23 ¶
	| 300 | Currently not supported; see below |		| 300 | Currently not supported; see below |
	| 400 | INVALID_SYNTAX (or some more specific) |		| 400 | INVALID_SYNTAX (or some more specific) |
	| 401 | AUTHENTICATION_FAILED or BLOCKED_BY_POLICY |		| 401 | AUTHENTICATION_FAILED or BLOCKED_BY_POLICY |
	| 420 | UNSUPPORTED_CRITICAL_PARAMETER_TYPE; see above |		| 420 | UNSUPPORTED_CRITICAL_PARAMETER_TYPE; see above |
	| 438 | Not possible as NONCEs are not used |		| 438 | Not possible as NONCEs are not used |
	| 500 | SERVER_BUSY_PLEASE_RETRY |		| 500 | SERVER_BUSY_PLEASE_RETRY |
	+-----------------+------------------------------------------------+		+-----------------+------------------------------------------------+
	Table 2		Table 2
	2.9. Mapping of STUN ALTERNATE-SERVER		3.5. Mapping of STUN ALTERNATE-SERVER
	Supporting STUN ALTERNATE-SERVERs and the 300 (Redirect) error code		Supporting STUN ALTERNATE-SERVERs and the 300 (Redirect) error code
	would require full delegation in the HIP case. As HIP delegation has		would require full delegation in the HIP case. As HIP delegation has
	not been fully specified, the definition of such a redirection		not been fully specified, the definition of such a redirection
	mechanism is left for future work.		mechanism is left for future work.
	3. Mapping STUN attribute Types defined in the TURN specification		4. Mapping STUN attribute Types defined in the TURN specification
			TBD.
	+----------------------+-----------+--------------------------------+		+----------------------+-----------+--------------------------------+
	| STUN Type | STUN | HIP Encoding |		| STUN Type | STUN | HIP Encoding |
	| | Encoding | |		| | Encoding | |
	+----------------------+-----------+--------------------------------+		+----------------------+-----------+--------------------------------+
	| LIFETIME | 0x000D | Part of HIP REG_REQUEST or |		| LIFETIME | 0x000D | Part of HIP REG_REQUEST or |
	| | | REG_RESPONSE |		| | | REG_RESPONSE |
	| BANDWIDTH | 0x0010 | A new HIP parameter |		| BANDWIDTH | 0x0010 | A new HIP parameter |
	| REMOTE-ADDRESS | 0x0012 | Mapped to the existing HIP |		| REMOTE-ADDRESS | 0x0012 | Mapped to the existing HIP |
	| | | LOCATOR parameter |		| | | LOCATOR parameter |
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 9 ¶
	| | | parameter |		| | | parameter |
	| REQUESTED-PORT-PROPS | 0x0018 | A new HIP parameter |		| REQUESTED-PORT-PROPS | 0x0018 | A new HIP parameter |
	| REQUESTED-TRANSPORT | 0x0019 | A new HIP parameter |		| REQUESTED-TRANSPORT | 0x0019 | A new HIP parameter |
	| REQUESTED-IP | 0x0022 | A new HIP parameter |		| REQUESTED-IP | 0x0022 | A new HIP parameter |
	| TIMER-VAL | 0x0021 | For further study |		| TIMER-VAL | 0x0021 | For further study |
	| CONNECT_STAT | 0x0023 | For further study |		| CONNECT_STAT | 0x0023 | For further study |
	+----------------------+-----------+--------------------------------+		+----------------------+-----------+--------------------------------+
	Table 3: Type mapping		Table 3: Type mapping
	3.1. Mapping of TURN error codes		4.1. Mapping of TURN error codes
	+------------------------+----------------------------------+		+------------------------+----------------------------------+
	| STUN error code | HIP error type |		| TURN error code | HIP error type |
	+------------------------+----------------------------------+		+------------------------+----------------------------------+
	| 437 (No binding) | Mapped to the HIP ICMP mechanism |		| 437 (No binding) | Mapped to the HIP ICMP mechanism |
	| 439, 442-446, 486, 507 | Mapped to a new HIP error type |		| 439, 442-446, 486, 507 | Mapped to a new HIP error type |
	+------------------------+----------------------------------+		+------------------------+----------------------------------+
	4. Mapping STUN protocol operations to HIP		5. Mapping STUN attribute Types defined in the ICE specification
	TBD.		TBD.
	4.1. Forming a Request or an Indication and sending it		+-----------------+-----------+-------------------------------------+
			| STUN Type | STUN | HIP Encoding |
			| | Encoding | |
			+-----------------+-----------+-------------------------------------+
			| PRIORITY | 0x0024 | Mapped to existing HIP LOCATOR as a |
			| | | new locator type |
			| USE-CANDIDATE | 0x0025 | Not needed in HIP |
			| ICE-CONTROLLING | 0x8029 | Not needed in HIP |
			| ICE-CONTROLLED | 0x802a | Not needed in HIP |
			+-----------------+-----------+-------------------------------------+
	When an implentation would create a STUN Request or a STUN		Table 5: Type mapping
	Indication, the corresponding HIP-mapped machanism would create a HIP
			5.1. Mapping of ICE error codes
			+---------------------+-------------------+
			| STUN error code | HIP error type |
			+---------------------+-------------------+
			| 487 (Role Conflict) | Not needed in HIP |
			+---------------------+-------------------+
			5.2. Mapping of PRIORITY attribute
			The PRIORITY is included in to a new locator type to be defined for
			the exchange of candidates. The candidates are carried in the
			LOCATOR parameter as defined in [2].
			5.3. Mapping of USE-CANDIDATE attribute
			Explicit indication of the address pair to be used as ICE implements
			with USE-CANDIDATE option is not needed in HIP. In HIP the ESP
			payload after Base Exchange or after mobility update function's as an
			implicit indication of the selected candidate pair. HIP return
			routability check used with mobility and multihoming uses the ESP
			similarly as a implicit indication of completion of mobility UPDATE
			as defined in [2].
			5.4. Mapping of ICE-CONTROLLING and ICE-CONTROLLED attributes
			The ICE-CONTROLLING and ICE-CONTROLLED attributes are not needed
			because the HIP has already resolving mechanism for handling
			simultaneous start of Base Exchange. The same mechanism can be used
			to elect the controlling and controlled role. The host having the
			smaller HIT MUST become the controlled host (For detailed description
			of HIT comparison see HIP Base Protocol specification section 6.5
			[1]).
			6. Mapping STUN protocol operations to HIP
			TBD.
			6.1. Forming a Request or an Indication and sending it
			When an implementation would create a STUN Request or a STUN
			Indication, the corresponding HIP-mapped mechanism would create a HIP
	message. Depending on the state of the HIP base protocol, the		message. Depending on the state of the HIP base protocol, the
	underlying HIP message may be a R1, an I2, a R2, an UPDATE, or a		underlying HIP message may be a R1, an I2, a R2, an UPDATE, or a
	NOTIFY; see below. Note that in all cases the HIP message may carry		NOTIFY; see below. Note that in all cases the HIP message may carry
	also other parameters than the mapped STUN payloads.		also other parameters than the mapped STUN payloads.
	The message types are mapped as follows:		The message types are mapped as follows:
	A STUN Request is mapped into a HIP packet that carries a		A STUN Request is mapped into a HIP packet that carries a
	REG_REQUEST payloads, where the REG_REQUEST payload indicates that		REG_REQUEST payloads, where the REG_REQUEST payload indicates that
	the client wants to register to the correspondingly-mapped		the client wants to register to the correspondingly-mapped
	service(s). If the STUN message carries attributes, corresponding		service(s). If the STUN message carries attributes, corresponding
	HIP parameters are added to the message. If the packet is an		HIP parameters are added to the message. If the packet is an
	UPDATE packet, the packet MUST also carry a SEQ payload; see below		UPDATE or an R2 packet, the packet MUST also carry a SEQ payload;
			see below
	A STUN Indiciations are mappend into a HIP NOTIFY packets that		A STUN Indications are mapped into a HIP NOTIFY packets that carry
	carry the corresponding mapped parameters.		the corresponding mapped parameters.
	A STUN Response is mapped into a HIP packet that carries an		A STUN Response is mapped into a HIP packet that carries an
	REG_RESPONSE payload, possible together with a number of other		REG_RESPONSE payload, possible together with a number of other
	payloads, corresponding to the STUN attributes. If the request		payloads, corresponding to the STUN attributes. If the request
	packet carried a SEQ, the response must carry a corresponding ACK.		packet carried a SEQ, the response must carry a corresponding ACK.
	The STUN transaction ID is replaced by the HIP SEQ and ACK		The STUN transaction ID is replaced by the HIP SEQ and ACK
	parameters, or implicitly by the R1/I2 or I2/R2 pair.		parameters, or implicitly by the R1/I2 or I2/R2 pair.
	Once the corresponding HIP message has been formed, it is sent		Once the corresponding HIP message has been formed, it is sent
	normally, either in the HIP protocol or as UDP encapsulated as		normally, either in the HIP protocol or as UDP encapsulated as
	specified in [4].		specified in [4].
	5. Mapping TURN protocol operations to HIP		7. Mapping TURN protocol operations to HIP
	TBD.		TBD.
	5.1. Allocate		7.1. Allocate
	If a HIP host wants to communicate with another HIP host through are		If a HIP host wants to communicate with another HIP host through are
	relay, one of the hosts need to register for a generic (ESP) relay		relay, one of the hosts need to register for a generic (ESP) relay
	service, define a policy, and pass ESP packets (UDP encapsulated or		service, define a policy, and pass ESP packets (UDP encapsulated or
	not) through the server.		not) through the server.
	The server indicates that it is willing to provide such relay service		The server indicates that it is willing to provide such relay service
	using REG_INFO. The client registers to the service using		using REG_INFO. The client registers to the service using
	REG_REQUEST, and the server informs the client about the service		REG_REQUEST, and the server informs the client about the service
	using REG_RESPONSE. The relayed address is returned in a RLOCATOR		using REG_RESPONSE. The relayed address is returned in a RLOCATOR
	skipping to change at page 8, line 34 ¶		skipping to change at page 9, line 46 ¶
	encapsulated-ESP. UDP encapsulation or plain ESP is indicated by the		encapsulated-ESP. UDP encapsulation or plain ESP is indicated by the
	REQUESTED-TRANSPORT parameter; see above. If UDP encapsulation is		REQUESTED-TRANSPORT parameter; see above. If UDP encapsulation is
	used, the REQUESTED-PORT-PROPS may used to indicate the desired UDP		used, the REQUESTED-PORT-PROPS may used to indicate the desired UDP
	port. Currently there is no way to specify a wanted ESP SPI number.		port. Currently there is no way to specify a wanted ESP SPI number.
	Other transports but ESP and UDP-encapsulated-ESP are currently		Other transports but ESP and UDP-encapsulated-ESP are currently
	unsupported.		unsupported.
	When the server relays HIP control packets, it MUST add appropriate		When the server relays HIP control packets, it MUST add appropriate
	RVS_HMAC, FROM, and/or VIA_RVS parameters, as defined in [3].		RVS_HMAC, FROM, and/or VIA_RVS parameters, as defined in [3].
	5.2. Set Active Destination, Connect, and Connect Status Indication		7.2. Set Active Destination, Connect, and Connect Status Indication
	The TURN Set Active Destination, Connect, and Connect Status		The TURN Set Active Destination, Connect, and Connect Status
	Indication do not make sense in the HIP case, as HIP works on the		Indication do not make sense in the HIP case, as HIP works on the
	layer below. Once a relay has been allocated at the server, it can		layer below. Once a relay has been allocated at the server, it can
	be used for traffic in both directions. Any hosts that know the		be used for traffic in both directions. Any hosts that know the
	right IP address, UDP port number, SPI triple (or just address, SPI		right IP address, UDP port number, SPI triple (or just address, SPI
	pair in the case of plain ESP) can send packets to the HIP host. Any		pair in the case of plain ESP) can send packets to the HIP host. Any
	traffic restrictions are up to a local policy between the HIP host		traffic restrictions are up to a local policy between the HIP host
	and the relay. It is expected that there will be a generic HIP		and the relay. It is expected that there will be a generic HIP
	extension defining traffic filtering policies.		extension defining traffic filtering policies.
	5.3. Send and Data indications		7.3. Send and Data indications
	The TURN Send and Data indications do not make sense in the HIP case,		The TURN Send and Data indications do not make sense in the HIP case,
	just as above. Payload data is simply sent as ESP or UDP-		just as above. Payload data is simply sent as ESP or UDP-
	encapsulated-ESP messages. Other signalling data than HIP can be		encapsulated-ESP messages. Other signaling data than HIP can be
	piggybacked on HIP control messages by using the "Next Header" field		piggy backed on HIP control messages by using the "Next Header" field
	in the fixed HIP packet header.		in the fixed HIP packet header.
	6. Security considerations		8. Mapping ICE protocol operations to HIP
			TBD.
			8.1. Connectivity checks
			When a host wants to find an address pair which it can use to
			communicate with the peer it has to send the address candidates
			either using HIP I2, R2 packets or HIP UPDATE packets. After
			exchanging the candidates both peers will start the return
			routability checks using UPDATE packets as defined in [2]. Once the
			controlling host has completed one or more successful checks, it will
			create a IPsec policy and security association for one of the pairs.
			As the ESP payload packet is then received on the controlled host it
			will be aware of the selected address pair.
			8.2. Controlling and controlled host election
			In the ICE [7] specification the controlling role is given to the one
			generating the offer. In HIP case the controlling role should be
			given, not to the host that generates the offer, but to the node that
			generates answer. In this manner the connectivity checks are in line
			with the mobility and multihoming return routability checks defined
			in [2].
			Resolving tie-breaker (both hosts starting connectivity checks
			simultaneously) should be done in the same way as simultaneous Base
			Exchange and mobility updates are resolved. The host having the
			smaller HIT MUST become as the controlled host. For detailed
			description of HIT comparison see HIP Base Protocol specification
			section 6.5 [1].
			9. Security considerations
	TBD.		TBD.
	Basically, HIP requires that there is an authenticated HIP		Basically, HIP requires that there is an authenticated HIP
	association between the HIP client and the relay server, and the two		association between the HIP client and the relay server, and the two
	communication HIP peers. Secondly, the HIP registration protocol		communication HIP peers. Secondly, the HIP registration protocol
	explicitly requires that any HIP clients registering for services are		explicitly requires that any HIP clients registering for services are
	authorised by the server.		authorized by the server.
	The danger of anyone being able to send data through the relay to the		The danger of anyone being able to send data through the relay to the
	client is expected to be covered by a separate document defining a		client is expected to be covered by a separate document defining a
	generic traffic filtering capacity for HIP. For example, such a		generic traffic filtering capacity for HIP. For example, such a
	capasity could, trust permitting, pass an ESP integrity key to the		capacity could, trust permitting, pass an ESP integrity key to the
	relay server, allowing it to verify that each arriving packet is		relay server, allowing it to verify that each arriving packet is
	coming from the right peer.		coming from the right peer.
	Reflection attacks on HIP control traffic are taken care of in the		Reflection attacks on HIP control traffic are taken care of in the
	way specified in [3]. Note, however, that the TURN-like relay		way specified in [3]. Note, however, that the TURN-like relay
	defined in this document may relay also other HIP control packets but		defined in this document may relay also other HIP control packets but
	I1s.		I1s.
	7. IANA considerations		10. IANA considerations
	IANA actions TBD.		IANA actions TBD.
	8. Acknowledgments		11. Acknowledgments
	9. Informative references		12. Informative references
	[1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host		[1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host
	Identity Protocol", draft-ietf-hip-base-09 (work in progress),		Identity Protocol", draft-ietf-hip-base-09 (work in progress),
	October 2007.		October 2007.
	[2] Henderson, T., "End-Host Mobility and Multihoming with the Host		[2] Henderson, T., "End-Host Mobility and Multihoming with the Host
	Identity Protocol", draft-ietf-hip-mm-05 (work in progress),		Identity Protocol", draft-ietf-hip-mm-05 (work in progress),
	March 2007.		March 2007.
	[3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		[3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	skipping to change at page 10, line 10 ¶		skipping to change at page 12, line 10 ¶
	[4] Schmitt, V., "HIP Extensions for the Traversal of Network		[4] Schmitt, V., "HIP Extensions for the Traversal of Network
	Address Translators", draft-ietf-hip-nat-traversal-02 (work in		Address Translators", draft-ietf-hip-nat-traversal-02 (work in
	progress), July 2007.		progress), July 2007.
	[5] Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. Wing,		[5] Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for (NAT) (STUN)",		"Session Traversal Utilities for (NAT) (STUN)",
	draft-ietf-behave-rfc3489bis-11 (work in progress),		draft-ietf-behave-rfc3489bis-11 (work in progress),
	October 2007.		October 2007.
			[6] Rosenberg, J., "Traversal Using Relays around NAT (TURN): Relay
			Extensions to Session Traversal Utilities for NAT (STUN)",
			draft-ietf-behave-turn-04 (work in progress), July 2007.
			[7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
			Protocol for Network Address Translator (NAT) Traversal for
			Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in
			progress), October 2007.
	Authors' Addresses		Authors' Addresses
	Pekka Nikander		Pekka Nikander
	Ericsson Research Nomadic Lab		Ericsson Research Nomadic Lab
	JORVAS FIN-02420		JORVAS FIN-02420
	FINLAND		FINLAND
	Phone: +358 9 299 1		Phone: +358 9 299 1
	Email: pekka.nikander@nomadiclab.com		Email: pekka.nikander@nomadiclab.com
	skipping to change at page 10, line 36 ¶		skipping to change at page 13, line 4 ¶
	Email: jan.melen@nomadiclab.com		Email: jan.melen@nomadiclab.com
	Miika Komu		Miika Komu
	Helsinki Institute for Information Technology		Helsinki Institute for Information Technology
	Metsanneidonkuja 4		Metsanneidonkuja 4
	Espoo		Espoo
	FINLAND		FINLAND
	Phone: +358 50 3841531		Phone: +358 50 3841531
	Email: miika@iki.fi		Email: miika@iki.fi
	Marcelo Bagnulo		Marcelo Bagnulo
	Universidad Carlos III de Madrid		Universidad Carlos III de Madrid
	Av. Universidad 30		Av. Universidad 30
	Leganes, Madrid 28911		Leganes, Madrid 28911
	SPAIN		SPAIN
	Phone: +34 91 6249500		Phone: +34 91 6249500
	Email: marcelo@it.uc3m.es		Email: marcelo@it.uc3m.es
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
End of changes. 40 change blocks.
	63 lines changed or deleted		174 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/