Prop 110 revisions

Wed Sep 5 23:30:40 UTC 2007

Here are three revised patches for proposal 110.  I know that you all still
have to consider rolling out, other possible considerations, etc.  But I
figured I'd make the changes that Nick suggested so they could be
considered.  If there are still issues with these I'd like to know.  And if
it turns out that this would better be set up with the version checking
proposal that's cool too.  Just thought I'd send these along for
consideration (:

Thanks,

Nate

On 8/22/07, mrwigglet <mrwigglet at gmail.com> wrote:
>
> 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/20070905/00ebcc05/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tor_prop110_patch1.patch
Type: text/x-patch
Size: 1044 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070905/00ebcc05/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tor_prop110_patch2.patch
Type: text/x-patch
Size: 5413 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070905/00ebcc05/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tor_prop110_patch3.patch
Type: text/x-patch
Size: 1870 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070905/00ebcc05/attachment-0002.bin>