Subject: Re: [NAT] Re: comments on draft-ietf-nat-app-guide--5.txt

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 19 Apr 2001 08:09:10 -0700 (PDT)

--- Tim Dorcey <[email-masked]> wrote:
> Pyda Srisuresh wrote:
> > > distinction I was trying to make was between the NAPT which maps a
> > > private port to a single public port and then keeps a list of acceptable
> > > remote (addr,port)'s for that port, versus the NAT which assigns a
> > > different public port for each acceptable remote (addr,port).  The
> > > former case is very much like a firewall.  The latter makes NATs more
> > > disruptive than they need to be.  I had guessed it was often motivated
> 
> > 
> > I do believe, the motivation is really one of security (i.e., being overly
> > cautious about letting in a new session, which may have hijacked an
> > existing session)  and perhaps a focus on one-to-one type of applications
> > rather than many-to-one type of applications that UDP is being used for.
> 
> What additional security is achieved by allowing only one session per
> public port?  Even if you allow multiple sessions per public port, you
> can still enforce the rule that sessions must be initiated from the
> private side.  If an application wants only one session per port, the
> application can open a new port on the local host for each new session. 
> What business does a NAT have assigning multiple public addresses to a
> single private address (where I mean "address" in this context to
> identify the process at (IP address,transport port))?
> 
> Tim
Many people view traditional NAT router as a one-way (session)
traffic filter, restricting sessions from external hosts into their
machines. Below is text from RFC 2663 security considerations section
addressing the subject w.r.t. UDP.

   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.

Clearly, these are different views on what a NAT device should
do with regard to UDP sessions. Some might choose to do one way 
over the other. Others might choose to give this as a configurable
option. I believe, Daniel was essentially pointing out the same 
thing in his earlier e-mail. The deciding criteria is not one of 
ease of implementation - rather a prefered point of view one takes. 
I am certainly not opposed to NAT retaining the same external 
UDP port assignment for communication with any number of 
external hosts. 

Thanks.

cheers,
suresh

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

_______________________________________________
nat mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nat

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 21 Apr 2001 12:45:28 -0700 (PDT)

[... snip]
> I have no problem with this view.  Reject packets that do not match an
> internally initiated session.  This is orthogonal to whether multiple
> sessions can occur on a single port.
> 

In that case, I agree with you. It indeed is an implementation-ease 
to not reuse an existing port BIND, when a new outbound session is 
created from same TCP/UDP port. Below is text from RFC 3022, 
section 3.1  which mentions this as a practice not commonly followed
by implementors.

   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.

> And I think this should be a requirement to call something a NAPT.  In
> conventional and mathmetical usage a "translation" is a 1:1 mapping.  If
> a device is going to map a single (addr,port) to multiple (addr,port)'s,
> then it should be called a "Network Address Port Mapper" or perhaps a
> "Network Session Translator."  It is clearly not translating an
> (addr,port).
> 

I understand and agree with what you say. But, NAT (and all the 
variations there of) as it stands, is not an IETF standard. So far, 
the WG has merely managed to capture the existing practice in the 
indutry, including all the caveats present, as a bunch of informational 
RFCs.

cheers,
suresh