a funny thing happened on the way to the nsa(.gov)


we talked about traceroute last week in understanding networks. this led me down a thousand rabbit holes, including this instructive powerpoint presentation featuring

Random Traceroute Factoid

•The default starting port in UNIX traceroute is 33434.This comes from 32768 (2^15 or the max value of a signed 16-bit integer) + 666 (the mark of Satan).”


but also more applicable things like address naming conventions and how to notice different possible relationships between network types (p21).


i wanted to see if anything interesting happened when i ran traceroute nsa.gov.

answer: not really. i ran whois on some of these, but they’re just regular ol’ cloud companies in new york and massachusetts and colorado. i guess this makes sense because the nsa probably doesn’t store all of our stuff on the same server that hosts the nsa.gov website.

from there, i tried to find an isis website, thinking that that might be a better way to find an nsa server along a traceroute. it was surprisingly difficult for me to find one via (english) google or twitter. i did learn about a quarterly isis magazine, but it had no web presence to speak of. #printnotdead

googling “nsa traceroute” pulled up a wired article from 2006 which lists the address of the folsom street web carrier hotel in san fran where the nsa was mirroring everyone’s communication. the article said to look for the string tbr2-p012201.sffca.ip.att.net in your traceroute or, really, any att.net string. still no dice. but, per the powerpoint presentation above, i was able to tell that the “sf” in there probably stands for “san francisco”.

it felt like i’d hit a dead end, so i read the manual page for traceroute to see if there were any arguments i could add to my traceroute command to give me more information. -D looked promising:

“When an ICMP response to our probe datagram is received, print
the differences between the transmitted packet and the packet
quoted by the ICMP response.  A key showing the location of
fields within the transmitted packet is printed, followed by the
original packet in hex, followed by the quoted packet in hex.
Bytes that are unchanged in the quoted packet are shown as under-
scores.  Note, the IP checksum and the TTL of the quoted packet
are not expected to match.  By default, only one probe per hop is
sent with this option.”

i dunno, maybe looking at the packet contents could be helpful? here’s a sampling:

from the definition in the manual page, we know the structure of this blob of letters and numbers is

[human-readable(ish) header]

[outbound packet contents]

[inbound packet contents with existing stuff as underscore and new stuff denoted]

so, a few interesting things, although not really what i was looking for:

  • tl decrements every time it’s sent out, and always comes back as 1. this must be the “time to live”!
  • the bytes? bits? under sum always leave as 0 and come back as something slightly different. maybe this is just to notify that it’s a new packet? or maybe the TTL changes the packet a little?
  • the ts always leaves as “00” and comes back as “08”. maybe 00 means outgoing and 08 means incoming? idk, tbh.

eventually, i somehow ended up at what i think is the traceroute spec, which sort of verified pieces of this. hopefully, i can get some more insight during class this week.

see, i told you! rabbit holes…

Leave a Reply