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

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Sun, 28 March 2021 10:22 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 A0E453A1740 for <ippm@ietfa.amsl.com>; Sun, 28 Mar 2021 03:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.494
X-Spam-Level:
X-Spam-Status: No, score=-9.494 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, HTTPS_HTTP_MISMATCH=0.1, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YWlxcitV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HJsGUDx6
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 hmE9B7rvmXvi for <ippm@ietfa.amsl.com>; Sun, 28 Mar 2021 03:22:18 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B08D3A173E for <ippm@ietf.org>; Sun, 28 Mar 2021 03:22:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35642; q=dns/txt; s=iport; t=1616926938; x=1618136538; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iTWB9i7R36Ca/ZH56OEnPBEUnwajqTVw3PxxIxg0918=; b=YWlxcitVIBD/TG7j+VVhIk6EXa7uvyxgL+ACh0E4V2Sg+7trBGVaRoZw MoUEl/l+zx9Ey+8cQe+/17pJF3VxtnB0o5G164at3hErBcZcxph+/rI4B 62dWqTULhMoHFhCR/YyWYISuKcgJ5W/HoE+W95O2tcXESxTRo6tPR9S4a g=;
X-IPAS-Result: =?us-ascii?q?A0ADAACaWGBgmJpdJa1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBgXwFAQEBAQsBgSIwIy59WjYxAweEN4FfgWkDhFlgiD8DgQmJI?= =?us-ascii?q?Y8KgS6BJQNUCwEBAQ0BAR0BBQ8CBAEBgxuBNQIXgWkCJTQJDgIDAQEBAwIDA?= =?us-ascii?q?QEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYZEAQEBBAEBDBUKEwEBIwYDCwEPA?= =?us-ascii?q?gEGAhABBAEBIQcDAgICHwYLFAkIAgQBDQUIEwSCUQGBflcDLwEOkHWQawKKH?= =?us-ascii?q?neBMoMEAQEGhR0NC4ITAwaBOQGCdYQHAQGBE4FGg3ImHIFJQoESQ4FbSTU+g?= =?us-ascii?q?VdHQgEBAoEzKxUWCYJgNYIrgVgGCxNIRCMDBDIZCCAvDAsVCj8IBwMUGwkEG?= =?us-ascii?q?QUJARMPGJA4QoMEh1ydclsKgwaJWYcWhkGFVINImiiGYB2GHo5Mgg6JUoMUj?= =?us-ascii?q?zMEHYRBAgQCBAUCDgEBBoFUOIFbcBU7gmlQFwINjX0iCw4JFIM5hRSFRXMCN?= =?us-ascii?q?gIGAQkBAQMJfIVgAiYHgQcBgQ4BAQ?=
IronPort-PHdr: A9a23:k7tAnB0LrRMGO1k7smDPaVBlVkAck7zpIg4Y7IYmgLtSc6Oluo7vJ 1Hb+e4FpEXERojS8flEzePKr+brXmlTqZqCsXVXdptKWldFjMgNhAUvDYaDDlGzN//laSE2X aEgHF9o9n22Kw5ZTcD5YVCBuHCp4DcIERW5PBZpYO/yH92ag8G+zevn/ZrVbk1Bjya8ZrUnK hKwoE3Ru8AajJEkJLw2z07Co2BDfKJdwmY7TW8=
IronPort-HdrOrdr: A9a23:SHIkBambbJYg1nvsgbZUQswrpiTpDfN+jmdD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1aiui/vXwXsFd3AUV4hLxW5Ce2GmO2dxQxRLAod8MZ Ka6NZOqTbIQwVoUu2QAH4ZU+/f4+DajZ6OW29JOzcLyimryQmp5rnzDgSC0n4lMw9n7L8+/Q H+4nfEz4q5tfXT8G6460by6NBslMLl2p9/AqW3+7QoAxHNrirtW4h7Qb2Fu1kO0aCSwXInis PFrRtlH+kb0QKqQkiPrRHg2xbt3V8VgheIozL18BiTw/DRfz40B9FMgohUaHLimjcdleth26 FG1X/xjeswMTr8nT/w79WNdxZmmlvcmwtbrccvjmdSWYZbVblJrYZ3xjItLL48GkvBmeQaOd grKPuZyOddcFucYXyclHJo2saQUnM6GQrDalQeu+SOugIm3ExR/g89/ogyj30A/JUyR91v/O LfKJllk7lIU4s/cb99PuEcWsG6Y1a9Ai7kASa3GxDKBasHM3XCp9rc+7Mu/tynf5QO0d8UlI neVkhb8Uo/YVjnB8HL/JAjyGGOfEyNGRDWju1O7ZlwvbPxAJDxNzeYdVwom8y85/oFBMnWXO uyJYJWD/fvIXCGI/cM4yTOH71pbVUOWswcvdg2H3iUpNjQF4HsvuvHNPbfTYCdVgoMayfaOD 8uTTLzLMJP4gSAQXnjmiXcXHvrZwj69ZJ0G67K4vgLxOE2R8txmzlQrW78ytCAKDVEvKBzVl B5OqnbnqSyonTz+33J4WVvMh9UFV1U/73kTnNPqWYxQgbJWIdGn+/aVXFZ3XOBKBM6ZdjRCh Rjq1N+/r/yM4ad3jk4C9WsMnuTinwaoH7ideZEpoSzoePePr8oBJcvX6J8UTjRHxtugABwtS NocwkfXHLSETvolISohJEZH/vkatF5mQunSPQk8U73hAG5n4UPTmFedyOyWcSX6DxeNgZ8tx lUyesjp5au3RyoMnAyhewkNkYkUhXmPJt2SCKfZItVnbj3fhpXVmniv03AtzgDPkz36k4Vmm vtaQqTdP2jOCsBhlloloD37VhzamKRO3hVV0k/m4h8GWPa00wDi9Ojbrav0meXd1sJyvwcNj aAejcJPgZy3bmMpW2osSfHGnM8ypo0OOvBSLwlbrHIw3uobJaFjKccApZvjdtYHcGrtu8ASu SEfQCJaDv+FuMywgSQz0xVcxVcuT0hkfny3gfi43X91HkjAeDKKFAjQ70AOdmT4yzlQPmPua 8Jx+4drK+1Mm/rbMSBxrySZzlfKgnLqWrzVvo2s/lvzNQPnao2G4OeXSrD1XlB0hl7JMDolF kGSKA+5LzaIIdgc8EbZioxxCtkqP2faE8w9gDmCO43el8gy2XWON6E+LLEo7siCE/pnnq5BX CPtylGu/vVVSqK0rAXT78qKWNNcU4m9TBs+viBe4C4MnTkS8hTuF6hdnmzf79WRPLbRfEerh Nm78qJmOHSfSziwwzUtSZ6JKUL82vPe7LHPCucXepTt9q9MhCQh6Hv5si5hjL+UyG6ZEQVnp ctTz1YUu1Tzj05yJQq2S2zQLHtqk0rk1FC8Shq/2Sdr7SO8SPeBwVaKgXXjZVdQClLPnWJhc rD9/KE1H6V2kkz5bDTUEFKft9PHNAMTo/4ayd2QPJgzoKVww==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,285,1610409600"; d="scan'208,217";a="687831132"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2021 10:22:16 +0000
Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 12SAMG6d004212 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sun, 28 Mar 2021 10:22:16 GMT
Received: from xfe-rcd-001.cisco.com (173.37.227.249) 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; Sun, 28 Mar 2021 05:22:16 -0500
Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Sun, 28 Mar 2021 05:22:16 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Sun, 28 Mar 2021 05:22:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aQIxxWRb0+BaIrGenrBwL+ebq+GGV6Hp1RniQobEmaVyDbaJG5BlO7n1nsuIHZ2pG6nNBKWP2FR7yImzirmifedP9k5i84+DrC88fS1sduwMREfnrC68f3hrMABBH5eiNTKBQI5Jrzbvlg3fCMcfKf+Ce6vLMMM9SScZ2sChziO+HNGahRgG+CNwGr/fVZU6iXhqi3I+eX8Zj75ZjjlYCqRNlWpcyl8Is40KHbcaOHVX4oRGEQkCec+WYJCzR+TcqnO5e2IagHGRlkMYUY8oPmA6btfFrRqVxYySPArAFyzV0+pF/efcw9GAE3RArFwgmdMi+tVUwETFXcLM+6l/lg==
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=iTWB9i7R36Ca/ZH56OEnPBEUnwajqTVw3PxxIxg0918=; b=dnUm3PkZ1zUf+WpvAVDYhiJN0mPSyxK1IjauVvtK9QZeXNCiB3AZ9asJzhzB9YIK/XE1jprplzUC4tvj4M7qww+f7KdN4qxwUaxAIeW9MrZWhzQdURL/Qj8n4MDyy92TOCrRmqFfjS2Z+uhWJIAW2O1FimCZU/W4WD90Jdgsb0ep2itwQicNZVuOyom3DxtgHswxegqQksdjJEgJ6v1WPU8nVNnuOwI95iipqEvolcBErj9xvfvqPHt6cY6pFNktZhF4c3HNG0QBJi7mN247bH8aay3OudDfwZAiHIOXpZ2sb29MKOjxH1sykIN6haBBYM3R+HZY8ffhjhzFRMXwIg==
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=iTWB9i7R36Ca/ZH56OEnPBEUnwajqTVw3PxxIxg0918=; b=HJsGUDx6jF0m2299mi9s50N/pDGEBXmz0EJMGx/ydNgCaSudEJoxXHVfz+sPG9S7AzZdFMUjc7rlWuEJ1+HytoVe5Xzdb0IndWV+U97R88jTTJO6sVMZU+xrpkbKP0X73Cx/1DOGIFCU4UEfOT3DOhju4zldPMGAk37zqXOatr8=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (2603:10b6:a02:c8::31) by BYAPR11MB2790.namprd11.prod.outlook.com (2603:10b6:a02:c4::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.30; Sun, 28 Mar 2021 10:22:14 +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.033; Sun, 28 Mar 2021 10:22:14 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>, Tommy Pauly <tpauly@apple.com>, Tommy Pauly <tpauly@apple.com>, Shwetha <shwetha.bhandari@gmail.com>
CC: "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Thread-Topic: [ippm] Discussion on draft-brockners-ippm-ioam-data-integrity method 3 variant in @ietf110
Thread-Index: AQHXFITi/2A5A5XWfEOVBHkDsBCHQKp7ET2AgAVeWwCAFmzcAIABJMRggAA1vACAARTM0A==
Date: Sun, 28 Mar 2021 10:22:14 +0000
Message-ID: <BYAPR11MB258425AF435E41881B028C14DA7F9@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> <BYAPR11MB258497AB264414E5F2B83FFFDA609@BYAPR11MB2584.namprd11.prod.outlook.com> <4D7F4AD313D3FC43A053B309F97543CF0147CD0A59@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF0147CD0A59@njmtexg5.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: research.att.com; dkim=none (message not signed) header.d=none; research.att.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ef5afda2-d097-43a4-918d-08d8f1d35b33
x-ms-traffictypediagnostic: BYAPR11MB2790:
x-microsoft-antispam-prvs: <BYAPR11MB27901B41E1D3F6AB468E2C75DA7F9@BYAPR11MB2790.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: cVfkSGluq+hMSdZPB2+8CaAIQnP1XLU1MS2o3gGtddrzm6l+kSVkcDWqLdxaIUASfeHv35/L70hTRqVE231RfszwYqCTGoWmPacJ7XkTKF0kRWvAXeL/kLgOWXjS/CBlXfKDxEvKuuOUOcq/P3+/DfynL0yyxS1Jp3avDEUwTrB9BcATDR9EXAXHXSOiXxE/3Da5XEIRQAoJavNta3gZKiYZmRvaNVw92XF6qZWP6KcuI6Icq6tuypVBfX7LREiyJydhPPy0L5c67TN5acZrlDu9ot5HniVnp/vn4V5skMpWQlNgV8e3CYqwqn2dD9vTpR5Iv9Gn9zB/sSkjK9IgmVxHNzeZSTawUH/muO1rWPq+0d3wrO1icU1CkDprGig3xqEQKJwEYxBoxA8ueMFTaKmTjW4SqZ3XgSiGs8j/UIeQFwcoBuD5qBdZ40IUSDh5AR8y4gTXXJmFi+kA0N8VS54qOXjrxUXapHInDnh/LqDKp/R7F6031dHvt5Zg9wUJWYvfXw4x7trpNBNwOLyy+K97fL5EjYGwyrJ3MZZ0e/NvemIrPtvtwIOhm7E5JYlDwWhFzC5BuN+5ke4mdXP/shSenn+R82wSFXmZAyyD+Oi6ViuJNPRmjT4dufyggdN/Bc4mbungfTcIZcbn1oscfMvUfDQMJ6t3UpxJELnZvZguOR2iGUXMIAfD5x4b7YCDkkHcg5VydCVxT7cIHjXTgv5pLbuOaO5w9SHF19xiJScf/lxpjwBmj7T50PFJjYfD
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:(396003)(366004)(346002)(376002)(39860400002)(136003)(9686003)(9326002)(86362001)(166002)(55016002)(33656002)(2906002)(5660300002)(38100700001)(66574015)(8936002)(186003)(66476007)(66946007)(53546011)(66446008)(76116006)(64756008)(26005)(110136005)(966005)(7696005)(6506007)(8676002)(66556008)(478600001)(71200400001)(4326008)(54906003)(316002)(52536014)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?eWtQWmRQZHBhMUl3TXgxTEQxb3hQLzhFK2lWYlJ5UFRjRExnZDdLWjFCbnVj?= =?utf-8?B?Z2JvR2YyMzZEMXg3MjBtN0JOTlFvdnlLMXNGRURrL1FKdTV1a0J4YWtIY1ll?= =?utf-8?B?QTg0ZVcwbGZFZ09Oc2tLV1Y0SG9PTTd1ek51Sy8yMmhGeW1aZ3RDMlNEUG5W?= =?utf-8?B?SFdOQVNiVUxDVnl5em9sV3d5RStUWnE5L0ZzU0JPajcxVUhjaGtHeHFGT0Vp?= =?utf-8?B?NTByRnA4WFBnS3lUWFJQWjNGQ3VHWUxaRW4vMXozczhNc0NQUEJhUHdleTJi?= =?utf-8?B?OWJyZnlUR2pCVFRhSGNYek90QTFTaW1wSHBjWDZsSFN5d0xHVTN0UXlScnda?= =?utf-8?B?MkV3Qzh4VWFaSUY0OEtRVTE5Ym9UbStxQVhsNEhPWk5KRzRlZ1NtNkZTbVor?= =?utf-8?B?b0VJcFR4RnovVnRhdU9EbDBhK01NQldLVGhCYW9yRitRTmxYQTVucHc3Lysw?= =?utf-8?B?N0pBUjFUVzNSbERKSXRLcU1Kd2VqcTdEaTlmeTNzL0lWUU5sYWhIbCtYSUpG?= =?utf-8?B?Q1pHVUVTNkVGVWYzNGxlSndCQ1lzUHZ6ejdKUS9hTFhRS0pONUZ3OE1rSWl5?= =?utf-8?B?NVg5NGxlZ1dJTmN3T0N4Q1ZHdkdyc1VObjhSSWR1VkRQMlZRZVc3MlFVMEhi?= =?utf-8?B?eVBpTWJocXpUWjZCOURqa1IvcGR0VjdqRTFlYUJCVHpIcGJMMnJja3B6Nklj?= =?utf-8?B?OS9kZ0lhN0xtSHozMjVmaUkzb3lPU3VKcDFvazR0WTU0Q0x5YTNDRVBwS0dK?= =?utf-8?B?L0JsYmFPbittbHlKRnNCcUM0VnJkcmIrUHpBVG1hWGhuMEkwbnZ6engzdXdt?= =?utf-8?B?ZElCWHowYURlTWJQc0xKWWMybGxhMW1ralA3VFQ1T0lnalcyL3VRS1VTVW5E?= =?utf-8?B?T3AyVVB3ajF2T3QrWHFOM1pjR2FhWVhpMzAwaWM2SzAyVWZLNjhqUkZUSkMv?= =?utf-8?B?eTN0Vk9KNUNaVzBjTU5ENldmUW15TktaOVM2K0d3ekkwN0M3QUZRTFJ0MWdj?= =?utf-8?B?bmN5R29URC9jZGwrS3FKMW9PSmY2Z29DNjJYTUpGY0dmUkpabklhaEZRUFVu?= =?utf-8?B?RFZSVk5SS3RZUmNaZVVQbkJjNmNkWDU3UWgxU0xiZzI5ZFlweFBMQ1RMWENX?= =?utf-8?B?RW1ZcUFJelF3Nk1ES1RmYzlkanZPZUt1TUd1SlVVSHNNZ3Q3cmxRNGdBMmdk?= =?utf-8?B?NU9DaDNOcVBQY2hVZGZzSGRLNWo4ZkxWdXlZcy9XQ0RBeHphUXpxYkVMN2s3?= =?utf-8?B?a1ZaYlJMK3RkY0d1ZWVtNTlBYXNuaFN5K0h6UEhodnB4cHBIbjd5bFM2eTgz?= =?utf-8?B?NEhFd1hVRGcveTZTVXFCTWdaeU1pTkV2eHlCZEhIYUlSYUl4aWtaa2dub21P?= =?utf-8?B?VUJ5YVc5M3J2WDlVZ2gwR1FGNUNmelZYYjdSdWVTNE1GYk5vK1h4TGhqVzJE?= =?utf-8?B?NnVFY00vVk0vM3hyNm1YVjFjTXltM1dzc2Q0d1duTmVFNmZvNGdnM0x0WGdQ?= =?utf-8?B?TkNyVlJSR0JLZUhoWTgxZU5jc0xSTHZ3OXVsSjNUNVJ3dVlqT21YY01hcll0?= =?utf-8?B?eHJDd01OZWpGZEdVRE5NZmhXS1RkWVlqZW9MekdEWFRoZDhtNm9FK2ZiSFZN?= =?utf-8?B?UkI2cGpvRjlCcVUvMFU5MDZiWGZmZzZwbG9NSVZvQlp2MXJubGlSa0pSUDJ6?= =?utf-8?B?ZFZwWEZsRk1URXZZRVhCelRkR0EyWWJYMi9QTjk0aUlFcHJKV2VNMGtnY1F3?= =?utf-8?Q?3Z00uxRm/ZtTfXyUaOjNN/iM0jf1xWWTs2whzFQ?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB258425AF435E41881B028C14DA7F9BYAPR11MB2584namp_"
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: ef5afda2-d097-43a4-918d-08d8f1d35b33
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2021 10:22:14.2085 (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: wsMOHZFazIYtCeOHtBSXCLx4xFp/j6zd5pds7M+HkYIUjzKR174Df0jCOIqGMjdmZ5ZqLuMqMEbszbTHTVs7QQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2790
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/EW-8nbkQo4gWpM5SawqKZri7CxQ>
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: Sun, 28 Mar 2021 10:22:24 -0000

Hi Al,

Thanks much – and I fully agree that we need to keep the deployment and associated cost aspects in mind when designing a solution for IOAM data-fields integrity.  We should also acknowledge that while integrity protection might be considered important for some future deployment, current uses of early implementations of IOAM or similar are in “limited and isolated domains” and they do well without an integrity protection solution. So we’re talking about a “niche” for now, though one which might become more important in the future if IOAM would get applied to “not so trusted environments”.  We can expect integrity protection to add a non-negligible burden on a deployment – hence we need to come up with a solution that is modular enough, so that operators and implementors can choose how they cut the balance between “protection” and “cost”.

The ”Performance and Diagnostic Metrics (PDM) team” (Michael, Nalini) already reached out – with the plan to investigate whether we can’t create a single solution which would cover PDM and IOAM – something that everyone would for sure appreciate.

Per your (great!) suggestion, I’m cc’ing Ben for any help / pointers to additional folks who might be interested in helping us design an adequate solution.

Thanks, Frank

From: MORTON, ALFRED C (AL) <acm@research.att.com>
Sent: Samstag, 27. März 2021 18:38
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>om>; Tommy Pauly <tpauly@apple.com>om>; Tommy Pauly <tpauly@apple.com>om>; Shwetha <shwetha.bhandari@gmail.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

Hi Frank, Tommy, and all,

TL;DR: No solution, just trying to refine the problem statement and suggestion to seek SEC advice.

I haven’t followed the integrity discussions closely, but hearing the review of options at the IETF-110/IPPM session, and additional details for the options that Frank described below, it seems we could use some expert advice. There is a perpetual tension between protection from various attacks and the protocol performance achievable in practice, especially when considering per-packet integrity. IOW, if the security measures drag down too hard on performance, they won’t be used in practice.

In a successful end-game, we will have balanced the (possibly increased) risks inherent in the selected security measures with the practical per-packet implementation (requiring high packet-per-second rates, wide distribution, and other deployment needs).

I’m a very interested spectator here, because we may need to solve this problem again for packet streams used in high-capacity testing with widespread deployment.

So, advice in the form of a recommended solution to our particular problem with an acceptable level of risk, from SEC-Dir, SEC-ADs, or elsewhere, might help us winnow-down the choices.

hope this helps,
Al


From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank Brockners (fbrockne)
Sent: Saturday, March 27, 2021 10:54 AM
To: Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>>; Shwetha <shwetha.bhandari@gmail.com<mailto:shwetha.bhandari@gmail.com>>
Cc: IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: [ippm] Discussion on draft-brockners-ippm-ioam-data-integrity method 3 variant in @ietf110

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<mailto:tpauly@apple.com>>
Sent: Freitag, 26. März 2021 21:58
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>>; Shwetha <shwetha.bhandari@gmail.com<mailto:shwetha.bhandari@gmail.com>>; Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com>>
Cc: IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto: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<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm__;!!BhdT!04mWk9x-Ut5K0ecNHfnt8g_vEeQPXwZx8oP_51cSZNUP214MyjqOchkEeA3R$>

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm__;!!BhdT!04mWk9x-Ut5K0ecNHfnt8g_vEeQPXwZx8oP_51cSZNUP214MyjqOchkEeA3R$>