IRTF HIP Research Group T. Henderson Internet-Draft The Boeing Company Expires: January 21, 2006 A. Gurtov HIIT July 20, 2005 HIP Experiment Report draft-irtf-hip-experiment-01 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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 January 21, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This is the initial draft of the HIP-RG experiment report. The report summarizes implications of deploying HIP for the end-host TCP/IP stack, applications, and network infrastructure. Henderson & Gurtov Expires January 21, 2006 [Page 1] Internet-Draft HIP Experiment Report July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 What is HIP? . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The ID/Locator Split . . . . . . . . . . . . . . . . . . . . 4 3. End-host Stack Implications . . . . . . . . . . . . . . . . 5 3.1 Transport issues (CELP, MAST) . . . . . . . . . . . . . . 5 3.2 Multi6/shim6 . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Resolver issues . . . . . . . . . . . . . . . . . . . . . 5 3.4 Local management of host identity namespace (including security/privacy issues) . . . . . . . . . . . . . . . . . 6 3.5 Interactions with host firewalls . . . . . . . . . . . . . 6 3.6 IPsec implementation issues . . . . . . . . . . . . . . . 6 3.7 IPv4 vs. IPv6 issues . . . . . . . . . . . . . . . . . . . 7 3.8 What have early adoptors learned from experience? . . . . 7 4. Application Implications . . . . . . . . . . . . . . . . . . 8 4.1 Static vs. dynamic linking of resolver library . . . . . . 8 4.2 Using legacy API . . . . . . . . . . . . . . . . . . . . . 8 4.3 Using native API . . . . . . . . . . . . . . . . . . . . . 8 5. Infrastructure Implications . . . . . . . . . . . . . . . . 9 5.1 Issues with global management of the host identity namespace . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Legacy NAT traversal . . . . . . . . . . . . . . . . . . . 9 5.3 Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 9 5.4 Firewall issues . . . . . . . . . . . . . . . . . . . . . 9 5.5 Access control lists based on HITs . . . . . . . . . . . . 9 5.6 HIP aware middleboxes . . . . . . . . . . . . . . . . . . 9 5.7 HIT resolution infrastructure . . . . . . . . . . . . . . 10 5.8 Rendezvous servers . . . . . . . . . . . . . . . . . . . . 10 5.9 Debugging . . . . . . . . . . . . . . . . . . . . . . . . 11 5.10 Tying into existing PKIs . . . . . . . . . . . . . . . . 11 6. General Implications . . . . . . . . . . . . . . . . . . . . 12 7. HIP Research Activities . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . 16 Henderson & Gurtov Expires January 21, 2006 [Page 2] Internet-Draft HIP Experiment Report July 2005 1. Introduction This document summarizes the work and experiences of the Host Identity Protocol IRTF Research Group (HIP-RG). The HIP-RG was chartered to explore the possible benefits and consequences of deploying the Host Identity Protocol architecture [2] in the Internet. 1.1 What is HIP? The Host Identity Protocol introduces a new name space, the "host identity" name space, to the Internet architecture. The express purpose of this new name space is to allow for the decoupling of identifiers (host identities) and locators (IP addresses) in the architecture. The authors and technical contributors to HIP have assumed that HIP will allow for alternative solutions for several of the Internet's challenging technical problems. Although there have been many architectural proposals to decouple identifiers and locators over the past 20 years, HIP is currently the most actively developed proposal in this area. A number of experimental draft specifications are in work in the IETF's HIP Working Group, including the HIP base protocol [3], among other drafts dealing with mobility management, DNS resource records, and HIP rendezvous servers. 1.2 Scope The research group is tasked with producing an "experiment report" documenting the collective experiences and lessons learned from other studies, related experimentation, and designs completed by the research group. The question of whether the basic identifier/locator split assumption is valid falls beyond the scope of this research group. When indicated by its studies, the HIP RG can suggest extensions and modifications to the protocol and architecture. It is also in scope for the RG to study, in a wider sense, the consequences and effects that wide-scale adoption of any type of separation of the identifier and locator roles of IP addresses is likely to have. Henderson & Gurtov Expires January 21, 2006 [Page 3] Internet-Draft HIP Experiment Report July 2005 2. The ID/Locator Split The topic of whether a new name space is needed for the Internet is controversial. The Name Space Research Group (NSRG) at the IRTF was not able to reach consensus on the issue, nor even to publish a final report. The IRTF HIP research group is tasked to evaluate the impact of deployment of a HIP or related name space in the Internet. Yet, there seems to be little disagreement that, for many scenarios, some level of indirection from network name to network location is essential or highly desirable to provide adequate service. Mobile IP [1] is one example (the first such Standards Track proposal), with particular deployment and security properties, that reuses an existing name space for host naming. Since Mobile IP was finalized many new variants to providing this indirection have been suggested. Most recently, there has been standardization and development efforts in the IETF and IRTF on multi6 protocols and HIP. In the research community, several related proposals have been explored, such as the Internet Indirection Infrastructure (i3) [4], IPNL [5], DataRouter [6], Network Pointers [7], FARA [8], and TRIAD [9]. HIP provides a rapid exchange of Host Identities (public keys) between hosts and uses a Sigma-compliant Diffie-Hellman key exchange to establish shared secrets between such endpoints [3]. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in- the-middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP) [10], it provides encryption and/or authentication protection for upper layer protocols such as TCP and UDP, while enabling continuity of communications across network layer address changes. Henderson & Gurtov Expires January 21, 2006 [Page 4] Internet-Draft HIP Experiment Report July 2005 3. End-host Stack Implications There are two primary ways to support HIP in an end-host. The first is to make changes to the kernel implementation to directly support the decoupling of identifier and locator. Although this type of modification is the higher performing approach, it is also the more challenging to deploy. The second approach is to implement all HIP processing in user-space, and configure the kernel to pass packets through user-space for HIP processing. The following public HIP implementations are known: o HIP4BSD (http://www.hip4inter.net)-- FreeBSD kernel modifications and user-space keying daemon; o HIPL (http://infrahip.hiit.fi)-- Linux kernel implementation; o OpenHIP (http://www.openhip.org)-- Linux kernel modifications and user-space keying daemon, plus a fully user-space Windows XP implementation; o pyHIP (http://www.sharemation.com/adm01bass/)-- Fully user-space implementation written in python (no longer maintained). 3.1 Transport issues (CELP, MAST) TODO 3.2 Multi6/shim6 TODO 3.3 Resolver issues Much initial experimentation with HIP has involved using HITs directly in IPv6 socket calls. To do so requires some type of a priori HIT exchange, in the absence of a resolution service. Manual exchange of HITs has been a major inconvenience for experimentation. It can be overcome via 1) opportunistic HIP mode, 2) storing HITs in DNS AAAA entries, 3) name resolution service such as OpenDHT, or 4) a HIT exchange service. At the time of writing, #1 is only supported by OpenHIP, and #2 is only supported by HIP4BSD. Implementing the first approach in a clean way is challenging, as HITs need to be known when an application binds to a socket. Approach #2 has been difficult in practice due to resistance of sysadmins for including AAAA entries in Henderson & Gurtov Expires January 21, 2006 [Page 5] Internet-Draft HIP Experiment Report July 2005 the DNS server. However, using a widely available third-party DNS service has a low cost. Approach #3 is being progressed with two independent implementations of HIP-OpenDHT interface. At the moment, the easiest way for enabling experimentation appears to be the approach #4 when a shell script based on SSH and SCP can connect to a peer machine and copy HITs to the local configuration files. However, this approach is not scalable or secure for the long run. 3.4 Local management of host identity namespace (including security/ privacy issues) One issue not being addressed by most experimental implementations is how to manage possibly multiple host identities (some may be unpublished). This is akin to source address selection for transport sockets. How much HIP policy to expose to users is a user interface issue. Default or automatic configuration guesses might have undesirable privacy implications for the user. HIIT has implemented an extension of native API to control multiple host identities (refer to Karlsson's Master's thesis). 3.5 Interactions with host firewalls HIP is presently an experimental protocol, and some default firewall configuration scripts on popular Linux distributions do not permit such traffic. Determining which rules to modify without compromising other performance can be tricky; the default rule set on one popular distribution has over 100 rules. Moreover, it may be the case that the end user has no control over the firewall settings, if administered by an enterprise IT department. 3.6 IPsec implementation issues HIP requires a Bound End-to-End Tunnel (BEET) mode of ESP operation, which mixes tunnel-mode semantics with transport-mode syntax. BEET is not supported by any known operating system distributions at present, so kernel modifications must be made to obtain true kernel support using existing IPsec code. The current strategy that implementors have adopted is to develop a common IPsec BEET patch for the Linux kernel. The patch could potentially allow all implementations to run in the userspace and use a common clean interface towards the kernel. Still, the BEET patch introduces problems for the opportunistic HIP mode when HITs are used at the socket API. Another inconvenience experienced in current Linux implementations (due to the native IPsec implementation, not HIP specifically) is a Henderson & Gurtov Expires January 21, 2006 [Page 6] Internet-Draft HIP Experiment Report July 2005 loss of the first data packet that triggers the HIP association establishment. Instead, this packet should be cached and transmitted after the association is established. 3.7 IPv4 vs. IPv6 issues TODO 3.8 What have early adoptors learned from experience? Installing several HIP implementations onto a single machine was creating some complications. All implementations store some files in /etc/hip directory and use /proc system to report the status. While direct conflicts in filenames were luckily avoided, it might have been better to coordinate from the beginning so that different implementations, for example, use different subdirectories. The experience with attempting to integrate the HIPL kernel-based implementation to the official Linux kernel has been negative. Although counter examples exist, e.g. SCTP is a large unit in the kernel, the Linux community resisted incorporating the HIP code. It was motivated by a possibility to run HIP in the user space. Experimental results comparing kernel vs. userspace HIP implementations in terms of performance and DoS resilience are needed. If the kernel implementation is shown to perform significantly better than the userspace implementation, it may be a sufficient justification to incorporate HIP to kernel. Opportunities for misconfiguration of the Linux kernel have been a side effect of the need to patch the kernel. Mistakenly disabling a configuration option or compiling a feature as a module instead of statically caused many installation problems. Some scripts that could verify that the configuration is appropriate could help to solve this problem, as could fully user-space test implementations. Henderson & Gurtov Expires January 21, 2006 [Page 7] Internet-Draft HIP Experiment Report July 2005 4. Application Implications 4.1 Static vs. dynamic linking of resolver library Using HIPL, several legacy applications were shown to work without changes using dynamic re-linking of the resolver library. This way, Firefox web browser successfully worked with an Apache web server. The re-linking just requires configuring a LD_PRELOAD system variable that can be easily done in a user shell profile file or as a start-up wrapper for an application. 4.2 Using legacy API OpenHIP legacy API allows using most HIP-unaware applications in a transparent way (Refer to Henderson et al. draft). 4.3 Using native API Several applications, including telnet and FTP, have been ported to use the native HIP API in HIPL. A concern that FTP would not work due to the problem of application referral, i.e. passing an the IP address within application messages, was solved. FTP is shown to work well in the passive and active modes. (Refer to Komu et al. Mobicom workshop paper). Henderson & Gurtov Expires January 21, 2006 [Page 8] Internet-Draft HIP Experiment Report July 2005 5. Infrastructure Implications 5.1 Issues with global management of the host identity namespace TODO 5.2 Legacy NAT traversal Legacy NAT traversal is being implemented for HIPL according to the PATH draft. While IPv6 mode is ready, IPv4 is still in progress (IPv4 is still unstable in HIPL). Finding an IPv6 NAT implementation for experiments has been difficult. Tests and performance measurements with an IPv4 NAT (WLAN access point) will be executed. A next topic is experimenting with legacy NAT traversal when both peers reside beyond a NATs. One possibility is to run STUN servers on PlanetLab to enable NAT traversal. 5.3 Impact on DNS Initially, HITs were expected to be stored as AAAA entries in DNS. This is a source of potential confusion for HIP unaware applications that cannot distinguish between a HIT and a valid IPv6 address. What is the impact of HIP resource records on DNS? DNS extensions are currently under development by NEC Eurolabs. 5.4 Firewall issues HIIT has implemented a HIP firewall based on Linux iptables. (Refer to Vehmersalo's Master's thesis.) 5.5 Access control lists based on HITs TODO 5.6 HIP aware middleboxes A design of a HIP registration protocol for architectured NATs has been completed and published. Performance measurement results with a prototype are available, but experimentation on a wide scale is still missing. (Refer to Tschofenig et al). As argued by Aura et al., the encryption of the Responder HI prevents NAT and firewall support for HIP. The catch is that when the HI is encrypted, middle boxes in the network cannot verify the signature on I2 and, thus, cannot safely create a state for the HIP association. On the other hand, if the HI is not encrypted, a stateful middle box Henderson & Gurtov Expires January 21, 2006 [Page 9] Internet-Draft HIP Experiment Report July 2005 like a NAT can process I2 and create a protocol state for the possible to push the I1/R1 exchange into the firewall and to filter false puzzle solutions at the firewall. The encryption of HI-I prevents such middle-box implementations. (Refer to Aura et al.) 5.7 HIT resolution infrastructure OpenDHT resolution has been implemented by Aalborg University, Denmark and by Boeing. (Add references). The prototype of the Host Identity Indirection Infrastructure (Hi3) has been implemented using OpenHIP and i3 software. A set of 25 i3 servers is running on PlanetLab. While a PlanetLab account is required to run the servers, anybody can openly use the provided service. The main idea is to transmit HIP control packets using the i3 system as a lookup and rendezvous service, while transmitting data packets efficiently end-to-end using IPsec. Performance measurements are being executed, comparing the association setup latency, throughout and RTT of Hi3 with plain IP, HIP and i3. One difficulty has been with debugging the i3 system. In some cases the messages did not traverse i3 correctly; due to its distributed nature and lack of tracing tools, making the system work has been challenging. Fortunately, these shortcomings are being addressed. NATs and firewalls were a major disturbing factor in execution of experiments. Many networks did not allow incoming UDP packets to go through, therefore, preventing messages from i3 servers to reach the client. So far the Hi3 system has been evaluated on a larger scale only analytically. The problem is that running a larger number of clients to create a sufficient load for the server is difficult. A cluster on the order of a hundred Linux servers is needed for this purpose. Contacts to a State Supercomputer Centre in Finland have not been successful so far. A possible opportunity is to use one of existing Emulab installations, e.g. in Utah for these tests. 5.8 Rendezvous servers A rendezvous server (RVS) has been implemented by HIIT for HIPL. Initial experimentation produced following observations. o RVS is essential for fast initial contact; DynDNS is not as fast yet. Henderson & Gurtov Expires January 21, 2006 [Page 10] Internet-Draft HIP Experiment Report July 2005 o RVS improves fault tolerance for multihoming. o Registration of a HIP host to RVS loads the host significantly. Following advanced concepts need further study. o Multiple RVS per host for fault tolerance (e.g. one rendezvous node crashes). An algorithm for selecting the best RVS. o Load balancing. A RVS server could distribute I1s to different responders if the responder's identity is shared or opportunistic HIP is used. o Offering a rendezvous service in a P2P fashion by HIP hosts. 5.9 Debugging TODO 5.10 Tying into existing PKIs TODO Henderson & Gurtov Expires January 21, 2006 [Page 11] Internet-Draft HIP Experiment Report July 2005 6. General Implications TODO Henderson & Gurtov Expires January 21, 2006 [Page 12] Internet-Draft HIP Experiment Report July 2005 7. HIP Research Activities The following is a possibly incomplete list of current research activities related to HIP. Boeing (T. Henderson, J. Ahrenholz. OpenHIP implementation, OpenDHT) Nomadiclab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP implementation) HIIT (A. Gurtov, M. Komu, A. Pathak, D. Beltrami. HIPL, legacy NAT traversal, firewall, i3, native API) UCB (D. Joseph, HIP proxy implementation) Laboratory of Computer Architecture and Networks, Polytechnic School of University of Sao Paulo, Brazil (T. Carvalho, HIP measurements, Hi3) Telecom Italia (M. Morelli, comparing existing HIP implementations) NEC Heidelberg (L. Eggert, M. Esteban working on RVS implementation, DNS) U. of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP registration protocol) U. of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP- OpenDHT) University of Parma (UNIPR), Department of Information Engineering Parma, Italy. N. Fedotova (HIP for P2P) Siemens (H. Tschofenig, HIP middleboxes) Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per Toft, HIP evaluation project, OpenDHT-HIP interface) Microsoft Research, Cambridge (T. Aura, HIP analysis) MIT (H. Balakrishnan. Delegation-Oriented Architecture) Henderson & Gurtov Expires January 21, 2006 [Page 13] Internet-Draft HIP Experiment Report July 2005 8. Acknowledgments Miika Komu. 9. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Moskowitz, R., "Host Identity Protocol Architecture", draft-ietf-hip-arch-02 (work in progress), January 2005. [3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-01 (work in progress), October 2004. [4] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S. Surana, "Internet Indirection Infrastructure (i3)", Proceedings of ACM SIGCOMM, August 2002. [5] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker, S., Stoica, I., and M. Walfish, "A Layered Naming Architecture for the Internet", Proceedings of ACM SIGCOMM, August 2004. [6] Touch, J. and V. Pingali, "DataRouter: A Network-Layer Service for Application-Layer Forwarding", Proceedings of International Workshop on Active Networks (IWAN), December 2003. [7] Tschudin, C. and R. Gold, "Network Pointers", ACM Computer Communications Review, January 2003. [8] Clark, D., Braden, R., Falk, A., and V. Pingali, "FARA: Reorganizing the Addressing Architecture", Proceedings of ACM SIGCOMM FDNA Workshop, August 2003. [9] Cheriton, D. and M. Gritter, "TRIAD: A New Next-Generation Internet Architecture", Unpublished, available at Citeseer, July 2000. [10] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. Henderson & Gurtov Expires January 21, 2006 [Page 14] Internet-Draft HIP Experiment Report July 2005 Authors' Addresses Tom Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA Email: thomas.r.henderson@boeing.com Andrei Gurtov HIIT Helsinki Institute for Information Technology Advanced Research Unit (ARU) P.O. Box 9800 Helsinki FIN-02015-HUT FINLAND Phone: +358 9 451 1 Email: gurtov@cs.helsinki.fi Henderson & Gurtov Expires January 21, 2006 [Page 15] Internet-Draft HIP Experiment Report July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Henderson & Gurtov Expires January 21, 2006 [Page 16]