[tor-dev] Reg : using the keep alive messages

[Sambuddho Chakravarty]

Dear Roger
 Thanks for your response. I read the spec document about the RELAY_DROP
cells. You say that no one has understood the passive correlation attack to
utilize the RELAY_DROP cells. I am however little curious to see if
"moderate padding" (enough to not mess up QoS of various services) can be
used to prevent some of the attacks that rely on parameters such as OWD ,
RTT and B/W variation to link relays that are being used in a circuit. I am
curious from the practical point of view of exploring such padding to
prevent our bandwidth based confirmation attack or the M&D attack (and its
2009 variant) .

Thanks
Sambuddho

On Thu, Jun 9, 2011 at 12:29 PM, Roger Dingledine <arma at mit.edu> wrote:

> On Wed, Jun 08, 2011 at 08:11:58PM -0400, Sambuddho Chakravarty wrote:
> > Hi All
> > I read in the Tor design spec that Tor control protocol supports
> keepalive
> > messages which could be used for link padding . I wonder if anyone has
> ever
> > explored using them...
>
> I don't think you mean the Tor control protocol. There's no need to pad
> that connection (or if there is, you've screwed up badly somewhere else).
>
> The Tor protocol supports PADDING cells -- see sec 3 of tor-spec.txt:
>
>   PADDING cells are currently used to implement connection keepalive.
>   If there is no other traffic, ORs and OPs send one another a PADDING
>   cell every few minutes.
>
> There's also a DROP relay cell. While PADDING cells can only be sent to
> the adjacent relay, the client can send DROP cells to any relay on her
> circuit, and any relay on the circuit can inject DROP cells to the client.
> See also sec 7.2 of tor-spec.
>
> But that said, I think the answer to your question is no. AFAIK nobody
> has understood passive correlation attacks well enough to get to the
> "if I change the design like this, does the attack work less well"
> research stage.
>
> --Roger
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110609/91685c1d/attachment.htm>