Delivery-Date: Sat, 25 Jul 2015 11:12:10 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id D3E0B1E054F;
	Sat, 25 Jul 2015 11:12:08 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2E70F36809;
	Sat, 25 Jul 2015 15:12:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 35AEE367F2
 for <tor-talk@lists.torproject.org>; Sat, 25 Jul 2015 15:11:59 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id iA9znP_-hJKK for <tor-talk@lists.torproject.org>;
 Sat, 25 Jul 2015 15:11:59 +0000 (UTC)
Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.sigterm.no", Issuer "RapidSSL SHA256 CA - G3" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id D13E7366EA
 for <tor-talk@lists.torproject.org>; Sat, 25 Jul 2015 15:11:58 +0000 (UTC)
Received: from smtp.postman.i2p (unknown [193.150.121.26])
 by postman.meeh.i2p (Postfix) with ESMTP id 7CC002E42FA
 for <tor-talk@lists.torproject.org>; Sat, 25 Jul 2015 17:11:52 +0200 (CEST)
X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d <str4d@i2pmail.org>
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <20150722233616.GY15647@mail2.eff.org>
 <20150723093849.388EFAE462@smtp.postman.i2p>
 <20150724005935.C0F38AE461@smtp.postman.i2p>
 <20150724164909.258A3AE460@smtp.postman.i2p>
 <20150725002108.15EF4AE464@smtp.postman.i2p>
 <20150725085106.86705AE464@smtp.postman.i2p>
In-Reply-To: <20150725085106.86705AE464@smtp.postman.i2p>
Message-Id: <20150725123046.67ED0AE467@smtp.postman.i2p>
Date: Sat, 25 Jul 2015 12:30:46 +0000 (UTC)
Subject: Re: [tor-talk] HORNET onion routing design
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

-----BEGIN PGP SIGNED MESSAGE-----
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@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?

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.

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.

str4d

> 
> Jeff
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVs4FrAAoJEBO17ljAn7PgfFMP/0RCe/ZWhzpZza6mjhWCXZQY
Y+A21MIKPxxXlNwUIIpUZdQFXHrZGLYn0a2iXTXgwNwrSFHdWO6fb9W7i3e5Ztzg
GSYfBT1TOVsY71aeH/0GfJqM0TvL6vTmh/jIeKx2pjIs1p155TncAi47SppV2Gdw
YC9lWfFIHoFjzfMptRDVy4Lh59DOzaJ6geCGCIZ6UnDS7CYu0AErsG6mziEFzQjj
1EL4gkloKgX4WcFCHL8V+0ES2928HwMibVW67MTPh1c7myAR7srt+8NPaRgvm1P7
dnaLSg/zUh8KvS7mKHkRz/gE2D487E9adglcZjwTAuDHCoRWlGfyAc3A8CNQPKCD
PyTgS41kmjH9gcGKeaMW3HVHZZOu2fmI3O3hs8Wc6zZJhlM2UyqJzEXD+COJrE15
ddUopdxKRLN1CjjeC7/kEfv9PaRBLGFNQQspb9YkpjqR7wy2VZ10+dVwqrOjND7j
61nlXszhA4fIjffNRpLbsIqHR/UAoZeMGHO0YnYNPrH1K8KK/FuLaIXFqbWaWsa0
03AbR9c6Ko2dQpMuyB647dIdTeMDnRhXRXS+NO1VOEO4c/GFMXnK8PXHQjwnODcB
z8APm7Iti1r1YAzLck87Pch8yR5f/7QQdCaHnM1B0FurQcmAtTDezuLV+wQ8oX21
mmdVTGRkmA3pAKxM7pDX
=aYBR
-----END PGP SIGNATURE-----
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

