RE: NAT Traversal

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On Sat, 2 Mar 2002, Henrik Levkowetz wrote:

> On Thursday, February 28, 2002 Chinna wrote:
> ...<snip>...
> >
> > I would also like to extend the request to everyone (the veterans who can
> > help us technically and also guide us through the IETF process, and
> > frankly THE MORE THE MERRIER).  Please join us if you want to help us. If
> > you are skeptical of us due to the flame exchange, honestly, that's not
> > our true nature. Please send me an email.
> >
>
> Well, I'm taking you up on this; then we'll see if I end up hit
> by a barrage of pies, eggs, tomatoes and whatnot from every direction...

Thankyou very much for supporting our proposal and joining us.

>
> I've followed the discussions with respect to NAT traversal on the ipsec
> mailing list during the last half year or so, while I've been working on
> the current draft on NAT traversal for Mobile IP, and also implementing
> NAT traversal for Mobile IP.
>
> It seems to me, viewing this discussion somewhat from the outside, that
> in the matter of NAT traversal for IPsec you have as a group become the
> victims of your own success. Let me explain what I mean; it is leading
> somewhere:
>
> One goal in IPsec work would naturally be to have the protocols concerned
> be as opaque and resistant as possible to both traffic and content analysis.
>
> One goal for NATs is to leverage extra information (in the form of port
> addresses preferably) in order to make up for a scarcity of ip-addresses.
>
> So the more you succeed in making the communication opaque, the less there
> is for NATs to work with. The (in this respect) straightforward solution to
> accomplish NAT traversal is then to give NATs their favourite stuff to work
> with: Port numbers. All ALGs (Application Layer Gateways) which are
> added to NATs are there to take care of the protocols which do NOT give
> the NATs port numbers to work with. They sometimes work, and sometimes
> work well.
>
> The solution subdivides into (at least) two parts: Discovering if you are
> behind a NAT, and doing something about it if you are.
>
> Chinna had a reference to an excellent draft which answers the first part
> in a generic way:
>   http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt
>
> The answer to the second part will have to consider the particular
> requirements of the protocols which you want to get trough a NAT, but
> if you would accept input from someone who's not of the IPsec community,
> I'd be willing to pitch in. I don't believe the problem is too intractable.
>

For our solution we do not require to even discover NAT. The SPIs can be
generated as a pair in all cases because this is such a simple operation.
If there are any NATs enroute, they will use this property to de-multiplex
the IPsec traffic and do IPsec pass-through.

If doing encapsulation, you MUST do NAT discovery becuase the price they
pay for encapsulation is high, 16 bytes of overhead (okay not 24 as I said
in my previous mail). So, you want to do encapsulation and send keepalives
every 9 seconds, only when you are absolutely sure that it is needed.

    Thanks again for your support,
    chinna