Re: [ippm] Discussion on draft-brockners-ippm-ioam-data-integrity method 3 variant in @ietf110

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Sat, 27 March 2021 14:53 UTC

Return-Path: <fbrockne@cisco.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F643A1F62 for <ippm@ietfa.amsl.com>; Sat, 27 Mar 2021 07:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.594
X-Spam-Level:
X-Spam-Status: No, score=-9.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Eo1b/ZN7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zP424+Jl
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 WYm-A70WxuLC for <ippm@ietfa.amsl.com>; Sat, 27 Mar 2021 07:53:46 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9843A2C19 for <ippm@ietf.org>; Sat, 27 Mar 2021 07:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22382; q=dns/txt; s=iport; t=1616856826; x=1618066426; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IJa7iXvNLUx7UTs4G9hIij10nZ/uXO3yu/ld1+oHt6w=; b=Eo1b/ZN7SqI0QHMgSDpBma60RW/ZtCPUkBtvccyVCQt9sqyfMa+o+JwM 6KhlWTKoq0Z84Y+JA6jM1XtO7P/rtVcQuwySGuRSg0yKNmh/hVcKazeqH eQaMBbtowfv8nx4Cnd47spgYIhi0eRr+cKydrXMkDv6ZT4ofnGQ/XhOZ1 w=;
X-IPAS-Result: =?us-ascii?q?A0A7AACcRl9gmJldJa1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBghCBIzAjLn1aNjEKhDeDSAOFOYhBA4oqihWEdYJTA1QLAQEBD?= =?us-ascii?q?QEBHQEKCgIEAQGEUAIXgWkCJTgTAgMBAQEDAgMBAQEBAQUBAQECAQYEFAEBA?= =?us-ascii?q?QEBAQEBhjYNhkQBAQEBAwEBIQoTAQEsCwEPAgEGAg4CAQQBASgDAgICHwYLF?= =?us-ascii?q?AkIAgQBDQUIE4JVAYF+VwMvAQ6QQJBrAooed4EygwQBAQaFHQ0LghMDBoE5g?= =?us-ascii?q?naEBwEBgROFOCYcgUlCgRJDgVt+PoIeQgEBAoFeKwmCYDWCK4FYJEhEJgRTI?= =?us-ascii?q?DsLFQpHBwM4KwETDxiTfodcnXJbCoMGkG+GQYVUg0ihCB2GHo5Mgg6MZo83H?= =?us-ascii?q?YRBAgICAgQFAg4BAQaBayGBW3AVO4JpUBcCDY4fCw4JFIM5hRSFRXMCNgIGA?= =?us-ascii?q?QkBAQMJfIVlLYEHAYEOAQE?=
IronPort-PHdr: A9a23:5TKb9hxPvqM4zMPXCzMtngc9DhMPsqjoPgMT9pssgq5PdaLm5Zn5I UjD/p1FhUfRWYid4PVB2KLasKHlDGoH55vJ8HUPa4dFWBJNj8IK1xchD8iIBQyeTrbqYiU2E d4EWApj+He2YkFNAMLzIVbVpy764TsbAB6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1K UC9rB7asY8dho4xQps=
IronPort-HdrOrdr: A9a23:YPXwwqjnfxiXarnVgB/r1L8dUnBQX4hx3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+gsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmu5 tIW5NVTOf9BV0St6nHySGzGdo43Z2j+Kenme/Rwx5WPH5XQotLhj0JbTqzOEtwWQVAGN4dHJ 2T+sJIq1ObCAoqR+68AWQIWPWGms3TmPvdEFA7LjMEyC3LtzOn77bmDwOVty1/bxpjyaovmF K16DDRyb6kt5iAu3rh/k/Vq69bgd7wjuZEbfb89vQ9DhXJpkKWaJ96W7uE1QpF4d2HzFoxit HDr1MBEq1ImgnsV1q4qxfsxAXsuQxGgxSJpDPo4gqAneXDSD03EMZHj45CGyGplnYIhs1206 5AwguixvxqJC7Ahyj06pzpUBxnhyOP0AIfuNMTlHBWXM8ibqZQp+UkjTpoOaoHdRiKjLwPIa 1LNoXx9fxWeVSVYzTypW902uGhWXw1A1OvXlUCktb96UkXoFlJi28jgOAPlHYJ85wwD7Ne4f 7fD6hunLZSCucLcKNGAvsbS8ffMB2PfTv8dEapZXj3HqAOPHzA77Tt5q8u2e2scJsUiLw/hY rGS1EdkWIpYUrhBYmv0fRwg1LwaVT4eQ6o5tBV5pB/tLG5bqHsKze/RFcnlNblrO4YBsHdRv avKJNbC/LuNgLVaMJ09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGecPu7HsurLR8UHkfERl cTVjn6I8tNqmqxXGXjvRTXU3TxPkj2/Zd6FrnG7/EeobJ9cLFkg0wwsxCU98uLITpNvugdZ0 1lOo7qlau9uC2x5mbH72JgPxJHFUZL6LD8U3dHzDV6dn/cQPImgZGyaGpS1HyIKltUVMXNCj NSoFxx5OaqNZCK3DsjDNimK2qeiHMWqBuxPs4hs5zGwf2gVoIzD54gVqA0KB7CEAZtnx127E 1ZbhUfe0PZHjTyqKmsgZAOHtvDf91kjArDG78NlVvv8WGn4eAmXD8yQiOnW8//u3deexNkwn lKt5I5rJXFszC1Mmc7iPk/KzR3GRSqKYMDKh+EaoVSkq3sYydqQw6x9GenoiB2XHb2/EMPgW GkCiuYdZjwcwdgk0Ed9Lr2+1VpcWjYRWZMUzRRtI1wEnmugAco7caCerez32yNalEL3+EaN3 XfbSEPJx51rurHpyK9iXKME24ryY4pOfGYBLM/c6vL0nfoM4GQk7oadsUksapNJZTrsuURV/ iYdBLQJDTkC/kx0wj9nAdvBABk7H0lm+jvwhvr8Syx22M+G+PbJBBjS6sAK9+Rq2jiSPDg6u Qysfsl+e+xOH72cNiI1OXeaCNCMArapSquVP4zwKoky54apf92Bd3WQDHI3HZI0FE3K9r1jl oXROB+7KraMoFicsQOc0tijxYUvcXKKFFuvh39A+c4c11olXPdMt+T67fDqLYkACS61UPNEE ja9zcY8+bOXiOF27JfFrk5Jn5OblMgrHtl5+GPeuTreUqXXvAG+ED/NHCzcLVQEvfYXboRqw t3+NGOkauccTHi1AXZoDt8JeZP/g+cMLePKRPJHfQN9dqwfUmIiO+t5sW4iT/sUzu1a0gCn+ R+BAUtR9UGjiNnlZE91yi5V7f+rU0kmUZP+D0PrC+Z5qG2pGPAWVxcOQLXgp9KTSBeP3iBg8 PC6/WZ3h3GkU948IiGElxRcNFIE8URSYayLz4GE7ljgIKV
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,283,1610409600"; d="scan'208,217";a="710077917"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Mar 2021 14:53:44 +0000
Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 12REri75026483 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sat, 27 Mar 2021 14:53:44 GMT
Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Sat, 27 Mar 2021 09:53:44 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Sat, 27 Mar 2021 09:53:44 -0500
Received: from NAM02-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 27 Mar 2021 10:53:43 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JWaL5RXWg9hAkFCAAeRofOeYgeD7cfZzRRP7An6tkqjP5+TBF4DAv7HjVsoeuwco0Kxn1RSOFaqYBIpPT74MrJQQHuWT25NJyugkEfMOUo+lnKwhHbt5fp0QwtBT+Y/olwtRoKEz1cBY3P5jQ2ubYkrrPe9xcxSSEFjqJ3Ku+yEnVArZeXJuvgiBrh6QqAC3AID7oKCRlXuHKoo9qhalWzhyt4WgX5s6apHCoInDlmOcWaSo5Bbnioh34BIjAS6rFFRswt1+EZN13bSywqWaERY9Z0I3IKrKbqORsiOo6T2OadiJCnDGKEOH9RnhfPhDHa1972Av3jPl5Re0BEuFgw==
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=IJa7iXvNLUx7UTs4G9hIij10nZ/uXO3yu/ld1+oHt6w=; b=SbDj7TAdKhtsmBJr1K9O9CRXCEmSA/iA6BJ4T572RE4F1cwSDP1c2QMCu8xucp2fvAcc+LIUjRCOPwxn8XmQsKN64RpqP/oK8Ipcw+gl4GH7Nv8rB2lTpymdK8p9mAA3YI91vr4p8EN/NABbZYdJzbqEbajPfdFSEbgOnVCPn8gxiG4UHgtbI0VeRlz5skbJFYG4veHUHZeXLIIN0Gi6RHPJwqFOoUDrg+52sr20WElSttuaTmFiJdYto10YXzjdRK2w0LfqTl2fxdZdpLSxc/32oj1QCCyftIQIKhOLH+2okXaYCbUpRNTliG1E/uM/I6+ZenCU8FgiIyOznOSj7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IJa7iXvNLUx7UTs4G9hIij10nZ/uXO3yu/ld1+oHt6w=; b=zP424+Jl2MbjwdwOrSMgtvfEorIrx7Su9NUPIK2WLKWdxrbet+qZ9P/h7BHTdUAC/ycQS1fcqOL9rAZ4Crx9VCaSTjKLERQoCXU9X7y7qIqpKnymqCmw7lip+J+g8CN47lY0t9Q+UpUrmwwgZuu85RMmc7gqjEui5P+mSd+7WBA=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (2603:10b6:a02:c8::31) by BYAPR11MB2582.namprd11.prod.outlook.com (2603:10b6:a02:cb::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.29; Sat, 27 Mar 2021 14:53:43 +0000
Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::f43e:a30f:8e8f:1e93]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::f43e:a30f:8e8f:1e93%6]) with mapi id 15.20.3977.029; Sat, 27 Mar 2021 14:53:42 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Tommy Pauly <tpauly@apple.com>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Shwetha <shwetha.bhandari@gmail.com>
CC: "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>
Thread-Topic: [ippm] Discussion on draft-brockners-ippm-ioam-data-integrity method 3 variant in @ietf110
Thread-Index: AQHXFITi/2A5A5XWfEOVBHkDsBCHQKp7ET2AgAVeWwCAFmzcAIABJMRg
Date: Sat, 27 Mar 2021 14:53:42 +0000
Message-ID: <BYAPR11MB258497AB264414E5F2B83FFFDA609@BYAPR11MB2584.namprd11.prod.outlook.com>
References: <CA+SnWFEGAwm0D2-U=5DapY=4Ky0R2xP0i=tFyjme6VaLRDdwwA@mail.gmail.com> <CA+SnWFHp7_tmqPGikvOOO5CGa1905wSnfrswaXBCmg0Z7LrTqg@mail.gmail.com> <ED2E3E28-C697-4CE7-A6F3-E4CF5B89AD42@apple.com> <B393DF12-BA0A-426A-8445-AE193050501F@apple.com>
In-Reply-To: <B393DF12-BA0A-426A-8445-AE193050501F@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: apple.com; dkim=none (message not signed) header.d=none;apple.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.50]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: af2ba489-cdab-49d4-4b44-08d8f1301d8c
x-ms-traffictypediagnostic: BYAPR11MB2582:
x-microsoft-antispam-prvs: <BYAPR11MB258217E6F6CF8CEF9DC42E47DA609@BYAPR11MB2582.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gmexjpnZt1wZbwQcjCAdAmYZD1YgHemdHg01ULQiXj3uHHmE/+YgVyTF84mtfPLfAobKMFkdYwcCwZt3lx47Pw9olsIQrHwv7LBgelFI4h4evyxis6sfLPSqpMzTxaHSoIk83kh+T/bb+5ECSEvQ+nRfWuZHDjH7zrru/JIrX9c8BjnbnlX2i+vIcH0MCx2ERCqBnQsNFagn8ffxqFwMSQb3mC9QN263kME1UYpqc+r/Xdc7+iQPbL2LLXUJGOkZ0Rvr3/FqibUkZnCmJhtGNhrgpoKoDiJc/ChIw7mb2UcL3lA8KegdMmhVPV44Dwz6/4KHY02JwX2szqwllP4miB6u/XYa+br9K44SQUiegP9O9XoSA70bGj6Y7+/PhRGdEyPdg2NQrx8P/60xLXo3Ju85JxXF2F2fXnSqWh5zCWQje+gpBkECJgMN2Pfi7QGhYKT05vlJ64TsYtstWl5Pl8Lv+a28POjmXfbKQEtaJRxzFufLhYDx3J6Iyzpd1+B/AwcB1udJEorwfiJUUiRzz9rtH8ag9npR4skjMBjq85a2xmyasIbVHMQa3LtCF9q2TMNN5GvMzMVaIhKWReixUUPM3XqxTGy1sQqTk1uVBmD1Yn8RSuhhl0IqnDTh1+M77/cgmqe4rUUANnIv2FQLnGRQaLp4dOtt8Abvs9N9GsUlbXvNYmAsnj2t2HQHk0/+nlpGkV388MjCtJsAZdlRv+FWasloey9M9gCCc1KwKdArzqrsxrd5/kVvnPoUKH4S
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2584.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(39860400002)(346002)(136003)(396003)(66574015)(83380400001)(9686003)(26005)(4326008)(66446008)(166002)(186003)(55016002)(110136005)(7696005)(316002)(5660300002)(52536014)(86362001)(53546011)(966005)(66946007)(64756008)(66556008)(8676002)(71200400001)(76116006)(2906002)(66476007)(478600001)(38100700001)(6506007)(33656002)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?eUl1dWJJQTdXME9PSjY3UERvL1laS1hJdXRISU0zbmRjT01QdmNkUXJNeDFa?= =?utf-8?B?LzY0S1Exbyt5UFg5RXBweDd6TVdSODduME5MY0RhdGdqTy9tSGNVR3kxNFFF?= =?utf-8?B?WWttMGVTSUlUamJsdVRJSVlqbFRyS3NkQlh1QVNrRW5DVEpjUFdVZW5lU2N2?= =?utf-8?B?UGdyVUhlaDN0OXdIOTFFeHJKQjhzUmZyODdDSHkvYW53V2hid2tEZTBZc2ZW?= =?utf-8?B?RE9kblVaVnFMb3Ird0dMaHRFaTRXeHc3ajdYY1B3cmhzVEtNclVDcDEzUzRn?= =?utf-8?B?d01TV0VWRDM5am1mVUt1aUJiNEwvT2NnQXU2bmdUTlk3Y2xzL1VGamZPU2h0?= =?utf-8?B?QTJZUFVkSTVYdmdlS1ZqZncyN2tmemxiRzUwYWxReHF0QjdnbzlxTzdFTCtN?= =?utf-8?B?ZUJObHJRRUhIUkNMSzY0RVJianp3UWUzV1oxSmNpNGFTQlhBVXNjaFZGeFVa?= =?utf-8?B?YW4waXJ4d3VEenRpV3ZxT2NpSkk3SjVlZXdWNHdpTk5SSk04Q0JyU1NFN2tU?= =?utf-8?B?Y0U0RXJDdXRqdlJwejFzd1Y5bG9CdUd5OUxLbHBGNG9mK0YybTZ5NmQzeWlj?= =?utf-8?B?RHF6azRrYmpNeUFBbU9nbmtFdnlLeWVQTEo4ZFJvS25naWU4OFM5eHRtakNR?= =?utf-8?B?NHZjSy83d2pVb2JuSXRyRzJwa1hieTRnUHhNMldyRCtFNUZjelU3a1RTM2Nu?= =?utf-8?B?ZjJ6WVRvb2oxbUd2aTJEU04wamdjNTlZMjlVUy9BS1EwdEp0UDczWHphcEsx?= =?utf-8?B?Vks5eS9iOHFIK1VORFdiMjRncDBVc1FLeWorbDgrUTlRcmUvbnhtcStiRXE0?= =?utf-8?B?ZStYNktUcVF0QmN2Y3BMRkFzR1YzTzNRZklhSExHdTZIcUlEczhId2FjTkF2?= =?utf-8?B?Y2FReUtrRmRFMm53b0UwZks2QkZJL3ZiZU82bTVBUElWQ0NwQUwrVnVFNEtn?= =?utf-8?B?bXJsUVV6eEc5RWR6enFxTDFYSmhvQW1XR2dqaVlOVEFlbS9VZHNQMFBLTml3?= =?utf-8?B?YWdZUDYzTWZrNXM4ZjVSa0p6cEUwN3Bjam82dUl5YlJlTEtiTkhYZmRUa0RO?= =?utf-8?B?VkljZ3Z5WW5WTFpwTVUzbnlpemRQK3paYzEvODZVVjZ0N1RKb29kQXhLOG1L?= =?utf-8?B?S1dMYWJUY2diU3d3a3dCMFVBWS92YTJGOCtTRG94UDFacmVxelh0NzFXblFN?= =?utf-8?B?SGc3T05CQVhUazRBdFFGWFNTLzR6T1Z2QVB6U24rYXp2TUNwQ0RNdGc2Q0dj?= =?utf-8?B?cEFvZE04bHk0Ykw0eEN1SGs3a0F2ZllwcUVCTTJEVkExeUxFRjJURnVBbEVZ?= =?utf-8?B?UGowalJtOXFNKzZJM21LeVFJM0RMVzBLUUFEYjJuZGpZYTVPQTk1bXR6VExU?= =?utf-8?B?MEVlQlIxTlBLVkFmakMxQStsTGxDcnBieTJ4Y0VoQzBDOVQ2TEpnYjU5U1VP?= =?utf-8?B?cjFlMVVxQkNLMThHRE9ndnc3OFhVQlJ4R2hXYjJ2dk1rTXhlR0k2VGk5bEx0?= =?utf-8?B?RzZyeGxQWGZqZUdzcGpPY2VoVHZQNTYvTGwvbEc0eWxvTXkzV3NCUUZDNDVZ?= =?utf-8?B?d2ZNeWQzOUZkbUlydmlWQ0ZIck9aVzZBTTNaK01CUTROSWJvTExyL25VdW1k?= =?utf-8?B?azJ0SWlDM1duQnBMN21EZnRGdW5YVkxSWnY2eWo0ZFFnU2RmY0ZXWDNHdnhK?= =?utf-8?B?T25WaVJNRkJpb2xKckQyOTB1U2t0Z1VvQW1GQjVNb0N6ZUR2U0g1cFZBTDZt?= =?utf-8?Q?MvV8mh6aixgwfeeBESQZz2B3buiLnrEa7g8xRoC?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB258497AB264414E5F2B83FFFDA609BYAPR11MB2584namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2584.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: af2ba489-cdab-49d4-4b44-08d8f1301d8c
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2021 14:53:42.8183 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: PUDBuO2OCu/wn1IiozaYncTxDn+cG5G51zKX0hjLwW4BQtlxpi5AAzyl2lCHs1nUS6iOGV+rC0yWWZmtdodsGw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2582
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/3PhQZ_xxrAU8c2tLG-x1DfsdaHE>
Subject: Re: [ippm] Discussion on draft-brockners-ippm-ioam-data-integrity method 3 variant in @ietf110
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Mar 2021 14:53:52 -0000

