Re: NAT Traversal

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

On 26 Feb 2002, Markus Stenberg wrote:

> pcn@cisco.com ("Chinna N.R. Pellacuru") writes:
> > On 25 Feb 2002, Derek Atkins wrote:
> > > "Jayant Shukla" <jshukla@trlokom.com> writes:
> > > >
> > > > What makes you think the client is involved? IPsec pass-thru implemented
> > > > in most low end NAT boxes is not complete RSIP as that would require
> > > > modifications to client and the gateway.
> > >
> > > See what I said before about demon-spawn!!!  NAT traversal via IPsec
> > > pass-thru[sic] is just plain wrong, broken, and lots of other words
> > > that I don't want to use in mixed company.
> > NAT translates all protocols in a transparent manner using some protocol
> > parameters, Eg. ports in case of UDP and TCP. I don't see why we should
> > not try and apply a similar model to IPsec, using cookies and SPIs.
> >
> > Sure the SPIs are encrypted during IKE negotiation and the NAT box cannot
> > see which SPIs are a pair. But if we somehow relate one SPI to another in
> > each pair, the NAT box can translate ESP traffic with a high probability
> > of success.
>
> Indeed? I'd like to know how my ESP transport mode's TCP checksum is fixed
> by the NAT box.
>
> Note: IPsec is other things than VPNs, too.

Transport mode in general is used when IPsec is being used to protect
already tunneled traffic like L2TP or GRE. So, in these cases the TCP
checksum is not an issue because the original IP datagram tunneled by
other tunnelling protocols will have the right checksum. Generally these
original addresses of the original IP datagram will be private addresses
that we don't want to translate in a VPN.

In what "other" cases are you saying we need to do IPsec transport mode
through NAT? Someone gets a private address, and does plain IPsec
transport mode through NAT! to whom? and why?

Well sounds familiar: we don't know how it will be used, or who needs it,
but it has to be there, and we will bend over backwards to accomplish it.

>
> Or, in tunnel mode, actually (*gasp*) more than one client behind large NAT
> accessing (*gasp*) SAME security gateway!
>
> High probability of success my .. foot.

I prefer a civilized debate, but if you insist...

I said, "if we somehow relate the SPIs in a pair", the NAT box can take
advantage of that to demultiplex. It's a very simple idea: make one spi
(or part of it) a hash of the other so that the NAT box can relate a pair
of SPIs. We have this working in our products.

>
> > Well, it's not pretty, but that is the inherent nature of NAT itself.
>
> It's far from pretty.
>

-Adding an encapsulation overhead of > 20 bytes is very pretty! we have
people already screaming about the overhead that ESP adds!

-Modifing IKE to do "NAT discovery" is very pretty! IKE isn't doing much
yet, so lets add more.

-Using adhoc keepalives schemes to maintain the unpredictable NAT
translations is very very pretty!

-Most of all, massive hand waving about "built-in host NAT implementation
within the IPsec stack" is the most prettiest of all

Probably NAT and pretty cannot be in the same sentence for most of us
anyway. So, let's not focus on the "pretty" factor of the solutions.

    chinna

> It seems that using some obscure port, or having disclaimer about 'This is
> copyright protected material, if you try to reverse-engineer this ROT-0
> encrypted packet you will be sued to hell' are the only two ways to deal
> with it.
>
> I'm starting to agree with Derek about what should be done with NATs..
>
> >     chinna
>
> -Markus
>
> --
> Markus Stenberg <stenberg@ssh.com> of SSH Communications Security (www.ssh.com)
> SSH 囲碁先生
>

chinna narasimha reddy pellacuru
s/w engineer