960 |
\subsection{Access control} |
\subsection{Access control} |
961 |
|
|
962 |
Any distributed computing system must support different levels of access control. For instance, in a Peer-to-Peer |
Any distributed computing system must support different levels of access control. For instance, in a Peer-to-Peer |
963 |
system, we may want to restrict the accessibility of data to only limited amount of participating peers. Yet, Peer-to-Peer |
system, we may want to restrict the accessibility of data to the limited amount of participating peers. Yet, Peer-to-Peer |
964 |
systems do not have a working and distributed access control scheme. Moreover, |
systems do not have a working access control scheme. Moreover, |
965 |
there has been a lot of violations of copyright laws by users of Peer-to-Peer file sharing systems. As a |
there have been lot of violations of copyright laws by users of Peer-to-Peer file sharing systems. As a |
966 |
consequence, some law suits have been filed against the companies who have build popular file-sharing programs. |
consequence, some law suits have been filed against the companies who have build popular file-sharing programs. |
967 |
|
|
968 |
To our knowledge, Nejdl et al. \cite{nejdl03accesscontrol} have very recently proposed the first practical solution to access |
Nejdl et al. \cite{nejdl03accesscontrol} have very recently proposed a practical solution to access |
969 |
control problem in Peer-to-Peer systems. They use Resource Description Framework (RDF) \cite{w3rdfurl} based |
control problem. They use Resource Description Framework (RDF) \cite{w3rdfurl} based |
970 |
schema policies to restrict access to certain data. Unfortunately, their current early prototype version only works in |
schema policies to restrict access to certain data. Their current early prototype version only works in |
971 |
loosely structured systems. |
loosely structured systems. |
972 |
|
|
973 |
|
|
974 |
\subsection{Hostile entities} |
\subsection{Hostile entities} |
975 |
|
|
976 |
One serious problem in Peer-to-Peer systems is the inability to identify hostile entities as trustworthy. |
One serious problem in Peer-to-Peer systems is the inability to identify hostile entities. |
977 |
Possible solutions include self-monitoring systems \cite{zhang03somo}, maintaining system invariants as |
One possible solution is to use a self-monitoring system, such as SOMO \cite{zhang03somo}, in which a self-monitoring overlay |
978 |
proposed in \cite{sit02securitycons}, distributed and secure peer identifier assignment |
constantly analyses the Peer-to-Peer overlay. Self-monitoring overlay is built on top of Peer-to-Peer overlay. Authors in |
979 |
\cite{castro02securerouting}, \cite{clarke00freenet} and self-certifying data using cryptographic |
\cite{sit02securitycons} suggest the use of system invariants. They emphasize that system invariants should be veriable, and if |
980 |
content hashes (e.g., SHA-1 \cite{fips-sha-1}). Identification of hostile entities is essential in the tightly structured |
system invariants fail the system must have a recovery mechanism. In distributed peer identifier assignment \cite{castro02securerouting, clarke00freenet}, |
981 |
|
multiple participating peers participate in a creation of peer identifier. Identification of hostile entities is essential in the tightly structured |
982 |
approach, in which the fundamental (and implicit) assumption is that there is a random, uniform distribution |
approach, in which the fundamental (and implicit) assumption is that there is a random, uniform distribution |
983 |
of peer identifiers that cannot be controlled by a hostile entity. |
of peer identifiers that cannot be controlled by a hostile entity. |
984 |
|
|
990 |
|
|
991 |
\subsection{Secure query routing} |
\subsection{Secure query routing} |
992 |
|
|
993 |
Much work has been done on secure routing, especially related to tightly structured systems. In |
By secure routing, we mean that a Peer-to-Peer system is able to deliver a network message |
994 |
\cite{castro02securitystructured} and \cite{castro02securerouting}, authors suggest the use |
thoughout the overlay to a correct destination. |
|
of constrained routing tables and diverse routes, and the detection of faults during data lookup routing. |
|
|
Additionally, authors present in \cite{castro02securerouting} an important aspect of the tightly structured approach with regard |
|
|
to fault tolerant query routing: the probability of routing successfully between to arbitrary |
|
|
correct peers, when a fraction $f$ of the other peers are faulty or hostile, is only $(1-f)^{h-1}$, where |
|
|
$h$ is the number of hops in the overlay. |
|
|
|
|
|
Sit and Morris \cite{sit02securitycons} discuss the possibility of allowing the query originator |
|
|
to observe lookup progress and cross-check routing tables using random queries. However, their |
|
|
approach is not very efficient, since this method creates lot of additional network traffic when |
|
|
in function. |
|
|
|
|
|
Additionally, Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure routing table |
|
|
maintenance, but their solution seems to have two major problems \cite{castro02securitystructured}. First, |
|
|
the solution is very expensive even without faulty or hostile entities. Second, each group of replicas |
|
|
in their solution must have less than 1/3 of its peers faulty. Thus, this feature results in a low |
|
|
probability of successful routing. |
|
995 |
|
|
996 |
Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al. in \cite{kaashoek03koorde} formally |
Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al. in \cite{kaashoek03koorde} formally |
997 |
prove the lower and upper bounds for the space requirements of locating a specific data item in a |
prove the lower and upper bounds for the space requirements of locating a specific data item reliable in a |
998 |
Peer-to-Peer system. They show that to provide high degree of fault tolerance and efficiency in the system, each |
Peer-to-Peer system. They show that to provide high degree of fault tolerance and efficiency in the system, each |
999 |
participating peer must maintain average of $O(\log{n})$ neighbors. |
participating peer must maintain average of $O(\log{n})$ neighbors. Fiat et al. in \cite{fiat02censorship, saia02dynamicfaultcontentnetwork} |
1000 |
|
and Datar in \cite{datar02butterflies} propose a tightly structured overlay with analytical results in the |
1001 |
Fiat et al. in \cite{fiat02censorship, saia02dynamicfaultcontentnetwork} and Datar in \cite{datar02butterflies} |
presence of hostile entities. However, none of these proposals address a dynamic tightly structured |
1002 |
describe a tightly structured overlay with analytical results in the presence of hostile entities. However, |
overlay with fault tolerance against multiple rounds |
|
none of these proposals address a dynamic tightly structured overlay with fault tolerance against multiple rounds |
|
1003 |
of hostile attacks. Also, above mentioned proposals are not very efficient. In \cite{fiat02censorship}, each peer |
of hostile attacks. Also, above mentioned proposals are not very efficient. In \cite{fiat02censorship}, each peer |
1004 |
must maintain information of $O(\log^3{n})$ other peers, and in \cite{datar02butterflies}, $O(\log^2{n})$ is required. |
must maintain information of $O(\log^3{n})$ other peers, and in \cite{datar02butterflies}, $O(\log^2{n})$ is required. |
1005 |
|
|
1006 |
Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing, gavoille01routing} list several open problems |
Authors argue in \cite{castro02securitystructured} that with the combination of |
1007 |
regarding routing in distributed networks. Obviously, more research is required in order to provide secure |
secure peer identifer assignment, secure routing table maintenance and secure message forwarding |
1008 |
data lookup routing in Peer-to-Peer networks. |
the secure routing in tightly structured systems is possible. Additionally, authors cite in \cite{castro02securerouting} |
1009 |
|
that the probability of routing successfully between to arbitrary |
1010 |
|
correct peers is $(1-f)^{h-1}$, when a fraction $f$ of the other peers are faulty or hostile and where |
1011 |
|
$h$ is the number of hops in the overlay. Sit and Morris \cite{sit02securitycons} discuss the possibility of |
1012 |
|
allowing the query originator to observe lookup progress and cross-check routing tables using random queries to achieve |
1013 |
|
secure routing in tightly structured overlay. However, their |
1014 |
|
approach is not very efficient, since this method creates lot of additional network traffic when |
1015 |
|
in function i.e., it is unknown if this techique is realizable in a efficient way. |
1016 |
|
Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure routing table |
1017 |
|
maintenance, but their solution seems to have two major problems according to \cite{castro02securitystructured}. |
1018 |
|
First, the solution is very expensive even without faulty or hostile entities. Second, each group of replicas |
1019 |
|
in their solution must have less than 1/3 of its peers faulty. Thus, this feature results in a low |
1020 |
|
probability of successful routing. |
1021 |
|
|
1022 |
|
Finally, Gavoille \cite{gavoille01routing} lists open problems in general distributed systems |
1023 |
|
(not only in Peer-to-Peer domain). |
1024 |
|
|
1025 |
\subsection{Other security threats} |
\subsection{Other security threats} |
1026 |
|
|
1028 |
the list includes viruses and trojans. Currently, there are not even partial solutions |
the list includes viruses and trojans. Currently, there are not even partial solutions |
1029 |
to the problems mentioned above. The reason for this is that there are no experience about these kinds of |
to the problems mentioned above. The reason for this is that there are no experience about these kinds of |
1030 |
attacks. Possible solution would be a distributed anti-virus software, but much more intensive research is required until |
attacks. Possible solution would be a distributed anti-virus software, but much more intensive research is required until |
1031 |
this kind of solution would be applicable. |
this kind of solution would be applicable. |
1032 |
|
|
1033 |
|
\subsection{Summary} |
1034 |
|
|
1035 |
|
In this subsection we list security problems in Peer-to-Peer systems in the table. |
1036 |
|
|
1037 |
|
|
1038 |
|
\scriptsize |
1039 |
|
\begin{longtable}{|l|l|l|l|} |
1040 |
|
|
1041 |
|
\hline |
1042 |
|
\multicolumn{1}{|c|}{\textbf{Problem}} & |
1043 |
|
\multicolumn{1}{c|}{\textbf{Problem description}} & |
1044 |
|
\multicolumn{1}{c|}{\textbf{Solutions}} & |
1045 |
|
\multicolumn{1}{c|}{\textbf{Comments/Status}} |
1046 |
|
\\ \hline |
1047 |
|
\endfirsthead |
1048 |
|
|
1049 |
|
\multicolumn{4}{c}% |
1050 |
|
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
1051 |
|
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
1052 |
|
\multicolumn{1}{c|}{\textbf{Problem description}} & |
1053 |
|
\multicolumn{1}{c|}{\textbf{Solutions}} & |
1054 |
|
\multicolumn{1}{c|}{\textbf{Comments/Status}} |
1055 |
|
\\ \hline |
1056 |
|
\endhead |
1057 |
|
|
1058 |
|
\endfoot |
1059 |
|
|
1060 |
|
|
1061 |
|
|
1062 |
|
\parbox{90pt}{Query routing \cite{sit02securitycons, aspnes02faultrouting, castro02securerouting, ratnasamy02routing, gavoille01routing, |
1063 |
|
lynch02atomicdataaccess, fiat02censorship, saia02dynamicfaultcontentnetwork, datar02butterflies}} & |
1064 |
|
\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} & |
1065 |
|
\parbox{110pt}{Query monitoring, cross check routing tables, verify routing tables, create routing table invariants} & |
1066 |
|
\parbox{110pt}{Increases system complexity} |
1067 |
|
\\ \hline |
1068 |
|
|
1069 |
|
|
1070 |
|
\parbox{90pt}{DoS attack \cite{sit02securitycons, saia02dynamicfaultcontentnetwork, datar02butterflies, daswani02queryflooddos, juels99clientpuzzles}} & |
1071 |
|
\parbox{110pt}{Distributed, controlled burden against specific computer(s)} & |
1072 |
|
\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic models, replication} & |
1073 |
|
\parbox{110pt}{Only partial solutions, traffic models most effective} |
1074 |
|
\\ \hline |
1075 |
|
|
1076 |
|
|
1077 |
|
\parbox{90pt}{Sybil attack \cite{douceur02sybil, castro02securerouting}} & |
1078 |
|
\parbox{110pt}{Single hostile entity presents multiple entities} & |
1079 |
|
\parbox{110pt}{Identify all peers simultaneously across the system, collect pool of peers which are validated, distributed peer ID creation} & |
1080 |
|
\parbox{110pt}{Not practically realizable, research focused on persistence, not on identity distinction} |
1081 |
|
\\ \hline |
1082 |
|
|
1083 |
|
|
1084 |
|
\parbox{90pt}{Spam attack \cite{naor03simpledht}} & |
1085 |
|
\parbox{110pt}{Hostile entity creates false versions of data, or gives wrong information about the data which entity is responsible for/knows about} & |
1086 |
|
\parbox{110pt}{Do not trust to single entity, get information from multiple entities, trust on majority's opinion} & |
1087 |
|
\parbox{110pt}{Easy to implement, creates more network traffic} |
1088 |
|
\\ \hline |
1089 |
|
|
1090 |
|
|
1091 |
|
\parbox{90pt}{Entity identification \cite{ajmani02conchord}, \cite{douceur02sybil}} & |
1092 |
|
\parbox{110pt}{Identify participating entities reliably and efficiently } & |
1093 |
|
\parbox{110pt}{Digital signatures, key infrastructure} & |
1094 |
|
\parbox{110pt}{Not practically realizable} |
1095 |
|
\\ \hline |
1096 |
|
|
1097 |
|
|
1098 |
|
\parbox{90pt}{Data integrity/authenticity \cite{fips-sha-1}, \cite{rivest96sdsi}, \cite{spkiworkinggroup}} & |
1099 |
|
\parbox{110pt}{Integrity/originality of data is unknown} & |
1100 |
|
\parbox{110pt}{Cryptographic content hashes, key architectures} & |
1101 |
|
\parbox{110pt}{For data integrity, there are working solutions, but for data authenticity, some of the solutions are partial, which may be practically realizable} |
1102 |
|
\\ \hline |
1103 |
|
|
1104 |
|
|
1105 |
|
\parbox{90pt}{Anonymity \cite{dingledine00free, tarzan:ccs9, pub00, clarke00freenet, reiter98crowds, 352607, 502002}} & |
1106 |
|
\parbox{110pt}{Anonymity cannot be provided in all cases} & |
1107 |
|
\parbox{110pt}{Remailers, pre-routing} & |
1108 |
|
\parbox{110pt}{Total anonymity cannot be provided yet} |
1109 |
|
\\ \hline |
1110 |
|
|
1111 |
|
|
1112 |
|
\parbox{90pt}{Malicious peers \cite{sit02securitycons, castro02securerouting}} & |
1113 |
|
\parbox{110pt}{How to identify malicious peers in the system ?} & |
1114 |
|
\parbox{110pt}{Create invariants for peer behavior, verify invariants, self-certifying data} & |
1115 |
|
\parbox{110pt}{Partial solutions, self-certifying data most reliable} |
1116 |
|
\\ \hline |
1117 |
|
|
1118 |
|
|
1119 |
|
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, daswani03openproblems}} & |
1120 |
|
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
1121 |
|
\parbox{110pt}{Schema-based rules} & |
1122 |
|
\parbox{110pt}{Some initial experiences, need more research} |
1123 |
|
\\ \hline |
1124 |
|
|
1125 |
|
|
1126 |
|
\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} & |
1127 |
|
\parbox{110pt}{Hostile peer could act correctly with its neighbors, but incorrectly with others} & |
1128 |
|
\parbox{110pt}{Public keys, digital signatures} & |
1129 |
|
\parbox{110pt}{Not practical approach/working proposal created yet} |
1130 |
|
\\ \hline |
1131 |
|
|
1132 |
|
|
1133 |
|
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
1134 |
|
\parbox{110pt}{Joining peer may join parallel network, formed a group of hostile peers, hostile peer(s) controls the construction of the network} & |
1135 |
|
\parbox{110pt}{Use trusted peers, based on history information, cryptography, key infrastructure} & |
1136 |
|
\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not practical approach/working proposal created yet} |
1137 |
|
\\ \hline |
1138 |
|
|
1139 |
|
|
1140 |
|
\parbox{90pt}{External security threats \cite{grahamp2psecurity}} & |
1141 |
|
\parbox{110pt}{Viruses, trojans, sniffers} & |
1142 |
|
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} & |
1143 |
|
\parbox{110pt}{Not much research has been done on this} |
1144 |
|
\\ \hline |
1145 |
|
|
1146 |
|
\caption{Security problems in Peer-to-Peer.} |
1147 |
|
\label{table_security_problems_Peer-to-Peer} |
1148 |
|
|
1149 |
|
|
1150 |
|
\end{longtable} |
1151 |
|
\normalsize |
1152 |
|
|
1153 |
|
|
1154 |
|
|
1155 |
\section{Performance and usability problems in Peer-to-Peer} |
\section{Performance and usability problems in Peer-to-Peer} |
1156 |
|
|
1157 |
In this section, we discuss performance issues regarding Peer-to-Peer systems. |
In this section, we discuss performance and usability issues regarding Peer-to-Peer systems. We start |
1158 |
|
by describing techniques to improve data lookups in Peer-to-Peer systems. Then, we focus on web-like |
1159 |
|
searches and system management problems. |
1160 |
|
|
1161 |
|
|
1162 |
\subsection{Efficient data lookup} |
\subsection{Efficient data lookup} |
1163 |
|
|
1165 |
especially with the loosely structured approach. In iterative deepening |
especially with the loosely structured approach. In iterative deepening |
1166 |
\cite{yang02improvingsearch}, multiple BFS searches are initiated |
\cite{yang02improvingsearch}, multiple BFS searches are initiated |
1167 |
with successively larger TTL depth limits, until either the query is satisfied, |
with successively larger TTL depth limits, until either the query is satisfied, |
1168 |
or the maximum depth $D$ has been reached. To perform a data lookup, the query |
or the maximum depth $D$ has been reached. |
1169 |
originator starts the data lookup with a small TTL value. If the search is not successful, |
|
1170 |
the query originator increases the TTL value and performs another data lookup. This |
Expanding ring, proposed by Shenker et al. in \cite{lv02searchreplication}, |
1171 |
process is repeated until the desired data is found or the maximum depth $D$ |
is similar to the iterative deepening technique. In this method, a peer starts a flood with small TTL, and |
1172 |
has been reached. Expanding ring, proposed by Shenker et al. in \cite{lv02searchreplication}, |
waits to see if the search is successful. If it is, then the peer stops the data lookuo. Otherwise, the peer increases |
1173 |
is similar to the iterative deepening technique. With these techniques, searches |
the TTL and starts another data lookup. With these techniques, searches |
1174 |
may not be fast when desired data item requires several consecutive flooding rounds. |
may not be fast when desired data item requires several consecutive flooding rounds. |
1175 |
|
|
1176 |
Directed BFS \cite{yang02improvingsearch} optimizes the original |
Directed BFS \cite{yang02improvingsearch} optimizes the original |
1191 |
has a poor response time but it doesn't generate as much network traffic as |
has a poor response time but it doesn't generate as much network traffic as |
1192 |
the original BFS. As suggested in \cite{lv02searchreplication}, the |
the original BFS. As suggested in \cite{lv02searchreplication}, the |
1193 |
random walk approach can be made more effective by introducing |
random walk approach can be made more effective by introducing |
1194 |
multiple ''walkers''. Freenet \cite{clarke00freenet} uses |
multiple ''walkers''. |
1195 |
random walk searches in data lookups. Freenet's data lookup model resembles |
|
1196 |
|
Freenet \cite{clarke00freenet} uses random walk searches in data lookups. Freenet's data lookup model resembles |
1197 |
Depth-First-Search (DFS) and peers' routing tables are dynamically built |
Depth-First-Search (DFS) and peers' routing tables are dynamically built |
1198 |
using caching. This is an outcome of Freenet's main design principles, anonymity. |
using caching. This is an outcome of Freenet's main design principles, anonymity. |
1199 |
Another property of the Freenet's data lookup model is that |
Another property of the Freenet's data lookup model is that |
1312 |
call their technique as a \emph{data overlay}, since it supports several fundamental data structures. |
call their technique as a \emph{data overlay}, since it supports several fundamental data structures. |
1313 |
Authors have used this data overlay when building a Self-Organized Meta data Overlay (SOMO), which can be used |
Authors have used this data overlay when building a Self-Organized Meta data Overlay (SOMO), which can be used |
1314 |
for monitoring the health of a tightly structured overlay. The fault tolerance of SOMO itself is currently |
for monitoring the health of a tightly structured overlay. The fault tolerance of SOMO itself is currently |
1315 |
unknown. |
unknown. |
|
|
|
|
|
|
|
\section{Miscellaneous problems in Peer-to-Peer} |
|
|
|
|
|
In this section we discuss miscellaneous problems in Peer-to-Peer systems. |
|
|
|
|
|
\subsection{Programming guidelines and benchmarks} |
|
|
|
|
|
All existing Peer-to-Peer systems have rather different interfaces even though they have common properties and |
|
|
components. More important, all existing Peer-to-Peer systems are incompatible with each other. One |
|
|
of the most important area of future research is to create common programming abstractions, i.e., |
|
|
interfaces, design patters and frameworks. Also, benchmarks are needed for comparing |
|
|
different algorithms equally. Recently, there have been few proposals towards common programming |
|
|
guidelines. This list includes \cite{zhao03api, frise02p2pframework, babaoglu02anthill}. |
|
|
Early experiments with Peer-to-Peer benchmarking include \cite{ratnasamy02routing, rhea03benchmarks}. |
|
1316 |
|
|
1317 |
\subsection{Social behavior} |
\subsection{Summary} |
1318 |
|
|
1319 |
Frequent assumption in Peer-to-Peer systems is that peers are willing to cooperate. Another belief |
In this subsection we list performance and usability problems in Peer-to-Peer systems in the table. |
|
is that all peers would behave equally, i.e., all peers both consume and contribute services. |
|
|
However, these assumptions are not true as several studies show \cite{saroiu02measurementstudyp2p, |
|
|
oram01harnessingpower, hearn02mojonation}. Peers rather consume than contribute and peers are |
|
|
unwilling to cooperate. |
|
|
|
|
|
Somewhat surprisingly little research has been done in this area, especially when considering |
|
|
the possible impact of \emph{unwanted social behavior} to performance of a Peer-to-Peer |
|
|
system. The problem is addressed by Golle et al. \cite{golle01incentivesp2p}, Ngan et al. |
|
|
\cite{ngan03enforcefile} and Shneidman et al. \cite{shneidman03rationality}. Some |
|
|
research has been focused on semantic properties of the overlay in order to increase |
|
|
cooperation among participating peers \cite{crespo02semanticoverlay}. Ramanathan et al. |
|
|
\cite{ramanathan02goodpeers} and Bernstein et al. \cite{bernstein03selection} use |
|
|
empirical metrics and decision trees when teaching peers to make better decisions |
|
|
when contacting other peers in Peer-to-Peer system. Alpine \cite{alpineurl} is an example of |
|
|
Peer-to-Peer system, which uses empirical metrics for peer selection. |
|
|
|
|
|
|
|
|
\subsection{Simulating Peer-to-Peer systems} |
|
|
|
|
|
Very little research has been done on simulating a Peer-to-Peer system. Presumably, this |
|
|
is due to complex nature of Peer-to-Peer system, which makes comprehensive simulations very |
|
|
difficult. Floyd et al. have been studying the simulation of the Internet in \cite{504642}. Authors |
|
|
state that simulating the Internet is very challenging task, because of its heterogeneity |
|
|
and rapid change. Obviously, these factors exist also in Peer-to-Peer systems even with higher |
|
|
rates. |
|
|
|
|
|
As long as comprehensive simulations of a Peer-to-Peer systems are lacking, we cannot make any detailed |
|
|
analysis on general properties of a Peer-to-Peer system, such as usage patterns. However, we can assume |
|
|
that, e.g., query keywords follow the Zipf-like distribution \cite{breslau98implications} both in the |
|
|
Internet and in Peer-to-Peer systems. |
|
1320 |
|
|
|
\section{Summary} |
|
|
|
|
|
In this section we summarize open problems in Peer-to-Peer systems. All the open problem entries |
|
|
listed in this section are not necessarily mentioned in the previous sections. Problems listed |
|
|
here are variations of previously mentioned problems, or otherwise related to them. |
|
|
|
|
|
In table \ref{table_security_problems_Peer-to-Peer} open problems related to security are listed; in |
|
|
table \ref{table_performanceusability_problems_Peer-to-Peer} problems related to performance are |
|
|
listed; in table \ref{table_Miscellaneous_problems_Peer-to-Peer} miscellaneous open problems are listed. |
|
|
|
|
|
|
|
|
\scriptsize |
|
|
\begin{longtable}{|l|l|l|l|} |
|
|
|
|
|
\hline |
|
|
\multicolumn{1}{|c|}{\textbf{Problem}} & |
|
|
\multicolumn{1}{c|}{\textbf{Problem description}} & |
|
|
\multicolumn{1}{c|}{\textbf{Solutions}} & |
|
|
\multicolumn{1}{c|}{\textbf{Comments/Status}} |
|
|
\\ \hline |
|
|
\endfirsthead |
|
|
|
|
|
\multicolumn{4}{c}% |
|
|
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
|
|
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
|
|
\multicolumn{1}{c|}{\textbf{Problem description}} & |
|
|
\multicolumn{1}{c|}{\textbf{Solutions}} & |
|
|
\multicolumn{1}{c|}{\textbf{Comments/Status}} |
|
|
\\ \hline |
|
|
\endhead |
|
|
|
|
|
\endfoot |
|
|
|
|
|
|
|
|
|
|
|
\parbox{90pt}{Query routing \cite{sit02securitycons, aspnes02faultrouting, castro02securerouting, ratnasamy02routing, gavoille01routing, |
|
|
lynch02atomicdataaccess, fiat02censorship, saia02dynamicfaultcontentnetwork, datar02butterflies}} & |
|
|
\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} & |
|
|
\parbox{110pt}{Query monitoring, cross check routing tables, verify routing tables, create routing table invariants} & |
|
|
\parbox{110pt}{Increases system complexity} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{DoS attack \cite{sit02securitycons, saia02dynamicfaultcontentnetwork, datar02butterflies, daswani02queryflooddos, juels99clientpuzzles}} & |
|
|
\parbox{110pt}{Distributed, controlled burden against specific computer(s)} & |
|
|
\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic models, replication} & |
|
|
\parbox{110pt}{Only partial solutions, traffic models most effective} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Sybil attack \cite{douceur02sybil, castro02securerouting}} & |
|
|
\parbox{110pt}{Single hostile entity presents multiple entities} & |
|
|
\parbox{110pt}{Identify all peers simultaneously across the system, collect pool of peers which are validated, distributed peer ID creation} & |
|
|
\parbox{110pt}{Not practically realizable, research focused on persistence, not on identity distinction} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Spam attack \cite{naor03simpledht}} & |
|
|
\parbox{110pt}{Hostile entity creates false versions of data, or gives wrong information about the data which entity is responsible for/knows about} & |
|
|
\parbox{110pt}{Do not trust to single entity, get information from multiple entities, trust on majority's opinion} & |
|
|
\parbox{110pt}{Easy to implement, creates more network traffic} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Entity identification \cite{ajmani02conchord}, \cite{douceur02sybil}} & |
|
|
\parbox{110pt}{Identify participating entities reliably and efficiently } & |
|
|
\parbox{110pt}{Digital signatures, key infrastructure} & |
|
|
\parbox{110pt}{Not practically realizable} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Data integrity/authenticity \cite{fips-sha-1}, \cite{rivest96sdsi}, \cite{spkiworkinggroup}} & |
|
|
\parbox{110pt}{Integrity/originality of data is unknown} & |
|
|
\parbox{110pt}{Cryptographic content hashes, key architectures} & |
|
|
\parbox{110pt}{For data integrity, there are working solutions, but for data authenticity, some of the solutions are partial, which may be practically realizable} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Anonymity \cite{dingledine00free, tarzan:ccs9, pub00, clarke00freenet, reiter98crowds, 352607, 502002}} & |
|
|
\parbox{110pt}{Anonymity cannot be provided in all cases} & |
|
|
\parbox{110pt}{Remailers, pre-routing} & |
|
|
\parbox{110pt}{Total anonymity cannot be provided yet} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Malicious peers \cite{sit02securitycons, castro02securerouting}} & |
|
|
\parbox{110pt}{How to identify malicious peers in the system ?} & |
|
|
\parbox{110pt}{Create invariants for peer behavior, verify invariants, self-certifying data} & |
|
|
\parbox{110pt}{Partial solutions, self-certifying data most reliable} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, daswani03openproblems}} & |
|
|
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
|
|
\parbox{110pt}{Schema-based rules} & |
|
|
\parbox{110pt}{Some initial experiences, need more research} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} & |
|
|
\parbox{110pt}{Hostile peer could act correctly with its neighbors, but incorrectly with others} & |
|
|
\parbox{110pt}{Public keys, digital signatures} & |
|
|
\parbox{110pt}{Not practical approach/working proposal created yet} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
|
|
\parbox{110pt}{Joining peer may join parallel network, formed a group of hostile peers, hostile peer(s) controls the construction of the network} & |
|
|
\parbox{110pt}{Use trusted peers, based on history information, cryptography, key infrastructure} & |
|
|
\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not practical approach/working proposal created yet} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{External security threats \cite{grahamp2psecurity}} & |
|
|
\parbox{110pt}{Viruses, trojans, sniffers} & |
|
|
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} & |
|
|
\parbox{110pt}{Not much research has been done on this} |
|
|
\\ \hline |
|
|
|
|
|
\caption{Security problems in Peer-to-Peer.} |
|
|
\label{table_security_problems_Peer-to-Peer} |
|
|
|
|
|
|
|
|
\end{longtable} |
|
|
\normalsize |
|
|
|
|
|
|
|
1321 |
|
|
1322 |
\scriptsize |
\scriptsize |
1323 |
\begin{longtable}{|l|l|l|l|} |
\begin{longtable}{|l|l|l|l|} |
1445 |
|
|
1446 |
|
|
1447 |
\end{longtable} |
\end{longtable} |
1448 |
\normalsize |
\normalsize |
1449 |
|
|
1450 |
|
|
1451 |
|
\section{Miscellaneous problems in Peer-to-Peer} |
1452 |
|
|
1453 |
|
In this section we discuss miscellaneous problems in Peer-to-Peer systems. |
1454 |
|
|
1455 |
|
\subsection{Programming guidelines and benchmarks} |
1456 |
|
|
1457 |
|
All existing Peer-to-Peer systems have rather different interfaces even though they have common properties and |
1458 |
|
components. More important, all existing Peer-to-Peer systems are incompatible with each other. One |
1459 |
|
of the most important area of future research is to create common programming abstractions, i.e., |
1460 |
|
interfaces, design patters and frameworks. Also, benchmarks are needed for comparing |
1461 |
|
different algorithms equally. Recently, there have been few proposals towards common programming |
1462 |
|
guidelines. This list includes \cite{zhao03api, frise02p2pframework, babaoglu02anthill}. |
1463 |
|
Early experiments with Peer-to-Peer benchmarking include \cite{ratnasamy02routing, rhea03benchmarks}. |
1464 |
|
|
1465 |
|
\subsection{Social behavior} |
1466 |
|
|
1467 |
|
Frequent assumption in Peer-to-Peer systems is that peers are willing to cooperate. Another belief |
1468 |
|
is that all peers would behave equally, i.e., all peers both consume and contribute services. |
1469 |
|
However, these assumptions are not true as several studies show \cite{saroiu02measurementstudyp2p, |
1470 |
|
oram01harnessingpower, hearn02mojonation}. Peers rather consume than contribute and peers are |
1471 |
|
unwilling to cooperate. |
1472 |
|
|
1473 |
|
Somewhat surprisingly little research has been done in this area, especially when considering |
1474 |
|
the possible impact of \emph{unwanted social behavior} to performance of a Peer-to-Peer |
1475 |
|
system. The problem is addressed by Golle et al. \cite{golle01incentivesp2p}, Ngan et al. |
1476 |
|
\cite{ngan03enforcefile} and Shneidman et al. \cite{shneidman03rationality}. Some |
1477 |
|
research has been focused on semantic properties of the overlay in order to increase |
1478 |
|
cooperation among participating peers \cite{crespo02semanticoverlay}. Ramanathan et al. |
1479 |
|
\cite{ramanathan02goodpeers} and Bernstein et al. \cite{bernstein03selection} use |
1480 |
|
empirical metrics and decision trees when teaching peers to make better decisions |
1481 |
|
when contacting other peers in Peer-to-Peer system. Alpine \cite{alpineurl} is an example of |
1482 |
|
Peer-to-Peer system, which uses empirical metrics for peer selection. |
1483 |
|
|
1484 |
|
|
1485 |
|
\subsection{Simulating Peer-to-Peer systems} |
1486 |
|
|
1487 |
|
Very little research has been done on simulating a Peer-to-Peer system. Presumably, this |
1488 |
|
is due to complex nature of Peer-to-Peer system, which makes comprehensive simulations very |
1489 |
|
difficult. Floyd et al. have been studying the simulation of the Internet in \cite{504642}. Authors |
1490 |
|
state that simulating the Internet is very challenging task, because of its heterogeneity |
1491 |
|
and rapid change. Obviously, these factors exist also in Peer-to-Peer systems even with higher |
1492 |
|
rates. |
1493 |
|
|
1494 |
|
As long as comprehensive simulations of a Peer-to-Peer systems are lacking, we cannot make any detailed |
1495 |
|
analysis on general properties of a Peer-to-Peer system, such as usage patterns. However, we can assume |
1496 |
|
that, e.g., query keywords follow the Zipf-like distribution \cite{breslau98implications} both in the |
1497 |
|
Internet and in Peer-to-Peer systems. |
1498 |
|
|
1499 |
|
|
1500 |
|
|
1501 |
|
\subsection{Summary} |
1502 |
|
|
1503 |
|
In this subsection we list security problems in Peer-to-Peer systems in the table. |
1504 |
|
|
1505 |
|
|
1506 |
\scriptsize |
\scriptsize |
1584 |
|
|
1585 |
\chapter{Fenfire hypermedia system} |
\chapter{Fenfire hypermedia system} |
1586 |
|
|
1587 |
In this chapter we give an overview of the Fenfire system. We also |
In this chapter we give an overview of the Fenfire system and |
1588 |
describe briefly xanalogical storage model. At the end of this chapter we study Storm, |
the xanalogical storage model. Also, we describe Storm |
1589 |
Fenfire's software module, which is an essential part of Fenfire's Peer-to-Peer |
which is an essential part of Fenfire's Peer-to-Peer functionality. |
|
functionality. |
|
1590 |
|
|
1591 |
\section{Overview} |
\section{Overview} |
1592 |
|
|