This paper indicates that p2p systems are very weak in security aspect.
Even without the Sybil attack, either the routing table attack or message
forward attack can make a p2p system disability. Unfortunately, none of
methods proposed can completely solve these security holes. Thus, security
weakness sounds an inherent feature accompanying with p2p systems.
The methods presented in this paper to enhance security could reduce
system performance, and bring more complexity in system design. For
example, solving puzzle, and periodically changing id will degrade the
performance of the node join operation; second routing by constrained
routing table and diverse routing could greatly increase system overhead
when system is in normal states; and fault tests increases the
design complexity of system. More importantly, at the cost of these
performance degradation and design complexities, simulation results show
that the system can tolerate up to 25% malicious nodes. This is not a very
satisfying result.
One of the nice features of p2p system is its good scalability in
performance. So we argue should we enhance its security level by
sacrificing its performance. Maybe we only apply p2p system to
applications which is not critical in security. For instance, we use p2p
system to do TV streaming. It is not a big deal if a person cannot watch
TV online for a while. We can use p2p system to store movies, music, and
softwares since even these files are lost in p2p hosts, there are usually
other backups available. If we really want to use p2p system for security
critical applications, we could use p2p as a cache providing good
performance, and use a central solution as a backup when attacks happen.
Another possible way to mitigate these security problems is that we may
propose some fast recover techniques for p2p system in case of system
disabilities happen. On the other hand, we should well protect the
information of users and the content of messages if necessary, so that we
can reduce the incentives of attackers in some degree.
Received on Thu Nov 17 2005 - 09:20:28 EST
This archive was generated by hypermail 2.2.0 : Thu Nov 17 2005 - 09:27:12 EST