[Hipsec-rg] draft-irtf-hip-experiment-04

[thomas.r.henderson at boeing.com (Henderson, Thomas R)]

 

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander at nomadiclab.com] 
> Sent: Tuesday, July 22, 2008 12:38 AM
> To: Andrei Gurtov
> Cc: hipsec-rg at honor.trusecure.com
> Subject: Re: [Hipsec-rg] draft-irtf-hip-experiment-04
> 
> Quick notes based on a very quick review:
> 
> - Section 2.1 focuses only on a BEET-like implementation, where the  
> IPsec part of the stack is extended.  As discussed a few years ago  
> within some IPsec-related WG (no longer remember which one), such an  
> implementation is unacceptable to some IPsec folks.  Therefore, it  
> would be good to describe also the alternatives, such as using plain  
> transport mode IPsec with HITs, and then doing NAT-like translation  
> below the IPsec layer, without touching the PF_KEY API or 
> IPsec at all.
> 
> - Section 4.1 could also briefly mention the DNS proxying 
> approach, in  
> which case no library changes are required?
> 
> It would be good to start getting some kind of conclusions.  I think  
> we start to be far enough so that we start to understand all the  
> issues in the small scale, and can probably extrapolate most (if not  
> all) of them to larger scale.

Pekka, thanks for reviewing.  I briefly mentioned to Andrei when doing
this latest resubmission that I'd like to see a major revision of the
document for -05 version, because I think it is drifting a bit from its
purpose which is to provide some conclusions or guidance back to the
IESG.  We probably have to refocus the text on that.

I think we are starting to understand the issues regarding how HIP might
impact people who deploy it as experimental software on their machine,
but we have little feedback, in my opinion, on other deployment issues
such as infrastructure (name server, rendezvous server) deployment,
managing HIP keys, or NAT traversal, for instance.

It is quite expensive to conduct grand experiments so one way I have
been thinking of starting again to work the issue would be to conduct a
preliminary analysis or use case development of what would it take for
some large commercial enterprise to deploy and manage HIP to ~100,000
devices, or for some large complicated network (think, for example, the
civil aviation environment with multiple service providers, regional
control centers in different countries, planes from many different
commercial airlines, and airports) to use HIP, or for a new
NAT-traversing P2P application to co-deploy with HIP on the IPv4
Internet.  Then, such use case development might motivate more targeted,
manageable experiments.

Tom