Changes between Version 19 and Version 20 of petconpaper

Mar 2, 2009 5:10:32 PM (10 years ago)



  • petconpaper

    v19 v20  
    66PET-CON 2009.1
    8 DRAFT 2009-03-01 03:10 UTC
     8DRAFT 2009-03-02 17:10 GMT
    21 <h2>Overview of I2P</h2><ul> - echelon does this part
    23         <li> Unidirectional tunnels, garlic (~= onion) routing, hidden services...
    24         <li> Started by jrandom in 2003; vanished in late 2007
    25         <li> ~800 routers == peers == users at any given time
    26         <li> ~50-100 new routers/day
    27         <li> 7 releases in 2008
    28           (pic from stats.i2p)
    29         <li> Total usage currently: ~10MBps, ~40K tunnel hops
    30         <li> Network growth: doubled in last 6 months
    31           (pic from stats.i2p)
    32         <li> Hidden services oriented - P2P friendly - only one HTTP outproxy (~= "exit node")
    33 </ul>
    3522<b>NOTE TO ECHELON: I did some editing/cleanup in your sections too.</b>
    150 <p>
    151 <h2>Tunnel Overview</h2><ul> - echelon will do this part
    153         <li> Client tunnels - for all user-generated traffic
    154         <li> Exploratory tunnels - low bw, used by the router for tunnel builds, tunnel tests, netdb queries...
    155              and for "exploration", as we will see below...
    156         <li> Tunnel lifetime 10m
    157         <li> Selected by each peer
    158         <li> Strict ordering within a tunnel (predecessor attack)
    159         <li> Tunnel build request can be rejected or dropped for a number of reasons
    160         <li> Periodic testing of each tunnel (~1KB per minute)
    162 </ul>
    163 <h2>NetDB Overview </h2><ul> - echelon will write this
    165         <li> RouterInfo for each router, and LeaseSet (~= "hidden service descriptor"), not discussed here
    166         <li> K/L/M/N/O bw classes ( &lt;12 / 12+ / 32+ / 64+ / 128+ KBps of configured shared capacity)
    167              for each router
    168         <li> Information only, not used for any routing decisions...
    169         <li> ...Except that K routers are not used
    170         <li> Lots of stats in there for network debugging, but NOTHING is trusted or used except IP/port (and "K")
    171         <li> Serious anonymity and DOS implications if we trust claimed capacity ("low-resource attacks")
    172         <li> L is the default, so about 96.5% of routers are L-O, and route for others
    173           (pic from stats.i2p)
    175 </ul>
     136 NetDB Overview
     138The NetDB is a collection of information stored on each peer. It containes for
     139each peer the RouterInfo and for each known service the LeaseSet , which is the
     140hidden service descriptor.LeaseSet will not be described here, for more info
     141into this topic look into the i2p website (ref).
     142the routerInfo is a small collection of all vital information describing a peer.
     143E.g. the IP, port, peer ID, I2P stable version number, net ID version, and some
     144statistical bandwith data are included. All of the these data are not trusted by
     145the peer except for the K classification of bandwith.
     146Each peer is set by default to 32kbit input and 32 kbit output bandwith with
     14790% share percantage (90% of maximum bandwith is allowed to be used up by
     148participating tunnels). These peers will fit into the L class of bandwith.
     149Each peer is sorted into a bandwith class based on the configured shared
     150bandwith: These classes are named K,L,M,N,and O. Limits are <12 kbit/sec for K,
     15112+ L, 32+ M, 64+ N,128+ kbit/sec O. This classification is just for information
     152and except the K class not used for any routing information (peers of K class
     153are not used at all for routing participating tunnels). Statistics shows only
     154a small number of K class routers (96 % are class L-O) which indicates most
     155peers are capable of routing tunnels.
     156But if we trust these (user set) classification, serious anonymity issues and
     157DOS implications (like the "low-ressource attacks") will rise up.
     158This led to the following implementation of peer profiling.
    176163<h2>Peer Profiling and Tiers  </h2>