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

Re: [tor-talk] HORNET onion routing design

Hash: SHA512

Jeffrey Burdges wrote:
> I've no read much of the NORNET article, although not yet carefully
> enough, very interesting.
> On Sat, Jul 25, 2015 at 12:21 AM, str4d <str4d@xxxxxxxxxxx> wrote:
>> In this design, I would say the major problems are wasting
>> network resources, and forcing router rotation. There is no way
>> to "cancel" a session other than to let it time out. This means
>> that an attacker can replay packets as rapidly as they want in
>> order to overwhelm the participating routers, effectively DoSing
>> the remote peer (as well as anyone else whose sessions are going
>> through those routers).
>> The participating routers can't do anything, because they are 
>> stateless and the packets they are processing *are* valid. The
>> remote peer *can* detect the replays, but they can't tell the
>> participating routers about it. All that the remote peer can do
>> is drop all packets from that session, select new participants
>> and switch to a new session - - which increases the probability
>> of selecting the adversary's malicious routers. Perhaps the
>> selection process can be constructed to minimize the danger, but
>> that is outside the scope of HORNET's design.
> Yes, sounds highly problematic.  I'd imagine one could add a bloom
> filter for nonces like I2P has though.  It's nolonger zero state,
> but a tiny state you can amortize anyway you like, including not
> checking every packet and peers warning one another.
> It's not clear to me that routers sending an extra 344 bytes is
> better than routers storing only their FS or similar and some route
> identifier.  Would this not depend upon application properties?
> It appears possible to extend NORNET to handle both routes using an
> ADHR and routes that store route information on the servers.
> Applications could select the style of routing themselves.
> Or is there some property of large networks that makes routers
> being stateless inherently better?

If you store the FS locally and have a route identifier, then
essentially you have an I2P tunnel (ignoring differences in the
specifics of the way symmetric onion encryption is handled). Routers
sending the extra 344 bytes _is_ what makes this better for the type
of large-scale network they are proposing - without the stored state
(and associated memory usage and lookup), packet processing is much

But in a real implementation, some kind of replay resistance would be
necessary (probably based on the nonce field in the CHDR), and this
would significantly affect the observed maximum throughput of
93.5Gb/s. Still, I expect it would remain faster than networks that do
store state.


> Jeff

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to