[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/