I2CP updates for 0.9.43 (from proposal 123)

This commit is contained in:
zzz
2019-09-13 10:05:56 +00:00
parent 55561cbffa
commit 0e0b4a587b
2 changed files with 123 additions and 10 deletions

View File

@ -3,8 +3,8 @@ I2CP Specification
==================
.. meta::
:category: Protocols
:lastupdated: June 2019
:accuratefor: 0.9.41
:lastupdated: September 2019
:accuratefor: 0.9.43
.. contents::
@ -235,6 +235,9 @@ below.
============== ======================
Version Required I2CP Features
============== ======================
0.9.43 BlindingInfo message supported
Additional HostReply message failure codes
0.9.41 EncryptedLeaseSet options
0.9.39 CreateLeaseSet2 message supported
@ -432,6 +435,7 @@ Message Types
Message Direction Type Since
=============================== ========= ==== =====
BandwidthLimitsMessage_ R -> C 23 0.7.2
BlindingInfoMessage_ C -> R 42 0.9.43
CreateLeaseSetMessage_ C -> R 4
CreateLeaseSet2Message_ C -> R 41 0.9.39
CreateSessionMessage_ C -> R 1
@ -485,6 +489,88 @@ Currently, the client limits are the only values set, and are actually the
router limits. All the values labeled as router limits are always 0. As of
release 0.7.2.
.. _msg-BlindingInfo:
BlindingInfoMessage
----------------------
Description
```````````
Advise the router that a Destination is blinded, with optional
lookup password and optional private key for decryption.
See proposals 123 and 149 for details.
The router needs to know if a destination is blinded.
If it is blinded and uses a secret or per-client authentication,
it needs to have that information as well.
A Host Lookup of a new-format b32 address ("b33")
tells the router that the address is blinded, but there's no mechanism to
pass the secret or private key to the router in the Host Lookup message.
While we could extend the Host Lookup message to add that information,
it's cleaner to define a new message.
This message provides a programmatic way for the client to tell the router.
Otherwise, the user would have to manually configure each destination.
Usage
`````
Before a client sends a message to a blinded destination, it must either
lookup the "b33" in a Host Lookup message, or send a Blinding Info message.
If the blinded destination requires a secret or per-client authentication,
the client must send a Blinding Info message.
The router does not send a reply to this message.
Sent from Client to Router.
Contents
````````
1. `Session ID`_
2. 1 byte [Integer]_ Flags
Bit order: 76543210
Bit 0: 0 for everybody, 1 for per-client
Bits 3-1: Authentication scheme, if bit 0 is set to 1 for per-client, otherwise 000
000: DH client authentication (or no per-client authentication)
001: PSK client authentication
Bit 4: 1 if secret required, 0 if no secret required
Bits 7-5: Unused, set to 0 for future compatibility
3. 1 byte [Integer]_ Endpoint type
Type 0 is a [Hash]_
Type 1 is a hostname [String]_
Type 2 is a [Destination]_
Type 3 is a Sig Type and [SigningPublicKey]_
4. 2 byte [Integer]_ Blinded Signature Type
5. 4 byte [Integer]_ Expiration
Seconds since epoch
6. Endpoint: Data as specified, one of
Type 0: 32 byte [Hash]_
Type 1: host name [String]_
Type 2: binary [Destination]_
Type 3: 2 byte [Integer]_ signature type
[SigningPublicKey]_ (length as implied by sig type)
7. [PrivateKey]_ Decryption key
Only present if flag bit 0 is set to 1
A 32-byte ECIES_X25519 private key
8. [String]_ Lookup Password
Only present if flag bit 4 is set to 1
Notes
`````
* As of release 0.9.43.
* The Hash endpoint type is probably not useful unless the router can do a reverse lookup in
the address book to get the Destination.
* The hostname endpoint type is probably not useful unless the router can do a lookup in
the address book to get the Destination.
.. _msg-CreateLeaseSet:
CreateLeaseSetMessage
@ -802,6 +888,12 @@ Contents
1. `Session ID`_
2. 4 byte [Integer]_ request ID
3. 1 byte [Integer]_ result code
0: Success
1: Failure
2: Lookup password required (as of 0.9.43)
3: Private key required (as of 0.9.43)
4: Lookup password and private key required (as of 0.9.43)
5: Leaseset decryption failure (as of 0.9.43)
4. [Destination]_, only present if result code is zero.
Notes
@ -810,8 +902,11 @@ Notes
* The session ID and request ID are those from the HostLookupMessage_.
* The result code is 0 for success, 1-255 for failure. Only 1 is used for
failure now, more specific failure codes may be defined in the future.
* The result code is 0 for success, 1-255 for failure.
1 indicates a generic failure.
As of 0.9.43, the additional failure codes 2-5 were defined
to support extended errors for "b33" lookups.
See proposals 123 and 149 for additional information.
.. _msg-MessagePayload:

View File

@ -5,7 +5,7 @@ New netDB Entries
:author: zzz, str4d, orignal
:created: 2016-01-16
:thread: http://zzz.i2p/topics/2051
:lastupdated: 2019-09-06
:lastupdated: 2019-09-13
:status: Open
:supercedes: 110, 120, 121, 122
@ -1894,12 +1894,30 @@ Format
Notes
`````
- Minimum router version is 0.9.42
- Minimum router version is 0.9.43
Issues
``````
Host Reply Message (enc)
------------------------
To support lookups of "b33" hostnames and return an indication
if the router does not have the required information, we define
additional result codes for the Host Reply Message, as follows:
::
2: Lookup password required
3: Private key required
4: Lookup password and private key required
5: Leaseset decryption failure
Values 1-255 are already defined as errors, so there is no
backwards-compatibility issue.
Host Lookup Message
@ -1929,12 +1947,12 @@ Changes
Notes
`````
- Minimum router and client version is 0.9.42 for request type 3.
- Minimum router and client version is TBD for request type 3.
Host Reply Message
------------------
Host Reply Message (meta)
-------------------------
Router to client.
@ -2002,7 +2020,7 @@ Changes
Notes
`````
- Minimum router and client version is 0.9.42 for the extended results.
- Minimum router and client version is TBD for the extended results.