You are here: Home > Publications > RIPE Labs > Manish Karir > First Impressions of Pollution in Two RIPE NCC Darknets

First Impressions of Pollution in Two RIPE NCC Darknets

Manish Karir — 21 Feb 2011
Contributors: Scott Walls
We partnered with several Regional Internet Registries (RIRs), including the RIPE NCC, to examine what traffic is going to unallocated IP address ranges. In this particular case, we looked at traffic going to 5/8 and 37/8.

Introduction

The IPv4 address space is nearing complete exhaustion. Very few /8s are left for allocation, and there are concerns as to whether these remaining /8s are even particularly useful to allocate. Because of this, we partnered with several Regional Internet Registries (RIRs), including the RIPE NCC, to examine what traffic is going to unallocated IP address ranges. Because these IP addresses are unallocated, we know that all traffic traveling into these spaces is pollution. This blog post details our initial findings from analyzing 7-days worth of data collection on the following networks: 5/8 and 37/8.

We found that small networks accounted for most of the pollution. In particular, we recommend cleanup or quarantine of the following networks:

  • 5.5.5.0/24
  • 5.113.105.0/24
  • 5.45.245.0/24
  • 5.123.252.0/24
  • 37.61.54.0/24

Also, we have found that in some occasions, certain events at a definite time account for a large amount of pollution. 

 

Goals and Methodology

Our main goals were to find out what kind of pollution, in what volumes, was going to each block of the Internet, and whether cleanup and quarantine are possible solutions.

Our methodology was as follows:

  • Contact the RIRs for Letters of Authorization (LOAs)
  • Temporarily advertise the network
  • Collect traffic
  • Analyze the data
  • Archive and present our findings to the public
  • Give cleanup/quarantine recommendations to the RIRs

 

Analysis of 5/8

To first get a handle on the data, we look at the cumulative distribution function (cdf) across all destination /24 networks in the /8. The cdf for the 5/8 network is shown in Figure 1.

Cumulative Distribution Function of Destination /24s in 5.0.0.0/8

Figure 1: Cumulative Distribution Function of Destination /24s in 5/8

We see from this graph that a small number of destination networks account for most of the traffic coming to 5/8. We know this, because if the destination addresses of traffic entering this subnet were evenly distributed, this graph would be perfectly diagonal from the origin to the upper right hand corner. Instead, we can see the slope on the left side, indicating that a few /24s contributing a high amount of traffic. We call this hotspotting , because the traffic is going to a few hot spots. Knowing this, it was natural for us to investigate exactly which subnets were sending the most traffic.

To do this, we created bar charts of the top ten /16 and /24 destination subnets (see Figure 2 and Figure 3 respectively).

Top Ten /16s in 5/8

Figure 2: Top Ten /16s in 5/8

 

Top Ten /24s in 5/8 Figure 3: Top Ten /16s in 5/8

 

To give a better sense of the data, here they are in a table, by average Mbps across the week:

Subnet (/24) Average Traffic (Mbps)
5.5.5.0/24 7.34
5.113.105.0/24 1.68
5.45.245.0/24 0.48
5.123.252.0/4 0.45
5.2.1.0/24 0.35

There are several important things to note about these two graphs. First, the “dropoff” is tremendous. That means, the vast majority of the traffic is going to a very small minority of the network. In fact, a single /24's traffic dwarfs that of the rest of the network . Therefore, we spent most of our time investigating the most popular /24s.

The 5.5.5.0/24 traffic can be mostly accounted for by large spikes, up to 250Mbps, of UDP packets, each one 250 bytes in length, and with random ports and source IPs, all to the IP address 5.5.5.5. These spikes are clearly visible in Figure 4 below showing traffic flow vs. time.

Traffic in Bytes by Protocol to 5.0.0.0/8

Figure 4: Traffic in bytes by protocol to 5/8

 

The large green spikes at times 50 and ~320 correspond to this 5.5.5.5 traffic.

The next highest traffic destination is 5.113.105.0/24. Upon inspection, we found mostly ICMPv6 packets traveling to this destination. Finally, 5.24.245.0/24 was receiving many packets whose payload seemed to link to Flash Video files .

 

Analysis of the 37/8

Again, our first step was to look at a cdf graph for 37/8 (see Figure 5).

Cumulative Distribution Function of Destination /24s in 37.0.0.0/8

Figure 5: Cumulative Distribution Function of Destination /24s in 37/8

