From ea3bf3ffc8537277bb45f8694cf634cc64d70f85 Mon Sep 17 00:00:00 2001 From: jrandom Date: Mon, 3 Oct 2005 06:21:08 +0000 Subject: [PATCH] might as well commit this draft --- router/doc/net.png | Bin 0 -> 24115 bytes router/doc/techintro.html | 982 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 982 insertions(+) create mode 100644 router/doc/net.png create mode 100644 router/doc/techintro.html diff --git a/router/doc/net.png b/router/doc/net.png new file mode 100644 index 0000000000000000000000000000000000000000..6eac3784245e13c794795634b797ec2ea0a2eab1 GIT binary patch literal 24115 zcmdRV^;;WX^k$1oix#)yrFd~jaHkMj+*{lVMH{?=7WYyhIKkbaP}~U++$kC~K=1&| z=exUq!#+E|oqObcpL6frnRDk%gtnH-a{^j|Cr_R{S5sAd|Kte<f=*?Um7L7n_B_4^JLg*jdmq^wz3a#U;@3<6G-AYc!Tpu=!hEov0D;@56B{HQr}B zJ!o`s8G2`thXAW4>QllZddv&! zU%!6U4J<<+VmXMAXx!(ZYdbDcdm=4pRaNDP2n1HZE!qHl69GYspgB3^n(jyD%du_( zusl7w(T*W)d%?fmvC#L{6UF|O_^!Hr*60%53|}*!`#K)W3^X;!EwX@$nzDG!y2ByX z$H#j(6AJ(Y)^1(X(7g5!MBn=7_#0y#UJRlKX9v>2+f6^wRA{shN*k=*)Kq6?V${@x zLSy*D(Q7Va=r|`sSAs_@?Ae*|N4 z_J4)Q#ykanqsR2ckibDX-Z@z%Aey#}`B6<-;oDI}b4>*UCyMFuK`#Lb2vr2qc$VEBhnN;67Q|q6V z!NI?HSLauc^gw!k z>biU~LRDlxRIE7ZLN2h!j??r&bikau{2nfSyEA`}BGBe zO@2CY2HM;7dKY`3%ZIC|i&F8mjM$js%J5GtZvSRD_! zUt%>BpaQ$L0ug_M(DfXmE)G^)l$ss&lZRg)E~M9)w#ywjJ0j-hj~PDuS-AN6Dv^nV zc_x_G8E(6jG;q#Q5fMp!VV#2aDt4%XR*{k@I$e|Y<0Ynnr5umdS2ZnPMy^HHG2n34e zNO`v4$9fv3sF*lF3F1-m_3h4;HTeFMp~X>nibQP-n5@M!p)!x&rUzovaioY2Mr-R4 z^W6!2py3FxG z$K><97Z%02e-d>wPa}Gd&CcGFS>nZt!u8n4J!<`*eSewozGEr&$YIE9OBTfI2=To7 zV`q-?jEr3*WM^)RXV=ii9yV%gSM_8_cwttospKj;$U7P%Y{P`$a6A1V5WbW8ERg99 zzpuR9GMvR&?#lHwPG_!yl224+a%s*%kzU@y%X!x-&^f(n-g2kNiKsDP&kfCMGXpnB z?KIt+hudd!GMRF}I|;{hSa;P;{>s*tQlaNXt0g=+XrWJ6$XLM=QmO(B)Hnh$0Bd`V z!y*2kzoR-z$$4%vCvEh4=FUnrmlLbR*vv&MUg+o~4LiAC2J<>>3yQec??P1;j^ z2lGK(u$76x6{ET!V%nCM-~@Oa&!%MuEj#juvYr9X&-T_^mHwS3qr`Mb?^p49Da^iyM9T^nWGo@v@&K#MdhU=h_ism{@ zDm0dbZB^en*gKS`Rwc@!lc10SAnJQdt}xE*bDLGXq^4b+iOLtzV-k9Pt(Y-pQZhg( zJQb;b9GR_FEDc?V2&I-#u0j+*l7;1nesY&4aGl*`uBz5scpAf(4@9czA$QNbD!~09 zDRIqxupUv}jjA09Gmqn=7wIAb9?etOSiCd*_GaSjWvs8IFxy2Hsa+W~TzDdJV57#! z6Y$PzIE5V8F=Vf7L+WW?J#fJo#p7yRGY0e^VW9JWKFZ{^MN)O+Dy#a$^b- zUw-5YD}z|Kv1_w~hM4QJf)oP%dV5jN&{c2E4fsS3_a66t0k!DYrm;r<@}aghBqi)9 zVJiv|o&1+pG(b1rsN8HjQQLD=SNolrwcYh<(U(RlIGoqp9%vRcj^d|l4`SFK9Fn>8 z_M?cYg|wkOH?q{*W)r*n?Tly4sKlQ-T56uk}eGp1-2)7m=dliIWSta#4>k*HJMfu^;YvQJY`ZV ziL3y+Ee9(w0{HS3?KA~dT5TAE_U6Tl4k*j%y^ji+(gyl6av-9m-w5LtbNs#n%Lvqf zK+!{*J)@i7o^cIRjw->Eo`k#2!nMBtv|)DD5YBkW!gt@BOUyAj1(2=E?enR+Wi)~- z$DUN|<>0$AsG>r#hH^GbjbMPPI)X;4naOJd-y%oJ?<5!4=P$_2w*}vM`l}v1y z7~i!fZxK`!|JQ8GWYnItk(c|9vVeG&%&-y&QwciNR0NheE@shDC>)-V5+OG#9s`rL$8?V{H&z?4mTfRM|@wDp_v};0K{LA5NNg zxm2rV6TULsba0x?Q1I&EiPhnjkmxycd?F;2DKuDOa(E1;EOgv_yqsyb?ta_)`8*s8 z^oCO7o&PSjt9CzLW~0#zW6Go%O`TTSLx0%!meo-G9OU<8=@-F)Tha14qHsJmk+UOyrnV)f^yV{M=w`gP zF1xSyhp+PWHRjfU$K#Dd(Ns*epg4I04gMaJd?m8JwmOr`&yhEXDoSb4X*LJ@S7D)1 zQ@dThUnl9lGtDH9`FVfwb}UHC-9YY7j!7i3daPGy+ecea5LA-Ke(X%>GLkwm=3nAP z8!H68IoHjc)Y&msqv`~~kXnY2$8A;QfZ;G{APeEXX%8$`Mg_ZDGsdm_;cFy3EY^9x z{F0mffFf}pJDLT&Pa^F+SYdOh5vZa#zR-b+N2DwKh_z2CaZimEDmdRHp?B<4*UgqueA&ZRIM#r!@C|fo z?6C9w1{#r}dI@>GN=Ivs?db-R2%c+m zgcrs`HIz152C=OP`w;sxaV4P8!_FiEDs_35$w%YI$au$+>G!9KWxX+oUm&c#^5*q9 z>B;HQ(b2I!H?2j(!XcQ}^BbvMc$v(HoqC!wRxX0|a;P2U4uXbLrFbg*W+&iqtWf!v zzTeTf!?gvA$WWnOB-;wg+Y4xNUQB%*ttAp))iy%>akTNQX3i)p!)ctHV#n*~Btl1r zTw~|T-doI1ck_DxEsxD4`D`9n&h$C`MloZ?GpYgYGrfTIaW#_5odKT$k2Z`YfcSm{ zA}~hRQSoi>Z;3?OYOc$?g|XSN!mU3Nyd8OvEP{8t!`VB}_z6DI%0sC(nApeppoh-C zpZ1p$!+yAKS1>D9j=s*ZBr&auU?(^FCOQ}u2vZuJK6j4K_^qWev;W2PJfBdFE&k!! z^gWr12BGo!>_Vkb6T(49D!S<2Q24F44JJsBVNv*qI1$aOA+JAswzzr3S>Zc5_~hpI z@He{9Acp61l@){hzxrjyHe}_NZw6lg7oGLOJW$q5#R0R%wn(-3r=y2Q6^C2_m;>f`^Npln@EZB*snGP6Q6rTh$T2>QKmw9r(w?I z8mkM=#5e}P4vJj8e0jfl#(RhL9O#P_mWRzD#aiE#7UEAKe%Us3=jit-LZIQsTFv3r zpkGZwL2{G1@Aelikqrr@?uVB}?Hq@Vi#sZqWYMNJyQ!n&$!1ABKJ2Q}1zHr146VsX^A{ zbECK6Z;9-Wgpc5XY1bl0H7UW0OLc^$9WnMq?1KW!)sn3a3a9-<{lji-YlTpiSUI2F zks}G;Nr}+~gOVN8JCU-js-Bs|hC7nxTE{I{Er5a||WW0e2Ce zP$7*|m0Zq^yn)-Wtzzgv7gXuSH*twnxFO4C?gTLVk{Fu{2t(j|N=@v(5$RSliE*6B zTMWdSOFdoG3<}1|+I@9llGEOm5f}a|^0dF&kt$M^I+j;Qs6N)pFWf(uQ)Eh>c4(bh zv>L()WUcV&RLK=cb|1L zThQMkGq9ksZ+$rPTdn$cYPg{G-1b1>g6hLomm;VltzyrY=a5nel@f6nrnawdt};_Y z+`;pC5z@J2()Z^O6{-4e2GO>Ripw&uFOE_je-Q)Ft^ZiR$p2#Tu|7OuyjF;@6)*N= zF8OEIT*KU4B3g|8XRiI3W_;70!|w@(c*ba+@toa|btTS#8vEaqwNnK?+K=UG{$l?@ z6s&wE5eo)OzkkLx=ZscI#Q&H}wlNJWQ0BV{*V`m6hRByeKTUdlYF~_K{&Hmafm3nb z6BO3#D7^*VFP8KJf2o^)mG)E+=&)&R7gXq;_X&PhXBwDL&=Eo-2$Wf_Hy+*=n6u6s ziecF2dNCNAGU=h3$Qgeu4>+E}bF!xv|7G^w3A|p+1{ty+AWEf5%#Da3>w&AtMu zH_-R_78*Bbg2(_Mu{)Z{x9V>fLTvhbFvzTDSrmpdu~L_wYRf4IweLHznn9s2JaOmh>NNvdhTuP3tRwr4c+M<#5tNS6bSyWHO@vnlfZaAG}27Qh($wOm|BS zpb|k)tW`zubP5Eduo>kPG=+zzWI_xHzR)JCZ<@rsPgHqFSV*n`=Upt=L7dEoX$Il+ z6`92z4PNs-Nec;sP?mZVcCoV>ObZiAm5dyPg$#&S)iam=0;L3d5+ml$&;kt1OiuH! zfht@4TQ>V#v)z|l-k&xjG%2U<7AQ2J{ZQCr9_8DsBd%I|iEoC8)6T6;qA2?;9&4v; z-bdp1BRRCe3D1y_hZBIWL&A4?Tev1R|Im>W-Mt9=kk}bAG7JqRy zGD%|b%vw*A|AG~vPsPh{291^J8OUnfHP5~@2-dbIcaoz_$)Ww_MYL>rkP~KRBh<6l zqQyQG9?F!E4crbSI<|#-xT~sC0=uKr&TlS3m8ZJ0^-r>QjK%--+C2n+sYOUgu(3r# z%5N(h%EEAgvvQ^AQybIg339MaW@Z{xe!%ViEdQ>%Es$y0kPy?i;s<>3{*#rl;#1)46MP8MKSz=jk;} z4q)SB4JK25x+>Q1CNi-2U^Ds14{sMAxqf|krDFR0G_S2h{}O(BSOz~`B-|ZjAOkpD zj>W--&Z8oKyI&}c9%7?5iSQxrZP-UX*F0w~tma|C&aBy-uEtwT8?Y?_y?fKKX~AcU zxVwXNWPtugi@D`@*F1J6B8|_-6NQAqF}o2Xv%F zPC7M67CG{4caWSCAT!SUIj@$O`n#R2EC@2bCQ)dzhCJjAT}xvaPh{l*-)EbwNhhh0 z03@FHx(9D5TDTNLvj*3Mm{jJRMY1_%43RxOZ?6xoueKjUc*}wUtJc(1GN5*Eut0oY zAxl@C`U|e0e*VGC^bP*>dq4+9Hm8^&l0G>o%3cerGm$WxlfP^2di~idqZJ+`;|b8G z^ZU-|d>FB?i#&1@b9XR80Nl>gk$)@x66}tF+EmoVb@zMgYVp67xDEQkDZ_T2`*c_! z^REzpydOI-cn{bl#m-#JxeK}5lwXP>}6&Ug^|r@&fr99ZfW zQuZ;M|4H57q5k@|xGW0DP5j-oGy$-5EMM&N&P2{^J6l5}8anbi`6c)i8#O{e2zh)q zBV{*D@F0LkNBJL|((TWQ6$6b{YDzJ->Bl|X##-x*50QX?kM$kJajr1s^=|_tfa}MS za;U#@Ibp}Az@fLV3@)hV@oVy`W>-#Gc_p>E_Cq#`(I06zA^uO_AG_Aw z$};pNGfo?Le9Jo|)l!@wIOtB_3-+x035JkWFhii93THNhvrI`#NsCjN_Y8?ofgRvn zj~GUI?ws5;-%rsr&7T}LkuF6PSS55MAK1>hJk?z*VuLOD6tq_RZ*?MF##_=*VH0vP zWda14z*9TEjimepg+@(UO;GH;>Ih;lE=wM0f^5MRFRJ5 z;o$%1$|;MeAt8F}?*t$jXK%POwsvVi%l|n|_rsfGB-nG9-C^LpN=8U|gya`e&{4;M zT&u`KqV0ym|A1ROf|EawRs{5p4>TW%XZwJiQ|5#qm)ZY0u%}Q%EG_Y)b|nAgakJOj z0gmM!&8KRo`NMZ!<5rld4ol5?92^DDku*Q*6drYYsA~^`U5#pc>&At7N|19n59;Ht zn#ElqSXo86X0$^+$Ieq@K;wiiGnStp5l~(IAG?*vmS-?$*{qMxLf4D>1P^BVah>-C zd7Uq!b^?lqkuQqhJS)|W3-r@&(w2&P3L|71&mj90&U1j*%)i{T(ReBDk6YS`j3Ocy zIxBt-qVAIwG?4oFjdA3~v+W7FhKQ3kJ?@J`Q-7ZO^p(y>!x7q|b=rwg&L|e`3PxBN z-1l$XpuGQ75BR2E_h-QE;oO`^puW`4hx6 zRrE?(RdwAuO(fyh;{L=|s73#u(qSZ4O|IOgf(S$oGqCdMi|Ma+DfQ}#_^ShHltewB}fhbd}baTMJ z;|6x;)b&BiOye2IjUlWpd2j7>(!tBzm^iSFG>P0g7GM75)CSGjZ6~-3_n{tV9{~-Y z9Oe_sTMmaZ3*`Pl*4;?^QzuCihMVe2l!3Qh@Di$5+~x~#%^xOz4({9S7f0_L z*Km-Uh1%)zYP$ne;`k*q909}g&r8Yo6$PEjCWheO`p$L=&Z`v?&#_vmX6=D?CmYUX z!{drxxDcbx1?EhgAC7RYH7=X2`c2^Qb^nYQJ>$1lr!5B=@hYe1(f@ucu*%$AxSZ|l zE`Ni5G<@ZW`^w;*=Mj!xuA$|>#KNuV=%O~&*R_=#f>cmU?M@xeYT)Hk3S*v$&=B6(l>fcU0lg>`)fPrfk zWfgyQUQr?xk|0AShg$o-f2>)kXIf%QC+iD&ndwUV$>)aHk#1`LUk!_7#L}`^KEIX?o|Mnq}B|v>uxv@jX4$3!Ti&;zdE@?=8Tz!vwZOEwKCG zW|~;C`a09=W25)CZ#cQ1$wew*(iUO3o>%Y%rDCRMS zRV>u!V?yXz6W^tk3^+|XD*ouISTA~d2APP@?#zb06Q>|+nR`JHRQZ#4kB`6HU5qI7 zOjg~?JO8tl(ABwCU<83fZ=#S7O+qWV%NJ{*uDp@>(U8jUz1nTerJS!xYC|}T{^}u& zA3gv&@PL0UXE32?8;L-}^08Y0Db%RZ%B_qs6M)*cH(Nk%j*Y8VXf}!YVED#sEvBS? za%kg-52>F@!C z*735_%o(YF%|E@nzQ4lK{7;8Y_f9uuU_U3lHGVi%V7kqyiyY|}B=Y#Fvlm%9%F> zqprj}3%N(f(hV4odoQ2R<0|2*&UX^gvB>mX^|9s!OTKsdAf9UHZJUyYNa`u$jL3hl z#>-EHdtpimd z3i7e3tvjnTWJF|dg%r3TYVtc&%tq_@D?jebRQQPb8$p$hw*wUoYvHyVKQ7;KzlU2F zw8A6hl;sV9U6ZzL8z#c`-HDu1AwkDgal4?pjPLl% z*Ns+oVJ{)YQ)#{rj1;exa1>-a-)k>Qe{oZya|VSzDABByn0nU`X$V5S^2Vg%q!Ol= zr(IYt2(79QA)qND9cUm;>4EOifmwF>hS5Hu8>0D)v1~JPEA!HaXvE$(G*k&w=$Iks z`w1KQU+C<!=x$y;=5wF3E@MOO0(N8_GIqjI5nkhRCC~Lu$`HZrt418fMq@59 z=i-Bk!=hur-(4@Qz@Ezo=Q2&ky=Q0zku3UUoEo*yC)XI1SwhFdK6vX~=?K@mu&~9& zMID{RFuwtN>rp@D!iWFoc-;@?_gV@>>TW0IXtd4`MyaSPI@J^ zIlCXh=ini~Is3nfI{D4EC%bmeZxx0~!idp1T=_S*CVKlh6Db)Wfgi=oqoa5^rJ9tj zFzwX)x*)&3*0+nRYn`77$g}NT|Cr;_l`?0JDB^^M?SInB6&$S+1)Ntw^h?jH=kyVy zH(Lxf#$9^G$jw*|V+G&^j9$gRwC4-}F!C zIk!0&H5+<-r(ORaD3GD8J~S3hD>`hl*61^ojEAp;&y~FXqk3dL%L;(eS&weXA810?# z4ExU6S3!`>jQzrGaXGOOb}O}KpF&gyvDO?yExd{jSZyopiIT~K*@o2Qd2Avlre@0O z@9iKK7TuYxWD|=3K zd(0QQ>iAR_^^Fk#_w2>^^(?#bj?AnaP_qL$=Y8~La%Rg=`#@2$lhEslB2pJ!Ro884ot1`GQ-jxvhgR9iW zV0rigb-xl)$%o>(u=(Gl9%l*luSX4n7eYrPx@1fgX zt9^V!V{mQx@;7{r!ohn{b0FEz-tz_=#Dw5^n#pWQM1jwQUAi|TaXC*9^DtrwKP#MB zJ3kS2%#!TExHWZA;*xqE2f1K!ab;q>kO}FSb6({6+E`6Mc9Z7OGQ4^2i4g1@x$O(k}puPJwUWd$caOnJ)8gbJNf-v^_Da++qd3llU@PUft(^?5f34TL4 z`=XfV^*?$vK)C$B-zG+4Hj_M!6N~;DB%m`wN-T$5D$|)?V zq4`0(U6E_}EsM8;5{!j*oW){x&_I||H?8pNHr}EhG|n??jO<%JpoKdfc+!$olPe&r z#>c+GLr}S;o1H*A=z) zkrq*BVOsVqK&gDW%+$J%ib9ph2B}x8!l`DfX6latG3B*sgY>q{+E0%j+4F6>t;o;U79XNS3?Ut48lqAQYPUykjZ zKucHoBs08;zqWY&Y3b2~B3FXnjz8_KV*Y7TO|L=)MlbHa74Ki-7VYh#H(BXDE@4dm zpl0ixwoGFERtF%FV*SSWGY|QFZqSREOM&fMw;$Sk731YDJi1Xr$i1iNgU~A}o)cS2F|U`)p_; z%YsWoG!CnGg>6i;1YmBeO0c|}y5$WyOpx1JO9A{rkldn104T}J_9PhkhFE_JP`c)D z8|CSXCrEKM-Px%pz0R^WU^8($4z}Ipz6!YPs<1aO@|=qG0U_#I({#BoWOlhFtq6yQ z2}kapR2wLAna`?SF?f>q+t^8%@ab(|Ew^I#aa~<%H~70>cK)kUd0m%BvHsV^{q~j$ z5;tMb6QOkFU_M)8n+`q|_G_*aQ^8~cxfOjrSFu=S`pEMsdKh6!-(vK&9^ckkEF_LA zwe$F>e@tUCHv2CeTShSCG?SwKYii|(^Z9O_^4CX*WvLr33^0dV46cpGvu&Y|F8?42 zM-v-Xr1B}L|NI@I`1ttxgxdTpz^}_Wvp%gOIE0&}r(J&xEVrxX+%7xDI%YgtFMeMSCMflDh)E5R@LmOW(#!Zh zi*Huls1{s*W6&_2^RvqW%6fA$j{~7^Kuh-gef6|$WI1GKC~k4%6&pA^apx@!NHBW; z{m-3Aoj38P?gI1%Qhpc^LUlj@5TI9r12X?xYa7%31thS8Gwj2R>AnOsE)Q_~RAS{` z{3myt14FdeBSf1Oa7LC*6)B_1o+o%gu9I7LrFHU1uM_gj4%P66*BHhKah#TfXqMT{ zC(tmIW2ul}KIcNV#hC`Y6FZyNdPhF2+`v^8q#Twu-s2A$-VqfQeQhEgM0q4o?6HYh zC;JWiOdu6{5SlnNzd;T8@kI*qc%WEX;Zgb9Dk}QsL(J$X$K2LDO!ouI^wloCNF*VA zf^d27h<78RA3ov#{mW{g`hd6+*=I@l2*P(;eUegt(}xKuMeJCi>wzshLN%>Y)q@IH zmA`;iIUi`t+UgN>w|X^kn-TJlhmg9w5LrukiT*5lY#lg$OemNpp zF%HTs;IMaa2mSTfQjJ?%q2k}XfRFJwt(@o}4|`PFs|%lrE_fr#4z^2s@m&u)aAX3l zX{-bwAp(_2MwM9)Srx{B2>%$PEzBrrSL19ioTWB4uiqixD#3k5m`;foFP!bZrEna7&gzz+v$Ps>Ac}T6N}V9IF&|c&y_v;ajmOI_^EQ8tGj5 zru+kd`z}?$|8l19iSjMjr9j$z)XkSuNz(G^bD)uM5HZkQ{Dq)+=8Lvz!0wTW*O>xud= zag?NKc&2zu8gDAYeRY$$%=K}Jto|=6(ZR~7wF3s`8Nu_T#83jj$w42gj!ZKtu$+29 za_2ru6c6#xp2Q5{2ormO+?L)rvC0wao?<+_G}>4=@#d&yZ`pubqph#4I|I%JNp4%N ztE&yKMOWJLlyG0)T<-1do$(Xj(AIQ)LO%B2amnq>SqdAIiT88-+IZ4?Hg@m)_|@S0 zsxaEw&)-+cX4#b6C!oF}qVe{(A%CT%$$a!pK9LJ~iQdP83VjVtpWt-D()@7>ZV6sy zd})R_y?8uP^%4CxrtFIgThKD+J9zyW)4Sp?kMNcDx)2V< zkLg3YriXfg>j6fNjWANlJDDRLo4B#n7vF;NxK8q!w9FTos(GTBR?t-DbKP>XjhF9T zS2Eg9l8qNHGsz9Q<|`p<^S?P;TS4Z@pIXtIz0{KFDt`#zv)`6DJT9jzzBD3Q zzFw=fM%s!+L*$jvM5U)-iF)E;=%4EFWFbiy-Ei$yFCi;!-rWy zSG-aXoD+pa!L*IC=Dygc6PvFU<1%G%Na05~m`1~3cx$9m5&w*F1E&{*1DvW$w&0Z6 z5qG;bnEhFVf08g_q+R#^k~dCOy@3#IAcz-nfak;}yDl*ZWYWhud`RQ%0>`FnAo{LD z=HXP}WnF60>R91DKng9yw0W>fdi%6ibN(aXJud$8oq)7_(M>_g!XNo3zQj5=SC5OI z5mMVoup=AuYBUs#YvN!n{AYl>6A4XdVuTowF(-wXyf)n(Qr&}d3~8(16T3e3i>B{z z_4WqcV{h~aJ1!$>M)r-p*6IzBTxx=58b0C#4^27mlFs z&fB=%D7_G!C)DTc#)_9pz&~mpANWJkx7i#BikUC$+WZjM_S$Q!aw6n(EdvB}AObFo zs4zXrdU*50OTc@+CusuL?EXpKB(rp55KCnxtOUdb7`YZg9a;ri_(n~Tt{%K=rM-K# zGC%#6bGeT}^uknjrPk=xW)+WKg~6O_)56azr{Cozm8Oj{cOn8fcm1v)piX9_#Yo^A zTq%RA-hIwa3A%e^O|#!=3qT;g?v4l~_|v~PYyP9n#?6J5@XX%xbDl!&?cLq8!%8xa z3=#Ds`n9r&k=oyM`}pnd@geK;xo$8{vf9+j5*o;%&k7U@lJQ}ZnVFVgP^CxA@xBhi zBm33Ll<{{x^cqWYm|sggx5;YLgI=M@Isf^#&$)PROBrN%mY$A{tfMAzb0#SBZnybc zk>tXOSAb-{_ZrV^9qHjKA(aZX_nMG>jHOrL@4u(q=p|8N_f@wG_q({rTbcEqEtmXi z)!PX{$i28526R-BF7^jNNg9mFr$5MZ* zK#XF#Sm7R3NjNx$e9SK)Oy-;P_b*5076M|)B>_lfsn0x-T6glrl2j1;4xWRdrTfs6 z8%OX35olWia#2{HLGfV6C6T4_sXZ-KC zk_pyv(uvj-kNe1?HK7dsQ;Dj_e|M1pa(G*;4Mx8a0hwfDU7=?yRf3g@q{hxM9I;amXS$`EKK6#97v!{dTIE z*hSJ$*ilQIw%UdE1D|%mYaKj`901^pBPwto1W%{q%BSGLv?rgUyY{_)Yn@FxI8;gy zsFbFH$4?8YcC?F`Pb*;UxR%(W_xqP3$)n3a150XvW@^PR$qYkF=rdcXFRe>ZNS?AV z8Ylv~5XMdp6F&59G(jN&X~wD4%Z2Qyo?o)xk!3Vjtx`DmoLYticl6Xlra?c6VWoMu z2lP_|;1zhyw9X+i<*9f2pI{kbOI8IfKr3eR=#VmBf5mIdwy{2l5{sAS!D=}RonOh> zt7v9CSVA<_>%pN(*dK+T$kd7nBGf_t=75bFQY1HcZ61quznla_bI)6>$nWdh zSfm)cUin5PZ4FD6bXNT3*94g%Q-xb=>cYOVTTEwIQ;=e6$dQMH+>7zDDun^oKj{Tq zyr#08Ts;XBvY$+LKZfK4uNl>HJp-biz*xR6By)SKq{L4ZN!r=Jk#&_Gw-#KuI3(v` zlx4`tw5_kV;nxdoZ*KEAeDp$ONloD+%WgZRIGEl-6uM%L&47}X4W)N0cTRlpHcjD5 z2AnUAXV-_F(Do?*4rj+uGvlMyzdD?+sSDn@+<<9!AqffsC5hNPrhc9j!jtB&=|)2@ z@R?-2KVMC+|P4 z+dBbotv~w4VKLNCvU61j53v)7r=_KPd7&}bF+ec>5-TIQ%@t;j9(9UHa6{GTyR19^ zxT0;v-8$E-&u+KZQ&d%B`V`SWJtMH&Skd6Lk1~h zw+F&`T>4JyE=o``pCd1ErP-6p$Pzz!SJQTkokoC)_cFupm8hSm$jANd+b_t#HvosXP~%e*CT`0+G& znx#^uQjfYccyip`cBF}ckUB4qZ#TJz=ZA2M`=^cbA2Bs+37#dbH?OfUFMrryBsf3f z{>oXd4`Zqx%F>u_{9#d8lM^u6{W)NHUUf4DEWg{%2L7k(_vI}`mCf|&#(ev#$$j-( z2hh~V`|(DYoc#w__c%r2IU@Wtvsfk7BUD7}u0XzNw+Qt)Yt$hsy798H{d zbT(%E8)oYWA0{~Vr)eOBV}A1ej89rf!<0RA&vpYtod`cys;h3E4|Jj^Mvu4ZPljb0 z&N>q$gJ!}x@{$byRaQ?a@sK-<3RTOK`W5MQpPfl)OlEnk&zF*QMM5Eyd^d6vRUZ`h zaL)!&L{HS|NOxb<&`YQ%&)ZD=T=y9n3vCVRF_L92BkPLTF_Ny-BR)%h z>JLY+9eR;HJUTeTZ$7U{XtM|7!tMY^|K?!u!3zYZ+%@urwpH{M#ccrBz*nK;d(0gy+-jGMe**3h!V2zW_~tS*Nv2BaDw&6zN5UM2s=aeU`&|q z%xsP~IK@IrYLTe?%$O`G&x1W4V0RNq zF$|RUhFzB$^|CxCJqK5*tD-Df@1j3{I@A#JOAO#svW(!O3RC8O$*d=TA>z^l4B@N!BJo+u-hbw@aC<;A6NW544(9L{7iGJ^Vo{|Nuv4|Qr;OJymtV7w5 zUsD}0rXmQL@QQc5oi7NG6>5O_yy_Eb`6~?*Hk~Qkcq!ZflX%sas6bV`P0MXk+b|P- z=)w5&WK)~Y0B+{#rjfz8xC3~xG00j4+nKA@Svp#YIn-&g1o#9i)*QSSo$gJalg8%m zOVs#~C0svay)SQh`=XK>#K#=3moX0LWq$RyWtZ@#?=b==o4ZA6jTduu0D(aiXBKt5 z6W1Oz`O&NQ|jJ&H2|QV{_6Wulo{B0>|4cw`P&8bJ9wWqQ!`G zx)W`owAJm45^7N3^~L~&A6o+`{^!Yy><{dx*d~%pi%{8K z@Xt8cEaBeod2`aeTzxvh7`IE89R~%Jej=-JmVl6fMv$46Q2HYQohT>?wvzJ&8guy( zqu{ZK%RE+y|6+A@acv6!m-Z$8HyJ3*pD7_PFs3~~^vp+JKfb&ovbVDMM0d;8!qF3e zc?%dh-a3C|@8Afqxm--`{swi;`pcf~8+)h|WeLFT`C<1V3+iVf(5gEPQE}zc2MIzj z|8>D-9@gH%iQP7Cjh(Yt*q(sQlC9P5D3M!T@J7(@RVWlH+yD~%*O!R%0VBUQP8RC# zjQ-(4#sp~(FwbxK#N$A|2*o@3hbXEr@w+{kH|Z~!L=nB_u8;SAmYVW2FPd(uK5Cw1 zgOmxfUgNWby8mCzeD^zC?-#8WiRea@Xo(uV6O2x@VG<<>5?zQEbr3`^QDUNpqXZM8 zM2Qx?MjgGzFo@CH1R3?t=YF62Kir?rFKeIkob^8MIeV?W_j{`?1nn%y0OA7zM|^=+ zjjJnW-{R5=170pzJ$P2QjH^n59_Gnww1G#o1+S(*9v106iRsOBHklPW8;y`*4;cuZ-f27R&_-NSen z7Wb@2@m4b?hS9f8)CS8Yyc|BK>hzn$RXnl>f)z!9VI}iY`(cr&(|PcmE@Co~xU!_( z=m=ffEMbi!Nsb92@?S6Ao#Yg7!)LS<1Dtj0@-@aj!pRdgXo0(Rs;u*#+(vJA9CXu~ z-z-SG&}#Ac>MH7q!6R0C@#G7oB{5m zW`A?@ZB98IOVHrsez%<@9s1b!*1J06c)yhp%Gklfo}gGt4h!`CrxVL(8PPNaleqZZ zXW}d6yI_AB@Udi{jb6Xx)4Ph$nAKjRVBE1k2XgsUn=!%*3D*jf>8RcOB~UDV@BD3p z1J!CN96o7i_L>AHz~HN(@eSF!-#fHF9nj_RN7f1WU=p0u16lHkS@MaAx^t z+>gvm+F6^YBVF@7S{vA{-J_PDHAMap&7l9<;_50bwx-em`+S4yiQ&7|PNEbVdQ8%M znnAZB&qhk+`{;rQuRPXBk_pS@rMAD{<_GUCcX3^>?JBOmZV9ov#4~1J3`g(xF5JJ5 z`IDQQE9E^V<$+!P+=vDKx@Dfd(?i53q?-}_?^W#lw$y^iM|jbB_gaZtFB@VI<;aF$ zl#c#DF&v5@IU1U^cc!8XLr{f1gAtj^977jqnhWD%@Dohi2_0ue^GSI43qJtAru3L^@zAi8QHcn@Q#wL#`z5(UEVk7GW?bZHAeYIG` z=^M^!s;Bmh9t%J53OT5;%NEUc^ z(HGcZ^3X+42}q;y4m-ZK^PV(@jE_+9_j#+>9+JqMpq}e1BBS_h&F{25=>=W*!hUX| ztmujuhE40uZmb1Rvai)*;=5hwmJt2b#}BsDTdu0%q8E?eQ9a)1%ZgK%n^#VO)pg zz>K89P_o^YY&(IeP-1*YnkKgJkmRDs^$%EpmJLZs;l^a!vXIZqlxr{L zy3WmZjs(qqkghLLRjH5TWG4MB?$DnqRJGpN`&{cNeyTXya2Ks3tm$$O?EpB9F;ok` zD_Wa@^ry8H>gmCax)9rqAuk2uHZP;lWT)mQdOV^iMe-2PyY`PZ0w6jgeXRRX&Z3&C zJ2=aicRs<(?*2`WuWp$`v>?19-O9^C!`WQJH_>oOh!iHz;LKmNALzHlX_x|wwlnvI z!U@MYt1YLWqwfh%@CPR8SuswOh02P(O8>mw5M0zDM9i;~eNHHD94>-q*CE)R%Kh!^^}_ zG_c;H&Y^aHT36+Dh2uvm9?b@s<|FTM*u*6|1Xb1dD~8YC)>*N7R47wW_~7?a%Nuipx5f#wLkXiTTnsa&MfNdKoS{uSp%2PpMXq(#-fJWnsxQ6xfm_Pa?T zoN8su?9jMBZ8zKb4%u!mo-t;?U^vQ26Y`=BZid9oPAAxZ5m+gGG!qH!m%zy2jZN%? zLl!3oG*FHh$Rz}~5tgZ)n3Ut#L60Th(9^-WTb{N zA`%w(k7JdL@T1LicQrzXg1R5jrIq)ONtHK25@Veg;XY+>YDYbOVHQ&aZ%qF3)aP?4s;JqYaiJ~%ue=vCvUgMNqB^SB4p z5ncuIEc{KO7$s|my9oFN*k_i0^R0sHw>2pKQ_qTSr2ZJkh^*kgSY69y(sO?7tKob@x@_?#Q782YTpQe}REut=X{SpDB#lG5!g zn$V$%<^Q5e10h(R+YtL}309ufn1RWZFR0#9U)M+`lVePO0;C_UbKJC~#GtW@L-Jh9 zucj4pFco4;2p_oA&De(S`}v$gGqHOc*7u(l>=Fi^He)OziaN30RlYb>`MownNvz0+C% zmI3{b;$z#sqzA{3-PHkn|G+)rgZ8D=JaJ>J;9qECy#J%;Bg#ahYA&%TR&S zP~rdaR}*N*gkVplsmPT>ccc$l@zHUW$D!t{o41!}-P^3hW;WaW>b1bao>M)Y36Bl zHw>zeU@82dIh*}LA|GFr;u?Y#;x12w_i-V?r^5;3q6`=%t+fFEpx}n>r2}NA)V%~D znIj6`Toju$?H10CImSt={)hyNJ0OK-N`~}Gqdy>Q8rz%SWHu=dB{)XvH)tRrJ{!8$ zDp5*{pegixiW|7|U5FG6Wu5);Gwn)~C379NOTnw!0ZiDZDP~T>f_bFq&y7CZ{Ur}r zE8S4`1C)U5t38>}!u_fYgd2y>v^(=SenP-VhOETpqDaYKFysyp5|~|<=sR$!5(vAo zUVvS<(t*wTLBkm3kP6UTONdOm&_k7tljGFAFR!0yUfud*%c7Cla9aUWVpQEfpu{ou zhq|*?zIwQ7Ze{cHL?vXOE%Ku=5p6N06XHfgCNUL9*0rw!`22; z?`=F<6bEkC(I^O=tNr!oz+J-%)vdBHjz0}InxvBDJlN8_04)dmQ7zBd;i_F-FkFXIdtRCYqySbe4W9Wt2u}*c#xOMRWe~JvAlKg(jZE?F*c0&C6VjP!OPsn^0hN`DbTJOp? zdgMh6lwZj!2IdSsuN`^3*7SU`_tz1HPC8$YAjmL)Gox^jyv7SY+eAXDUKkL8$l+<5 z(quAXraM=t1%}!$`|+K}q2ZPL(SwBw$1kuuJMxw8p35TAE6%@cFQT(<)4TSJX$FQX zKw6ivc&A3pD4zZeTYgmzg|zt^nTM2MHqjkYC}@JPf~Gv=@M~5dJ2CW{8WU+VH&`91 zFPyP7wvL|D+nk89#z`!gW8Z1l*(qU}+k7rzPk6MziF}r+AEh4V(r~qvA;(ur337_c z1lX1K&u8pb0s_lZ2#3^?ieGqluLXY+rVgc)$-65XovJ-S*yk;8LYW`|{UK&l7D%wD z$JjZ^CEm}ZC*Y-w4TgJpdqweq3Z{q-hXZsWXeR!;VUxdj_f@%{uBFjEpDO-mt8}T7 zhpFV*A}Zo36vC%cGKWHf3z-d2!2%t}GonQ?hVr}HbmV%hdTs;-#ZYviC^}{I*o7^h zzo3@!;q#pb*JUeH(_K2g-t9k@x@7)RR+z-o~l^uMtq=~%UYip_R zl3wWfC&a&cE5A({2(IsN7&Bzxn;ZWDKsHHwpf8ZDEf_XWb&X#SNZad+UV59{DO zB+4DaB7XY_Pt>Bi+-#>YZQ`g-#399|mqF*YNcj5#@2mH57q<>stDnSRw*Td@>SYqU zDo4&$ajg4kk>$n@*s7J-j?IB89ELwm=vZ$U6Q7@|!lKQ+;HlkM4RD1Sl-u)wXqpXZ z*=G9(=#PB?ZD{>O>1rJ&@XtXkpQ+UjZ4ziXVCW{s=MF7j{Hi9A%)cO(>lk}{cCbhY z{gEj`BF{Yd+n*vzj{zCwRF>|T&2nq2&98@ZPEoHONX8obfV*iIV z_~{q28){P5Mo~6^LuD+j)ataK)oZ%x$AU3VoT4mseEv_yZP)8 ztTp2$WaV*zT&mo2IdH%=vU?j&2f2}XOHAE95xqx!`I`!v^dttMSmBDX@-}AKv{<_| z&y#B&kgEz_C(emDGs~vVd>yQnFt1q?L&_lsRyYqka+O|Ye}k$Fyjp7ug5%j$9T^=r zSm~qs?DGTM{JIZNXIOvpAF}$WrT^unyAxrZbawFF{t=^*$oV{qU+S(d;`1+>tM=SO zO^cr_vq9TNW4V*-2ZC$k29n(zPWAeHjFqJTUiIU!JB_$j=EPI1jcx*({x(Af14x%o zfon2*CZFlNU=JM-d@-wZ$7iC$jxf@$#afQ5GKpT=1&ke?NlxTTk~olYRKtp$*osnC zy(OAaX!-KBb@en0X+5zuAv-$zk*adcff8z|ydR+wnYOI&XaGSkIqq5_c7+zd!3z5( z`w5bK1;#d%+D1y;qM#D$Th%=_4eGRkLk2!&A7p zCeY5z(JM`%&i@84Zhw*YUh8n5-?w@^9MBAcPz#1**cV%_0`fxT|(1Gsf zuWKqfPjiN-0Jm8bBeMA=q@g*b>?k$X$!tw$v2^?{loZD6kcjX&Bq1KI8AAs^Oa-y# zXDjRrqflht4cW;hj^%Rgf;aU;HV=;C_SIpRREYJ5PusH9M$$>0Ci=tOZUc_!$~fd2gE=WiBH5UN%Z}3~82`r8)7G4?Mjf zI6)VZPe!I(5+~slClp|dSh%2$Lo9$^65E9$pW>hg%k4K2a_1yg8FP(W)_!tz>4d$H z*b0WEjAFQCdslq_3C}YJRXRTDKVq!~?gCk^&8KHoPY?2DmlQVWw(HsQQSQ z6t($AM)k!!oHvrj=N!CO@RP}>D{;i!MOf-8mn+&lm7C%~G(V`oR6``ZyV5r`*Xp{1 z4#19{Bf7nf7b2W2&-ReYGO)J5muLHLIl$j;5C4g-Q)(aVdH_EAY4`c2rhzi@;;K#b zu2rbwL$LBgKsdKb>2IG=ja{XWpgeMaK7--xx9QTwffKd-MPSG z4rYTdyaRkTl#qVUa(1n-_G|nv{t<7LuEgyCdBc7i9OHi3(j~H5vx| z_|vZ>%p~ZdhtSw^PAa6^a>U`AA;x8iNqD$h`sav2i*tZ zi@zT7LD?S1HGkQ?7&Zpn|Ms=nI6cs?8S)Xq{{aFeU?Sttwr;)&evX`BZu`ZjBB#YK zCf2$8iz1rAK&JaCjQewY{BKxeb?tGe5*zqneA(!^biN18^Xq(Nt2Rl8yxjq#2AaPR z#*c31ou6(_7pwTV2q(3tWqCzHerGl!A~0U=Eq}iJj<`W9J7+1)@$gwFd5^^){eEvU zaQ-mtY5k%KyRI=kGz|&B71zJHIQZv4UMRCk$sy*{Fu~&?nl{4o^2W8NXTSvV`+U_A zlG9yVwJ&R%*s_h*^cksN5#nredwQEUZ>Lxl781~;6&gd{9vpz{y37(iT{=2m;w5n{ zxq?gn-L}n?Y%^@8BfDhTh|28DNVkQsQWjUzsfsr>lmMNQotcmC=4td63m6iLoli|l z`izn5f1yHNztD2&>P!hTamtY+e0+2*EV>@W#LD~5((jN&sQt16@02oB=eIp9ttOy9$bk%b>~W$> z4X!S6wDA5`N)u!BCHFz&Sb{7q6n4L&4-f`eRJE8=%S%sLf#i}$#X@nily3d+45IB5 z4n$dC$Nmo*PxqHZ6)T*~SmZ0W@4gKxN6dDD$`K7VioxTZl2u1JxMGa_*@2*ko6>Cu ze2^flGU?Ud4kMRmD|6mYY<6RFgTn2Q;oP*zakeVfka)EfypxfWb`7D|hp^f>Ys1Yx zv4PbKr{{4@tUz~<(_THTQ8Jclc{wm$;tSKS^fzS!eE~vcQl*Y@adBU!y5$$fpgWe^ zG)_mXyhaP%W^$RpWC9}fxtO=8ZH@y@$+3q2E=5MflK{Wxa&9pgm1;jXXO)5m)f(y3 z%aadb->HGMv~KVGY#+VJ73;a*Sv66ZpBb;Nt9)Qe;yTS@w#g^0=3Ur~4AC2wPz7+V zs|yVvirS;yH|W8$sz{_a-4GDAb!3!j_3BT$tsN2@nQ=-uP0Z^!Q)9A=oN6V7R?JD?iQ=L zc#hAA@S(N$}|0-}z%`^6-|n2}Mow zg*(s8>&#;l^Ts`z5j)z?U~u*0f;^Ah_x^CS!5pHyHp2z1&N*_HMg%m82&~*|J`ZpZ zA6!BKLEqSMiq#LaBGmU{rUV9Mfc?S9uG~U352b$B<-?QxdVB&{kfXv^X{}37D|+{q zrk<|#ATa9nO8lFLFCo5*L6bHEZWl`$jjt5Qf#C7p_M`^d?)&c%6LZE%$-=+}T}z*3 z%HiOhq@#^@V&UU=wei28G|FFycIBfL7k&Cs5Si zKDUbh{*ksfm`>f|9<5F3He3hZBN?u#%yhmC+Fs+*;pWo#a`G1qvc9UMSWZv?Yaxbw z_Q`ZwQddURfypU5=hERUPFa{?$0z!isvY_9gP<}OXu$in_kNNvmdsaWH2ns~Ff$R_xzl{j7|f=R67cG};alq# z#{X#QnFVzvXErTCtS&{Upas}DJXm=p>+_4KY_WWC37D-m-C02dRp+RqL*L`u`w(yT zXx`6o9bq7i8D={o_i!Zg7nDCC6Ea3u$DR)7>!FPfTi;YY%26AwoVl@j3{3GYN03iUD9$4`^9Xi2qYf1YeRn z8?ZKwFC&=0`R&E8!OCCgOSPoPz(=pC{k248q`YGQlE`Nw7E1TxsLwqxa`aC6+SKED zn|UgrIicX$_^Qs)?dY=m?nA?m2vIt!J1Sy1X>L3k|1m}g{zf0FTY4!0G5qeO<8Gi9 zN(ueOJz!VWW9icr|Lzv75Zz`D87FLC4xzWC zY~{eYPlRF+ld*peeePGY0tQ^^-ILBe|9^l^Zl3T_xbHj(NW-5zPN1V{pi!x29sYj+ D6zp&p literal 0 HcmV?d00001 diff --git a/router/doc/techintro.html b/router/doc/techintro.html new file mode 100644 index 000000000..c2d59356f --- /dev/null +++ b/router/doc/techintro.html @@ -0,0 +1,982 @@ + + + Introducing I2P - a scalable framework for anonymous communication + + + + +
+Introducing I2P
+a scalable framework for anonymous communication
+$Id: index.html,v 1.22 2005/10/03 00:31:27 jrandom Exp $ +
+
+ + + + + +
+
+* Introduction
+* Operation
+  * Overview
+  * Tunnels
+  * Network Database
+  * Transport protocols
+  * Cryptography
+
+		 +
+* Future
+  * Restricted routes
+  * Variable latency
+  * Open questions
+
+		 +
+* Similar systems
+  * Tor
+  * Freenet
+* Appendix A: Application layer
+
+
+
+ +
+ +

Introduction

+

+I2P is a scalable, self organizing, resilient message based anonymous network layer, +upon which any number of different anonymity or security conscious applications +can operate. Each of these applications may make their own anonymity, latency, and +throughput tradeoffs without worrying about the proper implementation of a free +route mixnet, allowing them to blend their activity with the larger anonymity set of +users already running on top of I2P. Applications available already provide the full +range of typical Internet activities - anonymous web browsing, anonymous web hosting, +anonymous blogging (with Syndie), anonymous chat (via IRC or +jabber), anonymous swarming file transfers (with i2p-bt and +Azureus), anonymous file sharing (with +I2Phex), anonymous email (with I2Pmail +and susimail), anonymous newsgroups, as well as several +other applications under development. Unlike web sites hosted within content +distribution networks like Freenet or +GNUnet, the services hosted on I2P are fully +interactive - there are traditional web-style search engines, bulletin boards, blogs +you can comment on, database driven sites, and bridges to query static systems like +Freenet without needing to install it locally. +

+ +

+With all of these anonymity enabled applications, I2P takes on the role of the message +oriented middleware - applications say that they want to send some data to a cryptographic +identifier (a "destination") and I2P takes care of making sure it gets there securely +and anonymously. I2P also bundles a simple streaming library +to allow I2P's anonymous best-effort messages to transfer as reliable, in-order streams, +transparently offering a TCP based congestion control algorithm tuned for the high +bandwidth delay product of the network. While there have been several simple SOCKS +proxies available to tie existing applications into the network, their value has been +limited as nearly every application routinely exposes what in an anonymity context is +sensitive information. The only safe way to go is to fully audit an application to +ensure proper operation, and to assist in that we provide a series of APIs in various +languages which can be used to make the most out of the network. +

