Subject: [Hipsec] HIP Native NAT Traversal

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 09 Apr 2010 16:14:34 +0300

Hi,

in Anaheim, we decided to continue discussing on the list the following
draft:

https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/

In particular, I would like to see discussions on the lessons learned
from the STUN-based implementations and potential benefits of
implementing STUN-like functionality in HIP.

Thanks,

Gonzalo
HIP WG co-chair

---

From: Miika Komu <[email-masked]>
Date: Fri, 09 Apr 2010 23:21:07 +0300

On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote:

Hi,

> implementing STUN-like functionality in HIP.

from a protocol design perspective, demultiplexing of HIP, ESP and STUN 
packets is complicated. At implementation level, this introduced an 
additional requirement of packet capture using iptables. I believe this 
part would become cleaner design and implementation-wise by replacing 
STUN with HIP.

It actually took quite a lot effort to hook in a standalone ICE library 
to the base exchange code. I believe it would also further complicate 
the mobility code.

+1 for the new draft, I believe having a single control plane instead of 
two makes things simpler. I would suggest the new draft to replace the 
existing one for standards track.

---

From: Ari Keranen <[email-masked]>
Date: Mon, 12 Apr 2010 12:33:10 +0300

Hi,

> part would become cleaner design and implementation-wise by replacing 

This is indeed a problem if you don't want to patch kernel code. While 
HIP packets can be simply demultiplexed using the non-ESP marker, STUN 
packets can't and therefore you need to either use some filtering before 
the IPsec processing (e.g., iptables) or process all the packets at user 
space, which causes some performance penalty.

> to the base exchange code. I believe it would also further complicate 

Also, using TURN for relaying IPsec ESP is not all that simple since you 
need to add and remove the TURN framing when sending data via a TURN 
relay. With an ESP relay you don't need any framing at all and all the 
ESP processing can be done as if no relay was used. That said, also TURN 
relaying can be used with the native NAT traversal mode and only the 
host using TURN relay needs to implement TURN.

I think the amount of implementation effort needed for integrating an 
ICE library into a HIP implementation turned out to be quite a bit 
higher that initially estimated. Also, the amount of extra code (some 10 
kLoC) needed for all the new parsers, state machines, etc., is quite 
high and by re-using the HIP code one should be able to do with much 
less. This should result in smaller binary size, less bugs, and easier 
debugging.

> existing one for standards track.

Considering the experiences with the STUN-based approach, the native HIP 
mode does sound like a better idea for the standards track.

Cheers,
Ari

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Apr 2010 16:05:55 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ari Keranen
> Sent: Monday, April 12, 2010 2:33 AM
> To: [email-masked]
> Subject: Re: [Hipsec] HIP Native NAT Traversal
> 
> Hi,
> 

