--- 1/draft-ietf-hip-applications-03.txt 2008-07-07 18:12:19.000000000 +0200 +++ 2/draft-ietf-hip-applications-04.txt 2008-07-07 18:12:19.000000000 +0200 @@ -1,22 +1,22 @@ Network Working Group T. Henderson Internet-Draft The Boeing Company Intended status: Informational P. Nikander -Expires: December 30, 2008 Ericsson Research NomadicLab +Expires: January 8, 2009 Ericsson Research NomadicLab M. Komu Helsinki Institute for Information Technology - June 28, 2008 + July 7, 2008 Using the Host Identity Protocol with Legacy Applications - draft-ietf-hip-applications-03 + draft-ietf-hip-applications-04 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -27,21 +27,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation @@ -63,21 +63,22 @@ 4.1. Connecting to a HIT or LSI . . . . . . . . . . . . . . . . 10 4.2. Using a modified DNS name . . . . . . . . . . . . . . . . 10 4.3. Other techniques . . . . . . . . . . . . . . . . . . . . . 11 5. Local address management . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Informative References . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes from previous versions . . . . . . . . . . . 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 Intellectual Property and Copyright Statements . . . . . . . . . . 22 1. Introduction 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 use as host identifiers in Internet protocols. Fully deployed, the HIP architecture would permit applications and users to explicitly request the system to send packets to another host by expressing a @@ -291,23 +292,23 @@ address. Note that these are the same type of applications that will likely break if used over certain types of network address 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 determine when to perform garbage collection on the LSI bindings. However, when using HITs, the security of using the HITs for identity comparison may be stronger than in the case of using IP addresses. Finally, applications may generate log files, and administrators or other consumers of these log files may become confused to find LSIs or HITs instead of IP addresses. Therefore, it is recommended that - the HIP software logs the HITs, LSIs (if applicable), and FQDN- - related information so that administrators can correlate other logs - with HIP identifiers. + the HIP software logs the HITs, LSIs (if applicable), corresponding + IP addresses, and FQDN-related information so that administrators can + correlate other logs with HIP identifiers. 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 preferable for applications to handle such names instead of IP addresses. However, such networks are out of scope of this document. 3.3. Discussion Solutions preserving the use of IP addresses in the applications have the benefit of better support for applications that use IP addresses @@ -530,22 +531,23 @@ HIP. That is, when the application makes a connect(HIT) system call, the resulting packets will either be sent to a node possessing the corresponding private key or the security association will fail to be 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. Therefore, it is recommended that the HIP software logs the HITs, - LSIs (if applicable), and FQDN-related information so that - administrators can correlate other logs with HIP identifiers. + LSIs (if applicable), corresponding IP addresses, and FQDN-related + information so that administrators can correlate other logs with HIP + identifiers. 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgments Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen, Julien Laganier, and Jukka Ylitalo have provided comments on different versions of this draft. Erik Nordmark provided the @@ -647,31 +649,36 @@ 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. -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 Editing pass through document. Organizationally, everything except 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 previous text of section 3.4 has been moved to section 5, and the previous Section 4 (security considerations) is now Section 6. 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 Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA Email: thomas.r.henderson@boeing.com