Re: [Hipsec] HIP Native NAT Traversal

[frogsir <[e-mail]>]

On Tue, Apr 13, 2010 at 2:05 AM, Dan Wing <[e-mail]> 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.
>


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

>
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hipsec
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> 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: [phone]
fax: [phone]
Email: [e-mail]
MSN: [e-mail]