Specious network performance measurements.

["Peter J. Cherny" <peterc () arquebus com au>]

While a bit off-list, I think this will be of interest ...

The probes shown in the trace below is representative what happens
after querying usatoday.com for the address of www.usatoday.com.

The probes are a brace of three echo requests, three dns udp null queries,
three tcp dns setups and a batch of udp traceroute packets, repeated a number
of times over the following days.

As the destination address is that of my border router (I use it's
src address for some dns queries) the traffic leaped out of the logs.

The explanation given by USAToday is included after the trace below.

I also believe that the source of the packets are F5 networks boxen.

I question the naive assumption that the metrics so gleaned will tell
anything at all about the topology of the network in which the target
user resides. It certainly won't tell them  much about my leaf nodes or
details about my upsteam provider Telstra's network.
(In fact, their main dns forwarder lives in Canberra while the US gateway
is most often out of Perth 3000 miles away).
I'd have thought AS routes would make a better way of finding the closest
usatoday server, certainly not icmp echo and dns which often travel
quite different paths to web traffic.
The assumption that any US based server will be closer than any other
also fails spectacularly for clients not in the US.

I'm also concerned that if another 100K web sites decide to do the same
measurements the net will be overwhelmed with noise.

Looking for a sanity check, pjc

------------------------------------------------------------------------------
20:21:51 206.251.19.80 -> 139.130.50.3 ICMP Echo (ping) request 
20:21:51 206.251.19.80 -> 139.130.50.3 ICMP Echo (ping) request
20:21:51 206.251.19.80 -> 139.130.50.3 ICMP Echo (ping) request

20:23:13 206.251.19.80 -> 139.130.50.3 DNS Standard query
20:23:13 206.251.19.80 -> 139.130.50.3 DNS Standard query
20:23:13 206.251.19.80 -> 139.130.50.3 DNS Standard query

20:24:14 206.251.19.80 -> 139.130.50.3 TCP 2200 > domain [SYN] Ack=0
Win=2048 Len=64
20:24:14 206.251.19.80 -> 139.130.50.3 TCP 2201 > domain [SYN] Ack=0
Win=2048 Len=64
20:24:14 206.251.19.80 -> 139.130.50.3 TCP 2202 > domain [SYN] Ack=0
Win=2048 Len=64

20:42:46 206.251.19.88 -> 139.130.50.3 UDP Src port: 2815  Dest port: 33434
20:42:48 206.251.19.88 -> 139.130.50.3 UDP Src port: 2816  Dest port: 33434
20:42:49 206.251.19.88 -> 139.130.50.3 UDP Src port: 2817  Dest port: 33434
20:43:56 206.251.19.88 -> 139.130.50.3 UDP Src port: 2815  Dest port: 33434
20:43:57 206.251.19.88 -> 139.130.50.3 UDP Src port: 2816  Dest port: 33434
20:43:59 206.251.19.88 -> 139.130.50.3 UDP Src port: 2817  Dest port: 33434
20:45:47 206.251.19.89 -> 139.130.50.3 UDP Src port: 2815  Dest port: 33434
20:45:48 206.251.19.89 -> 139.130.50.3 UDP Src port: 2816  Dest port: 33434
20:45:49 206.251.19.89 -> 139.130.50.3 UDP Src port: 2817  Dest port: 33434
20:46:50 206.251.19.89 -> 139.130.50.3 UDP Src port: 2815  Dest port: 33434
20:46:51 206.251.19.89 -> 139.130.50.3 UDP Src port: 2816  Dest port: 33434
20:46:53 206.251.19.89 -> 139.130.50.3 UDP Src port: 2817  Dest port: 33434
20:48:03 206.251.19.89 -> 139.130.50.3 UDP Src port: 2815  Dest port: 33434
20:48:04 206.251.19.89 -> 139.130.50.3 UDP Src port: 2816  Dest port: 33434
20:48:05 206.251.19.89 -> 139.130.50.3 UDP Src port: 2817  Dest port: 33434
20:49:13 206.251.19.89 -> 139.130.50.3 UDP Src port: 2815  Dest port: 33434
20:49:15 206.251.19.89 -> 139.130.50.3 UDP Src port: 2816  Dest port: 33434
20:49:16 206.251.19.89 -> 139.130.50.3 UDP Src port: 2817  Dest port: 33434
20:54:26 206.251.19.80 -> 139.130.50.3 UDP Src port: 2715  Dest port: 33434
20:54:28 206.251.19.80 -> 139.130.50.3 UDP Src port: 2716  Dest port: 33434
20:54:29 206.251.19.80 -> 139.130.50.3 UDP Src port: 2717  Dest port: 33434

------------------------------------------------------------------------------
Extracts of explanation from USAToday :-

<snip>
We own the devices and addresses for networks 209.67.29, 206.251.19, 167.8.29
and 216.33.87.
<snip>
While we currently do not have a way to disable the 64 byte packets to your
site I can at least explain the system  to you so you can understand as
well.......

We have several locations for our systems and have users accessing
www.usatoday.com from around the nation.  We try to provide the best response
time for the readers by using QOS measurements.
Those measurements include round trip time, completion rate, hop count,
topology, etc......   To obtain those metrics all of our sites perform 
automated pings and traceroutes to the local DNS system or network where the
user traffic originated from.   This can include ICMP pings,  destination
traffic for UDP port 33434, destination traffic for TCP/UDP port 53.

Our systems are in no way trying to maliciously learn about your network or in
any way attack your systems or 
infrastructure.

Our sole purpose is to collect response times, hop count and other
measurements
which are then used our traffic management systems to direct  www.usatoday.com
http traffic to the best location.   The methods the systems use to do that
are
standard practice and not harmful.  The settings are globally enabled and 
automated and we do not have settings we can adjust specifically for your
site. 
While the traffic may be unwanted - bear in mind it is a small amount of
traffic.  The packets are the minimum ip packet size of 64 bytes each and
generally occur in sets of three per request to our site.   It would be
helpful
if you would open up your DNS system for port 53 dns queries specifically for
our addresses as this would allow us to better serve our customers and would
also minimize the unsuccessful attempts by our systems to collect performance
data.

<snip>
------------------------------------------------------------------------------