[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/02/20 06:48:01

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 

Log message:
        Reorg

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.53&tr2=1.54&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.53 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.54
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.53       Thu Feb 
20 06:32:58 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Thu Feb 20 
06:48:00 2003
@@ -706,120 +706,9 @@
 
 \subsection{Attacks}
 
-\subsection{Data authenticity and integrity}
-
-\subsection{Anonymity}
-Anonymoys \cite{352607}
-Anonymoys \cite{293447}
-
-\subsection{Access Control}
-\subsection{Fault-tolerance}
-\subsection{Hostile entities}
-\subsection{Secure Query Routing}
-\subsection{Other Security threds}
-
-
--Could we use SDSI/SPKI in our system (it's hierarchical), like in ConChord 
\cite{ajmani02conchord}
--is there any other implementations of SDSI/SPKI-like systems ?
--SDSI/SPKI is not optimal for us, but somewhat working solution
--in our model: trust = trust no one
--give a brief explanation of current techiques in accountability and trust
-
-%Tuomas' example scenario #1(in finnish):
-
-jos joku sanoo, ett? urn-5 foo on blokeissa X
-ja j?tt?? blokit Y pois
-miten systeemi selviytyy ?
-eli kuinka pahasti pystyy mit?kin spooffaamaan, mill? todenn?k?isyyksill?
-tai jos vaan ei haluta antaa joillekin koneille jotakin blokkia
-niin miten helppoa on organisoida sellainen hy?kk?ys
-tai halutaan hukata verkosta tietyt blokit
-floodaamalla indeksi
-mutta sitten poistamalla ne serverit
-
-Solutions:
-1) periodically (cross) checking the consistency of routing tables with 
randomly chosen other nodes
-
-%Tuomas' example scenario #2:
-'What will happen if, jyu's network connection is broken ? Inside jyu network, 
how do we/system will self-organise ?'
-
-Solution: 
--SkipNet is able to self-organise after a organization has been disconnected 
from the network
--However, SkipNet uses Pastry as routing layer. Kademlia/Symphony would be 
better choice
--network partitions: techniques for maintaining DHT structure in real and 
dynamic environment \cite{rowston03controlloingreliability}
-
-%Tuomas' example scenario #3:
-'What will happen if a malicious node quantities large amounts of data in the 
system ?'
-
-Solutions:
-1) centralized: Per node based quotas based on reliable identification of 
publishers (usually requires CAs to work correctly)
-2) decentralized: Per node based quotas based on the ip address of the node
-
-It seems to be that DHTs are unable to self-reorganise rapidly after a sudden 
partitioning, because
-a) every node has a fixed space in identifier space
-b) system has a fixed identifier space, e.g. Pastry and Chord require a priori 
knowledge about the size of the system
-c) even if system is able self-reorganise, the key space is not uniformly 
distributed anymore -> all nodes have to leave/rejoin --> lot of traffic
-
-To ensure data availability:
-System myst maintain the desired level of replcation as nodes join and leave 
the system in order to. If nodes often join/leave the system
-for a short time before leaving (i.e. short 'half-life'), replicas will be 
wasted. Therefore, system should have a support foe lazy replica
-copying
-
-
-Network proximity: 
--\cite{pias03lighthouse}, \cite{ng02predicting}
-
-Efficient searching:
--result caching and view trees \cite{Bhattacharjee03resultcache} (insight: 
store and and retrieve prior results from view tree)
--bloom filters \cite{362692}
-
-Better load balancing techiques:
--Better and simple load balancing \cite{byers03dhtbalancing} (insight: "power 
of two choices" whereby an item is stored at the less loaded of two (or more) 
random alternatives)
-
-%One question is: how well SWAN can self-organise, e.g. in the case of Tuomas' 
scanario #2 ?
-
-Half-life phenomenon \cite{libennowell01observations}
-%Current decentralized, but structured \cite{chord, can, pastry, Tapestry 
etc.) ignores the fact 
-that a P2P system is never in 'ideal' state. P2P system is always evolving 
system.
-
--techniques for maintaining DHT structure in real and dynamic environment 
\cite{rowston03controlloingreliability}
--this is not problem any more for structured p2p overlay networks
--results can be directly applied to other DHTs
-
-Half-life concept:
-'Let there be N live nodes at time t. The doubling from time t is the time 
that pass before
-N new additional nodes arrive into the system. The halving time from time t is 
the time
-requires for half of the living nodes at time t to leave the system. The 
half-life from 
-time t is smaller of the properties stated above. The half-life of the entire 
system is the 
-minimum half-life overl all times t.'
-
-Heterogeneity
-%Current decentralized, but structured \cite{chord, can, pastry, Tapestry 
etc.) designs assume
-that all participating peers are equal, in terms of processing power, memory 
and network bandwidth.
-However, recent measurement study \cite{saroiu02measurementstudyp2p} exhibits 
the fact that in p2p networks, 
-there is a great amount of heterogeneity among participating peers.
-
-Proposal, Brocade: Landmark routing on overlay networks \cite{zhao02brocade}
--Secondary overlay layer on top of routing layer, which exploits knowledge of
-underlying network properties
-
-
-Security issues related to p2p, create by Ross Lee Graham:
-http://www.ida.liu.se/~rosgr/p2psecurity.html
-
-Symphony seems to be the first DHT system which support hetergeneity 
\cite{gurmeet03symphony}
-
-Notes from from \cite{hearn02mojonation}
-Open problems in p2p data-sharing:
-1) Attack resistance
-2) malicious nodes
-3) mutual distrust
-4) motivation to cooperate
-
-Other:
-a) Frequent join / leave caused poor data availability; discriminate againts 
newly joined zones
-b) Splitting data into a set of shares decreased data robustness
-
+1) Sybil attack \cite{douceur02sybil} 
+2) Fail-stop
+3) Spam generating model \cite{naor03simpledht}
 
 Decentralized, but structured
 a) Censorship Resistant Peer-to-Peer Content Addressable Networks 
