[tor-talk] HORNET onion routing design

[Jeffrey Burdges]

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 at i2pmail.org> 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?

Jeff