Re: [Hipsec] HIP Native NAT Traversal

[Ari Keranen <[e-mail]>]

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.

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

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

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


Cheers,
Ari