Misconfigured Addresses Created by P2P Clients:
One of the Largest Growing Causes of Internet Background Radiation
James Yoder
Columbus State University
Columbus, GA, USA
Abstract—“In 2004, in a tier-1 ISP [Internet Service Provider],
P2P [Peer 2 Peer] file sharing accounted for more than 60% of
traffic in the USA and more than 80% of the traffic in Asia.” [5]
“According to a survey conducted by ipoque (a German provider
of deep packet inspection solutions for Internet traffic
management and analysis), P2P dominates the Internet with 5090% traffic arising from P2P applications. Statistics from
Chinese sources reveal that P2P traffic currently accounts for
70% of China’s total network traffic.” [8]
With these high statistics, one has to wonder, “Is all of this P2P
traffic getting to its intended destination?” If you do a search for
Internet Background Radiation (IBR), you won’t find much
information even though it is a well-known problem in the
networking field.[2] “[IBR] can be analyzed using a so-called
network telescope. Traffic destined to an other-wise unused
network is dissected and analyzed for anomalies as well as worm
propagation, DDOS attacks and whatnot.” [8]
I.
INTRODUCTION
“Background
radiation
reflects
fundamentally
nonproductive traffic, either malicious (flooding backscatter,
scans for vulnerabilities, worms) or benign (misconfigurations).
While the general presence of background radiation is well
known to the network operator community, its nature has yet to
be broadly characterized.” [2]
In 2007, [1] was authored, shining a light on misconfigured
addresses caused by P2P software. It stated that 38.9% of all
IBR could be attributed to P2P misconfigured addresses and
was growing by at least 100% over each of the four years prior
to the paper’s publishing.
They were the only researchers known to be conducting the
study at the time, and no one seems to have written a paper on
the topic since. They had to discontinue collecting data in the
manner they were because the RIAA (Recording Industry
Association of America) accused them of distributing copywritten material. Assuming they were correct and the growth
rate didn’t change after the paper was authored, then this is
definitely a serious and relevant issue.
It is possible that the paper made an impact on the industry
that alleviated the problem. It could have made naïve
programmers aware of the problem his/her program may
contribute if certain measures are not taken. It could have also
made the malicious coders aware that people realized what they
were doing and were actively pursuing a solution causing them
to find other means to accomplish their task.
On the other hand, if the paper had no direct impact on the
problem and the growth rate continued at what they proposed,
then around 63.2 gigabits per second (gbps) of internet traffic is
background noise that can be attributed solely to misconfigured
IP addresses from P2P software.
We can calculate the total IBR at the time of the paper.
IBR caused by misconfigured IP addresses from P2P software
(7.9 gbps) and the percentage of the total IBR (38.9%) are
indicated in the source paper:[1]

7.9 gbps / 38.9% = 20.3 gbps

