21 |
|
|
22 |
\translatedtitle{Fenfire vertaisverkko ymp?rist?ss?} |
\translatedtitle{Fenfire vertaisverkko ymp?rist?ss?} |
23 |
|
|
24 |
\author{Hermanni Hyyti?l?} |
\author{Hermanni Hyytiälä} |
25 |
|
|
26 |
\linja{Software Engineering} |
\linja{Software Engineering} |
27 |
|
|
29 |
|
|
30 |
\keywords{Peer-to-Peer, P2P, security, Distributed systems, Hypermedia systems} |
\keywords{Peer-to-Peer, P2P, security, Distributed systems, Hypermedia systems} |
31 |
|
|
32 |
\avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut j?rjestelm?t, hypermedia-j?rjestelm?t} |
\avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut järjestelmät, hypermedia-järjestelmät} |
33 |
|
|
34 |
\contactinformation{\\ |
\contactinformation{\\ |
35 |
Hermanni Hyyti?l?\\ |
Hermanni Hyytiälä\\ |
36 |
Huhtalammentie 5 as. 17\\ |
Huhtalammentie 5 as. 17\\ |
37 |
40640 JYV?SKYL?\\ |
40640 Jyväskylä\\ |
38 |
s?hk?posti: hemppah@cc.jyu.fi} |
sähköposti: hemppah@cc.jyu.fi} |
39 |
|
|
40 |
|
|
41 |
\abstract{ |
\abstract{ |
51 |
related data from Peer-to-Peer network. |
related data from Peer-to-Peer network. |
52 |
} |
} |
53 |
\tiivistelma{ |
\tiivistelma{ |
54 |
T?ss? opinn?ytety?ss? arvioimme olemassaolevia vertaisverkkoja, protokollia ja |
Tässä opinnäytetyössä arvioimme olemassaolevia vertaisverkkoja, protokollia ja |
55 |
niiden erityisominaisuuksia. Teemme yhteenvedon olemassa olevista ongelmista |
niiden erityisominaisuuksia. Teemme yhteenvedon olemassa olevista ongelmista |
56 |
vertaisverkoissa ja jaamme ongelmat kolmeen alakategoriaan. Havaitsemme, ett? |
vertaisverkoissa ja jaamme ongelmat kolmeen alakategoriaan. Havaitsemme, ett? |
57 |
on olemassa useita ongelmia, joihin ei ole ratkaisua lainkaan, tai on ehdotelma |
on olemassa useita ongelmia, joihin ei ole ratkaisua lainkaan, tai on ehdotelma |
58 |
ongelman ratkaisemiseksi, mik? k?yt?nn?ss? on kuitenkin mahdotonta toteuttaa. |
ongelman ratkaisemiseksi, mikä käytönnössä on kuitenkin mahdotonta toteuttaa. |
59 |
|
|
60 |
T?m?n j?lkeen annamme yleiskuvan Fenfire-j?rjestelm?st?. |
Tämän jälkeen annamme yleiskuvan Fenfire-järjestelmästä. |
61 |
Arvioimme olemassaolevia vertaisverkkoarkkitehtuureja-- l?yh?sti ja tiukasti |
Arvioimme olemassaolevia vertaisverkkoarkkitehtuureja-- löyhästi ja tiukasti |
62 |
rakennettuja p??llysverkkoja-- Fenfiren vaatimusten valossa. Lopuksi ehdotamme |
rakennettuja päällysverkkoja-- Fenfiren vaatimusten valossa. Lopuksi ehdotamme |
63 |
yksin-kertaisia algoritmeja, joiden avulla voidaan tehokkaasti l?yt?? |
yksin-kertaisia algoritmeja, joiden avulla voidaan tehokkaasti löytää |
64 |
vertaisverkosta Fenfire:n kannalta olennaista tietoa |
vertaisverkosta Fenfire:n kannalta olennaista tietoa |
65 |
} |
} |
66 |
|
|
509 |
\exists s \in S$, $ip = map(identifier(s)) \wedge (provider(s) = p)$\}., |
\exists s \in S$, $ip = map(identifier(s)) \wedge (provider(s) = p)$\}., |
510 |
which means that resources which peer provides into the system are not kept locally. |
which means that resources which peer provides into the system are not kept locally. |
511 |
Every $p$ has neighbor(s), named as $neighbor$, which are $P$ = \{$p \in P: \exists neighbor$, |
Every $p$ has neighbor(s), named as $neighbor$, which are $P$ = \{$p \in P: \exists neighbor$, |
512 |
where $difference(p,p_neighbor)= ''close''$, where ?$''close''$ is small difference $d$ in $(IS,d)$\}. |
where $difference(p,p_neighbor)= ''close''$, where $''close''$ is small difference $d$ in $(IS,d)$\}. |
513 |
|
|
514 |
|
|
515 |
\section{Summary} |
\section{Summary} |
925 |
al \cite{296824}. |
al \cite{296824}. |
926 |
|
|
927 |
Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam |
Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam |
928 |
attack, hostile or faulty peer may produce false information of the data. Possible solution againts this attack |
attack, hostile or faulty peer may produce false information of the data, or refuses/is not able to reply to requests. |
929 |
is that peer should not trust to single entity. Instead peer should get information from multiple entities and trust |
Possible solution againts this attack is that peer should not trust to single entity. Instead peer should get |
930 |
on majority's opinion. This methods requires more messages to be sent to network increasing the load of system. |
information from multiple entities and trust on majority's opinion. This methods requires more messages to be |
931 |
However, if Spam attack is combined with Sybil attack, obviously previously mentioned solution doesn't work. |
sent to network increasing the load of system. However, if Spam attack is combined with Sybil attack, obviously |
932 |
Again, more research is required to solve this attack model reliability. Naor et al. \cite{naor03simpledht} has |
previously mentioned solution doesn't work. Again, more research is required to solve this attack model |
933 |
proposed a partial solution againts Spam attack with \emph{faulty} peers (not hostile). |
reliability. Naor et al. \cite{naor03simpledht} has proposed a partial solution againts Spam attack with |
934 |
|
\emph{faulty} peers (not hostile). |
935 |
|
|
936 |
Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example, |
Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example, |
937 |
hostile entity can attempt to burden targetted peers with garbage packets. As a implication, peers may act |
hostile entity can attempt to burden targetted peers with garbage packets. As a implication, peers may act |
1648 |
|
|
1649 |
\chapter{Fenfire hypermedia system} |
\chapter{Fenfire hypermedia system} |
1650 |
|
|
1651 |
In this chaper we give an overview of Fenfire system and its objectives. We also |
In this chaper we give an overview of Fenfire system. We also |
1652 |
describe briefly xanalogical model. At the end of this chapter we study Storm, |
describe briefly xanalogical model. At the end of this chapter we study Storm, |
1653 |
Fenfire's software module, which is an essential part of Fenfire's Peer-to-Peer |
Fenfire's software module, which is an essential part of Fenfire's Peer-to-Peer |
1654 |
functionality. |
functionality. |
1687 |
scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In this |
scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In this |
1688 |
example, when character 'D' is is first typed in, xanalogical storage model |
example, when character 'D' is is first typed in, xanalogical storage model |
1689 |
acquires a permanent identifier for that character and retains it when character |
acquires a permanent identifier for that character and retains it when character |
1690 |
is copied to different document. Thus, identifier distinguishes chararacter from |
is copied to different document. Thus, the identifier distinguishes chararacter from |
1691 |
all similar characters typed in independently\footnote{Xanalogical storage model |
all similar characters typed in independently\footnote{Xanalogical storage model |
1692 |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
1693 |
frames of video.}. The connectivity in xanalogical storage model between data content |
frames of video.}. The connectivity in xanalogical storage model between data content |
1887 |
locating data efficiently in the Peer-to-Peer overlay. There are two main |
locating data efficiently in the Peer-to-Peer overlay. There are two main |
1888 |
reasons for this. First, Kamdelia's XOR-based distance function is superior |
reasons for this. First, Kamdelia's XOR-based distance function is superior |
1889 |
over the distance functions of other systems. Second, there are already some |
over the distance functions of other systems. Second, there are already some |
1890 |
real-life systems (e.g., \cite{overneturl}, \cite{edonkey2kurl}, \cite{kashmirurl}), |
real-life systems (e.g., \cite{overneturl}, \cite{edonkey2kurl}, \cite{kashmirurl}, |
1891 |
which means that Kademlia's algorithm is simple and easy to implement. |
\cite{kato02gisp}), which means that Kademlia's algorithm is simple and easy to implement. |
1892 |
|
|
1893 |
In top of Kademlia, we propose the usage of Sloppy hashing \cite{sloppy:iptps03} which |
In top of Kademlia, we propose the usage of Sloppy hashing \cite{sloppy:iptps03} which |
1894 |
optimized for DOLR abstraction of tightly structured overlays. With Sloppy hashing, |
optimized for DOLR abstraction of tightly structured overlays. With Sloppy hashing, |
1995 |
\end{figure} |
\end{figure} |
1996 |
|
|
1997 |
|
|
1998 |
|
\subsection{Problems} |
1999 |
|
|
2000 |
\chapter{Open issues and future work} |
Perhaps the most biggest issue in Peer-to-Peer systems is non-maturity of |
2001 |
|
secure techologies. For instance online entities cannot be identified |
2002 |
|
safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one |
2003 |
|
security related problem occurs when user wants to perform global data lookup with a given |
2004 |
|
pointer random string; how user is able to verify the correctness |
2005 |
|
of the search results, and how do we know which one is the |
2006 |
|
correct Storm scroll block ? Spam attack is variation of previously |
2007 |
|
mentioned problem; data lookup is performed by a user, but there is no reply |
2008 |
|
from the system. How do we are able to know if this was a spam attack, or the |
2009 |
|
data really no exist in the system ? Another problem related to Fenfire's |
2010 |
|
security is that if a user downloads data from the network to local computer |
2011 |
|
and after network disconnetcion, user wants to verify \emph{offline} the |
2012 |
|
authenticity of data. Obviously, optimal solution to all security issues would |
2013 |
|
be that digital signatures are included to every message sent in the system. |
2014 |
|
However, these problems are not only limited to Fenfire, it concerns all |
2015 |
|
Peer-to-Peer based computer systems. We believe these problem is solved in a |
2016 |
|
near future as very intesive research is carried out in Peer-to-Peer field. |
2017 |
|
|
2018 |
One of the most important issues in Peer-to-Peer networks is the fact that |
\chapter{Conclusions and future work} |
|
online entities cannot be identified and verifyied safely. For our purposes |
|
|
this is a problem when user wants to perform global search with a given |
|
|
urn-5 random string. For instance, how user is able to verify the correctness |
|
|
of the search results ? Which one is the correct scroll block ? Furthermore, |
|
|
if user downloads data to local computer and wants to verify \emph{offline} |
|
|
that data really came from the entity which it was supposed to. These problems |
|
|
are not only limited to our Storm design, it concerns all Peer-to-Peer |
|
|
based computer systems. However, we believe this problem is solved in a near |
|
|
future as Peer-to-Peer networks will come more and more important in |
|
|
computing world. |
|
|
|
|
|
-benefis over p2p filesharing programs |
|
|
|
|
|
-'get me block XYZ' |
|
|
-there is no reply, how do we are able to know if this was a spam attack, or the |
|
|
data really no exist in the system ? |
|
|
|
|
|
-search engine ? |
|
|
|
|
|
-digital signature on messages (no spam attacks) ? |
|
|
-lack of working PKI architecture |
|
|
|
|
|
Our future work includes support for searching transclusions and xanalogical |
|
|
links in a Peer-to-Peer network. Specifically, we want to find transclusions |
|
|
or xanalogical links in a global scale. Preliminary analysis have showed |
|
|
that these questions are rather different than locating scroll or pointer |
|
|
blocks \emph{directly} from the network. Techiques used in distributed |
|
|
database systems may prove to be useful. However, more research is needed |
|
|
in this area. |
|
|
|
|
|
\cite{kato02gisp} |
|
|
|
|
|
In the following months, we will implement a working Storm Peer-to-Peer |
|
|
prototype. Potential candidates for tightly structured overlays are |
|
|
Kademlia \cite{maymounkov02kademlia}, Koorde \cite{kaashoek03koorde} and |
|
|
Chord \cite{stoica01chord}. One possibility for future work is to |
|
|
implement multisource downloading, which would creatly improve the |
|
|
performance of fetching large amounts of scroll blocks from the network. |
|
|
Additionally, we will likely use both DHT and DOLR methods when performing |
|
|
data lookups in the network. DOLR is used under normal condition and DHT |
|
|
when inviduals wants mirror their data to other peers. Again, future work |
|
|
is required how to implement this sensibly way. |
|
|
|
|
|
|
|
|
\cite{gribble01p2pdatabase} |
|
|
|
|
|
\chapter{Conclusions} |
|
2019 |
|
|
2020 |
In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms and |
In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms and |
2021 |
their properties. Currently, two main Peer-to-Peer overlay approaches |
their properties. Currently, two main Peer-to-Peer overlay approaches |
2045 |
of locality in tightly structured overlays. Finally, we believe that issues |
of locality in tightly structured overlays. Finally, we believe that issues |
2046 |
related to tightly structured overlays are solved in near future, because of |
related to tightly structured overlays are solved in near future, because of |
2047 |
wide and intensive co-operation among research groups. |
wide and intensive co-operation among research groups. |
|
|
|
|
|
|
2048 |
|
|
2049 |
\bibliographystyle{gradu} |
Our future work includes support for searching transclusions and xanalogical |
2050 |
\bibliography{progradu} |
links in a Peer-to-Peer network. Specifically, we want to find transclusions |
2051 |
|
or xanalogical links in a global scale. Preliminary analysis have showed |
2052 |
|
that these questions are rather different than locating scroll or pointer |
2053 |
|
blocks \emph{directly} from the network. Techiques used in distributed |
2054 |
|
database systems may prove to be useful. Some fundamental results |
2055 |
|
regarding Peer-to-Peer and database systems has already been |
2056 |
|
presented \cite{gribble01p2pdatabase}. |
2057 |
|
|
2058 |
|
As security techologies comes more mature, we wish to apply these |
2059 |
|
techologies with Fenfire, if applicable. |
2060 |
|
|
2061 |
|
In the following months, we will implement a Fenfire Peer-to-Peer |
2062 |
|
prototype. |
2063 |
|
|
2064 |
|
\bibliographystyle{gradu} |
2065 |
|
\bibliography{progradu} |
2066 |
\end{document} |
\end{document} |