<pre>Sorry if this starts a new thread, I hadn't yet joined the or-dev list<br>so I couldn't just hit 'reply'. Anyhow, I just have a few questions<br>so that I can hopefully get the patches right for this. Question 1 is
<br>what exactly you guys want the behavior to be, either the way Nick<br>outlines it or the way it is in 'additional complexity'. Second is<br>what the naming should be, RELAY_EARLY or something else. Third question
<br>is about where to put the two fields. Moving the counter for seen<br>extend cells to or_circuit_t is fine, but I'm not sure the other can<br>be moved to origin_circuit_t. The reason is that the only place I <br>
can find that the CELL_RELAY type is set is in relay_send_command_from_edge<br>and the type of circuit in that function is circuit_t not origin_circuit_t.<br>So if you could let me know what way that should be handled that'd be great.
<br>Also, whether or not you guys think this should go along with another<br>proposal (105 or other). Other than these few things I think I know<br>what is needed so hopefully we can work it all out.<br><br>Thanks,<br><br>
Nate<br><br>On Tue, Aug 21, 2007 at 05:43:35PM -0400, Nick Mathewson wrote:<br>> It looks like these patches introduces the RELAY_EXTEND<br>> cell type as a server-accepted synonym for the RELAY cell type.<br>> (RELAY_EXTEND is not my favorite name, since CELL_RELAY_EXTEND will
<br>> get confused with RELAY_COMMAND_EXTEND in casual writing; Roger, maybe<br>> we should change 110 to name the new type RELAY_EARLY or<br>> RELAY_EXTEND_OK? In the rest of this mail, I'll try to call it the
<br>> "special" cell type.)<br><br>I like RELAY_EARLY. It specifies how to treat the cell, rather than what<br>is meant to be in it, which might be handy later on.<br><br>> I don't think that the behavior matches that described in 'phase
<br>> one' of the proposal: special cells are passed on with the RELAY<br>> type, not with their own type.<br><br>Right. RELAY_EARLY cells need to be passed on as RELAY_EARLY cells,<br>and RELAY cells as RELAY cells.
<br><br>> The second patch mucks with some whitespace in circuitbuild.c, then<br>> starts adding features so that clients will send as the special cell<br>> type their first N relay cells on each circuit, where N is chosen
<br>> uniformly at random between 5 and 10.<br>> <br>> For this patch, I bet we could get the two uint16_ts that you've<br>> added to circuit_t down to a single field in origin_circuit_t (how<br>> many _more_ RELAY_EARLY cells will we originate?) and a single field
<br>> in or_circuit_t (how many _more_ cells will we accept before we<br>> accept stop accepting RELAY_EARLY cells)? The fields can be<br>> uint8_t, since the limit is well under 255 in both cases.<br><br>
Plausible.<br><br>> The third patch enforces the protocol by:<br>> A) Disallowing any RELAY_COMMAND_EXTEND cells without the special<br>> cell type, and<br>> B) Closing any circuit where too many cells of the special type
<br>> are sent.<br>> <br>> Rule B is not quite right: the rule is not "You may send no more<br>> than X special cells;" the rule is "special cells may only occur as<br>> the first X cells on any circuit." (See proposal 110, "Design"
<br>> section, last paragraph.)<br><br>Right.<br><br>But Nick, also see the 'additional complexity' section. It might be<br>smart for clients to send the first K of them as relay_early, but for<br>servers to enforce it by a "no more than K ever" rule. This could give us
<br>more flexibility if we want it later -- I don't think it increases the<br>damage that can be done via the infinite circuit attack, though sending<br>a relay_early cell later on would tell everybody in the circuit what
<br>you're up to.<br><br>(If we opt for this approach, we may find that RELAY_EARLY is now a bad<br>name. Hm.)<br><br>> Here's a way that we could get the new protocol in faster. It<br>> requires that something like proposal 105 is implemented, so that part
<br>> of negotiating a Tor connection is learning which connection protocol<br>> version the other router supports. Here goes:<br><br>Actually, I had meant for us to be able to do phase 1 and phase 2 quite<br>close together (
e.g. both in the 0.2.0.x timeframe), and it doesn't depend<br>on proposal 105. Basically, Alice should use a RELAY_EARLY cell when<br>all the nodes in her path would understand it, and not otherwise. She<br>has descriptors for all of them, after all, so she's in a fine position
<br>to know when it will work.<br><br>--Roger</pre>