We can now say that the total background noise at the time
of the paper was around 20.3 gigabits per second. This means
that the current amount of traffic going to misconfigured
addresses would be more than three times the total IBR when
the paper was authored. It is implied that the total amount of
IBR is generally static (in terms of the number of connections
per year). [1] It is understood that the overall amount of IBR
would have to grow as the amount of P2P misconfigured
addresses grows.
Once the authors of [1] identified which versions of each
program that were causing the most misconfigured addresses,
they diagnosed what was causing the problem and reported it to
the developers.
Section 2 identifies related work. Section 3 outlines my
proposed solution to the problem. Section 4 concludes this
paper.
II.
RELATED WORK
I was able to find papers on IBR and studies that track it
and analyze it.[2][3] Many papers focused on whether the data
sent by P2P software was indeed the data requested which is a
completely separate issue to the topic discussed in this paper.
Reference [4] focused on traffic sent to unused or
unreachable IP addresses, but not necessarily from P2P
applications.
Reference [5] covers index poisoning in P2P networks.
“To describe this attack, recall that most P2P file sharing
systems have indexes, allowing users to discover locations (IP
addresses and port numbers) of desired content.” “The index
poisoning attack is done by inserting massive numbers of
bogus records into the index.”
Reference [6], which was authored in June 2010, was a
good update on the status of IBR and how its profile has
changed over the past few years. Their findings agree with the
status of IBR found in the source paper. “This translates into
roughly 100% growth [of IBR] over the last four years. It is
interesting to note that this rate of growth is nearly twice that of
productive Internet traffic which is currently exhibiting 50%
year over year growth rates.” One of the unused networks they
monitor saw IBR rates up to150 gbps.[6]
household’s bandwidth be throttled if one child decides to
knowingly use software that contains bugs that cause these
issues? Should someone who is using the software for legal
purposes, but unaware of the bugs be punished?
3) What would stop an ISP from falsifying reports for
personal reasons? There are many other questions along this
same thought pattern. While this solution may make it easier
for someone that works at the ISP to harass clients, the
capability is already in place.
A) Test P2P Software
4) This solution relies on ISPs to hold their clients
accountable. It will not work if ISPs do not enforce the
solution or purposefully allow offenders to continue.
Since P2P misconfigured addresses are such a large part of
IBR, it would be good for a group of testers ensure that all
popular P2P software doesn’t have any address bugs similar to
those identified in [1]. A list could be maintained of all
software that contains these bugs and made available so that
users realize that they could be contributing to network
congestion just by using that specific application.
5) Offenders could make the argument that they are paying
for the ISPs service just as everyone else does and they should
be allowed to send data wherever they desire, even if it is not
expected to actually arrive anywhere. While I’m not aware of
any law that requires all data to have a destination, I do not see
how it would be beneficial to allow this type of usage
(especially on the scale we are experiencing).
B) ISP Monitoring
6) It is possible that new assigned addresses might not get
updated in the filtering part of the solution and valid packets
don’t get forwarded as they should. This would theoretically
never occur and cases would be very rare. DNS is able to
maintain an accurate listing of available domains and
hostnames. Maintaining a list of invalid addresses would be
equally difficult.
III.
SOLUTION
ISPs would benefit from not allowing clients to contribute
to the overall IBR. It would allow their network to run more
smoothly. It would also clear bandwidth for valid data
requests, thus making their clients happier and more likely to
stay with the provider.
ISPs should monitor usage of each client. Any large spikes
should be analyzed to ensure it is valid traffic. Data being sent
to addresses that don’t exist should be logged and reported.
Users that repeatedly abuse ISP resources should be
investigated further and potentially throttled or completely
removed.
REFERENCES
[1]
[2]
C) Address Filtering
Also, a list of invalid addresses could be maintained much
like the Dynamic Name System looks up hostnames. All
packets that are destined for these addresses would not be
forwarded.
Instead, the sender would be flagged for
investigation. If the client is a multiple offender, then the
account would be turned off. The user would be contacted
immediately to clear up what is causing the problem. If he/she
can remedy the situation, then the account will be unlocked.
Otherwise, it would be forwarded to the proper authorities.
IV.
CONCLUSION
[3]
[4]
[5]
[6]
The proposed solution presents a few issues:
1) There are privacy issues associated with ISPs monitoring
client usage. The ISP could just monitor the amount of traffic
and type as opposed to specifics. Any suspicious traffic could
be reported and/or forwarded to the proper authorities. The
closest thing to internet police in the United States of America
as of today would include: the Department of Defense’s Cyber
Command, the Department of Homeland Security’s
Cybersecurity division, and the Department of Justice’s
Computer Crime & Intellectual Property Section.
2) Is it fair to punish those who are unaware that they are
part of the problem?
For example, should an entire
[7]
[8]
[9]
Z. Li, A. Goyal, Y. Chen, and A. Kuzmanovic, “Measurement and
diagnosis
of
address
misconfigured
P2P
traffic,”
<http://networks.cs.northwestern.edu/publications/misconfig.pdf>
R. Pang, V. Yegneswaran, P. Barford, V. Paxson, and L. Peterson,
“Characteristics
of
internet
background
radiation,”
<http://conferences.sigcomm.org/imc/2004/papers/p27-pang.pdf>
P. Barford, R. Nowak, R. Willett, and V. Yegneswaran, “Toward a
model for source addresses of internet background radiation,”
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.8646&rep
=rep1&type=pdf>
E. Cooke, M. Bailey, F. Jahanian, and R. Mortier, “The dark oracle:
perspective-aware unused and unreachable address discovery,”
<http://www.usenix.org/events/nsdi06/tech/full_papers/cooke/cooke_ht
ml>
J. Liang, N. Naoumov, K. Ross, “The index poisoning attack in P2P file
sharing
systems,”
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.81.3640&rep
=rep1&type=pdf>
E. Wustrow, M. Karir, M. Bailey, F. Jahanian, and G. Houston, “Internet
background
radiation
revisited,”
<http://www.eecs.umich.edu/techreports/cse/2010/CSE-TR-564-10.pdf>
X. Huangcheng, “How to operate--solving the P2P puzzle,”
<http://www.huawei.com/publications/view.do?id=3289&cid=5680&pid
=61>
“Monitoring
internet
background
radiation”
<http://wiki.whatthehack.org/index.php/Monitoring_Internet_Backgroun
d_Radiation>
DoD
Cyber
Command
Website,
<http://www.defense.gov/home/features/2010/0410_cybersec/>