Re: [Hipsec] To tunnel or not

[Miika Komu <[e-mail]>]

Robert Moskowitz wrote:

Hi,

> 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.
> 
> 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'?

We have two choices:

a) Let the tunnel enumerate both LSI and HITs
b) Let the tunnel enumerate only HITs. LSIs must be translated locally 
to HITs as with BEET.

Option (a) is bad because LSIs are supposed to be local. So I'd vote for 
option (b).

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

I think we should modularize negotiation to support different protocols 
(ESP vs. AH vs. some other like S-RTP)  and their modes (tunnel vs. 
transport vs. beet).

> 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 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?
> 
> These are reasonable questions that have been asked of me over the past 
> year, and I would like to get some other's views.

Yes, it makes sense.