Re: [Hipsec] HIP Native NAT Traversal

> -----Original Message-----
> From: hipsec-bounces@ietf.org 
> [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen
> Sent: Monday, April 12, 2010 2:33 AM
> To: hipsec@ietf.org
> 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.

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

-d

> 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
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec