Subject: [Hipsec] To tunnel or not

From: Robert Moskowitz <[email-masked]>
Date: Wed, 19 Aug 2009 18:30:37 -0400

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

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

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.

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 20 Aug 2009 15:42:33 -0700

Robert Moskowitz wrote:
> 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...
 
> 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

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

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

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

Not sure I'm following you...

--julien

---

From: Miika Komu <[email-masked]>
Date: Mon, 24 Aug 2009 15:20:55 +0300

Robert Moskowitz wrote:

Hi,

> 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 

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).

> year, and I would like to get some other's views.

Yes, it makes sense.