Download Improving Tor using a TCP-over-DTLS Tunnel Joel Reardon Ian Goldberg Google Zurich

Improving Tor using a TCP-over-DTLS Tunnel
Joel Reardon
Ian Goldberg
Google Zurich
University of Waterloo
18th USENIX Security Symposium
August 12th, 2009
Tor: Internet anonymity tool
Problem
Tor Network
Tor: circuit construction
Tor: circuit construction
Tor: circuit construction
Tor: circuit construction
Tor
Privacy for usable, low-latency communication.
However it can be slow, and that discourages casual usage.
Where is the observed latency?
Tor’s Datapath
Onion Router
Onion Proxy
Socket
Router
Proxy
Output
Buffer
Datapath
1111
0000
0000
1111
Input
Buffer
Input
Buffer
Output
Buffer
Onion Router
1111
0000
11
00
11
00
1
0
1111
0000
1111
1111Socket0000
0000
Socket
Input
Buffer
Input
Buffer
Output
Buffer
Output
Buffer
Input
Buffer
Router
Server
Output
Buffer
Output buffers do introduce some latency
Output Buffer Size and Latency
(a) Waiting Times over Time
(b) Waiting Times CDF
100
250
80
200
Percentile
Waiting Time (milliseconds)
300
150
60
40
100
20
50
0
0
2
4
6
8
10
0
0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0
Time (min)
Waiting Time (milliseconds)
(c) Buffer Length over Time
(d) Buffer Length CDF
16
100
14
80
10
Percentile
Datalength (KB)
12
8
6
4
60
40
20
2
0
0
2
4
6
Time (min)
8
10
0
0
2
4
6
8
10 12 14 16
Buffer Length (KB)
This occurs when the socket is unwritable
A brief outline of TCP
TCP is designed to reliably send streams of data using packets
Congestion controls throttles sending to maximize throughput
while avoiding packet drops.
Of what are TCP output buffers composed?
Socket Output Buffer Size and Unacknowledged Packets
40
Socket Output Buffer Size (KB)
35
30
25
20
15
10
Socket Output Buffer Size
Unacknowledged Packets
Unwritable Socket
5
0
0
100
200
300
Time (seconds)
400
500
600
TCP Congestion Control (C/C) is to blame.
Tor’s multiplexing of circuits over TCP
OR
OR
a
a
OR
OR
b
a, b
OR
b
OR
If C/C is applied to a, then it is also applied to b
This is suboptimal; TCP is designed to throttle individual
connections based on whether they witness a packet
drop—proportional to their traffic.
An example of cross-circuit interference
Buffer Sizes across Circuits
1.2
1.0
Data (MB)
0.8
0.6
0.4
0.2
0.0
0
100
200
300
400
Time (seconds)
500
600
700
Experiment to observe interference by bulk senders
Delay (ms)
1600
1400
1200
1000
800
600
400
200
0
Circuit Delay
Circuit delay while peer under load
Packet Dropping / Reordering
TCP Stream (over network)
Kernel TCP
Buffered / Waiting
OR
OR
Readable
We want to use a separate TCP connection for each circuit
Concerns for separate TCP connections
Individual TCP streams leak precise information about the size
and rate of data to an adversary
Tor already faces some scalability concerns regarding its clique
topology
Some versions of Windows suffer when opening many TCP
sockets already
Any modification must be backwards compatible with the existing
Tor network
Our novel proposal: a TCP-over-DTLS tunnel
DTLS - a secure (cf. TLS) protocol for transporting datagrams
(UDP sockets)
TCP implementation in user-space is used to generate TCP/IP
packets, which are sent over DTLS
The other end injects the received packet into their user-level
TCP stack, and reads from user-level sockets
How TCP-over-DTLS addresses our issues
IP
TCP
TLS
Application Payload
(a) TCP Tor
IP UDP DTLS
TORTP
Application Payload
(b) TCP−over−DTLS Tor
How TCP-over-DTLS addresses our issues
UDP operates in an unconnected mode, so it accepts packets
from any destination
Each node advertises a UDP socket that multiplexes data for all
connections
The sender is used to demultiplex the proper connection that is
used to decrypt the DTLS payload
Nodes that do not offer a UDP socket will use the existing
transport, assuring backwards compatibility
Packet / Streams translation
Tor Interface
Tor
Processing
UDP
Socket
cell_pack
cell_unpack
DTLS decrypt
DTLS encrypt
User−level TCP
Streams
send()
recv()
Packets
rx()
tx()
TCP
TCP
Buffers Sockets
TCP
Re/Transmit
Thread
How TCP-over-DTLS addresses our issues
UDP Stream (over network)
OR
Kernel UDP
RXed Packets
Readable
m
User TCP
Buffered/Waiting
OR
Readable
Experimental results from our implementation
Circuit latency comparison
Delay (ms)
1600
TCP-over-DTLS Tor
TCP Tor
1400
1200
1000
800
600
400
200
0
Base Delay
Delay under Load
Future Work
Improved Memory Management
Cell Pool
0
1
2
3
4
5
6
7
8
9
10 11
empty list: 2, 5, 9, 4
socket 1’s input buffer: 0, 6, 7
socket 1’s output buffer: 1, 3, 11, 8
cell_t data: 10
Back-propagation of Congestion Window
TCP cwnd=15
actual cwnd=10
data
data
ack, cwnd=10
ack, cwnd=10
TCP cwnd=20
actual cwnd=10
TCP cwnd=10
actual cwnd=10
Summary
We determined that TCP congestion control introduces latency
into Tor’s datapath
We determined that multiplexing circuits over TCP results in the
unfair application of congestion control
We proposed TCP-over-DTLS: a solution to address this issue
that also addresses scalability issues and is backwards compatible
with the existing Tor network
We implemented our proposal and showed it successfully
addressed cross-circuit interference.