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

proposal 111 (NTCP2) minor update

Browse Source
This commit is contained in:
zzz
2016-07-03 18:42:21 +00:00
parent 339068929b
commit 0fb9e20200
1 changed files with 26 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -5,7 +5,7 @@ NTCP 2
:author: zzz :author: zzz
: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: 2016-07-03
:status: Open :status: Open
:supercedes: 106 :supercedes: 106
@@ -35,18 +35,38 @@ a lot harder.
Design 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,
and published as a single "transport" (i.e. Router Address) in the netdb
- Publish support for version 1 only, 2 only, or 1+2 in the netdb
in a separate field, and default to version 1 only
(don't bind version support to a particular router version)
- Ensure that all implementations (java/i2pd/kovri/go) can add version 2 support
(or not) on their own schedules
- Add random padding to all NTCP messages including handshake and data messages - 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) (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 - 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 so that DPI boxes and AV signatures can't easily classify them.
Also ensure that the messages going to
a single peer or set of peers do not have a similar pattern of bits 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) - Fix loss of bits in DH due to Java format (ticket #1112)
- Add "probing resistance" (as Tor calls it), this includes replay resistance - Add "probing resistance" (as Tor calls it), this includes replay resistance
- Maintain 2-way authenticated key exchange (2W-AKE).
1W-AKE is not sufficient for our application.
- Add options/version in handshake for future extensibility - Add options/version in handshake for future extensibility
- Add resistance to malicious MitM segmentation if possible - Add resistance to malicious MitM TCP segmentation if possible
- Don't add significantly to CPU required for connection setup - Don't add significantly to CPU required for connection setup
- Minimize changes - Minimize changes.
- Support both versions in a common set of code.
Non-Goals
=========
- Bullet-proof DPI resistance... that would be pluggable transports, proposal #109
- A TLS-based transport... that would be proposal #104
- Don't change the symmetric stream crypto, continue to use AES-CBC-256
(but do add flags in the handshake so we can change later)
@@ -209,7 +229,7 @@ Alternatives
- Poly1305 instead of HMAC-MD5? - Poly1305 instead of HMAC-MD5?
- Something else instead of AES for obfuscating the options block in message 1? - Something else instead of AES for obfuscating the options block in message 1?
- ECDH or 25519 DH instead of ElG DH? - ECDH or 25519 ECDH instead of ElG DH? Note that "25519 ECDH" is now called "X25519"
- Salsa20 (or derivatives) instead of AES? - Salsa20 (or derivatives) instead of AES?
When we add support for any new DH or block/stream cipher types, When we add support for any new DH or block/stream cipher types,