draft-ietf-hip-applications-01.txt		draft-ietf-hip-applications-02.txt
	Network Working Group T. Henderson		Network Working Group T. Henderson
	Internet-Draft The Boeing Company		Internet-Draft The Boeing Company
	Intended status: Informational P. Nikander		Intended status: Informational P. Nikander
	Expires: October 11, 2007 Ericsson Research NomadicLab		Expires: May 21, 2008 Ericsson Research NomadicLab
	April 9, 2007		M. Komu
			Helsinki Institute for Information
			Technology
			November 18, 2007
	Using the Host Identity Protocol with Legacy Applications		Using the Host Identity Protocol with Legacy Applications
	draft-ietf-hip-applications-01		draft-ietf-hip-applications-02
	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 35		skipping to change at page 1, line 38
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 11, 2007.		This Internet-Draft will expire on May 21, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Host Identity Protocol (HIP) and architecture proposes to add a		This document is an informative overview of how legacy applications
	cryptographic name space for network stack names. From an		can be made to work with the Host Identity Protocol (HIP). HIP
	application viewpoint, HIP-enabled systems support a new address		proposes to add a cryptographic name space for network stack names.
	family of host identifiers, but it may be a long time until such HIP-		From an application viewpoint, HIP-enabled systems support a new
	aware applications are widely deployed even if host systems are		address family of host identifiers, but it may be a long time until
	upgraded. This informational document discusses implementation and		such HIP-aware applications are widely deployed even if host systems
	API issues relating to using HIP in situations in which the system is		are upgraded. This informational document discusses implementation
	HIP-aware but the applications are not.		and Application Programming Interface (API) issues relating to using
			HIP in situations in which the system is HIP-aware but the
			applications are not, and is intended to aid implementors and early
			adopters in thinking about and locally solving systems issues
			regarding the incremental deployment of HIP.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Approaches for supporting legacy applications . . . . . . . . 5		3. Approaches for supporting legacy applications . . . . . . . . 5
	3.1. Using IP addresses in applications . . . . . . . . . . . . 5		3.1. Using IP addresses in applications . . . . . . . . . . . . 5
	3.2. Using DNS to map domain names to HIs . . . . . . . . . . . 6		3.2. Using DNS to map domain names to HIs . . . . . . . . . . . 7
	3.3. Connecting directly to a HIT . . . . . . . . . . . . . . . 8		3.3. Connecting directly to a HIT . . . . . . . . . . . . . . . 8
	3.4. Local address management . . . . . . . . . . . . . . . . . 8		3.4. Local address management . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Informative References . . . . . . . . . . . . . . . . . . . . 13		7. Informative References . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Changes from previous versions . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		A.1. From version-01 to version-02 (current) . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Host Identity Protocol (HIP) [1] is an experimental effort in the		The Host Identity Protocol (HIP) [1] is an experimental effort in the
	IETF and IRTF to study a new public-key-based name space for use as		IETF and IRTF to study a new public-key-based name space for use as
	host identifiers in Internet protocols. Fully deployed, the HIP		host identifiers in Internet protocols. Fully deployed, the HIP
	architecture will permit applications to explicitly request the		architecture would permit applications to explicitly request the
	system to send packets to another named host by expressing a		system to send packets to another host by expressing a location-
	location-independent name of the host when the system call to send		independent name of the host when the system call to send packets is
	packets is performed. However, there will be a transition period		performed. However, there will be a transition period during which
	during which systems become HIP-enabled but applications are not.		systems become HIP-enabled but applications are not. This
			informational document does not propose normative specification or
			even suggest that different HIP implementations use more uniform
			methods for legacy application support, but is intended instead to
			aid implementors and early adopters in thinking about and solving
			systems issues regarding the incremental deployment of HIP.
	When applications and systems are both HIP-aware, the coordination		When applications and systems are both HIP-aware, the coordination
	between the application and the system can be straightforward. For		between the application and the system can be straightforward. For
	example, using the terminology of the widely used sockets Application		example, using the terminology of the widely used sockets Application
	Programming Interface (API), the application can issue a system call		Programming Interface (API), the application can issue a system call
	to send packets to another host by naming it explicitly, and the		to send packets to another host by naming it explicitly, and the
	system can perform the necessary name-to-address mapping to assign		system can perform the necessary name-to-address mapping to assign
	appropriate routable addresses to the packets. To enable this, a new		appropriate routable addresses to the packets. To enable this, a new
	address family for hosts could be defined, and additional API		address family for hosts could be defined, and additional API
	extensions could be defined (such as allowing IP addresses to be		extensions could be defined (such as allowing IP addresses to be
	passed in the system call, along with the host name, as hints of		passed in the system call, along with the host name, as hints of
	where to initially try to reach the host).		where to initially try to reach the host).
	This note does not define a native HIP API such as described above.		This document does not define a native HIP API such as described
	Rather, this note is concerned with the scenario in which the		above. Rather, this document is concerned with the scenario in which
	application is not HIP-aware and a traditional IP-address-based API		the application is not HIP-aware and a traditional IP-address-based
	is used by the application. To use HIP in such a situation, there		API is used by the application. To use HIP in such a situation,
	are a few basic possibilities: i) allow applications to use IP		there are a few basic possibilities: i) allow applications to use IP
	addresses as before, and provide a mapping from IP address to host		addresses as before, and provide a mapping from IP address to host
	identifier (and back to IP address) within the system, ii) take		identifier (and back to IP address) within the system, ii) take
	advantage of domain name resolution to provide the application with		advantage of domain name resolution to provide the application with
	either an alias for the host identifier or (in the case of IPv6) the		either an alias for the host identifier or (in the case of IPv6) the
	host identity tag (HIT) itself, and iii) support the use of HITs		host identity tag (HIT) itself, and iii) support the use of HITs
	directly (without prior DNS resolution) in place of IPv6 addresses.		directly (without prior DNS resolution) in place of IPv6 addresses.
	This note describes several variations of the above strategies and		This document describes several variations of the above strategies
	suggests some pros and cons to each approach.		and points out tradeoffs with each approach.
	When HITs are used (rather than IP addresses) as peer names at the		When HITs are used (rather than IP addresses) as peer names at the
	system API level, they can provide a type of "channel binding"		system API level, they can provide a type of "channel binding" in
	(Section 1.1.6 of [2]) in that the ESP association formed by HIP is		that the Encapsulating Security Payload (ESP) association formed by
	cryptographically bound to the name (HIT) invoked by the calling		HIP is cryptographically bound to the name (HIT) invoked by the
	application.		calling application.
	2. Terminology		2. Terminology
	Host Identity: An abstract concept applied to a computing platform.		Host Identity: An abstract concept applied to a computing platform.
	Host Identifier (HI): A public key of an asymmetric key pair used as		Host Identifier (HI): A public key of an asymmetric key pair used as
	a name for a Host Identity. More details are available in [1].		a name for a Host Identity. More details are available in [1].
	Host Identity Tag (HIT): A 128-bit quantity composed with the hash		Host Identity Tag (HIT): A 128-bit quantity composed with the hash
	of a Host Identity. More details are available in [3] and [1].		of a Host Identity. More details are available in [2] and [1].
	Local Scope Identifier (LSI): A 32- or 128-bit quantity locally		Local Scope Identifier (LSI): A 32- or 128-bit quantity locally
	representing the Host Identity at the IPv4 or IPv6 API.		representing the Host Identity at the IPv4 or IPv6 API.
	Referral: An event when the application passes what it believes to		Referral: An event when the application passes what it believes to
	be an IP address to another application instance on another host,		be an IP address to another application instance on another host,
	within its application data stream. An example is the FTP PORT		within its application data stream. An example is the FTP PORT
	command.		command.
	Resolver: The system function used by applications to resolve domain		Resolver: The system function used by applications to resolve domain
	names to IP addresses.		names to IP addresses.
	3. Approaches for supporting legacy applications		3. Approaches for supporting legacy applications
	This section provides examples of how legacy applications, using		This section provides examples of how legacy applications, using
	legacy APIs, can operate over a HIP-enabled system and use HIP. The		legacy APIs, can operate on a HIP-enabled system and use HIP. The
	examples are organized by the name used by an application (or		examples are organized by the name used by an application (or
	application user) to name the peer system: an IP address, a domain		application user) to name the peer system: an IP address, a domain
	name, or a HIT. Finally, some local address management issues are		name, or a HIT. Finally, some local address management issues are
	discussed.		discussed.
	While the text below concentrates on the use of the sockets connect		Applications use IP addresses as short-lived local handles, long-
	system call, the same argument is also valid for other system calls		lived application associations, callbacks, referrals, and identity
	using socket addresses.		comparisons. Each of the below mechanisms has implications on these
			different uses of IP addresses by legacy applications.
	Recent work in the shim6 group has categorized the ways in which
	current applications use IP addresses [4]. These uses include short-
	lived local handles, long-lived application associations, callbacks,
	referrals, and identity comparisons. Each of the below mechanisms
	has implications on these different uses of IP addresses by legacy
	applications.
	3.1. Using IP addresses in applications		3.1. Using IP addresses in applications
	Consider the case in which an application issues a "connect(ip)"		Consider the case in which an application issues a "connect(ip)"
	system call to set the default destination to a system named by		system call to set the default destination to a system named by
	address "ip", but for which we would like to enable HIP to protect		address "ip", but for which we would like to enable HIP to protect
	the communications. Since the application or user does not (can not)		the communications. Since the application or user can not indicate a
	indicate a desire to use HIP through the standard sockets API, the		desire to use HIP through the standard sockets API when IP addresses
	decision to invoke HIP must be done on the basis of host policy. For		are used, the decision to invoke HIP must be done on the basis of
	example, if an IPsec-like implementation of HIP is being used, a		host policy. For example, when an IPsec-based implementation of HIP
	policy may be entered into the security policy database that mandates		is being used, a policy may be entered into the security policy
	to use or try HIP based on a match on the source or destination IP		database that mandates to use or try HIP based on a match on the
	address, or other factors. The mapping of IP address to host		source or destination IP address, or other factors. The mapping of
	identifier may be implemented by modifying the host operating system		IP address to host identifier may be implemented by modifying the
	or by wrapping the existings sockets API, such as in the TESLA		host operating system or by wrapping the existing sockets API, such
	approach [5].		as in the TESLA approach [3].
	There are a number of ways that HIP could be used in such a scenario.		There are a number of ways that HIP could be used in such a scenario.
	Manual configuration:		Manual configuration:
	Pre-existing SAs may be available due to previous administrative		Pre-existing SAs may be available due to previous administrative
	action.		action, or a binding between an IP address and a HIT could be
			stored in a configuration file or database.
	Opportunistically:		Opportunistically:
	The system could send an I1 to the Responder with an empty value		The system could send an I1 to the Responder with an empty value
	for Responder HIT.		for Responder HIT.
	Using DNS to map IP addresses to HIs:		Using DNS to map IP addresses to HIs:
	If the responder has host identifiers registered in the forward		If the responder has host identifiers registered in the forward
	DNS zone and has a PTR record in the reverse zone, the initiating		DNS zone and has a PTR record in the reverse zone, the Initiator
	system could perform a reverse+forward lookup to learn the HIT		could perform a reverse+forward lookup to learn the HIT associated
	associated with the address. Alternatively, the HIT could be		with the address. Although the approach should work under normal
	stored in some type of HIP name service such as a distributed hash		circumstances, it has not been tested to verify that there are no
	table (DHT), keyed by IP address. Unless secured with DNS		recursion or bootstrapping issues, particularly if HIP is used to
			secure the connection to the DNS servers. Unless secured with DNS
	security extensions, the use of the reverse DNS map is subject to		security extensions, the use of the reverse DNS map is subject to
	well-known security limitations (an attacker may cause an		well-known security limitations (an attacker may cause an
	incorrect IP address to domain name binding to occur).		incorrect IP address to domain name binding to occur).
	These types of solutions have the benefit of better supporting		Using the opportunistic mode or using DNS in the above fashion can
	applications that use IP addresses for long-lived application		cause additional setup delays compared to using plain IP. For
	associations, callbacks, and referrals. They have weaker security		opportunistic mode, a host must wait to learn whether the peer is
	properties than the approaches outlined in Section 3.2 and		HIP-capable, although the delays may be mitigated in some
	Section 3.3, however, because the binding between host identifier and		implementations by sending initial packets (e.g., TCP SYN) in
	address is weak and not visible to the application or user. In fact,		parallel to the HIP I1 packet. For DNS lookups, there are resolution
	the semantics of the application's "connect(ip)" call may be		latencies.
			Solutions preserving the use of IP addresses in the applications have
			the benefit of better support for applications that use IP addresses
			for long-lived application associations, callbacks, and referrals,
			although it should be noted that applications are discouraged from
			using IP addresses in this manner due to the frequent presence of
			NATs [4] and Section 3.3, because the binding between host identifier
			and address is weak and not visible to the application or user. In
			fact, the semantics of the application's "connect(ip)" call may be
	interpreted as "connect me to the system reachable at IP address ip"		interpreted as "connect me to the system reachable at IP address ip"
	but perhaps no stronger semantics than that. HIP can be used in this		but perhaps no stronger semantics than that. HIP can be used in this
	case to provide perfect forward secrecy and authentication, but not		case to provide perfect forward secrecy and authentication, but not
	to strongly authenticate the peer at the onset of communications.		to strongly authenticate the peer at the onset of communications.
	DNS with security extensions (DNSSEC) [6], if trusted, may be able to		DNS with security extensions (DNSSEC) [5] could be used to
	provide some additional initial authentication, but at a cost of		authenticate the bindings between IP address and host identifier, if
	initial resolution latency. Note that this usage does not		the necessary DNSSEC records were available and trusted.
	necessarily reveal to the user of the legacy application that HIP is
	being used.		The legacy application is unaware of HIP and cannot therefore notify
			the user when the application uses HIP. However, the operating
			system can notify the user of the usage of HIP through a user agent.
			Further, it is possible for the user agent to name the network
			application that caused a HIP-related event. This way, the user is
			aware when he or she is using HIP even though the legacy network
			application is not.
	Using IP addresses at the application layer may not provide the full		Using IP addresses at the application layer may not provide the full
	potential benefits of HIP mobility support. It allows for mobility		potential benefits of HIP mobility support. It allows for mobility
	if one is able to readdress the existing sockets upon a HIP readdress		if the system is able to readdress long-lived, connected sockets upon
	event. However, mobility will break in the connectionless case when		a HIP readdress event. However, as in current systems, mobility will
	an application caches the IP address and repeatedly calls sendto().		break in the connectionless case, when an application caches the IP
			address and repeatedly calls sendto(), or in the case of TCP when the
			system later opens additional sockets to the same destination.
			Section 4.1.6 of the base HIP protocol specification [1] states that
			implementations that learn of HIT-to-IP address bindings through the
			use of HIP opportunistic mode must not enforce those bindings on
			later communications sessions. This implies that when IP addresses
			are used by the applications, systems that attempt to
			opportunistically set up HIP must not assume that later sessions to
			the same address will communicate with the same host.
	3.2. Using DNS to map domain names to HIs		3.2. Using DNS to map domain names to HIs
	In the previous section, it was pointed out that a HIP-enabled system		In the previous section, it was pointed out that a HIP-enabled system
	might make use of DNS to transparently fetch host identifiers prior		might make use of DNS to transparently fetch host identifiers prior
	to the onset of communication. For applications that make use of		to the onset of communication. For applications that make use of
	DNS, the name resolution process is another opportunity to use HIP.		DNS, the name resolution process is another opportunity to use HIP.
	If host identifiers are bound to domain names (with a trusted DNS)		If host identifiers are bound to domain names (with a trusted DNS),
	the following are possible:		the following are possible:
	Return HIP LSIs and HITs instead of IP addresses:		Return HIP LSIs and HITs instead of IP addresses:
	The system resolver could be configured to return a Local Scope		The system resolver could be configured to return a Local Scope
	Identifier (LSI) or HIT rather than an IP address, if HIP		Identifier (LSI) or HIT rather than an IP address, if HIP
	information is available in the DNS that binds a particular domain		information is available in the DNS that binds a particular domain
	name to a host identifier, and otherwise to return an IP address		name to a host identifier, and otherwise to return an IP address
	as usual. The system can then maintain a mapping between LSI and		as usual. The system can then maintain a mapping between LSI and
	host identifier and perform the appropriate conversion at the		host identifier and perform the appropriate conversion at the
	system call interface or below. The application uses the LSI or		system call interface or below. The application uses the LSI or
	HIT as it would an IP address.		HIT as it would an IP address. This technique has been used in
			overlay networking experiments such as the Internet Indirection
			Infrastructure (i3).
	Locally use a HIP-specific domain name suffix:		Locally use a HIP-specific domain name prefix:
	One drawback to spoofing the DNS resolution is that some		One drawback to spoofing the DNS resolution is that some
	applications actually may want to fetch IP addresses (e.g.,		applications actually may want to fetch IP addresses (e.g.,
	diagnostic applications such as ping). One way to provide finer		diagnostic applications such as ping, or processes that generate
	granularity on whether the resolver returns an IP address or an		system log files). One way to provide finer granularity on
	LSI is to distinguish by the presence of a domain name suffix.		whether the resolver returns an IP address or an LSI is to
	Specifically, if the application requests to resolve		distinguish by the presence of a domain name prefix.
	"www.example.com.hip" (or some similar suffix), then the system		Specifically, if the application requests to resolve "HIP-
			www.example.com" (or some similar prefix string), then the system
	returns an LSI, while if the application requests to resolve		returns an LSI, while if the application requests to resolve
	"www.example.com", IP address(es) are returned as usual. Caution		"www.example.com", IP address(es) are returned as usual. The use
	against the use of domain name suffixes is discussed in [7].		of a prefix rather than suffix is recommended, and the use of a
			string delimiter that is not a dot (".") is also recommended, to
			reduce the likelihood that such modified DNS names are mistakenly
			treated as names rooted at a new top-level domain.
			Fetch HIP records transparently:
			A third option would be for the system to opportunistically query
			for HIP records in parallel to other DNS resource records, and to
			temporarily cache the HITs returned with a DNS lookup, indexed by
			the IP addresses returned in the same entry, and pass the IP
			addresses up to the application as usual. If an application
			connects to one of those IP addresses within a short time after
			the lookup, initiate a base exchange using the cached HITs. The
			benefit is that this removes the uncertainty/delay associated with
			opportunistic HIP, because the DNS record suggests that the peer
			is HIP-capable.
	Since the LSI or HIT is non-routable, a couple of potential hazards		Since the LSI or HIT is non-routable, a couple of potential hazards
	arise, in the case of referrals, callbacks, and long-lived		arise, in the case of referrals, callbacks, and long-lived
	application associations. First, applications that perform referrals		application associations. First, applications that perform referrals
	may pass the LSI to another system that has no system context to		may pass the LSI to another system that has no system context to
	resolve the LSI back to a host identifier or an IP address. Note		resolve the LSI back to a host identifier or an IP address. Note
	that these are the same type of applications that will likely break		that these are the same type of applications that will likely break
	if used over certain types of network address translators (NATs).		if used over certain types of network address translators (NATs).
	Second, applications may cache the results of DNS queries for a long		Second, applications may cache the results of DNS queries for a long
	time, and it may be hard for a HIP system to determine when to		time, and it may be hard for a HIP system to determine when to
	perform garbage collection on the LSI bindings. However, when using		perform garbage collection on the LSI bindings. However, when using
	HITs, the security of using the HITs for identity comparison may be		HITs, the security of using the HITs for identity comparison may be
	stronger than in the case of using IP addresses.		stronger than in the case of using IP addresses.
	It may be possible for an LSI or HIT to be routable or resolvable,		It may be possible for an LSI or HIT to be routable or resolvable,
	either directly or on an overlay. For example, a special IP address		either directly or through an overlay, in which case it would be
	that has some location invariance is the identifier-address discussed		preferable for applications to handle such names instead of IP
	in [8]. A term other than LSI may be needed for these routable		addresses. However, such networks are out of scope of this document.
	identifiers, since they would no longer be locally scoped. When
	using DNS, returning a routable identifier would avoid the
	aforementioned problems with referrals. However, the cost of
	routability may be that the hash binding between the routable
	identifier and the host identifier would be weakened, since more bits
	may be allocated to the hierarchical part.
	3.3. Connecting directly to a HIT		3.3. Connecting directly to a HIT
	The previous two sections describe the use of IP addresses and LSIs		The previous two sections describe the use of IP addresses and LSIs
	as local handles to a host identifier. A third approach, for IPv6		as local handles to host identifiers. A third approach, for IPv6
	applications, is to configure the application to connect directly to		applications, is to configure the application to connect directly to
	a HIT (e.g., "connect(HIT)" as a socket call). Although more		a HIT (e.g., "connect(HIT)" as a socket call). This scenario has
	cumbersome for human users (due to the flat HIT name space) than
	using either IPv6 addresses or domain names, this scenario has
	stronger security semantics, because the application is asking the		stronger security semantics, because the application is asking the
	system to send packets specifically to the named peer system. HITs		system to send packets specifically to the named peer system. HITs
	have been defined as Overlay Routable Cryptographic Hash Identifiers		have been defined as Overlay Routable Cryptographic Hash Identifiers
	(ORCHIDs) such that they cannot be confused with routable IP		(ORCHIDs) such that they cannot be confused with routable IP
	addresses; see [3].		addresses; see [2].
	Another challenge with this approach is in actually finding the IP
	addresses to use, based on the HIT. Some type of HIT resolution
	service would be needed in this case.
	A third challenge of this approach is in supporting callbacks and		This approach also has a few challenges. Using HITs can be more
	referrals to possibly non-HIP-aware hosts. However, since most		cumbersome for human users (due to the flat HIT name space) than
	communications in this case would likely be to other HIP-aware hosts		using either IPv6 addresses or domain names, Another challenge with
	(else the initial HIP associations would fail to establish), the		this approach is in actually finding the IP addresses to use, based
	problem may otherwise be that the peer host supports HIP but is not		on the HIT. Some type of HIT resolution service would be needed in
	able to perform HIT resolution for some reason.		this case. A third challenge of this approach is in supporting
			callbacks and referrals to possibly non-HIP-aware hosts. However,
			since most communications in this case would likely be to other HIP-
			aware hosts (else the initial HIP associations would fail to
			establish), the resulting referral problem may be that the peer host
			supports HIP but is not able to perform HIT resolution for some
			reason.
	3.4. Local address management		3.4. Local address management
	The previous sections focused mainly on client behavior (HIP		The previous sections focused mainly on client behavior (HIP
	initiator). We must also consider the behavior for servers.		initiator). We must also consider the behavior for servers.
	Typically, a server may bind to a wildcard IP address and well-known		Typically, a server binds to a wildcard IP address and well-known
	port. In the case of HIP use with legacy server implementations,		port. In the case of HIP use with legacy server implementations,
	there are again a few options. As in Section 3.1 above, the system		there are again a few options. As in Section 3.1 above, the system
	may be configured manually to always, optionally (depending on the		may be configured manually to always, optionally (depending on the
	client behavior), or never use HIP with a particular service, as a		client behavior), or never use HIP with a particular service, as a
	matter of policy, when the server specifies a wildcard (IP) address.		matter of policy, when the server specifies a wildcard (IP) address.
	When a system API call such as getaddrinfo [9] is used for resolving		When a system API call such as getaddrinfo [6] is used for resolving
	local addresses, it may also return HITs or LSIs, if the system has		local addresses, it may also return HITs or LSIs, if the system has
	assigned HITs or LSIs to internal virtual interfaces (common in many		assigned HITs or LSIs to internal virtual interfaces (common in many
	HIP implementations). The application may use such identifiers as		HIP implementations). The application may use such identifiers as
	addresses in subsequent socket calls.		addresses in subsequent socket calls.
			In the case when resolvers can return multiple destination
			identifiers for an application, it may be configured that some of the
			identifiers can be HIP-based identifiers, and the rest can be IPv4 or
			IPv6 addresses. The system resolver may return HIP-based identifiers
			in front of the list of identifiers when the underlying system and
			policies support HIP. An application processing the identifiers
			sequentially will then first try a HIP-based connection and only then
			other non-HIP based connections. However, certain applications may
			launch the connections in parallel. In such a case, the non-HIP
			connections may succeed before HIP connections. Based on local
			system policies, a system may disallow such behaviour and return only
			HIP-based identifiers when they are found from DNS.
	Some applications may try to bind a socket to a specific local		Some applications may try to bind a socket to a specific local
	address. If the local address specified is an IP address, again, the		address, or may implement server-side access control lists based on
	underlying system may be configured to still use HIP. If the local		socket calls such as getsockname() and getpeername() in the C-based
	address specified is a HIT (Section 3.3), the system should enforce		socket APIs. If the local address specified is an IP address, again,
	that connections can only come to the specified HIT. If a system has		the underlying system may be configured to still use HIP. If the
	many HITs, an application that binds to a single HIT cannot accept		local address specified is a HIT (Section 3.3), the system should
	connections to the other HITs in the system. It may be possible for		enforce that connections to the local application can only arrive to
	a system to specify a special ORCHID value as a local HIT wildcard		the specified HIT. If a system has many HITs, an application that
	value, if such wildcarding among local HIs is desired.		binds to a single HIT cannot accept connections to the other HITs in
			the system.
	When a host has multiple HIs and the socket behavior does not		When a host has multiple HIs and the socket behavior does not
	prescribe the use of any particular HI as a source identifier, it is		prescribe the use of any particular HI as a local identifier, it is a
	a matter of local policy as to how to select a HI to serve as a		matter of local policy as to how to select a HI to serve as a local
	source identifier.		identifier. However, systems that bind to a wildcard may face
			problems when multiple HITs or LSIs are defined. These problems are
			not specific to HIP per se, but are also encountered in non-HIP
			multihoming scenarios with applications not designed for multihoming.
			As an example, consider a client application that sends an UDP
			datagram to a server that is bound to a wildcard. The server
			application receives the packet using recvfrom() and sends a response
			using sendto(). The problem here is that sendto() may actually use a
			different server HIT than the client assumes. The client will drop
			the response packet when the client implements access control on the
			UDP socket (e.g. using connect()).
			Reimplementing the server application using the sendmsg() and
			recvmsg() to support multihoming (particularly considering the
			anchillary data) would be the ultimate solution to this problem, but
			with legacy applications is not an option. As a workaround, we make
			suggestion for servers providing UDP-based services with non-
			multihoming capable services. Such servers should announce only the
			HIT that matches to the default outgoing HIT of the host to avoid
			such problems.
			Finally, some applications may create a connection to a local HIT.
			In such a case, the local system may use NULL encryption to avoid
			unnecessary encryption overhead, and may be otherwise more permissive
			than usual such as excluding authentication, Diffie-Hellman exchange,
			and puzzle.
	4. Security Considerations		4. Security Considerations
	In this section we discuss the security of the system in general		In this section we discuss the security of the system in general
	terms, outlining some of the security properties. However, this		terms, outlining some of the security properties. However, this
	section is not intended to provide a complete risk analysis. Such an		section is not intended to provide a complete risk analysis. Such an
	analysis would, in any case, be dependent on the actual application		analysis would, in any case, be dependent on the actual application
	using HIP, and is therefore considered out of scope.		using HIP, and is therefore considered out of scope.
	The three outlined scenarios differ considerably in their security		The three outlined scenarios differ considerably in their security
	properties. There are further differences related to whether DNSSEC		properties. There are further differences related to whether DNSSEC
	is used or not, and whether the DNSSEC zones are considered		is used or not, and whether the DNSSEC zones are considered
	trustworthy enough from an application point of view.		trustworthy enough. Here we mean that the delegation chain from the
			reverse IP root should be trusted (typical trust anchor issues), and
			the DNS zone administrators in charge of the netblock should be
			trusted to put in the right information.
	When IP addresses are used to represent the peer system, the security		When IP addresses are used to represent the peer system, the security
	properties depend on the the configuration method. With manual		properties depend on the the configuration method. With manual
	configuration, the security of the system is comparable to a non-HIP		configuration, the security of the system is comparable to a non-HIP
	system with similar IPsec policies. The security semantics of an		system with similar IPsec policies. The security semantics of an
	opportunistic key exchange are roughly equal to current non-secured		initial opportunistic key exchange are roughly equal to non-secured
	IP; the exchange is vulnerable to man-in-the-middle attacks.		IP; the exchange is vulnerable to man-in-the-middle attacks.
	However, the system is less vulnerable to connection hijacking		However, the system is less vulnerable to connection hijacking
	attacks. If the DNS is used, if both maps are secured (or the HITs		attacks. If the DNS is used, if both zones are secured (or the HITs
	stored in the reverse DNS record) and the client trusts the DNSSEC		are stored in the reverse DNS record) and the client trusts the
	signatures, the system may provide a fairly high security level.		DNSSEC signatures, the system may provide a fairly high security
	However, much depends on the details of the implementation, the		level. However, much depends on the details of the implementation,
	security and administrative practises used when signing the DNS		the security and administrative practices used when signing the DNS
	zones, and other factors.		zones, and other factors.
	Using the forward DNS to map a domain name into an LSI is a case that		Using the forward DNS to map a domain name into an LSI is a case that
	is closest to the most typical use scenarios today. If DNSSEC is		is closest to the most typical use scenarios today. If DNSSEC is
	used, the result is fairly similar to the current use of certificates		used, the result is fairly similar to the current use of certificates
	with TLS. If DNSSEC is not used, the result is fairly similar to the		with TLS. If DNSSEC is not used, the result is fairly similar to the
	current use of plain IP, with the exception that HIP provides		current use of plain IP, with the exception that HIP provides
	protection against connection hijacking attacks.		protection against connection hijacking attacks.
	If the application is basing its operations on HITs, the connections		If the application is basing its operations on HITs, the connections
	become automatically secured due to the implicit channel bindings in		become automatically secured due to the implicit channel bindings in
	HIP. That is, when the application makes a connect(HIT) system call,		HIP. That is, when the application makes a connect(HIT) system call,
	the resulting packets will either be sent to a node possessing the		the resulting packets will either be sent to a node possessing the
	corresponding private key or the security association will fail to be		corresponding private key or the security association will fail to be
	established.		established.
			When the system provides (spoofs) LSIs or HITs instead of IP
			addresses as the result of name resolution, the resultant fields may
			inadvertently show up in user interfaces and system logs, which may
			cause operational concerns for some network administrators.
	5. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	6. Acknowledgments		6. Acknowledgments
	Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Miika Komu, Teemu		Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen,
	Koponen, Julien Laganier, and Jukka Ylitalo have provided comments on		Julien Laganier, and Jukka Ylitalo have provided comments on
	different versions of this draft.		different versions of this draft. Erik Nordmark provided the
			taxonomy of how applications use IP addresses in a previously expired
			Internet Draft. The document received substantial and useful
			comments during the review phase from David Black, Pekka Savola, Lars
			Eggert, and the DNS directorate.
	7. Informative References		7. Informative References
	[1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07		[1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host
	(work in progress), February 2007.		Identity Protocol", draft-ietf-hip-base-10 (work in progress),
			October 2007.
	[2] Linn, J., "Generic Security Service Application Program
	Interface Version 2, Update 1", RFC 2743, January 2000.
	[3] Nikander, P., "An IPv6 Prefix for Overlay Routable Cryptographic
	Hash Identifiers (ORCHID)", draft-laganier-ipv6-khi-07 (work in
	progress), February 2007.
	[4] Nordmark, E., "Shim6 Application Referral Issues",		[2] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for
	draft-ietf-shim6-app-refer-00 (work in progress), July 2005.		Overlay Routable Cryptographic Hash Identifiers (ORCHID)",
			RFC 4843, April 2007.
	[5] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A		[3] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A
	Transparent, Extensible Session-Layer Architecture for End-to-		Transparent, Extensible Session-Layer Architecture for End-to-
	end Network Services", Proceedings of USENIX Symposium on		end Network Services", Proceedings of USENIX Symposium on
	Internet Technologies and Systems (USITS), pages 211-224,		Internet Technologies and Systems (USITS), pages 211-224,
	March 2003.		March 2003.
	[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[4] Carpenter, B., "Architectural Principles of the Internet",
			RFC 1958, June 1996.
			[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"DNS Security Introduction and Requirements", RFC 4033,		"DNS Security Introduction and Requirements", RFC 4033,
	March 2005.		March 2005.
	[7] Faltstrom, P., "Design Choices When Expanding DNS",		[6] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
	draft-iab-dns-choices-04 (work in progress), October 2006.
	[8] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
	protocol", draft-ietf-shim6-proto-07 (work in progress),
	December 2006.
	[9] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
	Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,		Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
	February 2003.		February 2003.
			Appendix A. Changes from previous versions
			This section is to be removed by the RFC Editor before publication.
			It summarizes resolution of issues raised in the following reviews:
			(1) IESG last call, (2) Gen-ART review, and (3) DNS directorate
			review. Mobility and secdir reviews did not result in actionable
			comments.
			A.1. From version-01 to version-02 (current)
			Better clarity in the abstract and introduction about the goal of the
			draft; namely, that it is informational to help implementors and
			early adopters think about and solve deployment issues (comment from
			Pekka Savola).
			Delete the second paragraph of 3 about the general applicability of
			replacing IP addresses with LSIs and HITs at the socket layer.
			(comment from Pekka Savola).
			Delete comments in Section 3.2 on routable LSIs, as this is seen to
			be out of scope and potentially controversial or incomplete (comment
			from David Black).
			Delete reference to Erik Nordmark's shim6 application referral draft,
			since it is a dead draft (comment from David Black). Instead, Erik
			is cited in the acknowledgments section for providing the taxonomy of
			IP address usage scenarios.
			Clarify (and reference the base spec) in Sec. 3.1 that use of the
			opportunistic mode requires that systems not enforce that the
			HIT-to-IP address bindings learned will pertain to subsequent
			sessions to that IP address.
			Section 3.2 drew comments from several reviewers. First, David Black
			raised the issue that spoofing IP addresses with HITs or LSIs raises
			risks that it may turn up in log records; this has been noted in the
			text. The section on using a DNS suffix to signal the preferred use
			of HIP was objected to by members of the DNS directorate and others
			(including the co-author Pekka Nikander), due to concern that queries
			to a new TLD might leak out. The current draft instead recommends a
			DNS prefix instead of suffix, due to a suggestion by Thomas Narten.
			In section 3.1, clarify recursion issues that may arise when doing
			reverse+forward lookup of HIP records from DNS (comment from Pekka
			Savola).
			Clarify more specifically in security considerations section the
			DNSSEC trust assumptions or security considerations (outline of text
			provided by Pekka Savola, and similar comment raised by Peter Koch).
			Clarified in security considerations section that IP address spoofing
			could cause some operational difficulties if they unexpectedly show
			up in log files or UIs (comment from David Black).
			Clarified in Sec. 3.1 that opportunistic and DNS techniques can incur
			additional latency when compared to plain IP (comment from Lars
			Eggert)
			Added third option to Section 3.2 for using DNS (transparently
			fetching HIP resource records when doing other RR queries), suggested
			by Lars Eggert and also by Olaf Kolkman.
			Incorporated last-call comments from Miika Komu, which were all
			handled in Section 3.4: i) clarify multihoming issue for servers with
			multiple HITs, when receiving UDP, ii) clarify a problem that might
			arise for applications that do parallel connect, and iii) suggest
			that loopback HIP connections could use a NULL encryption.
			Removed expired references and updated active references.
			Incorporated additional review comments from Miika Komu, and some
			suggested replacement text, and added him as a co-author.
	Authors' Addresses		Authors' Addresses
	Tom Henderson		Thomas Henderson
	The Boeing Company		The Boeing Company
	P.O. Box 3707		P.O. Box 3707
	Seattle, WA		Seattle, WA
	USA		USA
	Email: thomas.r.henderson@boeing.com		Email: thomas.r.henderson@boeing.com
	Pekka Nikander		Pekka Nikander
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	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
			Miika Komu
			Helsinki Institute for Information Technology
			Metsaenneidonkuja 4
			Helsinki FIN-02420
			FINLAND
			Phone: +358503841531
			Email: miika@iki.fi
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
End of changes. 47 change blocks.
	158 lines changed or deleted		331 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/