[Hipsec-rg] HIP experiments

[miika at iki.fi (Miika Komu)]

On Thu, 19 Oct 2006, Henderson, Thomas R wrote:

>> i) experimental requirements.  What are we trying to accomplish with
>> experiments?  Can we sketch out the experiments that need to be
>> conducted and the data that need to be gathered?  There should be more
>> than one experiment, and it might be productive to define
>> them in small
>> chunks so that the task is more approachable by the
>> community.  We ought
>> to establish some milestones and have some discussion to refine the
>> approaches.
>
> Let me start by describing some broad categories of experiments that I
> envision.  I'd like to hear feedback on whether people already have
> conducted or plan to soon conduct experiments on these topics, and what
> other topics should be included.  Please provide pointers to published
> experimental results.

Some miscellaneous pointers and comments below.

> I will divide the below into "benefits" and "costs".
>
> -> Benefits:  What specific benefits accrue to particular applications
> when HIP is in the stack?  What generic benefits apply to having HIP
> generally available for all upper-layer protocols?
>
> 1) Host mobility and multihoming.  HIP allows for transport sessions to
> survive address locator changes.  There is a possibility that end-to-end
> HIP mobility and multihoming can occur as fast or faster than other
> end-to-end approaches including MIPv6 with route optimization and SIP
> mobility.  Are there specific experiments that quantify the possible
> handover benefits in typical operational settings?  Are any particular
> end-to-end mobility benefits from HIP offset by various (non-HIP) fast
> handoff approaches deployed for mobile networks, in practice?  Can
> anyone demonstrate that application performance is demonstrably improved
> by HIP mechanisms?

http://www.jokela.org/publications/iswcs04.pdf
http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

> Related to this, it has been suggested that HIP offers the potential for
> much better nomadic connectivity, such as the potential for a user to
> close his or her laptop at work, move to a coffee shop or home network,
> and keep all of the transport and application sessions alive.

http://www.ambient-networks.org/publications/Protocol_Enhancements_for_Intermittently_Connected_Hosts_0507.pdf
http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-crosslayer-00.txt

> 2) Security.  I have heard at least one HIP proponent suggest that the 
> main benefit of locating HIP at the network layer was to protect the 
> network layer against attacks on the bindings for mobility and 
> multihoming.  Is there evidence of stronger security than, for instance, 
> other techniques for mobility and multihoming such as mobile IP and 
> various multihoming techniques previously categorized by the multi6 
> working group?  Do we have any experimental or operational evidence that 
> HIP (e.g. SIGMA handshake) provides better security for public servers 
> than do other approaches that have been deployed, such as SYN cookies? 
> How about for clients?  Return routability checks also exist for mobile IP, 
> for instance.

I would add TLS to the comparison list. Also, there is a very initial 
draft in BTNS wg:

http://www.ietf.org/internet-drafts/draft-komu-btns-api-00.txt

> 3) IPv6 transition.  Because HIP allows for roaming across address
> families, it has been suggested as a mechanism to improve transition to
> IPv6.  This technique has been demonstrated at previous HIP meetings;
> has this been experimentally validated or has there been any more work
> along these lines?

InfraHIP has one post-grad student working on this topic. In general, the 
application and network layer address family independence eases transition 
towards IPv6, but first one should transition to HIP :) I believe that the 
identity/locator split can slow down transition towards IPv6 because the 
new namespace of HIP can extend the lifetime of NATted architectures:

http://www.ietf.org/internet-drafts/draft-schmitt-hip-nat-traversal-02.txt

(I am in no way advocating the use of NATs; they add complexity to all 
protocols but IPv6 is not here yet to wash away all of the NATs)

> 4) New architectures.  There have been a number of architectural and
> protocol proposals that accomplish some of the basic goals of HIP yet
> without requiring any use of HIP in the network stack.  For example, the
> NUTSS architecture
> ...

Regarding to SIP-HIP integration:

http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identities-04.txt

> -> Costs:  What are the operational costs of deploying HIP on a wide
> scale, including costs on implementation complexity, new or modified
> infrastructure, and operations, administration, and management (OA&M)?

Two publications in progress related to this.

> 7) NAT traversal.  How well does HIP NAT traversal work?  Researchers
> working on NAT traversal have explicitly tested their techniques on a
> large sample of commercially-available NATs, and published the results.
> Has anyone done this for HIP?  What are the costs in terms of
> implementation complexity or server infrastructure needed for hole
> punching?

Work in progress. Lauri Silvennoinen has almost completed the NAT 
implementation that covers base exchange (initiator and responder can be 
behind NAT). Better NAT mobility and multihoming specification work is 
also work in progress.

> 8) Non-routable addresses in applications.  Some existing HIP
> implementations (and many other overlay implementations outside of HIP)
> use modified resolvers to return quantities in DNS responses that are
> not IP addresses.  For instance, it is possible to return HITs instead
> of IPv6 addresses, to allow for non-HIP-aware applications to use HIP.
> Many people have objected in principle to this practice, claiming that
> it will break certain applications (such as ones that do referrals).
> Yet, the anecdotal claims by people who have adopted this implementation
> style are generally that everything works reliably.  Can we start to
> more systematically track what types of applications are prone to
> problems with this implementation approach?  Or is this concern really a
> non-issue in practice?

http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-03.txt
http://www.ietf.org/internet-drafts/draft-komu-shim-native-api-00.txt
http://www.iki.fi/miika/docs/f17-komu.pdf

There is some on going work regarding to these issues in InfraHIP.

> 9) Implementation costs.  Implementors have discovered that there are
> various costs of providing HIP in host operating systems.  First, it
> complicates the per-packet processing and has the potential to make
> certain operations (e.g., source address selection) more complicated.
> Second, there are performance hits due to both the cryptographic
> operations and due to implementation tricks that avoid kernel
> modifications but instead lead to additional memory copies.  Third,
> there is a policy management issue (how do I keep track of and protect
> my host identities?  How do I express that I want to browse using an
> anonymous host identity but use published host identity for my VoIP
> calls?  What about multi-user machines?)  It has been observed that HIP
> and other overlay techniques bring to the surface a lot of policy and
> management issues that heretofore could have been ignored or implicitly
> handled.  Can we better document these costs?

http://infrahip.hiit.fi/papers/niklas_dippa.pdf

> 10) HIP-aware middleboxes.  Researchers have suggested that future
> middleboxes could become HIP-aware and offer better control of network
> policy based on endpoint identification.  Do we have experience on the
> costs to the middleboxes and other policy management infrastructure to
> support these extensions?  Do we have any deployment experiences here?

Some work related to this is in progress in InfraHIP.

-- 
Miika Komu                                       http://www.iki.fi/miika/