Migrate proposals from old index

i2p2www/spec/proposals/100-restricted-routes.rst

@@ -0,0 +1,42 @@
+=================
+Restricted Routes
+=================
+.. meta::
+    :author: zzz
+    :created: 2008-09-14
+    :thread: http://zzz.i2p/topics/114
+    :lastupdated: 2008-10-13
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+
+Thoughts
+========
+
+- Add a new transport "IND" (indirect) which publishes a leaseSet hash in the
+  RouterAddress structure: "IND: [key=aababababababababb]". This transport bids
+  the lowest priority when the target router publishes it. To send to a peer via
+  this transport, fetch the leaseset from a ff peer as usual, and send it
+  directly to the lease.
+
+- A peer advertising IND must build and maintain a set of tunnels to another
+  peer. These are not exploratory tunnels and not client tunnels, but a second
+  set of router tunnels.
+
+  - 1-hop is sufficient?
+  - How to select peers for these tunnels?
+  - They need to be "non-restricted" but how do you know that? Reachability
+    mapping? Graph theory, algorithms, data structures may help here. Need to
+    read up on this. See tunnels TODO.
+
+- If you have IND tunnels then your IND transport must bid (low-priority) to
+  send messages out these tunnels.
+
+- How to decide to enable building indirect tunnels
+
+- How to implement and test without blowing cover

i2p2www/spec/proposals/101-multicast.rst

@@ -0,0 +1,37 @@
+=========
+Multicast
+=========
+.. meta::
+    :author: zzz
+    :created: 2008-12-08
+    :thread: http://zzz.i2p/topics/172
+    :lastupdated: 2009-03-25
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+Basic idea: Send one copy through your outbound tunnel, outbound endpoint
+distributes to all the inbound gateways. End-end encryption precluded.
+
+
+Thoughts
+========
+
+- New multicast tunnel message type (delivery type = 0x03)
+- Outbound endpoint multicast distribute
+- New I2NP Multicast Message type ?
+- New I2CP Multicast SendMessageMessage Message type
+- Don't encrypt router-router in OutNetMessageOneShotJob (garlic?)
+
+App:
+
+- RTSP Proxy?
+
+Streamr:
+
+- Tune MTU? Or just do it at the app?
+- On-demand receive & transmit

i2p2www/spec/proposals/102-service-directory.rst

@@ -0,0 +1,57 @@
+=================
+Service Directory
+=================
+.. meta::
+    :author: zzz
+    :created: 2009-01-01
+    :thread: http://zzz.i2p/topics/180
+    :lastupdated: 2009-01-06
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+This is similar to a proposal Sponge had a while back on IRC. I don't think he
+wrote it up, but his idea was to put it in the netDb. I'm not in favor of that,
+but the discussion of the best method of accessing the directory (netDb lookups,
+DNS-over-i2p, HTTP, hosts.txt, etc.) I will leave for another day.
+
+I could probably hack this up pretty quickly using HTTP and the collection of
+perl scripts I use for the add key form.
+
+
+Directory Interface
+===================
+
+Here's how an app would interface with the directory:
+
+REGISTER
+  - DestKey
+  - List of Protocol/Service pairs:
+
+    - Protocol (optional, default: HTTP)
+    - Service (optional, default: website)
+    - ID (optional, default: none)
+
+  - Hostname (optional)
+  - Expiration (default: 1 day? 0 for delete)
+  - Sig (using privkey for dest)
+
+  Returns: success or failure
+
+  Updates allowed
+
+LOOKUP
+  - Hash or key (optional). ONE of:
+
+    - 80-bit partial hash
+    - 256-bit full hash
+    - full destkey
+
+  - Protocol/service pair (optional)
+
+  Returns: success, failure, or (for 80-bit) collision.
+  If success, returns signed descriptor above.

i2p2www/spec/proposals/103-bigger-i2np-messages.rst

