I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Next batch of proposal migrations

Browse Source
This commit is contained in:
str4d
2016-04-04 12:51:03 +00:00
parent 46e15852c0
commit eb91dbfc8a
11 changed files with 951 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -6,7 +6,7 @@ NTCP Obfuscation
:created: 2010-11-23
:thread: http://zzz.i2p/topics/774
:lastupdated: 2014-01-03
:status: Draft
:status: Rejected
.. contents::
@ -14,12 +14,21 @@ NTCP Obfuscation
Introduction
============
This is fairly heavyweight but it prevents any detection by DPI equipment.
NTCP data is encrypted after the first message (and the first message appears to
be random data), thus preventing protocol identification through "payload
analysis". It is still vulnerable to protocol identification through "flow
analysis". That's because the first 4 messages (i.e. the handshake) are fixed
length (288, 304, 448, and 48 bytes).
By adding random amounts of random data to each of the messages, we can make it
a lot harder.
Modifications to NTCP
=====================
This is fairly heavyweight but it prevents any detection by DPI equipment.
The following data will be added to the end of the 288-byte message 1:
- A 514-byte ElGamal encrypted block

35
i2p2www/spec/proposals/108-pt-transport.rst Normal file
View File

@ -0,0 +1,35 @@
============
PT Transport
============
.. meta::
:author: zzz
:created: 2014-01-09
:thread: http://zzz.i2p/topics/1551
:lastupdated: 2014-09-28
:status: Draft
.. 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
========
There are a few potential layers of implementation:
1. A generic PT that implements SOCKS and ExtORPort and configures and forks the
in and out processes, and registers with the comm system. This layer knows
nothing about NTCP, and it may or may not use NTCP. Good for testing.
2. Building on 1), a generic NTCP PT that builds on the NTCP code and funnels
NTCP to 1).
3. Building on 2), a specific NTCP-xxxx PT configured to run a given external in
and out process.

46
i2p2www/spec/proposals/109-leaseset-2.rst Normal file
View File

@ -0,0 +1,46 @@
==========
LeaseSet 2
==========
.. meta::
:author: zzz
:created: 2014-01-22
:thread: http://zzz.i2p/topics/1560
:lastupdated: 2016-04-04
:status: Draft
.. contents::
Introduction
============
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
been extended with KeyCertificates to support newer signature types. However,
the encryption keys are part of the LeaseSet, which doesn't contain any
Certificates. It is therefore necessary to implement a new LeaseSet format, and
add support for storing it in the netDb.
A silver lining is that once LS2 is implemented, all existing Destinations can
make use of more modern encryption types; routers that can fetch and read a LS2
will be guaranteed to have support for any encryption types introduced alongside
it.
Format
======
The basic LS2 format would be like this:
- dest
- published timestamp (8 bytes)
- expires (8 bytes)
- subtype (1 byte) (regular, encrypted, meta, or service)
- flags (2 bytes)
- subtype-specific part:
- encryption type, encryption key, and leases for regular
- blob for encrypted
- properties, hashes, ports, revocations, etc. for service
- signature

208
i2p2www/spec/proposals/110-ntcp-2.rst Normal file
View File