+ + + + +

+I2P is not a research project - academic, commercial, or governmental, but is instead +an engineering effort aimed at doing whatever is necessary to provide a sufficient +level of anonymity to those who need it. It has been in active development since +early 2003 with one full time developer and a dedicated group of part time contributors +from all over the world. All of the work done on I2P is open source and +freely available on the website, with the majority +of the code released outright into the public domain but making use of a few +cryptographic routines under BSD-style licenses. The people working on I2P do not +control what people release client applications under, and there are several GPL'ed +applications available (I2PTunnel, +susimail, Azureus, +I2Phex). Funding +for I2P comes entirely from donations, and does not receive any tax breaks in any +jurisdiction, as many of the developers are themselves anonymous. +

+ +

Operation

+

Overview

+ +

+To understand I2P's operation, it is essential to understand a few key concepts. +First, I2P makes a strict separation between the software participating +in the network (a "router") and the anonymous endpoints ("destinations") associated +with individual applications. The fact that someone is running I2P is not usually +a secret. What is hidden is information on what the user is doing, if anything at +all, as well as what router a particular destination is connected to. End users +will typically have several local destinations on their router - for instance, one +proxying in to irc servers, another supporting the user's anonymous webserver ("eepsite"), +another for an I2Phex instance, another for torrents, etc. +

