Fwd: [p2p-hackers] For fans of datagram

[Adam Langley]

On 9/5/05, Nick Mathewson <nickm at freehaven.net> wrote:
> {BTW, this conversation really belongs on or-dev.  Any objection to
> taking it there?}

Nope, I'll forward some context afterward too.

> Right, and thanks for the excellent analysis.  I'd suggest that others
> might want to also want to check out section 4.1 of our "Challenges"
> paper draft at
>      http://tor.eff.org/cvs/doc/design-paper/challenges.pdf
> which describes some more problems with moving from a stream-based to
> a packet-based design.

Stream-based against packet-based is a different balance than
transport-the-packets against transport-the-data. At the moment we
transport the data (not the packets) over a stream based internode
transport. I'm not saying that a switch to transport-the-packets would
be a good thing (I believe the opposite), but a switch to a datagram
protocol.

Section 4.1 of that PDF seems to be considering the problems of a
transport-the-packets design. A transport-the-data with datagram
internode transport would eliminate points 1, 2, 3, 6 and 7. To answer
the rest:
  4) "The crypto is unspecified" -> DTLS
  5) "We'll still need to tune network parameters" -> yes, and this
means it would take a lot of reimplementing-tcp work.

> > As for the how we are looking at something like:
> >
> > IP / UDP / CC&GSD layer / DTLS
> >
> > (CC = congestion control, GSD = guaranteed single delivery)
> >
> > We could put DTLS under the CC layer, but that would mean extra
> > encryption for retransmissions and ACKs etc. At the moment we don't
> > protect our connection-metadata (the TCP header) and, unless someone
> > sees an advantage, I don't see that we should start doing so.
> 
> I'd need to see more of a design here to see what you're really doing
> before I could answer with any confidence.  Do you have anything written
> you could send a pointer to?

That would be the sum total of what I've written on it ;)

> In particular, you have a problem with cells from UDP circuits vs
> cells from TCP circuits.  Only TCP cells should get GSD, or else all
> hell will break loose.  But if encryption happens once per cell, then
> TCP-carrying cells would become distinguishable from UDP-carrying
> cells, since the latter would never get retransmitted.

Certainly GSD cannot be applied to UDP data (which is one of the
reasons that AirHook doesn't work). Your point about the difference
between GSD and non-GSD packets is well taken and would suggest that
DTLS /should/ be put under the CC&GSD layer to protect that metadata.

> Still, the design you have in mind may not have this flaw.

it did ;)


> > We need per-circuit flow control between directly connected nodes.

> It does have the problem of making congestion-based path detection
> even easier, though.

Consider the case where a user is downloading a large file, from a
webserver, using Tor. At the moment one could observe the Tor to user
data rates while attacking nodes to try and find a correlation between
attacking a node and impacting the data rate.

With per-circuit flow control I believe that the only difference is
that this observation could be carried out on the webserver to exit
node connection too. Without flow control there is no back pressure,
so attacking a down-circuit node has no effect on the exit node's TCP
connection to the web server. With flow control that connection would
show an effect from the down-circuit attack.

I don't have any good sense of how important that is. The flip side of
flow control would be lower memory usage on nodes and fewer dropped
connections. Someone else's call.

> Right.  DCCP is hard enough to find and deploy that we might need to
> consider a dual-moded OR connection protocol: try DCCP if both sides
> support it, and fall back to TCP if it doesn't work.

DCCP is *so* rare that I've never seen it running anywhere. The RFC is
still in draft. Honestly I don't think that it will ever work well
because there are so many firewalls and NATs which won't be able to
deal with it.

Also, a dual mode operation adds a lot of complexity.


AGL

-- 
Adam Langley                                      agl at imperialviolet.org
http://www.imperialviolet.org                       (+44) (0)7906 332512
PGP: 9113   256A   CC0F   71A6   4C84   5087   CDA5   52DF   2CB6   3D60