Subject: [Hipsec] ESP in clientVPN tunnel mode - what is needed in exchange

From: Robert Moskowitz <[email-masked]>
Date: Mon, 19 May 2014 14:08:54 -0400

I have a real need to provide ESP tunnel mode from a HIP client to a 
gateway.  The world just won't go as nicely as I would have wanted it to.

In the HIPL manual, there is an example of running OpenVPN within the 
BEET ESP connection, but I don't think that ends up with the same as ESP 
tunnel mode.

So what would be needed.  Simply a indicator that tunnel mode is in use, 
the run DHCP (or RA) through the tunnel?  Actually send addressing 
information as HIP parameters?

You don't want to use HITs in RFC4303 tunnel mode as is described in 
5202-bis.  You can use the initator's (client) HIT, but then you would 
still need to map it on the gateway side.

Probably have to go look at what ESP does for tunnel support  :)' but 
comments are welcome.

The tunnel needs act differently than 'classic ESP tunnel' so that HIP 
mobility is maintained.

I suspect that others have given this more thought in actually 
implementing it, so please direct me to any papers on this.

THanks

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 19 May 2014 14:14:11 -0400

More thoughts. 2 reserved bits can be used:

1 bit to indicate tunnel rather than transport
1 bit to indicate IPv4 or IPv6 tunnel addressing

Initially use the HIT/LSI to carry DHCP/RA packets through tunnel? 
Though LSI is a bit messy. Though again, others more familiar with this 
part may tell me how easy this is to handle.

On 05/19/2014 02:08 PM, Robert Moskowitz wrote:
> BEET ESP connection, but I don't think that ends up with the same as 
> ESP tunnel mode.
>
> So what would be needed. Simply a indicator that tunnel mode is in 
> use, the run DHCP (or RA) through the tunnel? Actually send addressing 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Mon, 19 May 2014 21:53:07 +0300

Hi,

> gateway.  The world just won't go as nicely as I would have wanted it to.

location-based security is old fashioned :(

At the application layer, tunnel mode may have some implications on the 
IPv4-IPv6 interoperability aspects of HIP.

> BEET ESP connection, but I don't think that ends up with the same as ESP

We tried successfully OpenVPN over HIP and vice versa.

> implementing it, so please direct me to any papers on this.

my dissertation lists the following papers:

* P. Salmela and J. Melén. Host Identity Protocol Proxy. In J. Filipe 
and L. Vasiu, editors, ICETE, pages 222–230. INSTICC Press, 2005.

* G. Iapichino and C. Bonnet. Host Identity Protocol and Proxy Mobile 
IPv6: a Secure Global and Localized Mobility Management Scheme for 
Multihomed Mobile Nodes. In Proceedings of the 28th IEEE conference on 
Global telecommunications, GLOBECOM’09, pages 578–583, Piscataway, NJ, 
USA, 2009. IEEE Press.

* D. Zhang, X. Xu, J. Yao, and Z. Cao. Investigation in HIP Proxies, 
Oct. 2011. Work in progress, Internet draft.

* T. Henderson, S. C. Venema, and D. Mattes. HIP-based Virtual Private 
LAN Service (HIPLS), Mar. 2012.

* J. Melen, J. Ylitalo, and P. Salmela. Host Identity Protocol-based 
Mobile Proxy, Aug. 2009. An expired Internet draft.

* R. H. Paine. Beyond HIP: The End to Hacking As We Know It. BookSurge 
Publishing, 2009.

Also this one:

http://link.springer.com/chapter/10.1007%2F978-3-540-75993-5_11

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 19 May 2014 15:11:50 -0400

> location-based security is old fashioned :(

It is but it is a case of stepwise development/deployment.  The parties 
involved first want their VPNs like they always had them but mobile.  
Then slowly migrate...

>
> At the application layer, tunnel mode may have some implications on 
> the IPv4-IPv6 interoperability aspects of HIP.
>

Yes, but OpenVPN over HIP adds what overhead byte-wise.  I would think 
there would be ESPnESP here.  Granted that was in the design for ESP, 
but still this is mobile.

> http://link.springer.com/chapter/10.1007%2F978-3-540-75993-5_11

One might think that a proxy has more work to perform on a per-packet 
basis than a gateway.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 19 May 2014 15:51:00 -0400

On 05/19/2014 02:14 PM, Robert Moskowitz wrote:
> Though LSI is a bit messy. Though again, others more familiar with 
> this part may tell me how easy this is to handle.

RFC 3456 for DHCP over IPsec. At least for IPv4. Now to read it...

>> use, the run DHCP (or RA) through the tunnel? Actually send 
>> addressing information as HIP parameters?
>>
>> The tunnel needs act differently than 'classic ESP tunnel' so that 
>> HIP mobility is maintained.
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 20 May 2014 09:13:31 -0400

> the IPv4-IPv6 interoperability aspects of HIP.

I have thought a lot about this, and BOY does it ever mess this up. 
There would need to be IPv4/v6 signalling within the ESP tunnel to make 
this work.  The VPN interface (separate from the HIP interface) would 
'know' if the incoming packet was v4 or v6, and would tag the ESP header 
appropriately?

Or no, wait, not so simple.  Actually the addresses ARE in the inner 
headers, I am getting confused with a HIP proxy that does not maintain 
an identity for each non-HIP host :)  But can ESP tunnel mix and match 
v4 and v6 inner packets...

Oh my head hurts!

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 20 May 2014 16:47:48 -0400

So DHCP could be sent in an R1 in a REQ_INFO parameter.
I2 would have the DHCP request and R2 the DHCP information?

You could pass DHCPv4/v6 as well as RA config information this way. Does 
make the packets a tad bigger!

On 05/20/2014 09:13 AM, Robert Moskowitz wrote:
> There would need to be IPv4/v6 signalling within the ESP tunnel to 
> make this work. The VPN interface (separate from the HIP interface) 
> would 'know' if the incoming packet was v4 or v6, and would tag the 
> ESP header appropriately?
>