307 |
\label{fig:gnutella_overlay_cluster} |
\label{fig:gnutella_overlay_cluster} |
308 |
\end{figure} |
\end{figure} |
309 |
|
|
|
Additionally, there has been other improvements also. In iterative deepening |
|
|
\cite{yang02improvingsearch}, multiple breadt-first searches are initiated |
|
|
with successively larger TTL depth limits, until either the query is satisfied, |
|
|
or the maximumum depth $D$ has been reached. To perform a data lookup, query |
|
|
originator starts a flood with small TTL value. If the search is not succesful, |
|
|
the query originator increases the TTL value and performs another flood. This |
|
|
process is repeated until the desired data is found or maximumum depth $D$ |
|
|
has been reached. Expanding ring, proposed by Shenker et al., \cite{lv02searchreplication}, |
|
|
is similar to iterative deepening techique. With these techniques, search |
|
|
may not be fast when desired data item requires many consecutive flooding rounds. |
|
|
|
|
|
Directed breadt-first search \cite{yang02improvingsearch} optimizes the original |
|
|
breadt-first searche in way that peer selects neighbors with many quality results |
|
|
may be reached, thereby maintaining the the quality of costs and decreasing the amount |
|
|
of messages sent to network. Alpine \cite{alpineurl} and NeuroGrid \cite{joseph02neurogrid} |
|
|
Peer-to-Peer system use somewhat similar method when performing data lookups. |
|
|
|
|
|
Local indices \cite{yang02improvingsearch} in one variation of active caching. |
|
|
In this scheme, each peer maintains an index over the data of all nodes within |
|
|
$h$ hops of itself, where $h$ is a system-wide variable, called radius of the |
|
|
index\footnote{In normal BFS case, the value of $h$ is 0, as peer only has index |
|
|
over its local content.}. Mutual index caching architecture, as proposed in |
|
|
\cite{osokine02distnetworks}, is one variation of local indices techique. |
|
|
|
|
|
In random walk approach \cite{lv02searchreplication}, peer forwards a query to |
|
|
randomly selected neighbor. The basic random walk approach decreases the |
|
|
overhead generated by messages. On the other hand, basic random walk approach |
|
|
has poor response time. As suggested in \cite{lv02searchreplication}, |
|
|
random walk approach can be done more effective by introducing |
|
|
multiple ''walkers''. Freenet \cite{clarke00freenet} Peer-to-Peer system uses |
|
|
random walk searches in query lookups. Indeed, Freenet's query resembles |
|
|
depth-first traversal and peers' routing tables are dynamically built |
|
|
using caching. This is an outcome of Freenet's main design priciples, |
|
|
i.e., anonymity. |
|
|
|
|
310 |
Previously presented improvements are only partial solutions. Obviously, more |
Previously presented improvements are only partial solutions. Obviously, more |
311 |
research is required to make loosely structured approach's data lookup more |
research is required to make loosely structured approach's data lookup more |
312 |
scalable and effective. |
scalable and effective. |
1068 |
addressing peer-anonymity by providing anonymous-like identifiers to peers (e.g., tightly structured peer |
addressing peer-anonymity by providing anonymous-like identifiers to peers (e.g., tightly structured peer |
1069 |
identifiers). |
identifiers). |
1070 |
|
|
1071 |
Anonymity is widely used in those Peer-to-Peer system in which data publication is performed. These include |
Anonymity is widely used in those Peer-to-Peer system in which data publication and non-censorship are important properties |
1072 |
|
of the system. These include |
1073 |
Freenet \cite{clarke00freenet}, Publius \cite{pub00}, Free haven \cite{dingledine00free}, Crowds \cite{reiter98crowds}, |
Freenet \cite{clarke00freenet}, Publius \cite{pub00}, Free haven \cite{dingledine00free}, Crowds \cite{reiter98crowds}, |
1074 |
Tangler \cite{502002} and upcoming Mnet \cite{mneturl}. Forwarding proxies are used in Freenet, Crowds and |
Tangler \cite{502002} and upcoming Mnet \cite{mneturl}. Forwarding proxies are used in Freenet, Crowds and |
1075 |
Free Haven in order to provide various types of anonymity. Tangler and Publius uses cryptographic |
Free Haven in order to provide various types of anonymity. Tangler and Publius uses cryptographic |
1159 |
to the problems mentioned above. |
to the problems mentioned above. |
1160 |
|
|
1161 |
|
|
1162 |
\scriptsize |
\section{Performance and usability problems in Peer-to-Peer} |
|
\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}, \cite{aspnes02faultrouting}, \cite{castro02securerouting}, \cite{ratnasamy02routing}, \cite{gavoille01routing}, \cite{lynch02atomicdataaccess}} & |
|
|
\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}, \cite{saia02dynamicfaultcontentnetwork}, \cite{datar02butterflies}, \cite{daswani02queryflooddos}, \cite{juels99clientpuzzles}} & |
|
|
\parbox{110pt}{Distributed, controlled burden againts 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}, \cite{castro02securerouting}} & |
|
|
\parbox{110pt}{Single hostile entity present multiple entities} & |
|
|
\parbox{110pt}{Identify all nodes simultaneously across the system, collect pool of nodes which are validated, distributed node 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} & |
|
|
\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}{Resource spoofing} & |
|
|
\parbox{110pt}{Hostile entity 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 |
|
1163 |
|
|
1164 |
|
In this section we review open problems regarding performance and usability. |
1165 |
|
|
1166 |
\parbox{90pt}{Entity identification \cite{ajmani02conchord}} & |
1) Which one is more important: short path length or overhead associated with keeping routing tables updated, e.g. number of state updates whenever join/leave occurs |
1167 |
\parbox{110pt}{Identify participating entities reliably and efficiently } & |
(number of neighbors) |
1168 |
\parbox{110pt}{Digital signatures, key infrastructure} & |
2) Are we able to achieve reasonably pathlenghts with less neigbors (Viceroy) ? |
1169 |
\parbox{110pt}{Not practically realizable} |
3) How big is the difference between optimal path length and worst case path length ? |
1170 |
\\ \hline |
4) How difficult is to recover from total routing mislead and the cost of it ? |
1171 |
|
5) Can we choose better neighbors by using network latencies instead of closeness of IDs in the ID space ? What are the effects doing so ? |
1172 |
|
6) Can we choose IDs (globally) based on the geographical location/distance ? Is there a working model for doing so ? |
1173 |
|
7) How do we should work with node heterogeneity; how big changes have to be made to existing algorithms for better support to heterogeneity ? |
1174 |
|
|
1175 |
\parbox{90pt}{Data integrity/authenticity \cite{dabek01widearea}} & |
Principles on scalable search in decentralized, and unstructured networks \cite{lv02searchreplication}: |
1176 |
\parbox{110pt}{Integrity/originality of data is unknown} & |
1) system must support adaptive termination |
1177 |
\parbox{110pt}{Cryptographic content hashes, key architectures} & |
2) message duplication should be minimized |
1178 |
\parbox{110pt}{For data integrity, there are working solutions, but for data authenticity, some of the solutions are partial, which may be practically realizable} |
3) each additional step during search should not significantly increase the number of nodes visited |
|
\\ \hline |
|
1179 |
|
|
1180 |
|
Network proximity: |
1181 |
|
-\cite{pias03lighthouse}, \cite{ng02predicting} |
1182 |
|
|
|
\parbox{90pt}{Anonymity \cite{reiter98crowds}, \cite{tarzan:ccs9}, \cite{pub00}, \cite{clarke00freenet}, \cite{reiter98crowds}, \cite{352607},\cite{502002}} & |
|
|
\parbox{110pt}{Anonymity cannot be provided in all cases} & |
|
|
\parbox{110pt}{Remailers, pre-routing} & |
|
|
\parbox{110pt}{Total anonymity cannot be provided yet} |
|
|
\\ \hline |
|
1183 |
|
|
1184 |
|
|
1185 |
\parbox{90pt}{Malicious nodes \cite{sit02securitycons}, \cite{castro02securerouting}} & |
\subsection{Efficient data lookup} |
|
\parbox{110pt}{How to identify malicious nodes in the system} & |
|
|
\parbox{110pt}{Create invariants for node behaviour, verify invariants, self-certifying data} & |
|
|
\parbox{110pt}{Partial solutions, self-certifying data most realiable} |
|
|
\\ \hline |
|
1186 |
|
|
1187 |
|
The most intensive research in Peer-to-Peer domain has been focused on efficient data lookup methods, |
1188 |
|
especially with loosely structured approach. In addition to ''super-peer'' method presented in chapter |
1189 |
|
2, there has been other improvements also. |
1190 |
|
In iterative deepening |
1191 |
|
\cite{yang02improvingsearch}, multiple breadt-first searches are initiated |
1192 |
|
with successively larger TTL depth limits, until either the query is satisfied, |
1193 |
|
or the maximumum depth $D$ has been reached. To perform a data lookup, query |
1194 |
|
originator starts a flood with small TTL value. If the search is not succesful, |
1195 |
|
the query originator increases the TTL value and performs another flood. This |
1196 |
|
process is repeated until the desired data is found or maximumum depth $D$ |
1197 |
|
has been reached. Expanding ring, proposed by Shenker et al., \cite{lv02searchreplication}, |
1198 |
|
is similar to iterative deepening techique. With these techniques, search |
1199 |
|
may not be fast when desired data item requires many consecutive flooding rounds. |
1200 |
|
|
1201 |
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol}, \cite{daswani03openproblems}} & |
Directed breadt-first search \cite{yang02improvingsearch} optimizes the original |
1202 |
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
breadt-first search in way that peer selects neighbors with many quality results |
1203 |
\parbox{110pt}{Schema-based rules} & |
may be reached, thereby maintaining the the quality of costs and decreasing the amount |
1204 |
\parbox{110pt}{Some initial experiences, need more research} |
of messages sent to network. Alpine \cite{alpineurl} and NeuroGrid \cite{joseph02neurogrid} |
1205 |
\\ \hline |
Peer-to-Peer system use somewhat similar method when performing data lookups. |
1206 |
|
|
1207 |
|
Local indices \cite{yang02improvingsearch} in one variation of active caching. |
1208 |
|
In this scheme, each peer maintains an index over the data of all nodes within |
1209 |
|
$h$ hops of itself, where $h$ is a system-wide variable, called radius of the |
1210 |
|
index\footnote{In normal BFS case, the value of $h$ is 0, as peer only has index |
1211 |
|
over its local content.}. Mutual index caching architecture, as proposed in |
1212 |
|
\cite{osokine02distnetworks}, is one variation of local indices techique. |
1213 |
|
|
1214 |
\parbox{90pt}{Inconsistent behaviour \cite{sit02securitycons}} & |
In random walk approach \cite{lv02searchreplication}, peer forwards a query to |
1215 |
\parbox{110pt}{Hostile node could act correctly with its neighbors, but incorrectly with others} & |
randomly selected neighbor. The basic random walk approach decreases the |
1216 |
\parbox{110pt}{Public keys, digital signatures} & |
overhead generated by messages. On the other hand, basic random walk approach |
1217 |
\parbox{110pt}{Not practical approach/working proposal created yet} |
has poor response time. As suggested in \cite{lv02searchreplication}, |
1218 |
\\ \hline |
random walk approach can be done more effective by introducing |
1219 |
|
multiple ''walkers''. Freenet \cite{clarke00freenet} Peer-to-Peer system uses |
1220 |
|
random walk searches in query lookups. Indeed, Freenet's query resembles |
1221 |
|
depth-first traversal and peers' routing tables are dynamically built |
1222 |
|
using caching. This is an outcome of Freenet's main design priciples, |
1223 |
|
i.e., anonymity. |
1224 |
|
|
1225 |
|
Since tightly structured systems have efficient data lookup at the application level overlay, |
1226 |
|
current research efforts are focused on proximity based data lookup. In proximity based data lookup, |
1227 |
|
peers try to choose routing-tables refering to other peers that are \emph{nearby} in |
1228 |
|
the underlying network. In this way, tightly structured systems are able to |
1229 |
|
decrease actual lookup \emph{latency}. CAN, Kademlia, Pastry and Tapestry have a advanced |
1230 |
|
heuristics for proximity based routing. Additionally, most recent version of Chord uses |
1231 |
|
proximity based routing inspired by Karger and Ruhl \cite{karger02findingnearest}. Skipnet |
1232 |
|
\cite{harvey03skipnet1} uses combination of proximity and application level overlay routing |
1233 |
|
when performing data lookups. Authors call this feature \emph{constrained load balancing}. |
1234 |
|
|
1235 |
|
Research related to proximity based routing include \cite{karger02findingnearest}, |
1236 |
|
\cite{hildrum02distributedobject}, \cite{brinkmann02compactplacement}, \cite{rhea02probabilistic}, |
1237 |
|
\cite{castro02networkproximity}, \cite{ng02predicting} and \cite{pias03lighthouse}. However, |
1238 |
|
more research is required to make latency heuristic more effective and practical. |
1239 |
|
|
|
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
|
|
\parbox{110pt}{Joining node may join parallel network, formed a group of hostile nodes, hostile node(s) controls the construction of the network} & |
|
|
\parbox{110pt}{Use trusted nodes, based on history information, Cryptography, key infrastructure} & |
|
|
\parbox{110pt}{Not 100\% sure if Centreal Authority (CA) is missing, not practical approach/working proposal created yet} |
|
|
\\ \hline |
|
1240 |
|
|
1241 |
|
\cite{ripeanu02mappinggnutella} |
1242 |
|
|
|
\parbox{90pt}{External security threats} & |
|
|
\parbox{110pt}{Viruses, trojans, sniffers} & |
|
|
\parbox{110pt}{Data integrity/authenticity, distributed antivirus software} & |
|
|
\parbox{110pt}{Not much research has been done on this} |
|
|
\\ \hline |
|
1243 |
|
|
|
\caption{Security problems in Peer-to-Peer.} |
|
|
\label{table_security_problems_Peer-to-Peer} |
|
1244 |
|
|
1245 |
|
|
|
\end{longtable} |
|
|
\normalsize |
|
|
|
|
1246 |
|
|
1247 |
|
|
1248 |
|
|
1249 |
|
|
|
Censorship \cite{502002} |
|
1250 |
|
|
1251 |
\cite{douceur02sybil} |
\cite{crespo02semanticoverlay} |
1252 |
|
Locality \cite{keleher-02-p2p} |
1253 |
|
|
1254 |
|
|
1255 |
|
|
1256 |
|
\subsection{Fast and usable search} |
1257 |
|
|
1258 |
\section{Performance and usability problems in Peer-to-Peer} |
To make Peer-to-Peer systems usable in a large, these systems have to support flexible, efficient |
1259 |
|
and easy to use search methods. For instance, Internet's perhaps the most important feature |
1260 |
|
is the ability to perform keyword or fuzzy searches (e.g., Google). Currently, only loosely |
1261 |
|
structured systems are able carry out this requirement. Unfortunately, as discussed in this text, |
1262 |
|
the data loouk model of loosely structured approach is not scalable. Thus, research efforts have |
1263 |
|
been focused on tightly structured approach. |
1264 |
|
The main in problem with tightly structured approach is the fact that tightly structured algorihms |
1265 |
|
performs data lookups based on a unique identifier. However, quite recently have been studies |
1266 |
|
on the feasibility of Peer-to-Peer Web-like indexing and searching \cite{li03feasibility}. Authors |
1267 |
|
argue, that it is possible to implement Peer-to-Peer Web-like search with certain radical compromises. |
1268 |
|
First, Peer-to-Peer search enginge may need to decrease result quality in order make searching more |
1269 |
|
efficient. Second, Peer-to-Peer systems must observe better the properties of underlying network for |
1270 |
|
better performance. Study list include \cite{kronfol02fasdsearch}, \cite{harren02complex}, |
1271 |
|
\cite{joseph02p2players}, \cite{Bhattacharjee03resultcache}, \cite{andrzejak02rangequeries}, |
1272 |
|
\cite{ansaryefficientbroadcast03} and \cite{chord:om_p-meng}. |
1273 |
|
|
1274 |
|
Many techniques have been developed in order to provide more efficient search indexing. First, as |
1275 |
|
studies queries follow Zipf-like distributions \cite{breslau98implications} caching and precomputation |
1276 |
|
can be done for optimizting search indices \cite{li03feasibility}. Second, regular compression algorithms |
1277 |
|
and Bloom filters \cite{362692} can be used for even better optimizations. |
1278 |
|
|
|
1) Which one is more important: short path length or overhead associated with keeping routing tables updated, e.g. number of state updates whenever join/leave occurs |
|
|
(number of neighbors) |
|
|
2) Are we able to achieve reasonably pathlenghts with less neigbors (Viceroy) ? |
|
|
3) How big is the difference between optimal path length and worst case path length ? |
|
|
4) How difficult is to recover from total routing mislead and the cost of it ? |
|
|
5) Can we choose better neighbors by using network latencies instead of closeness of IDs in the ID space ? What are the effects doing so ? |
|
|
6) Can we choose IDs (globally) based on the geographical location/distance ? Is there a working model for doing so ? |
|
|
7) How do we should work with node heterogeneity; how big changes have to be made to existing algorithms for better support to heterogeneity ? |
|
1279 |
|
|
|
Principles on scalable search in decentralized, and unstructured networks \cite{lv02searchreplication}: |
|
|
1) system must support adaptive termination |
|
|
2) message duplication should be minimized |
|
|
3) each additional step during search should not significantly increase the number of nodes visited |
|
1280 |
|
|
|
Network proximity: |
|
|
-\cite{pias03lighthouse}, \cite{ng02predicting} |
|
1281 |
|
|
|
Efficient searching: |
|
|
-result caching and view trees \cite{Bhattacharjee03resultcache} (insight: store and and retrieve prior results from view tree) |
|
|
-bloom filters \cite{362692} |
|
1282 |
|
|
1283 |
|
|
|
\subsection{Efficient data lookup} |
|
1284 |
|
|
|
-Object's popularity: studies have shown that Napster, Gnutella and Web |
|
|
queries follow Zipf-like distributions (1/2, 1/3, 1/4 etc.) |
|
1285 |
|
|
1286 |
|
|
|
Proposals (Yand et all): |
|
1287 |
|
|
|
Iterative Deepening |
|
|
In Iterative Deepening, multiple BFS are initiated with successively larger |
|
|
depths limits, until either they query is satisfied, or the maximum depth L |
|
|
has been reached |
|
|
|
|
|
Directed BFS |
|
|
Implements a strategy where a source sends a query messages to just a subset |
|
|
of neighbours and selecting neighbors through which nides with many quality results |
|
|
may be reached. Node may select a neighbor that has produced or forwarded many |
|
|
many quality results in the past, on the premise that past performance is a good |
|
|
indication of future performance. |
|
|
|
|
|
Local Indices |
|
|
In this method, each node N maintains an index over the data of all nodes within h hops |
|
|
of itself, where h is a system-wide variable known as radius of the index (h=0 is th BFS case). |
|
|
When a node receives a query message, it can process the query on behalf of every node within |
|
|
r hops. |
|
|
|
|
|
|
|
|
\cite{ratnasamy02routing} |
|
|
\cite{hildrum02distributedobject} |
|
|
\cite{adamic02localsearch} |
|
|
\cite{adamic01powerlawsearch} |
|
|
\cite{ripeanu02mappinggnutella} |
|
|
\cite{lv02searchreplication} |
|
|
\cite{brinkmann02compactplacement} |
|
|
\cite{lv02gnutellascalable} |
|
|
\cite{osokine02distnetworks} |
|
|
\cite{harvey03skipnet1} |
|
|
\cite{rhea02probabilistic} |
|
|
\cite{ansaryefficientbroadcast03} |
|
|
\cite{castro02networkproximity} |
|
|
\cite{yang02efficientsearch} |
|
|
\cite{crespo02semanticoverlay} |
|
|
Locality \cite{keleher-02-p2p} |
|
|
\cite{ng02predicting} |
|
1288 |
|
|
|
\subsection{Fault-tolerance and robustness} |
|
1289 |
|
|
|
\subsection{Fast and usable search} |
|
|
\cite{yang02improvingsearch} |
|
|
\cite{kronfol02fasdsearch} |
|
|
\cite{harren02complex} |
|
|
\cite{joseph02p2players} |
|
|
Bloom filters \cite{362692} |
|
|
\cite{andrzejak02rangequeries} |
|
|
\cite{li03feasibility} |
|
|
\cite{CuencaAcuna2002DSIWorkshop} |
|
|
\cite{Bhattacharjee03resultcache} |
|
|
\cite{chord:om_p-meng} |
|
1290 |
|
|
1291 |
\cite{ramanathan02goodpeers} |
\cite{ramanathan02goodpeers} |
1292 |
|
|
1430 |
-solution: need a way to control creation of node IDs (ID = SHA-1(ip-address), challange node verify its ID) |
-solution: need a way to control creation of node IDs (ID = SHA-1(ip-address), challange node verify its ID) |
1431 |
|
|
1432 |
|
|
1433 |
|
|
1434 |
|
\scriptsize |
1435 |
|
\begin{longtable}{|l|l|l|l|} |
1436 |
|
|
1437 |
|
\hline |
1438 |
|
\multicolumn{1}{|c|}{\textbf{Problem}} & |
1439 |
|
\multicolumn{1}{c|}{\textbf{Problem description}} & |
1440 |
|
\multicolumn{1}{c|}{\textbf{Solutions}} & |
1441 |
|
\multicolumn{1}{c|}{\textbf{Comments/Status}} |
1442 |
|
\\ \hline |
1443 |
|
\endfirsthead |
1444 |
|
|
1445 |
|
\multicolumn{4}{c}% |
1446 |
|
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
1447 |
|
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
1448 |
|
\multicolumn{1}{c|}{\textbf{Problem description}} & |
1449 |
|
\multicolumn{1}{c|}{\textbf{Solutions}} & |
1450 |
|
\multicolumn{1}{c|}{\textbf{Comments/Status}} |
1451 |
|
\\ \hline |
1452 |
|
\endhead |
1453 |
|
|
1454 |
|
\endfoot |
1455 |
|
|
1456 |
|
|
1457 |
|
|
1458 |
|
\parbox{90pt}{Query routing \cite{sit02securitycons}, \cite{aspnes02faultrouting}, \cite{castro02securerouting}, \cite{ratnasamy02routing}, \cite{gavoille01routing}, \cite{lynch02atomicdataaccess}} & |
1459 |
|
\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} & |
1460 |
|
\parbox{110pt}{Query monitoring, cross check routing tables, verify routing tables, create routing table invariants} & |
1461 |
|
\parbox{110pt}{Increases system complexity} |
1462 |
|
\\ \hline |
1463 |
|
|
1464 |
|
|
1465 |
|
\parbox{90pt}{DoS attack \cite{sit02securitycons}, \cite{saia02dynamicfaultcontentnetwork}, \cite{datar02butterflies}, \cite{daswani02queryflooddos}, \cite{juels99clientpuzzles}} & |
1466 |
|
\parbox{110pt}{Distributed, controlled burden againts specific computer(s)} & |
1467 |
|
\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic models, replication} & |
1468 |
|
\parbox{110pt}{Only partial solutions, traffic models most effective} |
1469 |
|
\\ \hline |
1470 |
|
|
1471 |
|
|
1472 |
|
\parbox{90pt}{Sybil attack \cite{douceur02sybil}, \cite{castro02securerouting}} & |
1473 |
|
\parbox{110pt}{Single hostile entity present multiple entities} & |
1474 |
|
\parbox{110pt}{Identify all nodes simultaneously across the system, collect pool of nodes which are validated, distributed node ID creation} & |
1475 |
|
\parbox{110pt}{Not practically realizable, research focused on persistence, not on identity distinction} |
1476 |
|
\\ \hline |
1477 |
|
|
1478 |
|
|
1479 |
|
\parbox{90pt}{Spam attack \cite{naor03simpledht}} & |
1480 |
|
\parbox{110pt}{Hostile entity creates false versions of data} & |
1481 |
|
\parbox{110pt}{Do not trust to single entity, get information from multiple entities, trust on majority's opinion} & |
1482 |
|
\parbox{110pt}{Easy to implement, creates more network traffic} |
1483 |
|
\\ \hline |
1484 |
|
|
1485 |
|
|
1486 |
|
\parbox{90pt}{Resource spoofing} & |
1487 |
|
\parbox{110pt}{Hostile entity gives wrong information about the data which entity is responsible for/knows about} & |
1488 |
|
\parbox{110pt}{Do not trust to single entity, get information from multiple entities, trust on majority's opinion} & |
1489 |
|
\parbox{110pt}{Easy to implement, creates more network traffic} |
1490 |
|
\\ \hline |
1491 |
|
|
1492 |
|
|
1493 |
|
\parbox{90pt}{Entity identification \cite{ajmani02conchord}} & |
1494 |
|
\parbox{110pt}{Identify participating entities reliably and efficiently } & |
1495 |
|
\parbox{110pt}{Digital signatures, key infrastructure} & |
1496 |
|
\parbox{110pt}{Not practically realizable} |
1497 |
|
\\ \hline |
1498 |
|
|
1499 |
|
|
1500 |
|
\parbox{90pt}{Data integrity/authenticity \cite{dabek01widearea}} & |
1501 |
|
\parbox{110pt}{Integrity/originality of data is unknown} & |
1502 |
|
\parbox{110pt}{Cryptographic content hashes, key architectures} & |
1503 |
|
\parbox{110pt}{For data integrity, there are working solutions, but for data authenticity, some of the solutions are partial, which may be practically realizable} |
1504 |
|
\\ \hline |
1505 |
|
|
1506 |
|
|
1507 |
|
\parbox{90pt}{Anonymity \cite{reiter98crowds}, \cite{tarzan:ccs9}, \cite{pub00}, \cite{clarke00freenet}, \cite{reiter98crowds}, \cite{352607},\cite{502002}} & |
1508 |
|
\parbox{110pt}{Anonymity cannot be provided in all cases} & |
1509 |
|
\parbox{110pt}{Remailers, pre-routing} & |
1510 |
|
\parbox{110pt}{Total anonymity cannot be provided yet} |
1511 |
|
\\ \hline |
1512 |
|
|
1513 |
|
|
1514 |
|
\parbox{90pt}{Malicious nodes \cite{sit02securitycons}, \cite{castro02securerouting}} & |
1515 |
|
\parbox{110pt}{How to identify malicious nodes in the system} & |
1516 |
|
\parbox{110pt}{Create invariants for node behaviour, verify invariants, self-certifying data} & |
1517 |
|
\parbox{110pt}{Partial solutions, self-certifying data most realiable} |
1518 |
|
\\ \hline |
1519 |
|
|
1520 |
|
|
1521 |
|
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol}, \cite{daswani03openproblems}} & |
1522 |
|
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
1523 |
|
\parbox{110pt}{Schema-based rules} & |
1524 |
|
\parbox{110pt}{Some initial experiences, need more research} |
1525 |
|
\\ \hline |
1526 |
|
|
1527 |
|
|
1528 |
|
\parbox{90pt}{Inconsistent behaviour \cite{sit02securitycons}} & |
1529 |
|
\parbox{110pt}{Hostile node could act correctly with its neighbors, but incorrectly with others} & |
1530 |
|
\parbox{110pt}{Public keys, digital signatures} & |
1531 |
|
\parbox{110pt}{Not practical approach/working proposal created yet} |
1532 |
|
\\ \hline |
1533 |
|
|
1534 |
|
|
1535 |
|
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
1536 |
|
\parbox{110pt}{Joining node may join parallel network, formed a group of hostile nodes, hostile node(s) controls the construction of the network} & |
1537 |
|
\parbox{110pt}{Use trusted nodes, based on history information, Cryptography, key infrastructure} & |
1538 |
|
\parbox{110pt}{Not 100\% sure if Centreal Authority (CA) is missing, not practical approach/working proposal created yet} |
1539 |
|
\\ \hline |
1540 |
|
|
1541 |
|
|
1542 |
|
\parbox{90pt}{External security threats} & |
1543 |
|
\parbox{110pt}{Viruses, trojans, sniffers} & |
1544 |
|
\parbox{110pt}{Data integrity/authenticity, distributed antivirus software} & |
1545 |
|
\parbox{110pt}{Not much research has been done on this} |
1546 |
|
\\ \hline |
1547 |
|
|
1548 |
|
\caption{Security problems in Peer-to-Peer.} |
1549 |
|
\label{table_security_problems_Peer-to-Peer} |
1550 |
|
|
1551 |
|
|
1552 |
|
\end{longtable} |
1553 |
|
\normalsize |
1554 |
|
|
1555 |
|
|
1556 |
|
|