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

"STARK, BARBARA H" <bs7652@att.com> Mon, 20 January 2020 16:24 UTC

Return-Path: <bs7652@att.com>
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 222671208B0 for <babel@ietfa.amsl.com>; Mon, 20 Jan 2020 08:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 aDLJV9pccz0B for <babel@ietfa.amsl.com>; Mon, 20 Jan 2020 08:24:05 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E7A981208BC for <babel@ietf.org>; Mon, 20 Jan 2020 08:24:05 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00KGI9rN009354; Mon, 20 Jan 2020 11:24:05 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2xmge6tfdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jan 2020 11:24:04 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00KGO3xa010209; Mon, 20 Jan 2020 11:24:03 -0500
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00KGNwbk010090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jan 2020 11:23:58 -0500
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 1451B400AE37; Mon, 20 Jan 2020 16:23:58 +0000 (GMT)
Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30485.vci.att.com (Service) with ESMTPS id F403C400AE36; Mon, 20 Jan 2020 16:23:57 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Mon, 20 Jan 2020 11:23:57 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Juliusz Chroboczek' <jch@irif.fr>
CC: 'Toke Høiland-Jørgensen' <toke@toke.dk>, "'babel-users@lists.alioth.debian.org'" <babel-users@lists.alioth.debian.org>, "'babel@ietf.org'" <babel@ietf.org>
Thread-Topic: [Babel-users] MAC rekeying in babeld and information model
Thread-Index: AQHVzJ0q8jDHxzeyx0S6Gir5zXgjYKfvDLIA///hz8CAAAgi8IADWLeAgAFttWA=
Date: Mon, 20 Jan 2020 16:23:56 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com>
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>
In-Reply-To: <878sm3a8qy.wl-jch@irif.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.99.207]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-20_07:2020-01-20, 2020-01-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=543 malwarescore=0 impostorscore=0 priorityscore=1501 phishscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 suspectscore=0 adultscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001200136
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/oP_XNVYZvIefRyqqAsccsrOHA0s>
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: Mon, 20 Jan 2020 16:24:12 -0000

> > Since that revision has Boolean (true/false) parameters of
> > babel-key-use-sign and babel-key-use-verify (but not key-use with
> > values of sign/verify/both), I did want to be sure we were talking
> > about the right model revision.
> 
> 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.

> 
> Toke, it would be helpful if we could understand what key-use is intended
> for.  My personal opinion right now is that we should:
> 
>   - remove key-use from the draft;
> 
>   - add a per-interface configuration "allow-unauthentified", which, if set,
>     causes all packets received on that interface to be accepted, whether
>     signed, unsigned, or incorrectly signed.
> 
> Incremental deployment is an important feature, and I think that we need to
> make really sure that the information model allows it.

The key-use-sign and key-use-verify are only peripherally involved in incremental deployment and key rotation -- you need to have at least one key with key-use-verify=true and key-use-sign=true. The common case when incrementally deploying will be to provide a single key with valid and sign = true and all interfaces' babel-mac-verify = false. Once all routers have the key, set babel-mac-verify to true in all routers. When rotating, the common case will be to provide an additional key with valid and sign = true. Once the new key is in all routers, delete old one.

I don't think an additional per-interface parameter is needed. I think babel-mac-verify should be fine. 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.
Barbara