@@ -0,0 +1,37 @@
+====================
+Bigger I2NP Messages
+====================
+.. meta::
+    :author: zzz
+    :created: 2009-04-05
+    :thread: http://zzz.i2p/topics/258
+    :lastupdated: 2009-05-27
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+iMule's use of 12KB datagrams exposed lots of problems. The actual limit today
+is more like 10KB.
+
+
+Thoughts
+========
+
+To do:
+
+- Increase NTCP limit - not so easy?
+
+- More session tag quantity tweaks. May hurt max window size? Are there stats to
+  look at? Make the number variable based on how many we think they need? Can
+  they ask for more? ask for a quantity?
+
+- Investigate increasing SSU max size (by increasing MTU?)
+
+- Lots of testing
+
+- Finally check in the fragmenter improvements? - Need to do comparison testing
+  first!

i2p2www/spec/proposals/104-tls-transport.rst

@@ -0,0 +1,26 @@
+=============
+TLS Transport
+=============
+.. meta::
+    :author: zzz
+    :created: 2009-05-03
+    :thread: http://zzz.i2p/topics/287
+    :lastupdated: 2009-05-03
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+It's a frequently-suggested-suggestion that we have a snoop-resistant transport
+so that we are resistant to fingerprinting and blocking by ISPs and state-level
+adversaries, like what Tor has (i.e. tries to look like a Firefox HTTPS
+session).
+
+
+Proposal
+========
+
+TBD

i2p2www/spec/proposals/105-garlicat-name-translation.rst

@@ -0,0 +1,86 @@
+=============================
+Name Translation for GarliCat
+=============================
+.. meta::
+    :author: Bernhard R. Fischer
+    :created: 2009-12-04
+    :thread: http://zzz.i2p/topics/453
+    :lastupdated: 2009-12-04
+    :status: Draft
+
+.. contents::
+
+
+Current Translation Mechanism
+=============================
+
+GarliCat (GC) performs name translation for setting up connections to other GC
+nodes. This name translation is just a recoding of the binary representation of
+an address into the Base32 encoded form. Thus, translation works back and
+forth.
+
+Those addresses are chosen to be 80 bits long. This is because Tor uses 80 bit
+long values for addressing its hidden services. Thus, OnionCat (which is GC for
+Tor) works with Tor without further intervention.
+
+Unfortunately (in respect to this addressing scheme), I2P uses 256 bit long
+values for addressing of its services. As already mentioned, GC transcodes
+between binary and Base32 encoded form. Due to the nature of GC being a layer 3
+VPN, in its binary representation the addresses are defined to be IPv6
+addresses which have a total length of 128 bit. Obviously, 256 bit long I2P
+addresses do not fit into.
+
+Thus, a second step of name translation becomes necessary:
+IPv6 address (binary) -1a-> Base32 address (80 bits) -2a-> I2P address (256 bits)
+-1a- ... GC translation
+-2a- ... I2P hosts.txt lookup
+
+The current solution is to let the I2P router do the work. This is accomplished
+by insertion of the 80 bit Base32 address and its destination (the I2P address)
+as a name/value pair into the hosts.txt or privatehosts.txt file of the I2P
+router.
+
+This basically works but it depends on a naming service which (IMHO) itself is
+in a state of development and not mature enough (especially in respect to name
+distribution).
+
+
+A Scalable Solution
+===================
+
+I suggest to change the stages of addressing in respect to I2P (and maybe also
+for Tor) in that way that GC does reverse lookups on the IPv6 addresses using
+the regular DNS protocol. The reverse zone shall directly contain the 256 bit
+I2P address in its Base32 encoded form. This changes the lookup mechanism to a
+single step thereby adding further advantages.
+IPv6 address (binary) -1b-> I2P address (256 bits)
+-1b- ... DNS reverse lookup
+
+DNS lookups within the Internet are known to be information leaks in respect to
+anonymity. Thus, those lookups have to be carried out within I2P. This implies
+that several DNS services should be around within I2P. As DNS queries are
+usually performed by using the UDP protocol, GC itself is needed for data
+transport because it does carry UDP packets which I2P natively does not.
+
+Further advantages are associated with DNS:
+1) It is a well-known standard protocol, hence, it is continously improved and
+many tools (clients, servers, libraries,...) exist.
+2) It is a distributed system. It supports the name space being hosted on
+serveral servers in parallel by default.
+3) It supports cryptography (DNSSEC) which enables authentication of resource
+records. This could directly be tied with the keys of a destination.
+
+
+Future Opportunities
+====================
+
+It may be possible that this naming service can also be used to do forward
+lookups. This is translating hostnames into I2P addresses and/or IPv6
+addresses. But this kind of lookup needs additional investigation because those
+lookups are usually done by the locally installed resolver library which uses
+regular Internet name servers (e.g. as specified in /etc/resolv.conf on
+Unix-like systems). This is different from the reverse lookups of GC that I
+explained above.
+A further opportunity could be that the I2P address (destination) gets
+registered automatically when creating a GC inbound tunnnel. This would greatly
+improve the usability.

