[babel] Purpose of 'generate from/to' and 'accept from/to' for passwords?
Toke Høiland-Jørgensen <toke@toke.dk> Mon, 20 January 2020 16:27 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 2892C1208ED for <babel@ietfa.amsl.com>; Mon, 20 Jan 2020 08:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 ejkVgJqgyVxp for <babel@ietfa.amsl.com>; Mon, 20 Jan 2020 08:27:37 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 AB5101208E3 for <babel@ietf.org>; Mon, 20 Jan 2020 08:27:37 -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=1579537655; bh=ZPN7yxbMOj5lx4NqaxQMxHiAava9QIByhw4cz1VAuFY=; h=From:To:Cc:Subject:Date:From; b=sq86LxisbLjEzy4P/rslxBLgvDZ4EpOoXUz6iNNUFxxc31/7NlRmbljDijeJ0q4BG E1ntPj3zoe4gVCC/Fg239vMKaVLbwhovVjH5QKZrxHKlYr5Hv+6ghhmNFWU8Q+hILe V6UbQpxXmd83Zo4MNhQxwoaUM830cQWrYROCQk5j0bBPagQen/wJmvXAhT2r3eTspx +kig1gLQmK7Pzjgqi6ikSqIeSPxJb8uBljYM+EAeTp+JHZcEP2cC+FFIJJCeIBr/ik DAPM8oHPpqkXIqOJks0+rzUSYQaJRkhcsy7UGSG45lpJ+5ZWIxLwZ1PzYF50bKHF5K UfIL+IMG+x1Mw==
To: bird-users@network.cz
Cc: babel@ietf.org
Date: Mon, 20 Jan 2020 17:27:34 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87lfq2nle1.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/0VPOg8H1gSS14Eh5n5kolZOEUY4>
Subject: [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: Mon, 20 Jan 2020 16:27:42 -0000
Hi Bird people When specifying passwords for protocol authentication in the Bird config, it is possible to specify time windows in which the password will be used to sign messages (the 'generate from/to' configuration options), and a separate time window in which that password will be accepted to authenticate a packet (the 'accept from/to' options). My question is this: What is the purpose of having these two time intervals be separate? I.e., in what deployment scenario is it useful to have a password be accepted to authenticate a message, without also using that password to sign outgoing messages? This question came out of a discussion around whether we should standardise a similar feature in the Babel RFCs. As you can see I'm struggling a little to come up with a definite use case: https://mailarchive.ietf.org/arch/msg/babel/XOahz4fuXXs-nHO4NMGdBwU8AZo -Toke
- [babel] Purpose of 'generate from/to' and 'accept… Toke Høiland-Jørgensen
- Re: [babel] Purpose of 'generate from/to' and 'ac… Ondrej Zajicek
- Re: [babel] Purpose of 'generate from/to' and 'ac… Juliusz Chroboczek
- Re: [babel] Purpose of 'generate from/to' and 'ac… Toke Høiland-Jørgensen