Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor to use a layered architecture #47

Open
ainghazal opened this issue Jan 10, 2024 · 0 comments
Open

refactor to use a layered architecture #47

ainghazal opened this issue Jan 10, 2024 · 0 comments

Comments

@ainghazal
Copy link
Collaborator

ainghazal commented Jan 10, 2024

In the past months we have been working on a major overhaul of the existing codebase to be able to use a new layered approach.

This will allow us for better local reasoning of the different components, and to write unit tests in an isolated way.

@ainghazal ainghazal changed the title review & merge networkio layer of the new minivpn architecture refactor to use a layered architecture Jan 10, 2024
bassosimone pushed a commit that referenced this issue Jan 10, 2024
This commit introduces the lower layer in the new layered minivpn architecture. This new architecture has already been implemented in an integration branch. The general idea is to split functionality by layers that we can reason about and write tests for more easily. Each layer will communicate with other layers through channels. Also, each layer will run a bunch of worker for performing channel or network-based I/O. Here, in particular, we're adding the network I/O layer on top of which the rest of the architecture is based, as well as all the required dependencies for making the code compile.

Reference issue: #47
ainghazal added a commit that referenced this issue Jan 15, 2024
This is the second commit in the series of incremental refactoring of
the current minivpn tree.

In this commit, we introduce the packet muxer, which is the layer just
above the networkio. The packet muxer handles and routes data or control
packets, and it also handles reset packets.

As dependencies for `packetmuxer`, we're also introducing the `optional`
and `session` packages.

Reference issue: #47

---------

Co-authored-by: Simone Basso <[email protected]>
ainghazal added a commit that referenced this issue Jan 15, 2024
This is the third commit in the series of incremental refactoring of the
current minivpn tree.

In this commit, we introduce the reliabletransport package, which is the
layer between packetmuxer and control channel.

Reliable transport adds a reliability layer on top of UDP (but it's also
used in TCP mode).

This first implementation of the reliability layer implements only a
naive strategy to get the TLS handshake working on an optimal
environment (i.e., no packet loss). We ACK any incoming packet, and we
assume all packets arrive in order.

After merging all the components in the new architecture, we will
revisit the reliability layer to follow the OpenVPN design more closely.

Reference issue: #47

---------

Co-authored-by: Simone Basso <[email protected]>
ainghazal added a commit that referenced this issue Jan 15, 2024
This is the fourth commit in the series of incremental refactoring of
the current minivpn tree.

In this commit, we introduce the controchannel package, which is the
layer between reliabletransport and the TLS manager.

Control channel is an abstraction layer that deals with "control
channel" messages in the OpenVPN implementation. The primary goal of the
control channel is to encapsulate TLS records to complete a TLS
handshake. Then this channel is established, a key exchange takes place,
from where the keys for encryption in the Data Channel are then derived.

This initial implementation, as with the current state of the minivpn,
implements no authentication or encryption of the control channel. This
issue will be tackled later on, by implementing `--tls-auth` and
`--tls-crypt`.

Reference issue: #47
ainghazal added a commit that referenced this issue Jan 19, 2024
This is the fifth commit in the series of incremental refactoring of the
current minivpn tree.

In this commit, we introduce the tlsstate package, which is the layer
above the control channel

tlsstate is a service worker that will attempt to do a TLS negotiation
(wrapped in a control packet), and then use this secure channel to
exchange keys with the OpenVPN server and use these keys for encrypting
and decrypting payloads in the data channel.

tlsstate waits for a signal in the NotifyTLS channel and then will start
the handshake and the key negotiation.

Reference issue: #47
ainghazal added a commit that referenced this issue Jan 19, 2024
This is the sixth commit in the series of incremental refactoring of the
current minivpn tree.

In this commit, we introduce the datachannel package. This layer is
above TLS and it communicates with TLS, the Packet Muxer and TUN. It is
also the last layer below the TUN interface.

datachannel has two channels to communicate with the muxer, two channels
to move cleartext bytes to the TUN interface, and one channel to receive
keys from TLS.

Reference issue: #47

---------

Co-authored-by: Simone Basso <[email protected]>
ainghazal added a commit that referenced this issue Jan 22, 2024
This is the seventh (and in a sense, last) commit in the series of
incremental refactoring of the current minivpn tree. With this package
we have all the needed layers to start reasoning about the complete
architecture.

TUN uses a similar strategy to the TLSBio in the tlssession package: it
uses channels to communicate with the layer below (the data channel),
and it buffers reads.

Reference issue: #47

---------

Co-authored-by: Simone Basso <[email protected]>
ainghazal added a commit that referenced this issue Jan 24, 2024
This is a follow-up to the ongoing architectural refactor after the last
merged layer (#54).

Here we add documentation to the layered approach.

Additionally, we change the `OnWorkerDone()` call so that the worker's
name is passed in the call and logging responsibility for the done event
belongs to the `workers.Manager`.

Reference issue: #47

---------

Co-authored-by: Simone Basso <[email protected]>
bassosimone added a commit that referenced this issue Feb 2, 2024
# Checklist

* [x] I have read the contribution guidelines
* [x] Iff you changed code related to services, or inter-service
communication, make sure you update the diagrams in `ARCHITECTURE.md`.
* [x] Reference issue for this pull request: #47

# Description

In this PR I implement the reliability algorithm for the OpenVPN
protocol:

- Each reliable packet emitted is subject to retransmission if it's not
acked in time. Retransmission follows an exponential backoff - beginning
at 2 seconds, with a cap at 60s.
- Incoming packets are subject to reordering before being passed to TLS.
- Incoming packets are passed to reliable.moveDownWorker to send ACKs if
there's a packet in the outgoing queue.

---------

Co-authored-by: Simone Basso <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant