[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT Traversal
pcn@cisco.com ("Chinna N.R. Pellacuru") writes:
> 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.
And unless you control both ends L2TP implementations, they might have UDP
checksumming on.. *oops*
And so he quoteth the RFC 2661:
,----
| The default for any L2TP implementation is that UDP checksums MUST be
| enabled for both control and data messages. An L2TP implementation
| MAY provide an option to disable UDP checksums for data messages. It
| is recommended that UDP checksums always be enabled on control
| packets.
`----
> 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, in case you want to do something else than VPN; if you limit your
designs to VPN cases only, they CAN be used only for VPN cases (and I know
for a fact that IPsec is being used in very strange applications these
days, although I can't speak of them).
> 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.
Yes, right, learn to read RFC before whining. L2TP, for example, is out there.
> > 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...
"Mommy, she started it!"
> 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.
Whole point of SPI's is that they're values that are convenient for the
receiver to handle. Thus, having them mandated by either remote SPI
selection, or some mystical 'NAT compatibility hash function' sounds
not-so-convenient to me.
What do you do in case of collisions? Not let traffic through? One big
server can have say, 10k SAs up at any time, so chance of collision _does_
exist there, and solution that works on best-effort basis isn't very good
one.
Also, finally, I haven't heard of this being documented practice and until
it is, it's unfortunately something that _might_ work for you but not
others. Same could be said also of some other NAT-T approaches we've
played with, but I believe mr. Dixon will talk about them in the next
IETF. Where's your draft on this SPI magic?
If we resort to 'my proprietary solution is better than yours', I don't
think we should be on IETF mailing list, but instead playing on the sandbox
and contesting who has the best toy.. We can do this by email if you wish.
> > > 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!
I'd like to see a big NAT box that has VPN-passthrough for N users to M
servers, where it doesn't expire mappings at all (because obviously
otherwise it breaks connectivity if the user say, goes for lunch in the
middle).
You _should_ know how big NATs some ISPs have already rolled out.
Infinite memory, anyone?
> -Most of all, massive hand waving about "built-in host NAT implementation
> within the IPsec stack" is the most prettiest of all
It isn't mandatory; however, it makes possible what the simple 'passthru'
fails in.
> 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.
At least something I can agree with..
> chinna narasimha reddy pellacuru
> s/w engineer
-Markus
--
Markus Stenberg <stenberg@ssh.com> of SSH Communications Security (www.ssh.com)