@ -0,0 +1,208 @@
======
NTCP 2
======
.. meta::
:author: zzz
:created: 2014-02-13
:thread: http://zzz.i2p/topics/1577
:lastupdated: 2014-09-21
:status: Draft
.. contents::
Introduction
============
NTCP data is encrypted after the first message (and the first message appears to
be random data), thus preventing protocol identification through "payload
analysis". It is still vulnerable to protocol identification through "flow
analysis". That's because the first 4 messages (i.e. the handshake) are fixed
length (288, 304, 448, and 48 bytes).
By adding random amounts of random data to each of the messages, we can make it
a lot harder.
Goals
=====
- Support NTCP 1 and 2 on a single port, auto-detect.
- Add random padding to all NTCP messages including handshake and data messages
(i.e. length obfuscation so all messages aren't a multiple of 16 bytes)
- Obfuscate the contents of messages that aren't encrypted (1 and 2), sufficiently
so that DPI boxes can't classify them. Also ensure that the messages going to
a single peer or set of peers do not have a similar pattern of bits
- Fix loss of bits in DH due to Java format (ticket #1112)
- Add "probing resistance" (as Tor calls it), this includes replay resistance
- Add options/version in handshake for future extensibility
- Add resistance to malicious MitM segmentation if possible
- Don't add significantly to CPU required for connection setup
- Minimize changes
Router Address
==============
Transport identifier is "NTCP" as before.
Routers would publish "ver=1,2" in the Router Address (not the Router Info)
if they support both NTCP 1 and NTCP 2 on the same port.
That's what we would do in Java.
"ver=1" is NTCP 1 only. This is the default if no "ver" is present.
"ver=2" is NTCP 2 only. This can't be used for a long time, as it's not
backwards-compatible. But sometime in the future, implementers could
support version 2 only.
Alternative: Make it something easier to parse, where it's the integer
representation of a bitfield. ver=3 means you support version 1 and 2.
ver=7 means you support versions 1, 2, and 3.
Messages
========
1) Session Request
------------------
Message 1 is obfuscated with random padding,
and the options block is AES-encrypted with Bob's (publicly known) router hash
as a cheap form of obfuscation.
There is no requirement that the session request be unbreakably encrypted,
e.g. with Bob's encryption key, as there's nothing secret in here and that would be
too expensive.
current:
- 256 byte X
- 32 byte H(x) ^ H(RI)
proposed:
- 16 byte MAC
- 16 byte AES-encrypted options block
- 1 byte protocol version (2)
- 3 bytes options (nothing now, all 0)
- 2 byte DH type (implies length of X)
0. Old ElG with leading zero (256 bytes) (unused in NTCP 2)
1. New ElG without leading zero (256 bytes)
2. ECDH? 25519?
- 2 byte block/stream cipher type
0. AES CBC
1. Salsa20? ChaCha?
- 4 byte timestamp (seconds since epoch, wrap around in 2038)
- 2 bytes unused, set to 0
- 2 byte padding count beyond X, to a minimum packet size of 289 bytes
- DH X (256 bytes or as implied by DH type)
- Random padding bytes as specified, to a minimum of 289 bytes.
No requirement for total message size to be a multiple of 16.
Options block is AES ECB encrypted with Bob's 32-byte router hash as the key.
This is the only portion of the message that is encrypted.
MAC: Standard 16-byte HMAC-MD5 (not the nonstandard one we use in SSU)
MAC covers only the options block.
MAC key is the first 16 bytes of Bob's router hash.
Encrypt-then-MAC.
To determine if incoming message is version 1 or version 2:
Method 1
Read 32 bytes.
If the MAC is good then assume it is version 2, otherwise it is version 1.
There's a tiny chance the MAC could be good but it's really version 1.
Method 2
Read 288 bytes.
If there is a 289th byte pending, assume it is version 2, otherwise it is version 1.
This method is vulnerable to MiTM segmentation at 288 bytes.
Timestamp is used for replay detection. Keep a cache of recent MACs for a time period,
reject duplicates, and reject timestamps beyond the cache lifetime or too far in future.
2) Session Created
------------------
The only change is adding a variable amount of padding at the end.
TODO: Replace this with the full spec
- Y type and length as specified in message 1
- The last 16 bytes of Y are used as the IV.
- Take the (former) first two padding bytes and make them the number
of padding bytes to follow, 0 - 65535
- Padding up to the first multiple of 16 (0-15 bytes) is required and encrypted.
- Padding after that is not encrypted, not used for next IV,
no requirement for total message size to be a multiple of 16.
- The last 16 encrypted bytes are used as the next IV in message 4
3) Session Confirm A
--------------------
The only change is adding a variable amount of padding at the end.
TODO: Replace this with the full spec
- The last 16 bytes of X from message 1 are used as the IV.
- Take the (former) first two padding bytes and make them the number
of padding bytes to follow after the sig, 0 - 65535
- Then pad with 0-15 bytes so that the message through the signature is a multiple of 16 bytes.
- Then the signature
- Padding after that is not encrypted, not used for next IV,
no requirement for total message size to be a multiple of 16.
- The last 16 encrypted bytes are used as the next IV in the first data transfer.
4) Session Confirm B
--------------------
The only change is adding a variable amount of padding at the end.
TODO: Replace this with the full spec
- The last 16 bytes of the encrypted contents of message 2 are used as the IV.
- Take the (former) first two padding bytes and make them the number
of padding bytes to follow, 0 - 65535
- Padding up to the first multiple of 16 (0-15 bytes) is required and encrypted.
- Padding after that is not encrypted, not used for next IV,
no requirement for total message size to be a multiple of 16.
- The last 16 encrypted bytes are used as the next IV in the first data transfer.
5) Data Packets
---------------
Add non-mod-16 padding after the checksum:
- Old:
- 2 byte data length
- Data
- Padding to multiple of 16 (including checksum)
- 4 byte checksum
- New:
- 2 byte data length
- Data
- 2 byte post-checksum padding count, 0-65535
- 0-15 bytes Padding to multiple of 16 (including checksum)
- 4 byte checksum
- Random Padding (unencrypted, not used in IV, not covered by checksum)
Alternatives
============
- Poly1305 instead of HMAC-MD5?
- Something else instead of AES for obfuscating the options block in message 1?
- ECDH or 25519 DH instead of ElG DH?
- Salsa20 (or derivatives) instead of AES?
When we add support for any new DH or block/stream cipher types,
we will have to bump the advertised version in the Router Address.

