Why Is The Defense Department Snooping On My Phone? | Hacker News Reader

Why Is The Defense Department Snooping On My Phone?

markturner.net

267 pointsmindcrime34 comments

Quick synopsis:

Provider uses IP addresses for their internal network tunnels that correspond to a DOD ARIN allocation.

Looks like this was the case.

> Aha! The IP is assigned to my phone’s GSM interface, so it looks like it’s benign after all. > That did the tip, Amatus!

A (extremely) large number of usual local network IP ranges are issued to the DOD. Including my local subnet as well. 11.1.11.0/24, if I ran a whois on that IP as well, it would return DOD, but that doesn't mean the DOD is snooping my network, it just means my router has all the routes for 11.1.11.0/24 associated with it and doesn't actually attempt to send traffic over the wire to that IP. I assume your Android phone is listening locally on that address for the VOIP communication, which would in return mean the DOD is NOT snooping on your phone. Much similar to apache or (insert other socket application) listening to 127.0.0.1:80 for local only traffic.

So you're saying that providers are using these address ranges where you'd usually expect to see something like 10., 172.16-31. or 192.168.*? That is, purely internal traffic that's not routed over the public net?

If so, I could buy that, but my question is "why?" That is, why not use an actual RFC1918 private address?

Or is your point actually something different, and I'm just missing it?

we are talking about an address IP range that happens to be DNS registered..it could be as simple as the DoD has some extra bandwidth/infrastructure that they are leasing out to say Sprint?

.it could be as simple as the DoD has some extra bandwidth/infrastructure that they are leasing out to say Sprint?

Ok, I get that in principle... but that particular combination sounds awfully suspicious. The DoD just happens to have extra IP space, and they just happen to lease it to cell phone carriers? Hmmmmmmmmm....

I mean, yeah, it could all be totally innocuous, but I'm still suspicious that there might be something else going on. I'm not exactly a card carrying member of the tinfoil-hat brigade, but I trust our government about as far as I can throw it... :-)

http://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addres...

Do a control-f for "DOD". These guys have so much IP4 space its not even funny. Being the government, they'll never give it up. So a total of 200 million IP4 addresses:

http://royal.pingdom.com/2008/02/13/where-did-all-the-ip-num...

So, when the country that starts the internet is also the country with the largest, by far, military and has obscene military spending, well, this is what happens.

Wow. For the curious but unmotivated, here are the /8 IPs they control:

7.0.0.0/8 11. 21. 22. 26. 28. 29. 30. 33. 55. 214. 215.

(omitted the 0.0.0/8 from all but the first for brevity)

I just had a LOST flashback.

Are you sure it wasn't a... flash forward?

I doubt the DOD purchased IP blocks much as I doubt Apple pays for their domain name.

Back before the commercialization of the Internet these things were relatively free.

DOD has 211 million public IP's! That is a way to reduce the budget deficit by auctioning off extra IP's. I doubt the DOD needs that many public IP's

Or like a tax refund they could give one to every adult in the USA!

Given that the DoD would probably still run the infrastructure.... no way I would accept that....

The best part is that the DoD is working hard to limit the outgoing bandwidth to just a certain subset of IP addresses in an attempt to limit their attack surface, so most of those IP addresses are never going to be externally accessible and may simple be used internally for internal only networks.

No, DOD is not leasing out IP addresses; ISPs are basically "stealing" them from DOD. This shouldn't be happening, but for some reason cellular carriers are complaining that ARIN won't give them IPv4 addresses even though addresses are available and the carriers clearly have enough devices to qualify. Something has gone wrong here, but I have not been able to find out why.

I'll guess mindcrime is the original poster. Due to responses to multiple threads, I figure a single explanation should suffice, referenced to related portions.

a904guy is using addresses that are not in the RFC 1918 block for his personal network. While this is discouraged, there isn't anything preventing it. It can cause problems if someone decides to later use 11.1.11.0/24 since he wouldn't be able to use those addresses locally AND talk to external sites on that same netblock without doing some creative NAT.

