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
|
2017-09-22 21:06:48 +00:00
|
|
|
recipiants of encrypted messages sent over the internet without a centralied
|
|
|
|
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
|
|
|
|
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-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-04-04 16:10:27 +00:00
|
|
|
l: lifetime_in_seconds_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-01-30 13:38:29 +00:00
|
|
|
u: last_updated_seconds_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-06-29 14:25:09 +00:00
|
|
|
x is the timestamp seconds 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,
|
2017-09-22 21:06:48 +00:00
|
|
|
x: time_expires_seconds_since_epoch_uint64
|
|
|
|
}
|
|
|
|
|
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-04-06 15:48:28 +00:00
|
|
|
a is the service info
|
2018-06-29 14:25:09 +00:00
|
|
|
i is the list of introductions that this service is advertising with
|
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-07-17 07:30:03 +00:00
|
|
|
n: "<16 bytes service topic (optional)>",
|
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.
|
|
|
|
|
2018-05-19 13:36:42 +00:00
|
|
|
if r is not present in sessions made by clients.
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
{
|
|
|
|
a: "i",
|
|
|
|
r: RC,
|
|
|
|
v: 0
|
|
|
|
}
|
|
|
|
|
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-01-19 16:51:27 +00:00
|
|
|
|
2018-02-06 17:02:06 +00:00
|
|
|
link stateless relay message (LSRM)
|
2018-01-19 16:51:27 +00:00
|
|
|
|
2018-02-06 17:02:06 +00:00
|
|
|
statelessly relay a link message.
|
|
|
|
|
|
|
|
{
|
|
|
|
a: "r",
|
2018-06-08 00:11:25 +00:00
|
|
|
c: r_counter_uint8,
|
2018-02-06 17:02:06 +00:00
|
|
|
d: "<32 bytes rc.K of destination>",
|
|
|
|
s: "<32 bytes rc.K of source>",
|
|
|
|
v: 0,
|
|
|
|
x: "<N bytes encrypted link message>",
|
|
|
|
y: "<24 bytes nounce>",
|
|
|
|
z: "<64 bytes signature>"
|
|
|
|
}
|
|
|
|
|
|
|
|
ONLY exchanged over ethernet, if recieved from an IP link it MUST be discarded.
|
|
|
|
|
|
|
|
relay an encrypted link message from source s to destination d.
|
|
|
|
check signature z using public key s and discard if invalid signature.
|
|
|
|
|
|
|
|
if d is equal to ourRC.k then decrypt x via SD(KE(d, s), y, x) and process it as
|
|
|
|
a link message. if the inner decrypted link message is a LRCM forward all
|
|
|
|
following LRUM, LRDM and LRSM to s via a LSRM. LIDM and LSRM are discarded.
|
|
|
|
|
|
|
|
if d is not equal to ourRC.k then forward it to an ethernet peer that is cloeser
|
|
|
|
to d than you are. if you are closer to d than all of your other ethernet peers
|
|
|
|
then increment c and send to the ethernet peer with the lowest detected latency
|
|
|
|
that isn't the peer that this message was recieved from but ONLY if c is less
|
|
|
|
than 128. if c is equal to or greater than 128 then the message is discarded.
|
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)
|
|
|
|
|
|
|
|
a latency measurement message, reply with a PLM response if we are the far end of a path.
|
|
|
|
|
|
|
|
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,
|
|
|
|
T: uint64_timestamp_sent,
|
2018-06-11 14:52:29 +00:00
|
|
|
V: 0
|
|
|
|
}
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
obtain exit address message (OXAM)
|
|
|
|
|
|
|
|
sent to an exit router to obtain a NAT ip address for ip exit traffic.
|
|
|
|
replies are sent down the path that messages originate from.
|
|
|
|
|
|
|
|
{
|
2017-10-27 17:22:10 +00:00
|
|
|
A: "X",
|
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,
|
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
|
|
|
}
|
|
|
|
|
|
|
|
grant exit address messsage (GXAM)
|
|
|
|
|
2018-01-29 20:02:23 +00:00
|
|
|
sent in response to an OXAM 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-01-30 13:38:29 +00:00
|
|
|
E: XR,
|
2017-09-22 21:06:48 +00:00
|
|
|
I: "<32 bytes signing public key of requester>",
|
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-01-19 16:51:27 +00:00
|
|
|
V: 0,
|
2018-01-29 20:02:23 +00:00
|
|
|
Z: "<64 bytes signature using exit info's signing key>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
E contains an exit route that was granted to the requester that can be used with
|
2018-01-29 20:02:23 +00:00
|
|
|
IP exit traffic.
|
|
|
|
|
2018-01-30 13:38:29 +00:00
|
|
|
The requester will now have any ip traffic going to address S forwarded to them
|
|
|
|
via the path that originally sent the OXAM and any TDFM will is recieved on the
|
|
|
|
same path will be forwarded out to the internet, given that they have
|
2018-01-29 20:02:23 +00:00
|
|
|
valid signatures and addresses.
|
|
|
|
|
|
|
|
|
2017-09-22 21:06:48 +00:00
|
|
|
reject exit address message (RXAM)
|
|
|
|
|
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,
|
|
|
|
I: "<32 bytes signing public key of requester>",
|
|
|
|
R: "<optional reject metadata>",
|
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-01-19 16:51:27 +00:00
|
|
|
V: 0,
|
2018-01-29 20:02:23 +00:00
|
|
|
Z: "<64 bytes signature signed by exit info's signing key>"
|
2017-09-22 21:06:48 +00:00
|
|
|
}
|
|
|
|
|
2018-01-29 20:02:23 +00:00
|
|
|
B is set to a backoff value.
|
|
|
|
R contains additional metadata text describing why the exit was rejected.
|
2017-09-28 17:02:05 +00:00
|
|
|
|
|
|
|
|
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-07-12 15:46:30 +00:00
|
|
|
D: "<N bytes encrypted HSD>",
|
|
|
|
H: "<32 bytes ephemeral public encryption key>",
|
|
|
|
N: "<32 bytes nonce for key exchange>",
|
|
|
|
S: 0,
|
|
|
|
V: 0,
|
|
|
|
Z: "<64 bytes signature of entire message using sender's signing key>"
|
|
|
|
}
|
|
|
|
|
2018-07-22 23:14:29 +00:00
|
|
|
D is encrypted with session key K which is derived by
|
|
|
|
|
|
|
|
K = PKE(H, SI.enckey, N)
|
|
|
|
|
2018-07-12 15:46:30 +00:00
|
|
|
ordered data message (variant 2)
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "H",
|
|
|
|
D: "<N bytes encrypted HSD>",
|
|
|
|
N: "<32 bytes nonce for symettric cipher>",
|
|
|
|
S: sequence_number_uint64,
|
2018-08-09 19:02:17 +00:00
|
|
|
T: "<16 bytes converstation tag>",
|
2018-06-08 00:11:25 +00:00
|
|
|
V: 0,
|
2018-07-12 15:46:30 +00:00
|
|
|
Z: "<64 bytes signature using sender's signing key>"
|
|
|
|
}
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
{
|
2018-08-09 19:02:17 +00:00
|
|
|
a: protocol_number_uint,
|
|
|
|
d: "<N bytes payload>",
|
|
|
|
i: Introduction for reply,
|
|
|
|
s: SI of sender,
|
|
|
|
t: "<16 bytes converstation tag present only in message 0>",
|
|
|
|
v: 0
|
2018-06-08 00:11:25 +00:00
|
|
|
}
|
|
|
|
|
2017-09-28 17:02:05 +00:00
|
|
|
transfer data fragment message (TDFM)
|
|
|
|
|
2018-01-29 20:02:23 +00:00
|
|
|
transfer data between paths.
|
2017-09-28 17:02:05 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
A: "T",
|
2018-06-21 15:46:35 +00:00
|
|
|
P: "<16 bytes path id>",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-07-12 18:21:44 +00:00
|
|
|
T: message_transfered_between_paths,
|
2018-07-12 15:46:30 +00:00
|
|
|
V: 0
|
2017-09-28 17:02:05 +00:00
|
|
|
}
|
|
|
|
|
2018-07-12 15:46:30 +00:00
|
|
|
transfer data to another path with id P on the local router place a random 32 byte and T values
|
2018-01-29 20:02:23 +00:00
|
|
|
into y and z values into a LRDM message (respectively) and send it in the
|
|
|
|
downstream direction.
|
|
|
|
|
2018-06-26 16:23:43 +00:00
|
|
|
transfer ip traffic message (TITM)
|
2017-09-28 17:02:05 +00:00
|
|
|
|
|
|
|
transfer ip traffic for exit
|
|
|
|
|
|
|
|
{
|
2018-06-26 16:23:43 +00:00
|
|
|
A: "E",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-01-19 16:51:27 +00:00
|
|
|
V: 0,
|
2017-10-27 17:22:10 +00:00
|
|
|
X: "<N bytes ipv6 packet>",
|
2018-01-29 20:02:23 +00:00
|
|
|
Y: "<16 bytes nounce>",
|
|
|
|
Z: "<64 bytes signature using previously provided signing key>"
|
2017-09-28 17:02:05 +00:00
|
|
|
}
|
|
|
|
|
2018-01-29 20:02:23 +00:00
|
|
|
X is parsed as an IPv6 packet and the source addresss is extracted.
|
|
|
|
Next we find the corrisponding signing key for a previously granted exit address
|
|
|
|
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
|
|
|
|
the X value is sent on the appropriate exit network interface.
|
|
|
|
|
|
|
|
When we recieve an ip packet from the internet to an exit address, we put it
|
2018-06-26 16:23:43 +00:00
|
|
|
into a TITM, signed with the exit info'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-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-01-29 20:02:23 +00:00
|
|
|
T: transaction_id_uint64,
|
|
|
|
V: 0,
|
|
|
|
Y: "<16 bytes nounce>",
|
|
|
|
Z: "<64 bytes signature using previously provided signing key>"
|
|
|
|
}
|
|
|
|
|
|
|
|
T is the transaction ID from the GXAM
|
|
|
|
|
|
|
|
close exit path message (CXPM)
|
|
|
|
|
|
|
|
client sends a CXPM when the exit is no longer needed.
|
|
|
|
The address used in exit MAY be reused later.
|
|
|
|
|
|
|
|
{
|
|
|
|
A: "C",
|
2018-07-23 21:59:43 +00:00
|
|
|
S: uint64_sequence_number,
|
2018-01-29 20:02:23 +00:00
|
|
|
T: transaction_id_uint64,
|
|
|
|
V: 0,
|
|
|
|
Y: "<16 bytes nounce>",
|
|
|
|
Z: "<64 bytes signagure using previously provided signing key>"
|
|
|
|
}
|
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
|
|
|
|
}
|