From 4d1c50af7ad5655e62ac254ccb31d6f532eb5ccc Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 25 Apr 2016 06:09:22 +0000
Subject: [PATCH] Update all proposals to conform to the proposal process
---
i2p2www/spec/proposals/001-process.rst | 2 +-
.../spec/proposals/100-restricted-routes.rst | 2 +-
i2p2www/spec/proposals/101-multicast.rst | 10 ++---
.../spec/proposals/102-service-directory.rst | 20 ++++++---
.../proposals/103-bigger-i2np-messages.rst | 16 +++++---
i2p2www/spec/proposals/104-tls-transport.rst | 14 +++++--
.../105-garlicat-name-translation.rst | 8 +++-
.../spec/proposals/106-ntcp-obfuscation.rst | 11 ++++-
.../107-bep9-information-recovery.rst | 13 ++++--
.../108-multipath-tcp-for-streaming.rst | 15 +++++--
i2p2www/spec/proposals/109-pt-transport.rst | 27 ++++++++----
i2p2www/spec/proposals/110-leaseset-2.rst | 18 +++++---
i2p2www/spec/proposals/111-ntcp-2.rst | 17 +++++---
...addressbook-subscription-feed-commands.rst | 2 +-
.../113-leaseset-key-persistence.rst | 11 ++++-
.../114-encrypted-streaming-flag.rst | 17 +++++---
...5-batch-multiple-data-cloves-in-garlic.rst | 23 ++++++++---
.../proposals/116-prefer-near-in-keyspace.rst | 24 +++++++----
.../117-opt-in-statistics-collection.rst | 15 +++++--
.../spec/proposals/118-i2pcontrol-api-2.rst | 12 +++---
.../proposals/119-bidirectional-tunnels.rst | 27 ++++++++----
.../120-meta-leaseset-for-multihoming.rst | 20 ++++++---
.../spec/proposals/121-encrypted-leaseset.rst | 41 ++++++++++++-------
i2p2www/spec/proposals/122-service-lookup.rst | 16 +++++---
.../spec/proposals/123-new-netdb-entries.rst | 15 +++----
.../124-session-tags-reset-message.rst | 20 ++++++---
.../125-obep-to-one-of-many-tunnels.rst | 37 ++++++++++++-----
27 files changed, 315 insertions(+), 138 deletions(-)
diff --git a/i2p2www/spec/proposals/001-process.rst b/i2p2www/spec/proposals/001-process.rst
index 6fd6800b9..400007dfe 100644
--- a/i2p2www/spec/proposals/001-process.rst
+++ b/i2p2www/spec/proposals/001-process.rst
@@ -6,7 +6,7 @@ The I2P Proposal Process
:created: 2016-04-10
:thread: http://zzz.i2p/topics/1980
:lastupdated: 2016-04-10
- :status: Draft
+ :status: Meta
.. contents::
diff --git a/i2p2www/spec/proposals/100-restricted-routes.rst b/i2p2www/spec/proposals/100-restricted-routes.rst
index 0c7e90ce4..99ac670dd 100644
--- a/i2p2www/spec/proposals/100-restricted-routes.rst
+++ b/i2p2www/spec/proposals/100-restricted-routes.rst
@@ -6,7 +6,7 @@ Restricted Routes
:created: 2008-09-14
:thread: http://zzz.i2p/topics/114
:lastupdated: 2008-10-13
- :status: Draft
+ :status: Reserve
.. contents::
diff --git a/i2p2www/spec/proposals/101-multicast.rst b/i2p2www/spec/proposals/101-multicast.rst
index 9de714ff5..9917359f3 100644
--- a/i2p2www/spec/proposals/101-multicast.rst
+++ b/i2p2www/spec/proposals/101-multicast.rst
@@ -6,20 +6,20 @@ Multicast
:created: 2008-12-08
:thread: http://zzz.i2p/topics/172
:lastupdated: 2009-03-25
- :status: Draft
+ :status: Dead
.. contents::
-Introduction
-============
+Overview
+========
Basic idea: Send one copy through your outbound tunnel, outbound endpoint
distributes to all the inbound gateways. End-end encryption precluded.
-Thoughts
-========
+Design
+======
- New multicast tunnel message type (delivery type = 0x03)
- Outbound endpoint multicast distribute
diff --git a/i2p2www/spec/proposals/102-service-directory.rst b/i2p2www/spec/proposals/102-service-directory.rst
index 5e890e2a2..e88b1a9b7 100644
--- a/i2p2www/spec/proposals/102-service-directory.rst
+++ b/i2p2www/spec/proposals/102-service-directory.rst
@@ -6,13 +6,23 @@ Service Directory
:created: 2009-01-01
:thread: http://zzz.i2p/topics/180
:lastupdated: 2009-01-06
- :status: Draft
+ :status: Rejected
+ :supercededby: 122
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is for a protocol apps could use to register and look up services
+in a directory.
+
+
+Motivation
+==========
+
+The most straightforward way to support onioncat is with a service directory.
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,
@@ -23,8 +33,8 @@ 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
-===================
+Specification
+=============
Here's how an app would interface with the directory:
diff --git a/i2p2www/spec/proposals/103-bigger-i2np-messages.rst b/i2p2www/spec/proposals/103-bigger-i2np-messages.rst
index 9b84e5003..539b54460 100644
--- a/i2p2www/spec/proposals/103-bigger-i2np-messages.rst
+++ b/i2p2www/spec/proposals/103-bigger-i2np-messages.rst
@@ -6,20 +6,26 @@ Bigger I2NP Messages
:created: 2009-04-05
:thread: http://zzz.i2p/topics/258
:lastupdated: 2009-05-27
- :status: Draft
+ :status: Dead
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about increasing the size limit on I2NP messages.
+
+
+Motivation
+==========
iMule's use of 12KB datagrams exposed lots of problems. The actual limit today
is more like 10KB.
-Thoughts
-========
+Design
+======
To do:
diff --git a/i2p2www/spec/proposals/104-tls-transport.rst b/i2p2www/spec/proposals/104-tls-transport.rst
index c9128d07e..b3c86d156 100644
--- a/i2p2www/spec/proposals/104-tls-transport.rst
+++ b/i2p2www/spec/proposals/104-tls-transport.rst
@@ -11,8 +11,14 @@ TLS Transport
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about implementing a TLS-based transport.
+
+
+Motivation
+==========
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
@@ -20,7 +26,7 @@ adversaries, like what Tor has (i.e. tries to look like a Firefox HTTPS
session).
-Proposal
-========
+Design
+======
TBD
diff --git a/i2p2www/spec/proposals/105-garlicat-name-translation.rst b/i2p2www/spec/proposals/105-garlicat-name-translation.rst
index 2a2ce6131..45c2fea13 100644
--- a/i2p2www/spec/proposals/105-garlicat-name-translation.rst
+++ b/i2p2www/spec/proposals/105-garlicat-name-translation.rst
@@ -6,11 +6,17 @@ Name Translation for GarliCat
:created: 2009-12-04
:thread: http://zzz.i2p/topics/453
:lastupdated: 2009-12-04
- :status: Draft
+ :status: Dead
.. contents::
+Overview
+========
+
+This proposal is about adding support for DNS reverse lookups to I2P.
+
+
Current Translation Mechanism
=============================
diff --git a/i2p2www/spec/proposals/106-ntcp-obfuscation.rst b/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
index 72704e416..ab9dafe90 100644
--- a/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
+++ b/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
@@ -12,8 +12,15 @@ NTCP Obfuscation
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about overhauling the NTCP transport to improve its resistance
+to automated identification.
+
+
+Motivation
+==========
NTCP data is encrypted after the first message (and the first message appears to
be random data), thus preventing protocol identification through "payload
diff --git a/i2p2www/spec/proposals/107-bep9-information-recovery.rst b/i2p2www/spec/proposals/107-bep9-information-recovery.rst
index 553002aeb..b60c75de5 100644
--- a/i2p2www/spec/proposals/107-bep9-information-recovery.rst
+++ b/i2p2www/spec/proposals/107-bep9-information-recovery.rst
@@ -6,13 +6,20 @@ BEP9 Information Recovery
:created: 2011-02-23
:thread: http://zzz.i2p/topics/860
:lastupdated: 2011-02-23
- :status: Draft
+ :status: Dead
.. contents::
-Problem
-=======
+Overview
+========
+
+This proposal is about adding full information recovery to I2P's implementation
+of BEP9.
+
+
+Motivation
+==========
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
diff --git a/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst b/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst
index f656a8619..1fbdd2e05 100644
--- a/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst
+++ b/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst
@@ -11,8 +11,15 @@ Multipath TCP for Streaming
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about extending streaming to use multiple tunnels per
+connection, similar to multipath TCP.
+
+
+Motivation
+==========
Client tunnels are used by the streaming lib in a fairly standard TCP manner.
@@ -24,7 +31,7 @@ tunnels are used based on individual characteristics like:
- Availability
-Proposal
-========
+Design
+======
TBD
diff --git a/i2p2www/spec/proposals/109-pt-transport.rst b/i2p2www/spec/proposals/109-pt-transport.rst
index 44ac53428..9a91e4d06 100644
--- a/i2p2www/spec/proposals/109-pt-transport.rst
+++ b/i2p2www/spec/proposals/109-pt-transport.rst
@@ -6,21 +6,32 @@ PT Transport
:created: 2014-01-09
:thread: http://zzz.i2p/topics/1551
:lastupdated: 2014-09-28
- :status: Draft
+ :status: Open
.. contents::
-Introduction
-============
+Overview
+========
-The general idea is to use Pluggable Transports (PTs) as an I2P transport for
-communication between routers. It would be an easy way to experiment with
-alternative protocols, and get ready for I2P blocking resistance.
+This proposal is for creating an I2P transport that connects to other routers
+through Pluggable Transports.
-Thoughts
-========
+Motivation
+==========
+
+Pluggable Transports (PTs) were developed by Tor as a way to add obfuscation
+transports to Tor bridges in a modular way.
+
+I2P already has a modular transport system that decreases the barrier to adding
+alternative transports. Adding support for PTs would provide I2P with an easy
+way to experiment with alternative protocols, and get ready for blocking
+resistance.
+
+
+Design
+======
There are a few potential layers of implementation:
diff --git a/i2p2www/spec/proposals/110-leaseset-2.rst b/i2p2www/spec/proposals/110-leaseset-2.rst
index 16150ea73..73cbd6113 100644
--- a/i2p2www/spec/proposals/110-leaseset-2.rst
+++ b/i2p2www/spec/proposals/110-leaseset-2.rst
@@ -6,13 +6,21 @@ LeaseSet 2
:created: 2014-01-22
:thread: http://zzz.i2p/topics/1560
:lastupdated: 2016-04-04
- :status: Draft
+ :status: Rejected
+ :supercededby: 123
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about a new LeaseSet format with support for newer encryption
+types.
+
+
+Motivation
+==========
The end-to-end cryptography used through I2P tunnels has separate encryption and
signing keys. The signing keys are in the tunnel Destination, which has already
@@ -27,8 +35,8 @@ will be guaranteed to have support for any encryption types introduced alongside
it.
-Format
-======
+Specification
+=============
The basic LS2 format would be like this:
diff --git a/i2p2www/spec/proposals/111-ntcp-2.rst b/i2p2www/spec/proposals/111-ntcp-2.rst
index c052a2354..b69bff060 100644
--- a/i2p2www/spec/proposals/111-ntcp-2.rst
+++ b/i2p2www/spec/proposals/111-ntcp-2.rst
@@ -6,14 +6,21 @@ NTCP 2
:created: 2014-02-13
:thread: http://zzz.i2p/topics/1577
:lastupdated: 2014-09-21
- :status: Draft
+ :status: Open
:supercedes: 106
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about overhauling the NTCP transport to improve its resistance
+to various forms of automated identification and attacks.
+
+
+Motivation
+==========
NTCP data is encrypted after the first message (and the first message appears to
be random data), thus preventing protocol identification through "payload
@@ -25,8 +32,8 @@ By adding random amounts of random data to each of the messages, we can make it
a lot harder.
-Goals
-=====
+Design Goals
+============
- Support NTCP 1 and 2 on a single port, auto-detect.
- Add random padding to all NTCP messages including handshake and data messages
diff --git a/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst b/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst
index 5e3a68312..fd2409f4b 100644
--- a/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst
+++ b/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst
@@ -6,7 +6,7 @@ Addressbook Subscription Feed Commands
:created: 2014-09-15
:thread: http://zzz.i2p/topics/1704
:lastupdated: 2016-04-17
- :status: Draft
+ :status: Open
.. contents::
diff --git a/i2p2www/spec/proposals/113-leaseset-key-persistence.rst b/i2p2www/spec/proposals/113-leaseset-key-persistence.rst
index 03882b6bc..19624e578 100644
--- a/i2p2www/spec/proposals/113-leaseset-key-persistence.rst
+++ b/i2p2www/spec/proposals/113-leaseset-key-persistence.rst
@@ -11,8 +11,15 @@ LeaseSet Key Persistence
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about persisting additional data in the LeaseSet that is
+currently ephemeral.
+
+
+Motivation
+==========
In 0.9.17 persistence was added for the netDb slicing key, stored in
i2ptunnel.config. This helps prevent some attacks by keeping the same slice
diff --git a/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst b/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst
index a632bce9e..632d71798 100644
--- a/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst
+++ b/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst
@@ -6,19 +6,26 @@
:created: 2015-01-21
:thread: http://zzz.i2p/topics/1795
:lastupdated: 2015-01-21
- :status: Draft
+ :status: Needs-Research
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about adding a flag to streaming that specifies the type of
+end-to-end encryption being used.
+
+
+Motivation
+==========
High-loaded apps can encounter a shortage of ElGamal/AES+SessionTags tags.
-Proposal
-========
+Design
+======
Add a new flag somewhere within the streaming protocol. If a packets comes with
this flag it means payload is AES encrypted by key from private key and peer's
diff --git a/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst b/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst
index 7591b3007..285522b6f 100644
--- a/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst
+++ b/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst
@@ -6,15 +6,22 @@ Batch Multiple Data Cloves in Garlic
:created: 2015-01-22
:thread: http://zzz.i2p/topics/1797
:lastupdated: 2015-01-22
- :status: Draft
+ :status: Needs-Research
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about sending multiple Data Garlic Cloves inside an end-to-end
+Garlic Message, instead of just one.
+
+Motivation
+==========
+Not clear.
Required Changes
@@ -26,9 +33,6 @@ necessary. Any batching would have to honor a max garlic size to minimize
dropping. Perhaps 3KB? Would want to instrument things first to measure how
often this would get used.
-This is backward-compatible, as the garlic receiver will already process all
-cloves it receives.
-
Thoughts
========
@@ -43,3 +47,10 @@ uncompressible. What does this leave? I2pd doesn't currently do the x-i2p-gzip
compression so it may help there a lot more. But stated goal of not running out
of tags is better fixed with proper windowing implementation in his streaming
library.
+
+
+Compatibility
+=============
+
+This is backward-compatible, as the garlic receiver will already process all
+cloves it receives.
diff --git a/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst b/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst
index c2877a5f0..e4b320aba 100644
--- a/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst
+++ b/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst
@@ -6,20 +6,30 @@ Prefer Nearby Routers in Keyspace
:created: 2015-04-25
:thread: http://zzz.i2p/topics/1874
:lastupdated: 2015-04-25
- :status: Draft
+ :status: Needs-Research
.. contents::
-Introduction
-============
+Overview
+========
-This is an idea to improve tunnel build success, by organizing peers so that
-they prefer connecting to other peers that are close to them in keyspace.
+This is a proposal to organize peers so that they prefer connecting to other
+peers that are close to them in keyspace.
+Motivation
+==========
+
+The idea is to improve tunnel build success, by increasing the probability that
+a router is already connected to another.
+
+
+Design
+======
+
Required Changes
-================
+----------------
This change would require:
@@ -29,7 +39,7 @@ This change would require:
Advantages for Tunnel Building
-==============================
+------------------------------
If you build a tunnel::
diff --git a/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst b/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst
index 3c06c40a7..7b9cd5335 100644
--- a/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst
+++ b/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst
@@ -11,8 +11,15 @@ Opt-in Statistics Collection
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about an opt-in automated reporting system for network
+statistics.
+
+
+Motivation
+==========
Currently there are several network parameters which have been determined by
educated guessing. It is suspected that some of those can be tweaked to improve
@@ -20,8 +27,8 @@ the overall performance of the network in terms of speed, reliability and so on.
However, changing them without proper research is very risky.
-Proposal
-========
+Design
+======
The router supports vast collection of stats which can be used to analyze
network-wide properties. What we need is an automated reporting system which
diff --git a/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst b/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst
index a0e33821a..2b3b4b79b 100644
--- a/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst
+++ b/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst
@@ -6,15 +6,15 @@ I2PControl API 2
:created: 2016-01-23
:thread: http://zzz.i2p/topics/2030
:lastupdated: 2016-02-01
- :status: Draft
+ :status: Open
.. contents::
-Introduction
-============
+Overview
+========
-This page will outline the API2 for i2pcontrol
+This proposal outlines API2 for I2PControl.
Developer headsup!
@@ -25,8 +25,8 @@ compatibility with API1 implementations. The reasons for this is to provide
users of >=API2 with simplest most coherent possible API.
-API 2
-=====
+API 2 Specification
+===================
.. raw:: html
diff --git a/i2p2www/spec/proposals/119-bidirectional-tunnels.rst b/i2p2www/spec/proposals/119-bidirectional-tunnels.rst
index 2d52af5eb..98ea916ce 100644
--- a/i2p2www/spec/proposals/119-bidirectional-tunnels.rst
+++ b/i2p2www/spec/proposals/119-bidirectional-tunnels.rst
@@ -6,32 +6,42 @@ Bidirectional Tunnels
:created: 2016-01-07
:thread: http://zzz.i2p/topics/2041
:lastupdated: 2016-01-07
- :status: Draft
+ :status: Needs-Research
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about implementing bidirectional tunnels in I2P.
+
+
+Motivation
+==========
i2pd is going to introduce bi-directional tunnels build through other i2pd
routers only for now. For the network their will appear as regular inbound and
outbound tunnels.
+
+Design
+======
+
Goals
-=====
+-----
1. Reduce network and CPU usage by reducing number of TunnelBuild messages
2. Ability to know instantly if a participant has gone away.
3. More accurate profiling and stats
4. Use other darknets as intermediate peers
+
Tunnel modifications
-====================
+--------------------
TunnelBuild
------------
-
+```````````
Tunnels are built the same way as inbound tunnels. No reply message is required.
There is special type of participant called "entrance" marked by flag, serving
as IBGW and OBEP at the same time. Message has the same format as
@@ -49,8 +59,7 @@ It will also contain field mentioning what darknet next peer belong to and some
additional information if it's not I2P.
TunnelTermination
------------------
-
+`````````````````
If peer want to go away it creates TunnelTermination messages encrypts with
layer key and send in "in" direction. If a participant receive such message it
encrypts it over with it's layer key and send to next peer. Once a messsage
diff --git a/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst b/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst
index faf144627..926a13835 100644
--- a/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst
+++ b/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst
@@ -6,13 +6,21 @@ Meta-LeaseSet for Multihoming
:created: 2016-01-09
:thread: http://zzz.i2p/topics/2045
:lastupdated: 2016-01-11
- :status: Draft
+ :status: Rejected
+ :supercededby: 123
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about implementing proper multihoming support in I2P that can
+scale up to large sites.
+
+
+Motivation
+==========
Multihoming is a hack and presumably won't work for e.g. facebook.i2p at scale.
Say we had 100 multihomes each with 16 tunnels, that's 1600 LS publishes every
@@ -24,10 +32,10 @@ would be long-lived, a lot longer than 10 minutes. So it's a two-stage lookup
for the LS, but the first stage could be cached for hours.
-Format
-======
+Specification
+=============
-::
+The meat-LeaseSet would have the following format::
- Destination
- Published Time stamp
diff --git a/i2p2www/spec/proposals/121-encrypted-leaseset.rst b/i2p2www/spec/proposals/121-encrypted-leaseset.rst
index 7201ea7be..9e1443aa4 100644
--- a/i2p2www/spec/proposals/121-encrypted-leaseset.rst
+++ b/i2p2www/spec/proposals/121-encrypted-leaseset.rst
@@ -6,13 +6,20 @@ Encrypted LeaseSet
:created: 2016-01-11
:thread: http://zzz.i2p/topics/2047
:lastupdated: 2016-01-12
- :status: Draft
+ :status: Rejected
+ :supercededby: 123
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about redesigning the mechanism for encrypting LeaseSets.
+
+
+Motivation
+==========
Current encrypted LS is horrendous and insecure. I can say that, I designed and
implemented it.
@@ -25,22 +32,34 @@ Reasons:
- Encryption pubkey still exposed
+Design
+======
+
Goals
-=====
+-----
- Make entire thing opaque
- Keys for each recipient
Strategy
-========
+--------
Do like GPG/OpenPGP does. Asymmetrically encrypt a symmetric key for each
recipient. Data is decrypted with that asymmetric key. See e.g. [RFC-4880-S5.1]_
IF we can find an algo that's small and fast.
-LS2 contents
-------------
+Trick is finding an asymmetric encryption that's small and fast. ElGamal at 514
+bytes is a little painful here. We can do better.
+
+See e.g. http://security.stackexchange.com/questions/824...
+
+This works for small numbers of recipients (or actually, keys; you can still
+distribute keys to multiple people if you like).
+
+
+Specification
+=============
- Destination
- Published timestamp
@@ -52,14 +71,6 @@ LS2 contents
Encrypted data could be prefixed with some enctype specifier, or not.
-Trick is finding an asymmetric encryption that's small and fast. ElGamal at 514
-bytes is a little painful here. We can do better.
-
-See e.g. http://security.stackexchange.com/questions/824...
-
-This works for small numbers of recipients (or actually, keys; you can still
-distribute keys to multiple people if you like).
-
References
==========
diff --git a/i2p2www/spec/proposals/122-service-lookup.rst b/i2p2www/spec/proposals/122-service-lookup.rst
index dea004c25..30cf154f3 100644
--- a/i2p2www/spec/proposals/122-service-lookup.rst
+++ b/i2p2www/spec/proposals/122-service-lookup.rst
@@ -6,17 +6,23 @@ Service Lookup
:created: 2016-01-13
:thread: http://zzz.i2p/topics/2048
:lastupdated: 2016-01-13
- :status: Draft
+ :status: Rejected
+ :supercedes: 102
+ :supercededby: 123
.. contents::
-Introduction
-============
+Overview
+========
This is the full-monty bombastic anything-goes-in-the-netdb proposal. AKA
anycast. This would be the 4th proposed LS2 subtype.
+
+Motivation
+==========
+
Say you wanted to advertise your destination as an outproxy, or a GNS node, or a
Tor gateway, or a Bittorrent DHT or imule or i2phex or Seedless bootstrap, etc.
You could store this information in the netDB instead of using a separate
@@ -51,8 +57,8 @@ When somebody did a lookup, they would get back a list of those records:
Expirations would be relatively long, hours at least.
-Considerations
-==============
+Security implications
+=====================
The downside is that this could turn into the Bittorrent DHT or worse. At a
minimum, the floodfills would have to severely rate- and capacity-limit the
diff --git a/i2p2www/spec/proposals/123-new-netdb-entries.rst b/i2p2www/spec/proposals/123-new-netdb-entries.rst
index 6c93c2869..d200571ad 100644
--- a/i2p2www/spec/proposals/123-new-netdb-entries.rst
+++ b/i2p2www/spec/proposals/123-new-netdb-entries.rst
@@ -6,20 +6,21 @@ New netDB Entries
:created: 2016-01-16
:thread: http://zzz.i2p/topics/2051
:lastupdated: 2016-01-16
- :status: Draft
+ :status: Open
+ :supercedes: 110, 120, 121, 122
.. contents::
-Introduction
-============
+Overview
+========
This is an update and aggregation of the following 4 proposals:
-- LS2
-- Encrypted LS2
-- Meta LS2 for massive multihoming
-- Unauthenticated service lookup (anycasting)
+- 110 LS2
+- 120 Meta LS2 for massive multihoming
+- 121 Encrypted LS2
+- 122 Unauthenticated service lookup (anycasting)
These proposals are mostly independent, but for sanity we define and use a
common format for several of them.
diff --git a/i2p2www/spec/proposals/124-session-tags-reset-message.rst b/i2p2www/spec/proposals/124-session-tags-reset-message.rst
index 6a64863f1..17665135b 100644
--- a/i2p2www/spec/proposals/124-session-tags-reset-message.rst
+++ b/i2p2www/spec/proposals/124-session-tags-reset-message.rst
@@ -6,13 +6,20 @@ Reset Message for ElGamal/AES+SessionTags
:created: 2016-01-24
:thread: http://zzz.i2p/topics/2056
:lastupdated: 2016-01-26
- :status: Draft
+ :status: Open
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is for an I2NP message that can be used to reset the session tags
+between two Destinations.
+
+
+Motivation
+==========
Imagine some destination has bunch of confirmed tags to another destination. But
that destination got restarted or lost these tags some other way. First
@@ -22,8 +29,11 @@ decrypt. Second destination should have a way to tell first destination to reset
updated LeaseSet.
+Design
+======
+
Proposed Message
-================
+----------------
This new clove must contain delivery type "destination" with a new I2NP message
called like "Tags reset" and containing sender's ident hash. It should include
@@ -33,7 +43,7 @@ Can be sent at any time if a destination can't decrypt messages.
Usage
-=====
+-----
If I restart my router and try to connect another destination, I send a clove
with my new LeaseSet, and I would send additional clove with this message
diff --git a/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst b/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
index b0dfc2485..5760f3d03 100644
--- a/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
+++ b/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
@@ -6,18 +6,32 @@ OBEP Delivery to One-of-Many Tunnels
:created: 2016-03-10
:thread: http://zzz.i2p/topics/2099
:lastupdated: 2016-03-10
- :status: Draft
+ :status: Open
.. contents::
-Introduction
-============
+Overview
+========
+
+This proposal is about delegating IBGW selection to the OBEP by providing it
+with a list of alternatives instead of a single option.
+
+
+Motivation
+==========
+
+The idea is to reduce connection congestion, by giving the OBEP flexibility in
+how it connects to IBGWs.
+
-To reduce connection congestion, give the OBEP a list of id/hash pairs (i.e.
-leases) to deliver the message to rather than just one. The OBEP would select
-one of those to deliver to. The OBEP would select, if available, one that it is
-already connected to, or already knows about.
+Design
+======
+
+Give the OBEP a list of id/hash pairs (i.e. leases) to deliver the message to
+rather than just one. The OBEP would select one of those to deliver to. The OBEP
+would select, if available, one that it is already connected to, or already
+knows about.
The originator (OBGW) would stick some (all?) of the target leases in the
delivery instructions instead of picking just one.
@@ -25,14 +39,15 @@ delivery instructions instead of picking just one.
This would make the OBEP-IBGW path faster and more reliable, and reduce overall
network connections.
-Proposal
-========
-
We have one unused delivery type (0x03) and two remaining bits 0 and 1) in the
flags. Because we've previously discussed multicast at the OBEP (deliver to all
specified leases), we could plan for that feature as well at the same time.
-So the specification proposal is::
+
+Specification
+=============
+
+::
Flag byte:
Delivery type 0x03: count byte and multiple id/hash pairs follow
--
GitLab