Re: [Hipsec] HIP Native NAT Traversal

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Ari Keranen [mailto:[e-mail]] 
> Sent: Tuesday, April 13, 2010 12:10 AM
> To: Dan Wing
> Cc: [e-mail]
> Subject: Re: [Hipsec] HIP Native NAT Traversal
> 
> 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.

Ok.

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

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

Ok, thanks.

-d