Re: [Hipsec] To tunnel or not

["Laganier, Julien" <[e-mail]>]

Robert Moskowitz wrote:
> 
> ESP Transport in a bound, end-to-end operation
> 
> or
> 
> ESP Tunnel  with HITS (or LSI?) explicit.
> 
> Developers have reported challenges in using what we have been calling
> BEET mode, and have pointed out that if explicit tunnels were used,
> then the special HIP "optimization"  (? right word) of Transport mode would
> be avoided.

While implementing HIP circa 2002 the only reason I had to start hacking the kernel was that "optimization". Other than that I could run the same daemon on FreeBSD and SunOS, and have the daemon configure IPsec SAs via PF_KEY. 

Thus I do agree that BEET is challenging to the extent that is not part of standards IPsec implementation. Would BEET be a standard part of IPsec the challenge would disappear. Is it likely? I don't think so...
 
> I have at least two technical problems with use of tunnel mode:
> 
> What is enumerated in the tunnel?  HITs always or HITs for IPv6 apps
> and LSIs for IPv4?  (as we have demonstarted that IPv4 apps work well over
> HIP over IPv6).  If HITs how will this work for IPv4?  I suspect that
> someone can explain how this could 'work'?

The Security Policy Database I had had entries requiring use of ESP tunnel mode for any communication between a local HITs or LSIs and any remote one.

A given communication from a local HIT or LSI to a remote one would thus trigger via PF_KEY the HIP daemon to establish keys. The HIP daemon would in turn insert a specific SPD entries requiring protection of communication between the specific local and remote HIT/LSI via an ESP tunnel mode SA between the local and remote IP addresses (v4 or v6).
 
Thus for every association there's one or two SPD entries (keyed by local/remote HITs and/or  LSIs), and the protection required by these entries is afforded by a tunnel mode SA between the local and remote IP addresses of the peers.

> Would there be expectations on tunnel behaviour that would have to be
> negotiated?

I'm do not understand what sort of behavioral expectations you're talking about. Can you tell us more..
 
> My basic philosophy was ESP transport was used as a 'short hand' for
> the HIP connection between two hosts.  That HIP is not a key negotiation
> for ESP, but that ESP is used operationally to simplify HIP (not to develop
> YAP) with SPIs being pointers to the underlying HITs (did I remember
> that right? :) ).

I remember that.
 
But I'm not sure this is in contradiction with the use of HIP as a key management to setup IPsec tunnel mode security association between pair of HITs (or LSIs.) These are IMHO two views of the same machinery.

> I can see where the process between two hosts is a tunneling process
> and in that HIP is used to secure the tunnel, but here the tunnel is not
> coupled to HIP but rather the process between two hosts that uses HIP.
> Does that make enough sense?

Not sure I'm following you...

--julien