/[gzz]/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/masterthesis.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.105 by hemppah, Mon Mar 3 15:01:47 2003 UTC revision 1.106 by hemppah, Tue Mar 4 08:15:53 2003 UTC
# Line 307  them stress the overhead of nearly entir Line 307  them stress the overhead of nearly entir
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.
# Line 1103  mentioned situations, i.e. pseudonym whi Line 1068  mentioned situations, i.e. pseudonym whi
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
# Line 1193  includes viruses, trojans and bugs in Pe Line 1159  includes viruses, trojans and bugs in Pe
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    
# Line 1550  General security considerations \cite{si Line 1430  General security considerations \cite{si
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    

Legend:
Removed from v.1.105  
changed lines
  Added in v.1.106

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26