Re: NAT Traversal

[Markus Stenberg <mstenber@ssh.com>]

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.

Or, in tunnel mode, actually (*gasp*) more than one client behind large NAT
accessing (*gasp*) SAME security gateway!

High probability of success my .. foot.

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

It's far from pretty. 

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 囲碁先生