ietf
[Top] [All Lists]

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

2000-04-22 14:50:02
   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? 

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

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

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.  

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.

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.  

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. 

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.  

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.

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.

yes.

Keith