Date: Sat, 22 Apr 2000 05:48:36 -0400
From: "J. Noel Chiappa" <jnc(_at_)ginger(_dot_)lcs(_dot_)mit(_dot_)edu>
> there are far too many problems to NAT, affecting far too many
> applications ... and the list is constantly growing larger.
Perhaps if there was a document that explained how to design an application
so that it worked through a NAT box, the list might not be growing so
quickly?
Although I wouldn't want to be the person to write such a document, since
they're going to have to wade through hordes of flak from people who seem to
convinced that if they just flame enough about how worthless NAT boxes are,
and how they ought to be banned/exterminated, NAT boxes will go
away. ("Back, tides!")
The list can also be useful in terms of really documenting for the first
time, in one places, all of the ways that application writer's hands are
tied if they want to be survive running through a NAT.
If all you want to do is a single TCP connection, it's not so bad. But
the moment you want to do any kind of back-connection, or to be able to
associate multiple connections in either direction, life gets hard.
What's the answer? Tell the application programmer, "Well, don't do
that!"? Tell them to do IP-IP tunnelling? Tell them to invent their
own streaming layer on top of TCP, ala ssh?
And if you want to design a new UDP protocol, what can you depend upon
for a NAT box to do? Will it pass unrecognized UDP protocols at all?
How will it handle port translations? Will it keep state?
For a classic example, look at the recommendations of the IAB Workshop last
year about IPSEC (and I'll asssume for the moment that IPSec is important to
securing the Internet, and stay away from the debates about IPSEC
versus SSL, etc):
It is urgent that we implement and deploy IPsec using some other
identifier than 32-bit IP addresses ... The current IPsec specifications
support the use of several different Identity types (e.g. Domain Name,
User(_at_)Domain Name). ... We strongly urge the IETF to completely
deprecate the use of the binary 32-bit IP addresses within IPsec
... in particular any IP address dependencies should be eliminated from
ISAKMP and IKE. Ubiquitous deployment of the Secure DNS Extensions ([8])
should be strongly encouraged to facilitate widespread deployment
of IPsec (including IKE) without address-based Identity types.
Well, where's Secure DNS deplyoment? :-)
More seriously, Secure DNS by itself isn't enough. We also need to
mandate that NAT boxes provide certain types of infrastructure in terms
of dynamic updating of DNS servers, *and* a split-DNS configuration that
gives correct inside/outside responses. Part of the problem with
relying on DNS names instead is that this assumes that DNS/NAT games are
(a) set up consistently, or (b) set up at all. Some ISP's or Company
setups may do NAT's, but not provide any kind of consistent DNS
addresses, either forwards or backwards resolution. Also, from an
implementation point of view, there isn't even a good way for you to
obtain a globally usable FQDN on most OS's.
The real issue is that NAT's are still considered a hack. And hacks
don't necessarily have the full set of support infrastructure behind
them so they can be used reliably. So while it's granted that there
hasn't been anyone on the IPSEC wg with interest in this area, it's also
fair to say that even if they were interested, they'd immediately run
across another problem of it's not clear what kind of support
infrastructure you can rely upon. (And if the support infrastructure
doesn't exist in the real world, spending man-years writing a spec that
presumes the existince of such a support infrastructure is just as
Cannutish as saying "Back, Tides!")
Maybe what is needed is a new IRTF working group --- the Anti-End2End
group. It's charter will be "the end to end principle is dead", and
they can try to figure out everything that will be needed to turn the IP
address into a 32-bit local routing entity. After all, this is a
fundamental architectural principal that we will be overturning, and it
will probably have impacts all over the stack. And after they come up
with the plan of everything that will have to change, people can look at
it, and say, "Oh, ugh, maybe that wasn't such a hot idea after all", or
"Gee, I guess while it's horrible, it's easier than trying to get IPV6
deployed."
Right now, NAT and other attacks on the end-to-end model are being done
as a series of hill-climbing optimizations, with no real attempt to see
if they can solve the entire problem or not. (After all, they're just
hacks, right? And everyone knows there's nothing more to the Internet
than http and e-mail anyway....)
IMHO the problem is that we're stuck halfway. Either NAT's are a
fundamental part of the architecture, and we have to try to figure out
*everything* that has to change in order to accomodate them as
first-class objects, or they are hacks and kludges which should go away,
and we should be working towards that goal. Right now, we're just
completely schizophrenic on the issue, and that's not helpful.
The question is, how to decide the issue. Super-soakers at 24 paces,
perhaps? :-)
- Ted
P.S. An interesting observation with NAT is that it's really the
newcomers to the internet, both in terms of protocols and users, that
suffer the most. Old users are grandfathered because they can get have
the class B's addresses in the swamp, and don't need to use NAT. Old
protocols (with the exception of those that do encryption), can depend
on the NAT boxes doing some truely awful stuff (like rewriting FTP's
command channel, and all of the TCP checksum games that have to take
place) to make their protocols work. It's really the newer users,
especially those that are using cable modems and ADSL users, and the
people who want to write newer protocols, that end up getting contrained
by NAT.
Speaking personally, I knew about these issues, so when I got my home
DSL connection, I insisted on getting a /27 from my provider, and
fortunately I (or more precisely my company) was willing to pay the
money to get a real address block, so I didn't have to deal with NAT. I
decided I didn't want to have to waste time with trying to make NAT
work, and it was simply cheaper to get real addresses. I had more
important things to do.
Other folks who are saavy enough can usually find contacts at places
with free address space, and so they're playing tunneling games so they
can get chunks of un-NAT-ed address space, even if their local provider
refuses to give it to them. A number of these people are IETF'ers. :-)
So not only do we have the usual IETF problem of too many problems and
too few people with clue, it's probably less effort for those who *can*
fix the problem (and I include either IPV6 or fixing NAT in this
category) to evade the problem completely, one way or another --- at
least at a personal level.