kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update all proposals to conform to the proposal process

Browse Source
This commit is contained in:
str4d
2016-04-25 06:09:22 +00:00
parent 63fa249f54
commit 4d1c50af7a
27 changed files with 317 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
i2p2www/spec/proposals/001-process.rst
View File

@@ -6,7 +6,7 @@ The I2P Proposal Process
:created: 2016-04-10 :created: 2016-04-10
:thread: http://zzz.i2p/topics/1980 :thread: http://zzz.i2p/topics/1980
:lastupdated: 2016-04-10 :lastupdated: 2016-04-10
:status: Draft :status: Meta
.. contents:: .. contents::

2
i2p2www/spec/proposals/100-restricted-routes.rst
View File

@@ -6,7 +6,7 @@ Restricted Routes
:created: 2008-09-14 :created: 2008-09-14
:thread: http://zzz.i2p/topics/114 :thread: http://zzz.i2p/topics/114
:lastupdated: 2008-10-13 :lastupdated: 2008-10-13
:status: Draft :status: Reserve
.. contents:: .. contents::

10
i2p2www/spec/proposals/101-multicast.rst
View File

@@ -6,20 +6,20 @@ Multicast
:created: 2008-12-08 :created: 2008-12-08
:thread: http://zzz.i2p/topics/172 :thread: http://zzz.i2p/topics/172
:lastupdated: 2009-03-25 :lastupdated: 2009-03-25
:status: Draft :status: Dead
.. contents:: .. contents::
Introduction Overview
============ ========
Basic idea: Send one copy through your outbound tunnel, outbound endpoint Basic idea: Send one copy through your outbound tunnel, outbound endpoint
distributes to all the inbound gateways. End-end encryption precluded. distributes to all the inbound gateways. End-end encryption precluded.
Thoughts Design
======== ======
- New multicast tunnel message type (delivery type = 0x03) - New multicast tunnel message type (delivery type = 0x03)
- Outbound endpoint multicast distribute - Outbound endpoint multicast distribute

20
i2p2www/spec/proposals/102-service-directory.rst
View File

@@ -6,13 +6,23 @@ Service Directory
:created: 2009-01-01 :created: 2009-01-01
:thread: http://zzz.i2p/topics/180 :thread: http://zzz.i2p/topics/180
:lastupdated: 2009-01-06 :lastupdated: 2009-01-06
:status: Draft :status: Rejected
:supercededby: 122
.. contents:: .. 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 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, 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. perl scripts I use for the add key form.
Directory Interface Specification
=================== =============
Here's how an app would interface with the directory: Here's how an app would interface with the directory:

16
i2p2www/spec/proposals/103-bigger-i2np-messages.rst
View File

@@ -6,20 +6,26 @@ Bigger I2NP Messages
:created: 2009-04-05 :created: 2009-04-05
:thread: http://zzz.i2p/topics/258 :thread: http://zzz.i2p/topics/258
:lastupdated: 2009-05-27 :lastupdated: 2009-05-27
:status: Draft :status: Dead
.. contents:: .. 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 iMule's use of 12KB datagrams exposed lots of problems. The actual limit today
is more like 10KB. is more like 10KB.
Thoughts Design
======== ======
To do: To do:

14
i2p2www/spec/proposals/104-tls-transport.rst
View File

@@ -11,8 +11,14 @@ TLS Transport
.. contents:: .. 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 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 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). session).
Proposal Design
======== ======
TBD TBD

8
i2p2www/spec/proposals/105-garlicat-name-translation.rst
View File

@@ -6,11 +6,17 @@ Name Translation for GarliCat
:created: 2009-12-04 :created: 2009-12-04
:thread: http://zzz.i2p/topics/453 :thread: http://zzz.i2p/topics/453
:lastupdated: 2009-12-04 :lastupdated: 2009-12-04
:status: Draft :status: Dead
.. contents:: .. contents::
Overview
========
This proposal is about adding support for DNS reverse lookups to I2P.
Current Translation Mechanism Current Translation Mechanism
============================= =============================

11
i2p2www/spec/proposals/106-ntcp-obfuscation.rst
View File

@@ -12,8 +12,15 @@ NTCP Obfuscation
.. contents:: .. 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 NTCP data is encrypted after the first message (and the first message appears to
be random data), thus preventing protocol identification through "payload be random data), thus preventing protocol identification through "payload

13
i2p2www/spec/proposals/107-bep9-information-recovery.rst
View File

