From nobody Wed Jan 12 11:48:39 2022 Return-Path: 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 A5A3A3A1A7B; Wed, 12 Jan 2022 11:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=apple.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 ygM0H3oZEEQc; Wed, 12 Jan 2022 11:48:33 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.rno.apple.com [17.179.253.38]) (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 2A21A3A1A79; Wed, 12 Jan 2022 11:48:33 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 20CJj0G9029634; Wed, 12 Jan 2022 11:48:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=noVFtfyliV328UPcZgsXqcn1gTVlUZmOhVgcHF6UKKE=; b=V52e5/hUtqkDKNSitvDFuLMy6n6Ek5xpZh7ykFzGkomikvgT64CotP+269zchGI0i3QT rb5PO9GGz3wsTZRZnVhgyrU8C9h6rDV0/HwGBApGw16OaG7FO0N/sYVyDqzxNZJv+uL8 rUR9O6/CYQN/D2qimVWoPhngAGgnX6tkCaxAxMUCKcoKyeJAToUNGXbDbQ0F6yPXdkpp qVF8pxqstes0w4fMWlXgr11FrG9iaPYgJmMrNUn3KzALj1Aboo0uWkYMU0QkNll+FpQc R4dqaxuSSSyS+2rbIbDSQnFcIg9EnwS9WhzCu4rfKNUKJszZCwokLILLv+vq3PK48VCQ vg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 3dj3dmsj1r-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Jan 2022 11:48:31 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5M00CCO4CU8740@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 12 Jan 2022 11:48:31 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5M00K0045M6H00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 12 Jan 2022 11:48:30 -0800 (PST) X-Va-A: X-Va-T-CD: e6091e616f2742cf5fde7f1935bb449e X-Va-E-CD: 0bcc6c31f70f3dc7506ef096334b6f2f X-Va-R-CD: d80fc7e42aa726f61d7c73ea7bd4fd87 X-Va-CD: 0 X-Va-ID: 5d0b919d-8a37-45ba-aef8-454d87d16034 X-V-A: X-V-T-CD: e6091e616f2742cf5fde7f1935bb449e X-V-E-CD: 0bcc6c31f70f3dc7506ef096334b6f2f X-V-R-CD: d80fc7e42aa726f61d7c73ea7bd4fd87 X-V-CD: 0 X-V-ID: 6d0915fb-1aa7-4efc-bd06-fd82944442a8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-12_05:2022-01-11, 2022-01-12 signatures=0 Received: from smtpclient.apple (unknown [17.11.168.226]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5M001F44CTGZ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 12 Jan 2022 11:48:30 -0800 (PST) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Tommy Pauly In-reply-to: <2064022850.261351660.1641927525018.JavaMail.zimbra@uliege.be> Date: Wed, 12 Jan 2022 11:48:29 -0800 Cc: ippm@ietf.org, draft-ietf-ippm-ioam-data-integrity@ietf.org Content-transfer-encoding: quoted-printable Message-id: <42B4FB74-4D64-4E9A-A3B2-6E5635CD9B0A@apple.com> References: <2064022850.261351660.1641927525018.JavaMail.zimbra@uliege.be> To: Justin Iurman X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-12_05:2022-01-11, 2022-01-12 signatures=0 Archived-At: Subject: Re: [ippm] draft-ietf-ippm-ioam-data-integrity X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 19:48:38 -0000 (No hats) My impression is that solution #2, where we protect the data fields = only, should be sufficient to address the integrity goals. Thanks, Tommy > On Jan 11, 2022, at 10:58 AM, Justin Iurman = wrote: >=20 > Hi all, >=20 > On behalf of the authors of draft-ietf-ippm-ioam-data-integrity, and = as a new > co-author, I wanted to share a key question that arose when working on = the next > version of the draft. Hope we can get some feedback or advice. >=20 > Currently, version -00 specifies that not only IOAM data fields are = protected > (i.e., signed) but also headers (both the IOAM Option-Type and the = Integrity > Protected Option-Type headers). Headers are signed by the encap node. = It is > indeed the most secure and complete solution. However, some header = fields are > updated in place between the encap and decap, which makes it = impossible to > include them in the signature or the validator won't be able to = recompute it. > For instance, as defined in draft-ietf-ippm-ioam-data, it is the case = for the > Trace Option-Type with its Flags field (especially the Overflow bit) = and its > RemainingLen field. The problem is potentially equivalent for the POT > Option-Type and its future "Flags", depending on their definitions = (note that > the Cumulative field, which is a data field, must be excluded no = matter what, > for the exact same reason as mentioned above). Therefore, we can think = of two > solutions, although solution #2 would have our vote. >=20 > Solution #1: include headers in the signature, exclude header fields = that are > updated in place. > * pros: > - some header fields are protected. > * cons: > - requires to define which fields to include/exclude in/from the = signature, > and so for each Option-Type header. > - more processing due to non-contiguous fields to include, = potentially. >=20 > Solution #2: exclude headers (both the IOAM Option-Type and the = Integrity > Protected Option-Type) from the signature. > * pros: > - avoids cons from solution #1. > * cons: > - headers are not protected. >=20 > Based on this tradeoff, we'd go for #2. It actually makes sense, as = the draft is > about "Integrity of In-situ OAM Data Fields". Of course, one could = argue that > some header fields bring context to data fields and, if altered, could > potentially trick nodes on the path (e.g., Namespace-ID). This is = true, and it's > also exactly why we bring this discussion to the list, so that we can = reach a > consensus on the best solution to adopt. FYI, = draft-ietf-ippm-ioam-data has a > section which states that in case you're looking for integrity = protection, you > can consider the data-integrity draft, or rely on the encapsulating = protocol. > The latter is therefore a solution for #2. >=20 > Thanks, > Justin >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm