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
|
2021-05-06 00:33:47 +00:00
|
|
|
whose values are b and z respectively
|
2017-09-22 21:06:48 +00:00
|
|
|
|
|
|
|
[ a, b, c ... ] is a list containing a b c and more items in that order
|
|
|
|
|
2021-05-06 00:33:47 +00:00
|
|
|
"<description>" is a bytestring whose contents and length is described by the
|
2017-09-22 21:06:48 +00:00
|
|
|
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
|
|
|
|
|
2018-12-18 18:57:31 +00:00
|
|
|
see wire-protocol.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
|
|
|
}
|
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
example wank address info:
|
2018-02-15 16:32:11 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
c: 1,
|
2019-05-21 14:57:21 +00:00
|
|
|
d: "wank",
|
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:
|
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
d1:ci1e1:d4:wank1: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 ... ],
|
2019-05-21 14:57:21 +00:00
|
|
|
e: extensions_supported,
|
2018-12-19 16:17:41 +00:00
|
|
|
i: "<max 8 bytes network identifier>",
|
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>",
|
2019-05-21 14:57:21 +00:00
|
|
|
s: [services, supported],
|
2019-01-24 13:18:15 +00:00
|
|
|
u: time_signed_at_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
|
|
|
}
|
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
e is a dict containing key/value of supported protocol extensions on this service node, keys are strings, values MUST be 0 or 1.
|
|
|
|
|
|
|
|
s is a list of services on this service node:
|
|
|
|
|
|
|
|
each service is a 6 item long, list of the following:
|
|
|
|
|
|
|
|
["_service", "_proto", ttl_uint, priority_uint, weight_uint, port_uint]
|
|
|
|
|
|
|
|
with the corrisponding SRV record:
|
|
|
|
|
|
|
|
<_service>.<_proto>.router_pubkey_goes_here.snode. <ttl_uint> IN SRV <priority_uint> <weight_uint> <port_uint> router_pubkey_goes_here.snode
|
|
|
|
|
2018-12-18 18:57:31 +00:00
|
|
|
|
2018-12-18 19:02:21 +00:00
|
|
|
RC.t is the timestamp of when this RC was signed.
|
|
|
|
RC is valid for a maximum of 1 hour after which it MUST be resigned with the new
|
|
|
|
timestamp.
|
|
|
|
|
2018-12-18 18:57:31 +00:00
|
|
|
RC.i is set to the network identifier.
|
|
|
|
|
|
|
|
only routers with the same network identifier may connect to each other.
|
|
|
|
|
2018-12-18 19:03:40 +00:00
|
|
|
"testnet" for testnet.
|
2018-12-18 19:02:21 +00:00
|
|
|
"lokinet" for the "official" lokinet mainline network.
|
2018-12-18 18:57:31 +00:00
|
|
|
|
|
|
|
other values of RC.i indicate the router belongs to a network fork.
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
and introset is 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
|
2019-05-21 14:57:21 +00:00
|
|
|
h is a list of srv records in same format as in RCs
|
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,
|
2019-05-21 14:57:21 +00:00
|
|
|
h: [list, of, advertised, services],
|
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>"
|
|
|
|
}
|
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
h is a list of services on this endpoint
|
|
|
|
|
|
|
|
each service is a 7 item long, list of the following:
|
|
|
|
|
|
|
|
["_service", "_proto", ttl_uint, priority_uint, weight_uint, port_uint, "<32 bytes SA of the service>"]
|
|
|
|
|
|
|
|
with the corrisponding SRV record:
|
|
|
|
|
|
|
|
<_service>.<_proto>.<service_address>.loki. <ttl_uint> IN SRV <priority_uint> <weight_uint> <port_uint> <SA of sub service>.loki.
|
|
|
|
|
|
|
|
recursion on SRV records is NOT permitted.
|
2017-09-22 21:06:48 +00:00
|
|
|
|
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",
|
2019-01-05 13:45:05 +00:00
|
|
|
e: "<32 bytes ephemeral public encryption key>",
|
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",
|
2019-06-04 18:31:17 +00:00
|
|
|
c: [ list, of, encrypted, LRCR frames ],
|
2018-02-22 20:11:06 +00:00
|
|
|
v: 0
|
2017-10-27 17:22:10 +00:00
|
|
|
}
|
|
|
|
|
2019-06-04 18:31:17 +00:00
|
|
|
c MUST contain dummy records if the hop length is less than the maximum
|
2018-06-08 00:11:25 +00:00
|
|
|
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
|
2021-05-06 00:33:47 +00:00
|
|
|
on network whose i is equal to RC.k and decrypt data any messages using
|
|
|
|
PKE(n, rc.p, c) as symmetric 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>",
|
2019-06-04 18:31:17 +00:00
|
|
|
d: uint_optional_ms_delay, // TODO
|
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>",
|
2019-04-17 19:05:54 +00:00
|
|
|
u: "<optional RC of the next hop>",
|
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
|
|
|
|
2019-06-04 18:31:17 +00:00
|
|
|
link relay status message (LRSM)
|
|
|
|
|
|
|
|
response to path creator about build status
|
|
|
|
|
|
|
|
{
|
|
|
|
a: "s",
|
|
|
|
c: [ list, of, encrypted, LRSR frames],
|
|
|
|
p: "<16 bytes rx path id>",
|
|
|
|
s: uint_status_flags, // for now, only set (or don't) success bit
|
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
|
|
|
the creator of the LRSM MUST include dummy LRSR records
|
|
|
|
to pad out to the maximum path length
|
|
|
|
|
|
|
|
link relay status record (LRSR)
|
|
|
|
|
|
|
|
record indicating status of path build
|
|
|
|
|
|
|
|
{
|
|
|
|
s: uint_status_flags,
|
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
|
|
|
uint_status_flags (bitwise booleans):
|
|
|
|
[0] = success
|
|
|
|
[1] = fail, hop timeout
|
|
|
|
[2] = fail, congestion
|
|
|
|
[3] = fail, refusal, next hop is not known to be a snode
|
|
|
|
[4] = fail, used by hop creator when decrypting frames if decryption fails
|
|
|
|
[5] = fail, used by hop creator when record decode fails
|
|
|
|
[4-63] reserved
|
|
|
|
|
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
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
link immediate state message (LISM)
|
2018-01-19 16:51:27 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
transfer a state message between nodes
|
2018-01-19 16:51:27 +00:00
|
|
|
|
2018-10-27 12:46:59 +00:00
|
|
|
{
|
|
|
|
a: "s",
|
2019-03-27 12:36:27 +00:00
|
|
|
s: state_message,
|
2018-10-27 12:46:59 +00:00
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
---
|
2018-10-27 12:46:59 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
state message:
|
2018-10-29 16:49:36 +00:00
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
NOTE: this message type is currently a documentation stub and remains unimplemented.
|
|
|
|
|
|
|
|
state messages propagate changes to the service nodes concensous to thin clients.
|
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
service node joined network
|
2018-10-27 12:46:59 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
{
|
|
|
|
A: "J",
|
|
|
|
R: "<32 bytes public key>",
|
|
|
|
V: 0
|
|
|
|
}
|
2018-10-27 12:46:59 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
service node parted network
|
2018-10-27 12:46:59 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
{
|
|
|
|
A: "P",
|
|
|
|
R: "<32 bytes public key>",
|
|
|
|
V: 0
|
|
|
|
}
|
2018-02-06 17:02:06 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
service node list request
|
2018-10-29 16:49:36 +00:00
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
request the service node list starting at index I containing R entries
|
2018-10-29 16:49:36 +00:00
|
|
|
|
2018-02-06 17:02:06 +00:00
|
|
|
{
|
2019-03-27 12:36:27 +00:00
|
|
|
A: "R",
|
2019-05-21 14:57:21 +00:00
|
|
|
I: starting_offset_int,
|
2019-03-27 12:36:27 +00:00
|
|
|
R: number_of_entires_to_request_int,
|
|
|
|
V: 0
|
2018-02-06 17:02:06 +00:00
|
|
|
}
|
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
service node list response
|
2018-02-06 17:02:06 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
response to service node list request
|
2018-01-19 16:51:27 +00:00
|
|
|
|
2019-03-27 12:36:27 +00:00
|
|
|
{
|
|
|
|
A: "L",
|
|
|
|
S: {
|
2019-05-21 14:57:21 +00:00
|
|
|
"<32 bytes pubkey>" : 1,
|
|
|
|
"<32 bytes pubkey>" : 1,
|
2019-03-27 12:36:27 +00:00
|
|
|
....
|
|
|
|
},
|
|
|
|
V: 0
|
|
|
|
}
|
2018-10-29 16:49:36 +00:00
|
|
|
|
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,
|
2019-02-21 17:41:29 +00:00
|
|
|
t: "<16 bytes converstation_tag>,
|
2018-08-13 23:22:31 +00:00
|
|
|
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
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
establish converstation tag message (variant 1)
|
2018-06-08 00:11:25 +00:00
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
generate a new convotag that is contained inside an encrypted HSD
|
2018-07-22 23:14:29 +00:00
|
|
|
|
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>",
|
2019-03-08 17:00:13 +00:00
|
|
|
F: "<16 bytes source path_id>",
|
2018-07-12 15:46:30 +00:00
|
|
|
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
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
A and B are both referring to alice and bob's SI respectively.
|
2018-08-13 23:22:31 +00:00
|
|
|
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
|
|
|
|
2019-03-08 17:00:13 +00:00
|
|
|
path = PickSendPath()
|
|
|
|
|
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,
|
2019-03-08 17:00:13 +00:00
|
|
|
F: path.lastHop.txID,
|
2018-08-13 23:22:31 +00:00
|
|
|
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
|
|
|
|
2019-03-08 17:00:13 +00:00
|
|
|
path = PickSendPath()
|
|
|
|
|
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,
|
2019-03-08 17:00:13 +00:00
|
|
|
F: path.lastHop.txID,
|
2018-08-13 23:22:31 +00:00
|
|
|
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:
|
2019-05-21 14:57:21 +00:00
|
|
|
signature verification of the outer message can only be done after decryption
|
|
|
|
because the signing keys are inside the encrypted HSD.
|
2018-08-13 23:22:31 +00:00
|
|
|
|
|
|
|
data from a previously made session (variant 2)
|
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
transfer data on a converstation previously made
|
2018-08-13 23:22:31 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
A: "H",
|
|
|
|
D: "<N bytes encrypted HSD>",
|
2019-03-08 17:00:13 +00:00
|
|
|
F: "<16 bytes path id of soruce>",
|
2018-08-13 23:22:31 +00:00
|
|
|
N: "<32 bytes nonce for symettric cipher>",
|
|
|
|
T: "<16 bytes converstation tag>",
|
|
|
|
V: 0,
|
|
|
|
Z: "<64 bytes signature using sender's signing key>"
|
|
|
|
}
|
|
|
|
|
2019-05-22 16:20:03 +00:00
|
|
|
reject a message sent on a convo tag, when a remote endpoint
|
|
|
|
sends this message a new converstation SHOULD be established.
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "H",
|
|
|
|
F: "<16 bytes path id of soruce>",
|
|
|
|
R: 1,
|
|
|
|
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,
|
2019-05-21 14:57:21 +00:00
|
|
|
X: [list, of, ip, packet, buffers],
|
2017-09-28 17:02:05 +00:00
|
|
|
}
|
|
|
|
|
2018-11-29 21:19:20 +00:00
|
|
|
an ip packet buffer is prefixed with a 64 bit big endian unsigned integer
|
|
|
|
denoting the sequence number for re-ordering followed by the ip packet itself.
|
|
|
|
|
2019-05-21 14:57:21 +00:00
|
|
|
X is parsed as a list of IP packet buffers.
|
2018-11-28 16:38:20 +00:00
|
|
|
for each ip packet the source addresss is extracted and sent on the
|
2018-11-21 12:31:36 +00:00
|
|
|
appropriate network interface.
|
2018-01-29 20:02:23 +00:00
|
|
|
|
2021-05-06 00:33:47 +00:00
|
|
|
When we receive an ip packet from the internet to an exit address, we put it
|
|
|
|
into a TITM, and send it downstream the corresponding 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
|
|
|
}
|