Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: "J. Noel Chiappa" <[email-masked]>
Date: Sat, 22 Apr 2000 05:48:36 -0400

> From: Keith Moore <[email-masked]>

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

We could also contemplate the possibility of producing fixes for old things
that NAT boxes break, but on the record so far, I'm not very sanguine.

(The enquiring mind wonders why this isn't happening - but doesn't have to
look too far. In addition to the usual IETF problem of too many problems and
too few people, there's the other camel in the tent, to whit - whose ox will
be gored if we make NAT boxes work better? And who will be the big losers if
we don't make NAT work better - why, the users, of course. But who cares
about them?)

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

So, has any of this happened? AFAIK, no; I may be wrong, but I don't recall
seeing anything about either deprecating use of address-based identities, or a
fix to IKE/etc to remove all address dependencies.  Sure, everyone's busy, but
has anyone in the IAB/IESG/etc been tasked with making this happen?

The really ironic thing about this particular case is that people who want to
deploy IPv6 would probably benefit from this particular fix, too. Right now,
as far as I can tell (sorry, it's been a while since I looked at this, and the
details made my eyes glaze over), a number of the different IPv4<->IPv6
interoperability tools don't work with IPSec, both because of the use of
address-based identities, and address dependencies in IKE. Removing these
dependencies might allow IPSec to work in IPv4<->IPv6 interactions.

But has anything happened here? Nope. Can't do anything to make NAT boxes
work better, can we?

Even more radically, we could start requiring that new stuff works through
NAT boxes. What a concept!

While to an objective observer that might seem like a fairly reasonable step,
given how widely NAT boxes are deployed, G-d forbid we do anything so
rational. I mean, who cares if we screw over the users, that's their own
fault for not realizing how tasteless NAT is.

Damn the users, full steam ahead!

	Noel

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 22 Apr 2000 21:06:04 +0859 ()

Noel;

> and how they ought to be banned/exterminated, NAT boxes will go away. ("Back,

You might have thought that NAT had made the Internet a collection of
private IP networks, which were acceptable.

However, the real problem of NAT is not of NAT itself but of NAT based
applicatins which are so network layer independent that they work over
non-IP networks.

NAT and NAT friendly application/transport protocols makes the Internet
a collection of private non-IP networks.

NAT is killing not only the Internet but also the IP protocol and a
standardization body for it.

For example, NAT friendly application/transport protocols for IP
telephony are H.323 and SIP.

Because SIP is so complex (even worse than H.323) and has no difficulty
to accomodate non-IP environment, SIP has lost the battle against H.323.

For telephony, the real battle should be fought between Internet
telephony and IP telephony over NAT with H.323 (Internet telephony
without NAT and IP telephony with NAT are opposite concepts).

The next thing to see is, what will happen between WAP and HTTP?

							Masataka Ohta

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 22 Apr 2000 11:10:31 -0400

Date: Sat, 22 Apr 2000 05:48:36 -0400
   From: "J. Noel Chiappa" <[email-masked]>

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Apr 2000 17:48:15 -0400

>    so that it worked through a NAT box, the list might not be growing so

here's a stab at one:

if you want your application to work with NATs:
(in light of both NATs and other typical conditions)

	- either make it two-party only (e.g. strict client/server). 
	  or have a central party that contacts all of the other
	  parties and looks up those addresses using their DNS names.
	  you cannot expect to set up arbitrary communications paths. 
	- don't make any assumption at all about the meanings of,
	  stability of, or uniqueness of, the IP address of the 
          communicating parties 
	- use TCP only, with short-lived connections 
	  (say, no more than a few minutes, or no more than the TTL
	   of the A record returned from the DNS lookup)
	- instruct your customers that all servers (i.e. all parties that 
          accept connections rather than initiate them) which need to
	  communicate with clients on the other side of a NAT, must be
	  located in public address space.
	- use DNS names, rather than IP addresses, to identify your endpoints
	  for the purpse of reaching them across the net 
	- all DNS names used in this way need to be evaluated from the same
	  point.
	- if you need to log events, assign each party a unique name for 
	  logging purposes.  don't rely on either the IP address or the
	  DNS name.
	- authenticate using TLS and client certs rather than IPsec.
	- bind your servers to well-known ports rather than 
	  having them dynamically assigned 
	- do a DNS lookup of your destination immediately before
	  setting up each TCP connection.
	- don't rely on an DNS inverse address (PTR) lookup to give you the 
	  name of a process/service for the purpose of reaching it later
	- don't rely on a process's idea of its own DNS name for the purpose
	  of reaching it later - many hosts don't know their own names.
	- if your application needs to access multiple services on the 
	  same host (e.g. NFS mount and NFS access), multiplex all 
	  of those service requests on the same port.   don't assume
	  that port A on host address X and port B on host address X 
	  actually reach the same host.  
        - similarly, don't do protocol feature negotiation using port 
          numbers, and don't do protocol version negotiation using port 
          numbers.  design your protocol so that it can negotiate
          version and/or features in-band.  this includes use of tls/ssl
	  if this is optional.

if you find that you cannot make your application work under these conditions:

	- attempt to detect the presence of NATs so that you can display
	  a reasonable error message.  e.g.

	  you have a NAT installed between A and B and this application
	  fundamentally cannot work over a NAT.

	  or

	  you have a NAT installed between A and B.  this application 
	  cannot work over a NAT without the explicit support in the
	  NAT for this application.  contact your NAT vendor to determine
	  whether your NAT can be modified to support this application.
	
> tied if they want to be survive running through a NAT.  

http://www.cs.utk.edu/~moore/what-nats-break.html
is an approximation of the latter kind of list.

> gives correct inside/outside responses.  

this might help in some ways, but it's not at all clear that it would
be a good idea overall.  Just because some NATs mung DNS records in
an attempt to fit in better doesn't mean that going further down this
path is architecturally sound.

> them so they can be used reliably.  

some things are inherently hacks.  it isn't clear that you can make
network address translation work reliably even if you add more stuff 
to those boxes. 

> address into a 32-bit local routing entity.  

seems like the NAT group is already a close approximation to that.
and somehow I doubt that such a group would attract enough people who
really understand the needs of applications, and the tradeoffs,
to produce a decent solution.

if we're going to compare various ways of attacking the NAT problem,
we first need to get some shared understanding of what kinds of service
the brave new network would need to provide.  otherwise, we have no
basis with which to compare the various solutions.

> completely schizophrenic on the issue, and that's not helpful.

yes.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Tue, 25 Apr 2000 10:41:08 -0400

> So, has any of this happened?

If I had a dollar for every time someone suggested just fixing
IPsec...

"Fixing" IPsec really also means fixing TCP/UDP, since they have
checksums that cover the IP addresses in use. Sure, if IPsec is in use
its MACs are stronger than the TCP/IP checksum, but one still has to
fix TCP/UDP to be IPsec aware so that they don't step on each other's
toes and do the wrong thing.

Bernard Aboba's recent posting to ipsra provides some excellent
details on some of the issues.

From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Date: Sat, 15 Apr 2000 15:56:35 -0700
Subject: NAT and IPSEC issues
Reply-To: <[email-masked]>
Importance: Normal

While we're on the subject of NAT and IPSRA issues, it might
make sense to articulate what the issues are exactly. 
Here's my understanding:

a) IPSEC AH will not go through the NAT, because the AH header
   incorporates the IP source and destination fields in the 
   authentication hash. 