As before, the hook on the far left side is strong evidence of hotspotting. Also, the kink in the graph at approximately 32,000 is evidence of traffic coming from the Conficker worm . Now we look at the top 10 destination networks, sorted by /16 and /24 (Figure 6 and 7). Top Ten /24s in 37/8

  Figure 6: Top Ten /24s in 37/8


Top Ten /24s in 37/8 Figure 7: Top Ten /24s in 37/8

 

 And, again, the tabular data:

Subnet (/24) Average Traffic (Mbps)
37.61.54.0/24 3.65
37.44.12.0/24 0.36
37.16.238.0/24 0.24
37.101.126.0/24 0.24
37.124.238.0/24 0.20

As you can see, again, most of the traffic is hitting a single /24. Looking into the traffic, we realized that the traffic to 37.61.54.0/24 is due to China blocking Facebook. You can see an example at the following link (you can even run your own query on Chinese DNS servers): http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml

The other subnets are negligible compared to 37.61.54.0, and are mostly from Conficker. To support this point, Figure 8 is showing the top destination ports on 37/8.

Top 20 TCP Destination Ports (by packets) to 37.0.0.0/8

Figure 8: Top 20 TCP destination ports (by packets) to 37/8

As you can see, port 445 (once again consistent with Conficker) is receiving the bulk of the damage.

Finally, we found one noteworthy event in 37/8, visible in Figure 9 showing traffic vs. time.

Traffic in Bytes by Protocol to 37.0.0.0/8

Figure 9: Traffic in bytes by protocol to 37/8


The spike in UDP traffic (at ~30 on the timescale) is visible across the entire network. On inspection, we found the spike to come from UDP source port 53, and we realized that the surge in traffic is  backscatter from a DNS Denial of Service (DoS) attack.

 

Comparison between the 5/8 and 37/8

There are some important differences between traffic going to 5/8 and traffic going to 37/8 as shown in graphs above: first, traffic to the most popular /24 network in 5/8 is twice as large as the traffic to the most popular /24 in 37/8. This skews the 5/8's cdf so that Conficker is less visible (although it is certainly still there). Because the traffic to 5.5.5.5 came in such large bursts, the graphs showing traffic vs. time also looked very different for 5/8 and 37/8.

One anomaly we noticed can be seen in Figure 10 and Figure 11 comparing TTL values of packets going to the two networks.

Packets per TTL Value for all Traffic to 5.0.0.0/8

Figure 10: Packets per TTL value for all traffic to 5/8

Packets per TTL Value for all Traffic to 37.0.0.0/8

Figure 11: Packets per TTL value for all traffic to 37/8

Note that in the 37/8, most traffic comes from TTLs around 100. These are most likely Windows hosts, who have a default TTL of 128. The smaller humps are below 64 (Linux and FreeBSD) and ~250 (Solaris or Cisco IOS). In the 5/8 range, however, there are large spikes at 32 and 250. 5/8 is receiving large amounts of traffic from Linux or FreeBSD hosts and Solaris hosts or Cisco Routers . This is atypical, and we do not yet have an explanation for it.

 

Conclusion

To recapitulate, we recommend cleanup or quarantine of the following networks:

  • 5.5.5.0/24
  • 5.113.105.0/24
  • 5.45.245.0/24
  • 5.123.252.0/24
  • 37.61.54.0/24

As next steps, we plan to dive deeper into analyzing the events, anomalies, and hotspots, so that we can further identify the root causes of the pollution. We hope that in doing so, we can be more helpful in the cleanup efforts.

 

Acknowledgments

This article has been submitted buy Manish Karir and Scott Walls, Research & Development, Merit Networks, Inc. 

3 Comments

Anonymous says:
21 Feb, 2011 03:15 PM
Hamachi.CC a mediated VPN software/service used 5.0.0.0/8 to address member nodes. It seems that this has been abandoned but grandfathered hosts if configuration hasn't been changed may still use these addresses.
Anonymous says:
22 Feb, 2011 12:21 PM
Just as interesting facts:

During a recent stay in a hotel in CA my public IP was 12.x.x.x. Someone else in a different hotel had one of the DNS resolvers pointing to 1.1.1.1.

Anonymous says:
27 Feb, 2011 03:19 PM
The Hamachi VPN software hasn't been abandoned but continues to be made available under LogMeIn brand still using the 5.0.0.0/8 netblock for it's addresses.
https://secure.logmein.com/UK/products/hamachi2/

Another similar product using the addresses in the same block is Comodo EasyVPN
http://www.comodo.com/home/email-security/vpn-access.php

In both cases I've tried asking the companies what they intend to do now that the 5.0.0.0/8 block has been assigned to RIPE but I've not had any official reply so far.
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.