[ippm] draft-ietf-ippm-ioam-data-integrity
Justin Iurman <justin.iurman@uliege.be> Tue, 11 January 2022 18:59 UTC
Return-Path: <justin.iurman@uliege.be>
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 E84EE3A07F0; Tue, 11 Jan 2022 10:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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=uliege.be
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 qFtZJlStFVtp; Tue, 11 Jan 2022 10:59:05 -0800 (PST)
Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EE83A0802; Tue, 11 Jan 2022 10:58:47 -0800 (PST)
Received: from mbx12-zne.ulg.ac.be (serv470.segi.ulg.ac.be [139.165.32.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by serv108.segi.ulg.ac.be (Postfix) with ESMTPS id 2BF48200E7D1; Tue, 11 Jan 2022 19:58:45 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 serv108.segi.ulg.ac.be 2BF48200E7D1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uliege.be; s=ulg20190529; t=1641927525; bh=Br1WgSqvbW/B/cw8DLrhEm1qUweoJ8s/nbrFQ3aclh8=; h=Date:From:Reply-To:To:Cc:Subject:From; b=SlsMhryMcCp+MFaTSekrEuhAp8vf262ujLlHqBZI4fQnyQB+OuZoQNpBQqTQpqHp3 69eeilXkChgPolwayCFies6Ia9hgVxZlUVMGeVeDGfJo6lLC7MOJD+6zaPkli8X/Ii fc5ALDpdazn8R4zM7gMY5vNSO60FQ3NYf7/EnxSxT8+zrb6Vg+M54uwVhHIFRMoRQS 3Ub0llW+8Gq+tcNem/2pTC1aSz1QK4ncBYv2Th2RHtoQZDy2uK9Xyi/eWr1wfXoYEy m0Jen22npNKgolwUsStybBE1nHdSgs2YkHsQFj1koa96XzA2XnfkwKBuF7y5RRFqxD nsN90cpDRcKgQ==
Received: from localhost (localhost [127.0.0.1]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 2674F60415BEB; Tue, 11 Jan 2022 19:58:45 +0100 (CET)
Received: from mbx12-zne.ulg.ac.be ([127.0.0.1]) by localhost (mbx12-zne.ulg.ac.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IZTJRex08BUT; Tue, 11 Jan 2022 19:58:45 +0100 (CET)
Received: from mbx12-zne.ulg.ac.be (mbx12-zne.ulg.ac.be [139.165.32.199]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 138BD6008D415; Tue, 11 Jan 2022 19:58:45 +0100 (CET)
Date: Tue, 11 Jan 2022 19:58:45 +0100
From: Justin Iurman <justin.iurman@uliege.be>
Reply-To: Justin Iurman <justin.iurman@uliege.be>
To: ippm@ietf.org
Cc: draft-ietf-ippm-ioam-data-integrity@ietf.org
Message-ID: <2064022850.261351660.1641927525018.JavaMail.zimbra@uliege.be>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [81.240.24.148]
X-Mailer: Zimbra 8.8.15_GA_4018 (ZimbraWebClient - FF95 (Linux)/8.8.15_GA_4026)
Thread-Index: PflMqkAsq+YH5JjkbuCX083ZTm6Z/Q==
Thread-Topic: draft-ietf-ippm-ioam-data-integrity
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Xuz3hBJ0zXwwBABvXlkmKeT4sYA>
Subject: [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 <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: Tue, 11 Jan 2022 18:59:10 -0000
Hi all, 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. 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. 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. 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. 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. Thanks, Justin
- Re: [ippm] draft-ietf-ippm-ioam-data-integrity Tommy Pauly
- [ippm] draft-ietf-ippm-ioam-data-integrity Justin Iurman