Update all proposals to conform to the proposal process
This commit is contained in:
str4d
@ -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::
|
||||
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
=============================
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -6,22 +6,33 @@ PT Transport
|
||||
:created: 2014-01-09
|
||||
:thread: http://zzz.i2p/topics/1551
|
||||
:lastupdated: 2014-09-28
|
||||
:status: Draft
|
||||
:status: Open
|
||||
|
||||
.. contents::
|
||||
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
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
|
||||
Overview
|
||||
========
|
||||
|
||||
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:
|
||||
|
||||
1. A generic PT that implements SOCKS and ExtORPort and configures and forks the
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
==========
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
========
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user