Skip to main content

Integrity of In-situ OAM Data Fields
draft-ietf-ippm-ioam-data-integrity-09

Document Type Active Internet-Draft (ippm WG)
Authors Frank Brockners , Shwetha Bhandari , Tal Mizrahi , Justin Iurman
Last updated 2024-07-05
Replaces draft-brockners-ippm-ioam-data-integrity
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ippm-ioam-data-integrity-09
ippm                                                        F. Brockners
Internet-Draft                                                     Cisco
Intended status: Standards Track                             S. Bhandari
Expires: 6 January 2025                                      Thoughtspot
                                                              T. Mizrahi
                                                                  Huawei
                                                               J. Iurman
                                                     Universite de Liege
                                                             5 July 2024

                  Integrity of In-situ OAM Data Fields
                 draft-ietf-ippm-ioam-data-integrity-09

Abstract

   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in the packet while the packet
   traverses a path in the network.  IETF protocols require features
   that can provide secure operation.  This document describes the
   integrity protection of IOAM-Data-Fields.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 January 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Brockners, et al.        Expires 6 January 2025                 [Page 1]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Threat Analysis . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Modification: IOAM-Data-Fields  . . . . . . . . . . . . .   5
     3.2.  Modification: IOAM Option-Type headers  . . . . . . . . .   5
     3.3.  Injection: IOAM-Data-Fields . . . . . . . . . . . . . . .   6
     3.4.  Injection: IOAM Option-Type headers . . . . . . . . . . .   6
     3.5.  Replay  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.6.  Management and Exporting  . . . . . . . . . . . . . . . .   7
     3.7.  Delay . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.8.  Threat Summary  . . . . . . . . . . . . . . . . . . . . .   8
   4.  Integrity Protected Option-Types  . . . . . . . . . . . . . .   8
     4.1.  Trace Integrity Protected Option-Types  . . . . . . . . .  10
     4.2.  POT Integrity Protected Option-Type . . . . . . . . . . .  10
     4.3.  E2E Integrity Protected Option-Type . . . . . . . . . . .  11
   5.  Integrity Protection Method . . . . . . . . . . . . . . . . .  12
     5.1.  Encapsulating node  . . . . . . . . . . . . . . . . . . .  12
       5.1.1.  Selection of header fields  . . . . . . . . . . . . .  13
     5.2.  Transit node  . . . . . . . . . . . . . . . . . . . . . .  14
     5.3.  Decapsulating node  . . . . . . . . . . . . . . . . . . .  14
     5.4.  Validator . . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  IOAM Option-Types . . . . . . . . . . . . . . . . . . . .  15
     6.2.  IOAM Integrity Protection Method Suite  . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   "In-situ" Operations, Administration, and Maintenance (IOAM) records
   OAM information within the packet while the packet traverses a
   particular network domain.  The term "in-situ" refers to the fact
   that the OAM data is added to the data packets rather than being sent
   within packets specifically dedicated to OAM.  IOAM is to complement
   mechanisms such as Ping or Traceroute.  In terms of "active" or