28
i2p2www/spec/proposals/111-leaseset-key-persistence.rst Normal file
View File

@ -0,0 +1,28 @@
========================
LeaseSet Key Persistence
========================
.. meta::
:author: zzz
:created: 2014-12-13
:thread: http://zzz.i2p/topics/1770
:lastupdated: 2014-12-13
:status: Draft
.. contents::
Introduction
============
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
after restart, and it also prevents possible correlation with a router restart.
There's two other things that are even easier to correlate with router restart:
the leaseset encryption and signing keys. These are not currently persisted.
Proposed Changes
================
TBD

28
i2p2www/spec/proposals/112-encrypted-streaming-flag.rst Normal file
View File

@ -0,0 +1,28 @@
==========================
'Encrypted' Streaming Flag
==========================
.. meta::
:author: orignal
:created: 2015-01-21
:thread: http://zzz.i2p/topics/1795
:lastupdated: 2015-01-21
:status: Draft
.. contents::
Introduction
============
High-loaded apps can encounter a shortage of ElGamal/AES+SessionTags tags.
Proposal
========
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
public key. That would allow to eliminated garlic (ElGamal/AES) encryption and
shortage of tags problem.
May be set per packet or per stream through SYN.

45
i2p2www/spec/proposals/113-batch-multiple-data-cloves-in-garlic.rst Normal file
View File

@ -0,0 +1,45 @@
====================================
Batch Multiple Data Cloves in Garlic
====================================
.. meta::
:author: orignal
:created: 2015-01-22
:thread: http://zzz.i2p/topics/1797
:lastupdated: 2015-01-22
:status: Draft
.. contents::
Introduction
============
Required Changes
================
The changes would be in OCMOSJ and related helper classes, and in
ClientMessagePool. As there is no queue now, a new queue and some delay would be
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
========
It is unclear whether this will have any useful effect, as streaming already
does batching and selects optimum MTU. Batching would increase message size and
exponential drop probability.
The exception is uncompressed content, gzipped at the I2CP layer. But HTTP
traffic is already compressed at higher layer, and Bittorrent data is usually
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.