i2p2www/spec/proposals/106-ntcp-obfuscation.rst

@@ -0,0 +1,48 @@
+================
+NTCP Obfuscation
+================
+.. meta::
+    :author: zzz
+    :created: 2010-11-23
+    :thread: http://zzz.i2p/topics/774
+    :lastupdated: 2014-01-03
+    :status: Draft
+
+.. contents::
+
+
+Introduction
+============
+
+This is fairly heavyweight but it prevents any detection by DPI equipment.
+
+
+Modifications to NTCP
+=====================
+
+The following data will be added to the end of the 288-byte message 1:
+
+- A 514-byte ElGamal encrypted block
+- Random padding
+
+The ElG block is encrypted to Bob's public key. When decrypted to 222 bytes, it
+contains:
+- 214 bytes random padding
+- 4 bytes 0 reserved
+- 2 bytes padding length to follow
+- 2 bytes protocol version and flags
+
+In messages 2-4, the last two bytes of the padding will now indicate the length
+of more padding to follow.
+
+Note that the ElG block does not have perfect forward secrecy but there's
+nothing interesting in there.
+
+We could modify our ElG library so it will encrypt smaller data sizes if we
+think 514 bytes is way too much? Is ElG encryption for each NTCP setup too much?
+
+Support for this would be advertised in the netdb RouterAddress with the option
+"version=2". If only 288 bytes are received in Message 1, Alice is assumed to be
+version 1 and no padding is sent in subsequent messages. Note that communication
+could be blocked if a MITM fragmented IP to 288 bytes (very unlikely according
+to Brandon).

i2p2www/spec/proposals/107-bep9-information-recovery.rst

@@ -0,0 +1,68 @@
+=========================
+BEP9 Information Recovery
+=========================
+.. meta::
+    :author: sponge
+    :created: 2011-02-23
+    :thread: http://zzz.i2p/topics/860
+    :lastupdated: 2011-02-23
+    :status: Draft
+
+.. contents::
+
+
+Problem
+=======
+
+BEP9 does not send the entire torrent file, thus losing several important
+dictionary items, and changes the torrent files total SHA1. This is bad for
+maggot links, and bad because important information is lost. Tracker lists,
+comments, and any additional data is gone. A way to recover this information is
+important, and it needs to add as little as possible to the torrent file. It
+also must not be circular dependent. Recovery information should not affect
+current clients in any way. torrents that are trackerless (tracker URL is
+literally 'trackerless') do not contain the extra field, as they are specific to
+using the maggot protocol of discovery and download, which does not ever lose
+the information in the first place.
+
+
+Solution
+========
+
+All that needs to be done is to compress the information that would be lost, and
+store it in the info dictionary.
+
+
+Implementation
+--------------
+1. Generate the normal info dictionary.
+2. Generate the main dictionary, and leave out the info entry.
+3. Bencode, and compress he main dictionary with gzip.
+4. Add the compressed main dictionary to the info dictionary.
+5. Add info to the main dictionary.
+6. Write the torrent file
+
+Recovery
+--------
+1. Decompress the recovery entry in the info dict.
+2. Bendecode the recovery entry.
+3. Add info to the recovered dictionary.
+4. For maggot-aware clients, you can now verify that the SHA1 is correct.
+5. Write out the recovered torrent file.
+
+
+Discussion
+==========
+
+Using the above outlined method, the size of the torrent increase is very small,
+200 to 500 bytes is typical. Robert will be shipping with the new info
+dictionary entry creation, and it will not be able to be turned off. Here is the
+structure::
+
+    main dict {
+        Tracker strings, comments, etc...
+        info : {
+            gzipped main bencoded dict minus the info dictionary and all other
+            usual info
+        }
+    }