One document matched: draft-nikander-hiprg-hi3-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 17:43:57 |