draft-ietf-hip-bone-01.txt		draft-ietf-hip-bone-02.txt
	HIP Working Group G. Camarillo		HIP Working Group G. Camarillo
	Internet-Draft P. Nikander		Internet-Draft P. Nikander
	Expires: September 10, 2009 J. Hautakorpi		Intended status: Experimental J. Hautakorpi
	Ericsson		Expires: January 7, 2010 Ericsson
	A. Johnston		A. Johnston
	Avaya		Avaya
	March 9, 2009		July 6, 2009
	HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking		HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking
	Environment		Environment
	draft-ietf-hip-bone-01.txt		draft-ietf-hip-bone-02.txt
	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 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 September 10, 2009.		This Internet-Draft will expire on January 7, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 27		skipping to change at page 2, line 27
	2. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3		2. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 3		2.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 3
	2.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 4		2.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 4
	2.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 4		2.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 4
	2.1.3. Locator Management . . . . . . . . . . . . . . . . . . 5		2.1.3. Locator Management . . . . . . . . . . . . . . . . . . 5
	2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 5		2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6		2.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6
	2.3.2. Identifier Assignment and Authentication . . . . . . . 6		2.3.2. Identifier Assignment and Authentication . . . . . . . 6
	2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7		2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7
	2.4. HIP Deployability and Legacy Applications . . . . . . . . 8		2.4. HIP Deployability and Legacy Applications . . . . . . . . 7
	3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8		3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8
	3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9		3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9
	3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10		3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10
	3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11		3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11
	3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11		3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11
	4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12		4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12
	5. RELOAD-based HIP BONE Instance Specification . . . . . . . . . 12		5. Architectural Considerations . . . . . . . . . . . . . . . . . 12
	5.1. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	5.2. Peer ID to ORCHID Transformation . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	5.3. Mapping between Protocol Primitives and HIP Messages . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6. Architectural Considerations . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The Host Identity Protocol (HIP) [RFC5201] defines a new name space		The Host Identity Protocol (HIP) [RFC5201] defines a new name space
	between the network and transport layers. HIP provides upper layers		between the network and transport layers. HIP provides upper layers
	with mobility, multihoming, NAT (Network Address Translation)		with mobility, multihoming, NAT (Network Address Translation)
	traversal, and security functionality. HIP implements the so called		traversal, and security functionality. HIP implements the so called
	identifier/locator (ID/locator) split, which implies that IP		identifier/locator (ID/locator) split, which implies that IP
	addresses are only used as locators, not as host identifiers. This		addresses are only used as locators, not as host identifiers. This
	split makes HIP a suitable protocol to build overlay networks that		split makes HIP a suitable protocol to build overlay networks that
	implement identifier-based overlay routing over IP networks, which in		implement identifier-based overlay routing over IP networks, which in
	turn implement locator-based routing.		turn implement locator-based routing.
	The remainder of this document is organized as follows. Section 2		The remainder of this document is organized as follows. Section 2
	provides background information on HIP. Section 3 describes the HIP		provides background information on HIP. Section 3 describes the HIP
	BONE (HIP-Based Overlay Networking Environment) framework. Section 4		BONE (HIP-Based Overlay Networking Environment) framework. Section 4
	discusses some of the advantages derived from using the HIP BONE		discusses some of the advantages derived from using the HIP BONE
	framework. Section 5 contains the RELOAD-based HIP BONE instance		framework. Finally, before the customary sections, Section 5
	specification. Finally, before the customary sections, Section 6
	attempts to put the presented proposal into a larger architectural		attempts to put the presented proposal into a larger architectural
	context.		context.
	2. Background on HIP		2. Background on HIP
	This section provides background on HIP. Given the tutorial nature		This section provides background on HIP. Given the tutorial nature
	of this section, readers that are familiar with what HIP provides and		of this section, readers that are familiar with what HIP provides and
	how HIP works may want to skip it. All descriptions contain		how HIP works may want to skip it. All descriptions contain
	references to the relevant HIP specifications where readers can find		references to the relevant HIP specifications where readers can find
	detailed explanations on the different topics discussed in this		detailed explanations on the different topics discussed in this
	skipping to change at page 4, line 20		skipping to change at page 4, line 19
	TCP connection is able to survive locator changes because the remote		TCP connection is able to survive locator changes because the remote
	host's identifier does not change.		host's identifier does not change.
	2.1.1. Identifier Format		2.1.1. Identifier Format
	HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash		HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash
	Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6		Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6
	addresses but cannot collide with regular IPv6 addresses because		addresses but cannot collide with regular IPv6 addresses because
	ORCHID spaces are registered with the IANA. That is, a portion of		ORCHID spaces are registered with the IANA. That is, a portion of
	the IPv6 address space is reserved for ORCHIDs. The ORCHID		the IPv6 address space is reserved for ORCHIDs. The ORCHID
	specification allows the creation of multiple disjoint identifier		specification allows creating multiple disjoint identifier spaces.
	spaces. Each such space is identified by a separate Context		Each such space is identified by a separate Context Identifier. The
	Identifier. The Context Identifier can be either drawn implicitly		Context Identifier can be either drawn implicitly from the context
	from the context the ORCHID is used in or carried explicitly in a		the ORCHID is used in or carried explicitly in a protocol.
	protocol.
	HIP defines a native socket API [I-D.ietf-hip-native-api] that		HIP defines a native socket API [I-D.ietf-hip-native-api] that
	applications can use to establish and manage connections.		applications can use to establish and manage connections.
	Additionally, HIP can also be used through the traditional IPv4 and		Additionally, HIP can also be used through the traditional IPv4 and
	IPv6 TCP/IP socket APIs. Section 2.4 describes how an application		IPv6 TCP/IP socket APIs. Section 2.4 describes how an application
	using these traditional APIs can make use of HIP. Figure 1 shows all		using these traditional APIs can make use of HIP. Figure 1 shows all
	these APIs between the application and the transport layers.		these APIs between the application and the transport layers.
	+-----------------------------------------+		+-----------------------------------------+
	| Application |		| Application |
	skipping to change at page 5, line 44		skipping to change at page 5, line 43
	traffic. If any of the hosts changes its set of locators, it runs an		traffic. If any of the hosts changes its set of locators, it runs an
	update exchange [RFC5206], which consists of three messages. If a		update exchange [RFC5206], which consists of three messages. If a
	host is multihomed, it simply provides more than one locator in its		host is multihomed, it simply provides more than one locator in its
	exchanges. However, if both of the end points move at the same time,		exchanges. However, if both of the end points move at the same time,
	or through some other reason both lose track of the peers' currently		or through some other reason both lose track of the peers' currently
	active locators, they need to resort to using a rendezvous server or		active locators, they need to resort to using a rendezvous server or
	getting new peer locators by some other means.		getting new peer locators by some other means.
	2.2. NAT Traversal		2.2. NAT Traversal
	HIP's NAT traversal mechanism is based on ICE (Interactive		HIP's NAT traversal mechanism [I-D.ietf-hip-nat-traversal] is based
	Connectivity Establishment) [I-D.ietf-mmusic-ice]. Hosts gather		on ICE (Interactive Connectivity Establishment)
	address candidates and, as part of the HIP base exchange, hosts		[I-D.ietf-mmusic-ice]. Hosts gather address candidates and, as part
	perform an ICE offer/answer exchange where they exchange their		of the HIP base exchange, hosts perform an ICE offer/answer exchange
	respective address candidates. Hosts perform end-to-end STUN		where they exchange their respective address candidates. Hosts
	[RFC5389] based connectivity checks in order to discover which		perform end-to-end STUN [RFC5389] based connectivity checks in order
	address candidate pairs yield connectivity.		to discover which address candidate pairs yield connectivity.
	Even though, architecturally, HIP lies below the transport layer		Even though, architecturally, HIP lies below the transport layer
	(i.e., HIP packets are carried directly in IP packets), in presence		(i.e., HIP packets are carried directly in IP packets), in presence
	of NATs, HIP sometimes needs to be tunneled in a transport protocol		of NATs, HIP sometimes needs to be tunneled in a transport protocol
	(i.e., HIP packets are carried by a transport protocol such as UDP).		(i.e., HIP packets are carried by a transport protocol such as UDP).
	2.3. Security		2.3. Security
	Security is an essential part of HIP. The following sections		Security is an essential part of HIP. The following sections
	describe the security-related functionality provided by HIP.		describe the security-related functionality provided by HIP.
	skipping to change at page 6, line 45		skipping to change at page 6, line 41
	pre-generated R1 packets within the overlay and let the overlay		pre-generated R1 packets within the overlay and let the overlay
	directly respond with R1s to I1s. In that way the responder is not		directly respond with R1s to I1s. In that way the responder is not
	bothered at all until the initiator sends an I2 packet, with the		bothered at all until the initiator sends an I2 packet, with the
	puzzle solution. Furthermore, a more sophisticated overlay could		puzzle solution. Furthermore, a more sophisticated overlay could
	verify that an I2 packet has a correctly solved puzzle before		verify that an I2 packet has a correctly solved puzzle before
	forwarding the packet to the responder.		forwarding the packet to the responder.
	2.3.2. Identifier Assignment and Authentication		2.3.2. Identifier Assignment and Authentication
	As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main		As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main
	representation identifiers. Potentially, HIP can use different types		representation for identifiers. Potentially, HIP can use different
	of ORCHIDs as long as the probability of finding collisions (i.e.,		types of ORCHIDs as long as the probability of finding collisions
	two nodes with the same ORCHID) is low enough. One way to completely		(i.e., two nodes with the same ORCHID) is low enough. One way to
	avoid this type of collision is to have a central authority generate		completely avoid this type of collision is to have a central
	and assign ORCHIDs to nodes. To secure the binding between ORCHIDs		authority generate and assign ORCHIDs to nodes. To secure the
	and any higher-layer identifiers, every time the central authority		binding between ORCHIDs and any higher-layer identifiers, every time
	assigns an ORCHID to a node, it also generates and signs a		the central authority assigns an ORCHID to a node, it also generates
	certificate stating who is the owner of the ORCHID. The owner of the		and signs a certificate stating who is the owner of the ORCHID. The
	ORCHID then includes the corresponding certificate in its R1 (when		owner of the ORCHID then includes the corresponding certificate in
	acting as responder) and I2 packets (when acting initiator) to prove		its R1 (when acting as responder) and I2 packets (when acting
	that it is actually allowed to use the ORCHID and, implicitly, the		initiator) to prove that it is actually allowed to use the ORCHID
	associated public key.		and, implicitly, the associated public key.
	Having a central authority works well to completely avoid collisions.		Having a central authority works well to completely avoid collisions.
	However, having a central authority is impractical in some scenarios.		However, having a central authority is impractical in some scenarios.
	As defined today, HIP systems generally use a self-certifying ORCHID		As defined today, HIP systems generally use a self-certifying ORCHID
	type called HIT (Host Identity Tag) that does not require a central		type called HIT (Host Identity Tag) that does not require a central
	authority (but still allows one to be used).		authority (but still allows one to be used).
	A HIT is the hash of a node's public key. A node proves that it has		A HIT is the hash of a node's public key. A node proves that it has
	the right to use a HIT by showing its ability to sign data with its		the right to use a HIT by showing its ability to sign data with its
	associated private key. This scheme is secure due to the so called		associated private key. This scheme is secure due to the so called
	skipping to change at page 8, line 18		skipping to change at page 8, line 11
	[I-D.ietf-hip-native-api] that applications can use to establish and		[I-D.ietf-hip-native-api] that applications can use to establish and
	manage connections. New applications can implement this API to get		manage connections. New applications can implement this API to get
	full advantage of HIP. However, in most cases, legacy (i.e., non-HIP		full advantage of HIP. However, in most cases, legacy (i.e., non-HIP
	aware) applications [RFC5338] can use HIP through the traditional		aware) applications [RFC5338] can use HIP through the traditional
	IPv4 and IPv6 socket APIs.		IPv4 and IPv6 socket APIs.
	The idea is that when a legacy IPv6 application tries and obtains a		The idea is that when a legacy IPv6 application tries and obtains a
	remote host's IP address (e.g., by querying the DNS) the DNS resolver		remote host's IP address (e.g., by querying the DNS) the DNS resolver
	passes the remote host's ORCHID (which was also stored in the DNS) to		passes the remote host's ORCHID (which was also stored in the DNS) to
	the legacy application. At the same time, the DNS resolver stores		the legacy application. At the same time, the DNS resolver stores
	stores the remote host's IP address internally at the HIP module.		the remote host's IP address internally at the HIP module. Since the
	Since the ORCHID looks like an IPv6 address, the legacy application		ORCHID looks like an IPv6 address, the legacy application treats it
	treats it as such. It opens a connection (e.g., TCP) using the		as such. It opens a connection (e.g., TCP) using the traditional
	traditional IPv6 socket API. The HIP module running in the same host		IPv6 socket API. The HIP module running in the same host as the
	as the legacy application intercepts this call somehow (e.g., using		legacy application intercepts this call somehow (e.g., using an
	an interception library or setting up the host's routing tables so		interception library or setting up the host's routing tables so that
	that the HIP module receives the traffic) and runs HIP (on behalf of		the HIP module receives the traffic) and runs HIP (on behalf of the
	the legacy application) towards the IP address corresponding to the		legacy application) towards the IP address corresponding to the
	ORCHID. This mechanism works well in almost all cases. However,		ORCHID. This mechanism works well in almost all cases. However,
	applications involving referrals (i.e., passing of IPv6 addresses		applications involving referrals (i.e., passing of IPv6 addresses
	between applications) present issues, to be discussed in Section 3		between applications) present issues, to be discussed in Section 3
	below. Additionally, management applications that care about the		below. Additionally, management applications that care about the
	exact IP address format may not work well with such straigthforward		exact IP address format may not work well with such straigthforward
	approach.		approach.
	In order to make HIP work through the traditional IPv4 socket API,		In order to make HIP work through the traditional IPv4 socket API,
	the HIP module passes an LSI (Local Scope Identifier), instead of a		the HIP module passes an LSI (Local Scope Identifier), instead of a
	regular IPv4 address, to the legacy IPv4 application. The LSI looks		regular IPv4 address, to the legacy IPv4 application. The LSI looks
	skipping to change at page 9, line 27		skipping to change at page 9, line 19
	The HIP BONE framework uses HIP to perform connection management.		The HIP BONE framework uses HIP to perform connection management.
	Data storage and retrieval and overlay maintenance are to be		Data storage and retrieval and overlay maintenance are to be
	implemented using protocols other than HIP. For lack of a better		implemented using protocols other than HIP. For lack of a better
	name, these protocols are referred to as peer protocols.		name, these protocols are referred to as peer protocols.
	HIP BONE is a generic framework that allows the use of different peer		HIP BONE is a generic framework that allows the use of different peer
	protocols. A particular HIP BONE instance uses a particular peer		protocols. A particular HIP BONE instance uses a particular peer
	protocol. The details on how to implement a HIP BONE using a given		protocol. The details on how to implement a HIP BONE using a given
	peer protocol need to be specified in a, so called, HIP BONE instance		peer protocol need to be specified in a, so called, HIP BONE instance
	specification. Section 3.4 discusses what details need to be		specification. Section 3.4 discusses what details need to be
	specified by HIP BONE instance specifications. Section 5 contains		specified by HIP BONE instance specifications. For example, the HIP
	the RELOAD-based HIP BONE instance specification.		BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is
			specified in [I-D.keranen-hip-reload-instance].
	3.1. Peer ID Assignment and Bootstrap		3.1. Peer ID Assignment and Bootstrap
	Nodes in an overlay are primarily identified by their Peer IDs.		Nodes in an overlay are primarily identified by their Peer IDs.
	(Note that the Peer ID concept here is a peer-layer protocol concept,		(Note that the Peer ID concept here is a peer-layer protocol concept,
	distinct from the HIP-layer node identifiers. Peer IDs may be long,		distinct from the HIP-layer node identifiers. Peer IDs may be long,
	may have some structure, and may consist of multiple parts.)		may have some structure, and may consist of multiple parts.)
	Overlays typically have an enrollment server that can generate Peer		Overlays typically have an enrollment server that can generate Peer
	IDs, or at least some part of the Peer ID, and sign certificates. A		IDs, or at least some part of the Peer ID, and sign certificates. A
	certificate generated by an enrollment server authorizes a particular		certificate generated by an enrollment server authorizes a particular
	skipping to change at page 10, line 50		skipping to change at page 10, line 44
	overlay itself provides the rendezvous service.		overlay itself provides the rendezvous service.
	Therefore, in HIP BONE, a node uses an I1 packet (as usual) to		Therefore, in HIP BONE, a node uses an I1 packet (as usual) to
	establish a connection with another node in the overlay. Nodes in		establish a connection with another node in the overlay. Nodes in
	the overlay forward I1 packets in a hop-by-hop fashion according to		the overlay forward I1 packets in a hop-by-hop fashion according to
	the overlay's routing table towards its destination. This way, the		the overlay's routing table towards its destination. This way, the
	overlay provides a rendezvous service between the nodes establishing		overlay provides a rendezvous service between the nodes establishing
	the connection. If the overlay nodes have active connections with		the connection. If the overlay nodes have active connections with
	other nodes in their forwarding tables and if those connections are		other nodes in their forwarding tables and if those connections are
	protected (typically with IPsec ESP), I1 packets may be sent over		protected (typically with IPsec ESP), I1 packets may be sent over
	protected connections between nodes. Alternatively, if there no such		protected connections between nodes. Alternatively, if there is no
	an active connection but the node forwarding the I1 packet has a		such an active connection but the node forwarding the I1 packet has a
	valid locator for the next hop, the I1 packets may be forwarded		valid locator for the next hop, the I1 packets may be forwarded
	directly, in a similar fashion to how I1 packets are today forwarded		directly, in a similar fashion to how I1 packets are today forwarded
	by a HIP rendezvous server.		by a HIP rendezvous server.
	Since HIP supports NAT traversal, a HIP base exchange over the		Since HIP supports NAT traversal, a HIP base exchange over the
	overlay will perform an ICE offer/answer exchange between the nodes		overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer
	that are establishing the connection. In order to perform this		exchange between the nodes that are establishing the connection. In
	exchange, the nodes need to first gather candidate addresses. Which		order to perform this exchange, the nodes need to first gather
	nodes can be used to obtain reflexive address candidates and which		candidate addresses. Which nodes can be used to obtain reflexive
	ones can be used to obtain relayed candidates is defined by the peer		address candidates and which ones can be used to obtain relayed
	protocol.		candidates is defined by the peer protocol.
	3.3. Lightweight Message Exchanges		3.3. Lightweight Message Exchanges
	In some cases, nodes need to perform a lightweight query to another		In some cases, nodes need to perform a lightweight query to another
	node (e.g., a request followed by a single response). In this		node (e.g., a request followed by a single response). In this
	situation, establishing a connection using the mechanisms in		situation, establishing a connection using the mechanisms in
	Section 3.2 for a simple query would be an overkill. A better		Section 3.2 for a simple query would be an overkill. A better
	solution is to forward a HIP message through the overlay with the		solution is to forward a HIP message through the overlay with the
	query and another one with the response to the query. The payload of		query and another one with the response to the query. The payload of
	such HIP packets is integrity protected [I-D.nikander-hip-hiccups].		such HIP packets is integrity protected [I-D.nikander-hip-hiccups].
	Nodes in the overlay forward this HIP packet in a hop-by-hop fashion		Nodes in the overlay forward this HIP packet in a hop-by-hop fashion
	according to the overlay's routing table towards its destination,		according to the overlay's routing table towards its destination,
	typically through the protected connections established between them.		typically through the protected connections established between them.
	Again, the overlay acts as a rendezvous server between the nodes		Again, the overlay acts as a rendezvous server between the nodes
	exchanging the messages.		exchanging the messages.
	3.4. HIP BONE Instantiation		3.4. HIP BONE Instantiation
	As discussed in Section 3, HIP BONE is a generic framework that		As discussed in Section 3, HIP BONE is a generic framework that
	allows the use of different peer protocols. A particular HIP BONE		allows using different peer protocols. A particular HIP BONE
	instance uses a particular peer protocol. The details on how to		instance uses a particular peer protocol. The details on how to
	implement a HIP BONE using a given peer protocol need to be specified		implement a HIP BONE using a given peer protocol need to be specified
	in a, so called, HIP BONE instance specification. A HIP BONE		in a, so called, HIP BONE instance specification. A HIP BONE
	instance specification needs to define:		instance specification needs to define, minimally:
	o the peer protocol to be used.		o the peer protocol to be used.
	o how to transform the peer IDs used by the peer protocol into the		o how to transform the peer IDs used by the peer protocol into the
	ORCHIDs that will be used in HIP.		ORCHIDs that will be used in HIP.
	o which peer protocol primitives trigger HIP messages.		o which peer protocol primitives trigger HIP messages.
	Section 5 contains the RELOAD-based HIP BONE instance specification.		Additionally, a HIP BONE instance specification may need to specify
			other details that are specific to the peer protocol used.
			As an example, the HIP BONE instance specification for RELOAD
			[I-D.ietf-p2psip-base] is specified in
			[I-D.keranen-hip-reload-instance].
	It is assumed that areas not covered by a particular HIP BONE		It is assumed that areas not covered by a particular HIP BONE
	instance specification are specified by the peer protocol or		instance specification are specified by the peer protocol or
	elsewhere. These areas include:		elsewhere. These areas include:
	o the algorithm to create the overlay (e.g., a DHT).		o the algorithm to create the overlay (e.g., a DHT).
	o Overlay maintenance functions.		o overlay maintenance functions.
	o data storage and retrieval functions.		o data storage and retrieval functions.
	o format and structure of peer IDs.		o format and structure of peer IDs.
	o the process for obtaining a peer ID.		o the process for obtaining a peer ID.
	o overlay identification.		o overlay identification.
	o bootstrap function		o bootstrap function
	o how to select STUN and TURN servers for the candidate address		o how to select STUN and TURN servers for the candidate address
	collection process in NAT traversal scenarios.		collection process in NAT traversal scenarios.
	o for what type of traffic or messages it is appropriate to use		o for what type of traffic or messages it is appropriate to use
	lightweight message exchanges.		lightweight message exchanges.
	Note that the border between HIP BONE instance specification and a		Note that the border between HIP BONE instance specification and a
	peer protocol specifications is blurry. Depending on how generic the		peer protocol specifications is blurry. Depending on how generic the
	specification of a given peer protocol is, its associated HIP BONE		specification of a given peer protocol is, its associated HIP BONE
	instance specification may need to specify more or less details.		instance specification may need to specify more or less details.
	Also, a particular HIP BONE instance specification left certain areas		Also, a particular HIP BONE instance specification left certain areas
	unspecified in order to leave their configuration up to each		unspecified in order to leave their configuration up to each
	particular overlays.		particular overlay.
	4. Advantages of Using HIP BONE		4. Advantages of Using HIP BONE
	Using HIP BONE, as opposed to a peer protocol, to perform connection		Using HIP BONE, as opposed to a peer protocol, to perform connection
	management in an overlay has a set of advantages. HIP BONE can be		management in an overlay has a set of advantages. HIP BONE can be
	used by any peer protocol. This keeps each peer protocol from		used by any peer protocol. This keeps each peer protocol from
	defining primitives needed for connection management (e.g.,		defining primitives needed for connection management (e.g.,
	primitives to establish connections and to tunnel messages through		primitives to establish connections and to tunnel messages through
	the overlay) and NAT traversal. Having this functionality at a lower		the overlay) and NAT traversal. Having this functionality at a lower
	layer allows multiple upper-layer protocols to take advantage of it.		layer allows multiple upper-layer protocols to take advantage of it.
	Additionally, having a solution that integrates mobility and		Additionally, having a solution that integrates mobility and
	multihoming is useful in many scenarios. Peer protocols do not		multihoming is useful in many scenarios. Peer protocols do not
	typically specify mobility and multihoming solutions. Combining a		typically specify mobility and multihoming solutions. Combining a
	peer protocol including NAT traversal with a separate mobility		peer protocol including NAT traversal with a separate mobility
	mechanism and a separate multihoming mechanism can easily lead to		mechanism and a separate multihoming mechanism can easily lead to
	unexpected (and unpleasant) interactions.		unexpected (and unpleasant) interactions.
	5. RELOAD-based HIP BONE Instance Specification		5. Architectural Considerations
	This section specifies the RELOAD-based HIP BONE instance
	specification.
	5.1. Peer Protocol
	The peer protocol to be used is RELOAD, which is specified in
	[I-D.ietf-p2psip-base].
	5.2. Peer ID to ORCHID Transformation
	RELOAD uses 128 bit peer IDs called Node-IDs. Since HIP uses 128 bit
	ORCHIDs, a peer's RELOAD Node-ID is used as the peer's ORCHID.
	5.3. Mapping between Protocol Primitives and HIP Messages
	The Attach procedure in RELOAD establishes a connection between two
	peers. This procedure is performed using the AttachReq and AttachAns
	messages. When HIP is used, the Attach procedure is performed by
	using a HIP base exchange. That is, peers send HIP I1 messages
	instead of RELOAD AttachReq messages.
	The RELOAD AttachLite procedure is used for the same purpose as the
	Attach procedure in scenarios with no NATs. When HIP is used, the
	AttachLite procedure is also performed by using a HIP base exchange.
	That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq
	messages.
	OPEN ISSUE: The RELOAD forwarding header carries Via and Destination
	lists. We should have the same functionality in HIP so that I1s can
	be source routed and R1s can use symmetric routing. The destination
	HIT for the I1 packet would be the destination peer. The header
	fields defined in RFC 5204 (RVS) and in the NAT traversal draft can
	be used to implement that functionality or as templates to specify
	new header fields that implement that functionality.
	OPEN ISSUE: RELOAD mandates TLS. That is, it does not support plain
	TCP or UDP. If HIP is used like this, there will be double
	encryption (avoidable using a null encryption algorithm at one of the
	levels) and double authentication.
	6. Architectural Considerations
	Architecturally, HIP can be considered to create a new thin "waist"		Architecturally, HIP can be considered to create a new thin "waist"
	layer on the top of the IPv4 and IPv6 networks; see Figure 3. The		layer on the top of the IPv4 and IPv6 networks; see Figure 3. The
	HIP layer itself consist of the HIP signalling protocol and one or		HIP layer itself consists of the HIP signalling protocol and one or
	more data transport protocols; see Figure 4. The HIP signalling		more data transport protocols; see Figure 4. The HIP signalling
	packets and the data transport packets can take different routes. In		packets and the data transport packets can take different routes. In
	the HIP BONE, the HIP signalling packets are typically first routed		the HIP BONE, the HIP signalling packets are typically first routed
	through the overlay and then directly (if possible), while the data		through the overlay and then directly (if possible), while the data
	transport packets are typically routed only directly between the end		transport packets are typically routed only directly between the end
	points.		points.
	+--------------------------------------+		+--------------------------------------+
	| Transport (using HITs or LSIs) |		| Transport (using HITs or LSIs) |
	+--------------------------------------+		+--------------------------------------+
	skipping to change at page 14, line 22		skipping to change at page 13, line 24
	Figure 3: HIP as a thin waist		Figure 3: HIP as a thin waist
	+------------------+-------------------+		+------------------+-------------------+
	| HIP signalling | data transports |		| HIP signalling | data transports |
	+------------------+-------------------+		+------------------+-------------------+
	Figure 4: HIP layer structure		Figure 4: HIP layer structure
	In HIP BONE, the peer protocol creates a new signalling layer on the		In HIP BONE, the peer protocol creates a new signalling layer on the
	top of HIP signalling. It is used to set up forwarding paths for HIP		top of HIP. It is used to set up forwarding paths for HIP signalling
	signalling messages. This is a similar relationship that an IP		messages. This is a similar relationship that an IP routing
	routing protocol, such as OSPF, has to the IP protocol itself. In		protocol, such as OSPF, has to the IP protocol itself. In the HIP
	the HIP BONE case, the peer protocol plays a role similar to OSPF,		BONE case, the peer protocol plays a role similar to OSPF, and HIP
	and HIP plays a role similar to IP. The ORCHIDs are used for		plays a role similar to IP. The ORCHIDs are used for forwarding HIP
	forwarding HIP packets according to the information in the routing		packets according to the information in the routing tables. The peer
	tables. The peer protocols are used to exchange routing information		protocols are used to exchange routing information based on Peer IDs
	based on Peer IDs and public keys, and to construct the routing		and public keys, and to construct the routing tables.
	tables.
	Architecturally, routing tables are located between the peer protocol		Architecturally, routing tables are located between the peer protocol
	and HIP, as shown in Figure 5. The peer protocol constructs the		and HIP, as shown in Figure 5. The peer protocol constructs the
	routing table and keeps it updated. The HIP layer accesses the		routing table and keeps it updated. The HIP layer accesses the
	routing table in order to make routing decisions. The bootstrap of a		routing table in order to make routing decisions. The bootstrap of a
	HIP BONE overlay does not create circular dependencies between the		HIP BONE overlay does not create circular dependencies between the
	peer protocol (which needs to use HIP to establish connections with		peer protocol (which needs to use HIP to establish connections with
	other nodes) and HIP (which needs the peer protocol to know how to		other nodes) and HIP (which needs the peer protocol to know how to
	route messages to other nodes) for the same reasons as the bootstrap		route messages to other nodes) for the same reasons as the bootstrap
	of an IP network does not create circular dependencies between OSPF		of an IP network does not create circular dependencies between OSPF
	skipping to change at page 15, line 28		skipping to change at page 14, line 28
	very different. In order to make routing decisions, the HIP layer		very different. In order to make routing decisions, the HIP layer
	needs to convert the routing table generated by the peer protocol		needs to convert the routing table generated by the peer protocol
	into a forwarding table that allows the HIP layer select a next-hop		into a forwarding table that allows the HIP layer select a next-hop
	for any packet being routed.		for any packet being routed.
	In HIP BONE, the HIP usage of public keys and deriving ORCHIDs		In HIP BONE, the HIP usage of public keys and deriving ORCHIDs
	through a hash function can be utilised at the peer protocol side to		through a hash function can be utilised at the peer protocol side to
	better secure routing table maintenance and to protect against		better secure routing table maintenance and to protect against
	chosen-peer-ID attacks.		chosen-peer-ID attacks.
	The HIP BONE allows quite a lot of flexibility how to arrange the		The HIP BONE provides quite a lot of flexibility with regards to how
	different protocols in detail. Figure 6 shows one potential stack		to arrange the different protocols in detail. Figure 6 shows one
	structure.		potential stack structure.
	+-----------------------+--------------+		+-----------------------+--------------+
	| peer protocols | media |		| peer protocols | media |
	+------------------+----+--------------+		+------------------+----+--------------+
	| HIP signalling | data transport |		| HIP signalling | data transport |
	| |		| |
	+------------------+-------------------+		+------------------+-------------------+
	| NAT | non-NAT | |		| NAT | non-NAT | |
	| | |		| | |
	| IPv4 | IPv6 |		| IPv4 | IPv6 |
	+------------------+-------------------+		+------------------+-------------------+
	Figure 6: Example HIP BONE stack structure		Figure 6: Example HIP BONE stack structure
	7. Security Considerations		6. Security Considerations
	TBD.		This document provides a high-level framework to build HIP-based
			overlays. The security properties of HIP and its extensions used in
			this framework are discussed in their respective specifications.
			Those security properties can be affected by the way HIP is used in a
			particular overlay (e.g., by how ORCHIDs are derived from Peer IDs).
			However, those properties are mostly affected by the design decisions
			made to build a particular overlay; not so much by how this high-
			level framework is specified in this document. Such design decisions
			are typically documented in a HIP BONE instance specification, which
			will describe the security properties of the resulting overlay.
	8. Acknowledgements		7. Acknowledgements
	HIP BONE is based on ideas coming from conversations and discussions		HIP BONE is based on ideas coming from conversations and discussions
	with a number of people in the HIP and P2PSIP communities. In		with a number of people in the HIP and P2PSIP communities. In
	particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas		particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas
	Henderson, Bruce Lowekamp, and Miika Komu provided useful input on		Henderson, Bruce Lowekamp, and Miika Komu provided useful input on
	HIP BONE.		HIP BONE.
	9. IANA Considerations		8. IANA Considerations
	This document does not contain any IANA actions.		This document does not contain any IANA actions.
	10. Normative References		9. References
			9.1. Normative References
	[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix		[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
	for Overlay Routable Cryptographic Hash Identifiers		for Overlay Routable Cryptographic Hash Identifiers
	(ORCHID)", RFC 4843, April 2007.		(ORCHID)", RFC 4843, April 2007.
	[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.
	[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the		[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
	Encapsulating Security Payload (ESP) Transport Format with		Encapsulating Security Payload (ESP) Transport Format with
	skipping to change at page 16, line 45		skipping to change at page 16, line 9
	April 2008.		April 2008.
	[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-		[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
	Host Mobility and Multihoming with the Host Identity		Host Mobility and Multihoming with the Host Identity
	Protocol", RFC 5206, April 2008.		Protocol", RFC 5206, April 2008.
	[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host		[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
	Identity Protocol with Legacy Applications", RFC 5338,		Identity Protocol with Legacy Applications", RFC 5338,
	September 2008.		September 2008.
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	October 2008.
	[I-D.ietf-hip-native-api]		[I-D.ietf-hip-native-api]
	Komu, M. and T. Henderson, "Basic Socket Interface		Komu, M. and T. Henderson, "Basic Socket Interface
	Extensions for Host Identity Protocol (HIP)",		Extensions for Host Identity Protocol (HIP)",
	draft-ietf-hip-native-api-05 (work in progress),		draft-ietf-hip-native-api-06 (work in progress), May 2009.
	July 2008.
			[I-D.ietf-hip-nat-traversal]
			Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
			Keraenen, "Basic HIP Extensions for Traversal of Network
			Address Translators", draft-ietf-hip-nat-traversal-08
			(work in progress), June 2009.
	[I-D.nikander-hip-hiccups]		[I-D.nikander-hip-hiccups]
	Nikander, P., Camarillo, G., and J. Melen, "HIP (Host		Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
	Identity Protocol) Immediate Carriage and Conveyance of		Identity Protocol) Immediate Carriage and Conveyance of
	Upper- layer Protocol Signaling (HICCUPS)",		Upper- layer Protocol Signaling (HICCUPS)",
	draft-nikander-hip-hiccups-01 (work in progress),		draft-nikander-hip-hiccups-01 (work in progress),
	November 2008.		November 2008.
			9.2. Informative References
			[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
			"Session Traversal Utilities for NAT (STUN)", RFC 5389,
			October 2008.
	[I-D.ietf-mmusic-ice]		[I-D.ietf-mmusic-ice]
	Rosenberg, J., "Interactive Connectivity Establishment		Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols",		Traversal for Offer/Answer Protocols",
	draft-ietf-mmusic-ice-19 (work in progress), October 2007.		draft-ietf-mmusic-ice-19 (work in progress), October 2007.
	[I-D.ietf-p2psip-base]		[I-D.ietf-p2psip-base]
	Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and		Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
	H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)		H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
	Base Protocol", draft-ietf-p2psip-base-02 (work in		Base Protocol", draft-ietf-p2psip-base-02 (work in
	progress), March 2009.		progress), March 2009.
			[I-D.keranen-hip-reload-instance]
			Keranen, A. and G. Camarillo, "HIP BONE Instance
			Specification for RELOAD",
			draft-keranen-hip-reload-instance-00 (work in progress),
			July 2009.
	Authors' Addresses		Authors' Addresses
	Gonzalo Camarillo		Gonzalo Camarillo
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: Gonzalo.Camarillo@ericsson.com		Email: Gonzalo.Camarillo@ericsson.com
End of changes. 32 change blocks.
	131 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/