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/