Brockners, et al.        Expires 6 January 2025                 [Page 2]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   "passive" OAM, "in-situ" OAM can be considered a hybrid OAM type.
   "In-situ" mechanisms do not require extra packets to be sent.  IOAM
   adds information to the already available data packets and therefore
   cannot be considered passive.  In terms of the classification given
   in [RFC7799], IOAM could be portrayed as Hybrid Type I.  IOAM
   mechanisms can be leveraged where mechanisms using, e.g., ICMP do not
   apply or do not offer the desired results, such as verifying that a
   certain traffic flow takes a pre-defined path, SLA verification for
   the data traffic, detailed statistics on traffic distribution paths
   in networks that distribute traffic across multiple paths, or
   scenarios in which probe traffic is potentially handled differently
   from regular data traffic by the network devices.

   IOAM MUST be deployed in an IOAM-Domain.  An IOAM-Domain is a set of
   nodes that use IOAM.  An IOAM-Domain is bounded by its perimeter or
   edge.  It is expected that all nodes in an IOAM-Domain are managed by
   the same administrative entity, that has means to select, monitor,
   and control the access to all the networking devices.  As such, IOAM-
   Data-Fields are carried in the clear within packets and there are no
   protections against any node or middlebox tampering with the data.
   IOAM-Data-Fields collected in an untrusted or semi-trusted
   environment require integrity protection to support critical
   operational decisions.  Please refer to [RFC9197] for more details on
   IOAM-Domains.

   Since arbitrary nodes and middleboxes can tamper with all packets
   data, including IOAM-Data-Fields, and the packets are (in general)
   processed by other intermediary nodes before they could arrive at a
   node that can verify the IOAM fields of the packet, there is little
   value in attempting to use cryptographic mechanisms to prevent such
   modifications to the IOAM fields in the packet.  Instead, we limit
   ourselves to the "detectability problem", namely, to allow an
   endpoint to detect that such modification has occurred since the
   generation of the IOAM-Data-Fields.  In addition to this
   detectability problem, the following considerations and requirements
   are to be taken into account in constructing an IOAM integrity
   mechanism:

   1.  IOAM data is processed by the data plane, hence viability of any
       method to prove integrity of the IOAM-Data-Fields must be
       feasible at data plane processing/forwarding rates (IOAM might be
       applied to all traffic a router forwards).

   2.  IOAM data is carried within packets.  Additional space required
       to prove integrity of the IOAM-Data-Fields SHOULD be optimal,
       i.e., SHOULD not exceed the Maximum Transmission Unit (MTU) or
       have adverse effect on packet processing.

Brockners, et al.        Expires 6 January 2025                 [Page 3]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   3.  Protection against replay of old IOAM data SHOULD be possible.
       Without replay protection, a rogue node can present the old IOAM
       data, masking any ongoing network issues/activity and making the
       IOAM-Data-Fields collection useless.

   This document defines a method to protect the integrity of IOAM-Data-
   Fields, using the IOAM Option-Types specified in [RFC9197] and
   [RFC9326] as an example.  The method will similarly apply to future
   IOAM Option-Types.

2.  Conventions

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Abbreviations

   Abbreviations used in this document:

   OAM:       Operations, Administration, and Maintenance

   IOAM:      In-situ OAM

   POT:       Proof of Transit

   E2E:       Edge to Edge

   DEX:       Direct Exporting

3.  Threat Analysis

   This section presents a threat analysis of integrity-related threats
   in the context of IOAM.  The threats that are discussed are assumed
   to be independent of the lower layer protocols; it is assumed that
   threats at other layers are handled by security mechanisms that are
   deployed at these layers.

   This document is focused on integrity protection for IOAM-Data-
   Fields.  Thus the threat analysis includes threats that are related
   to or result from compromising the integrity of IOAM-Data-Fields.
   Other security aspects such as confidentiality are not within the
   scope of this document.

Brockners, et al.        Expires 6 January 2025                 [Page 4]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   Throughout the analysis there is a distinction between on-path and
   off-path attackers.  As discussed in [RFC9055], on-path attackers are
   located in a position that allows interception and modification of
   in-flight protocol packets, whereas off-path attackers can only
   attack by generating protocol packets.

   The analysis also includes the impact of each of the threats.
   Generally speaking, the impact of a successful attack on an OAM
   protocol [RFC7276] is an illusion of nonexistent failures or
   preventing the detection of actual ones; in both cases, the attack
   may result in denial of service (DoS).  Furthermore, creating the
   illusion of a nonexistent issue may trigger unnecessary processing in
   some of the IOAM nodes along the path, and may cause more IOAM-
   related data to be exported to the management plane than is
   conventionally necessary.  Beyond these general impacts, threat-
   specific impacts are discussed in each of the subsections below.

3.1.  Modification: IOAM-Data-Fields

   Threat

      An on-path attacker can modify the IOAM-Data-Fields of in-transit
      packets.  The modification can either be applied to all packets or
      selectively applied to a subset of the en route packets.
      Maliciously modified IOAM-Data-Fields can for example mislead
      network diagnostics, result in incorrect network performance
      metrics, or could misguide network optimization efforts.

   Impact

      By systematically modifying the IOAM-Data-Fields of some or all of
      the in-transit packets, an attacker can create a fake picture of
      the network status.  Potential consequences include an impact on
      network performance, a change in the recorded forwarding path of
      packets, either based on fake node positions or fake data provided
      by the attacker to fool the system that ingests IOAM-Data-Fields.