\cite{fiat02censorship},
@@ -843,14 +732,6 @@
 c) Are there lower bounds for average degree of nodes, query path length etc. 
for a network that is
 fault tolerant to linear number of adversial faults ?
 
- 
-5.6. Attack models/behavior of faulty nodes
-
-1) Sybil attack \cite{douceur02sybil} 
-2) Fail-stop
-3) Spam generating model \cite{naor03simpledht}
-4) Byzantine problem \cite{357176}, p2p domain \cite{296824}
-
 Solutions for Sybil Attack: 
 1) data replication among several peers
 2) data fragmentation among several peer
@@ -860,47 +741,25 @@
 -in p2p environment, trusting to collective assurance of multiple signatories 
(like PGP) is not safe/undermines the authenticity of system (because of sybil 
attacks)
 -\cite{douceur02sybil} argues that Sybil attacks are always possible except 
under extreme and unrealistic assumptions of resource parity and coordination 
among entities
 
-Current research with regard to p2p security:
--lot of done has been done on persistence
--little has been done on distinctness (sybil attack)
--computational puzzles for preventing DDOS attacks (force attacker perform 
more work than victim)
--puzzles can be used for accountability (Dingeline, in Peer-to-Peer: 
Harnessing...), but can dangerous
--some research has been done on on-line identities for humans. However, they 
often has a direct relation to phychical world
-
-
-5.3. General security issues related to decentralized, but structured 
strategies
-
-Secure routing requires \cite{castro02securerouting}:
-1) a secure assignment of node identifiers
-2) secure routing table maintenance
-3) secure message forwarding
-
-General security considerations \cite{sit02securitycons}
-1) Define verifiable system invariants (and verify them!)
-2) Allow querier to observe lookup progress
-3) Assign keys to nodes in a verifiable way
-4) Server selection in routing may be abused
-5) Cross-check routing tables using random queries
-6) Avoid single points of respinsability
-
-5.2. Open Problems in p2p data-sharing \cite{daswani03openproblems}
-
-Search
-a) Query rigidity
-
-b) Autonomy, efficiency and Robustness
-
-c) Quality of Service, QoS
 
+\subsection{Data authenticity and integrity}
+-Could we use SDSI/SPKI in our system (it's hierarchical), like in ConChord 
\cite{ajmani02conchord}
+-is there any other implementations of SDSI/SPKI-like systems ?
+-SDSI/SPKI is not optimal for us, but somewhat working solution
+-in our model: trust = trust no one
+-give a brief explanation of current techiques in accountability and trust
 
-Security
-a) Availability (Gzz: priority 3)
 
-b) Data Authenticity (Gzz: priority 1)
 
-c) Anonymity (Gzz: priority 4)
+\subsection{Anonymity}
+Anonymoys \cite{352607}
+Anonymoys \cite{293447}
 
