[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT detection
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: NAT detection
- From: Marcus Watts <mdw_(_at_)_umich_(_dot_)_edu>
- Date: Tue, 03 Dec 2002 19:47:48 -0500
"YB" Jean-Yves Burlett <jean-yves_(_at_)_burlett_(_dot_)_org>
"RI" == Rossen Iliev <roko_(_at_)_gisbex_(_dot_)_com> write:
RI> It's a stupid question, but I want to be sure that there is no
RI> way for my ISP to detect the NAT server on my side?
YB> I think it can still be detectable based on traffic utilisation
YB> Even more simply : if you have, say, 2 computers behind the NAT that
YB> connect on your ISP's SMTP server and say HELO w/ a different name in
YB> a reasonably short amount of time, it can be a clue too.
YB> I don't think ISPs are that annoying w/ people doing NAT if they are
YB> not using their account to the max 24/7 like if you were doing a lot
YB> of p2p, etc.
I can think of at least 4 ways an ISP might be able to detect a
NAT (or "something"):
(1) mac address -- who assigned the ethernet address your NAT box
owns? Is there anything special about it?
(2) IP differences. Different IP stacks will generate
IP packets with slightly different contents
or otherwise behave differently. For instance,
some set DF, some don't, TTL may have different
values, etc. Even if your computers all run the
same TCP stack, your NAT box might change some
of these, but not others, which might in itself
indicate something is up.
(3) time delay. A NAT box is going to introduce an
unavoidable delay in packet propagation, which
is going to increase local round-trip delay.
(4) HTTP differences. Many browsers insert assorted
library and application versioning data into the HTTP
headers; multiple nearly simultaneous tcp streams
with different browser information fields
would suggest different computers or at least