IETF Logo Mail Archive

Re: [babel] [Babel-users] MAC rekeying in babeld and information model

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 21 January 2020 13:39 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 BBE6D1200CD for <babel@ietfa.amsl.com>; Tue, 21 Jan 2020 05:39:06 -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, SPF_HELO_NONE=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 YFjCgL8DJrRp for <babel@ietfa.amsl.com>; Tue, 21 Jan 2020 05:39:05 -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 344EF1200E5 for <babel@ietf.org>; Tue, 21 Jan 2020 05:39:05 -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=1579613943; bh=03zDlH1HPnDcjlAxq6P8KJ4KHPJdH1tpkyJLeYs0GGI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DbmCBAMpxOEB/dC7NCe1fVFpx5MkL7G2zUTEVYVO9nSF33d+YPOTvWYaWR52UE92C NzNbCi0qSI/AZ2C/KYTCRUlnwA421xOmPCgqxatcSzMv84RdLk3haCJlkiYXjroqef LyB1YuZBYraumMES2CAewwpo2k81w8zyXPYDJbiwWWWW9s8y7BzbZCSlWtYc7/YQ1r JGlUehDtQmofdMYK57w4F7vUvncDrO4NqkpM9ABJasonjE8xw31JNZsys1Bl36jTrv GqQJrHL4sJtLUsf95DWQ85drV4qhLKiJPxOPO0Qre55ntOspDM3ywlSeL21MX2nxxP RqSTS+11ZsNCw==
To: Juliusz Chroboczek <jch@irif.fr>, "STARK, BARBARA H" <bs7652@att.com>
Cc: "'babel-users@lists.alioth.debian.org'" <babel-users@lists.alioth.debian.org>, "'babel@ietf.org'" <babel@ietf.org>
In-Reply-To: <87lfq1nbsu.wl-jch@irif.fr>
References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> <878sm3a8qy.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfq1nbsu.wl-jch@irif.fr>
Date: Tue, 21 Jan 2020 14:39:03 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87v9p5lyiw.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/NvlBuC99p4m3HQixs7q0nFhgzHA>
Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model
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:39:07 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

>>> The second part of my inquiry -- how does the information model enable
>>> incremental deployment?  Section 5 of draft-ietf-babel-mac.
>
>> Incremental deployment is enabled through the interfaces object
>> babel-mac-verify parameter. Set this parameter to false until all
>> routers have key(s). Then set to true.
>
> Ah, ok.  That's fine, then, sorry for missing it.
>
>> I don't think an additional per-interface parameter is needed. I think
>> babel-mac-verify should be fine.
>
> Agreed.
>
>> If the group wants to remove the key-use parameters and only support
>> symmetrical keying, I have no objection. We could also make those
>> parameters optional-to-implement (square brackets), with the expectation
>> that an implementation wouldn't implement them if it only supports
>> symmetric keying.
>
> Shall we wait for Toke to express an opinion?

As I just replied in the other thread: The Bird implementation is going
to have this facility no matter what we specify in the spec, but I'm
fine with having it optional, or omitting it from the spec entirely, as
long as we don't forbid having a key-use parameter :)

-Toke

v2.23.0 | Report a Bug | By Email