Re: Patches (maybe) for proposal 110

[Roger Dingledine <arma@xxxxxxx>]

On Tue, Aug 21, 2007 at 05:43:35PM -0400, Nick Mathewson wrote:
> It looks like the first of these patches introduces the RELAY_EXTEND
> cell type as a server-accepted synonym for the RELAY cell type.
> (RELAY_EXTEND is not my favorite name, since CELL_RELAY_EXTEND will
> get confused with RELAY_COMMAND_EXTEND in casual writing; Roger, maybe
> we should change 110 to name the new type RELAY_EARLY or
> RELAY_EXTEND_OK?  In the rest of this mail, I'll try to call it the
> "special" cell type.)

I like RELAY_EARLY. It specifies how to treat the cell, rather than what
is meant to be in it, which might be handy later on.

>   I don't think that the behavior matches that described in 'phase
>   one' of the proposal: special cells are passed on with the RELAY
>   type, not with their own type.

Right. RELAY_EARLY cells need to be passed on as RELAY_EARLY cells,
and RELAY cells as RELAY cells.

> The second patch mucks with some whitespace in circuitbuild.c, then
> starts adding features so that clients will send as the special cell
> type their first N relay cells on each circuit, where N is chosen
> uniformly at random between 5 and 10.
> 
>   For this patch, I bet we could get the two uint16_ts that you've
>   added to circuit_t down to a single field in origin_circuit_t (how
>   many _more_ RELAY_EARLY cells will we originate?) and a single field
>   in or_circuit_t (how many _more_ cells will we accept before we
>   accept stop accepting RELAY_EARLY cells)?  The fields can be
>   uint8_t, since the limit is well under 255 in both cases.

Plausible.

> The third patch enforces the protocol by:
>     A) Disallowing any RELAY_COMMAND_EXTEND cells without the special
>        cell type, and
>     B) Closing any circuit where too many cells of the special type
>        are sent.
> 
>   Rule B is not quite right: the rule is not "You may send no more
>   than X special cells;" the rule is "special cells may only occur as
>   the first X cells on any circuit."  (See proposal 110, "Design"
>   section, last paragraph.)

Right.

But Nick, also see the 'additional complexity' section. It might be
smart for clients to send the first K of them as relay_early, but for
servers to enforce it by a "no more than K ever" rule. This could give us
more flexibility if we want it later -- I don't think it increases the
damage that can be done via the infinite circuit attack, though sending
a relay_early cell later on would tell everybody in the circuit what
you're up to.

(If we opt for this approach, we may find that RELAY_EARLY is now a bad
name. Hm.)

> Here's a way that we could get the new protocol in faster.  It
> requires that something like proposal 105 is implemented, so that part
> of negotiating a Tor connection is learning which connection protocol
> version the other router supports.  Here goes:

Actually, I had meant for us to be able to do phase 1 and phase 2 quite
close together (e.g. both in the 0.2.0.x timeframe), and it doesn't depend
on proposal 105. Basically, Alice should use a RELAY_EARLY cell when
all the nodes in her path would understand it, and not otherwise. She
has descriptors for all of them, after all, so she's in a fine position
to know when it will work.

--Roger