Subject: [Hipsec-rg] draft-irtf-hip-experiment-01.txt link
From: [email-masked] (Pekka Nikander)
Date: Sun Jul 31 03:04:02 2005

Andrei and Thomas,

> http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-01.txt
>

Thanks for working on this draft.  I think it makes a pretty useful  
summary of what is going on right now and what are the small scale  
problems and issues that people are looking at.  As such, keeping the  
document up to date clearly provides value to the community.

However, if we consider further future, when we hopefully have some  
limited real experience from using HIP in the Internet, I think we  
should focus then on more large scale issues.  Both practical ones  
(does HIP work through existings NATs?) and more fundamental ones  
(does the proposed DHT-based system really scale?  What are its  
security properties).

Hence, I think keeping the draft up to date in its current format is  
good, but I would also see it to evolve into a more substantial  
*experience* report in the future.  More answering to the question of  
what works, what does not, and what are the potential practical  
consequences if people started to widely use HIP in the Internet.

--Pekka

From: [email-masked] (Andrei Gurtov)
Date: Sat Jul 30 08:57:00 2005
Subject: [Hipsec-rg] draft-irtf-hip-experiment-01.txt link
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-9056-1122728388-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-01.txt

--=_courier-9056-1122728388-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-9056-1122728388-0001-2--

From: [email-masked] (Lars Eggert)
Date: Fri Jul 29 15:13:01 2005
Subject: [Hipsec-rg] draft-irtf-hip-dht-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--Apple-Mail-34-475929395
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi,

On Jul 29, 2005, at 20:55, Ahrenholz, Jeffrey M wrote:
> The HIP OpenDHT interface draft that I would like to introduce at  
> the RG meeting can be found here:
> http://hipserver.mct.phantomworks.org/drafts/draft-irtf-hip-dht-00.txt
> (While this was ready prior to the draft cutoff date, I was unable  
> to release until today due to internal legal problems.)
>
> This draft simply specifies what has already been posted to this list
> (see http://honor.trusecure.com/pipermail/hipsec-rg/2005-June/ 
> 000177.html). The idea is to have a common interface for using HIP  
> with OpenDHT that different implementations can interoperate with.

very cool! I'm excited to see that this implements the direct FQDN- 
 >HIT->IP mappings that may enable simpler rendezvous, multihoming  
and mobility functionality [1]. Are you looking into supporting the  
reverse mappings as well? (Not as important, but very nice to have.)

Maybe we can find some time to chat with interested folks in Paris?  
Is there another HIP lunch or dinner planned?

Lars

[1] HIP Resolution and Rendezvous Problem Description. Lars Eggert  
and Julien Laganier. Expired Internet Draft draft-eggert-hiprg-rr- 
prob-desc-00.txt, Work in Progress, October 2004. http:// 
www.larseggert.de/papers/draft-eggert-hiprg-rr-prob-desc-00.txt
--
Lars Eggert                                     NEC Network Laboratories

--Apple-Mail-34-475929395
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-34-475929395--

From: [email-masked] (Ahrenholz, Jeffrey M)
Date: Fri Jul 29 14:53:01 2005
Subject: [Hipsec-rg] draft-irtf-hip-dht-00.txt
Message-ID: <[email-masked]>

The HIP OpenDHT interface draft that I would like to introduce at the RG =
meeting can be found here:
http://hipserver.mct.phantomworks.org/drafts/draft-irtf-hip-dht-00.txt
(While this was ready prior to the draft cutoff date, I was unable to =
release until today due to internal legal problems.)