b) IPSEC ESP does not incorporate the IP source and destination
   fields in its authentication hash. However, there is an
   implicit dependency on source and dest. addresses within
   TCP and UDP checksums which cover the "pseudo-header." 
   Therefore ISPEC ESP will only go through the NAT if 
   TCP/UDP protocols are not involved (as in IPSEC tunnel
   mode or IPSEC/GRE), UDP/TCP checksums are turned off, or
   if UDP/TCP checksums are ignored by the receiving party. 

c) IKE will only go through the NAT if the parties do not
   check or use IP addresses in IKE MM identifiers (several 
   current implementations don't do this) AND if in addition 
   they don't check or use IP addresses in IKE QM identifiers 
   (most implementations DO use addresses and check them). 

d) Because of IKE rekeying behavior, it is necessary for 
   implementations to float their IKE source port in order
   to enable NATs to de-multiplex incoming rekeys which may
   not use the same cookies as the earlier traffic. 

e) In order to enable an IPSEC implementation to send traffic
   down the correct IPSEC SA, it is necessary for those SAs
   to be differentiated in some way. In practice this implies
   negotiation of non-overlapping filters.

Some conclusions resulting from the above:

1) Because many IPSEC tunnel mode implementations negotiate
   filters of "ANY to ANY" it is possible for their IKE traffic 
   to pass through NATs. However, the issue of overlapping filters
   means that there can only be a single IPSEC tunnel up from
   behind the NAT box to the security gateway. If there were two
   tunnels up, each with the same filters, the security gateway
   could be confused and send traffic down the wrong one. 

2) While it might be helpful to use something other than IP
   addresses as identifiers in IKE MM, in practice the real
   issue is the identifiers used in IKE QM. While FQDNs or
   userIDs could be used to signify "me" and "you" if it is
   necessary to use subnets in the filters it is not clear 
   how this could be addressed. 

3) While IPSEC tunnel mode with "ANY to ANY" filters 
   can pass through a NAT, IPSEC/L2TP cannot, due to the 
   specific filters that need to be negotiated. 

4) To get IPSEC transport mode to work (with ESP) it would
   be necessary to either turn off UDP/TCP checksumming or
   have receivers not do checksum checks on packets protected
   by ISPEC SAs. At first glance, it wouldn't appear that
   ignoring checksum checks would do much damage since 
   the cryptographic hashes are stronger than checksums
   anyway.