@@ -6,13 +6,20 @@ BEP9 Information Recovery
:created: 2011-02-23 :created: 2011-02-23
:thread: http://zzz.i2p/topics/860 :thread: http://zzz.i2p/topics/860
:lastupdated: 2011-02-23 :lastupdated: 2011-02-23
:status: Draft :status: Dead
.. contents:: .. 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 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 dictionary items, and changes the torrent files total SHA1. This is bad for

15
i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst
View File

@@ -11,8 +11,15 @@ Multipath TCP for Streaming
.. contents:: .. 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. 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 - Availability
Proposal Design
======== ======
TBD TBD

31
i2p2www/spec/proposals/109-pt-transport.rst
View File

@@ -6,22 +6,33 @@ PT Transport
:created: 2014-01-09 :created: 2014-01-09
:thread: http://zzz.i2p/topics/1551 :thread: http://zzz.i2p/topics/1551
:lastupdated: 2014-09-28 :lastupdated: 2014-09-28
:status: Draft :status: Open
.. contents:: .. 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.
Thoughts
======== ========
This proposal is for creating an I2P transport that connects to other routers
through Pluggable Transports.
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: There are a few potential layers of implementation:
1. A generic PT that implements SOCKS and ExtORPort and configures and forks the 1. A generic PT that implements SOCKS and ExtORPort and configures and forks the

18
i2p2www/spec/proposals/110-leaseset-2.rst
View File

@@ -6,13 +6,21 @@ LeaseSet 2
:created: 2014-01-22 :created: 2014-01-22
:thread: http://zzz.i2p/topics/1560 :thread: http://zzz.i2p/topics/1560
:lastupdated: 2016-04-04 :lastupdated: 2016-04-04
:status: Draft :status: Rejected
:supercededby: 123
.. contents:: .. 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 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 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. it.
Format Specification
====== =============
The basic LS2 format would be like this: The basic LS2 format would be like this:

17
i2p2www/spec/proposals/111-ntcp-2.rst
View File

@@ -6,14 +6,21 @@ NTCP 2
:created: 2014-02-13 :created: 2014-02-13
:thread: http://zzz.i2p/topics/1577 :thread: http://zzz.i2p/topics/1577
:lastupdated: 2014-09-21 :lastupdated: 2014-09-21
:status: Draft :status: Open
:supercedes: 106 :supercedes: 106
.. contents:: .. 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 NTCP data is encrypted after the first message (and the first message appears to
be random data), thus preventing protocol identification through "payload 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. a lot harder.
Goals Design Goals
===== ============
- Support NTCP 1 and 2 on a single port, auto-detect. - Support NTCP 1 and 2 on a single port, auto-detect.
- Add random padding to all NTCP messages including handshake and data messages - Add random padding to all NTCP messages including handshake and data messages

2
i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst
View File

@@ -6,7 +6,7 @@ Addressbook Subscription Feed Commands
:created: 2014-09-15 :created: 2014-09-15
:thread: http://zzz.i2p/topics/1704 :thread: http://zzz.i2p/topics/1704
:lastupdated: 2016-04-17 :lastupdated: 2016-04-17
:status: Draft :status: Open
.. contents:: .. contents::

11
i2p2www/spec/proposals/113-leaseset-key-persistence.rst
View File

@@ -11,8 +11,15 @@ LeaseSet Key Persistence
.. contents:: .. 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 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 i2ptunnel.config. This helps prevent some attacks by keeping the same slice

17
i2p2www/spec/proposals/114-encrypted-streaming-flag.rst
View File

@@ -6,19 +6,26 @@
:created: 2015-01-21 :created: 2015-01-21
:thread: http://zzz.i2p/topics/1795 :thread: http://zzz.i2p/topics/1795
:lastupdated: 2015-01-21 :lastupdated: 2015-01-21
:status: Draft :status: Needs-Research
.. contents:: .. 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. 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 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 this flag it means payload is AES encrypted by key from private key and peer's

23
i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst
View File

@@ -6,15 +6,22 @@ Batch Multiple Data Cloves in Garlic
:created: 2015-01-22 :created: 2015-01-22
:thread: http://zzz.i2p/topics/1797 :thread: http://zzz.i2p/topics/1797
:lastupdated: 2015-01-22 :lastupdated: 2015-01-22
:status: Draft :status: Needs-Research
.. contents:: .. 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 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 dropping. Perhaps 3KB? Would want to instrument things first to measure how
often this would get used. often this would get used.
This is backward-compatible, as the garlic receiver will already process all
cloves it receives.
Thoughts 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 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 of tags is better fixed with proper windowing implementation in his streaming
library. library.
Compatibility
=============
This is backward-compatible, as the garlic receiver will already process all
cloves it receives.

24
i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst
View File

