Re: [babel] Unicast Hellos?

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 30 May 2017 14:50 UTC

Return-Path: <toke@toke.dk>
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 05854129564 for <babel@ietfa.amsl.com>; Tue, 30 May 2017 07:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=toke.dk
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 yRSQchGsq7uj for <babel@ietfa.amsl.com>; Tue, 30 May 2017 07:50:44 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 2C5FE12955F for <babel@ietf.org>; Tue, 30 May 2017 07:50:44 -0700 (PDT)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1496155840; bh=XsOfb6G7yAjTcooNkxSqYRHuPy3kOQy+vPWWPVe8ZTI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=quHU8v+JBavjPpjpjIqefRcmFHqj4BpHiWITBlzvB6OhcCu5SkIm9dSY0bY/i3joi +FseMgQxonWDnu8WfqXl3Uo7DKds6kKcK6trtA2CFjzYqZiYc0AkZ9GRLI/k8ysHst L5hcrQQt627tXL930CyrZdQafk8uCJu8SPMx/zEmgzjMc0gjds4pdfTc0ActSJBIUr k82bu/OWuxPl/mNa03HKwqhIVqE01qW8mNzVAR8/VX9DEGcGuz6R2QxWaCJh21i1Tx 4PppZ9MhTVlXNRjS6pc6NWk91TJf/P/1wASiO1EHAo6Wr2we6rB7FGXJKeCaFoBGwf b68KVJIjlqDkQ==
To: justin kilpatrick <kilpatrickjustin@gmail.com>
Cc: babel@ietf.org, Juliusz Chroboczek <jch@irif.fr>
References: <87bmqck6sp.wl-jch@irif.fr> <874lw3apnn.fsf@alrua-kau> <87shjnomkl.wl-jch@irif.fr> <87vaoj95qm.fsf@alrua-kau> <CANhjow_v0rDwRoS0mSRat9R0cxTmxQeTb6Yf1O=KoVMUwhA=3g@mail.gmail.com> <87wp8yfu3z.fsf@alrua-x1> <CABdbigx5XSg4vqDcYWQ7NXMY=eA0yw6s511wKKTLTP7ZNuDKoQ@mail.gmail.com> <87d1aqfnhg.fsf@alrua-x1> <CABdbigzvYjTASPi-440wfqko7K6vykK81j0eQWmGjAGQLRwB4w@mail.gmail.com>
Date: Tue, 30 May 2017 16:50:38 +0200
In-Reply-To: <CABdbigzvYjTASPi-440wfqko7K6vykK81j0eQWmGjAGQLRwB4w@mail.gmail.com> (justin kilpatrick's message of "Tue, 30 May 2017 10:27:02 -0400")
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87inkibdq9.fsf@alrua-kau>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/vrymKAe9s4aVDB_ayRa3W5Ac_Mc>
Subject: Re: [babel] Unicast Hellos?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 30 May 2017 14:50:46 -0000

justin kilpatrick <kilpatrickjustin@gmail.com> writes:

> On Tue, May 30, 2017 at 10:06 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> justin kilpatrick <kilpatrickjustin@gmail.com> writes:
>>
>> Ah, right, so this is supposed to be in addition to the normal hello
>> mechanism?
>
> In our case yes, we need some of the same security properties to make
> sure this packet can go multiple hops and be secure on the other end.
> So that's a good place to share effort. We may end up having to modify
> some of the metric calculation code too so that we can compute roughly
> equal numbers by communicating directly with a remote node as the
> network should produce by the 'normal' method of route distribution.
>
> We want to verify some but not all remote routes and use that to rank
> neighbors by how many of their routes are trustworthy. A sort of local
> reputation system that we outline here [0].

Right, I see. I assume you'll need some kind of end-to-end verification
in this case, as you're basically trying to protect against malicious
transit nodes (that could just alter the multi-hop hello/IHUs); how are
you going to do that?

Also, from reading the description it was not clear to me exactly what a
"destination" is? If a gateway advertises a prefix (say
2001:db8:100::/64), which address is a node supposed to send its
multi-hop hello to?

>> Both of these use cases requires a replacement for multicast hellos, but
>> I was not envisioning them being multihop.
>
> If you don't need multihop functionality you can just remove the
> custom flush function. The normal unicast flush function will just
> send the packet to the neighbor address.

I'm developing an independent implementation of Babel (in the Bird
routing daemon), so I try not to look at the babeld code; and so I
didn't read your code. But from the white paper, it seems your unicast
hello is something separate from the unicast version of the normal hello
that we have been discussing. I.e., they should have separate TLV
numbers, no?

-Toke