Re: [Hipsec] HIP Native NAT Traversal

[Ari Keranen <[e-mail]>]

On 04/13/2010 02:05 AM, Dan Wing wrote:
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Ari Keranen
>> Sent: Monday, April 12, 2010 2:33 AM
>> To: [e-mail]
>> Subject: Re: [Hipsec] HIP Native NAT Traversal
>>
>> Hi,
>>
>> On 04/09/2010 11:21 PM, Miika Komu wrote:
>>> On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote:
>>>> 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.
>>> 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.
>> 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.
> 
> 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.

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.

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

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


Cheers,
Ari