lokinet/docs/high-level.txt

LLARP - Low Latency Anon Routing Protocol
	
	
	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.