3.2.  Modification: IOAM Option-Type headers

   Threat

      An on-path attacker can modify the header in IOAM Option-Types in
      order to change or disrupt the behavior of nodes processing IOAM-
      Data-Fields along the path.

   Impact

Brockners, et al.        Expires 6 January 2025                 [Page 5]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

      Changing the header of existing IOAM Option-Types, just like it is
      assumed for future IOAM Option-Types, may have several
      implications.  The following list of examples is not exhaustive,
      and is based on IOAM Option-Types defined in [RFC9197] and
      [RFC9326].  An attacker could maliciously increase the processing
      overhead in nodes that process IOAM-Data-Fields and increase the
      on-the-wire overhead of IOAM-Data-Fields, by modifying the IOAM-
      Trace-Type field in the IOAM Trace Option-Type header.  An
      attacker could also prevent some of the nodes that process IOAM-
      Data-Fields from incorporating IOAM-Data-Fields, by modifying the
      RemainingLen field in the IOAM Trace Option-Type header.  Another
      possibility for the attacker is to change the definition or
      interpretation of IOAM-Data-Fields by modifying the Namespace-ID
      field, which is common to all IOAM Option-Type headers.  For IOAM-
      Namespaces, please refer to [RFC9197], Section 4.2.  Without the
      right context (i.e., Namespace-ID), IOAM-Data-Fields become
      meaningless, just like data without metadata.  An attacker could
      also set the Loopback flag in the IOAM Trace Option-Type header so
      that packet copies would be sent back by each node to the
      encapsulating node.  Note that the modification of the header can
      lead to similar impacts described in Section 3.1.

3.3.  Injection: IOAM-Data-Fields

   Threat

      An attacker can inject packets with IOAM Option-Types and IOAM-
      Data-Fields.  This threat is applicable to both on-path and off-
      path attackers.

   Impact

      This attack and its impacts are similar to Section 3.1.

3.4.  Injection: IOAM Option-Type headers

   Threat

      An attacker can inject packets with IOAM Option-Type headers, thus
      manipulating other nodes that process IOAM-Data-Fields in the
      network.  This threat is applicable to both on-path and off-path
      attackers.

   Impact

      This attack and its impacts are similar to Section 3.2.

Brockners, et al.        Expires 6 January 2025                 [Page 6]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

3.5.  Replay

   Threat

      In addition to replaying old packets in general, an attacker can
      replay packets with IOAM-Data-Fields.  Specifically, an attacker
      may replay a previously transmitted IOAM Option-Type with a new
      data packet, therefore attaching old IOAM-Data-Fields to a fresh
      user packet.  This threat is applicable to both on-path and off-
      path attackers.

   Impact

      The impacts of this attack are similar to those described in
      Section 3.1.

3.6.  Management and Exporting

   Threat

      Attacks that compromise the integrity of IOAM-Data-Fields can be
      applied at the management plane, e.g., by manipulating network
      management packets.  Furthermore, the integrity of IOAM-Data-
      Fields that are exported to a receiving entity can also be
      compromised.  Management plane attacks are not within the scope of
      this document; the network management protocol is expected to
      include inherent security capabilities.  The integrity of exported
      data is also not within the scope of this document.  It is
      expected that the specification of the export format will discuss
      the relevant security aspects.

   Impact

      Malicious manipulation of the management protocol can cause nodes
      that process IOAM-Data-Fields to malfunction, to be overloaded, or
      to incorporate unnecessary IOAM-Data-Fields into user packets.
      The impact of compromising the integrity of exported IOAM-Data-
      Fields is similar to the impacts of previous threats that were
      described in this section.

3.7.  Delay

   Threat

      An on-path attacker may delay some or all of the in-transit
      packets that include IOAM-Data-Fields in order to create an
      illusion of congestion.  Delay attacks are well known in the
      context of deterministic networks [RFC9055] and time

