Re: [babel] HMAC routerid->key mappings?

Dave Taht <dave.taht@gmail.com> Sun, 02 December 2018 00:42 UTC

Return-Path: <dave.taht@gmail.com>
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 B74A8130E6B for <babel@ietfa.amsl.com>; Sat, 1 Dec 2018 16:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lqRIMNi4O7cI for <babel@ietfa.amsl.com>; Sat, 1 Dec 2018 16:42:46 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BE9130E68 for <babel@ietf.org>; Sat, 1 Dec 2018 16:42:46 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id y20so10068437qtm.13 for <babel@ietf.org>; Sat, 01 Dec 2018 16:42:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HdxTJCj9H4GqResHgQmkA0D+Y2MRUSLuafNhxpZTCpw=; b=FvHwD4FqUV98IM1RL+6bmNaRTBottd89WbjdST0PAnXHta+nZtMOygzTiEVapSYLLx G/UVygcWOYH0se4Bn2Sg0jW5LrR4u9wMZs6NXjuQkHDaVaIExsW8/GXtZK0wNfjYBI9u StVP5kijgf8sw7giwX2v6A6WS7rtFVdmvbrksJ7ZpzjRpRQzPUpuvDo+rrY+bQv9Bvci 8mU284dzi70o/etW+ZMCuj75Nm1/XHqwbLQEPgjBx1vGWtIGaSeICbFU1h2EIEORQXwl tmAMs9Lp66jdftbAheG3dWa/I7Ds6KMIvKo5v+S3ocb2G9kLOW10h1mM3rAAHIARmrVj /9dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HdxTJCj9H4GqResHgQmkA0D+Y2MRUSLuafNhxpZTCpw=; b=eLIIXRR/+SzCjK8vjUdTsO5Y+k35kR26pDdK6ktRTEFgu8QZfmSrpVpg/DltnRWv+0 I26pQokFWuuy6JdpbYis/MSA3aIiWybpiYRgR9Y49shgVRshtMHk0oly0A5JtyojvdMw +0iWM72hGo144878MJDcUlyrHwsT88Zi/PG18IsijL//wIOHr2ukPZLGqJIg99WPcydT 88EkXQp6GeqUnU31RqIl9Niv5WotVbp86DKK5dqfhi8DhrIytv/yyjwwFgVqq6xF56EL qJpM0/y8vgmRLyB0j2Tk9u2RV3u+qNXnauo4wCGr/7C5gOMJrpErCdLkc3m/DcvTPEzj GXXQ==
X-Gm-Message-State: AA+aEWagxbcFwHCZEBwy80Z9XR3ZwS3yB30mzC8qzMpKb27pULPnE0KB a8j9TvDQANiTI7CAg1xAAr7eoppd6w/e3ZoRF3c=
X-Google-Smtp-Source: AFSGD/V39Ie+U6FnkOtyDL5P5x6m+Xw+xXsq625DtYqIEzfmdQWfzwnCQx6wBizwu9LJawKmHN24BB97UhaKu/iMPDk=
X-Received: by 2002:ac8:5314:: with SMTP id t20mr10458199qtn.328.1543711365030; Sat, 01 Dec 2018 16:42:45 -0800 (PST)
MIME-Version: 1.0
References: <CAA93jw4cO2B8uNiw8_zEHZZrNEDe4zk=W8tvZoQJbRcmpd=Wgw@mail.gmail.com> <87muppf0k0.wl-jch@irif.fr>
In-Reply-To: <87muppf0k0.wl-jch@irif.fr>
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 1 Dec 2018 16:42:32 -0800
Message-ID: <CAA93jw7cS=akrO2pM1EZ8cHKeTGR9X43RkSEhurGULYQ3c3vVQ@mail.gmail.com>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: babel-users <babel-users@lists.alioth.debian.org>, Babel at IETF <babel@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/EL7UphxyKRZmhA1tVqgb5ZEaKHQ>
Subject: Re: [babel] HMAC routerid->key mappings?
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: Sun, 02 Dec 2018 00:42:49 -0000

On Sat, Dec 1, 2018 at 12:34 PM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> > as keys (currently) protect each interface, not each router association...
>
> Correct.  Babel uses both unicast and multicast, and Babel-HMAC is
> designed so that it can protect multicast traffic while remaining immune
> to replay, even in the absence of persistent state or hardware clocks.
>
> > consider, instead a case where you are dropping a bunch of networks
> > into an information interchange (call it "BIX"[1]), where a bunch of
> > networks have agreed to interconnect, over a single "wire", much like
> > how BGP network interchanges work today. Key exchange here, in the BGP
> > world, is on a per-router, not per-interface, basis.
>
> BGP is a unicast-only protocol, hence it can easily use per-peer keys.
>
> > It is unwise to share one key with all interchangers. Co-ordinating a
> > key rollover with that many different entities on that wire is hard.
>
> > Using specific keys instead for each of the A-F, A-G, A-B, etc,
> > associations limits the geometric growth and security vulnerabilities.
>
> The clean solution would be to use a bunch of point-to-point interfaces,
> either by replacing your switch with direct router-to-router links, or by

Would be a rather big switch to replace, so, no, not in this model...

> putting up a bunch of VLANs or GRE tunnels.  Then you can use Babel-HMAC
> unmodified.

Well, an even cleaner solution for that wire would be to be using one
veth per link (or in the case of vms,
dockers, snaps, etc, the virtual interface they present), bridged to
the wire, which is a common deployment model. A vm
is often migrated between machines, and it would just pick up in one
place and resume in another.

Incidentally, "multiple vms bridged to a wire" was my mental model for
setting up a bunch of vms to test interop, simulating various
conditions. I have a standard veth model for simulating delay and
multiple routers for the wifi work also (using namespaces).

Anyway:

The "one interface per key" rule adds complexity but I think it also
brings benefits by requiring such. In such an environment
you'd want to rate limit and observe how much bandwidth is being used
for each interconnect anyway.

Other stats and abstractions fall out of it.

In the case of bridging veths like this, we'd still end up with mcast
hellos hitting the wire, but using unicast
then for everything else, and I'd judge hmacing and discarding those
extra hellos as pretty cheap, although noisy in the log file.

About the only issue I see for an interchange like this is that you'd
also need one ipv4 address per veth, which are kind of scarce.

unless there was a way to do the obscure extended nexthop idea in
https://tools.ietf.org/rfc/rfc5549.txt in babel and linux?

https://www.oreilly.com/library/view/bgp-in-the/9781491983416/ch04.html
goes into it. It makes my brain hurt.

>
> > A) while we can append quite a few HMACs in a hello, at some point,
> > when an interchange's hmacs grows past the size of a packet, we run
> > out of space. What happens? Can we resend that hello with even more
> > HMAC's attached, and win?
>
> Sort of.  However, if there are any plaintext routers on the same link,
> they will parse both packets.

Definitely would not allow any plaintext routers on that wire.

>  I think that Babel should deal fairly well
> with packet duplication, but I'm not sure.

Yea! More things for me to try blowing up!

Has anyone here ever futzed with a fuzzer, btw? This looks good:
http://lcamtuf.coredump.cx/afl/

> But at that point, you might as well use DTLS.

Heh. I would like hmac to stabilize first.

>
> > So if the code (in addition to protecting interfaces) could also (or
> > instead of interfaces) associate keys to routerids, we scale to this
> > scenario.
>
> I'm not going to do that, unless there are any good reasons why you don't
> want to use DTLS in that case.

Look forward to trying it.

>
> > 1) Use BGP instead at large interchanges
>
> Yep.  If your routing tables are relatively stable, BGP is the right choice.

There are many, many, reasons to not want to use another routing
protocol as complicated and difficult to use and configure as BGP in
any scenario smaller than the global scale internet. There's also
source specific routing, which I think is still problematic in any BGP
protocol? I see ISIS in FRR has got it now.

>
> > 2) Use DTLS
>
> Yep.  It supports per-peer keying out of the box.

K.

>
> > 3) Use a minimal number for all associations on an interface scaled to
> > the max size of hello + ihu + hmacs
>
> Not so keen on that -- while the protocol does in principle support
> multiple HMACs, both the amount of overhead and the amount of computation
> go up linearly with the number of HMACs.  It's really not designed for that.

The HMAC benchmarks were promising yesterday. (compared to DTLS!!!!???? )

I guess my mental model about key rollover was pretty different -
where everyone was assuming at most 2 keys, I
was assuming potentially many and key rollovers taking weeks. "dang, I
really need to ask joe to retire that old key, and when does mary get
back from vacation?"

The optimization I had in mind was to enthusiastically sign hellos
with every active key you have, but only sign unicast with the keys
you know are working.

>
> Of course, you could envision using the unicast variant of the protocol
> (the one that rejects all multicast packets except Hellos) and protect
> unicast packets with HMAC instead of DTLS.

That is what works, theoretically, right now, with the existing codebase.

>  But at that point, you might
> just as well use DTLS.
>
> Quite frankly -- just use DTLS, or run HMAC over point-to-point links.
>
> -- Juliusz



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740