This draft simply specifies what has already been posted to this list=20
(see =
http://honor.trusecure.com/pipermail/hipsec-rg/2005-June/000177.html). =
The idea is to have a common interface for using HIP with OpenDHT that =
different implementations can interoperate with.

thanks,
-Jeff

From: [email-masked] (Andrei Gurtov)
Date: Tue Jul 26 11:08:00 2005
Subject: [Hipsec-rg] Emailing: HIPRG_IETF63_agenda.txt
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-7694-1122390626-0001-2
Content-Type: multipart/mixed;
 boundary="------------080102010605020900080009"

This is a multi-part message in MIME format.
--------------080102010605020900080009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Attached is the HIP RG agenda for Paris.

Andrei

--------------080102010605020900080009
Content-Type: text/plain;
 name="HIPRG_IETF63_agenda.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="HIPRG_IETF63_agenda.txt"

FRIDAY, August 5, 2005
0900-1130 Room 341

Chairs:  Andrei Gurtov ([email-masked])
         Tom Henderson ([email-masked])
	 (Tom is not attending this time)

AGENDA:

1. Agenda, attendance sheets, note-taker, jabber scribe
5 min

2. HIP experiment report (Andrei Gurtov)
draft-irtf-hip-experiment-01.txt 
10 min

3. HIP-OpenDHT Interface (Jeff Ahrenholz)
draft-boeing-hiprg-opendht-00.txt (sic)
15 min

4. Using HIP with Legacy Applications (Pekka Nikander)
draft-henderson-hip-applications-01.txt
10 min 

5. Migrating HIP application in the Internet using Xen (Pekka Nikander)
Ongoing work with T. Koponen and A. Gurtov
15 min

6. NAT problem statement (Martin Stiemerling)
draft-stiemerling-hip-nat-05.txt
10 min

7. Traversal of HIP aware NATs and Firewalls (Hannes Tschofenig)
draft-tschofenig-hiprg-hip-natfw-traversal-02.txt
10 min

8. Using SRTP transport format with HIP (Hannes Tschofenig)
draft-tschofenig-hiprg-hip-srtp-00.txt
draft-tschofenig-hiprg-host-identities-02.txt
15 min

9. Privacy extentions (Alfredo Matos)
draft-matos-hip-privacy-extensions-00
15 min

10. Implementation status of BEET and PATH (Andrei Gurtov)
draft-nikander-esp-beet-mode-03.txt
draft-nikander-hip-path-00.txt
10 min

11. Hi3 implementation and experimental results (Andrei Gurtov)
draft-nikander-hiprg-hi3-00.txt
10 min

12. Hi3 scalability analysis (Dmitry Korzun)
draft-nikander-hiprg-hi3-00.txt
15 min

13. Open Discussion.

--------------080102010605020900080009--

--=_courier-7694-1122390626-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-7694-1122390626-0001-2--

From: [email-masked] ([email-masked])
Date: Thu Jul 21 13:54:02 2005
Subject: [Hipsec-rg] Re: draft-irtf-hip-experiment-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

The Secretariat CANNOT process your Internet-Draft submission due to
following reason(s):

 * All Internet-Drafts must have on the first page an intellectual property
rights (IPR) statement that says:

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.

If you are using xml2rfc, this can be accomplished by updating the
'ipr' attribute in the 'rfc' element to refer to 3978. See
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr for
more information.

> Hi,
>
> This is a submission of the new version of HIP experiment report.
>
> Andrei
>
>

From: [email-masked] (Andrei Gurtov)
Date: Sun Jul 17 14:31:01 2005
Subject: [Hipsec-rg] Draft agenda, IETF63
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-14384-1121625126-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

This is a draft agenda, let me know if any changes are needed. Criteria 
for slot allocation have been 10-15 minutes for new items, 5-10 minutes 
for existing items to summarize the updates.

Andrei

FRIDAY, August 5, 2005
0900-1130 Room XX

Chairs:  Andrei Gurtov ([email-masked])
         Tom Henderson ([email-masked])
     (Tom is not attending this time)

AGENDA:

1. Agenda, attendance sheets, note-taker, jabber scribe
5 min

2. HIP experiment report (Andrei Gurtov)
draft-irtf-hip-experiment-01.txt
10 min

3. Hi3 implementation and experimental results (Andrei Gurtov)
draft-nikander-hiprg-hi3-00.txt
10 min

4. Hi3 scalability analysis (Dmitry Korzun)
draft-nikander-hiprg-hi3-00.txt
15 min

5. HIP-OpenDHT Interface (Jeff Ahrenholz)
draft-boeing-hiprg-opendht-00.txt (sic)
15 min

6. Using HIP with Legacy Applications (Jeff Ahrenholz)
draft-henderson-hip-applications-01.txt
10 min

7. Status of native HIP API (Andrei Gurtov on behalf of Miika Komu)
draft-mkomu-hip-native-api-00.txt
5 min

8. HIP application migration (Pekka Nikander)
Ongoing work with T. Koponen and A. Gurtov
15 min

9. Privacy extentions (Marco Liebsch)
draft-matos-hip-privacy-extensions-00
15 min

10. Using SRTP transport format with HIP (Hannes Tschofenig)
draft-tschofenig-hiprg-hip-srtp-00.txt
15 min

11. NAT problem statement (Martin Stiemerling)
draft-stiemerling-hip-nat-05.txt
10 min

12. Implementation status of BEET and PATH (Andrei Gurtov)
draft-nikander-esp-beet-mode-03.txt
draft-nikander-hip-path-00.txt
5 min

13. Open Discussion.
10 min

--=_courier-14384-1121625126-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-14384-1121625126-0001-2--

From: [email-masked] (Andrei Gurtov)
Date: Fri Jul 15 15:53:03 2005
Subject: [Hipsec-rg] draft-irtf-hip-experiment-01.txt
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-32555-1121457244-0001-2
Content-Type: multipart/mixed;
 boundary="------------010209070700060107000300"

This is a multi-part message in MIME format.
--------------010209070700060107000300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

This is a submission of the new version of HIP experiment report.

Andrei

--------------010209070700060107000300
Content-Type: text/plain;
 name="draft-irtf-hip-experiment-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-irtf-hip-experiment-01.txt"

IRTF HIP Research Group                                     T. Henderson
Internet-Draft                                        The Boeing Company
Expires: January 16, 2006                                      A. Gurtov
                                                                    HIIT
                                                           July 15, 2005

                         HIP Experiment Report
                      draft-irtf-hip-experiment-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 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 January 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This is the initial draft of the HIP-RG experiment report.

Henderson & Gurtov      Expires January 16, 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 16, 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 16, 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 16, 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 16, 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 16, 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 16, 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 16, 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 16, 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 16, 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 16, 2006               [Page 11]

Internet-Draft            HIP Experiment Report                July 2005

6.  General Implications

   TODO

Henderson & Gurtov      Expires January 16, 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 16, 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 16, 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: [email-masked]

   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: [email-masked]

Henderson & Gurtov      Expires January 16, 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
   [email-masked].

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 16, 2006               [Page 16]


--------------010209070700060107000300--

--=_courier-32555-1121457244-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-32555-1121457244-0001-2--

From: [email-masked] (Jan Mikael Melen)
Date: Fri Jul 15 05:54:01 2005
Subject: [Hipsec-rg] HIP4BSD source code base-03 and FBSD 5.4
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Thanks the link is now fixed! No it doesn't Linux compile on Linux.

   Regards,
	Jan

On Thursday 14 July 2005 20:32, Andrei Gurtov wrote:
> Hi,
>
> It seems the link is not correct on the web site
> http://www.hip4inter.net/download/hip_freebsd53_20050711.tar.gz
>
> should be
>
> http://www.hip4inter.net/download/hip_freebsd54_20050711.tar.gz
>
> Does it compile under Linux?
>
> Andrei
>
> Jan Mikael Melen wrote:
> >Hi,
> >
> >There is now available new version of the HIP4BSD source code at
> >http://www.hip4inter.net/ this version implements the draft-ietf-base-03
> > and FBSD kernel has been updated to 5.4. It has not yet been
> > interoperability tested.
> >
> >  Regards,
> >    Jan
> >_______________________________________________
> >Hipsec-rg mailing list
> >[email-masked]
> >http://honor.trusecure.com/mailman/listinfo/hipsec-rg

From: [email-masked] (Martin Stiemerling)
Date: Fri Jul 15 03:11:00 2005
Subject: [Hipsec-rg] I-D ACTION:draft-stiemerling-hip-nat-05.txt  (fwd)
Message-ID: <64F2AF5F539CA7000618A49E@[10.1.1.109]>

--==========7F1B34AF84F62F1CE8BF==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Dear all,

Please find attached the announcement of an updated "HIP across Middleboxes"
draft. This version includes comments of Tom Henderson and comments made
during the last HIPRG meeting.

A diff to the -04 draft is available here:

<http://www.stiemerling.org/ietf/hip/draft-stiemerling-hip-nat-05-diff-04.html>

  Martin

------------ Forwarded Message ------------
Date: Donnerstag, 14. Juli 2005 15:50 Uhr -0400
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-stiemerling-hip-nat-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Middlebox Traversal Issues of Host Identity
                          Protocol (HIP) Communication
	Author(s)	: M. Stiemerling, et al.
	Filename	: draft-stiemerling-hip-nat-05.txt
	Pages		: 13
	Date		: 2005-7-14
	
The Host Identity Protocol (HIP) fundamentally changes the way in
   which two Internet hosts communicate.  One key advantage over other
   schemes is that HIP does not require modifications to the traditional
   network-layer functionality of the Internet, i.e., its routers.  In
   the current Internet, however, many devices other than routers modify
   the traditional network-layer behavior of the Internet.  These
   "middleboxes" are intermediary devices that perform functions other
   than the standard functions of an IP router on the datagram path
   between source and destination hosts.  Whereas some types of
   middleboxes may not interfere with HIP at all, others can affect some
   aspects of HIP communication and others can render HIP communication
   impossible.  This document discusses the problems associated with HIP
   communication across network paths that include specific types of
   middleboxes, namely, network address translators and firewalls.  It
   identifies and discusses issues in the current HIP specifications
   that affect communication across these types of middleboxes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stiemerling-hip-nat-05.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.   You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce  to change your
subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-stiemerling-hip-nat-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-stiemerling-hip-nat-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---------- End Forwarded Message ----------

--==========7F1B34AF84F62F1CE8BF==========
Content-Type: message/rfc822;
 name="I-D ACTION:draft-stiemerling-hip-nat-05.txt "

To: [email-masked]
From: [email-masked]
Date: Thu, 14 Jul 2005 15:50:02 -0400
Subject: I-D ACTION:draft-stiemerling-hip-nat-05.txt 
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Middlebox Traversal Issues of Host Identity
                          Protocol (HIP) Communication
	Author(s)	: M. Stiemerling, et al.
	Filename	: draft-stiemerling-hip-nat-05.txt
	Pages		: 13
	Date		: 2005-7-14
	
The Host Identity Protocol (HIP) fundamentally changes the way in
   which two Internet hosts communicate.  One key advantage over other
   schemes is that HIP does not require modifications to the traditional
   network-layer functionality of the Internet, i.e., its routers.  In
   the current Internet, however, many devices other than routers modify
   the traditional network-layer behavior of the Internet.  These
   "middleboxes" are intermediary devices that perform functions other
   than the standard functions of an IP router on the datagram path
   between source and destination hosts.  Whereas some types of
   middleboxes may not interfere with HIP at all, others can affect some
   aspects of HIP communication and others can render HIP communication
   impossible.  This document discusses the problems associated with HIP
   communication across network paths that include specific types of
   middleboxes, namely, network address translators and firewalls.  It
   identifies and discusses issues in the current HIP specifications
   that affect communication across these types of middleboxes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stiemerling-hip-nat-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-stiemerling-hip-nat-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-stiemerling-hip-nat-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-stiemerling-hip-nat-05.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-stiemerling-hip-nat-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--==========7F1B34AF84F62F1CE8BF==========--

From: [email-masked] (Andrei Gurtov)
Date: Thu Jul 14 13:32:01 2005
Subject: [Hipsec-rg] HIP4BSD source code base-03 and FBSD 5.4
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-9342-1121362377-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

It seems the link is not correct on the web site
http://www.hip4inter.net/download/hip_freebsd53_20050711.tar.gz

should be

http://www.hip4inter.net/download/hip_freebsd54_20050711.tar.gz

Does it compile under Linux?

Andrei

Jan Mikael Melen wrote:

>Hi,
>
>There is now available new version of the HIP4BSD source code at 
>http://www.hip4inter.net/ this version implements the draft-ietf-base-03 and 
>FBSD kernel has been updated to 5.4. It has not yet been interoperability 
>tested.
>
>  Regards,
>    Jan
>_______________________________________________
>Hipsec-rg mailing list
>[email-masked]
>http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>  
>

--=_courier-9342-1121362377-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-9342-1121362377-0001-2--

From: [email-masked] (Jan Mikael Melen)
Date: Mon Jul 11 02:50:01 2005
Subject: [Hipsec-rg] HIP4BSD source code base-03 and FBSD 5.4
Message-ID: <[email-masked]>

Hi,

There is now available new version of the HIP4BSD source code at 
http://www.hip4inter.net/ this version implements the draft-ietf-base-03 and 
FBSD kernel has been updated to 5.4. It has not yet been interoperability 
tested.

  Regards,
    Jan