Network Working Group P. Nikander Internet-Draft J. Arkko Expires: December 26, 2004 Ericsson Research Nomadic Lab B. Ohlman Ericsson Research IP Networks June 27, 2004 Host Identity Indirection Infrastructure (Hi3) draft-nikander-hiprg-hi3-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 December 26, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Secure Internet Indirection Infrastructure (Secure-i3) is a proposal for a flexible and secure overlay network that, if universally deployed, would effectively block a number of denial-of-service problems in the Internet. The Host Identity Protocol (HIP), on the other hand, is a proposal for deploying opportunistic, IPsec based end-to-end security, allowing any hosts to communicate in a secure way through the Internet. In this paper, we Nikander, et al. Expires December 26, 2004 [Page 1] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 explore various possibilities for combining ideas from Secure-i3 and HIP, thereby producing an architecture that is more efficient and secure than Secure-i3 and more flexible and denial-of-service resistant than HIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Hi3 architecture . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Minimal integration . . . . . . . . . . . . . . . . . . . 5 2.2 Separating data and control . . . . . . . . . . . . . . . 5 2.3 Providing more DoS protection . . . . . . . . . . . . . . 6 3. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 5. References (informative) . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Nikander, et al. Expires December 26, 2004 [Page 2] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 1. Introduction The original Internet protocol stack design deliberately did not include solutions for mobility, multi-address multi-homing, address agility in general, or security related to them. During the last few years, there has been a considerable number of proposals to address these issues, both separately and in an integrated manner, both from the academic community and from the industry. For a partial list of proposals, consider LIN6 [3], MAST/CELP [2], FARA [4], IPNL [5], PeerNet [6], and i3 [7]. So far, none of the proposals have gained major acceptance, partially perhaps because the time has not been ripe, and partially because many of the proposals do not properly take into account deployment and operational concerns. In this paper, we focus on two recent proposals, the Secure Internet Indirection Infrastructure, Secure-i3 [8], and the Host Identity Protocol [1], HIP. The Secure Internet Indirection Infrastructure proposes an i3-like Distributed Hash Tables (DHT) based overlay connectivity, based on registering triggers into the infrastructure, in a secure way. Inheriting from i3, Secure-i3 provides infrastructure-based services for mobility, multi-address multi-homing, multicast, and anycast. If a host uses only Secure-i3 for its communications, it can keep its IP addresses secret and utilize the infrastructure to effectively mitigate even severe distributed flooding denial-of-service attacks. However, as a major drawback, the proposal requires that all traffic flows through an overlay server, thereby almost doubling the amount of network traffic. Similarly, mobile hosts may not be able to use the most efficient route to communicate with each other. The Host Identity Protocol is a proposal to effectively add a new layer to the IP stack. The new layer is located within the IP layer, between the forwarding and the actual end-to-end functions, such as IPsec. Effectively, when HIP is used, the applications no longer connect to IP addresses but to separate Host Identifiers. HIP provides end-to-end oriented opportunistic security, CPU and memory exhausting denial-of-service resistance, mobility, and multi-address multi-homing. It allows any pair of hosts to authenticate the (perhaps anonymous) public key of their peer and establish confidential and integrity protected communication channels. Mobility and multi-address multi-homing are implemented by the end-hosts, allowing each end-host to inform its peers about the current IP addresses in use. It is possible to extend HIP with a PKI, but no serious efforts have been made into that direction. The base HIP protocol is designed to work without any new infrastructure, by storing the Host Identifiers into the existing DNS directories. However, in order to fully support initial rendezvous, Nikander, et al. Expires December 26, 2004 [Page 3] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 simultaneous movement, location privacy, and third party referrals, a new piece of infrastructure called the rendezvous server is needed. Compared to Secure-i3, HIP is unable to deal with the type of flooding denial-of-service attacks that Secure-i3 can address, and lacks support for multicast or anycast. A HIP rendezvous server simply forwards HIP control packets to a registered HIP host. It can also provide a two-way forwarding function [9]. Functionally, a rendezvous server is pretty similar to a single i3 server, as it forwards a packet to a registered IP address, based on the destination HIT in the packet. In this paper, we argue that Secure-i3, with some slight modifications, could provide a secure, integrated rendezvous infrastructure for HIP, basically forming a secure control plane for the Internet. HIP based data traffic could still be carried directly end-to-end, without involvement from the overlay, between trusted hosts. Additionally, we briefly consider some deployment and operational aspects, arguing that moving into a world combining Secure-i3 and HIP could be made gradually, giving immediate benefits to the upgrading sites. Nikander, et al. Expires December 26, 2004 [Page 4] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 2. Hi3 architecture We base our proposal for integrating HIP and Secure-i3 on the observation that DHT extended HIP rendezvous server and the basic Secure-i3 infrastructure are conceptually fairly close to each other. The basic idea is to allow direct, IPsec-protected end-to-end traffic while using indirection infrastructure to route the HIP control packets. Additionally, we to HIP apply the Secure-i3 DoS protection idea of not revealing the actual IP addresses. 2.1 Minimal integration As noted above, Secure-i3, with slight modifications, could be used as a decentralized instantiation of the HIP rendezvous server. The HITs could directly act as public 128-bit long triggers, and there would be no private triggers. Trigger insertion and removal could be secured with public key cryptography instead of using the secret key construct used in Secure-i3. Data traffic could flow, IPsec protected, directly between the hosts just as today. The main advantage of this initial design is its simplicity. A major drawback is that the Secure-i3 resistance against flooding DoS attacks is lost. Furthermore, many of the more advanced features of Secure-i3 are lost. In the following, we will show a new architecture that that retains many of those properties while keeping the efficiency of HIP. That is, we continue to allow direct IPsec protected traffic between end-hosts but also make it possible for end-hosts to use IPsec-forwarding middle boxes, thereby hiding their actual IP address from untrusted peers. 2.2 Separating data and control In i3, public triggers are only used for initial rendezvous. The server host is supposed to create a new private trigger and ask the client to use that for all future communication. In HIP, on the other hand, the HITs are used for all control traffic while the actual data traffic is passed in IPsec envelopes, indexed by SPIs. For the data traffic, the IPsec envelopes and SPIs can be used to implement DoS protection in a structurally similar way to Secure-i3. It is easy to design a middle box that forwards traffic based on < destination address, SPI > pairs. The middle boxes can securely learn the appropriate mappings by listening to the signed HIP control packets flowing through them. Such a middle box can also be easily located between distinct IP realms. Hence, instead of selecting an i3 server that is topologically close to the communication path and using that to forward regular traffic, as suggested in [7], a host could utilize an IPsec-forwarding middle box on the path, either Nikander, et al. Expires December 26, 2004 [Page 5] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 within an IP realm or between multiple IP realms. As the middle box can be on or close to the path, there is no triangular routing. Furthermore, with the HIP mobility and multi-homing mechanisms, a host under attack could even selectively move its legitimate traffic over to alternative middle boxes, similar to a host dynamically changing its private trigger in i3. In Hi3, the SPI mappings can be created dynamically, basically at any location, independent of the trigger and SPI values. This can be compared to Secure-i3, where the private triggers are distributed based on the DHT topology. Using private triggers necessitates the host to learn the routing location of the servers in order to be able to select a proper one. When SPI based forwarding is used, it is sufficient that the host knows a number of IPsec-forwarding middle boxes that are willing to serve the host. The hosts do not need to know anything about the DHT. As the SPI-based forwarding and firewalling functionality is separate from the control plane, each host and site can implement the function in a way suitable to them. That makes deployment easier. 2.3 Providing more DoS protection Above, we separated the control traffic and regular data traffic into different ``planes'', and protected the data plane with IPsec-forwarding middle boxes. However, this arrangement still leaves the host vulnerable to DoS attacks through the control messages. In other words, it is still possible to flood hosts by sending traffic to their public triggers, i.e., HITs. To block this attack, we next consider a few variations. As an initial step, we can divide the indirection infrastructure into two parts, more or less like in Secure-i3. The first part stores only public triggers, and it forwards only HIP I1 messages. Compared to the current situation, this arrangement blocks possible I1 storms already at the indirection infrastructure. The second part stores temporary private triggers, and carries the rest of HIP control messages. As a first approximation, we can imagine the HIP hosts to create temporary triggers as they reply to I1 messages with R1 messages. The created trigger will initially have a very short lifetime, and only a successful R2 message will update its lifetime. But we can do better. When a HIP host registers its public trigger to the public part of the indirection infrastructure, it can also delegate the process of replying to I1s to the infrastructure. In HIP, replying to an I1 is a mechanical operation that does not create Nikander, et al. Expires December 26, 2004 [Page 6] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 any state. Hence, if a HIP host provides the infrastructure with a number of pre-computed R1 messages, the infrastructure can reply to I1s by constructing the appropriate R1 packets from the pre-computed messages. The R1 could include a new private trigger. The private triggers can be distributed over a number of DHT servers, thereby leveling load in the case of an I1 flood. Furthermore, the HIP puzzle can be defined to depend on the private trigger, making the solution valid only for that particular private trigger. Once the initiator has processed the R1 packet and produced the puzzle solution, it sends an I2. The I2 is now sent to the private trigger. Furthermore, the DHT server that hosts the private trigger can verify that the puzzle solution is correct before passing the I2 packet to the end-host. Effectively, this distributes the proposed Secure-i3 DoS-filter function over all DHT server nodes, allowing the puzzle to be formed and verified by different nodes. Note that in the resulting structure we do not need IP source addresses for anything any more. The initial requests are sent to the infrastructure, and the infrastructure answers back based on the requestor's registered identifier. Once the HIP association has been set up, the source addresses are no longer used. Consequently, the source address field can be reused for other purposes, for example, to record the packet's path. Nikander, et al. Expires December 26, 2004 [Page 7] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 3. Mobility In Hi3, basic mobility between already communicating hosts can be provided directly at the HIP level, without involving the infrastructure. Only if the hosts lose direct reachability information, they need to revert back to the infrastructure. Even in that case they may use private triggers, being safe from attacks launched by third parties. However, if they do use private triggers, the hosts must keep the infrastructure updated with their current location information. For initial reachability, a mobile host needs to update its public registrations at the infrastructure. To reduce signalling overhead, we propose that the mobile host only updates its public registration. As the private triggers are created by the infrastructure during the initial session setup (see Section 2.3), the mobile hosts could easily provide the infrastructure with information that allows it to distribute this update to the servers hosting the private triggers. By combining the end-to-end mobility provided by HIP and the indirect mobility provided by the infrastructure, the resulting mechanism is highly efficient (no triangle routing for regular data) and robust (inherited from i3). Nikander, et al. Expires December 26, 2004 [Page 8] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 4. Acknowledgements The authors want to thank Jukka Ylitalo, Heikki Mahkonen and Jan Melen for fruitful discussions on this problem space. 5 References (informative) [1] Moskowitz, R., "Host Identity Protocol Architecture", draft-moskowitz-hip-arch-05 (work in progress), October 2003. [2] Crocker, D., "CHOICES FOR MULTIADDRESSING", draft-crocker-mast-analysis-01 (work in progress), October 2003. [3] Ishiyama, M., Kunishi, M. and F. Teraoka, "An Analysis of Mobility Handling in LIN6", in Proceedings of International Symposium on Wireless Personal Multimedia Communication (WPMC) 2001, 2001. [4] Clark, D., Braden, R., Falk, A. and V. Pingali, "FARA: Reorganizing the Addressing Architecture", in ACM SIGCOMM 2003 Workshops, August 25-27, Germany, Aug 2003. [5] Francis, P., "IPNL: A NAT-extended Internet Architecture"", in Applications, Technologies, Architectures, and Protocols for Computer Communications, 2001. [6] Eriksson, J., Faloutsos, M. and S. Krishnamurthy, "Pushing Peer-to-Peer Down the Stack", in Proceedings of 2nd International Workshop on Peer-to-Peer Systems (IPTPS'03), Feb 2003. [7] Stoica, I., Adkins, D., Zhuang, S., Shenker, S. and S. Surana, "Internet Indirection Infrastructure", in Proceedings of ACM SIGCOMM 2002, Aug 2002. [8] Adkins, D., Lakshminarayanan, K., Perrig, A. and I. Stoica, "Towards a More Functional and Secure Network Infrastructure", Technical report UCB/CSD-03-1242, 2003. [9] Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security, Mobility, and Multi-Homing in a HIP Way", in Proceedings of Network and Distributed Systems Security Symposium, NDSS'03, Feb 2003. Nikander, et al. Expires December 26, 2004 [Page 9] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 Authors' Addresses Pekka Nikander Ericsson Research Nomadic Lab JORVAS FI-02420 FINLAND Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com Jari Arkko Ericsson Research Nomadic Lab JORVAS FI-02420 FINLAND Phone: +358 9 299 1 EMail: jari.arkko@nomadiclab.com Borje Ohlman Ericsson Research IP Networks KISTA SWEDEN EMail: borje.ohlman@ericsson.com Nikander, et al. Expires December 26, 2004 [Page 10] Internet-Draft Host Identity Indirection Infrastructure (Hi3) June 2004 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 (2004). 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. Nikander, et al. Expires December 26, 2004 [Page 11]