|
|
|
Proposal: Quic can be a drop in replacements for tor circuits
|
|
|
|
|
|
|
|
- Quic provides end to end congestion control tunnel - and provides ability to have multiple streams inside
|
|
|
|
- Multiple stream packets inside single Quic connection.
|
|
|
|
- We can set these packets to be the same size (get the same fixed frame properties for tor cells)
|
|
|
|
- Provides the ability to do drop-based congestion control
|
|
|
|
- We can have fixed length queues at the tor relays, and if the queues overflow, packets will get dropped
|
|
|
|
- In this case, drops signal congestion, and Quic will back off when drops occur, so Quic will back off from sending (similar to TCP)
|
|
|
|
- We also get selective acknowledgment, fast retransmit, slow start
|
|
|
|
- Quic has a reordering constant, which allows for cells to be acknowledged if they are out of order by at most N=3.
|
|
|
|
|
|
|
|
Concerns:
|
|
|
|
- Possible side channel of drop and reordering information
|
|
|
|
- The guard could choose to drop a pattern of cells, which would go to the exit. the client would ask for that pattern again.
|
|
|
|
- The drop pattern would be visible to the exit.
|
|
|
|
- Other side channels exist in Tor now. Is this one any worse? Can all existing side channels actually be solved?
|
|
|
|
|
|
|
|
Experiment ideas:
|
|
|
|
1. We should create a network simulator that would simulate a network and connections that is similar to Tor. We should simulate how this network would react when it is fully utilized to the point where it is dropping packets. We should solve the question of how Quic would work as a intranet. Would every flow stay in slow start forever? What is the number of Quic connections that we would expect to go through a large tor relay?
|
|
|
|
2. How to tune Quic to make it better or worse?
|
|
|
|
3. How much memory load is there for each session?
|
|
|
|
4. What would the drop rate look like?
|
|
|
|
|
|
|
|
Stuff inside Quic that we would need to tune
|
|
|
|
1. Queue length
|
|
|
|
2. Queue management
|
|
|
|
3. How long slow start works - what those windows would be
|
|
|
|
4. Backoff rate
|
|
|
|
5. Reordering parameter - we could accept more or less
|
|
|
|
6. Alternate drop recovery strategies - we should start to test against IETF for a baseline
|
|
|
|
7. Explicit congestion notification - ECN- there are extensions for this, it isn't clear how this would impact the side channel issue.
|
|
|
|
|
|
|
|
Questions to answer:
|
|
|
|
- How would re-encryption between relays work? Quic encryption is TLS 1.3, so this means the outer layer would be TLS 1.3 by default, but is replaceable.
|
|
|
|
IETF Quic has a connection ID in the clear. But we'll have to do an outer layer of onion encryption on the outside to encrypt the connection ID between links.
|
|
|
|
We would keep the ntor handshake (but packet based) to extend the circuit.
|
|
|
|
- Fingerprintability
|
|
|
|
Hardware fingerprinting - Able to learn about different Quic implementations because TCP packets are in the clear. In the past we have re-written at each hop- not feasible to require that all clients use the same Quic implementation.
|
|
|
|
|
|
|
|
Experiments:
|
|
|
|
1. Learn what the default drop rate and fairness look like when we run a network to full utilization with a large number of Quic connections
|
|
|
|
2. Tuning those parameters- seeing how the different quic parameters affect that
|
|
|
|
3. Drop side channel- we could simulate the side channel, find out how big it is. how can we decrease the accuracy of the side channel if there is padding that is being dropped at the middle. could we add padding packets that the middle would also handle and add noise?
|
|
|
|
|
|
|
|
Considerations:
|
|
|
|
- Privcount people can tell us about the load on the network
|
|
|
|
- Rob & Aaron - avg active circuit span is ~480sec
|
|
|
|
- Teor: 1.3 billion circuits in 24 hours on Apr 7, 2018
|
|
|
|
|
|
|
|
In parallel with these experiments, we need to solidify the handwavey stuff.
|
|
|
|
- What would our onion crypto look like between hops? Packet numbers exposed there? do we need an IV field for each of those? etc
|
|
|
|
- Also how would this integrate into tor? incompatibilities between links.
|
|
|
|
- What would the upgrade path look like?
|
|
|
|
- Quic library would construct frames, then we would treat them as cells, and then transmit (DTLS would be at the channel level)
|
|
|
|
- Quic would need to be more specialized- we would need each of the pieces of the protocol. how much is tweakable with these libraries? we would then become the maintainer of the library.
|
|
|
|
- Implementation- abstraction layer in the channel is violated everywhere. we would need a real transport layer.
|
|
|
|
- Openssl talks directly to the socket.
|
|
|
|
|
|
|
|
Action items:
|
|
|
|
- Blog post
|
|
|
|
- In order to write this- we need to point people to a topology that we think is a reasonable one to test on. We need to identify a tor-ish topology for people to test on.
|
|
|
|
- We shouldn't dump the channel abstraction (would be needed for DTLS)
|
|
|
|
- We should prepare in the short term for needed abstraction layers. Transport/connection, channel, relay cells framing (how you craft a cell) - all layers of abstraction layers that we need |
