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

Juliusz Chroboczek <jch@irif.fr> Sat, 01 December 2018 20:35 UTC

Return-Path: <jch@irif.fr>
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 47723130E5A for <babel@ietfa.amsl.com>; Sat, 1 Dec 2018 12:35:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 YbjLQNDKjwSO for <babel@ietfa.amsl.com>; Sat, 1 Dec 2018 12:35:00 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B4E130E55 for <babel@ietf.org>; Sat, 1 Dec 2018 12:35:00 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wB1KYpvC006037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Dec 2018 21:34:52 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id wB1KYrRp032767; Sat, 1 Dec 2018 21:34:53 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 385174EE2E; Sat, 1 Dec 2018 21:34:58 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id WDCik1FY3Re0; Sat, 1 Dec 2018 21:34:56 +0100 (CET)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 077484EE2C; Sat, 1 Dec 2018 21:34:56 +0100 (CET)
Date: Sat, 01 Dec 2018 21:34:55 +0100
Message-ID: <87muppf0k0.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Dave Taht <dave.taht@gmail.com>
Cc: babel-users <babel-users@lists.alioth.debian.org>, Babel at IETF <babel@ietf.org>
In-Reply-To: <CAA93jw4cO2B8uNiw8_zEHZZrNEDe4zk=W8tvZoQJbRcmpd=Wgw@mail.gmail.com>
References: <CAA93jw4cO2B8uNiw8_zEHZZrNEDe4zk=W8tvZoQJbRcmpd=Wgw@mail.gmail.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 01 Dec 2018 21:34:52 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 01 Dec 2018 21:34:54 +0100 (CET)
X-Miltered: at korolev with ID 5C02F06B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5C02F06D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5C02F06B.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@irif.fr>
X-j-chkmail-Enveloppe: 5C02F06D.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5C02F06B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5C02F06D.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/WiH2rtFFlg_pwgdwAcHoPmmadD4>
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: Sat, 01 Dec 2018 20:35:02 -0000

> 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
putting up a bunch of VLANs or GRE tunnels.  Then you can use Babel-HMAC
unmodified.

> 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.  I think that Babel should deal fairly well
with packet duplication, but I'm not sure.

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

> 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.

> 1) Use BGP instead at large interchanges

Yep.  If your routing tables are relatively stable, BGP is the right choice.

> 2) Use DTLS

Yep.  It supports per-peer keying out of the box.

> 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.

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.  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