[ippm] Update on draft-ietf-ippm-ioam-data-integrity

Justin Iurman <justin.iurman@uliege.be> Sat, 24 February 2024 15:13 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 011C3C14F5FC; Sat, 24 Feb 2024 07:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.404
X-Spam-Level:
X-Spam-Status: No, score=-4.404 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu3nkqaHEWnd; Sat, 24 Feb 2024 07:13:29 -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 F1990C14F5E4; Sat, 24 Feb 2024 07:13:27 -0800 (PST)
Received: from [192.168.1.55] (125.179-65-87.adsl-dyn.isp.belgacom.be [87.65.179.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by serv108.segi.ulg.ac.be (Postfix) with ESMTPSA id 2B2E5200BE55; Sat, 24 Feb 2024 16:13:25 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 serv108.segi.ulg.ac.be 2B2E5200BE55
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uliege.be; s=ulg20190529; t=1708787605; bh=Qm9qI7waS6TlOb8eNEPytm03ZSrYcwDCQQjN5Gl8JXg=; h=Date:To:Cc:From:Subject:From; b=rE/nJCsswKGWhFKdSwi8ayPOvnbMVvcaZReGYtt5ckpFg/vqg+atqnCoQ/6E2eyc3 jqO54+C01BvcBcY9mI3f7uoGaZio9YjVXa6x+ITyTGqQxoOr6eAiatigJqtNJV2UxP 3398/lTRNZ15JKFBT2dW/FX3zDvI+9Df/alG1PTHkHNNGttAv462f7v54pVJuSQ+E5 /fpinYo0RL8AdsaSCrelSAQhZ4vi+nMWqJKfL5liOf2BkFDRvAYqez7NR+kVeSX6Wn AVq+z2/KR35NVY2KPfyDZVwxp/iNu1xknunEu/BlSWrsh2tl5lCldhvdF1kSgXSDT1 mwIc2BUT3RGYA==
Message-ID: <93d0ecf7-89a3-4370-98b0-8549eba4fa9e@uliege.be>
Date: Sat, 24 Feb 2024 16:13:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: IETF IPPM WG <ippm@ietf.org>
Cc: IPPM Chairs <ippm-chairs@ietf.org>
From: Justin Iurman <justin.iurman@uliege.be>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/iZ2Kg-GC71M6LfKR3rCaa7U2KA8>
Subject: [ippm] Update on draft-ietf-ippm-ioam-data-integrity
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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, 24 Feb 2024 15:13:34 -0000

Hi folks,

Following secdir review, we are working on a draft revision. We would 
like to share different solutions, based on trade-offs we are facing, 
and get some feedback/opinions from the WG. The real challenge is to 
have something deployable/efficient for the integrity protection of 
Trace Option-Types (other Option-Types are OK), and which does the 
expected job. Right now, we have three possibilities for Trace 
Option-Types, each listed with their pros and cons:

1) Current method proposed in the document, i.e., a full chain 
validation at the end (i.e., on the Validator).

(+) full integrity protection
(-) not efficient
(-) consumes more bytes, different header compared to other Option-Types

This solution is messy but does the (full, expected) job. It does not 
trust any nodes (even IOAM ones) and would detect any compromised nodes. 
Why is it messy? Because the entire chain validation is performed at the 
end on the Validator, which is of course not efficient, and because it 
requires an additional Nonce/ICV to distinguish the integrity of the 
header and IOAM-Data-Fields (i.e., each transit nodes must be able to 
check the header integrity independently). Note that the Validator 
problem could be mitigated by, e.g., (i) having the Validator out of the 
forwarding path and (ii) having multiple Validators.

2) Ben's suggestion, i.e., a per hop validation.

(+) more efficient than solution 1
(+) same integrity header for all Option-Types
(-) partial integrity protection (i.e., we trust IOAM nodes)

This solution solves all problems encountered in solution 1 and is 
elegant, *but* it does "half" the job (i.e., we trust IOAM nodes, which 
means that if an IOAM node is compromised, we wouldn't be able to detect 
tampered IOAM data).

3) IPsec (i.e., sunset this draft).

+ pragmatic approach which does not require any new protocol definition
+ less overhead than solution 1
- requires additional configuration effort (setup IPsec tunnels)
- partial integrity protection (i.e., we trust IOAM nodes)

This solution is quite similar to what solution 2 proposes, here without 
the need for a new protocol, but which probably introduces more 
overhead. For each link that connects to nodes, configure an associate 
IPsec connection - and implement IOAM on top of the IPsec topology. As a 
result, each link will be encrypted and/or integrity checked and man in 
the middle attacks are not feasible. Which also means that we would 
sunset this draft.


So I guess it all comes down to choosing between solution 1 and solution 
3 (solution 2 may be better than solution 3 but, given the similarities, 
solution 3 would probably be chosen for simplicity). The key question 
is: do we want full or partial integrity protection? And, based on that, 
consider the impact of such a choice: is it efficient and/or deployable?

We would really appreciate your comments or feedback on this.

Thanks,
Justin