Slashdot Mirror
Researchers Probe Dark and Murky Net
umm qasr writes: "Security Focus has an interesting article on blocks of internet space that are hidden from most users, it is based on a survey by Arbor Networks. The most common 'invisible sites' being .mil, which seems is unintentional. The survey suggests others, which seem more sinister...using unused netblock addresses to send spam. It's a bit short on the details but interesting none the less."
>Its kinda crazy thinking about all the stuff thats out
>there that no one will ever see. I always figured
>anything sensative for military use would be stored on
>a proprietary government network
Might already be that way and we just don't know it. Talk about "dark netspace," nobody holds more of it than the US military... A bunch of class A's - 6.*, 7.*, 11.*, 21.*, 22.* - not to mention the smaller, uglier blocks. I imagine they could be running some sort of TOP-SEC-NET (or maybe SEC-PORN-NET) on one of these, unbeknownst to the outside world.
Shaun
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
Sorry 'bout the whoring..
Dark address space refers to globally unique IPs (ie. not private IPs as defined by the RFCs) that should be accessible from anywhere on the internet but are not due to one of many reasons. The two reasons I am most familiar with are:
/24 or longer masks). This means that unless there is an aggregrate route for that block that will get the packets there eventually, the IP is dark for people using that provider.
.mil
Route filtering.
To reduce the size of the routing table in the memory of their core routers, some providers throw away announcements of small blocks (say
Some providers also filter blocks that are listed by the one of allocators (ARIN, RIPE, APNIC) as not being allocated or are reserved for special use. The article infers that this is what happens to lots of
Black holed routes.
Sometimes, either intentionally or accidently, providers announce routes to blocks that they actually can't reach directly. This is usually a misconfiguration or done on purpose to null route blocks containing a host performing a DOS or some other network misdemeanour. This is usually a transient state.
hth
Marty
"I can't buy want I want because it's free. Can't be what they want because I'm me." -Corduroy, Pearl Jam
The Internet was never a military network. This seems to confuse many people buts its quite simple. ARPAnet was created to allow the computer science community to share resources since all the new CS departments in the 1960's were calling for more and more government funds to pay for bigger and faster computer systems. It was though that networking them would allow collaboration and sharing of big iorn machines. Futile hope I know 8)
The confusion is based on the fact that Paul Baran at RAND had designed a network which would have used inexpensive links with multiple redundancies to ensure that communications would not be disrupted in a command and control structure for the Nuclear deterant. This idea was also being developed seperately in the UK and called Packet Switching by Donald Davis at the UK National Physics Lab on the first system to use this technology. It was later used as a basis for ARPAnet.
The important point is that when the ARPAnet was created the inventors had never heard of the RAND report and the Air Force had turned down RANDs plan to build a test syestem. It was civilian to the core. However when the military absorbed ARPA to form DARPA the created a nonclassified system called MilNet. This came later and is not the same as saying the Internet is built on a military system
Ok that was my 2c's worth. Any comments?
Okay, first off, slow down. I actually know of some of the people involved in that article. Odds are, your intuition is right: They simply used the source address IP data and nothing more. It's fairly simple to get that from a mail server without compromising any of the actual mail content.
The ArborNetwork's crew is as white hat as they come.
- billn
In answer to your question- it depends, but certainly in some cases- yes.
Route-filters help address this, but many people don't do aggressive route filtering. Route filters, at least in this context, allow you to describe which route announcements you will accept from who. You typically write route-filters to *only* listen to route announcements for the networks that the person you are peering with owns. If its a multihomed connection then this can be a pain. If its an ISP (especially a multihomed one with multihomed customers) it becomes even more of a pain and becomes a matter of trusting your peers to enforce the right policies at the edge of their network. Some people do things with BGP communities to make this easier, but many folks do not have the clue to do so.
As mentioned earlier in the article, aggressive route filtering can actually increase the discontinuties in the network, but failing to do the right filtering can create opportunities for antisocial/malicious behavior.
There were attempts, with some success to create truly useful route registries- the radb's. MCI and someone else (I'm pretty sure it was the route-arbiter project folks- in which Abha [from this report] played a significant role) maintained these. Some people used these to auto-create route filters, but I think that all got just to darn complicated. I could be totally wrong about this, but that's my recollection.
Not to rant (to late), but to my way of thinking this all is rooted in a basic issue with large multi-entity IP networks- a peer isn't just someone you exchange traffic with for free [or with settlements] it really is a *peer*. By exchanging routing information (especially if you do something like accept/honor MED's) you really do have to trust these people- that means you have to believe they are as competent or moreso than yourself- in other works, a peer- in the truest sense of the word. With extremely democratic large scale IP networks (like the Internet) the meaning and usefullness of the term peer becomes significantly diluted- and this means that the network as a whole is likely to not function at a fully optimized state (or even a merely completely working state) all/most of the time. That isn't a horrible thing, but it certainly does make you reevaluate certain assumptions many people make about IP networks.
Further, I believe that most if not almost all of the "scaling" problems in the Internet today are not as much technical capability problems as configuration/design/education problems. We now have a giant, dynamic network that usually works quite well- can it fail catastrophically? I believe it *can*, but the size, interconnectiveness and diversity tends to locally contain failure conditions- events that would have been extremely catastrophic just a couple of years ago.
I'll stop "lecturing" now, except to say that it is great to see folks like these, CAIDA, Packet Design, and assorted others starting to really try to formalize analysis methods for networks of this complexity- its a great step forward from the cult-of-the-few-geeks (The Internet Routing Cabal wasn't that long ago- not to say they weren't great people who made lots of personal sacrifices to keep things working)
As a footnote, Craig L. and Abha A. have done other related work (before they were with Arbor Networks). I know they presented some of their work on BGP reconvergence time at the Montreal NANOG. I suspect they've presented since then.
http://www.nanog.org/mtg-9910/converge.html
I always figured anything sensative for military use would be stored on a proprietary government network
It's called SIPRNET, and is well protected.