Has there been a discussion to send STUN directly over HIP, rather 
than replacing STUN with STUN-mimicing HIP messages?  Sending
STUN messages directly over HIP would remove the need to demux
STUN/HIP/ESP -- you would only need to demux HIP/ESP in the kernel
(as with today's HIP), and deal with a single HIP 'container' for
the STUN messages.

> relay.

IPsec ESP native (IP protocol 50) across a NAT?  This isn't
going to work well with large scale NATs with lots of clients
going to the same destination (e.g., the same TURN server),
as I understand IPsec rekeying changes the SPI and the large
scale NAT won't know which IPsec session just got rekeyed.

-d

> With an ESP relay you don't need any framing at all 
> and all the 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: frogsir <[email-masked]>
Date: Tue, 13 Apr 2010 06:13:09 +0300

It will be easier to demultiplex connectivity checks for different HAs, if
we use HIP native NAT traversal

ICE is not a RFC yet. Therefore, it is not reliable. We have to consider the
incompatibility of  ICE versions and also STUN message versions.

On Fri, Apr 9, 2010 at 11:21 PM, Miika Komu <[email-masked]> wrote:

> additional requirement of packet capture using iptables. I believe this part
> would become cleaner design and implementation-wise by replacing STUN with
> HIP.
>
> It actually took quite a lot effort to hook in a standalone ICE library to
> the base exchange code. I believe it would also further complicate the
> mobility code.
>

-- 
Best Regards

Santtu (Nick name)
Xiang Liu

Operation Manager
Frosmo Ltd.
http://www.frosmo.com
twitter.com/Frosmo

Erottajankatu 15-17A
00130 Helsinki,
Finland

mobile: +358 44 3688809
fax: +358 20 7419 9099
Email: [email-masked]
MSN: [email-masked]

---

From: frogsir <[email-masked]>
Date: Tue, 13 Apr 2010 06:21:51 +0300

> (as with today's HIP), and deal with a single HIP 'container' for

*We have made such implementation.  The whole STUN message is encapsulate
into HIP_STUN parameter which is carried by HIP_UPDATE packets. it solves
most of  the demultiplexing problems indeed.*

-- 
Best Regards

Santtu (Nick name)
Xiang Liu

Operation Manager
Frosmo Ltd.
http://www.frosmo.com
twitter.com/Frosmo

Erottajankatu 15-17A
00130 Helsinki,
Finland

mobile: +358 44 3688809
fax: +358 20 7419 9099

---

From: Miika Komu <[email-masked]>
Date: Tue, 13 Apr 2010 08:31:49 +0300

On 13/04/10 06:21, frogsir wrote:

Hi,

> On Tue, Apr 13, 2010 at 2:05 AM, Dan Wing <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>      > From: [email-masked] <mailto:[email-masked]>
>      > [mailto:[email-masked] <mailto:[email-masked]>]
>     On Behalf Of Ari Keranen
>      > To: [email-masked] <mailto:[email-masked]>
> *We have made such implementation.  The whole STUN message is
> encapsulate into HIP_STUN parameter which is carried by HIP_UPDATE
> packets. it solves most of  the demultiplexing problems indeed.*

to be more precise, it was just an internal implementation trick to get 
incoming STUN messages from the packet capture module to hipd. So it 
really did not solve the problem because it still required HIP/ESP/STUN 
demuxing somewhere in the system.

Having STUN messages in HIP encapsulated format *on-the-wire* would 
solve the demux problem, but the extra parser and marshaling library 
would still be necessary for STUN which would further increase the 
footprint of hipd.

---

From: Ari Keranen <[email-masked]>
Date: Tue, 13 Apr 2010 10:10:07 +0300

> (as with today's HIP), and deal with a single HIP 'container' for

As Miika pointed out, this would still require implementing a STUN stack 
and considering that what is missing from HIP compared to STUN is just a 
couple of parameters, it does not seem worth while to duplicate all 
those features with STUN on top of HIP. Also, you would lose the 
possibility for middleboxes doing something smart when they see STUN if 
STUN was carried over HIP (if middleboxes would understand STUN over 
HIP, they would probably understand HIP too), so many of the benefits of 
using STUN would not apply here.

> scale NAT won't know which IPsec session just got rekeyed.

Actually, I meant UDP encapsulated IPsec ESP as described in 
draft-ietf-hip-nat-traversal.

Cheers,
Ari

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Apr 2010 12:31:24 -0700

> From: frogsir [mailto:[email-masked]] 
> Sent: Monday, April 12, 2010 8:22 PM
> To: Dan Wing
> Cc: Ari Keranen; [email-masked]
> We have made such implementation.  The whole STUN message is 
> encapsulate into HIP_STUN parameter which is carried by 
> HIP_UPDATE packets. it solves most of  the demultiplexing 
> problems indeed.     

Is that preferable to re-inventing STUN and ICE as HIP messages?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Apr 2010 12:41:23 -0700

> From: Ari Keranen [mailto:[email-masked]] 
> Sent: Tuesday, April 13, 2010 12:10 AM
> To: Dan Wing
> Cc: [email-masked]

Ok.

(I fear the day that middleboxes try to understand and 'help' STUN.)

> draft-ietf-hip-nat-traversal.

Ok, thanks.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Apr 2010 20:43:07 -0700

> [mailto:[email-masked]] On Behalf Of frogsir
> Sent: Monday, April 12, 2010 8:13 PM
> Cc: [email-masked]
> It will be easier to demultiplex connectivity checks for 
> different HAs, if we use HIP native NAT traversal
> 
> ICE is not a RFC yet. 

ICE is in the RFC Editor's queue and will be RFC5245,
http://www.rfc-editor.org/authors/rfc5245.txt

> Therefore, it is not reliable. We have 
> to consider the incompatibility of  ICE versions and also 
> STUN message versions. 

There is only one version of ICE and it supports only
one version of STUN.  There are certainly pre-standard 
implementations of ICE (such as that used by Microsoft's
MSN), but HIP would never need to interoperate with those.

-d

> 	from a protocol design perspective, demultiplexing of 
> HIP, ESP and STUN packets is complicated. At implementation 
> level, this introduced an additional requirement of packet 
> capture using iptables. I believe this part would become 
> cleaner design and implementation-wise by replacing STUN with HIP.
> 	
> 	It actually took quite a lot effort to hook in a 
> standalone ICE library to the base exchange code. I believe 
> it would also further complicate the mobility code.
> 	
> 	+1 for the new draft, I believe having a single control 
> plane instead of two makes things simpler. I would suggest 
> the new draft to replace the existing one for standards track.
>