169 |
In the end, however, we observe that there are only two approaches in which all modern Peer-to-Peer |
In the end, however, we observe that there are only two approaches in which all modern Peer-to-Peer |
170 |
systems fall: the loosely structured approach and the tightly structured approach. By structure, we refer to |
systems fall: the loosely structured approach and the tightly structured approach. By structure, we refer to |
171 |
the topology of the overlay network, i.e., how the connections between participating peers are created |
the topology of the overlay network, i.e., how the connections between participating peers are created |
172 |
and maintained. In the loosely structured approach the construction and the maintenance of the overlay is controlled |
and maintained. By data lookup model, we mean the methods which are used for finding data from the overlay. |
173 |
loosely. The placement of services and topology of the overlay is random. Data lookups in loosely structured systems are |
In the loosely structured approach the construction and the maintenance of the overlay is controlled |
174 |
|
loosely. The placement of services and topology of the overlay is random. The data lookup model in loosely structured systems is |
175 |
not very efficient, because of unstructured properties of the overlay. On the other hand, in the tightly structured |
not very efficient, because of unstructured properties of the overlay. On the other hand, in the tightly structured |
176 |
approach the overlay is constructed determistically, which all participating peers have to follow. The topology of the |
approach the overlay is constructed determistically, which all participating peers have to follow. The topology of the |
177 |
overlay and the placement of services is controlled tightly therefore enabling more scalable and efficient data lookups. |
overlay and the placement of services is controlled tightly therefore enabling more scalable and efficient data lookup model. |
178 |
|
|
179 |
In the following sections, we will discuss in more detail the properties of these approaches. |
In the following sections, we will discuss in more detail the properties of these approaches. |
180 |
|
|
496 |
to cope with billions of concurrent peers \cite{osokine02distnetworks}, \cite{kubiatowicz00oceanstore}. |
to cope with billions of concurrent peers \cite{osokine02distnetworks}, \cite{kubiatowicz00oceanstore}. |
497 |
|
|
498 |
To end user, the biggest difference between these systems is how data lookups are performed. Loosely |
To end user, the biggest difference between these systems is how data lookups are performed. Loosely |
499 |
structured systems provide a more rich and user friendly way of searching data than tightly structured systems |
structured systems provide more rich and user friendly way of searching data than tightly structured systems |
500 |
as they have a support for keyword searches. On the other hand, tightly structured |
as they have a support for keyword searches. Tightly structured |
501 |
systems support only exact key lookups as each data item is identified by globally unique keys. |
systems support only exact key lookups since each data item is identified by globally unique keys. |
502 |
|
|
503 |
In the end, both systems have open problems and issues. We will discuss these aspects more detail in |
In the end, both systems have open problems and issues. We will discuss these aspects more detail in |
504 |
chapter 3. Table \ref{table_comparison_approach} lists the key differences between the loosely structured |
chapter 3. Table \ref{table_comparison_approach} lists the key differences between the loosely structured |
592 |
\subsection{Algorithms} |
\subsection{Algorithms} |
593 |
|
|
594 |
Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer algorithms |
Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer algorithms |
595 |
and their key properties with regard to performance and scalability. List |
and their key properties with regard to performance and scalability. The list |
596 |
includes algorithms from both loosely and tightly structured approaches. The list doesn't |
includes algorithms from both loosely and tightly structured approaches. The list doesn't |
597 |
include \emph{all} proposed Peer-to-Peer algorithms. Only the ones which already have |
include \emph{all} proposed Peer-to-Peer algorithms. Only the ones which already have |
598 |
been widely deployed in real life, or the ones which may be promising in the future |
been widely deployed, or the ones which may be promising in the future |
599 |
Peer-to-Peer systems are included in this thesis. |
Peer-to-Peer systems are included in this thesis. |
600 |
|
|
601 |
We decided to follow the guidelines from \cite{kaashoek03koorde} in measuring |
We decided to follow the guidelines from \cite{kaashoek03koorde} in measuring |
607 |
Here, we describe the listed properties of Peer-to-Peer algorithms: |
Here, we describe the listed properties of Peer-to-Peer algorithms: |
608 |
|
|
609 |
\begin{itemize} |
\begin{itemize} |
610 |
\item \textbf{Lookup}: the number of messages required when a data lookup is performed |
\item \textbf{Lookup}: the number of messages required when a data lookup is performed. |
611 |
\item \textbf{Space}: the number of neighbors which peers knows about (neighbors) |
\item \textbf{Space}: the number of neighbors which peers knows about (neighbors). |
612 |
\item \textbf{Insert/delete}: the number of messages required when a peer joins or leaves the network |
\item \textbf{Insert/delete}: the number of messages required when a peer joins or leaves the network. |
613 |
\item \textbf{Number of network connections}: the number of concurrent network connections required to maintain correct neighbor information |
\item \textbf{Number of network connections}: the number of concurrent network connections required to maintain correct neighbor information. |
614 |
\end{itemize} |
\end{itemize} |
615 |
|
|
616 |
\scriptsize |
\scriptsize |
819 |
needed to make Peer-to-Peer systems more secure and efficient. |
needed to make Peer-to-Peer systems more secure and efficient. |
820 |
|
|
821 |
Both the loosely structured and the tightly structured approach have their own specific problems. |
Both the loosely structured and the tightly structured approach have their own specific problems. |
822 |
Since Napster \cite{napsterurl} and Gnutella \cite{gnutellaurl} were first introduced |
Since Gnutella \cite{gnutellaurl} was first introduced |
823 |
to the public, researchers' main concern has been the scalability problem of the loosely structured |
to the public, researchers' main concern has been the scalability problem of loosely structured |
824 |
approach. However, people often misunderstand the scalability problem of the loosely structured |
systems. However, people often misunderstand the scalability problem of the loosely structured |
825 |
approach; \emph{network} of loosely structured systems is scalable, but the \emph{data lookup model} is not. |
approach; \emph{the network overlay} of loosely structured systems is scalable, but the \emph{data lookup model} is not. |
826 |
The main concern of the tightly structured system is to make overlay's data lookup process |
The main concern of the tightly structured system is to make overlay's data lookup process |
827 |
more fault tolerant against hostile attacks. Other key problems in tightly structured |
more fault tolerant against hostile attacks. Other key problems in tightly structured |
828 |
systems are the lack of keyword searches, support for heterogeneous peers and load balancing |
systems are the lack of keyword searches, support for heterogeneous peers and load balancing |
829 |
\cite{balakrishanarticle03lookupp2p}. |
\cite{balakrishanarticle03lookupp2p}. |
830 |
|
|
|
To make Peer-to-Peer systems even more popular (e.g., in industry), Peer-to-Peer domain |
|
|
needs better infrastructures to deal with security issues. Some research has been done regarding |
|
|
anonymity, access control, data availability and data integrity but as |
|
|
we state in the following sections, much more research work is required to solve these issues. |
|
|
|
|
831 |
\section{Security problems in Peer-to-Peer} |
\section{Security problems in Peer-to-Peer} |
832 |
|
|
833 |
In this section we discuss security problems related to Peer-to-Peer domain. |
In this section we discuss security problems related to Peer-to-Peer domain. |
834 |
|
|
835 |
\subsection{Attacks} |
\subsection{Attacks} |
836 |
|
|
837 |
There are five known attack models against Peer-to-Peer systems: Sybil attack \cite{douceur02sybil}, |
There are five known attack models against Peer-to-Peer systems: the Sybil attack \cite{douceur02sybil}, |
838 |
Fail-stop attack, Spam attack \cite{naor03simpledht}, Byzantine attack \cite{357176} and \cite{296824}, and |
the Fail-stop attack, the Spam attack \cite{naor03simpledht}, the Byzantine attack \cite{357176} and \cite{296824}, and |
839 |
general Distributed Denial of Service attack. |
the Distributed Denial of Service attack. |
840 |
|
|
841 |
In Sybil attack model, a hostile entity presents multiple |
In the Sybil attack model \cite{douceur02sybil}, a hostile entity presents multiple |
842 |
entities. Therefore, one hostile entity can control a large fraction of the Peer-to-Peer system. Possible solution to |
entities. Therefore, one hostile entity can control a large fraction of Peer-to-Peer system. Possible solution against |
843 |
Sybil attack would be that the system could distinguish entities of the system reliably. Unfortunately, |
the Sybil attack would be that the system could distinguish entities of the system reliably. Unfortunately, |
844 |
currently there are no realizable techniques for this task. Partial solutions for Sybil attack is to replicate |
currently there are no realizable techniques for this task. Partial solutions for the Sybil attack is to replicate |
845 |
and fragment data randomly among several participating peers. However, both suggestions assume that two different |
and fragment data items randomly among several participating peers. However, this suggestion assumes that two different |
846 |
remote entities are actually different; Sybil attacks are still possible and therefore would need centralized |
remote entities are actually different; Sybil attacks are still possible and therefore would need centralized |
847 |
authority for reliable authentication. As the author argues in \cite{douceur02sybil}, without centralized authority, |
authority for reliable authentication. As the author argues in \cite{douceur02sybil}, without centralized authority, |
848 |
Sybil attacks are always possible in a Peer-to-Peer system except under extreme and unrealistic assumptions of |
Sybil attacks are always possible in a Peer-to-Peer system except under extreme and unrealistic assumptions of |
849 |
resource parity and coordination among entities. |
resource parity and coordination among entities. |
850 |
|
|
851 |
In random fail-stop model, cited in \cite{naor03simpledht}, a faulty peer is deleted from the Peer-to-Peer system. |
In the Fail-stop attack model, cited in \cite{naor03simpledht}, a faulty peer is deleted from the Peer-to-Peer system. |
852 |
The reason for the faultiness of a peer can be a software failure, a hostile attack, or an external threat such as virus or |
The reason for the faultiness of a peer can be a software failure or a hostile attack. |
853 |
trojan. The Byzantine attack model \cite{357176} closely related to fail-stop model. Byzantine model can be seen as more |
The Byzantine attack model \cite{357176} is closely related to Fail-stop model. Byzantine model can be seen as more |
854 |
severe than fail-stop model as there are no restrictions over the behavior of faulty peers. Practical but partial |
severe than Fail-stop model as there are no restrictions over the behavior of faulty peers. A practical |
855 |
solution for Byzantine failures has been proposed by Castro et al. \cite{296824}. |
solution for the Byzantine failures have been proposed by Castro et al. \cite{296824}. |
856 |
|
|
857 |
Spam generating attack is another known attack model against Peer-to-Peer system. In Spam |
The Spam generating attack \cite{naor03simpledht} is an another known attack model against Peer-to-Peer system. In the Spam |
858 |
attack, a hostile or faulty peer may produce false information of the data, or refuses to (or is not able to) reply to requests. |
attack, a hostile or faulty peer may produce false information of the data, or refuses to (or is not able to) reply to requests. |
859 |
Possible solution against this attack is that peer should not trust a single entity. Instead, a peer should get |
Possible solution against this attack is that peer should not trust a single entity. Instead, a peer should get |
860 |
information from multiple entities and trust on the majority's opinion. This method requires more messages to be |
information from multiple entities and trust on the majority's opinion. This method requires more messages to be |
862 |
the previously mentioned solution doesn't work. Naor et al. \cite{naor03simpledht} have proposed a partial solution against Spam attack |
the previously mentioned solution doesn't work. Naor et al. \cite{naor03simpledht} have proposed a partial solution against Spam attack |
863 |
in \emph{faulty} peer environment (not hostile). |
in \emph{faulty} peer environment (not hostile). |
864 |
|
|
865 |
Traditional overloading of targeted peers is the best known form of distributed Denial of Service attack (DDoS). For example, |
Traditional overloading of targeted peers is the best known form of distributed Denial of Service attack (DDoS) (see, e.g., \cite{372148}). |
866 |
a hostile entity can attempt to burden targeted peers with garbage network packets. As an implication, peers may act |
For example, a hostile entity can attempt to burden targeted peers with garbage network packets. As an implication, peers may act |
867 |
incorrectly or stop working. DDoS attack may be very severe, especially if the rate of replication and caching |
incorrectly or stop working. The DDoS attack may be very severe, especially if the rate of replication and caching |
868 |
in the Peer-to-Peer system is low. This may lead to data loss in the Peer-to-Peer system. Daswani et al. |
in the Peer-to-Peer system is low. This may lead to data loss in the Peer-to-Peer system. Daswani et al. |
869 |
\cite{daswani02queryflooddos} suggest efficient load balancing |
\cite{daswani02queryflooddos} suggest efficient load balancing |
870 |
policies for Peer-to-Peer system in order to prevent massive system failures. Sit et al. \cite{sit02securitycons} |
policies for Peer-to-Peer system in order to prevent massive system failures. Sit et al. \cite{sit02securitycons} |
871 |
suggest that identifier assignment algorithm for peers would assign identifier with respect to network topology |
suggest that identifier assignment algorithm for peers would assign identifier with respect to network topology |
872 |
and replicas should be located physically to different locations. |
and replicas should be located physically to different locations. |
873 |
|
|
874 |
As stated in \cite{naor03simpledht}, an important aspect is that when it comes to general security aspects and |
As stated in \cite{naor03simpledht}, an important aspect is that when it comes to different attack models in |
875 |
Byzantine faults in any Peer-to-Peer system, there should be a clear distinction between attacks on the |
any Peer-to-Peer system, there should be a clear distinction between attacks on the |
876 |
algorithms assuming the construction of the overlay is correct, and attacks on the construction itself. Clearly, Sybil |
algorithms assuming the construction of the overlay is correct, and attacks on the construction itself. Clearly, Sybil |
877 |
and Spam attacks belong to the first category, and the rest of the attacks to the latter category. |
and Spam attacks belong to the first category, and the rest of the attacks to the latter category. |
878 |
|
|