Prop 110 revisions

[mrwigglet]

Sorry if this starts a new thread, I hadn't yet joined the or-dev list
so I couldn't just hit 'reply'.  Anyhow, I just have a few questions
so that I can hopefully get the patches right for this.  Question 1 is
what exactly you guys want the behavior to be, either the way Nick
outlines it or the way it is in 'additional complexity'.  Second is
what the naming should be, RELAY_EARLY or something else.  Third question
is about where to put the two fields.  Moving the counter for seen
extend cells to or_circuit_t is fine, but I'm not sure the other can
be moved to origin_circuit_t.  The reason is that the only place I
can find that the CELL_RELAY type is set is in relay_send_command_from_edge
and the type of circuit in that function is circuit_t not origin_circuit_t.
So if you could let me know what way that should be handled that'd be great.
Also, whether or not you guys think this should go along with another
proposal (105 or other).  Other than these few things I think I know
what is needed so hopefully we can work it all out.

Thanks,

Nate

On Tue, Aug 21, 2007 at 05:43:35PM -0400, Nick Mathewson wrote:
> It looks like 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070822/8da30ca8/attachment.htm>