[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: flow control questions



On Sun, Jan 28, 2007 at 10:10:50AM -0800, Christian Seberino wrote:
> Hello Again Tor-landers!

Sorry about the delay; stuff has been tremendously hectic.  It's
entirely possible that you've figured out the answers to your
questions by now without me, but in case you're still waiting on this,
here goes...

> I'm running out of things to ask because the Tor docs are pretty good
> overall!
> I'm pretty sure about the answers to some of the question below.  I just
> wanted to verify I didn't goof somewhere....
> 
> So basically ORs have a a limit on number of Relay Data cells they are
> willing to send down/up the circuit in **each direction**?

Not quite.  These windows apply to the number of cells that the OR
will create (package from a local stream and send along a circuit) or
consume (receive from a circuit and relay to a local stream).  They
don't apply to the number of cells that the OR will relay for other
ORs.

> It appears, when an OR can send more cells, it sends a RELAY_SENDME to OP
> which may respond with another RELAY_SENDME back to OR right?  Do BOTH of
> these RELAY_SENDMEs cause (both?) the OR's windows to increase (by
> 100)?

"SENDME" means "Send Me".  If I'm an OR, and I send you a SENDME cell,
it means that you should increase the window of cells that you are
willing to send _me_ by 100.  If I _get_ a SENDME cell from _you_ it
means that _I_ should increase the window of cells that I'm willing to
send you by 100.

Let's consider an extreme case, where there is a circuit between Alice
(a Tor client) and Bob (an exit server), and all of the data on the
circuit is flowing from Alice to Bob.  [There are 2 other ORs involved
in the circuit, but because they neither originate nor consume relay
cells, they don't matter.]  Both parties will keep track of two
windows: how many relay cells Alice is willing to receive, and how
many relay cells Bob is willing to receive.  Both windows start at
1000 cells.

Every time Alice sends a relay cell to Bob, she notes that Bob's
receive window has fallen by 1.  Every time Bob gets a relay cell
along the circuit from Alice, he notes that his receive window has
fallen by 1.  When Bob notes that his window has fallen to 900, he
sends a RELAY_SENDME cell Back up the circuit to Alice, and increments
his receive window by 100.  When Alice gets it, she increments her
view of Bob's receive window by 100.

But since (in this example) Alice never receives any data relay cells
from Bob, Alice's receive window never falls below its original 1000.
Therefore, Alice never needs to send Bob a relay cell at all.

> So ORs have freedom to send out tons of RELAY_SENDMEs to increase its
> windows?   So OPs have freedom to send out tons of RELAY_SENDMEs to
> increase OR  windows?  Then why aren't windows vulnerable to attack since
> both ORs and OPs can just pump out more RELAY_SENDMEs to increase windows
> whenever they want?  What prevents manipulation?

This is a flow control mechanism, not a DOS-prevention mechanism.  If
Alice or Bob wants to DOS the network, there are plenty of easier and
more effective ways for them to do it.

(Yes, they could increase their receive window a lot, and cause
intermediate ORs to get swamped with a ton of cells along a given
circuit.  We could prevent this by saying that no OR need ever queue
more than a certain number of cells on a given circuit, but see
above: there are easier ways to abuse the network.)

yrs,
-- 
Nick Mathewson

Attachment: pgpyBVkKJfaBR.pgp
Description: PGP signature