Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
R
re6stnet
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Joanne Hugé
re6stnet
Commits
bcc82f9a
Commit
bcc82f9a
authored
Jan 28, 2021
by
Joanne Hugé
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Define the Re6st protocol in docs
parent
43972615
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
129 additions
and
0 deletions
+129
-0
docs/re6st-protocol
docs/re6st-protocol
+129
-0
No files found.
docs/re6st-protocol
0 → 100644
View file @
bcc82f9a
Re6st Protocol
--------------
Table of Contents
-----------------
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. Re6st packet format . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Network Version Message . . . . . . . . . . . . . . . . . . . . . . . . .
5. Address Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. Tunnel Destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. Introduction
---------------
The re6st protocol is defined for communication between nodes of a re6st
network relative to the network itself. Nodes communicate to cooperate
together on the creation and destruction of tunnels.
2. Handshake
-----------------
The first step for two nodes to communicate is to establish
a connection, which requires a handshake. The purpose of the handshake
is to authenticate the nodes between each other by exchanging their public
certificate, and initialize a secret.
Three types of exchanges are defined for the handshake protocol:
| Seqno | Content |
| ----- | ----------------------------------------------------------------- |
| 0 | pub(sender) |
| 1 | sender protocol, fingerprint(receiver), pub(sender) |
| 2 | sender protocol, X = encrypt(receiver, secret), sign(sender, X) |
During a handshake, two or more exchanges may happen, depending on lost
packets, the cache's content, etc...
The handshake proceeds as follows:
Beginning of handshake:
If the node already has a certificate corresponding to the peer node's
IP, he sends seqno 1, else he sends seqno 0.
Reception of seqno 0:
The node adds the certificate to its list of known certificates, and sends
seqno 1.
Reception of seqno 1:
The received certificate is added
If the fingerprint is correct:
- a new secret strictly greater than the previous one is generated
- seqno 2 is sent.
Else, the node goes back to the beginning
Reception of seqno 2:
If the signature verification or if the secret is less or equal to the secret
node previously had, the handshake fails.
Else, the node sends its network version.
3. Re6st packet format
----------------
| Field | Length |
| --------------- | --------- |
| Sequence number | 4 octets |
| Code | 1 octet |
| Message | Variable |
| HMAC | 20 octets |
The sequence number is increased at each message, starting from 2 after
the handshake.
The code defines the type of message:
000 : Network Version
001 : Address
010 : Tunnel Destruction Request
011 : Tunnel Destruction Response
... : Reserved
The message contents depends on the code, and can vary in size. It must
be small enough for the packet to not exceed the default minimum MTU
of IPv6 (1280) bytes.
The HMAC field contains HMAC(secret, data), where HMAC is a HMAC function
using sha1 and the secret created during the handshake, and data is the
packet contents from the sequence number to the message.
4. Network Version Message
--------------------------
The Network Version Message contains the signed network version. It is
encoded such that each new version message is strictly greater than the
previous.
5. Address Message
------------------
Each node has a list (potentially empty) of addresses to advertise to other
nodes. An address is a tuple of three values: IP, port and protocol.
For instance: (10.0.0.2, 1194, TCP), (2001:db8:42:4::1, 1195, UDPv6)
In order for nodes to make tunnels between each other, they need to know
each other's advertised list of address. There are two ways for nodes
to learn about this:
- Asking the registry with the Remote Procedure Call getBootstrapPeer:
this is done only if a node doesn't know any node's addresses yet
- Sending a re6st packet with code 001 to a node
The address list is sent as a string, each address is separated by a
semicolon, and each address contains an ip, port and protocol separated
by a comma.
"ip1,port1,proto1;ip2,port2,proto2;ip3,port3,proto3"
6. Tunnel Destruction
---------------------
The destruction of a tunnel requires multiple stages:
- soft locking: the node orders babel to raise the cost of its route to
the peer
- hard locking: the route is marked as unusable
- locking request: a request to close the tunnel is sent to the peer,
corresponding to an empty code 2 message
- locking response: the peer answers with an empty code 3 message
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment