On Thu, 2006-07-06 at 11:25 +0200, Antoine Pitrou wrote: > The solution is to detect that the two processes are behind the same NAT > (i.e. they share the same public IP address), then use the private > IP/port instead of the public one. There may be corner cases but I doubt > they're really important...
You cannot do this in general.
Processes: A, B
NATs: N, M, O
STUN server: S
Internet: I
(no other participants)
A -- N
|
+-- O -- I -- S
|
B -- M
There is no way for A or B to get N's or M's address (in the N-M-O
subnet). A and B can only learn O's external address. A's and B's
private address in their own subnets are useless. The *only* way A and B
can communicate is to hairpin through O. Or install a new STUN server
inside the N-M-O subnet, which is not always possible.
For this reason, hairpin support is *required* for NATs (in the upcoming
RFC, draft-ietf-behave-nat-udp-07).
Regarding security issues, as David and Alex pointed out, hairpin
support does not affect the security offered by the NAT (when
implemented properly).
--
Saikat
signature.asc
Description: This is a digitally signed message part
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