+ +

+Another critical concept to understand is the "tunnel" - a directed path through +an explicitly selected set of routers, making use of layered encryption so that +the messages sent in the tunnel's "gateway" appear entirely random at each hop +along the path until it reaches the tunnel's "endpoint". These unidirectional +tunnels can be seen as either "inbound" tunnels or "outbound" tunnels, referring +to whether they are bringing messages to the tunnel's creator or away from them, +respectively. The gateway of an inbound tunnel can receive messages from any +peer and will forward them down through the tunnel until it reaches the (anonymous) +endpoint (the creator). On the other hand, the gateway of an outbound tunnel is +the tunnel's creator, and messages sent through that tunnel are encoded so that +when they reach the outbound tunnel's endpoint, that router has the instructions +necessary to forward the message on to the appropriate location. +

+ +

+A third critical concept to understand is I2P's "network database" (or "netDb") +- a pair of algorithms used to share network metadata. The two types of metadata +carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the data +necessary for contacting a particular router (their public keys, transport +addresses, etc), while the leaseSet gives routers the information necessary for +contacting a particular destination. Within each leaseSet, there are any number +of "leases", each of which specifies the gateway for one of that destination's +inbound tunnels as well as when that tunnel will expire. The leaseSet also +contains a pair of public keys which can be used for layered garlic encryption. +

