Re: NAT Traversal

["Chinna N.R. Pellacuru" <[e-mail]>]

First, I would like to request that the visionaries of "IPsec
Pass-through" (who were probably banished to the underground in this and
other forums), to join us, and help us refine our approach more and come
up with a more solid proposal.

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.

On 28 Feb 2002, Markus Stenberg wrote:

> [e-mail] ("Chinna N.R. Pellacuru") writes:
> <snip>


I assume that there is not much disagreement on the snipped portions, and
hence snipped.


> > > 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!
>
> Setting SPIs by some magic formula sounds of NAT-oriented kludge to me as
> well.
>

Yes, we propose a NAT oriented solution. NAT mucks with all protocols that
were finalized before it came into existance, and all newer protocols are
designed to work with NAT. I think it is not very prudent to try and sneak
through NAT, and when you get burnt, give up.

We would like to call our solution: ESP Aware NAT (eNAT). Our goal is to
make NAT as intelligent as possible about IKE and more importantly ESP, so
that NAT doesn't step all over these protocols.

> <snip>
>
> > 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!
>
> Unfortunately you are NOT usually able to choose which type of NAT you are
> behind. Some of the hotels, ISPs et al whose "Internet Access" I've tried
> to use have had awful kludge NATs that basically do simple TCP/UDP NAPT
> without any support for other protocols or application level handling.

What do these ISPs and hotels advertise? Fast movie downloads at greater
than 2Mbps speeds? If any ISP or hotel is serious about their business, it
is in their best interest to have the right equipment. I personally would
stay away from any entity whose *only* focus is fast movie downloads and
doesn't want to listen to legitimate requirements.

Or is the assumption that the rest of the world is so dumb. If people were
so dumb, they would also put a firewall which only allows TCP port 80. Why
don't you use TCP port 80 then.

I think that's the feedback we are getting from some of the UDP
encapsulation deployments. Use TCP, it works better. Use TCP but don't do
retransmissions. Does it sound familiar? TCP translations aren't pruned as
aggressively as UDP translations. So, use TCP. Probably you should make
the encapsulation scheme generic enough to negotiate what protocol and
what port will be used. So, if someone blocks even TCP port 80, then you
can do a port scan and pick the port and protocol that is being allowed.
We can negotiate this in IKE. Seriously, first IKE can do a port scan, and
negotiate the ports and protocols that are being allowed. That way we can
get through the dumbest of the dumb boxes out there. We can tell all
firewall administrators that doing a port scan is legit, and we are
actually a "security protocol" and we have genuine reasons to do it.

>
> If 'change all network devices' was applicable solution, I'd say we'd be
> running IPv6 and not worrying about the legacy issues (such as NAT) at all.

I think that is probably another myth. IPv6 will get rid of NAT. NAT is
being used for other reasons than just getting over the IPv4 address
shortage problem. For example NAT can be used for using a different
address space without having to re-number your whole network overnight.
And there are those people who live and die by their NAT boxes, because
they beleive NAT provides "security by obscurity" also they would have a
lot of flexibilty in addressing if they use NATs.

Have you heard of NAT-PT, NAT Protocol Translation in IPv6? I think it is
too simplistic to assume that NAT will die as soon as IPv6 hits the field,
or in the near future.

NAT already translates scores of protocols by knowing intimate details of
each of the protocols, and there are still dozens on the to-do list to be
translated. If upgrading NAT is such a no-no, why are dozens of protocols
still waiting on the queue to be translated.

>
> Why isn't RSIP out there everywhere if that is a valid assumption?
>

Probably because RSIP is a very generic solution, that is trying to be a
one size fits all. It fits everybody somewhat, but no one perfectly?! I am
not an expert on RSIP, but I think assuming that RSIP wasn't deployed
solely because people were not willing to upgrade their equipment is being
foolish.