-d) Access Control (Gzz: priority 2)
+\subsection{Access Control}
+\subsection{Fault-tolerance}
+\subsection{Hostile entities}
+\subsection{Secure Query Routing}
+\subsection{Other Security threds}
 
 
 \cite{daswani03openproblems}
@@ -957,6 +816,13 @@
 2) message duplication should be minimized
 3) each additional step during search should not significantly increase the 
number of nodes visited
 
+Network proximity: 
+-\cite{pias03lighthouse}, \cite{ng02predicting}
+
+Efficient searching:
+-result caching and view trees \cite{Bhattacharjee03resultcache} (insight: 
store and and retrieve prior results from view tree)
+-bloom filters \cite{362692}
+
 
 \subsection{Efficient data lookup}
 \cite{ratnasamy02routing}
@@ -990,6 +856,40 @@
 \cite{chord:om_p-meng}
 
 \subsection{System management}
+
+Symphony seems to be the first DHT system which support hetergeneity 
\cite{gurmeet03symphony}
+
+
+Better load balancing techiques:
+-Better and simple load balancing \cite{byers03dhtbalancing} (insight: "power 
of two choices" whereby an item is stored at the less loaded of two (or more) 
random alternatives)
+
+%One question is: how well SWAN can self-organise, e.g. in the case of Tuomas' 
scanario #2 ?
+
+Half-life phenomenon \cite{libennowell01observations}
+%Current decentralized, but structured \cite{chord, can, pastry, Tapestry 
etc.) ignores the fact 
+that a P2P system is never in 'ideal' state. P2P system is always evolving 
system.
+
+-techniques for maintaining DHT structure in real and dynamic environment 
\cite{rowston03controlloingreliability}
+-this is not problem any more for structured p2p overlay networks
+-results can be directly applied to other DHTs
+
+Half-life concept:
+'Let there be N live nodes at time t. The doubling from time t is the time 
that pass before
+N new additional nodes arrive into the system. The halving time from time t is 
the time
+requires for half of the living nodes at time t to leave the system. The 
half-life from 
+time t is smaller of the properties stated above. The half-life of the entire 
system is the 
+minimum half-life overl all times t.'
+
+Heterogeneity
+%Current decentralized, but structured \cite{chord, can, pastry, Tapestry 
etc.) designs assume
+that all participating peers are equal, in terms of processing power, memory 
and network bandwidth.
+However, recent measurement study \cite{saroiu02measurementstudyp2p} exhibits 
the fact that in p2p networks, 
+there is a great amount of heterogeneity among participating peers.
+
+Proposal, Brocade: Landmark routing on overlay networks \cite{zhao02brocade}
+-Secondary overlay layer on top of routing layer, which exploits knowledge of
+underlying network properties
+
 \cite{sloppy:iptps03}
 \cite{libennowell01observations}
 \cite{karger02findingnearest}
@@ -1019,7 +919,15 @@
 \cite{cornelli02reputableservents}
 \cite{oram01harnessingpower}
 \cite{golle01incentivesp2p}
-\cite{hearn02mojonation}
+
+Notes from from \cite{hearn02mojonation}
+
+1) Attack resistance
+2) malicious nodes
+3) mutual distrust
+4) motivation to cooperate
+
+
 
 \subsection{Usage patterns}
 \cite{saroiu02measurementstudyp2p}
@@ -1050,6 +958,29 @@
 3) Centralized
 -no recent research efforts/no interests
 -not suitable for real p2p, as Napster case showed
+
+Current research with regard to p2p security:
+-lot of done has been done on persistence
+-little has been done on distinctness (sybil attack)
+-computational puzzles for preventing DDOS attacks (force attacker perform 
more work than victim)
+-puzzles can be used for accountability (Dingeline, in Peer-to-Peer: 
Harnessing...), but can dangerous
+-some research has been done on on-line identities for humans. However, they 
often has a direct relation to phychical world
+
+
+5.3. General security issues related to decentralized, but structured 
strategies
+
+Secure routing requires \cite{castro02securerouting}:
+1) a secure assignment of node identifiers
+2) secure routing table maintenance
+3) secure message forwarding
+
+General security considerations \cite{sit02securitycons}
+1) Define verifiable system invariants (and verify them!)
+2) Allow querier to observe lookup progress
+3) Assign keys to nodes in a verifiable way
+4) Server selection in routing may be abused
+5) Cross-check routing tables using random queries
+6) Avoid single points of respinsability
 
 
 \scriptsize