Re: [babel] Purpose of 'generate from/to' and 'accept from/to' for passwords?

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 21 January 2020 13:37 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 0E57A1200CD for <babel@ietfa.amsl.com>; Tue, 21 Jan 2020 05:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.54
X-Spam-Level:
X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 41H-wQ9ydUVK for <babel@ietfa.amsl.com>; Tue, 21 Jan 2020 05:37:39 -0800 (PST)
Received: from mail.toke.dk (unknown [85.204.121.218]) (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 BE38C1200F7 for <babel@ietf.org>; Tue, 21 Jan 2020 05:37:39 -0800 (PST)
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=1579613856; bh=TfR0C2PZoqRYw4ob93olnCrGox8fcTfNkQihFT6nh8k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=C7T1WvA8E16qD45o4V0FXZfFmRaGS+F5iwkhdSFzTE+mMZEKUES0o2Xsg1YigelSX qbp6cLjvHJdOACjgYGeM8ZkQp5zkBMqq+pY7H2nriwnHvA3zMl86Ni7HXKYanLM+k2 sIgZ1LjZplCdOXkr5GJXy1ZQQdGk18HMGgw1l1fQYYXxFGnZXEqK0IL3vM2zAu9gVQ +r9ufpYtHFAAHzUS9or/H2BPe8941IMjjuhjvLbSiHotSl2htdQA8QUCfhYDg+dli1 4WoAr3MlFO8Oe8Yp8ycvD5YnqQ+5nCL3xCLiWpYlBHXpdjVugDk7iK1PVBJYdqG1aH bDhTnK1gHj8cQ==
To: Juliusz Chroboczek <jch@irif.fr>, Ondrej Zajicek <santiago@crfreenet.org>
Cc: bird-users@network.cz, babel@ietf.org
In-Reply-To: <87iml5nabk.wl-jch@irif.fr>
References: <87lfq2nle1.fsf@toke.dk> <20200120190142.GV2475@feanor.crfreenet.org> <87iml5nabk.wl-jch@irif.fr>
Date: Tue, 21 Jan 2020 14:37:35 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87y2u1lylc.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/LP3jW9Fw0JneakeaUesKCzf6WYQ>
Subject: Re: [babel] Purpose of 'generate from/to' and 'accept from/to' for passwords?
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: Tue, 21 Jan 2020 13:37:44 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

> Thanks, Ondrej.
>
>> Well, it is requirement of OSPF spec (RFC 2328). I could assume it could
>> help for smoother key transitions when clocks are not perfectly synchronized.
>
> Ah, I see.
>
> OSPF only allows one key in the trailer, so it needs the ability to send
> one key but accept many.  Babel-MAC allows multiple keys in the trailer,
> and that ability is therefore not required.
>
> Or am I missing something?

No, I think you're right.

> I have no objection to keeping the ability, since it's pretty trivial to
> implement.  No objection to making it optional, since it's not
> particularly useful in Babel-MAC.  No objection to removing it altogether,
> since it's good to avoid unnecessary features.

Well, the Bird implementation (which I really should get around to
finishing) is going to re-use the existing config syntax, so that is
going to implement it in any case. I don't have any strong opinions as
to what the spec should say, as long as it doesn't forbid such an option :)

-Toke