* Michael Rogers <m.rogers at cs.ucl.ac.uk> [2007-03-10 01:37:01]: > Matthew Toseland wrote: > > That's another interesting point: port rewriting. Right now we don't > > take any steps to identify our external port number, apart from using it > > as well as our real port number if we hear it from successful connectees. > > STUNT uses the following trick, based on the fact that most NATs > increase the external port number by 0, 1 or 2 for successive mappings > with the same internal address and port number: > > * Contact first STUNT server, learn external port p1 > * Contact second STUNT server, learn external port p2 > * Predicted port for next connection = p2 + (p2 - p1) > * Peers exchange their predicted ports out of band, then try to connect > > This might also work with STUN - I'm not sure whether UDP mappings are > allocated in the same way but I don't see why they wouldn't be. However, > the predicted port doesn't stay fresh for very long unless p1 = p2 (full > cone), so it might not be very useful unless the peers have a > low-latency channel to exchange predicted ports (eg a mutual friend's node). > > Cheers, > Michael
Moreover such things -source port randomization- (http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=90) will prevent it to work ;) NextGen$
