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

[Sambuddho Chakravarty]

 Which is the relevant part of the that should I look into for injecting
such cells in streams ?

Thanks
Sambuddho


On Thu, Jun 9, 2011 at 3:03 PM, Sambuddho Chakravarty
<sc2516 at columbia.edu>wrote:

> 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/20110624/7c07c083/attachment.htm>