2017-10-27 17:22:10 +00:00
|
|
|
LLARP v0
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2017-10-27 17:22:10 +00:00
|
|
|
LLARP (Low Latency Anon Routing Protocol) is a protocol for anonymizing senders and
|
2018-11-09 00:06:58 +00:00
|
|
|
recipiants of encrypted messages sent over the internet without a centralised
|
2017-09-22 21:06:48 +00:00
|
|
|
trusted party.
|
|
|
|
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
|
|
document are to be interpreted as described in RFC 2119 [RFC2119].
|
|
|
|
|
|
|
|
basic structures:
|
|
|
|
|
|
|
|
all structures are key, value dictionaries encoded with bittorrent encoding
|
2017-10-27 17:22:10 +00:00
|
|
|
notation:
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2017-10-27 17:22:10 +00:00
|
|
|
a + b is a concatanated with b
|
2017-09-22 21:06:48 +00:00
|
|
|
|
|
|
|
a ^ b is a bitwise XOR b
|
|
|
|
|
|
|
|
x[a:b] is a memory slice of x from index a to b
|
|
|
|
|
|
|
|
BE(x) is bittorrent encode x
|
|
|
|
|
|
|
|
BD(x) is bittorrent decode x
|
|
|
|
|
|
|
|
{ a: b, y: z } is a dictionary with two keys a and y
|
|
|
|
who's values are b and z respectively
|
|
|
|
|
|
|
|
[ a, b, c ... ] is a list containing a b c and more items in that order
|
|
|
|
|
|
|
|
"<description>" is a bytestring who's contents and length is described by the
|
|
|
|
quoted value <description>
|
|
|
|
|
|
|
|
"<value>" * N is a bytestring containing the <value> concatenated N times.
|
|
|
|
|
2017-10-27 17:22:10 +00:00
|
|
|
cryptography:
|
|
|
|
|
2018-04-30 11:26:01 +00:00
|
|
|
see crypto_v0.txt
|
2017-10-27 17:22:10 +00:00
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
---
|
|
|
|
|
2018-02-16 12:25:35 +00:00
|
|
|
wire protocol
|
|
|
|
|
|
|
|
see iwp-v0.txt
|
2017-09-22 21:06:48 +00:00
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
datastructures:
|
|
|
|
|
|
|
|
all datastructures are assumed version 0 if they lack a v value
|
|
|
|
otherwise version is provided by the v value
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
all ip addresses can be ipv4 via hybrid dual stack ipv4 mapped ipv6 addresses,
|
|
|
|
i.e ::ffff.8.8.8.8. The underlying implementation MAY implement ipv4 as native
|
|
|
|
ipv4 instead of using a hybrid dual stack.
|
|
|
|
|
2018-02-15 16:32:11 +00:00
|
|
|
net address:
|
|
|
|
|
|
|
|
net addresses are a variable length byte string, if between 7 and 15 bytes it's
|
|
|
|
treated as a dot notation ipv4 address (xxx.xxx.xxx.xxx)
|
|
|
|
if it's exactly 16 bytes it's treated as a big endian encoding ipv6 address.
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
address info (AI)
|
|
|
|
|
2018-02-15 16:32:11 +00:00
|
|
|
An address info (AI) defines a publically reachable endpoint
|
2017-10-27 17:22:10 +00:00
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
{
|
|
|
|
c: transport_rank_uint16,
|
|
|
|
d: "<transport dialect name>",
|
2018-02-16 12:30:41 +00:00
|
|
|
e: "<32 bytes public encryption key>",
|
2018-02-15 16:32:11 +00:00
|
|
|
i: "<net address>",
|
2018-01-25 16:32:45 +00:00
|
|
|
p: port_uint16,
|
|
|
|
v: 0
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-02-16 12:25:35 +00:00
|
|
|
example iwp address info:
|
2018-02-15 16:32:11 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
c: 1,
|
2018-02-16 12:25:35 +00:00
|
|
|
d: "iwp",
|
2018-02-16 12:30:41 +00:00
|
|
|
e: "<32 bytes of 0x61>",
|
2018-02-15 16:32:11 +00:00
|
|
|
i: "123.123.123.123",
|
|
|
|
p: 1234,
|
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
2018-02-16 12:30:41 +00:00
|
|
|
bencoded form:
|
|
|
|
|
2018-02-22 16:48:31 +00:00
|
|
|
d1:ci1e1:d3:iwp1:e32:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1:d3:iwp1:i15:123.123.123.1231:pi1234e1:vi0ee
|
2018-02-15 16:32:11 +00:00
|
|
|
|
2018-10-04 13:03:59 +00:00
|
|
|
Traffic Policy (TP)
|
|
|
|
|
|
|
|
Traffic policy (TP) defines port, protocol and QoS/drop policy.
|
|
|
|
|
|
|
|
{
|
|
|
|
a: protocol_integer,
|
|
|
|
b: port_integeger,
|
|
|
|
d: drop_optional_integer,
|
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
|
|
|
drop d is set to 1 to indicate that packets of protocol a with source port b will be dropped.
|
|
|
|
if d is 0 or not provided this traffic policy does nothing.
|
|
|
|
|
2017-09-28 17:02:05 +00:00
|
|
|
Exit Info (XI)
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
An exit info (XI) defines a exit address that can relay exit traffic to the
|
|
|
|
internet.
|
|
|
|
|
2017-09-28 17:02:05 +00:00
|
|
|
{
|
2018-04-04 16:10:27 +00:00
|
|
|
a: "<net address exit address>",
|
|
|
|
b: "<net address exit netmask>",
|
2018-01-29 20:02:23 +00:00
|
|
|
k: "<32 bytes public encryption/signing key>",
|
2018-10-04 13:03:59 +00:00
|
|
|
p: [ list, of, traffic, policies],
|
2018-01-25 16:32:45 +00:00
|
|
|
v: 0
|
2017-09-28 17:02:05 +00:00
|
|
|
}
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
|
|
|
|
Exit Route (XR)
|
|
|
|
|
|
|
|
An exit route (XR) define an allocated exit address and any additional
|
|
|
|
information required to access the internet via that exit address.
|
|
|
|
|
|
|
|
{
|
|
|
|
a: "<16 bytes big endian ipv6 gateway address>",
|
|
|
|
b: "<16 bytes big endian ipv6 netmask>",
|
|
|
|
c: "<16 bytes big endian ipv6 source address>",
|
2018-10-27 12:46:59 +00:00
|
|
|
l: lifetime_in_milliseconds_uint64,
|
2018-01-30 13:38:29 +00:00
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
router contact (RC)
|
|
|
|
|
2018-04-06 15:48:28 +00:00
|
|
|
router's full identity
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
{
|
|
|
|
a: [ one, or, many, AI, here ... ],
|
2018-05-28 20:51:15 +00:00
|
|
|
k: "<32 bytes public long term identity signing key>",
|
2018-08-02 00:48:43 +00:00
|
|
|
n: "<optional max 32 bytes router nickname>",
|
2018-05-28 20:51:15 +00:00
|
|
|
p: "<32 bytes public path encryption key>",
|
2018-10-16 17:09:40 +00:00
|
|
|
u: next_update_needed_milliseconds_since_epoch_uint64,
|
2018-01-19 16:51:27 +00:00
|
|
|
v: 0,
|
2018-01-26 14:17:51 +00:00
|
|
|
x: [ Exit, Infos ],
|
2018-01-19 16:51:27 +00:00
|
|
|
z: "<64 bytes signature using identity key>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
service info (SI)
|
|
|
|
|
2018-04-06 15:48:28 +00:00
|
|
|
public information blob for a hidden service
|
|
|
|
|
2018-06-08 00:11:25 +00:00
|
|
|
e is the long term public encryption key
|
2018-04-06 15:48:28 +00:00
|
|
|
s is the long term public signing key
|
|
|
|
v is the protocol version
|
|
|
|
x is a nounce value for generating vanity addresses that can be omitted
|
|
|
|
|
2018-06-23 00:00:44 +00:00
|
|
|
if x is included it MUST be equal to 16 bytes
|
2018-04-06 15:48:28 +00:00
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
{
|
2018-06-08 00:11:25 +00:00
|
|
|
e: "<32 bytes public encryption key>",
|
2017-09-22 21:06:48 +00:00
|
|
|
s: "<32 bytes public signing key>",
|
2018-01-19 16:51:27 +00:00
|
|
|
v: 0,
|
2018-06-23 00:00:44 +00:00
|
|
|
x: "<optional 16 bytes nonce for vanity>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
service address (SA)
|
|
|
|
|
2018-04-06 15:48:28 +00:00
|
|
|
the "network address" of a hidden service, which is computed as the blake2b
|
|
|
|
256 bit hash of the public infomration blob.
|
|
|
|
|
|
|
|
HS(BE(SI))
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-07-06 16:08:30 +00:00
|
|
|
when in string form it's encoded with z-base32 and uses the .loki tld
|
|
|
|
|
2018-06-29 14:25:09 +00:00
|
|
|
introduction (I)
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-04-06 15:48:28 +00:00
|
|
|
a descriptor annoucing a path to a hidden service
|
|
|
|
|
2018-06-08 00:11:25 +00:00
|
|
|
k is the rc.k value of the router to contact
|
2018-04-06 15:48:28 +00:00
|
|
|
p is the path id on the router that is owned by the service
|
|
|
|
v is the protocol version
|
2018-10-27 12:46:59 +00:00
|
|
|
x is the timestamp milliseconds since epoch that this introduction expires at
|
2018-04-06 15:48:28 +00:00
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
{
|
2018-06-08 00:11:25 +00:00
|
|
|
k: "<32 bytes public identity key of router>",
|
2018-07-09 14:24:44 +00:00
|
|
|
l: advertised_path_latency_ms_uint64, (optional)
|
2018-06-12 12:49:23 +00:00
|
|
|
p: "<16 bytes path id>",
|
2018-01-19 16:51:27 +00:00
|
|
|
v: 0,
|
2018-10-27 12:46:59 +00:00
|
|
|
x: time_expires_milliseconds_since_epoch_uint64
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-06-29 14:25:09 +00:00
|
|
|
introduction set (IS)
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-06-29 14:25:09 +00:00
|
|
|
a signed set of introductions for a hidden service
|
2018-08-13 23:22:31 +00:00
|
|
|
a is the service info of the publisher
|
2018-06-29 14:25:09 +00:00
|
|
|
i is the list of introductions that this service is advertising with
|
2018-08-13 23:22:31 +00:00
|
|
|
k is the public key to use when doing encryption to this hidden service
|
2018-07-17 06:41:52 +00:00
|
|
|
n is a 16 byte null padded utf-8 encoded string tagging the hidden service in
|
2018-07-17 07:30:03 +00:00
|
|
|
a topic searchable via a lookup (optional)
|
2018-04-06 15:48:28 +00:00
|
|
|
v is the protocol version
|
2018-06-29 14:25:09 +00:00
|
|
|
w is an optinal proof of work for DoS protection (slot for future)
|
2018-04-06 15:48:28 +00:00
|
|
|
z is the signature of the entire IS where z is set to zero signed by the hidden
|
|
|
|
service's signing key.
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
{
|
2018-04-06 15:48:28 +00:00
|
|
|
a: SI,
|
2018-01-08 13:49:05 +00:00
|
|
|
i: [ I, I, I, ... ],
|
2018-08-13 23:22:31 +00:00
|
|
|
k: "<1218 bytes sntrup4591761 public key block>",
|
2018-09-23 13:57:21 +00:00
|
|
|
n: "<16 bytes service topic (optional)>",
|
|
|
|
t: timestamp_uint64_milliseconds_since_epoch_published_at,
|
2018-01-19 16:51:27 +00:00
|
|
|
v: 0,
|
2018-06-29 14:25:09 +00:00
|
|
|
w: optional proof of work,
|
2017-09-22 21:06:48 +00:00
|
|
|
z: "<64 bytes signature using service info signing key>"
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-01-25 17:54:16 +00:00
|
|
|
---
|
|
|
|
|
|
|
|
Encrypted frames:
|
|
|
|
|
2018-02-22 20:04:42 +00:00
|
|
|
|
2018-01-25 17:54:16 +00:00
|
|
|
Encrypted frames are encrypted containers for link message records like LRCR.
|
|
|
|
|
|
|
|
32 bytes hmac, h
|
|
|
|
32 bytes nounce, n
|
|
|
|
32 bytes ephmeral sender's public encryption key, k
|
|
|
|
remaining bytes ciphertext, x
|
|
|
|
|
|
|
|
decryption:
|
|
|
|
|
|
|
|
0) verify hmac
|
|
|
|
|
|
|
|
S = PKE(n, k, our_RC.K)
|
|
|
|
verify h == MDS(n + k + x, S)
|
|
|
|
|
|
|
|
If the hmac verification fails the entire parent message is discarded
|
|
|
|
|
|
|
|
1) decrypt and decode
|
|
|
|
|
|
|
|
new_x = SD(S, n[0:24], x)
|
|
|
|
msg = BD(new_x)
|
|
|
|
|
|
|
|
If the decoding fails the entire parent message is discarded
|
|
|
|
|
|
|
|
encryption:
|
|
|
|
|
|
|
|
to encrypt a frame to a router with public key B.k
|
|
|
|
|
|
|
|
0) prepare nounce n, ephemeral keypair (A.k, s) and derive shared secret S
|
|
|
|
|
|
|
|
A.k, s = ECKG()
|
|
|
|
n = RAND(32)
|
2018-06-12 16:45:12 +00:00
|
|
|
S = PKE(p, A.k, B.k, n)
|
2018-01-25 17:54:16 +00:00
|
|
|
|
|
|
|
1) encode and encrypt
|
|
|
|
|
|
|
|
x = BE(msg)
|
|
|
|
new_x = SE(S, n[0:24], x)
|
|
|
|
|
2018-06-12 16:45:12 +00:00
|
|
|
2) generate message authentication
|
2018-01-25 17:54:16 +00:00
|
|
|
|
2018-02-16 12:24:25 +00:00
|
|
|
h = MDS(n + A.k + new_x, S)
|
2018-01-25 17:54:16 +00:00
|
|
|
|
|
|
|
resulting frame is h + n + A.k + new_x
|
|
|
|
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
---
|
|
|
|
|
|
|
|
link layer messages:
|
|
|
|
|
|
|
|
the link layer is responsible for anonymising the source and destination of
|
|
|
|
routing layer messages.
|
|
|
|
|
|
|
|
any link layer message without a key v is assumed to be version 0 otherwise
|
|
|
|
indicates the protocol version in use.
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
link introduce message (LIM)
|
|
|
|
|
|
|
|
This message MUST be the first link message sent before any others. This message
|
|
|
|
identifies the sender as having the RC contained in r. The recipiant MUST
|
|
|
|
validate the RC's signature and ensure that the public key in use is listed in
|
|
|
|
the RC.a matching the ipv6 address it originated from.
|
|
|
|
|
|
|
|
{
|
|
|
|
a: "i",
|
2018-09-08 15:53:20 +00:00
|
|
|
n: "<32 bytes nonce for key exhcange>",
|
|
|
|
p: uint64_milliseconds_session_period,
|
2018-01-30 13:38:29 +00:00
|
|
|
r: RC,
|
2018-09-08 15:53:20 +00:00
|
|
|
v: 0,
|
|
|
|
z: "<64 bytes signature of entire message by r.k>"
|
2018-01-30 13:38:29 +00:00
|
|
|
}
|
|
|
|
|
2018-09-08 15:53:20 +00:00
|
|
|
the link session will be kept open for p milliseconds after which
|
|
|
|
the session MUST be renegotiated.
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
link relay commit message (LRCM)
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
request a commit to relay traffic to another node.
|
2017-09-22 21:06:48 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
a: "c",
|
2018-06-08 00:11:25 +00:00
|
|
|
c: [ list, of, encrypted, frames ],
|
2018-02-22 20:11:06 +00:00
|
|
|
v: 0
|
2017-10-27 17:22:10 +00:00
|
|
|
}
|
|
|
|
|
2018-06-08 00:11:25 +00:00
|
|
|
c and r MUST contain dummy records if the hop length is less than the maximum
|
|
|
|
hop length.
|
|
|
|
|
2018-01-25 17:54:16 +00:00
|
|
|
link relay commit record (LRCR)
|
2017-10-27 17:22:10 +00:00
|
|
|
|
2018-06-28 15:10:25 +00:00
|
|
|
record requesting relaying messages for 600 seconds to router
|
2018-02-22 20:11:06 +00:00
|
|
|
on network who's i is equal to RC.k and decrypt data any messages using
|
2018-01-19 16:51:27 +00:00
|
|
|
PKE(n, rc.K, c) as symettric key for encryption and decryption.
|
2017-10-27 17:22:10 +00:00
|
|
|
|
2018-06-28 15:10:25 +00:00
|
|
|
if l is provided and is less than 600 and greater than 10 then that lifespan
|
|
|
|
is used (in seconds) instead of 600 seconds.
|
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
if w is provided and fits the required proof of work then the lifetime of
|
|
|
|
the path is extended by w.y seconds
|
2018-06-08 00:11:25 +00:00
|
|
|
|
2017-10-27 17:22:10 +00:00
|
|
|
{
|
2018-06-08 00:11:25 +00:00
|
|
|
c: "<32 byte public encryption key used for upstream>",
|
2018-01-08 13:49:05 +00:00
|
|
|
i: "<32 byte RC.k of next hop>",
|
2018-06-28 15:10:25 +00:00
|
|
|
l: uint_optional_lifespan,
|
2018-01-08 13:49:05 +00:00
|
|
|
n: "<32 bytes nounce for key exchange>",
|
2018-06-22 00:25:30 +00:00
|
|
|
r: "<16 bytes rx path id>",
|
|
|
|
t: "<16 bytes tx path id>",
|
2018-06-08 00:11:25 +00:00
|
|
|
v: 0,
|
2018-06-17 14:49:42 +00:00
|
|
|
w: proof of work
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
w if provided is a dict with the following struct
|
2018-06-08 00:11:25 +00:00
|
|
|
|
|
|
|
{
|
2018-06-28 15:10:25 +00:00
|
|
|
t: time_created_seconds_since_epoch,
|
2018-06-17 14:49:42 +00:00
|
|
|
v: 0,
|
|
|
|
y: uint32_seconds_extended_lifetime,
|
|
|
|
z: "<32 bytes nonce>"
|
2018-06-08 00:11:25 +00:00
|
|
|
}
|
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
the validity of the proof of work is that given
|
2017-10-27 17:22:10 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
h = HS(BE(w))
|
|
|
|
|
2018-06-29 12:15:15 +00:00
|
|
|
h has log_e(y) prefixed bytes being 0x00
|
2018-06-08 00:11:25 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
this proof of work requirement is subject to change
|
2018-06-08 00:11:25 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
if i is equal to RC.k then any LRDM.x values are decrypted and interpreted as
|
|
|
|
routing layer messages. This indicates that we are the farthest hop in the path.
|
2017-10-27 17:22:10 +00:00
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
link relay upstream message (LRUM)
|
|
|
|
|
|
|
|
sent to relay data via upstream direction of a previously created path.
|
|
|
|
|
|
|
|
{
|
|
|
|
a: "u",
|
2018-06-17 14:49:42 +00:00
|
|
|
p: "<16 bytes path id>",
|
2018-01-19 16:51:27 +00:00
|
|
|
v: 0,
|
2018-06-11 14:52:29 +00:00
|
|
|
x: "<N bytes encrypted x1 value>",
|
2018-06-17 14:49:42 +00:00
|
|
|
y: "<32 bytes nonce>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
x1 = SD(k, y, x)
|
2018-06-11 14:52:29 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
if we are the farthest hop, process x1 as a routing message
|
|
|
|
otherwise transmit a LRUM to the next hop
|
2017-09-22 21:06:48 +00:00
|
|
|
|
|
|
|
{
|
2018-06-11 14:52:29 +00:00
|
|
|
a: "u",
|
2018-06-17 14:49:42 +00:00
|
|
|
p: p,
|
|
|
|
v: 0,
|
|
|
|
x: x1,
|
2018-07-28 21:46:23 +00:00
|
|
|
y: y ^ HS(k)
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-06-11 14:52:29 +00:00
|
|
|
link relay downstream message (LRDM)
|
|
|
|
|
|
|
|
sent to relay data via downstream direction of a previously created path.
|
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
{
|
|
|
|
a: "d",
|
|
|
|
p: "<16 bytes path id>",
|
|
|
|
v: 0,
|
|
|
|
x: "<N bytes encrypted x1 value>",
|
|
|
|
y: "<32 bytes nonce>"
|
|
|
|
}
|
2018-06-11 14:52:29 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
if we are the creator of the path decrypt x for each hop key k
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
x = SD(k, y, x)
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
otherwise transmit LRDM to next hop
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-06-17 14:49:42 +00:00
|
|
|
x1 = SE(k, y, x)
|
2017-09-22 21:06:48 +00:00
|
|
|
|
|
|
|
{
|
2018-06-17 14:49:42 +00:00
|
|
|
a: "d",
|
|
|
|
p: p,
|
2018-01-19 16:51:27 +00:00
|
|
|
v: 0,
|
2018-06-17 14:49:42 +00:00
|
|
|
x: x1,
|
2018-07-28 21:46:23 +00:00
|
|
|
y: y ^ HS(k)
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-02-06 17:02:06 +00:00
|
|
|
link immediate dht message (LIDM):
|
|
|
|
|
|
|
|
transfer one or more dht messages directly without a previously made path.
|
|
|
|
|
|
|
|
{
|
2018-05-31 23:10:48 +00:00
|
|
|
a: "m",
|
2018-06-01 14:08:54 +00:00
|
|
|
m: [many, dht, messages],
|
2018-02-22 20:11:06 +00:00
|
|
|
v: 0
|
2018-02-06 17:02:06 +00:00
|
|
|
}
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-10-29 16:49:36 +00:00
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
link immediate SML message (LISM)
|
2018-01-19 16:51:27 +00:00
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
transfer an SML message between nodes
|
2018-01-19 16:51:27 +00:00
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
{
|
|
|
|
a: "s",
|
|
|
|
s: SMLMessage,
|
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
|
|
|
----
|
|
|
|
|
2018-10-29 16:49:36 +00:00
|
|
|
Stateles Mesh Layer (SML)
|
|
|
|
|
|
|
|
As a censor circumvention method layer 4 (udp) or layer 2 (ethernet)
|
|
|
|
network bridges are used to stateless route messages to the main onion
|
|
|
|
routing network in a stateless manner such that these network bridges
|
|
|
|
can be cacsaded many layers deep. The incentive to run these would be
|
|
|
|
the ability to hide your traffic shape in the shape of others without
|
|
|
|
the need to excess node churn.
|
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
stateless mesh discovery protocol (SMDP)
|
|
|
|
|
2018-10-29 16:49:36 +00:00
|
|
|
protocol for detecting and discovering mesh local
|
|
|
|
topology and where the mainline network is.
|
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
TODO: implement me
|
|
|
|
|
|
|
|
stateless mesh layer (SML)
|
|
|
|
|
|
|
|
similar to link layer messeages but sent over the connectivity mesh layer that
|
|
|
|
uses ethernet.
|
|
|
|
|
|
|
|
SML messages MUST be contained inside a LISM when not over ethernet.
|
2018-02-06 17:02:06 +00:00
|
|
|
|
2018-10-29 16:49:36 +00:00
|
|
|
SML message MUST be routed to the recipiant if we are not the recipiant based
|
|
|
|
on the currently unspecified stateless routing protocol.
|
|
|
|
|
|
|
|
TODO: implement routing protocol :^)
|
|
|
|
|
2018-02-06 17:02:06 +00:00
|
|
|
{
|
2018-11-09 19:07:10 +00:00
|
|
|
a: protocol_id_uint16,
|
2018-10-27 12:46:59 +00:00
|
|
|
r: "<32 bytes public identity key of recipiant>",
|
|
|
|
s: "<32 bytes public identity key of sender>",
|
2018-10-29 16:49:36 +00:00
|
|
|
t: "<1280 bytes payload>",
|
2018-02-06 17:02:06 +00:00
|
|
|
v: 0,
|
2018-10-27 12:46:59 +00:00
|
|
|
z: "<64 bytes signature generated by sender>"
|
2018-02-06 17:02:06 +00:00
|
|
|
}
|
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
protocol values:
|
2018-02-06 17:02:06 +00:00
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
0 - mesh discovery
|
2018-10-29 16:49:36 +00:00
|
|
|
t is a SMDP frame (todo: specify me)
|
2018-02-06 17:02:06 +00:00
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
1 - direct chat
|
|
|
|
t is a NUL padded plaintext chat message for node opers to communicate between
|
|
|
|
nodes.
|
2018-02-06 17:02:06 +00:00
|
|
|
|
2018-10-29 16:49:36 +00:00
|
|
|
2 - relayed data packet
|
2018-10-27 12:46:59 +00:00
|
|
|
t is a udp packet relayed from a client behind a client.
|
2018-01-19 16:51:27 +00:00
|
|
|
|
2018-10-29 16:49:36 +00:00
|
|
|
3 - snode to snode direct ip traffic
|
|
|
|
t is an ip packet for "0 hop" direct ip traffic between service nodes
|
|
|
|
|
2018-01-19 16:51:27 +00:00
|
|
|
---
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
routing layer:
|
|
|
|
|
2018-01-19 16:51:27 +00:00
|
|
|
the routing layer provides inter network communication between the LLARP link
|
|
|
|
layer and ip (internet protocol) for exit traffic or ap (anonymous protocol) for
|
|
|
|
hidden services. replies to messages are sent back via the path they
|
2018-07-23 21:59:43 +00:00
|
|
|
originated from inside a LRDM. all routing messages have an S value which
|
|
|
|
provides the sequence number of the message so the messages can be ordered.
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
ipv4 addresses are allowed via ipv4 mapped ipv6 addresses, i.e. ::ffff.10.0.0.1
|
|
|
|
|
2018-06-21 15:46:35 +00:00
|
|
|
path confirm message (PCM)
|
2018-06-11 14:52:29 +00:00
|
|
|
|
2018-06-21 15:46:35 +00:00
|
|
|
sent as the first message down a path after it's built to confirm it was built
|
2018-06-11 14:52:29 +00:00
|
|
|
|
2018-07-23 21:59:43 +00:00
|
|
|
always the first message sent
|
|
|
|
|
2018-06-11 14:52:29 +00:00
|
|
|
{
|
2018-06-21 15:46:35 +00:00
|
|
|
A: "P",
|
|
|
|
L: uint64_milliseconds_path_lifetime,
|
2018-07-23 21:59:43 +00:00
|
|
|
S: 0,
|
|
|
|
T: uint64_milliseconds_sent_timestamp,
|
2018-06-21 15:46:35 +00:00
|
|
|
V: 0
|
|
|
|
}
|
|
|
|
|
|
|
|
path latency message (PLM)
|
|
|
|
|
2018-09-11 15:28:36 +00:00
|
|
|
a latency measurement message, reply with a PLM response if we are the far end
|
|
|
|
of a path.
|
2018-06-21 15:46:35 +00:00
|
|
|
|
|
|
|
variant 1, request, generated by the path creator:
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "L",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-06-21 15:46:35 +00:00
|
|
|
V: 0
|
|
|
|
}
|
|
|
|
|
|
|
|
variant 2, response, generated by the endpoint that recieved the request.
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "L",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-09-11 15:28:36 +00:00
|
|
|
T: uint64_timestamp_recieved,
|
2018-06-11 14:52:29 +00:00
|
|
|
V: 0
|
|
|
|
}
|
|
|
|
|
2018-11-12 16:43:40 +00:00
|
|
|
obtain exit message (OXM)
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-11-09 19:07:10 +00:00
|
|
|
sent to an exit router to obtain ip exit traffic context.
|
2017-09-22 21:06:48 +00:00
|
|
|
replies are sent down the path that messages originate from.
|
|
|
|
|
|
|
|
{
|
2017-10-27 17:22:10 +00:00
|
|
|
A: "X",
|
2018-10-27 12:46:59 +00:00
|
|
|
B: [list, of, permitted, blacklisted, traffic, policies],
|
2018-11-09 19:07:10 +00:00
|
|
|
E: 0 for snode communication or 1 for internet access,
|
2017-09-22 21:06:48 +00:00
|
|
|
I: "<32 bytes signing public key for future communication>",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-06-21 15:46:35 +00:00
|
|
|
T: uint64_transaction_id,
|
2018-01-19 16:51:27 +00:00
|
|
|
V: 0,
|
2018-10-27 12:46:59 +00:00
|
|
|
W: [list, of, required, whitelisted, traffic, policies],
|
2017-09-28 17:02:05 +00:00
|
|
|
X: lifetime_of_address_mapping_in_seconds_uint64,
|
2018-06-21 15:46:35 +00:00
|
|
|
Z: "<64 bytes signature using I>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-11-12 16:43:40 +00:00
|
|
|
grant exit messsage (GXM)
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-11-12 16:43:40 +00:00
|
|
|
sent in response to an OXM to grant an ip for exit traffic from an external
|
2017-09-22 21:06:48 +00:00
|
|
|
ip address used for exit traffic.
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "G",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-01-29 20:02:23 +00:00
|
|
|
T: transaction_id_uint64,
|
2018-11-14 18:02:27 +00:00
|
|
|
Y: "<16 byte nonce>",
|
|
|
|
V: 0,
|
|
|
|
Z: "<64 bytes signature>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-11-09 19:07:10 +00:00
|
|
|
any TITM recieved on the same path will be forwarded out to the internet if
|
|
|
|
OXAM.E is not 0, otherwise it is interpreted as service node traffic.
|
2018-01-29 20:02:23 +00:00
|
|
|
|
|
|
|
|
2018-11-12 16:43:40 +00:00
|
|
|
reject exit message (RXM)
|
2017-09-22 21:06:48 +00:00
|
|
|
|
2018-01-29 20:02:23 +00:00
|
|
|
sent in response to an OXAM to indicate that exit traffic is not allowed or
|
|
|
|
was denied.
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
{
|
2018-06-29 14:25:09 +00:00
|
|
|
A: "J",
|
2017-09-22 21:06:48 +00:00
|
|
|
B: backoff_milliseconds_uint64,
|
2018-10-27 12:46:59 +00:00
|
|
|
R: [list, of, rejected, traffic, policies],
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-01-29 20:02:23 +00:00
|
|
|
T: transaction_id_uint64,
|
2018-11-14 18:02:27 +00:00
|
|
|
V: 0,
|
|
|
|
Y: "<16 byte nonce>",
|
|
|
|
Z: "<64 bytes signature>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2017-09-28 17:02:05 +00:00
|
|
|
|
2018-09-11 15:28:36 +00:00
|
|
|
discarded data fragment message (DDFM)
|
|
|
|
|
|
|
|
sent in reply to TDFM when we don't have a path locally or are doing network
|
2018-11-14 18:02:27 +00:00
|
|
|
congestion control from a TITM.
|
2018-09-11 15:28:36 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
A: "D",
|
|
|
|
P: "<16 bytes path id>",
|
|
|
|
S: uint64_sequence_number_of_fragment_dropped,
|
|
|
|
V: 0
|
|
|
|
}
|
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
transfer data fragment message (TDFM)
|
|
|
|
|
|
|
|
transfer data between paths.
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "T",
|
|
|
|
P: "<16 bytes path id>",
|
|
|
|
S: uint64_sequence_number,
|
2018-09-11 15:28:36 +00:00
|
|
|
T: hidden_service_frame,
|
2018-08-13 23:22:31 +00:00
|
|
|
V: 0
|
|
|
|
}
|
|
|
|
|
2018-09-11 15:28:36 +00:00
|
|
|
transfer data to another path with id P on the local router place a random 32
|
|
|
|
byte and T values into y and z values into a LRDM message (respectively) and
|
|
|
|
send it in the downstream direction. if this path does not exist on the router
|
|
|
|
it is replied to with a DDFM.
|
2018-08-13 23:22:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
hidden service data (HSD)
|
|
|
|
|
|
|
|
data sent anonymously over the network to a recipiant from a sender.
|
|
|
|
sent inside a HSFM encrypted with a shared secret.
|
|
|
|
|
|
|
|
{
|
|
|
|
a: protocol_number_uint,
|
|
|
|
d: "<N bytes payload>",
|
|
|
|
i: Introduction for reply,
|
|
|
|
n: uint_message_sequence_number,
|
|
|
|
o: N seconds until this converstation plans terminate,
|
|
|
|
s: SI of sender,
|
|
|
|
t: "<16 bytes converstation tag present only when n is 0>",
|
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-07-12 18:21:44 +00:00
|
|
|
hidden service frame (HSF)
|
2018-06-08 00:11:25 +00:00
|
|
|
|
2018-07-12 15:46:30 +00:00
|
|
|
TODO: document this better
|
2018-06-08 00:11:25 +00:00
|
|
|
|
2018-07-12 15:46:30 +00:00
|
|
|
intro message (variant 1)
|
2018-06-08 00:11:25 +00:00
|
|
|
|
2018-07-22 23:14:29 +00:00
|
|
|
start a new session
|
|
|
|
|
2018-06-08 00:11:25 +00:00
|
|
|
{
|
2018-06-11 14:52:29 +00:00
|
|
|
A: "H",
|
2018-08-13 23:22:31 +00:00
|
|
|
C: "<1048 bytes ciphertext block>",
|
2018-07-12 15:46:30 +00:00
|
|
|
D: "<N bytes encrypted HSD>",
|
|
|
|
N: "<32 bytes nonce for key exchange>",
|
|
|
|
V: 0,
|
|
|
|
Z: "<64 bytes signature of entire message using sender's signing key>"
|
|
|
|
}
|
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
alice (A) wants to talk to bob (B) over the network, both have hidden services
|
|
|
|
set up and are online on the network.
|
2018-07-22 23:14:29 +00:00
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
A and B are both SI.
|
|
|
|
A_sk is alice's private signing key.
|
2018-07-22 23:14:29 +00:00
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
for alice (A) to send the string "beep" to bob (B), alice picks an introduction
|
|
|
|
to use on one of her paths (I_A) such that I_A is aligning with one of bobs's
|
|
|
|
paths (I_B)
|
2018-07-12 15:46:30 +00:00
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
alice generates:
|
|
|
|
|
|
|
|
T = RAND(16)
|
|
|
|
|
|
|
|
m = {
|
|
|
|
a: 0,
|
|
|
|
d: "beep",
|
|
|
|
i: I_A,
|
|
|
|
n: 0,
|
|
|
|
s: A,
|
|
|
|
t: T,
|
|
|
|
v: 0
|
2018-07-12 15:46:30 +00:00
|
|
|
}
|
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
X = BE(m)
|
2018-07-12 15:46:30 +00:00
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
C, K = PQKE_A(I_B.k)
|
|
|
|
N = RAND(32)
|
|
|
|
D = SE(X, K, N)
|
2018-07-12 15:46:30 +00:00
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
M = {
|
|
|
|
A: "T",
|
|
|
|
P: I_B.P,
|
|
|
|
S: uint64_sequence_number,
|
|
|
|
T: {
|
|
|
|
A: "H",
|
|
|
|
C: C,
|
|
|
|
D: D,
|
|
|
|
N: N,
|
|
|
|
V: 0,
|
2018-09-17 13:28:26 +00:00
|
|
|
Z: "\x00" * 64
|
2018-08-13 23:22:31 +00:00
|
|
|
},
|
|
|
|
V: 0
|
2018-06-08 00:11:25 +00:00
|
|
|
}
|
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
Z = S(A_sk, BE(M))
|
2017-09-28 17:02:05 +00:00
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
alice transmits a TDFM to router with public key I_B.K via her path that ends
|
|
|
|
with router with public key I_B.k
|
2017-09-28 17:02:05 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
A: "T",
|
2018-08-13 23:22:31 +00:00
|
|
|
P: I_B.P,
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-08-13 23:22:31 +00:00
|
|
|
T: {
|
|
|
|
A: "H",
|
|
|
|
C: C,
|
|
|
|
D: D,
|
|
|
|
N: N,
|
|
|
|
V: 0,
|
|
|
|
Z: Z
|
|
|
|
},
|
2018-07-12 15:46:30 +00:00
|
|
|
V: 0
|
2017-09-28 17:02:05 +00:00
|
|
|
}
|
|
|
|
|
2018-08-13 23:22:31 +00:00
|
|
|
the shared secret (S) for further message encryption is:
|
|
|
|
|
|
|
|
S = HS(K + PKE(A, B, sk, N))
|
|
|
|
|
|
|
|
given sk is the local secret encryption key used by the current hidden service
|
|
|
|
|
|
|
|
please note:
|
|
|
|
signature verification can only be done after decryption
|
|
|
|
|
|
|
|
TODO: explain bob's side too (it's invsere of alice's process)
|
|
|
|
|
|
|
|
data from a previously made session (variant 2)
|
|
|
|
|
|
|
|
transfer data on a session previously made
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "H",
|
|
|
|
D: "<N bytes encrypted HSD>",
|
|
|
|
N: "<32 bytes nonce for symettric cipher>",
|
|
|
|
T: "<16 bytes converstation tag>",
|
|
|
|
V: 0,
|
|
|
|
Z: "<64 bytes signature using sender's signing key>"
|
|
|
|
}
|
|
|
|
|
2018-01-29 20:02:23 +00:00
|
|
|
|
2018-06-26 16:23:43 +00:00
|
|
|
transfer ip traffic message (TITM)
|
2017-09-28 17:02:05 +00:00
|
|
|
|
2018-11-14 18:02:27 +00:00
|
|
|
transfer ip traffic
|
2017-09-28 17:02:05 +00:00
|
|
|
|
|
|
|
{
|
2018-11-09 19:07:10 +00:00
|
|
|
A: "I",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-01-19 16:51:27 +00:00
|
|
|
V: 0,
|
2018-09-17 13:28:26 +00:00
|
|
|
X: "<N bytes ip packet>",
|
2018-11-14 18:02:27 +00:00
|
|
|
Y: "<16 bytes nonce>",
|
2018-01-29 20:02:23 +00:00
|
|
|
Z: "<64 bytes signature using previously provided signing key>"
|
2017-09-28 17:02:05 +00:00
|
|
|
}
|
|
|
|
|
2018-09-17 13:28:26 +00:00
|
|
|
X is parsed as an IP packet and the source addresss is extracted.
|
2018-11-14 18:02:27 +00:00
|
|
|
Next we find the corrisponding signing key for a previously granted address
|
2018-01-29 20:02:23 +00:00
|
|
|
and use it to validate the siganture of the entire message. If the signing key
|
|
|
|
cannot be found or the signature is invalid this message is dropped, otherwise
|
2018-11-14 18:02:27 +00:00
|
|
|
the X value is sent on the appropriate network interface.
|
2018-01-29 20:02:23 +00:00
|
|
|
|
|
|
|
When we recieve an ip packet from the internet to an exit address, we put it
|
2018-11-14 18:02:27 +00:00
|
|
|
into a TITM, signed with the router's signing key and send it downstream the
|
2018-02-06 17:02:06 +00:00
|
|
|
corrisponding path in an LRDM.
|
2018-01-29 20:02:23 +00:00
|
|
|
|
|
|
|
update exit path message (UXPM)
|
|
|
|
|
|
|
|
sent from a new path by client to indicate that a previously established exit
|
|
|
|
should use the new path that this message came from.
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "U",
|
2018-11-14 12:23:08 +00:00
|
|
|
P: "<16 bytes previous tx path id>",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-11-14 12:23:08 +00:00
|
|
|
T: uint64_txid,
|
2018-01-29 20:02:23 +00:00
|
|
|
V: 0,
|
2018-11-14 18:02:27 +00:00
|
|
|
Y: "<16 bytes nonce>",
|
2018-01-29 20:02:23 +00:00
|
|
|
Z: "<64 bytes signature using previously provided signing key>"
|
|
|
|
}
|
|
|
|
|
|
|
|
close exit path message (CXPM)
|
|
|
|
|
2018-11-14 18:02:27 +00:00
|
|
|
client sends a CXPM when the exit is no longer needed or by the exit if the
|
|
|
|
exit wants to close prematurely.
|
|
|
|
also sent by exit in reply to a CXPM to confirm close.
|
2018-01-29 20:02:23 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
A: "C",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-01-29 20:02:23 +00:00
|
|
|
V: 0,
|
2018-11-14 18:02:27 +00:00
|
|
|
Y: "<16 bytes nonce>",
|
|
|
|
Z: "<64 bytes signature>"
|
2018-01-29 20:02:23 +00:00
|
|
|
}
|
2018-06-29 14:25:09 +00:00
|
|
|
|
2018-11-14 12:23:08 +00:00
|
|
|
update exit verify message (EXVM)
|
|
|
|
|
|
|
|
sent in reply to a UXPM to verify that the path handover was accepted
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "V",
|
|
|
|
S: uint64_sequence_number,
|
|
|
|
T: uint64_txid,
|
2018-11-14 18:02:27 +00:00
|
|
|
V: 0,
|
|
|
|
Y: "<16 bytes nonce>",
|
|
|
|
Z: "<64 bytes signature>"
|
2018-11-14 12:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-06-29 14:25:09 +00:00
|
|
|
DHT message holder message:
|
|
|
|
|
|
|
|
wrapper message for sending many dht messages down a path.
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "M",
|
|
|
|
M: [many, dht, messages, here],
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-06-29 14:25:09 +00:00
|
|
|
V: 0
|
2018-09-08 15:53:20 +00:00
|
|
|
}
|