Hi Tommy, IPPM WG,

We’ll look into the update after the Easter break. Before that, I’d greatly appreciate further input and thoughts on the preferred methods.

In our IPPM WG meeting during IETF 110, you voiced a preference for Method 3 – broken up into a “Method 3a – with symmetric key (the current Method 3)” and a “Method 3b – with asymmetric keys”.

Per the discussion, the Method 3 approach suffers from the challenges that one would need to provision a secret per packet, which is a significant effort – but provides for replay protection. Detecting whether a secret has already been used or not is detectable by the verifier. Method 4 also provides for replay protection given that it also uses a secret per packet and at the same time is to help the secret provisioning issue, given that we’d only bootstrap a key generator on the nodes and would then leverage Key-IDs – which makes “secrets per packet” much more manageable.

Per the note above, during the WG discussion, a preference was voiced for “Method 3” – but at the same time, asked for avoiding a secret per packet – but re-using the secret for multiple packets, e.g. defined by duration or number of packets. How would we arrive at a solution for replay protection in that case?
Options we could consider include:
(a) Include the payload (or portions of the payload) into the signing process, so that the signed IOAM data becomes unique and cannot be easily re-used for future packets.
(b) Include an additional “identifier” or “nonce” as part of the IOAM-data, which would make the IOAM-data and thus the signature unique – which could be checked and tracked by the verifiers.
(c) ? any other options ?