+ +

+I2P's operation can be understood by putting those three concepts together: +

+ +

+ +

+When Alice wants to send a message to Bob, she first does a lookup in the +netDb to find Bob's leaseSet, giving her his current inbound tunnel gateways +(3 and 4). She then picks one of her outbound tunnels and sends the message +down it with instructions for the outbound tunnel's endpoint to forward the +message on to one of Bob's inbound tunnel gateways. When the outbound +tunnel endpoint receives those instructions, it forwards the message as +requested, and when Bob's inbound tunnel gateway receives it, it is +forwarded down the tunnel to Bob's router. If Alice wants Bob to be able +to reply to the message, she needs to transmit her own destination explicitly +as part of the message itself (taken care of transparently in the +streaming library). Alice may also cut down on +the response time by bundling her most recent leaseSet with the message so +that Bob doesn't need to do a netDb lookup for it when he wants to reply, but this +is optional. +

+ +

+While the tunnels themselves have layered encryption to prevent unauthorized +disclosure to peers inside the network (as the transport layer itself does to +prevent unauthorized disclosure to peers outside the network), it is necessary +to add an additional end to end layer of encryption to hide the message from the +outbound tunnel endpoint and the inbound tunnel gateway. This +"garlic encryption" lets Alice's router wrap up multiple +messages into a single "garlic message", encrypted to a particular public key +so that intermediary peers cannot determine either how many messages are within +the garlic, what those messages say, or where those individual cloves are +destined. For typical end to end communication between Alice and Bob, the +garlic will be encrypted to the public key published in Bob's leaseSet, +allowing the message to be encrypted without giving out the public key to Bob's +own router. +

+ +

+Another important fact to keep in mind is that I2P is entirely message based +and that some messages may be lost along the way. Applications using I2P +can use the message oriented interfaces and take care of their own congestion +control and reliability needs, but most would be best served by reusing the +provided streaming library to view I2P as a streams +based network. +

+ +

Tunnels

+ +

+Both inbound and outbound tunnels work along similar principles - the tunnel +gateway accumulates a number of tunnel messages, eventually preprocessing them +into something for tunnel delivery. Next, the gateway encrypts that preprocessed +data and forwards it to the first hop. That peer and subsequent tunnel +participants add on a layer of encryption after verifying that it isn't a +duplicate before forward it on to the next peer. Eventually, the +message arrives at the endpoint where the messages are split out again and +forwarded on as requested. The difference arises in what +the tunnel's creator does - for inbound tunnels, the creator is the endpoint +and they simply decrypt all of the layers added, while for outbound tunnels, +the creator is the gateway and they pre-decrypt all of the layers so that after +all of the layers of per-hop encryption are added, the message arrives in the +clear at the tunnel endpoint. +

+ +

