Subject: Re: (NAT) Comment on RFC 2663

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 28 Jan 2001 09:56:30 -0800 (PST)

Tim,

NAT is basically session oriented. Below is text from RFC 2663, 
section 9, concerning the security issue with UDP sessions.
        
   1. UDP sessions are inherently unsafe. Responses to a datagram
      could come from an address different from the target address
      used by sender ([Ref 4]). As a result, an incoming UDP packet
      might match the outbound session of a traditional NAT router
      only in part (the destination address and UDP port number of
      the packet match, but the source address and port number may
      not). In such a case, there is a potential security compromise
      for the NAT device in permitting inbound packets with partial
      match. This UDP security issue is also inherent to firewalls.

      Traditional NAT implementations that do not track datagrams on
      a per-session basis but lump states of multiple UDP sessions
      using the same address binding into a single unified session
      could compromise the security even further. This is because,
      the granularity of packet matching would be further limited to
      just the destination address of the inbound UDP packets.

RFC 3022 (Traditional NAT) says the following about address (and port)
binding for NAPT in section 3.1

   In the case of NAPT, where many private addresses are mapped to a
   single globally unique address, the binding would be from the tuple
   of (private address, private TU port) to the tuple of (assigned
   address, assigned TU port).  As with Basic NAT, this binding is
   determined when the first outgoing session is initiated by the tuple
   of (private address, private TU port) on the private host.  While not
   a common practice, it is possible to have an application on private
   host establish multiple simultaneous sessions originating from the
   same tuple of (private address, private TU port).  In such a case, a
   single binding for the tuple of (private address, private TU port)
   may be used for translation of packets pertaining to all sessions
   originating from the same tuple on a host.

As you can see, neither of the RFCs prohibit the use of UDP port 
binding in the manner you suggest. It is an implementation option 
as to how UDP session binding is done for individual UDP based 
applications. For example, the approach you suggest was pursued by 
Activision folks for their game protocol design (Ref: Section 5.1, 
RC3027).

Hope this helps.

cheers,
suresh

--- Tim Dorcey <[email-masked]> wrote:
> 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/>

=====

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.
List archive: <URL:http://www.portmasters.com/archives/>

---

From: Tim Dorcey <[email-masked]>
Date: Sun, 28 Jan 2001 14:40:30 -0800

> Activision folks for their game protocol design (Ref: Section 5.1,

Yes, I realize that, but I am not a NAT implementor.  What I was looking for
was some terminology by which the needs of my application could be concisely
communicated to users and to NAT product vendors.  It would great if I could
say "this application will work if your NAT supports connection-less UDP port
binding, as defined in RFC 2663."  Then, the user could search for this in
their NAT documentation, or contact the NAT vendor.  I guess I can refer them
to "Activision protocol," but I really think this issue is more fundamental.

NAT would not be nearly so disruptive to the development of new applications
if it simply engaged in address remapping, rather than prohibiting multiple
sessions per address (where I take "address" in this context to mean (IP
address,TU port)).  That's what really destroys the concept of an address.  If
an application wants only one session per address, it can open up new ports on
the local host for each new session.  Allowing multiple sessions per address
does not prevent the NAT from requiring internal initiation of new sessions.
It just means that it must maintain a list of acceptable sessions for each
local address, rather than assigning a new local address to each acceptable
session.  With either variety of NAT, it is possible for a host to be
triggered into initiating a session toward a malicious host.  The only
difference is that connection-oriented NAT prevents this from occurring when
the malicious host also cannot accept external initiations.

I am personally interested in UDP, where connectionless NAT allows 2 hosts to
establish a session by simultaneous inititations (since the NAT cannot
distinguish a session initiation from a reply).  In the case of TCP, a NAT can
distinguish a reply from an initiation, but I wonder why it should care?  If I
send a SYN to a certain address, isn't that evidence that I would like a TCP
session with that end-point, so why should the NAT care whether it is an
outgoing or an incoming SYN that actually succeeds in establishing a session?
I guess there is some risk that an incoming SYN could be from a source address
that is spoofed to match a recent outgoing SYN destination.  I'm not sure this
is a major threat, but I am no security expert.

Again, I am not suggesting that NAT's should be mandated to maintain 1:1
address mappings (though my personal preferences are obviously evident).  I am
just asking for some terminology by which application developers, application
users, and NAT developers might communicate about this issue.

Tim

-