60
i2p2www/spec/proposals/114-prefer-near-in-keyspace.rst Normal file
View File

@ -0,0 +1,60 @@
=================================
Prefer Nearby Routers in Keyspace
=================================
.. meta::
:author: chisquare
:created: 2015-04-25
:thread: http://zzz.i2p/topics/1874
:lastupdated: 2015-04-25
:status: Draft
.. contents::
Introduction
============
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.
Required Changes
================
This change would require:
1. Every router prefer connections near them in the keyspace.
2. Every router be aware that every router prefers connections near them in
the keyspace.
Advantages for Tunnel Building
==============================
If you build a tunnel::
A -long-> B -short-> C -short-> D
(long/random vs short hop in keyspace), you can guess where the tunnel build
probably failed and try a different peer at that point. In addition, it would
allow you to detect denser parts in key space and have routers just not use them
since it may be someone colluding.
If you build a tunnel::
A -long-> B -long-> C -short-> D
and it fails, you can infer that it was more likely failing at C -> D and you
can choose another D hop.
You can also build tunnels so that the OBEP is closer to the IBGW and use those
tunnels with OBEP that are closer to the given IBGW in a LeaseSet.
Security Implications
=====================
If you randomize the placement of short vs long hops in the keyspace, an
attacker probably won't get much of an advantage.
The biggest downside though is it may make user enumeration a bit easier.

31
i2p2www/spec/proposals/115-opt-in-statistics-collection.rst Normal file
View File

@ -0,0 +1,31 @@
============================
Opt-in Statistics Collection
============================
.. meta::
:author: zab
:created: 2015-11-04
:thread: http://zzz.i2p/topics/1981
:lastupdated: 2015-11-04
:status: Draft
.. contents::
Introduction
============
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
the overall performance of the network in terms of speed, reliability and so on.
However, changing them without proper research is very risky.
Proposal
========
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
collects those stats in a centralized place. Naturally, this would be opt-in as
it pretty much destroys anonymity. (The privacy-friendly stats are already
reported to stats.i2p) As a ballpark figure, for a network of size 30,000 a
sample of 300 reporting routers should be representative enough.

458
i2p2www/spec/proposals/116-i2pcontrol-api-2.rst Normal file
View File

