/[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.175 by hemppah, Mon Mar 24 10:26:09 2003 UTC revision 1.176 by hemppah, Mon Mar 24 11:44:58 2003 UTC
# Line 960  between anonymity and other properties o Line 960  between anonymity and other properties o
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    
# Line 989  identifier, such as crypto-based puzzles Line 990  identifier, such as crypto-based puzzles
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    
# Line 1030  Ross Lee Graham lists several external t Line 1028  Ross Lee Graham lists several external t
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    
# Line 1043  The most intensive research in Peer-to-P Line 1165  The most intensive research in Peer-to-P
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
# Line 1069  randomly selected neighbor. The basic ra Line 1191  randomly selected neighbor. The basic ra
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
# Line 1189  describe an arbitrary data structure on Line 1312  describe an arbitrary data structure on
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|}
# Line 1494  ganesan02yappers}} & Line 1445  ganesan02yappers}} &
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
# Line 1578  networks (MANETs) can be only connected Line 1584  networks (MANETs) can be only connected
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    

Legend:
Removed from v.1.175  
changed lines
  Added in v.1.176

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