Subject: (NAT) Comment on RFC 2663

From: Tim Dorcey <[email-masked]>
Date: Fri, 26 Jan 2001 19:18:38 -0800

In trying to give some users guidance on if/how a particular application
would work with their particular firewall/IP
sharing/router/modem/masquerading/NAT product, I was hoping I might find
the terminology I needed in RFC 2663.  The distinction I was looking for
was between what I would call "connection-oriented" versus
"connection-less" NAT.  A connection-oriented NAT maintains a 1:1
mapping between (private addr,private port,remote addr,remote port) <->
(public addr,public port).  A connection-less NAT maintains a 1:1
mapping between (private addr,private port) <-> (public addr, public
port), regardless of how many remote end-points the (private
addr,private port) may be interacting with.

This issue is not the same as the one-directional versus bi-directional
distinction discussed in RFC 2663.  For example, a NAT could be
connection-less, but still enforce the rule that incoming packets are
rejected unless they originate at an address to which a packet has been
recently sent.  And, theoretically at least, a NAT could be
connection-oriented while still allowing the first packet of a session
to originate outside the private network.

The distinction is significant because "telephone-like" applications can
function easily in a connection-less NAT environment as follows.  When
the application wishes to accept calls, it can establish a session with
a directory server in the public address space, which can then provide
to other hosts the (public addr, public port) at which this application
is currently reachable.  If the NAT is configured to prohibit external
initiations, then 2 applications who wish to communicate with one
another can both initiate packets toward each other (coordinated by the
directory server or some other intermediary in the public address
space), signalling their NAT that incoming traffic from that end-point
is desired.

Of course, this won't work if the NAT is connection-oriented, since
"each other" is not defined until packets are initiated to each other.
One might say that connection-oriented NAT is therefore more secure,
since it prevents 2 parties from using coordinated simultaneous
initiations to get around a block on external initiations.  But, the
only extra security is that a host behind a connection-oriented NAT
could not be triggered into establishing a connection with another host
who is also behind a connection-oriented NAT (or any device that blocks
external initiations).  That doesn't sound like much of a security
feature.  It does sound like a major impediment to desired
communications.

Whether it is a good thing or a bad thing, we really need some accepted
terminology for this distinction.  E.g., recent releases of Linux IP
Masquerade will operate in "connection-less" mode for UDP traffic if you
enable the "LooseUDP" option.  Who knows what it is called (if it is
available) with other NAT implementations.   I do not believe the RFC
2663 discussion of "one-directional" versus "bi-directional" NAT is
adequate.  And, I don't believe an application that depends on 1:1
end-point mappings should need an ALG to operate through a NAT.  If
anything, applications that want connections mapped to end-points should
need an ALG.

Tim

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.
List archive: <URL:http://www.portmasters.com/archives/>