@ -0,0 +1,458 @@
================
I2PControl API 2
================
.. meta::
:author: hottuna
:created: 2016-01-23
:thread: http://zzz.i2p/topics/2030
:lastupdated: 2016-02-01
:status: Draft
.. contents::
Introduction
============
This page will outline the API2 for i2pcontrol
Developer headsup!
------------------
All RPC paramters will now be lower case. This *will* break backwards
compatibility with API1 implementations. The reasons for this is to provide
users of >=API2 with simplest most coherent possible API.
API 2
=====
.. raw:: html
{% highlight lang='json' -%}
{
"id": "id",
"method": "method_name",
"params": {
"token": "auth_token",
"method_param": "method_parameter_value",
},
"jsonrpc": "2.0"
}
{
"id": "id",
"result": "result_value",
"jsonrpc": "2.0"
}
{% endhighlight %}
Parameters
----------
"id"
The id number or the request.
Used to identify which reply was spawn by which request.
"method_name"
The name of the RPC that is being invoked.
"auth_token"
The session authentication token.
Needs to be supplied with every RPC except for the 'authenticate' call.
"method_parameter_value"
The method parameter.
Used to offer a different flavors of a method. Like 'get', 'set' and flavors
like that.
"result_value"
The value that the RPC returns. Its type and contents depends on the method
and which method.
Prefixes
--------
The RPC naming scheme is similar to how it's done in CSS, with vendor prefixes
for the different API implementations (i2p, kovri, i2pd)::
XXX.YYY.ZZZ
i2p.XXX.YYY.ZZZ
i2pd.XXX.YYY.ZZZ
kovri.XXX.YYY.ZZZ
The overall idea with vendor-specific prefixes is to allow for some wiggle room
and let implementations innovate without having to wait for every other
implementation to catch up. If a RPC is implemented by all implementations its
multiple prefixes can be removed and it can be included as a core RPC in the
next API version.
Method reading guide
--------------------
* **rpc.method**
* *parameter* [type of parameter]: [null], [number], [string], [boolean],
[array] or [object]. [object] being a {key:value} map.
::
"return_value" [string] // This is the value returned by the RPC call
Methods
-------
* **authenticate** - Given that a correct password is provided, this method provides you with a token for further access and a list of supported API levels.
* *password* [string]: The password for this i2pcontrol implementation
::
[object]
{
"token" : [string], // The token to be used be supplied with all other RPC methods
"api" : [[int],[int], ...] // A list of supported API levels.
}
* **control.** - Control i2p
* **control.reseed** - Start reseeding
* [nil]: No parameter needed
::
[nil]
* **control.restart** - Restart i2p instance
* [nil]: No parameter needed
::
[nil]
* **control.restart.graceful** - Restart i2p instance gracefully
* [nil]: No parameter needed
::
[nil]
* **control.shutdown** - Shut down i2p instance
* [nil]: No parameter needed
::
[nil]
* **control.shutdown.graceful** - Shut down i2p instance gracefully
* [nil]: No parameter needed
::
[nil]
* **control.update.find** - **BLOCKING** Search for signed updates
* [nil]: No parameter needed
::
true [boolean] // True iff signed update is available
* **control.update.start** - Start update process
* [nil]: No parameter needed
::
[nil]
* **i2pcontrol.** - Configure i2pcontrol
* **i2pcontrol.address** - Get/Set the ip address that i2pcontrol listens to.
* *get* [null]: This parameter does not need to be set.
::
"0.0.0.0" [string]
* *set* [string]: This will be an ip address like "0.0.0.0" or "192.168.0.1"
::
[nil]
* **i2pcontrol.password** - Change the i2pcontrol password.
* *set* [string]: Set the new password to this string
::
[nil]
* **i2pcontrol.port** - Get/Set the port that i2pcontrol listens to.
* *get* [null]: This parameter does not need to be set.
::
7650 [number]
* *set* [number]: Change the port that i2pcontrol listens to to this port
::
[nil]
* **settings.** - Get/Set i2p instance settings
* **settings.advanced** - Advanced settings
* *get* [string]: Get the value of this setting
::
"setting-value" [string]
* *getAll* [null]:
::
[object]
{
"setting-name" : "setting-value", [string]
".." : ".."
}
* *set* [string]: Set the value of this setting
* *setAll* [object] {"setting-name" : "setting-value", ".." : ".." }
::
[nil]
* **settings.bandwidth.in** - Inbound bandwidth settings
* **settings.bandwidth.out** - Outbound bandwidth settings
* *get* [nil]: This parameter does not need to be set.
::
0 [number]
* *set* [number]: Set the bandwidth limit
::
[nil]
* **settings.ntcp.autoip** - Get IP auto detection setting for NTCP
* *get* [null]: This parameter does not need to be set.
::
true [boolean]
* **settings.ntcp.hostname** - Get NTCP hostname
* *get* [null]: This parameter does not need to be set.
::
"0.0.0.0" [string]
* *set* [string]: Set new hostname
::
[nil]
* **settings.ntcp.port** - NTCP port
* *get* [null]: This parameter does not need to be set.
::
0 [number]
* *set* [number]: Set new NTCP port.
::
[nil]
* *set* [boolean]: Set NTCP IP auto detection
::
[nil]
* **settings.ssu.autoip** - Configure IP auto detection setting for SSU
* *get* [nil]: This parameter does not need to be set.
::
true [boolean]
* **settings.ssu.hostname** - Configure SSU hostname
* *get* [null]: This parameter does not need to be set.
::
"0.0.0.0" [string]
* *set* [string]: Set new SSU hostname
::
[nil]
* **settings.ssu.port** - SSU port
* *get* [null]: This parameter does not need to be set.
::
0 [number]
* *set* [number]: Set new SSU port.
::
[nil]
* *set* [boolean]: Set SSU IP auto detection
::
[nil]
* **settings.share** - Get bandwidth share percentage
* *get* [null]: This parameter does not need to be set.
::
0 [number] // Bandwidth share percentage (0-100)
* *set* [number]: Set bandwidth share percentage (0-100)
* **settings.upnp** - Enable or disable UPNP
* *get* [nil]: This parameter does not need to be set.
::
true [boolean]
* *set* [boolean]: Set SSU IP auto detection
::
[nil]
* **stats.** - Get stats from the i2p instance
* **stats.advanced** - This method provides access to all stats kept within the instance.
* *get* [string]: Name of the advanced stat to be provided
* *Optional:* *period* [number]: The period for the requested stat
* **stats.knownpeers** - Returns the number of known peers
* **stats.uptime** - Returns the time in ms since the router started
* **stats.bandwidth.in** - Returns the inbound bandwidth (ideally for the last second)
* **stats.bandwidth.in.total** - Returns the number of bytes received since last restart
* **stats.bandwidth.out** - Returns the outbound bandwidth (ideally for the last second)'
* **stats.bandwidth.out.total** - Returns the number of bytes sent since last restart'
* **stats.tunnels.participating** - Returns the number of tunnels participated in currently
* **stats.netdb.peers.active** - Returns the number of peers we've recently communicated with
* **stats.netdb.peers.fast** - Returns the number of 'fast' peers
* **stats.netdb.peers.highcapacity** - Returns the number of 'high capacity' peers
* **stats.netdb.peers.known** - Returns the number of known peers
* *get* [null]: This parameter does not need to be set.
::
0.0 [number]
* **status.** - Get i2p instance status
* **status.router** - Get router status
* *get* [null]: This parameter does not need to be set.
::
"status" [string]
* **status.net** - Get router network status
* *get* [null]: This parameter does not need to be set.
::
0 [number]
/**
* 0 – OK
* 1 – TESTING
* 2 – FIREWALLED
* 3 – HIDDEN
* 4 – WARN_FIREWALLED_AND_FAST
* 5 – WARN_FIREWALLED_AND_FLOODFILL
* 6 – WARN_FIREWALLED_WITH_INBOUND_TCP
* 7 – WARN_FIREWALLED_WITH_UDP_DISABLED
* 8 – ERROR_I2CP
* 9 – ERROR_CLOCK_SKEW
* 10 – ERROR_PRIVATE_TCP_ADDRESS
* 11 – ERROR_SYMMETRIC_NAT
* 12 – ERROR_UDP_PORT_IN_USE
* 13 – ERROR_NO_ACTIVE_PEERS_CHECK_CONNECTION_AND_FIREWALL
* 14 – ERROR_UDP_DISABLED_AND_TCP_UNSET
*/
* **status.isfloodfill** - Is the i2p instance currently a floodfill
* *get* [null]: This parameter does not need to be set.
::
true [boolean]
* **status.isreseeding** - Is the i2p instance currently reseeding
* *get* [null]: This parameter does not need to be set.
::
true [boolean]
* **status.ip** - Public IP detected of this i2p instance
* *get* [null]: This parameter does not need to be set.
::
"0.0.0.0" [string]

2
runserver.py
View File

@ -2,4 +2,4 @@
from i2p2www import app
if __name__ == '__main__':
app.run(host='127.0.0.1', port=5000, debug=False)
app.run(host='127.0.0.1', port=5000, debug=True)