I decided to see if I could find out more about this mysterious IP address that apparently belongs to the Department of Defense.
One of the best ways to do this is to run a traceroute, which shows the path back to the IP through the Internet’s routers. I also wanted to see if I could find any evidence that my router or my ISP’s router was compromised or broken.
Performing a traceroute from my home computer to the IP provides me this output:
root@maestro:# traceroute 28.191.58.169
traceroute to 28.191.58.169 (28.191.58.169), 30 hops max, 60 byte packets
1 wireless.tonsler (192.168.3.252) 0.971 ms 1.419 ms 1.634 ms
2 user-0c2h181.cable.mindspring.com (24.40.133.1) 14.064 ms 13.993 ms 24.788 ms
3 66.26.46.13 (66.26.46.13) 18.689 ms 18.942 ms 19.029 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
It’s not unusual that the traceroute dies on the way back: many hosts and/or networks go down and the packet trace stops. However, it is interesting that the traceroute dies on Time Warner’s network. That last router, 66.26.46.13, belongs to Road Runner:
#
# Query terms are ambiguous. The query is assumed to be:
# “n 66.26.46.13”
#
# Use “?” to get help.
##
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=66.26.46.13?showDetails=true&showARIN=false&ext=netref2
#NetRange: 66.26.0.0 – 66.26.255.255
CIDR: 66.26.0.0/16
OriginAS:
NetName: ROADRUNNER-MIDSOUTH
NetHandle: NET-66-26-0-0-1
Parent: NET-66-0-0-0-0
NetType: Direct Allocation
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate: 2000-09-29
Updated: 2011-07-06
Ref: http://whois.arin.net/rest/net/NET-66-26-0-0-1OrgName: Road Runner HoldCo LLC
OrgId: RRMA
Address: 13820 Sunrise Valley Dr
City: Herndon
StateProv: VA
PostalCode: 20171
Country: US
RegDate:
Updated: 2011-06-07
Comment: Allocations for this OrgID serve Road Runner residential customers out of the Columbus, OH, Herndon, VA and Raleigh, NC RDCs.
Ref: http://whois.arin.net/rest/org/RRMAReferralServer: rwhois://ipmt.rr.com:4321
OrgTechHandle: IPTEC-ARIN
OrgTechName: IP Tech
OrgTechPhone: +1-703-345-3416
OrgTechEmail: abuse@rr.com
OrgTechRef: http://whois.arin.net/rest/poc/IPTEC-ARINOrgAbuseHandle: ABUSE10-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-703-345-3416
OrgAbuseEmail: abuse@rr.com
OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE10-ARIN#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#Found a referral to ipmt.rr.com:4321.
%rwhois V-1.5:0020b0:00 ipmt.rr.com (by Time Warner Cable, Inc. V-1.0)
network:Class-Name:network
network:ID:NETBLK-ISRR-66.26.0.0-18
network:Auth-Area:66.26.0.0/18
network:Org-Name:Road Runner
network:Tech-Contact:ipaddreg@rr.com
network:Updated:2011-11-08 10:31:32
network:IP-Network:66.26.0.0/18
network:Admin-Contact:IPADD-ARIN
network:IP-Network-Range:66.26.0.0 – 66.26.63.255organization:Class-Name:organization
organization:ID:NETBLK-ISRR-66.26.0.0-18
organization:Auth-Area:66.26.0.0/18
organization:Org-Name:Road Runner
organization:Tech-Contact:ipaddreg@rr.com
organization:Street-Address:13820 Sunrise Valley Drive
organization:City:Herndon
organization:State:VA
organization:Postal-Code:20171
organization:Country-Code:US
organization:Phone:703-345-3151
organization:Updated:2011-11-08 10:31:32
organization:Created:2011-11-08 10:31:32
organization:Admin-Contact:IPADD-ARIN%ok
#
# Query terms are ambiguous. The query is assumed to be:
# “n 66.26.46.13”
#
# Use “?” to get help.
##
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=66.26.46.13?showDetails=true&showARIN=false&ext=netref2
#NetRange: 66.26.0.0 – 66.26.255.255
CIDR: 66.26.0.0/16
OriginAS:
NetName: ROADRUNNER-MIDSOUTH
NetHandle: NET-66-26-0-0-1
Parent: NET-66-0-0-0-0
NetType: Direct Allocation
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate: 2000-09-29
Updated: 2011-07-06
Ref: http://whois.arin.net/rest/net/NET-66-26-0-0-1OrgName: Road Runner HoldCo LLC
OrgId: RRMA
Address: 13820 Sunrise Valley Dr
City: Herndon
StateProv: VA
PostalCode: 20171
Country: US
RegDate:
Updated: 2011-06-07
Comment: Allocations for this OrgID serve Road Runner residential customers out of the Columbus, OH, Herndon, VA and Raleigh, NC RDCs.
Ref: http://whois.arin.net/rest/org/RRMAReferralServer: rwhois://ipmt.rr.com:4321
I would expect the packet to die after crossing a DoD router somewhere, but instead it dies on Time Warner’s router. It’s as if the router was programmed to drop the packet like it does with the standard non-routeable networks. The router certainly didn’t shuffle the packet up to Ohio as one would expect, though I’m sure the WHOIS record for the DoD address points to an administrative office in Columbus. I know the datacenter could be somewhere else. Like Fort Meade, perhaps.
So my traceroute experiment provides me with more questions than answers, leading me to believe this traffic isn’t a hacker’s prank after all.
Update 2:25 PM: It also dies mysteriously from my hosting provider:
[markt@eddy ~]$ traceroute 28.191.58.169
traceroute to 28.191.58.169 (28.191.58.169), 30 hops max, 40 byte packets
1 10.1.2.61 (10.1.2.61) 0.376 ms 0.605 ms 0.843 ms
2 . (67.217.162.84) 1.105 ms 1.121 ms 0.986 ms
3 v941.ash01-mls-dc-core-a.latisys.net (67.217.171.53) 0.844 ms 0.834 ms 0.683 ms
4 v912.ash01-mls-dc-bdr-a.latisys.net (67.217.171.17) 1.205 ms 0.997 ms 0.966 ms
5 * * *
6 * * *
It’s possible that the DOD requested the packets to be dropped so that their connection can’t be DOS’d. It’s also possible that it’s for many other reasons, and not necessarily related to concealing a surveillance operation.
Or, as the commenters on the TriLUG mailing list pointed out, there may not be any advertised routes for this network block. Therefore, some ISPs treat it like a private network block which will never be used in a corporate or home network.
After seeing your posts, I strongly believe to think that your telecomprovider is using DPI (deep packet inspection). Since you are using a SIP connection, that connection is routed to the DOD which routes it on towards you, probably sniffing the connection on-the-fly. In holland (where I live) we had a big problem with mobile phone providers not allowing VoIP connections, due to certain DPI settings that disallowed traffic to services like whatsapp, skype, and many others. I think the DOD enforced your ISP to put a DPI-router on their system, which causes every SIP package to be routed to the DOD server.
Traceroute just sends out pings with a different TTL. When they get blocked (like you see with ***) doesnt mean that it doesnt work, it just means that they blocked ICMP packages. Try portscanning, maybe that will give the result that you were looking for (but be warned, the DOD may have alarm triggers set on certain ports).
This is a simple case of sprint using the DoD block inside their network and NATing to a public IP.
The problem is their NAT equipment doesn’t know how to fix SIP packets. Your music player is probably standard HTTP traffic and works fine through their NAT.
Your traceroute dies because that IP is not globally routable. You can use a looking glass service (example: http://lookingglass.level3.net/bgp/bgp.cgi?site=sea1&target=28.191.58.169) to see that that IP isn’t advertised on the internet.
If they were doing DPI or something as crazy as “the router was programmed to drop the packet” it would be MUCH easier to transparently tap the line than alter the packets with the help of all major ISPs.
The DoD doesn’t care about your SIP packets.
Hi Tony,
Your reasoning is sound, though I’d like to see some sort of evidence that shows that Sprint is indeed squatting on this network for use as private IPs and from yesterday’s Google searches I haven’t found much of this at all.
On the other hand, I’ve noticed traffic from my phone coming from two different DoD IPs during separate phone call tests that took place within minutes of each other. If this traffic is being NATted by Sprint, it certainly isn’t a one-to-one mapping. And my phone wouldn’t be assigned a different, DoD-based IP address within minutes (or Sprint’s DHCP leases are far too short!).
So if my phone, internally, is using a DoD IP as a private IP and Sprint is NATting this and Sprint’s firewall isn’t smart enough to rewrite the private IP in the SIP packets, then I would expect to see that private IP to remain constant for longer than it has. Do you see what I mean?
(And yes, I readily admit the possibility that my phone was reassigned a different IP from Sprint’s DHCP server between my test calls but it would’ve been quite coincidental.)