Re: [Hipsec] HIP Native NAT Traversal

> -----Original Message-----
> From: frogsir [mailto:frogsir@gmail.com] 
> Sent: Monday, April 12, 2010 8:22 PM
> To: Dan Wing
> Cc: Ari Keranen; hipsec@ietf.org
> Subject: Re: [Hipsec] HIP Native NAT Traversal
> 
> 
> 
> On Tue, Apr 13, 2010 at 2:05 AM, Dan Wing <dwing@cisco.com> wrote:
> 
> 
> 
> 
> 	> -----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.
> 	
> 
> 
> 
> 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

> 	> > 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
> 	
> 	_______________________________________________
> 	Hipsec mailing list
> 	Hipsec@ietf.org
> 	https://www.ietf.org/mailman/listinfo/hipsec
> 	
> 
> 
> 
> 
> -- 
> 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: santtu.liu@frosmo.com
> MSN: frogsir@hotmail.com
> 
> 