RE: Airport NAT behavior
RE: Airport NAT behavior
- Subject: RE: Airport NAT behavior
- From: "Tim Dorcey" <email@hidden>
- Date: Mon, 27 Mar 2006 21:05:14 -0800
- Importance: Normal
> Have you looked at STUN (RFC 3489)? It seems to solve some of these
> problems, but it does require at least one end to have a
Yes, but it will also be stymied by NAT's which use a different port for
each connection. The core issue is this. A host can signal their NAT that
inbound traffic is desired from a certain remote (addr,port) simply by
sending a packet to that (addr,port). But, to do that, they must first know
where the inbound traffic will be coming from, which is impossible if the
NAT on the other end is choosing a new port for each connection. The only
way to learn the port is to receive a packet, and the only way to receive a
packet is to first know the port.
If the NATs maintain 1:1 port mappings, then each party can learn the other
party's (addr,port) from a central server that both have connected to. They
can each instruct their NAT's to accept inbound traffic from that addr,port
by simultaneously initiating connections to each other.
This kind of "connection broker" is generally viewed as an unpleasant hack,
that would be unnecessary if NAT-PMP or ipv6 were widely deployed. However,
I think it has some merit in its own right. From a purist point of view,
address secrecy is a poor form of security. But, I have seen the following
scenario play out in the real world: User A acquires (addr,port) of user B
from central directory server and requests a connection from B. User B
refuses connection. User A retaliates by launching favorite DOS attack
against B.
The solution in the directory server model is for user A to install access
control rules on the server to regulate distribution of their (addr,port).
But, this could become cumbersome. There is much to be said for keeping
these rules on the client where they can be easily upated, and perhaps
augmented by an interactive UI. Then, the server can act as an
intermediary, passing small amounts of information between end-points during
a negotiation phase. Only if they agree to connect are addresses
distributed. Then, since both parties already know who they are, it is easy
for each to instruct their NAT what particular (addr,port) is to be allowed
in.
So, I will add NAT-PMP support to my app as soon as I possibly can, to get
the 1:1 port mapping it insures. But, I don't see that obviating the need
for connection brokers.
Sorry for getting off track on this list.
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden