[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] HORNET onion routing design
On Sat, Jul 25, 2015 at 12:30 PM, str4d <str4d@xxxxxxxxxxx> wrote:
> 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
> faster.
>
Yeah, I've understood the difference now :
- Sending the full AHDR costs O(m^2) where m is the length of the
route/circuit.
- Doing local look ups costs at most O(n log n), maybe less, but the n is
the number of clients using the router.
It doesn't matter that even the constant on the first line is much higher
too, being bandwidth, because m is bounded and n grows.
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.
>
Appears there is no need to change the protocol to address this though.
It's an orthogonal problem to amortize those checks better as the network
grows using bloom filters, spot checks, warnings between routers, etc.
Jeff
p.s. Appears NORNET routers could tag the FSes they issue to connect
packets that lie in the same (directed) circuit. It'd be an interesting
exercise to prevent this.
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk