Re: NAT Negotiation

On Tue, 13 Jan 2004 09:48:36 +1100 
Aaron Drew <[email protected]> wrote:
> On Mon, 12 Jan 2004 10:49 pm, Magnus Auvinen wrote:

>> Now the C1 and C2 can communicate with each other. I don't know if
>> this works because of the assumption at point 4. You could perhaps
>> use some other algorithm to predict what port will be the next one
>> (don't have PP installed so I can't look at the .ppt file).

> This is a *BAD* idea. I know that Linux doesn't just use the local
> port number for NAT connections but also the external destination
> address and destination port number. This is the most correct way to
> operate (especially from a security point of view) and any NAT
> implementation that relies on anything less (such as _only_ the local
> port number as you suggest) is clearly broken and should NOT be relied
> upon.

It is a bad but surprisingly reliable idea.  It is also a hack.  Loosely
it comes down to:

  Client1 sends packet to server.  Server notes port etc.

  Client2 sends packet to server.  Server notes port etc.

  Server predicts the next port which will allocated by the NAT devices
  for Client1 and Client2 and instructs each client to start sending a
  packet stream to the other's NAT device at the predicted port.

If the prediction was successful after a few packets each way (so that
each end creates a port mapping) two way communication through the NAT
boxes will be in place.  If the prediction was unsuccessful they'll
either have to try again or fail.  

This is exactly what GameSpy and similar products do.  Frankly they
usually do it by taking the new port number allocated by the test packet
stream to the server and incrementing it by one to get the predicted
port for the next port allocation.  Simple, dumb, surprisingly
effective.

> The ONLY reliable way to do this is to have some mutually accessible
> server in the middle and use it to explicitly relay traffic between
> NATed clients.

Right.  However an 85% solution covers a heck of a lot of bases,
especially when you can just throw in a few retries to whittle down that
15% failure mode to something consumer-grade acceptable.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email protected]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557