Subject: [ippm] draft-ietf-ippm-ioam-data-integrity

From: Justin Iurman <[email-masked]>
Date: Tue, 11 Jan 2022 19:58:45 +0100 (CET)

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

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 12 Jan 2022 11:48:29 -0800

(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 <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm