RE: [Algorithms] UDP Network connectivity

[nicroman <nic...@fr...>]

Hmmm,

NAT P2P communication is only possible (in a reliable fashion) if one of the
systems (A or B) is behind a cone-NAT (as long as the port is ok, all IP
addresses pass, which is a huge security failure, but,...), or using UPnP.

In the more "secure" (and normally following RFC3022) NAT, this simply
fails, because there is no way to tell B which will be the port A will use
to communicate with it !

Those routers are storing sextuples like (on A side):
(@A,port-A,@RA,port-RA,@RB,port-RB)
Incoming packets (A side) are discarded if they are not in the form:
(@RB,port-RB,@RA,port-RA).
On the B side, packets will also be discarded if they are not in the form:
(@RA,port-RA,@RB,port-RB)
And if at one point you change port-RB, port-RA WILL change as well (A
side), and if you change port-RA, port-RB will change on B side, making
these 2 values tied in a non predictable way, hence, making impossible to
establish a p2p connection (as soon as you receive a 'new' port-RB, your
port-RA will be obsolete, and the new port-RA won't make through to new
port-RB)

The only way to get around this, is:
- Cone-NAT (which shouldn't exist in my opinion)
- UPnP routers (they start to be the norm right now).

Nicolas Romantzoff



> -----Original Message-----
> 
> That is true, but part of the algo I described is at the same 
> time A sent a connection request to the IP/Port advertised on C, to B.
> 
> So A->B is a send from 10001 on A to 20000 on B. Since B is 
> cone NAT, 20000 is accepted for packets from both A and C.  B 
> then replies to A's packet source address (10001) and the 
> connection is establised.
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.782 / Virus Database: 528 - Release Date: 22/10/2004