Brockners, et al.        Expires 6 January 2025                 [Page 7]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

      synchronization [RFC7384], and may be somewhat mitigated in these
      environments by using redundant paths in a way that is resilient
      to an attack along one of the paths.  This approach does not
      address the threat in the context of IOAM, as it does not meet the
      requirement to measure a specific path or to detect a problem
      along the path.  Note that the mechanisms in this document do not
      attempt to provide any mitigation against this threat.

   Impact

      Since IOAM can be applied to a fraction of the traffic, an
      attacker can detect and delay only the packets that include IOAM-
      Data-Fields, thus preventing the authenticity of delay and load
      measurements.

3.8.  Threat Summary

   +-------------------------------------------+--------+------------+
   | Threat                                    |In scope|Out of scope|
   +-------------------------------------------+--------+------------+
   |Modification: IOAM-Data-Fields             |   +    |            |
   +-------------------------------------------+--------+------------+
   |Modification: IOAM Option-Type headers     |   +    |            |
   +-------------------------------------------+--------+------------+
   |Injection: IOAM-Data-Fields                |   +    |            |
   +-------------------------------------------+--------+------------+
   |Injection: IOAM Option-Type headers        |   +    |            |
   +-------------------------------------------+--------+------------+
   |Replay                                     |   +    |            |
   +-------------------------------------------+--------+------------+
   |Management and Exporting                   |        |     +      |
   +-------------------------------------------+--------+------------+
   |Delay                                      |        |     +      |
   +-------------------------------------------+--------+------------+

                     Figure 1: Threat Analysis Summary

4.  Integrity Protected Option-Types

   This section defines new IOAM Option-Types.  Their purpose is to
   carry IOAM-Data-Fields with integrity protection.  All existing IOAM
   Option-Types defined in [RFC9197] are extended as follows:

   64  IOAM Pre-allocated Trace Integrity Protected Option-Type:
      corresponds to the IOAM Pre-allocated Trace Option-Type
      ([RFC9197]) with integrity protection.

