Subject: Re: (NAT) NATP behavior

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 19 Sep 1999 14:53:23 -0700 (PDT)

--- "Michael C. Richardson" <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> >>>>> "Tim" == Tim Dorcey <[email-masked]> writes:
>     Tim> "Michael C. Richardson" wrote:
> 
>     >> >>>>> "Tim" == Tim Dorcey <[email-masked]> writes:
>     Tim> Suppose a process behind a NATP writes a UDP packet from (private
>     Tim> addr,port x) to some (addr,port) on the public Internet.  The NAT
>     Tim> picks an arbitrary port y, and forwards the packet from (public
>     Tim> addr,port y).  The process then immediately writes another packet
>     Tim> from the same (private addr,port x) to a different destination
>     Tim> (addr,port).  Assuming the NAT had not yet timed out the original
>     Tim> port mapping, would it be safe to assume that a well behaved NAT
>     Tim> would forward the second packet from the same (public addr,port y)?
>     Tim> If not, can anyone give a good reason why a NAT should not behave
>     Tim> that way?
>     >> Because, the NAPT would have no way to determine if the reply packet
>     >> was coming from the right origin. While this is a security check that
>     >> the
> 
>     Tim> I'm not sure what you're getting at.  If the process in the private
>     Tim> space has sent packets to 2 destinations, then there are 2 "right
>     Tim> origins" for incoming packets.  Packets from either origin will be
>   
>   a NAPT that cares about security won't map to the same publicaddr,port for
> the two outgoing connections.
>  

Tim is right. This has nothing to do with security - Just a matter of what is
prevalent out there with NAPT implementations . There are many gaming
applications (like chat) that like to be able to interact with multiple peers
using the same (private-addr, TUPort#). I dont see any security harm in 
each of those sessions using the same (Assigned Addr, TUPort#) so the peer 
nodes can all identify the private user by a unique tuple of 
(Assigned Addr, TUPort#)   

>     Tim> routed to the same process in the private address space.  I don't
>     Tim> think the NAPT needs to try to figure out which is a reply to which.
>     Tim> Why should the NAPT make it appear to hosts on the outside world
>     Tim> that there are 2 distinct endpoints?  Some applications might care
>     Tim> to identify packets originating at the same end-point.  Of course,
>     Tim> an IP source (addr,port) is subject to spoofing, so an application
>     Tim> should not put complete trust in it as an end-point identifier.
>     Tim> And, by the dynamic nature of NAPT, the identification will be short
>     Tim> lived.  But, then again, NAPT's look at source addresses all the
>     Tim> time.  Other applications might like to too.
> 
>   You might like it, but I can name at least ten NAPT implementations that
> don't work that way.
>

Agreed. Many NAPT implementations do not work the way Tim was asking for.
That is merely because it is easier to implement the way they did - Not 
because of a security hole, as far as I can tell. 
 
>     Tim> In a similar vein, if a NAT administrator has set up a static port
>     Tim> mapping so that all UDP packets which arrive at (public addr,port y)
>     Tim> are forwarded to (private addr,port x), is it safe to assume that
>     Tim> any UDP packet which originates at (private addr,port x) will be
>     Tim> forwarded from (public addr,port y)?
>     >> No, I don't think so.
> 
>     Tim> This makes no sense to me.  Suppose you have a telephone-like
>     Tim> application that can play both client and server roles.  A person X
>     Tim> behind a NAPT wishes to accept calls from the outside world, so they
> 
>   Direction is very important to many administrators. Just because you are
> willing to accept packets in one direction does not mean that you are willing
                    ^^^^^^^
Change this to "sessions" - And I am with you. 

> to pass them in the opposite direction.
> 
>     Tim> set up a static port mapping to accept packets on (public addr,port
>     Tim> s) and forward them to (private addr,port t).  Another person Y
>     Tim> behind another NAPT does the same thing.  Now, they both try to call
> 
>   You've just identified why NAPT is such a loss once you get beyond web
> surfing. Use RSIP.
> 
Hmm... Sounds to me like a leap of faith to RSIP.

>    :!mcr!:            |  Cow#1: Are you worried about getting Mad Cow
> Disease?
>    Michael Richardson |  Cow#2: No. I'm a duck.
> 

cheers,
suresh

===

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.