-
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
implement UDP reliability layer #32
Comments
From the work done to remediate all the vulnerabilities uncovered by the Red Team Lab, this has proven to be the most interesting. I have partially implemented openvpn's reliability layer, and added the provided The initial handshake proves to be the most sensitive part in my implementation. I've added retry loops in the different steps for the handshake, and I manage to get However, OpenVPN also seems to get into a TLS handshake stall from time to time at the same injection rates. This is probabilistic, and the approximate failure rate should be determined more accurately:
It's worth noting that OpenVPN tendency to stall at the same injection rate feels lesser than mine (based on superficial observation). I'm tempted to keep debugging the TLS handshake, and perhaps finding ways in the current implementation to follow OpenVPN's more closely, but at this point I feel that for the purposes of monitoring services, this is approaching a good state: if a censor is successfully injecting packets at such a rate, we want to measure a rate of failure that is approximately equal to the reference implementation. Perhaps I could determine this failure rate empirically, so that I have a reference of what is the order of magnitude I need to approach to. One useful thing might be to log the number of drops and/or bad packets (most of the cases will be drops becase the incoming packet id is out of the capacity of the receive window, which is by default set to a len of 8 packets in the reference implementation). On the other hand, I also feel that priority-wise, time would be better spent implementing The time-to-bootstrap will be a good proxy of anomalies. |
This is not a complete implementation of the reliability layer. Rather, I've tried to achieve te minimal incremental change that adds resilience in the fase of network noise. To achieve that, the simple thing to do was to make session an object owned by an implementation of reliableTransport. I've reused the reliableUDP implementation in govpn, and I like the simplicity of that implementation a lot. A lot of our current logic (ackqueue/retries) needs to move from the tlsTransport minivpn implementation into reliableTransport. - Related: ooni#32
This is not a complete implementation of the reliability layer. Rather, I've tried to achieve te minimal incremental change that adds resilience in the fase of network noise. To achieve that, the simple thing to do was to make session an object owned by an implementation of reliableTransport. I've reused the reliableUDP implementation in govpn, and I like the simplicity of that implementation a lot. A lot of our current logic (ackqueue/retries) needs to move from the tlsTransport minivpn implementation into reliableTransport. - Related: ooni#32
I've tried to achieve te minimal incremental change that adds resilience in the face of network noise. To achieve that, the simple thing to do was to make session an object owned by an implementation of reliableTransport. I've reused the reliableUDP implementation in govpn, and I like the simplicity of that implementation a lot. A lot of our current logic (ackqueue/retries) needed to move from the tlsTransport minivpn implementation into reliableTransport. Although the DoS documented in the MIV-01 report is not done, we add the e2e testing script to facilitate further development. - Related: ooni#32 more tests
I've tried to achieve te minimal incremental change that adds resilience in the face of network noise. To achieve that, the simple thing to do was to make session an object owned by an implementation of reliableTransport. I've reused the reliableUDP implementation in govpn, and I like the simplicity of that implementation a lot. A lot of our current logic (ackqueue/retries) needed to move from the tlsTransport minivpn implementation into reliableTransport. Although the DoS documented in the MIV-01 report is not done, we add the e2e testing script to facilitate further development. - Related: ooni#32 more tests
I've tried to achieve te minimal incremental change that adds resilience in the face of network noise. To achieve that, the simple thing to do was to make session an object owned by an implementation of reliableTransport. I've reused the reliableUDP implementation in govpn, and I like the simplicity of that implementation a lot. A lot of our current logic (ackqueue/retries) needed to move from the tlsTransport minivpn implementation into reliableTransport. Although the DoS documented in the MIV-01 report is not done, we add the e2e testing script to facilitate further development. - Related: ooni#32 more tests
OpenVPN implements its own reliability layer on top of UDP (it's worthy to note that it's used for TCP too). We should follow the reference implementation as closely as possible.
This basically boils down to keep track of acknowledged packets on a fixed-size structure, and retry sending if acks have not been received after a given period. Retries follow an exponential back-off, and incoming packets with ids beyond a certain acknowledgment window will be dropped since sequentiality cannot be guaranteed by the data structure.
edit: for some reason I had originally written "sentimentality" in the last sentence.
Relevant pointers:
The text was updated successfully, but these errors were encountered: