Subject: (NAT) NATP behavior

From: [email-masked] (Tim Dorcey)
Date: Wed, 15 Sep 1999 23:23:46 -0700 (PDT)

Suppose a process behind a NATP writes a UDP packet from (private addr,port
x) to some (addr,port) on the public Internet.  The NAT picks an arbitrary
port y, and forwards the packet from (public addr,port y).  The process
then immediately writes another packet from the same (private addr,port x)
to a different destination (addr,port).  Assuming the NAT had not yet timed
out the original port mapping, would it be safe to assume that a well
behaved NAT would forward the second packet from the same (public addr,port
y)?  If not, can anyone give a good reason why a NAT should not behave that
way?

In a similar vein, if a NAT administrator has set up a static port mapping
so that all UDP packets which arrive at (public addr,port y) are forwarded
to (private addr,port x), is it safe to assume that any UDP packet which
originates at (private addr,port x) will be forwarded from (public
addr,port y)?

Would either of the above depend on whether port x was in the registered or
re-useable port range?

I am trying to upgrade an application protocol to work with NATP, and
haven't found much documentation on how these things work.  Thanks in
advance for any info.

Tim

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Michael C. Richardson" <[email-masked]>
Date: Sat, 18 Sep 1999 17:05:09 -0400

>>>>> "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
end host may not want, if the NAPT is really in the form of a firewall, 
then the end application looses. 
  So, while there are many NAPTs that do behave as you describe, I don't
think your application should rely upon it.

    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.

  See RSIP if you want things to really work for UDP.

   :!mcr!:            |  Cow#1: Are you worried about getting Mad Cow Disease?
   Michael Richardson |  Cow#2: No. I'm a duck.
 Home: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Tim Dorcey <[email-masked]>
Date: Sat, 18 Sep 1999 20:52:25 -0700

> was coming from the right origin. While this is a security check that the

I'm not sure what you're getting at.  If the process in the private space has sent packets to 2 destinations, then there are 2 "right
origins" for incoming packets.  Packets from either origin will be routed to the same process in the private address space.  I don't think
the NAPT needs to try to figure out which is a reply to which.  Why should the NAPT make it appear to hosts on the outside world that there
are 2 distinct endpoints?  Some applications might care to identify packets originating at the same end-point.  Of course, an IP source
(addr,port) is subject to spoofing, so an application should not put complete trust in it as an end-point identifier.  And, by the dynamic
nature of NAPT, the identification will be short lived.  But, then again, NAPT's look at source addresses all the time.  Other applications
might like to too.

>     Tim> forwarded from (public addr,port y)?

This makes no sense to me.  Suppose you have a telephone-like application that can play both client and server roles.  A person X behind a
NAPT wishes to accept calls from the outside world, so they set up a static port mapping to accept packets on (public addr,port s) and
forward them to (private addr,port t).  Another person Y behind another NAPT does the same thing.  Now, they both try to call each other at
the same time.  Person X originates a UDP packet at X(private addr,port t) to Y(public addr,port s); the NAPT chooses an arbitrary port x to
forward it from.  Person Y originates a UDP packet at Y(private addr,port t) to X(public addr,port s); their NAPT chooses an arbitrary port
y to forward it from.  Y replies to X's packet, which the NAPT sends back from s to x.  X replies to Y's packet, which their NAPT sends back
from s to y.  Now, X thinks it is talking to 2 different endpoints, s and y, and Y thinks it is talking to 2 different endpoints, s and x.
Perhaps they just carry on their conversation in duplicate.  More likely, the protocol carries some other end-point identifier, so now the
application has to figure out how the same person can be at 2 different addresses.  Perhaps someone has stolen their identifier.  Each might
decide to trust the connection they initiated and drop the other, so both would be dropped.  All of this could be avoided if the NAPT simply
used the same public port for all packets originating at a given private port within a reasonable time window (and if there is a static port
mapping in effect, it should anticipate its use).

Admittedly, this is a contrived example.  Here is a better one.  In the above application, X had to somehow figure out that Y could be
reached at Y(public addr,port s).  If a NAPT used consistent port mappings, Y could simply send a packet from (private addr,port t) to a
directory server of some sort.  The directory server could note the (addr,port) at which the packet arrived from and tell other hosts to use
that (addr,port) to reach Y.  Such directory services are likely to be needed anyway to handle dynamic IP address assignment.  The only
complication NAPT adds is that the application can no longer assume a well known port.  Or, at least, that's the only complication it needs
to add.

Tim

-

---

From: "Michael C. Richardson" <[email-masked]>
Date: Sun, 19 Sep 1999 10:23:47 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> was coming from the right origin. While this is a security check that

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

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

-

---

From: Tim Dorcey <[email-masked]>
Date: Sun, 19 Sep 1999 13:43:43 -0700

> the two outgoing connections.

I still don't understand the additional security achieved by mapping the same process to 2 different public ports.  Incoming packets will
have distinct source (addr,port)s, so I'm not sure why the NAPT requires them to also have distinct destination (addr,port)s, except perhaps
as a convenience for the NAPT developer.  But, then again, hackers have been known to do clever things, so I could easily be missing
something.  If there is a security benefit, then perhaps host IP stacks should start doing it as well, i.e., insert a different source port
for each different destination port on outgoing packets.

>   You might like it, but I can name at least ten NAPT implementations that

It would be very helpful to me if you would.  And also, if anyone can name particular NAPT implementations that do use consistent port
mappings, that would be a big help as well.  I have heard from one in private already, and will certainly recommend it to users of my
application.

> to pass them in the opposite direction.

I understand that.  And there seems to be a common default policy among NAPTs that it is okay to allow connections initiated from the
private side.  So, I would not have expected that setting up an explicit allowance for externally initiated connections on a given port
would automatically revoke the ability to initiate connections on that port from the private side.

>   You've just identified why NAPT is such a loss once you get beyond web

But, I thought I described a simple way that it could be made less of a loss.

> surfing. Use RSIP.

RSIP sounds like a good long-term solution, if ipv6 doesn't arrive first and obviate the need to use port mapping  to extend the address
space.

In the short term, I think NAPT vendors should offer their users a range of security levels.  My sense is that the main objective of many
people deploying NAPT today is to allow multiple hosts to share the same publically routable Internet address.  E.g., some address
translation products are called "routers" rather than "firewalls."  Some ISP's are assigning private addresses to dial-up customers, and I
doubt that their motive is security.  One could argue that forcing some security policies on them at the same time is a good thing.  The
problem is this:  effective security is generally based on allowing what has been explicitly permitted, and denying what is unknown.  But,
this raises the question of how something can become known in the first place.  E.g., if effective security policies had been widely
implemented on the Internet 8 years ago, the www would probably never have developed.  Fortunately, there were enough unprotected hosts at
educational institutions, and on dial-up links in subsequent years, to allow the value of the application to be demonstrated, and security
risks to become known, so that firewall administrators could make informed decisions about whether to permit it or not.  Without this kind
of open environment, the only source of new Internet applications will be large companies that have the clout to establish infrastructure
support prior to end-user demand.

Perhaps one could argue that now we know, the Internet is the www, and nothing else should be permitted.  But, I think the popularity of ICQ
and similar applications suggests that there is also strong demand for peer-to-peer communications, at least in the consumer space.  When
only small amounts of data are being exchanged, this can be implemented as a client-server-client interaction, which many NAPT's seem
willing to allow by default.  This becomes impractical for higher rate streams such as audio and video.  It seems silly to pump data into
and out of an application server simply to satisfy a NAPT's idea of how applications are supposed to work.

I don't have a problem if a NAPT administrator must specifically permit a certain protocol port to enable a peer-to-peer exchange.  The
problem I have is with wholesale prohibition of this type of communication, when all it takes to support it is consistent mapping of a
private port to a single public port (within a reasonable time window).

Tim

-