+The choice of specific peers to pass on messages as well as their particular +ordering is important to understanding both I2P's anonymity and performance +characteristics. While the network database (below) has its own criteria for +picking what peers to query and store entries on, tunnels may use any peers in +the network in any order (and even any number of times) in a single tunnel. If +perfect latency and capacity data were globally known, selection and ordering +would be driven by the particular needs of the client in tandem with their threat +model. Unfortunately, latency and capacity data is not trivial to gather +anonymously, and depending upon untrusted peers to provide this information has +its own serious anonymity implications. +

+ +

+From an anonymity perspective, the simplest technique would be to pick peers +randomly from the entire network, order them randomly, and use those peers +in that order for all eternity. From a performance perspective, the simplest +technique would be to pick the fastest peers with the necessary spare capacity, +spreading the load across different peers to handle transparent failover, and +to rebuild the tunnel whenever capacity information changes. While the former +is both brittle and inefficient, the later requires inaccessible information +and offers insufficient anonymity. I2P is instead working on offering a range +of peer selection strategies, coupled with anonymity aware measurement code to +organize the peers by their profiles. +

+ +

+As a base, I2P is constantly profiling the peers with which it interacts with +by measuring their indirect behavior - for instance, when a peer responds to +a netDb lookup in 1.3 seconds, that round trip latency is recorded in the +profiles for all of the routers involved in the two tunnels (inbound and +outbound) through which the request and response passed, as well as the queried +peer's profile. Direction measurement, such as transport layer latency or +congestion, is not used as part of the profile, as it can be manipulated and +associated with the measuring router, exposing them to trivial attacks. While +gathering these profiles, a series of calculations are run on each to summarize +its performance - its latency, capacity to handle lots of activity, whether they +are currently overloaded, and how well integrated into the network they seem to +be. These calculations are then compared for active peers to organize the routers +into four tiers - fast and high capacity, high capacity, not failing, and failing. +The thresholds for those tiers are determined dynamically, and while they +currently use fairly simple algorithms, alternatives exist. +

+ +

+Using this profile data, the simplest reasonable peer selection strategy is to +pick peers randomly from the top tier (fast and high capacity), and this is +currently deployed for client tunnels. Exploratory tunnels (used for netDb +and tunnel management) pick peers randomly from the not failing tier (which +includes routers in 'better' tiers as well), allowing the peer to sample +routers more widely, in effect optimizing the peer selection through randomized +hill climbing. These strategies alone do however leak information regarding the +peers in the router's tip tier through predecessor and netDb harvesting attacks. +In turn, several alternatives exist which, while not balancing the load as evenly, +will address the attacks mounted by particular classes of adversaries. +

+ +

+By picking a random key and ordering the peers according to their XOR distance +from it, the information leaked is reduced in predecessor and harvesting attacks +according to the peers' failure rate and the tier's churn. Another simple strategy +for dealing with netDb harvesting attacks is to simply fix the inbound tunnel +gateway(s) yet randomize the peers further on in the tunnels. To deal with +predecessor attacks for adversaries which the client contacts, the outbound tunnel +endpoints would also remain fixed. The selection of which peer to fix on the most +exposed point would of course need to have a limit to the duration, as all peers +fail eventually, so it could either be reactively adjusted or proactively avoided +to mimic a measured mean time between failures of other routers. These two strategies +can in turn be combined, using a fixed exposed peer and an XOR based ordering within +the tunnels themselves. A more rigid strategy would fix the exact peers and ordering +of a potential tunnel, only using individual peers if all of them agree to participate +in the same way each time. This varies from the XOR based ordering in that the +predecessor and successor of each peer is always the same, while the XOR only makes +sure their order doesn't change. +

+ +

+As mentioned before, I2P currently (release 0.6.1.1) includes the tiered random +strategy above, but the others are planned for the 0.6.2 release. A more detailed +discussion of the mechanics involved in tunnel operation, management, and peer +selection can be found in the +tunnel spec. +

+ +

Network Database

+ +

+As mentioned earlier, I2P's netDb works to share the network's metadata. Two +algorithms are used to accomplish this - primarily, a small set of routers are +designated as "floodfill peers", while the rest of the routers participate in +the Kademlia derived +distributed hash table for redundancy. To integrate the two algorithms, each +router always uses the Kademlia style store and fetch, but acts as if the +floodfill peers are 'closest' to the key in question. Additionally, when a +peer publishes a key into the netDb, after a brief delay they query another +random floodfill peer, asking them for the key, and if that peer does not have +it, they move on and republish the key again. Behind the scenes, when one of +the floodfill peers receives a new valid key, they republish it to the other +floodfill peers who then cache it locally. +

+ +

+Each piece of data in the netDb is self authenticating - signed by the +appropriate party and verified by anyone who uses or stores it. In addition, +the data has liveliness information within it, allowing irrelevant entries to be +dropped, newer entries to replace older ones, and, for the paranoid, protection +against certain classes of attack. This is also why I2P bundles the necessary +code for maintaining the correct time, occasionally querying some SNTP servers +(the pool.ntp.org round robin by default) +and detecting skew between routers at the transport layer. +

+ +

+The routerInfo structure itself contains all of the information that one router +needs to know to securely send messages to another router. This includes their +identity (made up of a 2048bit ElGamal public key, a 1024bit DSA public key, and +a certificate), the transport addresses which they can be reached on, such as +an IP address and port, when the structure was published, and a set of arbitrary +uninterpreted text options. In addition, there is a signature against all of +that data as generated by the included DSA public key. The key for this routerInfo +structure in the netDb is the SHA256 hash of the router's identity. The options +published are often filled with information helpful in debugging I2P's operation, +but when I2P reaches the 1.0 release, the options will be disabled and kept blank. +

+ +

+The leaseSet structure is similar, in that it includes the I2P destination +(comprised of a 2048bit ElGamal public key, a 1024bit DSA public key, and a +certificate), a list of "leases", and a pair of public keys for garlic encrypting +messages to the destination. Each of the leases specify one of the destination's +inbound tunnel gateways by including the SHA256 of the gateway's identity, a 4 +byte tunnel id on that gateway, and when that tunnel will expire. The key for +the leaseSet in the netDb is the SHA256 of the destination itself. +

+ +

+As the router currently automatically bundles the leaseSet for the sender inside +a garlic message to the recipient, the leaseSet for destinations which will not +receive unsolicited messages do not need to be published in the netDb at all. If +the destination itself is sensitive, the leaseSet could instead be transmitted +through other means without ever going into the netDb. +

+ +

+Bootstrapping the netDb itself is simple - once a router has at least one routerInfo +of a reachable peer, they query that router for references to other routers in the +network with the Kademlia healing algorithm. Each routerInfo reference is stored in +an individual file in the the router's netDb subdirectory, allowing people to easily +share their references to bootstrap new users. +

+ +

+Unlike traditional DHTs, the very act of conducting a search distributes the data +as well, since rather passing Kademlia's standard IP+port pairs, references are given +to the routers that the peer should query next (namely, the SHA256 of those routers' +identities). As such, iteratively searching for a particular destination's leaseSet +or router's routerInfo will also provide you with the routerInfo of the peers along +the way. In addition, due to the time sensitivity of the data published, the information +doesn't often need to migrate between peers - since a tunnel is only valid for 10 +minutes, the leaseSet can be dropped after that time has passed. To take into +account Sybil attacks on the netDb, the Kademlia routing location used for any given +key varies over time. For instance, rather than storing a routerInfo on the peers +closest to SHA256(routerInfo.identity), they are stored on the peers closest to +SHA256(routerInfo.identity + YYYYMMDD), requiring an adversary to remount the attack +again daily so as to maintain their closeness to the current routing key. As the +very fact that a router is making a lookup for a given key may expose sensitive data +(and the fact that a router is publishing a given key even more so), all netDb +messages are transmitted through the router's exploratory tunnels. +

+ +

+The netDb plays a very specific role in the I2P network, and the algorithms have +been tuned towards our needs. This also means that it hasn't been tuned to address the +needs we have yet to run into. As the network grows, the primary floodfill algorithm +will need to be refined to exploit the capacity available, or perhaps replaced with +another technique for securely distributing the network metadata. +

+ +

Transport protocols

+ +

+Communication between routers needs to provide confidentiality and integrity +against external adversaries while authenticating that the router contacted +is the one who should receive a given message. The particulars of how routers +communicate with other routers isn't critical - three separate protocols have +been used at different points to provide those bare necessities. To accommodate +the need for high degree communication (as a number of routers will end up +speaking with many others), I2P is migrating from a TCP based transport +to a UDP based one - "Secure Semireliable UDP", or "SSU". As described in the +SSU spec:

+ +
+The goal of this protocol is to provide secure, authenticated, +semireliable, and unordered message delivery, exposing only a minimal amount of +data easily discernible to third parties. It should support high degree +communication as well as TCP-friendly congestion control, and may include +PMTU detection. It should be capable of efficiently moving bulk data at rates +sufficient for home users. In addition, it should support techniques for +addressing network obstacles, like most NATs or firewalls. +
+ +

Cryptography

+ +

+A bare minimum set of cryptographic primitives are combined together to provide I2P's +layered defenses against a variety of adversaries. At the lowest level, interrouter +communication is protected by the transport layer security - SSU +encrypts each packet with AES256/CBC with both an explicit IV and MAC (HMAC-SHA256-128) +after agreeing upon an ephemeral session key through a 2048bit Diffie-Hellman exchange, +station-to-station authentication with the other router's DSA key, plus each network +message has their own SHA256 hash for local integrity checking. +Tunnel messages passed over the transports have their own +layered AES256/CBC encryption with an explicit IV and verified at the tunnel endpoint +with an additional SHA256 hash. Various other messages are passed along inside +"garlic messages", which are encrypted with ElGamal/AES+SessionTags (explained below). +

+ +

Garlic messages

+ +

+Garlic messages are an extension of "onion" layered encryption, allowing the contents +of a single message to contain multiple "cloves" - fully formed messages along side +their own instructions for delivery. Messages are wrapped into a garlic message whenever +the message would otherwise be passing in cleartext through a peer who should not have +access to the information - for instance, when a router wants to ask another router to +participate in a tunnel, they wrap the request inside a garlic, encrypt that garlic to +the receiving router's 2048bit ElGamal public key, and forward it through a tunnel. +Another example is when a client wants to send a message to a destination - the sender's +router will wrap up that data message (along side some other messages) into a garlic, +encrypt that garlic to the 2048bit ElGamal public key published in the recipient's +leaseSet, and forward it through the appropriate tunnels. +

+ +

+The "instructions" attached to each clove inside the encryption layer includes the +ability to request that the clove be forwarded locally, to a remote router, or to a +remote tunnel on a remote router. There are fields in those instructions allowing a +peer to request that the delivery be delayed until a certain time or condition has +been met, though they won't be honored until the +nontrivial delays are deployed. It is possible to +explicitly route garlic messages any number of hops without building tunnels, or even +to reroute tunnel messages by wrapping them in garlic messages and forwarding them a +number of hops prior to delivering them to the next hop in the tunnel, but those +techniques are not currently used in the existing implementation. +

