Re: [babel] [Babel-users] rather than ripemd160...

Dave Taht <dave@taht.net> Wed, 28 November 2018 16:51 UTC

Return-Path: <dave@taht.net>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A59130E27 for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 08:51:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjIOpWahXa1R for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 08:51:30 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADACB130E72 for <babel@ietf.org>; Wed, 28 Nov 2018 08:51:29 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id B8781221E9; Wed, 28 Nov 2018 16:51:27 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>, babel-users@lists.alioth.debian.org, babel@ietf.org
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <CAPDSy+5QDu_kW-f=JWO1cPJJnDwDNpVwxwVC9SxfcE5+EOMpRg@mail.gmail.com> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr>
Date: Wed, 28 Nov 2018 08:51:16 -0800
In-Reply-To: <875zwhxv28.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 28 Nov 2018 13:09:35 +0100")
Message-ID: <8736rl16yj.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/4kQYIPE8-nIOfG5iJEkOyqpcTmg>
Subject: Re: [babel] [Babel-users] rather than ripemd160...
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2018 16:51:32 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

>> Why not? If it's not MTI you risk the case where you get to pick between
>> "good performance on weak devices" and "interoperability with RFC-only
>> implementations".
>
> Is there any evidence that there are devices that can reasonably run Babel
> and that are too weak to use SHA256 for protecting control traffic?
>
> I don't have an ARM device handy right now, but a 450MHz MIPS 24Kc is able
> to SHA256 on the order of 16MB/s.  That's 10000 full-size frames per second,
> or on the order of 600000 Babel updates per second.

Sigh. Benchmarks. In particular I loathe benchmarks that do just one
small thing repeatedly, fully in i and dcache and claim "that's how fast
it is". No, you go and measure the impact on the total system, under a
real workload, changing whether you have hmac on or off, to draw a conclusion.

In the crypto case especially, people are really fond of 
large block sizes, and not fond of showing lots of very small
ones. startup overhead can be significant. It takes a really long time
to sha1 one byte.

Hardware crypto offloads for packets, from userspace, as another
example, are generally a lose, due to the kernel/userspace transition
required.

Lastly...

Routers *are* doing other things besides exchanging routes, like moving
packets around and dns, dhcp, and so on. Complex systems have emergent
properties that don't show up without "all up testing", which often
results in "RUD" - rapid unscheduled dissassembly. 

I already showed with the rtod experiments that a sufficient number of
routes can disable the dns and dhcp daemons, on a low end router.

Your typical low end router forwards packets until it runs out of cpu,
which is usually well below line rate. Processing packets locally eats
even more cpu.

We also tried in the last battlemesh we went at, to coax those trying to
measure convergence times to also measure them under heavy load. I don't
know if toke's preso on the second+ long delays that network experienced
fully registered (but we went off and fixed wifi regardless). I would
rather like to make battlemesh this year... with working hmac, unicast,
kick-arse wifi, and other whizbang new features and bugfixes.

...

I'm trying to redteam these ideas. If a given attacker hits me with
10,000 babel packets a second, unauthed, do I die? If I try valiantly to
verify these packets and fail, do I die sooner? If I figure out I'm
under attack from this particular box, can I blackhole all/most its packets
and move on, and not die at all? (RRL in bind is an example)

And honestly, all I'm pushing for at the moment is a way to do key
rotation, and it would be good to be able to have two algorithms to
evaluate. 

>
> My suggestion is to implement whatever the list recommends (Blake2B or 2S)
> in both BIRD and babeld, but to keep the status quo (SHA256 is MTI) in the spec.

I can live with that, but would prefer to have running code to deploy at
some scale, and measure.

> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users