@@ -6,20 +6,30 @@ Prefer Nearby Routers in Keyspace
:created: 2015-04-25 :created: 2015-04-25
:thread: http://zzz.i2p/topics/1874 :thread: http://zzz.i2p/topics/1874
:lastupdated: 2015-04-25 :lastupdated: 2015-04-25
:status: Draft :status: Needs-Research
.. contents:: .. contents::
Introduction Overview
============ ========
This is an idea to improve tunnel build success, by organizing peers so that This is a proposal to organize peers so that they prefer connecting to other
they prefer connecting to other peers that are close to them in keyspace. 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 Required Changes
================ ----------------
This change would require: This change would require:
@@ -29,7 +39,7 @@ This change would require:
Advantages for Tunnel Building Advantages for Tunnel Building
============================== ------------------------------
If you build a tunnel:: If you build a tunnel::

15
i2p2www/spec/proposals/117-opt-in-statistics-collection.rst
View File

@@ -11,8 +11,15 @@ Opt-in Statistics Collection
.. contents:: .. 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 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 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. However, changing them without proper research is very risky.
Proposal Design
======== ======
The router supports vast collection of stats which can be used to analyze 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 network-wide properties. What we need is an automated reporting system which

12
i2p2www/spec/proposals/118-i2pcontrol-api-2.rst
View File

@@ -6,15 +6,15 @@ I2PControl API 2
:created: 2016-01-23 :created: 2016-01-23
:thread: http://zzz.i2p/topics/2030 :thread: http://zzz.i2p/topics/2030
:lastupdated: 2016-02-01 :lastupdated: 2016-02-01
:status: Draft :status: Open
.. contents:: .. contents::
Introduction Overview
============ ========
This page will outline the API2 for i2pcontrol This proposal outlines API2 for I2PControl.
Developer headsup! 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. users of >=API2 with simplest most coherent possible API.
API 2 API 2 Specification
===== ===================
.. raw:: html .. raw:: html

27
i2p2www/spec/proposals/119-bidirectional-tunnels.rst
View File

@@ -6,32 +6,42 @@ Bidirectional Tunnels
:created: 2016-01-07 :created: 2016-01-07
:thread: http://zzz.i2p/topics/2041 :thread: http://zzz.i2p/topics/2041
:lastupdated: 2016-01-07 :lastupdated: 2016-01-07
:status: Draft :status: Needs-Research
.. contents:: .. 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 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 routers only for now. For the network their will appear as regular inbound and
outbound tunnels. outbound tunnels.
Design
======
Goals Goals
===== -----
1. Reduce network and CPU usage by reducing number of TunnelBuild messages 1. Reduce network and CPU usage by reducing number of TunnelBuild messages
2. Ability to know instantly if a participant has gone away. 2. Ability to know instantly if a participant has gone away.
3. More accurate profiling and stats 3. More accurate profiling and stats
4. Use other darknets as intermediate peers 4. Use other darknets as intermediate peers
Tunnel modifications Tunnel modifications
==================== --------------------
TunnelBuild TunnelBuild
----------- ```````````
Tunnels are built the same way as inbound tunnels. No reply message is required. 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 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 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. additional information if it's not I2P.
TunnelTermination TunnelTermination
----------------- `````````````````
If peer want to go away it creates TunnelTermination messages encrypts with 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 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 encrypts it over with it's layer key and send to next peer. Once a messsage

20
i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst
View File

@@ -6,13 +6,21 @@ Meta-LeaseSet for Multihoming
:created: 2016-01-09 :created: 2016-01-09
:thread: http://zzz.i2p/topics/2045 :thread: http://zzz.i2p/topics/2045
:lastupdated: 2016-01-11 :lastupdated: 2016-01-11
:status: Draft :status: Rejected
:supercededby: 123
.. contents:: .. 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. 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 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. for the LS, but the first stage could be cached for hours.
Format Specification
====== =============
:: The meat-LeaseSet would have the following format::
- Destination - Destination
- Published Time stamp - Published Time stamp

41
i2p2www/spec/proposals/121-encrypted-leaseset.rst
View File

@@ -6,13 +6,20 @@ Encrypted LeaseSet
:created: 2016-01-11 :created: 2016-01-11
:thread: http://zzz.i2p/topics/2047 :thread: http://zzz.i2p/topics/2047
:lastupdated: 2016-01-12 :lastupdated: 2016-01-12
:status: Draft :status: Rejected
:supercededby: 123
.. contents:: .. 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 Current encrypted LS is horrendous and insecure. I can say that, I designed and
implemented it. implemented it.
@@ -25,22 +32,34 @@ Reasons:
- Encryption pubkey still exposed - Encryption pubkey still exposed
Design
======
Goals Goals
===== -----
- Make entire thing opaque - Make entire thing opaque
- Keys for each recipient - Keys for each recipient
Strategy Strategy
======== --------
Do like GPG/OpenPGP does. Asymmetrically encrypt a symmetric key for each 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]_ 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. 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 - Destination
- Published timestamp - Published timestamp
@@ -52,14 +71,6 @@ LS2 contents
Encrypted data could be prefixed with some enctype specifier, or not. 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 References
========== ==========

16
i2p2www/spec/proposals/122-service-lookup.rst
View File

@@ -6,17 +6,23 @@ Service Lookup
:created: 2016-01-13 :created: 2016-01-13
:thread: http://zzz.i2p/topics/2048 :thread: http://zzz.i2p/topics/2048
:lastupdated: 2016-01-13 :lastupdated: 2016-01-13
:status: Draft :status: Rejected
:supercedes: 102
:supercededby: 123
.. contents:: .. contents::
Introduction Overview
============ ========
This is the full-monty bombastic anything-goes-in-the-netdb proposal. AKA This is the full-monty bombastic anything-goes-in-the-netdb proposal. AKA
anycast. This would be the 4th proposed LS2 subtype. 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 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. 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 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. 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 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 minimum, the floodfills would have to severely rate- and capacity-limit the

15
i2p2www/spec/proposals/123-new-netdb-entries.rst
View File

@@ -6,20 +6,21 @@ New netDB Entries
:created: 2016-01-16 :created: 2016-01-16
:thread: http://zzz.i2p/topics/2051 :thread: http://zzz.i2p/topics/2051
:lastupdated: 2016-01-16 :lastupdated: 2016-01-16
:status: Draft :status: Open
:supercedes: 110, 120, 121, 122
.. contents:: .. contents::
Introduction Overview
============ ========
This is an update and aggregation of the following 4 proposals: This is an update and aggregation of the following 4 proposals:
- LS2 - 110 LS2
- Encrypted LS2 - 120 Meta LS2 for massive multihoming
- Meta LS2 for massive multihoming - 121 Encrypted LS2
- Unauthenticated service lookup (anycasting) - 122 Unauthenticated service lookup (anycasting)
These proposals are mostly independent, but for sanity we define and use a These proposals are mostly independent, but for sanity we define and use a
common format for several of them. common format for several of them.

20
i2p2www/spec/proposals/124-session-tags-reset-message.rst
View File

@@ -6,13 +6,20 @@ Reset Message for ElGamal/AES+SessionTags
:created: 2016-01-24 :created: 2016-01-24
:thread: http://zzz.i2p/topics/2056 :thread: http://zzz.i2p/topics/2056
:lastupdated: 2016-01-26 :lastupdated: 2016-01-26
:status: Draft :status: Open
.. contents:: .. 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 Imagine some destination has bunch of confirmed tags to another destination. But
that destination got restarted or lost these tags some other way. First 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. updated LeaseSet.
Design
======
Proposed Message Proposed Message
================ ----------------
This new clove must contain delivery type "destination" with a new I2NP 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 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 Usage
===== -----
If I restart my router and try to connect another destination, I send a clove 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 with my new LeaseSet, and I would send additional clove with this message

37
i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
View File

@@ -6,18 +6,32 @@ OBEP Delivery to One-of-Many Tunnels
:created: 2016-03-10 :created: 2016-03-10
:thread: http://zzz.i2p/topics/2099 :thread: http://zzz.i2p/topics/2099
:lastupdated: 2016-03-10 :lastupdated: 2016-03-10
:status: Draft :status: Open
.. contents:: .. contents::
Introduction Overview
============ ========
To reduce connection congestion, give the OBEP a list of id/hash pairs (i.e. This proposal is about delegating IBGW selection to the OBEP by providing it
leases) to deliver the message to rather than just one. The OBEP would select with a list of alternatives instead of a single option.
one of those to deliver to. The OBEP would select, if available, one that it is
already connected to, or already knows about.
Motivation
==========
The idea is to reduce connection congestion, by giving the OBEP flexibility in
how it connects to IBGWs.
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 The originator (OBGW) would stick some (all?) of the target leases in the
delivery instructions instead of picking just one. 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 This would make the OBEP-IBGW path faster and more reliable, and reduce overall
network connections. network connections.
Proposal
========
We have one unused delivery type (0x03) and two remaining bits 0 and 1) in the 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 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. specified leases), we could plan for that feature as well at the same time.
So the specification proposal is::
Specification
=============
::
Flag byte: Flag byte:
Delivery type 0x03: count byte and multiple id/hash pairs follow Delivery type 0x03: count byte and multiple id/hash pairs follow