Subject: (NAT) NAT response to packet from unknown external source

From: Tim Dorcey <[email-masked]>
Date: Fri, 13 Aug 1999 16:18:20 -0700

I am in the process of modifying an application protocol to make it
NAT-friendly, and have a question that I hope someone can help with.

Suppose a process at (private addr,private port) sends a UDP packet to
an external address S.  The NAT forwards the packet from (public
addr,public port) and leaves that port open for a period of time to
accept a "reply" from S.  It is my understanding that some NAT's will
forward any packet that arrives at (public addr,public port) to (private
addr,private port).  Other NATs will only forward packets arriving on
the public port if they believe them to be a "reply" (i.e., if their
source address matches S).  In this case, does anyone know what is the
common or recommended response to packets arriving from the wrong
source?  ICMP destination unreachable?  Silently drop?  Or something
else?

Thanks for any help,

Tim

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

---

From: Pravin <[email-masked]>
Date: Fri, 13 Aug 1999 19:06:42 -0700 (PDT)

silent drop is the best idea. 'cuz general practice is: NAT ports 
are in higher range say above 4096. you are receiving some datagrams on 
such ports from the mysterious sources means - someone in the dark corner 
is really curious about your network.

	sending him some honest ICMP destination/port unreachables
will give him some leverage ;-) do you want that?

-pravin
~~~
you can not step into the same river again!

-

---

From: Daniel Senie <[email-masked]>
Date: Fri, 13 Aug 1999 23:32:23 -0400

Thanks for taking the time to look into making your protocol
NAT-friendly. Your question is specifically about being NAPT friendly,
and this response takes that into account.

The NAPT box should ONLY translate and forward packets coming from the
outside world which match a table entry for the remote IP address and
Local (public) IP address and local port.

Specifically, you'd want to be sure directed broadcast packets that
happen to reach the public side of the NAPT gateway are not translated,
since there isn't a complete match.

The table in the NAPT should have the fields:

protocol (UDP, TCP, etc.)
private IP
private port
public IP
public port
remote IP
remote port

Storing the public IP address in each record of the table is not
necessary unless the NAPT box has multiple interfaces to the outside
world.

Incoming packets, such as reply packets, need to match on the public and
remote fields, or else the packet should be dropped. I prefer silent
drops in this case to ICMP responses, but others will disagree. It is
polite for hosts to send ICMP unreachable messages in these types of
cases, though folks who build firewall products often prefer not to
reply, as it gives out more information than the sender is really
entitled to. This is tangental to your question. Suffice it to say that
if your application doesn't have to rely on seeing ICMP unreachables,
that's probably the safer bet.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Tim Dorcey <[email-masked]>
Date: Fri, 13 Aug 1999 20:44:54 -0700

That would be my instinct if I were writing a NAT.  But, I'm not trying to
write a NAT, just trying to figure out how my application can best work with
what's out there now and in the future.

Actually, if I were writing a NAT, I wouldn't drop them at all, but would
forward incoming packets to the (private addr,private port) regardless of
where they originated (as an option).  That way, a process in a private
address space could establish a public service simply by sending packets to
some host in the outside world, i.e., to a directory server that could share
the location of the service with certain other hosts.  And, it could terminate
the public service by not sending any packets on that port for a while.

This would be useful when the particular "service" to be located is a
particular person running a particular application, where there is potentially
a wide range of application-specific mechanisms by which people might choose
to be identified, organized, and located by others at any given moment.

Tim

-