Brockners, et al.        Expires 6 January 2025                 [Page 8]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   65  IOAM Incremental Trace Integrity Protected Option-Type:
      corresponds to the IOAM Incremental Trace Option-Type ([RFC9197])
      with integrity protection.

   66  IOAM POT Integrity Protected Option-Type: corresponds to the IOAM
      POT Option-Type ([RFC9197]) with integrity protection.

   67  IOAM E2E Integrity Protected Option-Type: corresponds to the IOAM
      E2E Option-Type ([RFC9197]) with integrity protection.

   The Direct Export (DEX) Option-Type [RFC9326] is not covered by the
   Integrity Protection Method defined in this document (see Section 5).
   This document focuses on the integrity protection of IOAM-Data-
   Fields, while DEX does not have IOAM-Data-Fields by definition.
   Therefore, DEX is considered out of scope for this document.  DEX, as
   well as any IOAM Option-Type without IOAM-Data-Fields, MUST NOT use
   the Integrity Protection Method defined in this document.

   The IOAM Integrity Protection header follows the IOAM Option-Type
   header and precedes IOAM-Data-Fields, when the IOAM Option-Type is an
   Integrity Protected Option-Type.  It is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Method-ID   |  Nonce Length |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  Integrity Check Value (ICV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: IOAM Integrity Protection header

   Method-ID:  8-bit unsigned integer.  It defines the Integrity
      Protection Method to compute the Integrity Check Value (ICV)
      field.  If a node encounters an unknown value, it MUST NOT change
      the contents of the IOAM Integrity Protection header and MUST NOT
      change the contents of the IOAM-Data-Fields.  In other words, the
      node MUST NOT process the IOAM Option-Type.  See Section 6.2.

   Nonce Length:  8-bit unsigned integer.  It defines the length of the
      Nonce field, in octets.

Brockners, et al.        Expires 6 January 2025                 [Page 9]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   Reserved:  16-bit Reserved field.  It MUST be set to zero upon
      transmission and ignored upon receipt.

   Nonce:  Variable length field.  Its size depends on the Nonce Length
      field.

   Integrity Check Value (ICV):  Variable length field.  Its size
      depends on the Method-ID field.

   In order to keep IOAM-Data-Fields aligned, the total length of the
   IOAM Integrity Protection header MUST be a multiple of 4 octets.

4.1.  Trace Integrity Protected Option-Types

   Both the IOAM Pre-allocated Trace Option-Type header and the IOAM
   Incremental Trace Option-Type header, as defined in [RFC9197], are
   followed by the IOAM Integrity Protection header when the IOAM
   Option-Type is respectively set to the IOAM Pre-allocated Trace
   Integrity Protected Option-Type or the IOAM Incremental Trace
   Integrity Protected Option-Type:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Namespace-ID          | NodeLen | Flags | RemainingLen|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IOAM-Trace-Type                |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Method ID   |  Nonce length |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  Integrity Check Value (ICV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       IOAM-Data-Fields                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.  POT Integrity Protected Option-Type

   The IOAM POT Option-Type header, as defined in [RFC9197], is followed
   by the IOAM Integrity Protection header when the IOAM Option-Type is
   set to the IOAM POT Integrity Protected Option-Type:

Brockners, et al.        Expires 6 January 2025                [Page 10]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Namespace-ID          | IOAM-POT-Type | IOAM-POT-Flags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Method ID   |  Nonce length |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  Integrity Check Value (ICV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       IOAM-Data-Fields                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.  E2E Integrity Protected Option-Type

   The IOAM E2E Option-Type header, as defined in [RFC9197], is followed
   by the IOAM Integrity Protection header when the IOAM Option-Type is
   set to the IOAM E2E Integrity Protected Option-Type:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Namespace-ID          |         IOAM-E2E-Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Method ID   |  Nonce length |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  Integrity Check Value (ICV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       IOAM-Data-Fields                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Brockners, et al.        Expires 6 January 2025                [Page 11]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

5.  Integrity Protection Method

   This document defines a new method that uses a symmetric key based
   algorithm for the integrity protection of IOAM-Data-Fields.  The
   method MUST use AES-GMAC ([NIST.800-38D]), a block cipher mode of
   operation providing data origin authentication, which is also a
   specialization of the Galois/Counter Mode (GCM).  The GCM
   authenticated encryption operation has four inputs: a secret key, an
   Initialization Vector (IV), a plaintext, and Additional Authenticated
   Data (AAD).  It has two outputs: a ciphertext whose length is
   identical to the plaintext and an Authentication Tag. GMAC is the
   special case of GCM in which the plaintext has a length of zero.
   Therefore, the empty ciphertext output is ignored, and the only
   output is the Authentication Tag.

   In this method, the AES-GMAC Authentication Tag MUST NOT be
   truncated, meaning its size MUST always be 16 octets (i.e., a full
   Authentication Tag).  More security recommendations are discussed in
   Section 7.  Below, we refer to the AES-GMAC Initialization Vector
   (IV) as the nonce, and to the AES-GMAC Authentication Tag as the
   Integrity Check Value (ICV).

5.1.  Encapsulating node

   The encapsulating node generates a nonce and stores it in the Nonce
   field of the IOAM Integrity Protection header (the Nonce length field
   is set accordingly).  It MUST be a 12-octet nonce, based on the
   "Deterministic Construction" (see Section 7).  The Method ID field
   MUST be set to 1, as defined in Section 6.2.

   The Integrity Check Value (ICV) is the result of a GMAC operation
   over a selection of header fields (see Section 5.1.1) and immutable
   IOAM-Data-Fields added by the encapsulating node.  With the nonce
   provided to GMAC, the encapsulating node performs the following
   operation:

   *  AAD = (header fields || node's immutable IOAM-Data-Fields)

   *  ICV = GMAC(AAD)

   The encapsulating node stores the ICV in the corresponding field of
   the IOAM Integrity Protection header.

Brockners, et al.        Expires 6 January 2025                [Page 12]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

5.1.1.  Selection of header fields

   The main objective of the Integrity Protection Method defined in this
   document is to provide integrity protection of IOAM-Data-Fields.
   However, some Option-Type header fields are crucial for IOAM-Data-
   Fields.  Without them, IOAM-Data-Fields are meaningless.  Therefore,
   the integrity of such header fields MUST be protected too.

   For Trace Option-Types, here is the list of header fields that
   participate (in that order) in the integrity protection of IOAM-Data-
   Fields:

   1.  Namespace-ID

   2.  IOAM-Trace-Type

   The NodeLen field is not included in the list because it can be
   deduced from the IOAM-Trace-Type field.  Other header fields that are
   not included in the list are either mutable or only useful for
   processing Trace Option-Types (i.e., they don't provide context or
   meaning to IOAM-Data-Fields).

   For a POT Option-Type, here is the list of header fields that
   participate (in that order) in the integrity protection of IOAM-Data-
   Fields:

   1.  Namespace-ID

   2.  IOAM-POT-Type

   Other header fields that are not included in the list are either
   mutable or only useful for processing a POT Option-Type (i.e., they
   don't provide context or meaning to IOAM-Data-Fields).

   For a E2E Option-Type, here is the list of header fields that
   participate (in that order) in the integrity protection of IOAM-Data-
   Fields:

   1.  Namespace-ID

   2.  IOAM-E2E-Type

   Those are all the header fields defined for a E2E Option-Type.

Brockners, et al.        Expires 6 January 2025                [Page 13]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   New IOAM Integrity Protected Option-Types that intend to use the
   Integrity Protection Method defined in this document MUST also
   specify a list of corresponding Option-Type header fields that
   participate in the integrity protection of IOAM-Data-Fields, as
   above.  The same logic can be applied to select header fields, by
   following this simple rule:

   *  Only immutable IOAM Option-Type header fields that provide context
      or meaning to IOAM-Data-Fields are considered, others are excluded
      (e.g., mutable or reserved fields).  For example, the Namespace-
      ID, which is common to all IOAM Option-Types, MUST always be
      included in the list.  Once specified, the list MUST NOT change
      for interoperability reasons.

5.2.  Transit node

   For a transit node, the Integrity Check Value (ICV) is the result of
   a GMAC operation over the received ICV field and immutable IOAM-Data-
   Fields added by the transit node.  With the received Nonce field
   provided to GMAC, the transit node performs the following operation:

   *  AAD = (ICV field || node's immutable IOAM-Data-Fields)

   *  ICV = GMAC(AAD)

   The transit node updates the ICV field in the IOAM Integrity
   Protection header.

   A transit node MUST NOT add or remove the IOAM Integrity Protection
   header.

5.3.  Decapsulating node

   The decapsulating node MAY perform the function of the Validator.  If
   it does, please refer to Section 5.4.

   If the decapsulating node does not perform the function of the
   Validator, which is an alternative to put the Validator out of the
   forwarding path in case of performance concerns, the decapsulating
   node MUST send the entire IOAM Integrity Protected Option-Type to the
   Validator.  The method to send it to the Validator is out of scope
   for this document.  Before that, the decapsulating node updates the
   ICV field in the IOAM Integrity Protection header.  The Integrity
   Check Value (ICV) is the result of a GMAC operation over the received
   ICV field and immutable IOAM-Data-Fields added by the decapsulating
   node.  With the received Nonce field provided to GMAC, the
   decapsulating node performs the following operation:

Brockners, et al.        Expires 6 January 2025                [Page 14]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   *  AAD = (ICV field || node's immutable IOAM-Data-Fields)

   *  ICV = GMAC(AAD)

   The decapsulating node MUST NOT add the IOAM Integrity Protection
   header.

5.4.  Validator

   A node that performs the validation of the integrity protection is
   referred to as the Validator.  This method assumes that symmetric
   keys have been distributed to the Validator only.  The details of the
   mechanisms used for key distribution are outside the scope of this
   document.  We refer to the method as "Zero Trust" in the sense that
   neither the encapsulating node, nor transit nodes, nor any other non-
   IOAM nodes need to be trusted.  The Validator is the only point of
   trust, meaning the method is considered a full integrity protection
   of IOAM-Data-Fields.

   The Validator MUST recompute the ICV by iteratively following the
   previous steps of the method in the same order, using the respective
   symmetric keys received previously.  The recomputed ICV is then
   compared to the received ICV field.  As a result, the Validator can
   detect if the integrity of IOAM-Data-Fields is intact or altered.
   The validation is one-step in some cases (e.g., with POT Type-0 or
   E2E), where only the encapsulating node updates the ICV, according to
   the definition of this method.  For other cases where transit nodes
   also update the ICV (e.g., with Trace Option-Types), the Validator
   MUST identify these transit nodes in order to look up their
   respective keys.  For that, a unique identifier of the node, such as
   the "node_id" for Trace Option-Types, MUST be included in IOAM-Data-
   Fields.  Whatever the Option-Type, the nonce allows the encapsulating
   node to be identified (see Section 7).  Details on how the mapping
   between those identifiers and keys is implemented on the Validator
   are outside the scope of this document.

   The Validator MUST NOT update the ICV field in the IOAM Integrity
   Protection header.  Since its role is to validate the integrity of
   IOAM-Data-Fields, it trusts itself whether it adds IOAM-Data-Fields
   or not.

6.  IANA Considerations

6.1.  IOAM Option-Types

   IANA is requested to define the following new code points in the
   "IOAM Option-Type" registry:

Brockners, et al.        Expires 6 January 2025                [Page 15]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   64  IOAM Pre-allocated Trace Integrity Protected Option-Type (see
      Section 4)

   65  IOAM Incremental Trace Integrity Protected Option-Type (see
      Section 4)

   66  IOAM POT Integrity Protected Option-Type (see Section 4)

   67  IOAM E2E Integrity Protected Option-Type (see Section 4)

   A document defining a new IOAM Integrity Protected Option-Type
   intended to use the method in this document MUST specify the
   corresponding IOAM Option-Type header fields involved in the
   integrity protection of IOAM-Data-Fields.  See Section 5.1.1 as an
   example.

6.2.  IOAM Integrity Protection Method Suite

   IANA is requested to define a new registry named "IOAM Integrity
   Protection Method Suite", inside the "In Situ OAM (IOAM)" registry
   group.

   This new registry defines 256 code points to identify IOAM Integrity
   Protection methods.  The following code points are defined in this
   document:

     ID     Description                           Reference
   +------+-------------------------------------+---------------+
   | 0x00 | Reserved                            | This document |
   +------+-------------------------------------+---------------+
   | 0x01 | Zero Trust (AES-GMAC, 16-octet ICV) | This document |
   +------+-------------------------------------+---------------+
   | 0x02 |                                     |               |
   | ...  | Unassigned                          |               |
   | 0xFE |                                     |               |
   +------+-------------------------------------+---------------+
   | 0xFF | Reserved                            | This document |
   +------+-------------------------------------+---------------+

              Figure 3: IOAM Integrity Protection Method Suite

   Code points 2-254 are available for assignment via the "IETF Review"
   process, as per [RFC8126].

   New registration requests MUST use the following template: the value
   of the requested code point, a description of the method, and a
   reference to the document defining the code point.

Brockners, et al.        Expires 6 January 2025                [Page 16]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

7.  Security Considerations

   Please refer to Section 3 for a threat analysis of integrity-related
   threats in the context of IOAM.

   The Integrity Protection Method defined in this document (see
   Section 5) leverages symmetric keys.  The symmetric keys need to be
   exchanged in a secure way between the nodes involved with integrity
   protection of IOAM-Data-Fields.  The details of the key exchange are
   outside the scope of this document.

   There is an additional per-packet processing for each node that uses
   the Integrity Protection Method defined in this document.
   Inappropriate use of this Integrity Protection Method might overload
   nodes and cause them to stop functioning properly.  Operators
   deploying IOAM with this Integrity Protection Method MUST ensure that
   such overload situations are avoided.  This could for example be
   achieved by applying IOAM only to a subset of the entire traffic,
   keeping in mind that only that subset would be integrity protected.

   To ensure integrity protection of IOAM-Data-Fields, the Integrity
   Protection Method defined in this document uses AES-GMAC
   ([NIST.800-38D]).  In that context, a generated key MUST be fresh.
   Another important requirement is that the same combination of a nonce
   (AES-GMAC IV) and a key MUST NOT be used more than once.  Otherwise,
   security guarantees are destroyed.  To avoid such scenario, and to
   avoid frequent rotation or refreshing of keys, a 12-octet nonce MUST
   be used, and the nonce MUST be based on the "Deterministic
   Construction" ([NIST.800-38D], Sec. 8) as follows:

   *  The nonce is the concatenation of two fields, called the fixed
      field and the invocation field.

   *  The fixed field identifies the device and MUST be unique (e.g.,
      the IOAM unique identifier of the device).

   *  The invocation field identifies the sets of inputs (i.e., packets)
      to the authenticated encryption function in that particular
      device, and MUST be unique for each packet.  It typically is
      either an integer counter or a linear feedback shift register that
      is driven by a primitive polynomial to ensure a maximal cycle
      length.  In either case, the invocation field increments upon each
      invocation of the authenticated encryption function.

   *  The leading (i.e., leftmost) 32 bits of the nonce MUST hold the
      fixed field, while the trailing (i.e., rightmost) 64 bits MUST
      hold the invocation field.  It means a limit of 2^32 distinct
      devices, and a limit of 2^64 invocations (i.e., packets) for a

Brockners, et al.        Expires 6 January 2025                [Page 17]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

      given key.  As an example, it would take 7 years for a key to
      reach the limit of 2^64 with 1500-byte packets on a 1 Pbps
      (Petabits per second) link, while it would take 170 days with
      100-byte packets.

   The nonce makes an ICV (AES-GMAC Authentication Tag) unique but does
   not necessarily prevent replay attacks.  To enable replay protection,
   the encapsulating node and the Validator MUST agree on a common
   methodology to keep the nonce valid only for a specific period of
   time, which is outside the scope of this document.  However, a
   suggestion would be to put a 64-bit timestamp in the invocation field
   of the nonce, based on the above recommendations.

8.  Acknowledgements

   The authors would like to thank Santhosh N, Rakesh Kandula, Saiprasad
   Muchala, Al Morton, Greg Mirsky, Benjamin Kaduk, Mehmet Beyaz, and
   Martin Duke for their comments and advice.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [NIST.800-38D]
              National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC",  NIST Special
              Publication 800-38D, 2001,
              <http://csrc.nist.gov/publications/nistpubs/800-38D/SP-
              800-38D.pdf>.

Brockners, et al.        Expires 6 January 2025                [Page 18]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   [RFC7276]  Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
              Weingarten, "An Overview of Operations, Administration,
              and Maintenance (OAM) Tools", RFC 7276,
              DOI 10.17487/RFC7276, June 2014,
              <https://www.rfc-editor.org/info/rfc7276>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/info/rfc7384>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.

   [RFC9055]  Grossman, E., Ed., Mizrahi, T., and A. Hacker,
              "Deterministic Networking (DetNet) Security
              Considerations", RFC 9055, DOI 10.17487/RFC9055, June
              2021, <https://www.rfc-editor.org/info/rfc9055>.

   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
              Ed., "Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
              May 2022, <https://www.rfc-editor.org/info/rfc9197>.

   [RFC9326]  Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
              Mizrahi, "In Situ Operations, Administration, and
              Maintenance (IOAM) Direct Exporting", RFC 9326,
              DOI 10.17487/RFC9326, November 2022,
              <https://www.rfc-editor.org/info/rfc9326>.

Authors' Addresses

   Frank Brockners
   Cisco Systems, Inc.
   Hansaallee 249, 3rd Floor
   40549 DUESSELDORF
   Germany
   Email: fbrockne@cisco.com

   Shwetha Bhandari
   Thoughtspot
   3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout
   Bangalore, KARNATAKA 560 102
   India
   Email: shwetha.bhandari@thoughtspot.com

Brockners, et al.        Expires 6 January 2025                [Page 19]
Internet-Draft         IOAM-Data-Fields Integrity              July 2024

   Tal Mizrahi
   Huawei
   8-2 Matam
   Haifa 3190501
   Israel
   Email: tal.mizrahi.phd@gmail.com

   Justin Iurman
   Universite de Liege
   10, Allee de la decouverte (B28)
   4000 Sart-Tilman
   Belgium
   Email: justin.iurman@uliege.be

Brockners, et al.        Expires 6 January 2025                [Page 20]