Thoughts? Opinions? Preferences?

While evolving the design for Method3 (or better 3a and 3b), I’d suggest that we keep Method 4 on the table for now.

Thanks, Frank

From: Tommy Pauly <tpauly@apple.com>
Sent: Freitag, 26. März 2021 21:58
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>rg>; Shwetha <shwetha.bhandari@gmail.com>om>; Frank Brockners (fbrockne) <fbrockne@cisco.com>
Cc: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: Re: [ippm] Discussion on draft-brockners-ippm-ioam-data-integrity method 3 variant in @ietf110

Just checking here—when could we expect an updated proposal for the integrity document? Once we can converge on a set of approaches we like, we would like to get this prepared for a WG adoption.

Best,
Tommy


On Mar 12, 2021, at 6:30 AM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>> wrote:

Thanks, that’d be great to see the variants of Method 3 like that!

Best,
Tommy


On Mar 8, 2021, at 8:31 PM, Shwetha <shwetha.bhandari@gmail.com<mailto:shwetha.bhandari@gmail.com>> wrote:

My bad, it should be possible to reverse the process for validation and retrieve the previous signature in the reverse order. We will update the draft to have Method 3 with both symmetric/asymmetric variants.

Thanks,
Shwetha

On Tue, Mar 9, 2021 at 7:07 AM Shwetha <shwetha.bhandari@gmail.com<mailto:shwetha.bhandari@gmail.com>> wrote:
During the session 1 of ippm at IETF 110, it was suggested to consider introducing a variant of method 3 in  draft-brockners-ippm-ioam-data-integrity with asymmetric keys.


When we were designing the methods to protect integrity of the entire IOAM data collected at each node, the node chains it's own node data with the signature from the previous node and overwrites the signature:
Trace signature = sign([Trace Signature || its node_data_list[x] hash])

In the symmetric key case this operation can be validated by reversing the operation by the validator who has the shared secret from each node.
However this will not work if nodes use their private keys to sign and validator has the public key to validate as it can only validate but not derive a specific node's signature to reverse the operation.

So I think the space optimized  method to overwrite the signature at each node cannot be modified to use asymmetric keys easily. Will be happy to discuss ideas to create a space optimized asymmetric key based solution.

Thanks
Shwetha

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm