Re: : Export END_CIRC_REASON_* to controler

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Nick Mathewson (nickm@xxxxxxxxxxxxx):

> I couldn't use all of it, since this isn't right:
> 
> > +      /* Prevent arbitrary destroys from going unnoticed by controller */
> > +      if(reason == END_CIRC_AT_ORIGIN ||
> > +              reason == END_CIRC_REASON_NONE ||
> > +              reason == END_CIRC_REASON_REQUESTED) {
> > +        reason = END_CIRC_REASON_OR_CONN_CLOSED;
> 
> According to tor-spec.txt, OR_CONN_CLOSED means:
> 
>      8 -- OR_CONN_CLOSED  (The OR connection that was carrying this
>                            circuit died.)
> 
> But the code above is called when we get a DESTROY cell, and destroys
> only tear down a single circuit, not the whole connection.
> 
> Probably, we should define more reasons; see some of the comments I
> did for the patch in r8672 for other reasons that don't match up with
> what the spec seems to say.

Yeah agreed, I'm all for adding more. I saw your comments about
timeout reason, and was thinking the same thing. But I do think that
giving this circumstance in particular a special reason is important.

One issue I would like to guard against/watch for is an adversary
destroying circuits if they do not detect one of their colluders at
each end.  Adversaries doing this would be able to ensure that the
only time they waste bandwidth on a connection is if they know they
are able to determine its origin, thus gaining an advantage over the
expected rate of O((c/n)^2).

For the scanner to detect this, there shouldn't be any way a node can
make us mistake a malicious closure from one that should happen
normally (ie was requested by us). Taking the reason right from the
wire enables a node to do this.


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs