Re: NAT Traversal

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

On 27 Feb 2002, Markus Stenberg wrote:

> 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.
> `----

If you look a telnet packet which is going through L2TP, it looks like:

IP ESP [UDP L2TP PPP IP TCP DATA]*
where * denotes encrypted and DATA is generally one byte.

The inner most IP and TCP header are not touched by anything regardless of
what scheme you use, or don't use. That is what I am referring to above.

Now a UDP encapsulation of the above packet would look like:

IP UDP IKE-NAT ESP [UDP L2TP PPP IP TCP DATA]*

Wondering if IESG or someone else has a limit on the number of
encapsulations that are allowed.

Coming to the UDP checksum in the L2TP UDP encapsulation header the
current drafts say:

Depending on local policy, one of the following MUST be done:
a) If the protocol header after the ESP header is a TCP/UDP
   header, zero the checksum field in the TCP/UDP header.
b) If the protocol header after the ESP header is a TCP/UDP
   header, recompute the checksum field in the TCP/UDP header.
c) If the protocol header after the ESP header is a TCP/UDP
   header and the peer's real source IP address has been received
   according to [Kiv00], incrementally recompute the TCP/UDP checksum:
   - subtract the IP source address in the received packet
     from the checksum
   - add the real IP source address received via IKE to the checksum

- What "local policy" is being reffered to here? How do you not have to
"control both ends of the L2TP implementation" in this case? In general
someone always controls both ends of an L2TP deployment. Sane people don't
randomly pick an L2TP LNS and try to talk to it, just for the heck of it.
You would want to talk to your own L2TP LNS.

- If it is OK here to just "recompute the checksum field" why not do it
for all ESP decapsulation. We will hack up the checksum in general that we
won't have any checksum issues at all. I don't see why checksum is such a
big design criteria. It is optional for most protocols, and more and more
it is loosing it's popularity. For example IPv6 doesn't have a checksum
field. Obviously if people are just hacking up checksums by recomputing
them before passing on to the upper layers, it is seen more as a pain than
a benefit.

- There is NOTHING special about your solution in dealing with checksums.

>
> > 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).
>

Please save us from that crap about special needs that no one knows about.
I am sure the rest of us don't have time to go through it.


> > 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.
>

Looks like you have read a lot of RFCs. That's good. Also try to
understand basic practical deployments of those protocols that you read
about. That will help you from not coming up with weird schemes for
imaginary special cases.

> > > 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 can understand your frustration. Sorry to be the one to spoil your party
here. Massive hand waving will only get you so far. It's really amazing
that you made it upto "last call". Next time try to come up with something
that will work.

Get used to it, and try not to take it personally. You will grow up
someday, but until then ask your mom or some other adult to proof read
your mails before posting it to a large audience like this working group.

> > 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.
>

OK, it's the prettyness and other vague arguments again:

- IKE is a key management protocol. "NAT discovery" doesn't belong in a
key management protocol. Go get your own protocol to do weird things like
"NAT discovery". We have enough people pulling their hair off, looking at
the complexity of IKE. We are trying to simplify it in Son-of-IKE, but
looks like some people just don't get it. How does Son-of-IKE do "NAT
discovery"?! Why should "NAT discovery" be a requirement for a key
management protocol? Yeah, IKE will soon solve all our problems, and we
can go home happy and start thinking about the grandson-of-IKE. How
convenient!

- Cookies are used to identify IKE SAs. Just because you have a bizzare
scheme and set the IKE cookies to zero, it doesn't mean that the rest of
the world that existed and thrived on the original assumption, should just
vanish. What a way to propose a solution! How convenient!

- Port 500 is for IKE, not for UDP encapsulated ESP traffic. The rest of
the world assumed that, and now that you are coming in later and breaking
that assumption, you should deal it somehow, and not expect the rest of
the world to just vanish. How convenient!

What design principles is your solution based on? Why is not changing a
NAT device the "most important" design principle? NAT changes every day to
accomidate new protocols. It's not the case that NAT devices don't change
at all, and all new protocols have to do UDP encapsulation to get through
NAT! We will not change NAT but screw up most of IKE and IPsec!

> 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.

Tell me about it. How does your "NAT keepalives" make absolutely sure that
the NAT translations are kept alive? Are you sending a keepalive every
microsecond to be absolutely sure that no NAT translation expires? What if
some NAT box is using a sub microsecond timeout to blow away it's UDP
translations. There are practical and acceptable limits for everything.
You can very rarely design for the absoute, if at all.

In your case if a NAT translation expires for some reason beyond your
control (for example a NAT implementation decides to prune it's
translations randomly because there are too many translations), then you
are completely hosed!

------------------------------------------------------------------
Important note: But if NAT is translating on SPI matching, it can always
setup the translations again just by matching the SPIs.
------------------------------------------------------------------

We all know what happens to chatty protocols that MUST send a lot of
traffic to work. They just die. Ever wonder why most IT administratos want
to get rid of Apple Talk.

>
> 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.

Good point. We'll write up an ID and submit it. You can discuss possible
solutions until there is some critical mass. You don't have to absoultely
start with an ID to even start discussing some ideas.

As usual Cisco has a patent application on this technique, and I am 100%
sure that Cisco will give it to IETF if this is accepted as a standard,
as Cisco has done with so many other things in the IETF.

>
> > > > 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?
>

As I pointed out before, this is more a FATAL deficiency of your scheme
then ours. This is because your scheme ridiculously assumes that you can
somehow maintain a NAT translation for as long as you want!

I think it's prudent to let NAT do it's job, so that it knows what it is
doing.  This is more natural, and this is how NAT deals with all protocols
under the sun. But as usual, IPsec want's to act special. We are special,
we are immortal, we are a "security protocol"!

Ever wonder why customers are buying those "IPsec pass-through" boxes like
crazy? Because they work and it is simple and elegant and because of it's
simplicity they are cheap.

I hope that in the best interest of the customers a good working solution
gets standardized, not something that is bizzare and does NOT work.

> > -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.

Please stop this hand waving atleast until someone gets back to me on the
details of how this will work. I am yet to receive a clarification on the
scenario I described in my other mail. For now let's just say that no
solution can handle this scenario, and it is not a requirement to move
forward.

Expect to see our ID soon, and you can try and poke holes in our approach.
It's nothing special. It's just the IPsec pass-through with the added SPI
matching to give NAT more intelligence about IPsec.

    chinna

>
> > 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)
>

chinna narasimha reddy pellacuru
s/w engineer