Compare datagram Tor designs

A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and Bjoern A. Zeeb of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/100-tor-spec-udp.txt

7. SHALON: Lightweight Anonymization based on Open Standards by Panchenko et al: http://lorre.uni.lu/~andriy/papers/shalon-icccn09.pdf

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified owner::sjmurdoch priority::medium resolution::implemented severity::normal status::closed tor-relay type::project labels

Trac:
Description: A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and BattleZ of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on five pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

to

A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and BattleZ of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/tor.git/blob/master:/doc/spec/proposals/100-tor-spec-udp.txt

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

Trac:
Description: A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and BattleZ of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/tor.git/blob/master:/doc/spec/proposals/100-tor-spec-udp.txt

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

to

A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and Bjoern A. Zeeb of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/tor.git/blob/master:/doc/spec/proposals/100-tor-spec-udp.txt

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

7. "SHALON: Lightweight Anonymization based on Open Standards" by Panchenko et al http://www-i4.informatik.rwth-aachen.de/~andriy/papers/shalon-icccn09.pdf

pde also points out djb's CurveCP: http://curvecp.org/ which apparently is a TCP-like user-space stack with reasonable congestion control, per-packet confidentiality, and authentication. Wonder if it could play the role of pairwise TCP stacks + link encryption.

Replying to arma:

pde also points out djb's CurveCP: http://curvecp.org/

pde also points to a bit of congestion control explanation for it at http://www.cace-project.eu/downloads/deliverables-y2/CACE_D2.3_M24.pdf

See also Announcing the Release of a Userspace TCP Stack on or-dev 2010-10-26.

Trac:
Points: N/A to N/A
Actualpoints: N/A to N/A
Milestone: Deliverable-Mar2011 to N/A

Trac:
Owner: N/A to sjmurdoch
Status: new to assigned

Trac:
Milestone: N/A to Tor: unspecified

Trac:
Description: A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and Bjoern A. Zeeb of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/tor.git/blob/master:/doc/spec/proposals/100-tor-spec-udp.txt

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

to

A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and Bjoern A. Zeeb of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/100-tor-spec-udp.txt

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

Trac:
Status: assigned to accepted
Description: A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and Bjoern A. Zeeb of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/100-tor-spec-udp.txt

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

to

A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.

We've been talking to Robert Watson and Bjoern A. Zeeb of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.

We really ought to have a better intuition about what we're going to actually do once that stumbling block is resolved.

We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.

We might draw on six pieces of background work for ideas:

1. Joel Reardon's thesis: http://freehaven.net/anonbib/#reardon-thesis

2. The old ZKS designs: http://freehaven.net/anonbib/#freedom2-arch

3. Zach Brown's Cebolla: http://freehaven.net/anonbib/#cebolla http://www.cypherspace.org/cebolla/

4. Camilo Viecco's UDP-Tor design: http://www.petsymposium.org/2008/hotpets/udp-tor.pdf

5. Csaba Kiraly's work: http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf

6. Marc Liberatore's proposal 100: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/100-tor-spec-udp.txt

7. SHALON: Lightweight Anonymization based on Open Standards by Panchenko et al: http://lorre.uni.lu/~andriy/papers/shalon-icccn09.pdf

The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.

Trac:
Summary: Project: design for UDP transport to Project: comparison of datagram tor designs

The work-in-progress document can be found in Git at https://gitweb.torproject.org/sjm217/torspec.git/tree/refs/heads/datagram_comparison:/proposals/ideas/xxx-datagram-comparison.

Periodic snapshots will be put up at http://www.cl.cam.ac.uk/~sjm217/volatile/datagram-comparison.pdf

A good start; I'm interested in seeing how this develops.

Trac:
Type: enhancement to project
Summary: Project: comparison of datagram tor designs to Compare datagram Tor designs

Karsten, is this closeable now that we have a pdf? and maybe time for a new ticket to implement one of the approaches, e.g. the delay-based congestion control approach, and simulate it?

Trac:
Cc: N/A to karsten

Yes, sounds like it's safe to close this ticket now. I'm planning to make project tickets for all sponsor F year 2 deliverables and assign them to sponsor F milestones this week. I'll look out for existing tickets, like a ticket to implement one of the datagram approaches, and either turn them into project tickets or add them as child ticket to a project ticket.

Trac:
Keywords: N/A deleted, tor-relay added