Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers

tom petch <ietfa@btconnect.com> Wed, 24 February 2021 10:42 UTC

Return-Path: <ietfa@btconnect.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D567C3A138D; Wed, 24 Feb 2021 02:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 3FirjRGeSS8J; Wed, 24 Feb 2021 02:42:25 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80127.outbound.protection.outlook.com [40.107.8.127]) (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 C06B93A1388; Wed, 24 Feb 2021 02:42:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lyVvuEZgx8cZTvRFKrlm7T8eNzKMfDITfW8XAr4xCM8P4uvR+U9ikNN6rDhxtDdBGZNCwkJdfhbOuH5BbL9H351N181Q66My+1LM15VvVPxu8HHWu3oklxURDf1XY9vw1daxHD3dQSP0rkyFoOovh4YAZrWubGRgFEKowr4EvwTAlCM+7guyE+9QXHZfyU/RUJvoFMEZ/E8eZ9a4hsZGZGa6/ke3T615C7fWTvL6Hk5FRzzwRKvA3XIqNakLgAkN7Q8DLdiOPknyoHgcxUaz0EZlDP3b1pdSKrPwZ/uxvb9IX7Q8HxXoZBAaPrwIc9PEGKVkJwkqWT+zo6uJNJ3C1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HGQjcEFHr4bgpfW0jMAF+fCYP2X0PSJlVgp/LvRnY3I=; b=PWgsSHDttdybWmjzV3xq7U6osQzIeqOZw8gS63XFjFEzksMog3esMTpZeOy++yCYATp7vgyo8/MtpyZuQHCR48k+7XzxoQtxPBWJssGDuiUL++w/rq4+tKB39edPsSOR1wgmVC9+rU+X2KgNfIKaZDN/Pp6yHuaEqjnzhY0hZ6VL8sw4lnW/3kyN1f8BfXefjTmtA7TfPA/JSbdvFn8DnRyf8arRQh38q8ofqfGUAKV1J1AKUwA+eDCCpZMH0YEY5K1K5awet6TjzcQluknLEfho0GVP00dTK1346CoC84XFJrNu6mCwbKbf1xMoHCQcMUJZxA9+DBV59xg/UwpwEA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HGQjcEFHr4bgpfW0jMAF+fCYP2X0PSJlVgp/LvRnY3I=; b=hBMHxGNuylam71QxcBxU/jH8CTb58zJ8JWiaSTPdZKeCDsXeLHt+VoYAhupixZrvgFYxIHUpfqi8FYN43Eb7OExwxM496xZPbzghyBbKk355CSe9wdAY15PEYiEW9VvF1EQqbZ57JkgBgMOB7jgBC0u4MGRkSnoMlEUBHZ+EoDE=
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by DB6PR0701MB2888.eurprd07.prod.outlook.com (2603:10a6:4:71::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Wed, 24 Feb 2021 10:42:22 +0000
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::e079:baec:373c:824f]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::e079:baec:373c:824f%7]) with mapi id 15.20.3890.014; Wed, 24 Feb 2021 10:42:22 +0000
From: tom petch <ietfa@btconnect.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Reshad Rehman <reshad@yahoo.com>, Jeffrey Haas <jhaas@pfrc.org>
CC: "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-secure-sequence-numbers@ietf.org" <draft-ietf-bfd-secure-sequence-numbers@ietf.org>
Subject: Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers
Thread-Topic: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers
Thread-Index: AQHXCh8ArO+M5MTrXUuTjEr8rm9J1apnHRsd
Date: Wed, 24 Feb 2021 10:42:22 +0000
Message-ID: <DB7PR07MB5546592E043B8B39069A19FDA29F9@DB7PR07MB5546.eurprd07.prod.outlook.com>
References: <1995CE5F-4996-4C2B-9BFE-B3DC56511CC0@gmail.com>
In-Reply-To: <1995CE5F-4996-4C2B-9BFE-B3DC56511CC0@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.146.121.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b84a279e-dfc7-4262-ea72-08d8d8b0dde6
x-ms-traffictypediagnostic: DB6PR0701MB2888:
x-microsoft-antispam-prvs: <DB6PR0701MB28885E4B61E3E392E847F5C7A29F9@DB6PR0701MB2888.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UVTSi89lKDJeQEw3wbANG2BuZN7L9Bc9YF1tTP6kdsu0YpvUt5M14wtqjijtJc2/pEsB2sRIgeA15RjsIHTTWMR/4ExwdVkXB6m3EYrTSYPSBWeeYHQHgMOUIVU+qcKQd7myQp+V/yNXNdEiZKOCMyyO8h8Hhz6OkHEmOwqWKVMSK1tp2vHNAzPfTK58DWNSbmJEATgIOIrZS1a3xlekYQo3LZMyRR/Ibmz6mNtxeSR1AsIFopb0OsUZLC/fcJtn1ev14WdYIYFc21VFBEo8vBsRwBRpw1BsWtSlA5NHputVMOisWohntdRaXGPR63hg3B3OiVrXLs/4o13FbWhAY1jVc0t+nGBzQKBi1gs08RBWRGv59i4Mvs9ksvPWkYbh8upn2FeO2mhTafgm/FzMsym95qr7MHbDdcUBYGDGoGBiIpt9PyX2wY5jxDMUvfF0ILz+427PwFgK/9CRzxDnLS1ceSMRiTquVdcRDtV/O59MJBCtph9z/LS4jABoRc8GP+Pa7cURrLXRgH9HT/RUpQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(39860400002)(376002)(366004)(396003)(66616009)(66946007)(66446008)(66556008)(64756008)(66476007)(86362001)(76116006)(71200400001)(8676002)(186003)(26005)(4326008)(8936002)(91956017)(7696005)(6506007)(33656002)(55016002)(9686003)(5660300002)(52536014)(83380400001)(478600001)(54906003)(99936003)(2906002)(316002)(110136005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?6i4JzvZMtQ9Fhr9+o2gUTNZcjFjYLGAjejgbqtmDsiLegLev3VpxS+52?= =?Windows-1252?Q?BOcwPqcr4+P3TVKmqDG8dmud80J0WQr5EV4KtS+zQ0Uautg0kLRGELjc?= =?Windows-1252?Q?ilHDwyWuGmP1dxhlcF97A9pkLTf+BvjdECE5zu9NjbI45MBXcPsJyKRA?= =?Windows-1252?Q?scM/qxksxMONqtKDUwRbxyqE3BtvKj5n6vmd2E6FqTT4s089YiAmTn3z?= =?Windows-1252?Q?bB6SmwNIeC2/UWp6KMWD/Y044np0VCpQlYKwOuLmGbVika+qPfVvXoae?= =?Windows-1252?Q?jvbDOslIjPCym5qhIc+eRHvhxURKGoQso9NE18RCZ18SIIRNEiBVwZVJ?= =?Windows-1252?Q?iKgPObJdjcckJHXuqEXuR9A8QN6HLd4XGKj59ug/gHbIKw475pOp6/uQ?= =?Windows-1252?Q?+GuxlqKKqNM2V0giD08PlmCSXGFdGsHOYP2x1yyBMhWvPGTwlHvD6G+2?= =?Windows-1252?Q?osGxznRCA19O5aUZ5KGzyNea7fdsTUVdFL6aoHbUIwkVj9Zif3NWtueb?= =?Windows-1252?Q?TMZhjtq1lC5R4C8nVvll4L12QJWK7ytdhyWgV/PIG2e750m4ENuKJSOD?= =?Windows-1252?Q?rDH9BgAK8wPPc7VmKDIDCXKPsU+t56VUwalUM7qdm+81mANpYWeVuWdK?= =?Windows-1252?Q?henY57itdjpuzfJxf9CDW2WPbEFrQFWo1RnWnXyZO37WwdEw2efKKWJe?= =?Windows-1252?Q?uV8njOlQY/8iaVp1bnOj1wkh8S4r9E7QOEee5VqgPiEGGD/WZcQbU/QA?= =?Windows-1252?Q?3mSjgJiuU8hFI6yQOZtB9sOJxuO91m0Ek1iotjO7l+Nb0K8qee0NG0k+?= =?Windows-1252?Q?ZrsZZvp7T8j3uBmwYy6QOJWAaU3CUQqTCiF/pLn6tGlYT5N4MTA+mal8?= =?Windows-1252?Q?l5+LcbkcFEcU1lB1QduaRzMURhVwBfPqBp8SIcAHzT6a9wT5j7StpRQK?= =?Windows-1252?Q?9titsuGJ6n7AfTzqaJh303lmQQ5NX0yfLbit054caJgztgt1vjlr/U7v?= =?Windows-1252?Q?O+keP3D/mzY1IlUshlTe7IQNzviuIO8LbuV8vWy5N9TRtTd+Rx8NmrwB?= =?Windows-1252?Q?oo/l4idhthwawHWqLN43pU3Bii27pEBadVA2ToB+aYoxREqetT89ocdD?= =?Windows-1252?Q?oVnaZDo+YjKOXjRhXzK9jsbaNsUTfBMwvcaMgI1dFmOVOh3Y69cdqnjD?= =?Windows-1252?Q?OE5ldk6ta48v2xuyEzzztB8EY+CmlEKBB81DZ8UUCOtimHx2bU6Wu8i0?= =?Windows-1252?Q?bpVMxOmiZgH25DmC32V9ZaYpcww5NuYVFOfPiL1geTbPxBpaj7BSMOaN?= =?Windows-1252?Q?vqsE21EGzzDryWAhcx3Hj7LIkzKUmPBgkkE/qaDcbvYKD/8jlrrvUqsG?= =?Windows-1252?Q?LRIBg00vGFssqVerzrTDwHh04Hx9/a1nLS+7XLAnZBJVbuHW8UL6tXE6?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_DB7PR07MB5546592E043B8B39069A19FDA29F9DB7PR07MB5546eurp_"
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b84a279e-dfc7-4262-ea72-08d8d8b0dde6
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2021 10:42:22.0207 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qqjxZiFE+i71YMyOJ+0sPqtrsFw2PyY+ibzPqusSbJEL00s1U/I7wBOzUonFYNjd5h/imwITEg0e3sTYKxT/og==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2888
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/TEZByd_kbmGOsPnruhIrxznqG-o>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2021 10:42:28 -0000

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Mahesh Jethanandani <mjethanandani@gmail.com>
Sent: 23 February 2021 20:02

Top posting because I am obliged to use the web to view this and the result is an unusable mess:-(

Two thoughts.

Several WG have tried to set up registries of suitable security algorithms and have failed dismally (the recent Last Call review of NTP yang shows some of the problems).  The TLS WG is probably the least unsuccessful in this regard but I do not see their work as having wider application.

Monotonic is a word I learnt and understood at university until I came to the IETF when I found that American mathematics and European mathematics differ.  I see the IETF using the American meaning which always grates with me.

Tom Petch

Hi Reshad,

I never really received this e-mail, till Sonal forwarded it to me. Anyway, here are our responses to the comments you have provided. Please see inline with [mj].

Hi Sonal, authors,

Thanks for the document update. Main comments:


  1.  Hash has been replaced by symmetric algorithm, to be able to retrieve the sequence number at the receiving side, this is good.
     *   Section 3 mentions that the symmetric key is provisioned securely on sender and receiver, but there is no mention of provisioning of the algorithm/function. Also there is no mention of what algorithms to use, is this on purpose since what’s good today will not be recommended tomorrow? Should we at least say “do not use DES” or too obvious?

[mj] I believe this is a question for the WG, and maybe something we can bring up in the upcoming meeting, if it is not answered on the mailing list. Would the WG prefer that a (set of) algorithms MUST be defined to ensure interoperability, or is this something we should leave up to implementors/operators to agree? We are concerned what we define today might be obsoleted tomorrow.


     *
     *   Was there any discussions/thoughts on using asymmetric encryption instead (I didn’t follow this document when it started)? It avoids the pain of having a shared secret. I’m not saying we should go with asymmetric, just wondering.

[mj] We chose symmetric because that is what 5880 talks about.


     *
     *   For the key, the terms “symmetric key”, “shared secret key” and “shared key” are used, settle on one for clarity (I believe it should be “shared key” or “shared secret”?)

[mj] Ok. How about “shared secret key”?


     *
     *   For the algorithm, the terms “symmetric key algorithm”, “symmetric algorithm” , “symmetric encryption algorithm”, “symmetric decryption algorithm” are used. Again, pick 1 “symmetric algorithm”?).

[mj] Ok. We will pick “symmetric algorithm”.


     *
     *   The term “hash” is still used e.g. in section 4 header

[mj] That is deliberate. We use “hash” when we refer to the value that is calculated over the entire packet and appended as a value at the end of the packet. That is different from ciphertext, which is the value after applying the symmetric algorithm on the sequence number and inserted in-lieu of the sequence number before the hash is calculated.


     *
     *   Security is not my expertise. Should we get a security review asap, as opposed to waiting for IESG review. Jeff/Martin?

[mj] It would not be a bad idea, although we do have a security expert as a co-author on the draft :-)


     *
  1.  Diagram chains are clearer now.
  2.  Sequence number validity as described at the bottom of page 3 and on P4 (at the end of section 3). RFC5880 sections 6.7.3 and 6.7.4 describe that received sequence number should be between bfd.RcvAuthSeq(+1) to bfd.RcvAuthSeq+(3*Detect Mult) inclusive. I don’t see why this has to be changed for secure sequence numbers.

[mj] We will just refer to 5880.


  1.
  2.  Jeff’s comment regarding “The first sequence number can be obtained…” in section 3. I believe the text is incorrect. RFC5880 sections 6.7.3 and 6.7.4 explain how the first sequence number is obtained (using bfd.AuthSeqKnown and bfd.RcvAuthSeq).

[mj] Ditto.


  1.

Nits:

Section 4: s/”while encryption/decryption”/”while doing encryption/decryption”/
[mj] Ok.

What does “non linear” mean in “monotonically increasing (but non linear) sequence number”?

[mj] A monotonically increasing number is just that, an increasing number, but it does not have to be linear. See the diagram below. That is why the mention of non-linear.

[cid:7B4395E2-5D1F-4619-9AAB-30E5D8E25183]
Section 7: s/Jeff Hass/Jeff Haas/
[mj] Will fix :-). Thanks

Regards,
Reshad.
Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>