Secondly, yes, the provider should use RFC 1918 and RFC 4193 blocks. While this can cause problems when provider A uses 10.0.0.0/24 and provider B uses 10.0.0.0/24 and Provider A later buys Provider B, the private address blocks are there and are not supposed to be routed or announced outside local networks. In this case, it appears that Time Warner (or whomever), used 28.0.0.0/8 internally. This probably dates back to the @home network when the providers shared responsibility and grabbed the 24.0.0.0/8 block, then, later split and renumbered. TWC may have just swapped 24 for 28 on their network to eliminate re-engineering. No way to know for sure without someone knowing some history.

shareme: There is a difference between DNS registered (which this block is not), and assigned and registered by ARIN. ARIN delegates blocks to particular entities and maintains that directory. That doesn't mean I can't use those IP addresses locally (I wouldn't be able to announce them to the global internet - well, you could if you had upstream providers willing or negligent in their best practices).

The government is not leasing IP addresses to Sprint. How do we know this? Because the IP addresses are not being announced by anyone:

    HE.inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden)
    + = Active Route, - = Last Active, * = Both
    0.0.0.0/0          *[Static/5] 28w4d 15:04:18
                    > to x.x.x.x via ge-0/3/0.0

    Internap.inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden)
    + = Active Route, - = Last Active, * = Both

    0.0.0.0/0          *[Static/5] 28w4d 15:03:57
                    > to x.x.x.x via ge-0/1/0.0

or, if you don't trust an active routing table that has defaults set, you can look at route-views:

    route-views>show ip bgp 28.191.58.169
    BGP routing table entry for 0.0.0.0/0, version 338718131
    Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
      Not advertised to any peer
      2905 65524 16637
      196.7.106.245 from 196.7.106.245 (196.7.106.245)
        Origin IGP, metric 0, localpref 100, valid, external, best

Now, related to this conversation, but included in a separate blog post, are some traceroutes that show packets vanishing into thin air as they exit networks.

As most networks don't run defaultless - they have a default path just in case they receive a packet for an IP address that isn't in their routing table. This happens when you have a client of a provider that may not have their filters set properly, or, are have odd confederations or community settings that you don't see their announcement. Rather than blackhole those organizations, one normally has a default route pointed to a provider. A backbone provider would more likely run defaultless, a host or Internet Service Provider would normally run with a default route.

So, you run a traceroute on a network that has a default route, and it gets to the border to a provider that doesn't run defaults and the packet is dropped. The DoD isn't filtering these packets or making them disappear - the Internet doesn't know where they should go, and, since there is no default route, the packets are dropped at the first router that doesn't know how to route it.

I'll guess mindcrime is the original poster.

Actually, no. But the OP is a friend, and this showed up in my G+ feed earlier. I thought some HN people might either A. find it interesting and/or B. have an explanation.

Due to responses to multiple threads, I figure a single explanation should suffice, referenced to related portions. <snip />

That all sounds reasonable... but you'd think if somebody was going to squat on some IP address space, they'd pick somebody other than the DoD to mess with. :-)

Network engineers often make very arbitrary decisions with regards to IP numbering/renumbering.

RFC 4913 suggests using the current timestamp + the mac address of your machine, sha1 hashed and then taking the lower 40 bits to generate your Unique Local Address (ULA). An RFC that is specific about generating an arbitrary number.

I doubt much thought went into it - it was an unused, unannounced block that didn't conflict with their existing 10.0.0.0/8 network.

If the author wanted to look, the Via header is actually not a great place to look. It's not the most accurate header in terms of telling you where the call is being handled.

If you look inside the SDP's (usually in the INVITE and 200 OK, potentially 183/180 or ACK) it will tell you where the actual RTP traffic is going. If those RTP ports and addresses are changed something is certainly foul. My guess is they are not.

If you see a Record Route header it means some proxy has inserted itself into the signaling traffic. Or again, if the SDP inside SIP header is changed.

For reference, an SDP looks like this:

v=0 o=- 1996782469 1996782469 IN IP4 203.43.12.32 s=- c=IN IP4 203.43.12.32 t=0 0 m=audio 57076 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv

That all sounds reasonable... but you'd think if somebody was going to squat on some IP address space, they'd pick somebody other than the DoD to mess with. :-)

Actually I do that quite often as the DoD's IP allocations are fixed and well known. I figure that since nothing on my networks should ever be talking to the DoD anyway, the worst that will happen is that DoD spyware can no longer phone home. No big loss :)

Wait, maybe I shouldn't have said that on a public forum...

A very large network that will remain unnamed thought the same thing. They numbered all internal systems (20k+ devices) inside 50.0.0.0/8.

The DoD handed the block back to IANA in 1998, and in 2010 it was allocated for use.

Regarding using RFC 1918 blocks - some of the mid-to-large size carriers have, either due to their size or due to wasteful subnetting, fully used the available RFC1918 blocks and have begun using otherwise unrouted spaces such as the DoD subnets to continue addressing devices on their network. For example, in Canada, Rogers has begun to use the 7/8 subnet for CMTS addressing because the RFC1918 address space isn't large enough. I believe some carriers solve this by having topographically independent networks that re-use the RFC1918 space in different sections of the country, however not all carriers have done this.

Comcast went with IPv6. But it doesn't seem all that surprising that Rogers just annexed 7/8. ;-)

Judging by the subsequent posts on the guy's blog, I'm not so sure he is willing to buy into the explanation. I'm with cd34: ISP using unannounced DoD IP space. Happens on networks all across the world, all the time. No secret area-51 voip NSA black ops: just bad network policy.

Of course, that might just be what they WANT us to think. <dawns tinfoil hat>

Cell providers are known to break SIP on purpose on thier networks. Sometimes by inserting broken 'via' headers in the SIP packets.

The DOD IP is in the 28/8 range which is not in the global routing table. So the packets never reach DOD.

cd34 answered it adequately. If you want a fairly detailed explanation of how they actually monitor your telecommunications, check out James Bamford's The Shadow Factory:

http://en.wikipedia.org/wiki/The_Shadow_Factory

Hi folks. I'm Mark Turner, the blogger who discovered this situation.

Thanks to the help of a few folks who commented on my blog, I was able to learn that the 28.x.x.x IP was assigned to my phone's interface. Thus it appears Sprint has "borrowed" addresses from the DoD. Because SIP packets contain the source IP (unlike the other traffic from my phone) the internal IP was leaking through Sprint's NATting, causing my confusion. It's all harmless, though a good argument for moving to IPv6!

These posts are mainly good so that someone who actually knows networking will respond and tell them they are correct or incorrect.

The problem here is that to be sure I think you'd have to know both networking and internal network layouts of the cell providers.

In other words, there are missing pieces that make all explanations difficult to confirm or not.

Since the IP address assignment was updated in 2009, it seems unlikely that the address was transferred from the DoD to Sprint or some other intermediate ISP.

  "That’s what hackers do, you know."
  "I have my own VoIP system (remember, I’m a hacker)"

Did this irritate anyone else? It really distracted me from the article when the guy just _has_ to make sure we know he's a hacker because he bought a VoIP system and installed Google Voice on his smartphone.

Did this irritate anyone else? It really distracted me from the article when the guy just _has_ to make sure we know he's a hacker

To be fair, Mark probably had no idea this would show up on HN. I was the one who posted it here, not him. He probably thought his audience for this would be the same regular audience for his blog, which includes a lot of RTP locals who know him in person and know his background. In that context, those statements make perfect sense.

because he bought a VoIP system and installed Google Voice on his smartphone.

Nah, Mark's been hacking on Linux and Asterisk stuff a long time; and he's a sharp guy who definitely deserves the "hacker" appellation.

Mindcrime's correct. It's my blog: I write for me and nobody else. If you liked something, great. If not, there's plenty of other links here on HN. Knock yourself out.

In this case, I added those comments to my post so that a non-technical audience would better understand the mindset. Believe it or not, not everyone thinks the way we geeks do. :)

Reply on news.ycombinator.com