+ +

Session tags

+ +

+As an unreliable, unordered, message based system, I2P uses a simple combination of +asymmetric and symmetric encryption algorithms to provide data confidentiality and +integrity to garlic messages. As a whole, the combination is referred to as +ElGamal/AES+SessionTags, but that is an excessively verbose way to describe the simple +use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces. +

+ +

+The first time a router wants to encrypt a garlic message to another router, they encrypt +the keying material for an AES256 session key with ElGamal and append the AES256/CBC +encrypted payload after that encrypted ElGamal block. In addition to the encrypted +payload, the AES encrypted section contains the payload length, the SHA256 hash of the +unencrypted payload, as well as a number of "session tags" - random 32 byte nonces. The +next time the sender wants to encrypt a garlic message to another router, rather than +ElGamal encrypt a new session key they simply pick one of the previously delivered session +tags and AES encrypt the payload like before, using the session key used with that +session tag, prepended with the session tag itself. When a router receives a garlic encrypted +message, they check the first 32 bytes to see if it matches an available session tag - if +it does, they simply AES decrypt the message, but if it does not, they ElGamal decrypt the +first block. +

+ +

+Each session tag can be used only once so as to prevent internal adversaries from unnecessarily +correlating different messages as being between the same routers. The sender of an +ElGamal/AES+SessionTag encrypted message chooses when and how many tags to deliver, +prestocking the recipient with enough tags to cover a volley of messages. Garlic messages +may detect the successful tag delivery by bundling a small additional message as a clove (a +"delivery status message") - when the garlic message arrives at the intended recipient and +is decrypted successfully, this small delivery status message is one of the cloves exposed and +has instructions for the recipient to send the clove back to the original sender (through an +inbound tunnel, of course). When the original sender receives this delivery status message, +they know that the session tags bundled in the garlic message were successfully delivered. +

+ +

+Session tags themselves have a very short lifetime, after which they are discarded +if not used. In addition, the quantity stored for each key is limited, as are the +number of keys themselves - if too many arrive, either new or old messages may be +dropped. The sender keeps track whether messages using session tags are getting +through, and if there isn't sufficient communication it may drop the ones previously +assumed to be properly delivered, reverting back to the full expensive ElGamal +encryption. +

+ +

+One alternative is to transmit only a single session tag, and from that, seed a +deterministic PRNG for determining what tags to use or expect. By keeping this +PRNG roughly synchronized between the sender and recipient (the recipient precomputes a +window of the next e.g. 50 tags), the overhead of periodically bundling a large number +of tags is removed, allowing more options in the space/time tradeoff, and perhaps +reducing the number of ElGamal encryptions necessary. However, it would depend +upon the strength of the PRNG to provide the necessary cover against internal +adversaries, though perhaps by limiting the amount of times each PRNG is used, any +weaknesses can be minimized. At the moment, there are no immediate plans to move +towards these synchronized PRNGs. +

+ +

Future

+

+While I2P is currently functional and sufficient for many scenarios, there are +several areas which require further improvement to meet the needs of those +facing more powerful adversaries as well as substantial user experience optimization. +

+ +

Restricted route operation

+ +

+I2P is an overlay network designed to be run on top of a functional packet switched +network, exploiting the end to end principle to offer anonymity and security. +While the Internet no longer fully embraces the end to end principle, I2P does require a +substantial portion of the network to be reachable - there may be a number of peers +along the edges running using restricted routes, but I2P does not include an +appropriate routing algorithm for the degenerate case where most peers are +unreachable. It would, however work on top of a network employing such an +algorithm. +

+ +

+Restricted route operation, where there are limits to what peers are +reachable directly, has several different functional and anonymity +implications, dependent upon how the restricted routes are handled. At the most +basic level, restricted routes exist when a peer is behind a NAT or firewall which +does not allow inbound connections. This was largely addressed in I2P 0.6.0.6 by +integrating distributed hole punching into the transport layer, allowing people +behind most NATs and firewalls to receive unsolicited connections without any +configuration. However, this does not limit the exposure of the peer's IP address to +routers inside the network, as they can simply get introduced to the peer through +the published introducer. +

+ +

+Beyond the functional handling of restricted routes, there are two levels of +restricted operation that can be used to limit the exposure of one's IP address - +using router-specific tunnels for communication, and offering 'client routers'. For +the former, routers can either build a new pool of tunnels or reuse their exploratory +pool, publishing the inbound gateways to some of them as part of their routerInfo in +place of their transport addresses. When a peer wants to get in touch with them, +they see those tunnel gateways in the netDb and simply send the relevant message to +them through one of the published tunnels. If the peer behind the restricted route +wants to reply, it may do so either directly (if they are willing to expose their IP +to the peer) or indirectly through their outbound tunnels. When the routers that the +peer has directly connections to want to reach it (to forward tunnel messages, for +instance), they simply prioritize their direct connection over the published tunnel +gateway. The concept of 'client routers' simply extends the restricted route by not +publishing any router addresses. Such a router would not even need to publish their +routerInfo in the netDb, merely providing their self signed routerInfo to the peers +that it contacts (necessary to pass the router's public keys). Both levels of +restricted route operation are planned for I2P 2.0. +

+ +

+There are tradeoffs for those behind restricted routes, as they would likely +participate in other people's tunnels less frequently, and the routers which +they are connected to would be able to infer traffic patterns that would not +otherwise be exposed. On the other hand, if the cost of that exposure is less +than the cost of an IP being made available, it may be worthwhile. This, of course, +assumes that the peers that the router behind a restricted route contacts are not +hostile - either the network is large enough that the probability of using a hostile +peer to get connected is small enough, or trusted (and perhaps temporary) peers are +used instead. +

+ +

Variable latency

+ +

+Even though the bulk of I2P's initial efforts have been on low latency communication, +it was designed with variable latency services in mind from the beginning. At the +most basic level, applications running on top of I2P can offer the anonymity of +medium and high latency communication while still blending their traffic patterns +in with low latency traffic. Internally though, I2P can offer its own medium and +high latency communication through the garlic encryption - specifying that the +message should be sent after a certain delay, at a certain time, after a certain +number of messages have passed, or another mix strategy. With the layered encryption, +only the router that the clove exposed the delay request would know that the message +requires high latency, allowing the traffic to blend in further with the low latency +traffic. Once the transmission precondition is met, the router holding on to the +clove (which itself would likely be a garlic message) simply forwards it as +requested - to a router, to a tunnel, or, most likely, to a remote client destination. +

+ +

+There are a substantial number of ways to exploit this capacity for high latency +comm in I2P, but for the moment, doing so has been scheduled for the I2P 3.0 release. +In the meantime, those requiring the anonymity that high latency comm can offer should +look towards the application layer to provide it. +

+ +

Open questions

+
+How to get rid of the timing constraint?
+Can we deal with the sessionTags more efficiently?
+What, if any, batching/mixing strategies should be made available on the tunnels?
+What other tunnel peer selection and ordering strategies should be available?
+
+ +

Similar systems

+

+I2P's architecture builds on the concepts of message oriented middleware, the topology +of DHTs, the anonymity and cryptography of free route mixnets, and the adaptability of +packet switched networking. The value comes not from novel concepts of algorithms +though, but from careful engineering combining the research results of existing +systems and papers. While there are a few similar efforts worth reviewing, both for +technical and functional comparisons, two in particular are pulled out here - Tor +and Freenet. +

+ +

Tor

+

website

+ +

+At first glance, Tor and I2P have many functional and anonymity related similarities. +While I2P's development began before we were aware of the early stage efforts on Tor, +many of the lessons of the original onion routing and ZKS efforts were integrated into +I2P's design. Rather than building an essentially trusted, centralized system with +directory servers, I2P has a self organizing network database with each peer taking on +the responsibility of profiling other routers to determine how best to exploit available +resources. Another key difference is that while both I2P and Tor use layered and +ordered paths (tunnels and circuits/streams), I2P is fundamentally a packet switched +network, while Tor is fundamentally a circuit switched one, allowing I2P to +transparently route around congestion or other network failures, operate redundant +pathways, and load balance the data across available resources. While Tor offers +the useful outproxy functionality by offering integrated outproxy discovery and +selection, I2P leaves such application layer decisions up to applications running on +top of I2P - in fact, I2P has even externalized the TCP-like streaming library itself +to the application layer, allowing developers to experiment with different strategies, +exploiting their domain specific knowledge to offer better performance. +

+ +

+From an anonymity perspective, there is much similarity when the core networks are +compared. However, there are a few key differences. When dealing with an internal +adversary or most external adversaries, I2P's simplex tunnels expose half as much +traffic data than would be exposed with Tor's duplex circuits by simply looking at +the flows themselves - an HTTP request and response would follow the same path in +Tor, while in I2P the packets making up the request would go out through one or +more outbound tunnels and the packets making up the response would come back through +one or more different inbound tunnels. While I2P's per selection and ordering +strategies should sufficiently address predecessor attacks, I2P can trivially +mimic Tor's non-redundant duplex tunnels by simply building an inbound and +outbound tunnel along the same routers.

+ +

+Another anonymity issue comes up in Tor's use of telescopic tunnel creation, as +simple packet counting and timing measurements as the cells in a circuit pass +through an adversary's node exposes statistical information regarding where the +adversary is within the circuit. I2P's use of exploratory tunnels for delivering +and receiving the tunnel creation requests and responses effectively spreads the +messages randomly across the network, so that each of the peers who forwards the +individual tunnel creation messages only see the peer they transmit to or receive +from, and thanks to the garlic encryption, they are not aware of whether the message +is part of a tunnel creation process or not. The participant positional information +is useful to an adversary for mounting predecessor, intersection, and traffic +confirmation attacks. +

+ +

+Tor's support for a second tier of "onion proxies" does offer a nontrivial degree +of anonymity while requiring a low cost of entry, while I2P will not offer this +topology until 2.0. +

+ +

+On the whole, Tor and I2P complement each other in their focus - Tor works towards +offering high speed anonymous Internet outproxying, while I2P works towards offering +a decentralized resilient network in itself. In theory, both can be used to achieve +both purposes, but given limited development resources, they both have their +strengths and weaknesses. The I2P developers have considered the steps necessary to +modify Tor to take advantage of I2P's design, but concerns of Tor's viability under +resource scarcity suggest that I2P's packet switching architecture will be able to +exploit scarce resources more effectively. +

+ +

Freenet

+

website

+ +

+Freenet played a large part in the initial stages of I2P's design - giving proof to +the viability of a vibrant pseudonymous community completely contained within the +network, demonstrating that the dangers inherent in outproxies could be avoided. +The first seed of I2P began as a replacement communication layer for Freenet, +attempting to factor out the complexities of a scalable, anonymous and secure point +to point communication from the complexities of a censorship resistant distributed +data store. Over time however, some of the anonymity and scalability issues +inherent in Freenet's algorithms made it clear that I2P's focus should stay strictly +on providing a generic anonymous communication layer, rather than as a component of +Freenet. Over the years, the Freenet developers have come to see the weaknesses +in the older design, prompting them to suggest that they will require a "premix" +layer to offer substantial anonymity. In other words, Freenet needs to run on top +of a mixnet such as I2P or Tor, with "client nodes" requesting and publishing data +through the mixnet to the "server nodes" which then fetch and store the data according +to Freenet's heuristic distributed data storage algorithms. +

+ +

+Freenet's functionality is very complementary to I2P's, as Freenet natively provides +many of the tools for operating medium and high latency systems, while I2P natively +provides the low latency mix network suitable for offering adequate anonymity. The +logic of separating the mixnet from the censorship resistant distributed data store +still seems self evident from an engineering, anonymity, security, and resource +allocation perspective, so hopefully the Freenet team will pursue efforts in that +direction, if not simply reusing (or helping to improve, as necessary) existing +mixnets like I2P or Tor. +

+ +

+It is worth mentioning that there has recently been discussion and work by the +Freenet developers on a "globally scalable darknet" using restricted routes between +peers of various trust. While insufficient information has been made publicly +available regarding how such a system would operate for a full review, from what +has been said the anonymity and scalability claims seem highly dubious. In +particular, the appropriateness for use in hostile regimes against state level +adversaries has been tremendously overstated, and any analysis on the implications +of resource scarcity upon the scalability of the network has seemingly been avoided. +Further review of this "globally scalable darknet" will have to wait until the +Freenet team makes more information available. +

+ +

Appendix A: Application layer

+ +

+I2P itself doesn't really do much - it simply sends messages to remote destinations +and receives messages targeting local destinations - most of the interesting work +goes on at the layers above it. By itself, I2P could be seen as an anonymous and +secure IP layer, and the bundled streaming library as +an implementation of an anonymous and secure TCP layer on top of it. Beyond that, +I2PTunnel exposes a generic TCP proxying system for +either getting into or out of the I2P network, plus a variety of network +applications provide further functionality for end users. +

+ +

Streaming library

+ +

+The streaming library has grown organically for I2P - first mihi implemented the +"mini streaming library" as part of I2PTunnel, which was limited to a window +size of 1 message (requiring an ACK before sending the next one), and then it was +refactored out into a generic streaming interface (mirroring TCP sockets) and the +full streaming implementation was deployed with a sliding window protocol and +optimizations to take into account the high bandwidth x delay product. Individual +streams may adjust the maximum packet size and other options, though the default +of 4KB compressed seems a reasonable tradeoff between the bandwidth costs of +retransmitting lost messages and the latency of multiple messages. +

+ +

+In addition, in consideration of the relatively high cost of subsequent messages, +the streaming library's protocol for scheduling and delivering messages has been optimized to +allow individual messages passed to contain as much information as is available. +For instance, a small HTTP transaction proxied through the streaming library can +be completed in a single round trip - the first message bundles a SYN, FIN, and +the small payload (an HTTP request typically fits) and the reply bundles the SYN, +FIN, ACK, and the small payload (many HTTP responses fit). While an additional +ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been +received, the local HTTP proxy can deliver the full response to the browser +immediately. +

+ +

+On the whole, however, the streaming library bears much resemblance to an +abstraction of TCP, with its sliding windows, congestion control algorithms +(both slow start and congestion avoidance), and general packet behavior (ACK, +SYN, FIN, RST, rto calculation, etc). +

+ +

Naming library and addressbook

+

Developed by: mihi, Ragnarok

+ +

+Naming within I2P has been an oft-debated topic since the very beginning with +advocates across the spectrum of possibilities. However, given I2P's inherent +demand for secure communication and decentralized operation, the traditional +DNS-style naming system is clearly out, as are "majority rules" voting systems. +Instead, I2P ships with a generic naming library and a base implementation +designed to work off a local name to destination mapping, as well as an optional +add-on application called the "addressbook". The addressbook is a web-of-trust +driven secure, distributed, and human readable naming system, sacrificing only +the call for all human readable names to be globally unique by mandating only +local uniqueness. While all messages in I2P are cryptographically addressed +by their destination, different people can have local addressbook entries for +"Alice" which refer to different destinations. People can still discover new +names by importing published addressbooks of peers specified in their web of trust, +by adding in the entries provided through a third party, or (if some people organize +a series of published addressbooks using a first come first serve registration +system) people can choose to treat these addressbooks as name servers, emulating +traditional DNS. +

+ +

+I2P does not promote the use of DNS-like services though, as the damage done +by hijacking a site can be tremendous - and insecure destinations have no +value. DNSsec itself still falls back on registrars and certificate authorities, +while with I2P, requests sent to a destination cannot be intercepted or the reply +spoofed, as they are encrypted to the destination's public keys, and a destination +itself is just a pair of public keys and a certificate. DNS-style systems on the +other hand allow any of the name servers on the lookup path to mount simple denial +of service and spoofing attacks. Adding on a certificate authenticating the +responses as signed by some centralized certificate authority would address many of +the hostile nameserver issues but would leave open replay attacks as well as +hostile certificate authority attacks. +

+ +

+Voting style naming is dangerous as well, especially given the effectiveness of +Sybil attacks in anonymous systems - the attacker can simply create an arbitrarily +high number of peers and "vote" with each to take over a given name. Proof-of-work +methods can be used to make identity non-free, but as the network grows the load +required to contact everyone to conduct online voting is implausible, or if the +full network is not queried, different sets of answers may be reachable. +

+ +

+As with the Internet however, I2P is keeping the design and operation of a +naming system out of the (IP-like) communication layer. The bundled naming library +includes a simple service provider interface which alternate naming systems can +plug into, allowing end users to drive what sort of naming tradeoffs they prefer. +

+ +

Syndie

+ +

+Syndie is a safe, anonymous blogging / content publication / content aggregation system. +It lets you create information, share it with others, and read posts from those you're +interested in, all while taking into consideration your needs for security and anonymity. +Rather than building its own content distribution network, Syndie is designed to run on +top of existing networks, syndicating content through eepsites, Tor hidden services, +Freenet freesites, normal websites, usenet newgroups, email lists, RSS feeds, etc. Data +published with Syndie is done so as to offer pseudonymous authentication to anyone +reading or archiving it. +

+ +

I2PTunnel

+

Developed by: mihi

+ +

+I2PTunnel is probably I2P's most popular and versatile client application, allowing +generic proxying both into and out of the I2P network. I2PTunnel can be viewed as +four separate proxying applications - a "client" which receives inbound TCP connections +and forwards them to a given I2P destination, an "httpclient" (aka "eepproxy") which +acts like an HTTP proxy and forwards the requests to the appropriate I2P destination +(after querying the naming service if necessary), a "server" which receives inbound I2P +streaming connections on a destination and forwards them to a given TCP host+port, +and an "httpserver" which extends the "server" by parsing the HTTP request and +responses to allow safer operation. There is an additional "socksclient" application, +but its use is not encouraged for reasons previously mentioned. +

+ +

+I2P itself is not an outproxy network - the anonymity and security concerns inherent +in a mix net which forwards data into and out of the mix have kept I2P's design focused +on providing an anonymous network which capable of meeting the user's needs without +requiring external resources. However, the I2PTunnel "httpclient" application offers +a hook for outproxying - if the hostname requested doesn't end in ".i2p", it picks a +random destination from a user-provided set of outproxies and forwards the request to +them. These destinations are simply I2PTunnel "server" instances run by volunteers +who have explicitly chosen to run outproxies - no one is an outproxy by default, and +running an outproxy doesn't automatically tell other people to proxy through you. +While outproxies do have inherent weaknesses, they offer a simple proof of concept for +using I2P and provide some functionality under a threat model which may be sufficient +for some users. +

+ +

+I2PTunnel enables most of the applications in use. An "httpserver" pointing at a +webserver lets anyone run their own anonymous website (or "eepsite") - a webserver +is bundled with I2P for this purpose, but any webserver can be used. Anyone may +run a "client" pointing at one of the anonymously hosted IRC servers, each of which +are running a "server" pointing at their local IRCd and communicating between IRCds +over their own "client" tunnels. End users also have "client" tunnels pointing at +I2Pmail's POP3 and SMTP destinations (which in turn are +simply "server" instances pointing at POP3 and SMTP servers), as well as "client" +tunnels pointing at I2P's CVS server, allowing anonymous development. At times people have +even run "client" proxies to access the "server" instances pointing at an NNTP server. +

+ +

i2p-bt

+

Developed by: duck, et al

+ +

+i2p-bt is a port of the mainline python BitTorrent client to run both the tracker and +peer communication over I2P. Tracker requests are forwarded through the eepproxy to +eepsites specified in the torrent file while tracker responses refer to peers by their +destination explicitly, allowing i2p-bt to open up a +streaming lib connection to query them for blocks. +

+ +

+In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making a few +modifications as necessary to strip any anonymity-compromising information from the +application and to take into consideration the fact that IPs cannot be used for +identifying peers. +

+ +

Azureus/azneti2p

+

Developed by: parg, et al

+ +

+The developers of the Azureus BitTorrent client +have created an "azneti2p" plugin, allowing Azureus users to participate in anonymous +swarms over I2P, or simply to access anonymously hosted trackers while contacting +each peer directly. In addition, Azureus' built in tracker lets people run their +own anonymous trackers without running bytemonsoon (which has substantial prerequisites) +or i2p-bt's tracker. The plugin is currently (July 2005) fully functional, but is in early +beta and has a fairly complicated configuration process, though it is hopefully going +to be streamlined further. +

+ +

I2Phex

+

Developed by: sirup

+ +

+I2Phex is a fairly direct port of the Phex gnutella filesharing client to run +entirely on top of I2P. While it has disabled some of Phex's functionality, +such as integration with gnutella webcaches, the basic file sharing and chatting +system is fully functional. +

+ +

I2Pmail/susimail

+

Developed by: postman, susi23, mastiejaner

+ +

+I2Pmail is more a service than an application - postman offers both internal and +external email with POP3 and SMTP service through I2PTunnel instances accessing a +series of components developed with mastiejaner, allowing people to use their +preferred mail clients to send and receive mail pseudonymously. However, as most +mail clients expose substantial identifying information, I2P bundles susi23's +web based susimail client which has been built specifically with I2P's anonymity +needs in mind. The I2Pmail/mail.i2p service offers transparent virus and spam +filtering as well as denial of service prevention with hashcash augmented quotas. +In addition, each user has control of their batching strategy prior to delivery +through the mail.i2p outproxies, which are separate from the mail.i2p SMTP and +POP3 servers - both the outproxies and inproxies communicate with the mail.i2p +SMTP and POP3 servers through I2P itself, so compromising those non-anonymous +locations does not give access to the mail accounts or activity patterns of the +user. Further details and plans for future refinements can be found on the +eepsite www.postman.i2p. +

+ + +