> > > 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.
> > ------------------------------------------------------------------
>
> What if traffic is (mostly) unidirectional? I believe this match-SPI logic
> works on assumption that you have traffic going out semi-constantly.
>
> Is that valid assumption?
>
> In case of some UDP-based streaming applications, for example, I have
> encountered up to minute of unidirectional traffic. If your NAT happens to
> reset mappings in 30 seconds (which seems to be industry minimum, barring
> running out of memory), your stream is screwed half the time.

Translations are reset even if there is continuous traffic in one
direction?! NAT translations are prime candidates for pruning when there
is NO TRAFFIC, NOT when there is unidirectional traffic all the time. What
NAT implementations are you basing your design on. Now is the assumption
that even the NAT implementations are also dumb, or are you playing around
with undergrad student's projects.

NAT resetting the translation is NOT a problem in our solution. That is
what the note above is saying. This is because we made NAT intelligent
enough about ESP that it can reset and re-establish the translation as
many times as it wants.

>
> <snip>
> > 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.
>
> Obviously. But comparison is unfair if one solution is totally specified
> and other one is mostly handwaving (I've seen maybe one or two paragraphs
> about it here). And I believe comparison is what you're very bent on.
>

Let me know what other details you want. I can give you all the details
you want in the mean time.

But, the fact of the matter is that the whole solution can be described
fully in a couple of paragraphs. If you are expecting us to come up with 3
drafts like your solution, then each draft will have only one sentence
each.

The solution is the "IPsec pass-through" with "SPI matching". The "SPI
matching" is done by making one SPI (or part of it) a hash of the other.
Now which part of this solution is not clear to you.

Most of the details are pretty obvious to anyone who has implemented NAT.
There is a NAT translation table, and you should keep the parameters of
the protocol that is being translated (SPIs and cookies in our case), in
the translation table, and translate the protocol by knowing how the
protocol works.

If you agree that "IPsec pass-through" generally works, "SPI matching"
will only make it more scalable, and predictable.

> <snip>
> > 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"!
>
> You believe we can actually keep all NATs up to date constantly? By that
> argument, we could get instant upgrade to IPv6 as well as long as IPv4
> worked side-by-side. I don't believe in that.

Frankly, I am amazed to hear something like this from someone working for
a company based in the EU. Ironically, even though I work for a company
based in the US, I beleive that people will upgrade to IPv6 as the demand,
and pressure builds up. At some point it becomes easy to just upgrade to
IPv6, instead of cobbling up your IPv4 network. It depends on which is the
less painful. No serious entity runs IPv4 or IPv6 just for the heck of it.
All upgrade decisions depend on the pain factor of the various options
available.

>
> > 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.
>
> The pass-thru works for end-user but not for ISP. In case of single user,
> you don't need to maintain state and state resets don't hurt (you can have
> dedicated memory easily enough for few IKE/IPsec SAs).

How many times do I have to repeat that, our solution allows NAT to reset
and re-establish an ESP translation as many times as it wants.

In the interest of everyone, please stop your impulsive responses, and
take some timeout to understand our position.

>
> > 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.
>
> Likewise.
>
> > > > -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.
>
> Read draft-stenberg-ipsec-nat-traversal-02.txt (it's long expired but it's
> still available on the 'net and it details some design things better than
> current drafts). Section 3.4 details built-in NAT functionality.

"built-in NAT functionality"! Yes, I read that thing a long time ago, and
still didn't recover from the shock. A whole NAT implementation within the
IPsec implementation! I can't beleive that this is even being proposed as
a solution. Please see my other mail on this topic.

>
> > 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.
>
> Looking forward to it.
>

I am waiting for some help (one and all, please just send me a note if you
are interested). We can have it out soon, because the underlying design is
pretty simple.

    chinna


> >     chinna
>
> -Markus
>
> --
> Markus Stenberg <[e-mail]> of SSH Communications Security (www.ssh.com)
>

chinna narasimha reddy pellacuru
s/w engineer