Re: [Hipsec] HIP Native NAT Traversal

[Miika Komu <[e-mail]>]

On 13/04/10 06:21, frogsir wrote:

Hi,

> On Tue, Apr 13, 2010 at 2:05 AM, Dan Wing <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>      > -----Original Message-----
>      > From: [e-mail] <mailto:[e-mail]>
>      > [mailto:[e-mail] <mailto:[e-mail]>]
>     On Behalf Of Ari Keranen
>      > Sent: Monday, April 12, 2010 2:33 AM
>      > To: [e-mail] <mailto:[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.*

to be more precise, it was just an internal implementation trick to get 
incoming STUN messages from the packet capture module to hipd. So it 
really did not solve the problem because it still required HIP/ESP/STUN 
demuxing somewhere in the system.

Having STUN messages in HIP encapsulated format *on-the-wire* would 
solve the demux problem, but the extra parser and marshaling library 
would still be necessary for STUN which would further increase the 
footprint of hipd.