draft-ietf-hip-via-00.txt		draft-ietf-hip-via-01.txt
	HIP Working Group G. Camarillo		HIP Working Group G. Camarillo
	Internet-Draft A. Keranen		Internet-Draft A. Keranen
	Intended status: Experimental Ericsson		Intended status: Experimental Ericsson
	Expires: April 29, 2010 October 26, 2009		Expires: September 9, 2010 March 8, 2010
	Host Identity Protocol (HIP) Multi-hop Routing Extension		Host Identity Protocol (HIP) Multi-hop Routing Extension
	draft-ietf-hip-via-00.txt		draft-ietf-hip-via-01.txt
			Abstract
			This document specifies two extensions to HIP to implement multi-hop
			routing. The first extension allows implementing source routing in
			HIP. That is, a host sending a HIP packet can define a set of hosts
			that the HIP packet should traverse. The second extension allows a
			HIP packet to carry and record the list of hosts that forwarded it.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 40
	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 29, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document specifies two extensions to HIP to implement multi-hop		described in the BSD License.
	routing. The first extension allows implementing source routing in
	HIP. That is, a host sending a HIP packet can define a set of hosts
	that the HIP packet should traverse. The second extension allows a
	HIP packet to carry and record the list of hosts that forwarded it.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
	2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Protocol Definitions . . . . . . . . . . . . . . . . . . . . . 3		3. Protocol Definitions . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Creating and Processing Via Lists . . . . . . . . . . . . . 3		3.1. Creating and Processing Via Lists . . . . . . . . . . . . . 4
	3.2. Creating Destination Lists . . . . . . . . . . . . . . . . 4		3.2. Creating Destination Lists . . . . . . . . . . . . . . . . 4
	3.3. Processing Destination Lists . . . . . . . . . . . . . . . 4		3.3. Processing Destination Lists . . . . . . . . . . . . . . . 5
	4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Source and Destination Route List Parameters . . . . . . . 5		4.1. Source and Destination Route List Parameters . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	6.1. Forwarding Loops . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	When HIP [RFC5201] is used in certain contexts (e.g., in a HIP BONE		When HIP [RFC5201] is used in certain contexts, hosts need the
	[I-D.ietf-hip-bone] overlay), hosts need the ability to perform		ability to perform source routing. That is, a host needs the ability
	source routing. That is, a host needs the ability to send a HIP		to send a HIP packet that will traverse a set of hosts before
	packet that will traverse a set of hosts before reaching its		reaching its destination. Such features are needed, e.g., in HIP
	destination. This document defines an extension that provides HIP		BONE [I-D.ietf-hip-bone] overlay networks or if two hosts wish to
	with this functionality.		keep a third, or more, HIP hosts on the signaling path. This
			document defines an extension that provides HIP with this
			functionality.
	Additionally, when HIP packets are routed through multiple hosts,		Additionally, when HIP packets are routed through multiple hosts,
	some of these hosts (e.g., the destination host) need the ability to		some of these hosts (e.g., the destination host) need the ability to
	know the hosts a particular packet traversed. This document defines		know the hosts a particular packet traversed. This document defines
	another extension that provides HIP with this functionality.		another extension that provides HIP with this functionality.
	These two extensions enable multi-hop routing in HIP. Before these		These two extensions enable multi-hop routing in HIP. Before these
	extensions were specified, HIP only supported a single intermediate		extensions were specified, there were standardized ways for
	host (i.e., a rendezvous server [RFC5204]) between the source of a		supporting only a single intermediate host (e.g., a rendezvous server
	HIP packet and its destination.		[RFC5204]) between the source of a HIP packet and its destination.
	2. Terminology		2. Terminology
	2.1. Requirements Language		2.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2.2. Definitions		2.2. Definitions
			The following terms used in this document are similar to those
			defined by RELOAD [I-D.ietf-p2psip-base] but used here in context of
			HIP.
	Destination list: A list of HITs of the hosts that a HIP packet		Destination list: A list of HITs of the hosts that a HIP packet
	should traverse.		should traverse.
	Via list: A list of HITs of the hosts that a HIP packet has		Via list: A list of HITs of the hosts that a HIP packet has
	traversed.		traversed.
	Symmetric routing: A response to a message is routed back using the		Symmetric routing: A response to a message is routed back using the
	same set of intermediary nodes as the original message used,		same set of intermediary nodes as the original message used,
	except in reversed order.		except in reversed order. Also known as symmetric recursive
			routing.
	3. Protocol Definitions		3. Protocol Definitions
			The multi-hop routing extensions may be used in different contexts
			and whether a new HIP packet should, for example, include a Via list
			or have different options enabled, can depend on the particular use
			case, local policies, and different protocols using the extension.
			This section defines how the new parameters are handled, but when to
			use these extensions is out of scope for this document.
	3.1. Creating and Processing Via Lists		3.1. Creating and Processing Via Lists
	When a host sending a HIP packet needs to record the hosts that are		When a host sending a HIP packet needs to record the hosts that are
	on the path that the HIP packet traverses, it includes an empty		on the path that the HIP packet traverses, it includes an empty
	ROUTE_VIA parameter to the packet.		ROUTE_VIA parameter to the packet.
	A host that receives a packet with a ROUTE_VIA parameter SHOULD add		A host that receives a packet with a ROUTE_VIA parameter SHOULD add
	its own HIT to the end of the ROUTE_VIA parameter, unless it is the		its own HIT to the end of the ROUTE_VIA parameter, unless it is the
	receiver of the packet. If the host uses a different HIT on the HIP		receiver of the packet. If the host uses a different HIT on the HIP
	association it used for receiving the packet than for sending it		association it used for receiving the packet than for sending it
	forward, it SHOULD also add the receiving HIT to the route list		forward, it SHOULD also add the receiving HIT to the route list
	before the sending HIT.		before the sending HIT.
	If the host is the receiver of the packet, and the received packet		If the host is the receiver of the packet, and the received packet
	generates a response HIP packet, the host checks the SYMMETRIC flag		generates a response HIP packet, the host checks the SYMMETRIC flag
	from the ROUTE_VIA parameter. If the SYMMETRIC flag is set, the host		from the ROUTE_VIA parameter. If the SYMMETRIC flag is set, the host
	SHOULD create a ROUTE_DST parameter from the ROUTE_VIA parameter, as		MUST create a ROUTE_DST parameter from the ROUTE_VIA parameter, as
	described in Section 3.2, and include it in the response packet.		described in Section 3.2, and include it in the response packet.
	Also, if an intermediary host generates a new HIP packet (e.g., an		Also, if an intermediary host generates a new HIP packet (e.g., an
	error NOTIFY packet) due to a HIP packet that had a ROUTE_VIA		error NOTIFY packet) due to a HIP packet that had a ROUTE_VIA
	parameter with SYMMETRIC flag set, and the new packet is intended for		parameter with SYMMETRIC flag set, and the new packet is intended for
	the sender of the original HIP packet, the host SHOULD construct and		the sender of the original HIP packet, the host SHOULD construct and
	add a ROUTE_DST parameter into the new packet as in the previous		add a ROUTE_DST parameter into the new packet as in the previous
	case.		case.
	3.2. Creating Destination Lists		3.2. Creating Destination Lists
	skipping to change at page 4, line 45		skipping to change at page 5, line 11
	parameter to the ROUTE_DST parameter, but in reversed order. This		parameter to the ROUTE_DST parameter, but in reversed order. This
	results in HIP response packet being forwarded using the same set of		results in HIP response packet being forwarded using the same set of
	hosts as the packet for which the response was generated for.		hosts as the packet for which the response was generated for.
	3.3. Processing Destination Lists		3.3. Processing Destination Lists
	When a host receives a HIP packet that contains a ROUTE_DST		When a host receives a HIP packet that contains a ROUTE_DST
	parameter, it first looks up its own HIT from the route list. If		parameter, it first looks up its own HIT from the route list. If
	host's own HIT is not in the list and the host is not the receiver of		host's own HIT is not in the list and the host is not the receiver of
	the packet, the packet was incorrectly forwarded and MUST be dropped.		the packet, the packet was incorrectly forwarded and MUST be dropped.
	Next hop for the packet is the HIT after host's own HIT in the list.		If the host's HIT is in the list more than once, the list is invalid
	If the host's HIT was the last HIT in the list, the next hop is the		and the packet MUST be dropped to avoid forwarding loops. Next hop
			for the packet is the HIT after host's own HIT in the list. If the
			host's HIT was the last HIT in the list, the next hop is the
	receiver's HIT in the HIP header.		receiver's HIT in the HIP header.
			If the MUST_FOLLOW flag in the ROUTE_DST parameter is not set, the
			host SHOULD check whether it has a valid locator for one of the hosts
			later in the list, or for the receiver of the packet, and it MAY
			select such a host as the next hop. If the MUST_FOLLOW flag is set,
			the host MUST NOT skip any hosts in the list.
			If the host has a valid locator for the next hop, it MUST forward the
			HIP packet to the next hop host. If the host can not determine a
			valid locator for the next hop host, it SHOULD drop the packet and
			SHOULD send back a NOTIFY error packet with type UNKNOWN_NEXT_HOP
			(value [TBD by IANA; 90]). The Notification Data field for the error
			notifications SHOULD contain the HIP header of the rejected packet
			and the ROUTE_DST parameter.
	4. Packet Formats		4. Packet Formats
	This memo defines two new HIP parameters that are used for recording		This memo defines two new HIP parameters that are used for recording
	a route via multiple hosts (ROUTE_VIA) and to define a route a packet		a route via multiple hosts (ROUTE_VIA) and for defining a route a
	should traverse by the sender of the packet (ROUTE_DST).		packet should traverse by the sender of the packet (ROUTE_DST).
	The ROUTE_DST parameter is integrity protected with the signature		The ROUTE_DST parameter is integrity protected with the signature
	(where present) but ROUTE_VIA is not so that intermediary hosts can		(where present) but ROUTE_VIA is not so that intermediary hosts can
	add their own HITs to the list. Both parameters have critical type		add their own HITs to the list. Both parameters have critical type
	(as defined in Section 5.2.1 of [RFC5201]) since the packet will not		(as defined in Section 5.2.1 of [RFC5201]) since the packet will not
	be properly routed unless all hosts on path recognize the parameters.		be properly routed unless all hosts on path recognize the parameters.
	4.1. Source and Destination Route List Parameters		4.1. Source and Destination Route List Parameters
	0 1 2 3		0 1 2 3
	skipping to change at page 5, line 46		skipping to change at page 6, line 38
	Type [ TBD by IANA		Type [ TBD by IANA
	ROUTE_DST: 971		ROUTE_DST: 971
	ROUTE_VIA: 65525 ]		ROUTE_VIA: 65525 ]
	Length length in octets, excluding Type and Length		Length length in octets, excluding Type and Length
	(i.e., number-of-HITs * 16 + 4)		(i.e., number-of-HITs * 16 + 4)
	Flags bit flags that can be used for requesting special		Flags bit flags that can be used for requesting special
	handling of the parameter		handling of the parameter
	Reserved reserved for future use		Reserved reserved for future use
	HIT Host Identity Tag of one of the hosts on the path		HIT Host Identity Tag of one of the hosts on the path
	Figure 1: Format of the ROUTE_VIA and ROUTE_DST parameters		Figure 1: Format of the ROUTE_VIA and ROUTE_DST Parameters
	Figure 1 shows the format of both ROUTE_VIA and ROUTE_DST parameters.		Figure 1 shows the format of both ROUTE_VIA and ROUTE_DST parameters.
	The ROUTE_DST parameter, if present, MUST have at least one HIT, but		The ROUTE_DST parameter, if present, MUST have at least one HIT, but
	the ROUTE_VIA parameter can also have zero HITs. Both can contain at		the ROUTE_VIA parameter can also have zero HITs. Both can contain at
	most 32 HITs. The Flags field is used for requesting special		most 32 HITs. The Flags field is used for requesting special
	handling for certain Route lists. The flags defined in this document		handling for via and destination lists. The flags defined in this
	are shown in Table 1. The Reserved field can be used by future		document are shown in Table 1. The Reserved field can be used by
	extensions; it MUST be zero when sending and ignored when receiving		future extensions; it MUST be zero when sending and ignored when
	this parameter.		receiving this parameter.
	+-----+-----------+-------------------------------------------------+		+-----+-------------+-----------------------------------------------+
	| Pos | Name | Purpose |		| Pos | Name | Purpose |
	+-----+-----------+-------------------------------------------------+		+-----+-------------+-----------------------------------------------+
	| 0 | SYMMETRIC | The response packet MUST be sent using |		| 0 | SYMMETRIC | The response packet MUST be sent with a |
	| | | ROUTE_DST list made from this ROUTE_VIA list, |		| | | ROUTE_DST list made from the ROUTE_VIA list |
	| | | i.e., using symmetric routing. |		| | | containing this flag, i.e., using symmetric |
	+-----+-----------+-------------------------------------------------+		| | | routing. |
			| 1 | MUST_FOLLOW | All the hosts in a ROUTE_DST list MUST be |
			| | | traversed, i.e., even if a host would have a |
			| | | valid locator for a host beyond the next hop, |
			| | | it MUST NOT forward the packet there but to |
			| | | the next hop host. |
			+-----+-------------+-----------------------------------------------+
	Table 1: Bit flags in ROUTE_VIA parameter		Table 1: Bit Flags in ROUTE_VIA and ROUTE_DST Parameters
	The "Pos" column in Table 1 shows the bit position of the flag (as in		The "Pos" column in Table 1 shows the bit position of the flag (as in
	Figure 1) in the Flags field, "Name" gives the name of the flag used		Figure 1) in the Flags field, "Name" gives the name of the flag used
	in this document, and "Purpose" gives brief description of the		in this document, and "Purpose" gives brief description of the
	meaning of that flag.		meaning of that flag.
			The flags apply to both ROUTE_VIA and ROUTE_DST parameters and when a
			ROUTE_DST parameter is added to a packet because of a ROUTE_VIA
			parameter, the same flags MUST be copied to the ROUTE_DST parameter.
	5. IANA Considerations		5. IANA Considerations
	This section is to be interpreted according to [RFC5226].		This section is to be interpreted according to [RFC5226].
	This document updates the IANA Registry for HIP Parameter Types		This document updates the IANA Registry for HIP Parameter Types
	[RFC5201] by assigning new HIP Parameter Type values for the new HIP		[RFC5201] by assigning new HIP Parameter Type values for the new HIP
	Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 4).		Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 4). This
			document also defines a new Notify Packet Type [RFC5201]
			UNKNOWN_NEXT_HOP in Section 3.3.
	6. Security Considerations		6. Security Considerations
	6.1. Forwarding Loops
	A malicious host could craft a destination route list that contains		A malicious host could craft a destination route list that contains
	the same HIT more than once and thus create a forwarding loop. Since		the same HIT more than once and thus create a forwarding loop. The
	the IP layer TTL is decremented on each hop, the loop will be		check described in Section 3.3 should break such loops but hosts MAY
	eventually broken, but hosts may additionally protect themselves		in addition utilize the OVERLAY_TTL [I-D.ietf-hip-bone] parameter for
	against this attack by checking that their own HIT is in the		additional protection against forwarding loops.
	destination list only once and drop invalid packets.
	7. References		7. Acknowledgments
	7.1. Normative References
			Tom Henderson provided valuable comments and improvement suggestions
			for this document.
			8. References
			8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,		[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
	"Host Identity Protocol", RFC 5201, April 2008.		"Host Identity Protocol", RFC 5201, April 2008.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		8.2. Informative References
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.
	7.2. Informative References
	[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", RFC 5204, April 2008.		Rendezvous Extension", RFC 5204, April 2008.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[I-D.ietf-hip-bone]		[I-D.ietf-hip-bone]
	Camarillo, G., Nikander, P., Hautakorpi, J., and A.		Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
	Johnston, "HIP BONE: Host Identity Protocol (HIP) Based		and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
	Overlay Networking Environment", draft-ietf-hip-bone-02		Based Overlay Networking Environment",
	(work in progress), July 2009.		draft-ietf-hip-bone-04 (work in progress), January 2010.
			[I-D.ietf-p2psip-base]
			Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
			H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
			Base Protocol", draft-ietf-p2psip-base-07 (work in
			progress), February 2010.
	Authors' Addresses		Authors' Addresses
	Gonzalo Camarillo		Gonzalo Camarillo
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	02420 Jorvas		02420 Jorvas
	Finland		Finland
	Email: Gonzalo.Camarillo@ericsson.com		Email: Gonzalo.Camarillo@ericsson.com
	skipping to change at page 7, line 36		skipping to change at page 9, line 4
	Authors' Addresses		Authors' Addresses
	Gonzalo Camarillo		Gonzalo Camarillo
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	02420 Jorvas		02420 Jorvas
	Finland		Finland
	Email: Gonzalo.Camarillo@ericsson.com		Email: Gonzalo.Camarillo@ericsson.com
	Ari Keranen		Ari Keranen
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	02420 Jorvas		02420 Jorvas
	Finland		Finland
	Email: ari.keranen@ericsson.com		Email: Ari.Keranen@ericsson.com
End of changes. 30 change blocks.
	76 lines changed or deleted		130 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/