BCP38 making it work, solving problems

Suresh Ramasubramanian suresh at outblaze.com
Wed Oct 13 12:07:32 UTC 2004

Randy Bush wrote:
>> For the week starting Sept 12, our dark space telescope "saw" 1675
>> spoofed DDOS attacks.
> any idea why someone(s) is ddosing dark space?  seems a bit silly.

Something like this I rather fancy ...


> [Planetlab-announce] network telescope Larry Peterson llp at
> CS.Princeton.EDU Thu Apr 15 16:31:24 EDT 2004
> * Previous message: [Planetlab-announce] Cambridge meeting * Messages
> sorted by: [ date ] [ thread ] [ subject ] [ author ]
> I have a request to make of PlanetLab sites... There is an effort 
> underway to collect information about worms, ddos backscatter, and
> other suspect activity on the Internet. Our ability to do this sort
> of analysis would be greatly enhanced by having access to IP address
> blocks spread across the Internet, for example, at as many PlanetLab
> sites as possible. My specific request is for sites to contribute
> blocks of, say, 16 otherwise unused addresses to PlanetLab. I have
> attached a note from Vern Paxson outlining the idea, a so called
> "network telescope". Please let me know if your site would be willing
> to contribute (assign) some number of addresses to PlanetLab for this
> purpose.
> Larry
> ------------------------------
> A basic challenge for analyzing Internet-scale malicious phenomena
> such as worms and automated scanning is acquiring sufficiently broad
>  visibility into their workings.  Monitoring at a single location may
> for example miss the early stages of a worm's spread or, more
> generally, lack the diverse perspectives necessary for capturing
> large-scale behavior.
> A powerful tool for acquiring such broader visibility is a "network 
> telescope".  Network telescopes monitor traffic sent to communication
>  dead-ends such as unallocated portions of the IP address space or
> ports on endhosts for which no server is listening.  Since there is
> no legitimate reason for a host to send packets to those
> destinations, such traffic provides strong evidence of malicious
> activity - including DDoS backscatter, port scanning, and probe
> activity from worms.
> Our goal is to build a large-scale telescope with significantly more 
> sampling breadth and diversity than current telescopes.  This
> telescope will be structured as two layers.  Its front-end sensors
> will be spread across a large number of address blocks and monitoring
> points to achieve sampling diversity.  We'll use both unallocated
> address blocks (which attackers can learn about fairly easily) but
> also unused subblocks within allocated blocks. This latter "dark
> address space" is much more difficult for an attacker to learn about
> and also enables highly diverse distribution of the sensors.
> It's this latter that we're hoping can be done in conjunction with PL
>  nodes.  In particular, the way we picture it working is that the PL
>  nodes will have multiple addresses assigned to them. A monitor
> running on the host then tunnels traffic it receives on the extra
> addresses over to the analysis point.  It could also tunnel traffic
> sent to its "normal" address but for which there's no listener.
> One crucial issue with building a large telescope is *filtering*.
> For a very large telescope, the volume of data collected can be
> enormous. However, for many forms of analysis we can often filter out
> a great deal of the traffic.  For example, for worm detection we can
> drop traffic seen by the sensor rather than forwarding it if the
> traffic does not correspond to worm activity of possible interest
> (e.g., it's instead DoS backscatter, or activity from known worms).
> Because PL nodes can do computation before they forward traffic over
> the tunnel (unlike, for example, telescope sensors based on using
> routers), they make ideal platforms for developing such filtering.

More information about the NANOG mailing list