IRTF HIP Research Group T. Henderson Internet-Draft The Boeing Company Expires: September 5, 2007 A. Gurtov HIIT March 4, 2007 HIP Experiment Report draft-irtf-hip-experiment-03 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 September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Henderson & Gurtov Expires September 5, 2007 [Page 1] Internet-Draft HIP Experiment Report March 2007 Abstract This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. What is HIP? . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Related Work on ID/Locator Split . . . . . . . . . . . . . 4 2. Host Stack Implications . . . . . . . . . . . . . . . . . . . 6 2.1. Modifications to TCP/IP stack implementations . . . . . . 6 2.1.1. ESP implementation extensions . . . . . . . . . . . . 8 2.1.2. Resolver issues . . . . . . . . . . . . . . . . . . . 8 2.1.3. IPsec management API extensions . . . . . . . . . . . 9 2.1.4. Transport protocol issues . . . . . . . . . . . . . . 9 2.2. Local management of host identity namespace . . . . . . . 9 2.3. Interactions with host firewalls . . . . . . . . . . . . . 9 2.4. Relation to shim6 protocols . . . . . . . . . . . . . . . 10 2.5. IPv4 vs. IPv6 issues . . . . . . . . . . . . . . . . . . . 10 2.6. What have early adoptors learned from experience? . . . . 10 3. Infrastructure Implications . . . . . . . . . . . . . . . . . 11 3.1. Legacy NAT traversal . . . . . . . . . . . . . . . . . . . 11 3.2. Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 11 3.3. HIP aware middleboxes . . . . . . . . . . . . . . . . . . 11 3.4. HIT resolution infrastructure . . . . . . . . . . . . . . 11 3.5. Rendezvous servers . . . . . . . . . . . . . . . . . . . . 12 4. Application Implications . . . . . . . . . . . . . . . . . . . 14 4.1. Static vs. dynamic linking of resolver library . . . . . . 14 4.2. Using legacy API . . . . . . . . . . . . . . . . . . . . . 14 4.3. Using native API . . . . . . . . . . . . . . . . . . . . . 14 5. Network Operator's Perspective . . . . . . . . . . . . . . . . 15 5.1. Management of the host identity namespace . . . . . . . . 15 5.2. Use of ESP encryption . . . . . . . . . . . . . . . . . . 15 5.3. User privacy issues . . . . . . . . . . . . . . . . . . . 15 5.4. Access control lists based on HITs . . . . . . . . . . . . 15 5.5. Firewall issues . . . . . . . . . . . . . . . . . . . . . 15 6. Experimental Basis of this Report . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Henderson & Gurtov Expires September 5, 2007 [Page 2] Internet-Draft HIP Experiment Report March 2007 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 [1] 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, including potentially host mobility, host multihoming, site multihoming, IPv6 transition, and network-level security. 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. 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 [2]. 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) [3], 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. A number of experimental draft specifications are in work in the IETF's HIP Working Group, including the HIP base protocol [2], among other drafts dealing with mobility management, DNS resource records, and HIP rendezvous servers (include references to other drafts here). 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 Henderson & Gurtov Expires September 5, 2007 [Page 3] Internet-Draft HIP Experiment Report March 2007 and effects that wide-scale adoption of any type of separation of the identifier and locator roles of IP addresses is likely to have. In this report, we summarize the collective experience of early implementors and adopters of HIP, organized as follows: o Section 2 describes the implications of supporting HIP on an end- host. o Section 3 covers a number of issues regarding the deployment of and interaction with network infrastructure, including middlebox traversal, name resolution, ACLs, and HIP infrastructure such as rendezvous servers. o Whereas the two previous sections focus on the implementation and deployment of the network plumbing to make HIP work, the next two focus on the impact to users and operators of the network. Section 4 examines how the support of HIP in the host and network infrastructure affects applications; whether and how HIP provides benefits or drawbacks to HIP-enabled and legacy applications. o Section 5 provides an operator's perspective on HIP deployment. o In Section 6, we list the experimental activities and research that have contributed to this report. 1.3. Related Work on 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 [4] 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. Even prior to Mobile IP, the IETF has published informational documents describing architectures separating network name and location, including the work of Jerome Saltzer [5], and Nimrod [6]. Most recently, there has been standardization and development efforts in the IETF and IRTF on multi6/shim6 protocols and HIP. In the research community, several related proposals have been explored, such as the Internet Indirection Infrastructure (i3) [7], IPNL [8], Henderson & Gurtov Expires September 5, 2007 [Page 4] Internet-Draft HIP Experiment Report March 2007 DataRouter [9], Network Pointers [10], FARA [11], and TRIAD [12]. Henderson & Gurtov Expires September 5, 2007 [Page 5] Internet-Draft HIP Experiment Report March 2007 2. 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 fully user-space Windows XP and Mac OS X implementations; o pyHIP (http://www.sharemation.com/adm01bass/)-- Fully user-space implementation written in Python (no longer maintained). 2.1. Modifications to TCP/IP stack implementations In this section, we focus on the support of HIP assuming the following: o HIP is implemented by directly changing the TCP/IP stack implementation o Applications (the sockets API) are unaware of HIP A common way to partition the HIP implementation is to implement a keying daemon in user-space that interacts with kernel-level support for ESP, as shown in Figure 1. However, the HIPL project demonstrates that it is possible to support HIP with a purely kernel- level implementation. Henderson & Gurtov Expires September 5, 2007 [Page 6] Internet-Draft HIP Experiment Report March 2007 +--------------------+ +--------------------+ | | | | | +------------+ | | +------------+ | | | Key | | HIP | | Key | | | | Management | <-+-----------------------+-> | Management | | | | Process | | | | Process | | | +------------+ | | +------------+ | | ^ | | ^ | | | | | | | | v | | v | | +------------+ | | +------------+ | | | IPsec | | ESP | | IPsec | | | | Stack | <-+-----------------------+-> | Stack | | | | | | | | | | | +------------+ | | +------------+ | | | | | | | | | | Initiator | | Responder | +--------------------+ +--------------------+ Figure 1: HIP deployment model Figure 2 summarizes the main implementation impact of supporting HIP, and is discussed further in subsequent sections. To enable HIP natively in an implementation requires extensions to the key management interface (here depicted as PFKEY) with the security association database (SAD) and security policy database (SPD), changes to the ESP implementation itself to support BEET-mode processing [13], extensions to the name resolution library, and (in the future) interactions with transport protocols to respond correctly to mobility and multihoming events. Henderson & Gurtov Expires September 5, 2007 [Page 7] Internet-Draft HIP Experiment Report March 2007 -------- --------- | HIP |-- ----| App | (legacy application) -------- | | --------- | | | | | ------------ | | | resolver | | | ------------ | sockets API user-space --|-------------------|------------------------------- | sockets and | kernel | pfkey API --------- |-------------> |TCP/UDP| (sockets bound to HITs) | --------- | | ---------- --------- | SAD/SPD|<-----> | ESP | {HIT_s, HIT_d} <-> SPI ---------- --------- {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} | --------- | IP | --------- Figure 2: Overview of typical implementation changes to support HIP 2.1.1. ESP implementation extensions 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 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. 2.1.2. Resolver issues Much initial experimentation with HIP has involved using HITs directly in IPv6 socket calls. To do so requires some type of a Henderson & Gurtov Expires September 5, 2007 [Page 8] Internet-Draft HIP Experiment Report March 2007 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 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. 2.1.3. IPsec management API extensions Changes to PFKEY. TODO. 2.1.4. Transport protocol issues (CELP, MAST) TODO 2.2. Local management of host identity namespace 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). Describe security and privacy issues with storing private keys securely on a host. 2.3. 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 Henderson & Gurtov Expires September 5, 2007 [Page 9] Internet-Draft HIP Experiment Report March 2007 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. 2.4. Relation to shim6 protocols TODO 2.5. IPv4 vs. IPv6 issues TODO 2.6. 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 September 5, 2007 [Page 10] Internet-Draft HIP Experiment Report March 2007 3. Infrastructure Implications Section 5 3.1. 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. 3.2. 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. 3.3. 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 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.) 3.4. 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 Henderson & Gurtov Expires September 5, 2007 [Page 11] Internet-Draft HIP Experiment Report March 2007 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. 3.5. 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. 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. Henderson & Gurtov Expires September 5, 2007 [Page 12] Internet-Draft HIP Experiment Report March 2007 o Offering a rendezvous service in a P2P fashion by HIP hosts. Henderson & Gurtov Expires September 5, 2007 [Page 13] Internet-Draft HIP Experiment Report March 2007 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 [14]. 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 September 5, 2007 [Page 14] Internet-Draft HIP Experiment Report March 2007 5. Network Operator's Perspective 5.1. Management of the host identity namespace Issues with PKI, SIP names, etc. TODO 5.2. Use of ESP encryption Reference the Dietz draft discussion regarding whether operators can provide "value-added" services and priority, and comply with wiretapping laws, if all sessions are encrypted. This is not so much a HIP issue as a general IPsec issue. 5.3. User privacy issues Issues with tracking of HITs 5.4. Access control lists based on HITs TODO 5.5. Firewall issues HIIT has implemented a HIP firewall based on Linux iptables. (Refer to Vehmersalo's Master's thesis.) Henderson & Gurtov Expires September 5, 2007 [Page 15] Internet-Draft HIP Experiment Report March 2007 6. Experimental Basis of this Report This report is derived from reported experiences and research results of early adoptors, implementors, and research activities. In particular, a number of implementations have been in development since 2002 (Section Section 2). (add other experience here). The following is a possibly incomplete list of current research activities related to HIP. o Boeing (T. Henderson, J. Ahrenholz, J. Meegan. OpenHIP implementation, Secure Mobile Architecture) o Nomadiclab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP implementation) o HIIT (A. Gurtov, M. Komu, A. Pathak, D. Beltrami. HIPL, legacy NAT traversal, firewall, i3, native API) o UCB (D. Joseph, HIP proxy implementation) o Laboratory of Computer Architecture and Networks, Polytechnic School of University of Sao Paulo, Brazil (T. Carvalho, HIP measurements, Hi3) o Telecom Italia (M. Morelli, comparing existing HIP implementations) o NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS implementation, DNS, NAT traversal) o U. of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP registration protocol) o U. of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP- OpenDHT) o University of Parma (UNIPR), Department of Information Engineering Parma, Italy. N. Fedotova (HIP for P2P) o Siemens (H. Tschofenig, HIP middleboxes) o Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per Toft, HIP evaluation project, OpenDHT-HIP interface) o Microsoft Research, Cambridge (T. Aura, HIP analysis) o MIT (H. Balakrishnan. Delegation-Oriented Architecture) Henderson & Gurtov Expires September 5, 2007 [Page 16] Internet-Draft HIP Experiment Report March 2007 7. Acknowledgments Miika Komu has provided helpful comments on earlier versions of this draft. Henderson & Gurtov Expires September 5, 2007 [Page 17] Internet-Draft HIP Experiment Report March 2007 8. References [1] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 (work in progress), February 2007. [3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [6] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996. [7] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S. Surana, "Internet Indirection Infrastructure (i3)", Proceedings of ACM SIGCOMM, August 2002. [8] 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. [9] Touch, J. and V. Pingali, "DataRouter: A Network-Layer Service for Application-Layer Forwarding", Proceedings of International Workshop on Active Networks (IWAN), December 2003. [10] Tschudin, C. and R. Gold, "Network Pointers", ACM Computer Communications Review, January 2003. [11] Clark, D., Braden, R., Falk, A., and V. Pingali, "FARA: Reorganizing the Addressing Architecture", Proceedings of ACM SIGCOMM FDNA Workshop, August 2003. [12] Cheriton, D. and M. Gritter, "TRIAD: A New Next-Generation Internet Architecture", Unpublished, available at Citeseer, July 2000. [13] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) mode for ESP", draft-nikander-esp-beet-mode-06 (work in progress), August 2006. Henderson & Gurtov Expires September 5, 2007 [Page 18] Internet-Draft HIP Experiment Report March 2007 [14] Henderson, T. and P. Nikander, "Using HIP with Legacy Applications", draft-ietf-hip-applications-00 (work in progress), November 2006. Henderson & Gurtov Expires September 5, 2007 [Page 19] Internet-Draft HIP Experiment Report March 2007 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 September 5, 2007 [Page 20] Internet-Draft HIP Experiment Report March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Henderson & Gurtov Expires September 5, 2007 [Page 21]