draft-ietf-hip-applications-03.txt		draft-ietf-hip-applications-04.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: December 30, 2008 Ericsson Research NomadicLab		Expires: January 8, 2009 Ericsson Research NomadicLab
	M. Komu		M. Komu
	Helsinki Institute for Information		Helsinki Institute for Information
	Technology		Technology
	June 28, 2008		July 7, 2008
	Using the Host Identity Protocol with Legacy Applications		Using the Host Identity Protocol with Legacy Applications
	draft-ietf-hip-applications-03		draft-ietf-hip-applications-04
	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 38		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 December 30, 2008.		This Internet-Draft will expire on January 8, 2009.
	Abstract		Abstract
	This document is an informative overview of how legacy applications		This document is an informative overview of how legacy applications
	can be made to work with the Host Identity Protocol (HIP). HIP		can be made to work with the Host Identity Protocol (HIP). HIP
	proposes to add a cryptographic name space for network stack names.		proposes to add a cryptographic name space for network stack names.
	From an application viewpoint, HIP-enabled systems support a new		From an application viewpoint, HIP-enabled systems support a new
	address family of host identifiers, but it may be a long time until		address family of host identifiers, but it may be a long time until
	such HIP-aware applications are widely deployed even if host systems		such HIP-aware applications are widely deployed even if host systems
	are upgraded. This informational document discusses implementation		are upgraded. This informational document discusses implementation
	skipping to change at page 2, line 39		skipping to change at page 2, line 39
	4.1. Connecting to a HIT or LSI . . . . . . . . . . . . . . . . 10		4.1. Connecting to a HIT or LSI . . . . . . . . . . . . . . . . 10
	4.2. Using a modified DNS name . . . . . . . . . . . . . . . . 10		4.2. Using a modified DNS name . . . . . . . . . . . . . . . . 10
	4.3. Other techniques . . . . . . . . . . . . . . . . . . . . . 11		4.3. Other techniques . . . . . . . . . . . . . . . . . . . . . 11
	5. Local address management . . . . . . . . . . . . . . . . . . . 12		5. Local address management . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	9. Informative References . . . . . . . . . . . . . . . . . . . . 18		9. Informative References . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. Changes from previous versions . . . . . . . . . . . 19		Appendix A. Changes from previous versions . . . . . . . . . . . 19
	A.1. From version-01 to version-02 . . . . . . . . . . . . . . 19		A.1. From version-01 to version-02 . . . . . . . . . . . . . . 19
	A.2. From version-02 to version-03 (current) . . . . . . . . . 20		A.2. From version-02 to version-03 . . . . . . . . . . . . . . 20
			A.3. From version-03 to version-04 (current) . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 22		Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The Host Identity Protocol (HIP) [RFC5201] is an experimental effort		The Host Identity Protocol (HIP) [RFC5201] is an experimental effort
	in the IETF and IRTF to study a new public-key-based name space for		in the IETF and IRTF to study a new public-key-based name space for
	use as host identifiers in Internet protocols. Fully deployed, the		use as host identifiers in Internet protocols. Fully deployed, the
	HIP architecture would permit applications and users to explicitly		HIP architecture would permit applications and users to explicitly
	request the system to send packets to another host by expressing a		request the system to send packets to another host by expressing a
	skipping to change at page 8, line 35		skipping to change at page 8, line 35
	address. Note that these are the same type of applications that will		address. Note that these are the same type of applications that will
	likely break if used over certain types of network address		likely break if used over certain types of network address
	translators (NATs). Second, applications may cache the results of		translators (NATs). Second, applications may cache the results of
	DNS queries for a long time, and it may be hard for a HIP system to		DNS queries for a long time, and it may be hard for a HIP system to
	determine when to perform garbage collection on the LSI bindings.		determine when to perform garbage collection on the LSI bindings.
	However, when using HITs, the security of using the HITs for identity		However, when using HITs, the security of using the HITs for identity
	comparison may be stronger than in the case of using IP addresses.		comparison may be stronger than in the case of using IP addresses.
	Finally, applications may generate log files, and administrators or		Finally, applications may generate log files, and administrators or
	other consumers of these log files may become confused to find LSIs		other consumers of these log files may become confused to find LSIs
	or HITs instead of IP addresses. Therefore, it is recommended that		or HITs instead of IP addresses. Therefore, it is recommended that
	the HIP software logs the HITs, LSIs (if applicable), and FQDN-		the HIP software logs the HITs, LSIs (if applicable), corresponding
	related information so that administrators can correlate other logs		IP addresses, and FQDN-related information so that administrators can
	with HIP identifiers.		correlate other logs with HIP identifiers.
	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 through an overlay, in which case it would be		either directly or through an overlay, in which case it would be
	preferable for applications to handle such names instead of IP		preferable for applications to handle such names instead of IP
	addresses. However, such networks are out of scope of this document.		addresses. However, such networks are out of scope of this document.
	3.3. Discussion		3.3. Discussion
	Solutions preserving the use of IP addresses in the applications have		Solutions preserving the use of IP addresses in the applications have
	the benefit of better support for applications that use IP addresses		the benefit of better support for applications that use IP addresses
	skipping to change at page 15, line 11		skipping to change at page 15, line 11
	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		When the system provides (spoofs) LSIs or HITs instead of IP
	addresses as the result of name resolution, the resultant fields may		addresses as the result of name resolution, the resultant fields may
	inadvertently show up in user interfaces and system logs, which may		inadvertently show up in user interfaces and system logs, which may
	cause operational concerns for some network administrators.		cause operational concerns for some network administrators.
	Therefore, it is recommended that the HIP software logs the HITs,		Therefore, it is recommended that the HIP software logs the HITs,
	LSIs (if applicable), and FQDN-related information so that		LSIs (if applicable), corresponding IP addresses, and FQDN-related
	administrators can correlate other logs with HIP identifiers.		information so that administrators can correlate other logs with HIP
			identifiers.
	7. IANA Considerations		7. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	8. Acknowledgments		8. Acknowledgments
	Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen,		Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen,
	Julien Laganier, and Jukka Ylitalo have provided comments on		Julien Laganier, and Jukka Ylitalo have provided comments on
	different versions of this draft. Erik Nordmark provided the		different versions of this draft. Erik Nordmark provided the
	skipping to change at page 20, line 29		skipping to change at page 20, line 29
	handled in Section 3.4: i) clarify multihoming issue for servers with		handled in Section 3.4: i) clarify multihoming issue for servers with
	multiple HITs, when receiving UDP, ii) clarify a problem that might		multiple HITs, when receiving UDP, ii) clarify a problem that might
	arise for applications that do parallel connect, and iii) suggest		arise for applications that do parallel connect, and iii) suggest
	that loopback HIP connections could use a NULL encryption.		that loopback HIP connections could use a NULL encryption.
	Removed expired references and updated active references.		Removed expired references and updated active references.
	Incorporated additional review comments from Miika Komu, and some		Incorporated additional review comments from Miika Komu, and some
	suggested replacement text, and added him as a co-author.		suggested replacement text, and added him as a co-author.
	A.2. From version-02 to version-03 (current)		A.2. From version-02 to version-03
	DNSSEC clarifications added based on dns-dir review from Peter Koch		DNSSEC clarifications added based on dns-dir review from Peter Koch
	Editing pass through document. Organizationally, everything except		Editing pass through document. Organizationally, everything except
	security considerations was in one section. The existing text of		security considerations was in one section. The existing text of
	Sections 3.1 through 3.3 was moved to new Sections 3 and 4, the		Sections 3.1 through 3.3 was moved to new Sections 3 and 4, the
	previous text of section 3.4 has been moved to section 5, and the		previous text of section 3.4 has been moved to section 5, and the
	previous Section 4 (security considerations) is now Section 6.		previous Section 4 (security considerations) is now Section 6.
	Performed further wordsmithing and cleanup.		Performed further wordsmithing and cleanup.
			A.3. From version-03 to version-04 (current)
			Add suggestion by David Black to also log IP addresses used in HIP
			conversations (Sections 3.2 and 7).
	Authors' Addresses		Authors' Addresses
	Thomas 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
End of changes. 9 change blocks.
	11 lines changed or deleted		18 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/