-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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
This was referenced Jan 19, 2024
Closed
Merged
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]>
This was referenced Jan 24, 2024
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
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.
The text was updated successfully, but these errors were encountered: