From 318c59641e88fa5362e7be4a21c5c7ee143dd24c Mon Sep 17 00:00:00 2001 From: KeeJef <27277414+KeeJef@users.noreply.github.com> Date: Mon, 18 Jun 2018 18:18:22 +1000 Subject: [PATCH] Spelling/formatting/wording cleanup Reading for public --- doc/high-level.txt | 273 +++++++++++++++++++++++---------------------- 1 file changed, 138 insertions(+), 135 deletions(-) diff --git a/doc/high-level.txt b/doc/high-level.txt index d7aa9a5ec..34f940ea4 100644 --- a/doc/high-level.txt +++ b/doc/high-level.txt @@ -1,138 +1,141 @@ LLARP - Low Latency Anon Routing Protocol - -This document describes the high level outline of LLARP, specific ally the -project's goals, non-goals and network architecture from a bird's eye view. - -Preface: - -Working on I2P has been a really big learning experience for everyone involved. -After much deliberation I have decided to start making a "next generation" onion -routing protocol. Specifically LLARP is (currently) my PERSONAL research project -to explore the question: - -"What if I2P was made in the current year (2018)? What would be different?" - -Project Non Goals: - -This project does not attempt to solve traffic shape correlation or active nation -state sponsored network attacks. The former is an inherit property of low latency -computer networks that I personally do not think is possible to properly fully -"solve". The latter is a threat that lies outside the scope of what the current -toolset that is available to me at the moment. - -This project does not attempt to be a magical application level cure-all for -application or end user security. At the end of the day that is a problem that -exists between chair and keyboard. - -The Single Project Goal: - -LLARP is a protocol suite meant to anonymize IP by providing an anonymous -network level (IPv4/IPv6) tunnel broker for both "hidden serivces" and -communication back to "the clearnet" (the normal internet). Both hidden service -and clearnet communication MUST permit both outbound and inbound traffic on the -network level without any NAT (expcet for IPv4 in which NAT is permitted due to -lack of address availability). - -In short We want to permit both anonymous exit and entry network level traffic -between LLARP enabled networks and the internet. - -Rationale for starting over: - -Despite Tor Project's best efforts to popularize Tor use, Tor2Web seems to be -widely popular for people who do not wish to opt into the ecosystem. My proposed -solution would be to permit inbound traffic from "exit nodes" in additon to -allowing outbound exit traffic. I have no ideas on how this could be done with -the existing protocols in Tor or if it is possible or advisable to attempt such -as I am not familiar with their ecosystem. - -I2P could have beeen used as a medium for encrypted anonymous IP transit but the -current network has issues with latency and throughput. Rebasing I2P atop more -modern cryptography has been going on internally inside I2P for at least 5 years -with less progress than desired. Like some before me, I have concluded that it -would be faster to redo the whole stack "the right way" than to wait for I2P to -finish rebasing. That being said, nothing is preventing I2P from be used for -encrypted anonymous IP transit traffic in a future where I2P finishes their -protocol migrations, I just don't want to wait. - -In short, I want to take the "best parts" from Tor and I2P and make a new -protocol suite. - -For both Tor and I2P I have 2 categories for the attributes they have. - -the good -the bad and the ugly - -The good (I2P): - -I2P aims to provide an anonymous unspoofable load balanced network layer. - -I want this feature. - -I2P is trust agile, it does not have any hard coded trusts in its network -archetecture. Even network boostrap can be done from a single router if the user -desires to (albiet this is currenly ill advised). - -I want this feature. - -The good (Tor): - -Tor embraces the reality of the current intneret infrastructure by having a -client/server architecture. This allows very low barriers of entry in using the -Tor network and a higher barrier of entry for contributing routing -infrastructure. This promotes a healthy network shape of high capacity servers -serving low capacity clients that "dangle off of the side" of the network. - -I want this feature. - -The bad and the ugly (I2P): - -Bad: I2P uses old cryptography, specically 2048 bit ElGamal using non standard primes. -The use of ElGamal is so pervasive throughout the I2P protocol stack that it -exists at every level of it. Removing it is a massive task that is taking a long -LONG time. - -I don't want this feature. - -Ugly: I2P cannot currently mitigate most sybil attacks with their current network -architecture. Recently I2P has added some blocklist solutions signed by release -signers but this probably won't scale in the event of a "big" attack. In -addition I2P isn't staffed for such attacks either. - -This is a hard problem to solve that the loki network may be able to help with. -More research is needed. - -The bad and the ugly (Tor): - -Bad: Tor is strictly TCP oriented. -I don't want this feature. - -Ugly: Tor isn't very trust agile. Tor has a hard coded directory authority list. -It cannot be altered trivially by the end user. - -This is also a hard problem to solve that the loki network also may be able to -help with. More research is needed. + + + This document describes the high level outline of LLARP, specific all the + project's goals, non-goals and network architecture from a bird's eye view. + + + Preface: + + + Working on I2P has been a really big learning experience for everyone involved. + After much deliberation I have decided to start making a "next generation" onion + routing protocol. Specifically LLARP is (currently) a research project + to explore the question: + + + "What if I2P was made in the current year (2018)? What would be different?" + + + Project Non Goals: + + + This project does not attempt to solve traffic shape correlation or active nation + state sponsored network attacks. The former is an inherit property of low latency + computer networks that I personally do not think is possible to properly fully + "solve". The latter is a threat that lies outside the scope of what the current + toolset that is available to me at the moment. + + + This project does not attempt to be a magical application level cure-all for + application or end user security. At the end of the day that is a problem that + exists between chair and keyboard. + + + The Single Project Goal: + + + LLARP is a protocol suite meant to anonymize IP by providing an anonymous + network level (IPv4/IPv6) tunnel broker for both "hidden services" and + communication back to "the clearnet" (the normal internet). Both hidden service + and clearnet communication MUST permit both outbound and inbound traffic on the + network level without any NAT (expect for IPv4 in which NAT is permitted due to + lack of address availability). + + + In short We want to permit both anonymous exit and entry network level traffic + between LLARP enabled networks and the internet. + + + Rationale for starting over: + + + Despite Tor Project's best efforts to popularize Tor use, Tor2Web seems to be + widely popular for people who do not wish to opt into the ecosystem. My proposed + solution would be to permit inbound traffic from "exit nodes" in addition to + allowing outbound exit traffic. I have no ideas on how this could be done with + the existing protocols in Tor or if it is possible or advisable to attempt such + as I am not familiar with their ecosystem. + + + I2P could have been used as a medium for encrypted anonymous IP transit but the + current network has issues with latency and throughput. Rebasing I2P atop more + modern cryptography has been going on internally inside I2P for at least 5 years + with less progress than desired. Like some before me, I have concluded that it + would be faster to redo the whole stack "the right way" than to wait for I2P to + finish rebasing. That being said, nothing is preventing I2P from be used for + encrypted anonymous IP transit traffic in a future where I2P finishes their + protocol migrations, I just don't want to wait. + + + In short, I want to take the "best parts" from Tor and I2P and make a new + protocol suite. + + + For both Tor and I2P I have 2 categories for the attributes they have. + + + the good + the bad and the ugly + + + The good (I2P): + + + I2P aims to provide an anonymous unspoofable load balanced network layer. + + + I want this feature. + + + I2P is trust agile, it does not have any hard coded trusts in its network + architecture. Even network boostrap can be done from a single router if the user + desires to (albeit this is currently ill advised). + + + I want this feature. + + + The good (Tor): + + + Tor embraces the reality of the current internet infrastructure by having a + client/server architecture. This allows very low barriers of entry in using the + Tor network and a higher barrier of entry for contributing routing + infrastructure. This promotes a healthy network shape of high capacity servers + serving low capacity clients that "dangle off of the side" of the network. + + + I want this feature. + + + The bad and the ugly (I2P): + + + Bad: I2P uses old cryptography, specially 2048 bit ElGamal using non standard primes. + The use of ElGamal is so pervasive throughout the I2P protocol stack that it + exists at every level of it. Removing it is a massive task that is taking a long + LONG time. + + + I don't want this feature. + + + Ugly: I2P cannot currently mitigate most sybil attacks with their current network + architecture. Recently I2P has added some blocklist solutions signed by release + signers but this probably won't scale in the event of a "big" attack. In + addition I2P isn't staffed for such attacks either. + + + This is a hard problem to solve that the Loki network may be able to help + with by creating a financial barrier to running multiple a relays. + + + + The bad and the ugly (Tor): + + + Bad: Tor is strictly TCP oriented. + I don't want this feature. -Conclusion: - -LLARP attempts to be a Low Latency, Client/Server based, Anonymous Unspoofable -Load Balanced Packet based Network Layer with Inbound (Entry), Outbound (Exit) -and Hidden Service (Internal) IP connectivity. - -There is a Possibilty of using the Loki Network's Service Nodes for Sybil -Mitigation. More research is needed. - -The immediate future: - -The Loki network recently approached me with their white paper and has peaked my -interest in some of the sybil attacks they claimed to have solved with their -protocol. I will attempt to some how make LLARP utilize their technology in the -future. - -For now, it is easier to do an i2p network fork with some i2pd specific features -applied network wide. Specifically bidirectional tunnels, full replacement of -ElGamal 2048 with curve25519/EdIES from all levels of the protocol and possibly -implementing a new UDP based i2np transport. Changing the i2p network id and -deploying on an internal test network is implied. - -More research is needed.