Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields

In Situ Operations, Administration, and Maintenance (IOAM) records OAM information within packets while they traverse a 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 (a.k.a. In-Data-Packet OAM ). IOAM is deployed inside an IOAM-Domain, which consists of a set of nodes that use IOAM. The boundaries of the IOAM-Domain are formed by IOAM control points, as defined in . 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 access to all the networking devices. Per , IOAM-Data-Fields are carried in the clear within packets and there are no protections against any device tampering with the data. IOAM-Data-Fields collected in an untrusted environment require at least integrity protection to support critical operational decisions. Refer to for more details on IOAM-Domains. Since arbitrary nodes can tamper with all packets data, including IOAM-Data-Fields, and the packets are (in general) processed by other intermediary nodes before they are delivered to 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, this document is limited 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, the following considerations and requirements are to be taken into account in constructing an IOAM integrity mechanism: 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 may be applied to all traffic that a router forwards). IOAM data is carried within packets. The additional space required to provide integrity protection of the IOAM-Data-Fields must not cause packets to exceed the applicable Maximum Transmission Unit (MTU) within the IOAM-Domain and should minimize adverse effects on packet processing. 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 for Intra-IOAM-Domain use cases, using the IOAM Option-Types specified in as an example.

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 when, and only when, they appear in all capitals, as shown here.

This document uses terms such as IOAM-Data-Fields, IOAM-Domain, IOAM-Namespace, IOAM-Option-Type (or Option-Type), encapsulating node, transit node, and decapsulating node. Refer to for definitions. This document also introduces the term "Validator". Refer to for the definition. The following abbreviations are used in this document: Operations, Administration, and Maintenance In Situ OAM Proof of Transit Edge to Edge Maximum Transmission Unit Galois/Counter Mode Galois Message Authentication Code Initialization Vector Integrity Check Value Additional Authenticated Data The following notation is used in this document: The concatenation of A and B, where the octets of B immediately follow the octets of A.

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 those 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 out of scope. Throughout the analysis there is a distinction between on-path and off-path attackers. As discussed in , on-path attackers are located in a position that allows interception, modification, or dropping of in-flight protocol packets, whereas off-path attackers can only attack by generating protocol packets. Since IOAM operates within administratively controlled IOAM-Domains that define a trust boundary, this reduces potential attack vectors and should naturally mitigate off-path threats. The analysis also includes the impact of each of the threats. Generally speaking, the impact of a successful attack on an OAM protocol is an illusion of nonexistent failures (or disruption) or preventing the detection of actual ones, as described in Section 9 of ; in both cases, the attack could result in Denial-of-Service (DoS). Furthermore, creating the illusion of a nonexistent issue could trigger unnecessary processing in some of the IOAM nodes along a forwarding path, and could 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.

Applicability On-path only. Threat An 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. 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.

Applicability On-path only. Threat An attacker can modify the fields of an IOAM Option-Type header to change or disrupt the behavior of nodes processing IOAM-Data-Fields along the path, or change the interpretation of IOAM-Data-Fields. The modification can either be applied to all packets or selectively applied to a subset. Impact Modification of fields in an IOAM Option-Type header can have multiple impacts. The following examples are non-exhaustive. An attacker that modifies the Namespace-ID field (, Section 4.3), common to all IOAM Option-Type headers, can alter the definition and interpretation of IOAM-Data-Fields. Without the correct Namespace-ID, IOAM-Data-Fields cannot be reliably interpreted. An attacker that modifies the Trace-Type field (, Section 4.4.1) of the IOAM Trace Option-Type header can increase node processing overhead for IOAM-Data-Fields and increase on-the-wire overhead. An attacker that modifies the RemainingLen field (, Section 4.4.1) of the IOAM Trace Option-Type header can prevent nodes from incorporating IOAM-Data-Fields. An attacker that sets the Loopback flag (, Section 3) in the IOAM Trace Option-Type header can cause a Denial-of-Service by inducing each node to send packet copies to the encapsulating node. Modification of the header can result in impacts similar to those described in .

Applicability On-path only. Threat An attacker can inject additional IOAM-Data-Fields into packets containing at least one IOAM Option-Type, thus falsifying the view of the actual network state. The injection can either be applied to all packets or selectively applied to a subset. Impact This attack causes impacts similar to those described in .

Applicability Both on-path and off-path. Threat An attacker can inject packets with IOAM Option-Type headers, thus manipulating other nodes that process IOAM-Data-Fields in the network. Impact This attack and its impacts are similar to those described in .

Applicability On-path only. Threat An attacker can remove IOAM-Data-Fields from packets containing at least one IOAM Option-Type, thus hiding the diagnosis of some nodes. The deletion can either be applied to all packets or selectively applied to a subset. Impact This attack causes impacts similar to those described in .

Applicability On-path only. Threat An attacker can remove IOAM Option-Type headers from packets, thus preventing the use of IOAM to diagnose the network. The deletion can either be applied to all packets or selectively applied to a subset. The mechanisms in this document do not provide any mitigation against this threat. Impact By systematically removing IOAM Option-Type headers from some or all of the in-transit packets, an attacker can make telemetry recording incomplete or even impossible. As a consequence, network diagnosis could be incomplete or non-existent.

Applicability Both on-path and off-path. Threat In addition to replaying old packets in general, an attacker can replay packets with IOAM-Data-Fields. Specifically, an attacker could replay a previously transmitted IOAM Option-Type header with a new data packet, therefore attaching old IOAM-Data-Fields to a fresh user packet. Impact This attack causes impacts similar to those described in .

Applicability Both on-path and off-path. 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 out of scope; the network management protocol is expected to include inherent security capabilities. The integrity of exported data is also out of scope. 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.

Applicability On-path only. Threat An attacker might delay some or all of the in-transit packets that include IOAM-Data-Fields to create an illusion of congestion. Delay attacks are well known in the context of deterministic networks and time synchronization , and could 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.

+===========================================+===========+ | Threat | Document | | | Scope | | +=====+=====+ | | In | Out | +===========================================+=====+=====+ | Modification: IOAM-Data-Fields | X | | +-------------------------------------------+-----+-----+ | Modification: IOAM Option-Type header | X | | +-------------------------------------------+-----+-----+ | Injection: IOAM-Data-Fields | X | | +-------------------------------------------+-----+-----+ | Injection: IOAM Option-Type header | X | | +-------------------------------------------+-----+-----+ | Deletion: IOAM-Data-Fields | X | | +-------------------------------------------+-----+-----+ | Deletion: IOAM Option-Type header | | X | +-------------------------------------------+-----+-----+ | Replay | X | | +-------------------------------------------+-----+-----+ | Management and Exporting | | X | +-------------------------------------------+-----+-----+ | Delay | | X | +-------------------------------------------+-----+-----+

This section defines new IOAM Option-Types to carry IOAM-Data-Fields with integrity protection. For each IOAM Option-Type defined in , a corresponding Integrity-Protected Option-Type is defined as follows: IOAM Integrity-Protected Pre-allocated Trace Option-Type: corresponds to the IOAM Pre-allocated Trace Option-Type (, Section 4.4) with integrity protection. IOAM Integrity-Protected Incremental Trace Option-Type: corresponds to the IOAM Incremental Trace Option-Type (, Section 4.4) with integrity protection. IOAM Integrity-Protected POT Option-Type: corresponds to the IOAM POT Option-Type (, Section 4.5) with integrity protection. IOAM Integrity-Protected E2E Option-Type: corresponds to the IOAM E2E Option-Type (, Section 4.6) with integrity protection. The Direct Export (DEX) Option-Type is not covered by the Integrity Protection Method defined in . This document focuses on the integrity protection of IOAM-Data-Fields, whereas DEX does not carry IOAM-Data-Fields by definition. As a consequence, DEX and similar (i.e., any IOAM Option-Type with no IOAM-Data-Fields) are considered out of scope and MUST NOT use the Integrity Protection Method defined in this document. The Integrity Protection header sits between an IOAM Option-Type header and its IOAM-Data-Fields, forming an equivalent Integrity-Protected Option-Type. This placement ensures that the Integrity Protection header is part of the header, rather than a trailer after the IOAM-Data-Fields. The Integrity Protection header is defined as shown in .

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) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-bit unsigned integer, see . 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 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. 8-bit unsigned integer. It defines the length of the Nonce field, in octets. 16-bit Reserved field. It MUST be set to zero upon transmission and ignored upon receipt. Variable length field. Its size depends on the Nonce Length field. Variable length field. Its size depends on the Method ID field. In order to keep IOAM-Data-Fields aligned (, Section 4.4.2), the total length of the Integrity Protection header MUST be a multiple of 4 octets.

Both the IOAM Pre-allocated Trace Option-Type header and the IOAM Incremental Trace Option-Type header are identical, as defined in Section 4.4 of . When followed by the Integrity Protection header, they respectively form the IOAM Integrity-Protected Pre-allocated Trace Option-Type and the IOAM Integrity-Protected Incremental Trace Option-Type (). The definitions of fields that are not part of the Integrity Protection header are the same as in .

The IOAM POT Option-Type header is defined in Section 4.5 of . When followed by the Integrity Protection header, it forms the IOAM Integrity-Protected POT Option-Type (). The definitions of fields that are not part of the Integrity Protection header are the same as in .

The IOAM E2E Option-Type header is defined in Section 4.6 of . When followed by the Integrity Protection header, it forms the IOAM Integrity-Protected E2E Option-Type (). The definitions of fields that are not part of the Integrity Protection header are the same as in .

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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This document defines an Integrity Protection Method for IOAM-Data-Fields using symmetric keys. The method uses AES-GMAC , a mode of operation that provides data origin authentication and is a specialization of Galois/Counter Mode (GCM). GCM takes as input a secret key, an Initialization Vector (IV), a plaintext, and Additional Authenticated Data (AAD), and produces a ciphertext and an Authentication Tag. GMAC is the special case of GCM with zero-length plaintext; the ciphertext output is empty and ignored, and only the Authentication Tag is produced. For this method, the Authentication Tag MUST NOT be truncated and MUST be 16 octets in length. In this document, the GMAC Initialization Vector (IV) is referred to as the nonce, the GMAC Authentication Tag is referred to as the Integrity Check Value (ICV), and the GMAC Additional Authenticated Data (AAD) is referred to as AAD. Due to IOAM space constraints, maintaining a separate nonce and ICV for each IOAM node participating in integrity protection is not practical. This Integrity Protection Method uses a single Nonce field and a single ICV field in the packet. The nonce is generated by the encapsulating node according to the requirements defined in and remains unchanged. The ICV is iteratively updated by participating nodes using the received ICV and their immutable IOAM-Data-Fields as inputs to the GMAC operation. This design enables reconstruction of the integrity chain by a Validator.

In order to use this method and apply integrity protection, it is REQUIRED that each IOAM node that updates the ICV (in the Integrity Protection header) has its own unique symmetric key. Although GMAC supports all AES key sizes (i.e., 128, 192, and 256 bits), it is RECOMMENDED to use the longest key size when possible. Each key MUST be securely generated and fresh. Also, each key MUST be securely distributed to only the corresponding IOAM nodes and any Validator that needs to validate messages protected by that key. Except key rotation requirements, the details of key generation and distribution are out of scope. In addition to key management, per-message nonces used with GMAC MUST be managed to prevent reuse of a key-nonce pair. Since reuse of a nonce with a given key allows forgery of arbitrary ciphertexts with valid authentication tag, it is extremely important to have high confidence in nonce non-reuse. For this method, the size of the nonce MUST always be 12 octets. If a node receives a Nonce Length value other than 12, it MUST NOT change the contents of the 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. A nonce MUST NOT be reused with the same key. The nonce is based on the "Deterministic Construction" and has the format shown in .

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Encapsulating Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Counter (64 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-bit unsigned integer. It identifies the key used by the corresponding Encapsulating Node ID to compute the ICV with GMAC. 24-bit unsigned integer. It identifies an IOAM encapsulating node that generated the nonce. It MUST be unique for each IOAM node in the IOAM-Domain, which means a reasonable limit of 2^24 distinct IOAM nodes in total. 64-bit unsigned integer. It is an incrementing counter managed by the corresponding encapsulating node (i.e., the one whose ID is the same as the Encapsulating Node ID field). The counter MUST start at 0 for each Key ID and MUST be unique for each packet, which means a limit of 2^64 packets per Key ID on the corresponding Encapsulating Node ID. Since GMAC does not require a nonce to be secret or unpredictable, it is secure to use a counter. When the key-specific counter of an encapsulating node reaches the maximum value (i.e., 2^64), the encapsulating node MUST stop applying integrity protection with that key and start using a new one. Ideally, before that limit is reached, the key management system SHOULD rotate the key and notify any Validator that needs to validate messages protected by that key. The Key ID field provides an easy way to avoid conflicts during key rotations with other IOAM nodes that apply integrity protection. When an encapsulating node reaches its maximum use of 256 distinct keys (i.e., see the Key ID field) and is also about to reach the limit of its key-specific counter, the key management system MUST rotate the keys of all IOAM nodes in the IOAM-Domain and notify any Validator with the new keys. In addition, the internal integrity protection state of all IOAM nodes, which is useful to detect and prevent key-nonce reuse, MUST be reset. Overall, the key management system MUST NOT (ever) redistribute an old key to any of the IOAM nodes in the IOAM-Domain. An encapsulating node that participates in the integrity protection of IOAM-Data-Fields MAY retain on persistent storage the current key in use and the corresponding key-specific counter, such that a power interruption or system crash (or reboot in general) does not lead to nonce reuse. If it is not possible for some reason, the encapsulating node MUST NOT reuse the key and the key management system MUST rotate the key before the encapsulating node resumes integrity protection. In case of a power interruption or system crash (or reboot in general) on any transit node that participates in the integrity protection of IOAM-Data-Fields, the transit node MUST NOT reuse the key and the key management system MUST rotate the key before the transit node resumes integrity protection. To illustrate with an example, it would take 7 years for a single key of an encapsulating node to reach the limit of 2^64 1500-byte packets on a 1 Pbps (Petabits per second) link at line rate, while it would take approximately 143 days with 64-byte packets. For 256 distinct keys of an encapsulating node, it would take 1792 and 100 years respectively. This is a worst-case scenario, as such link capacity is not common and IOAM might not be applied to all packets.

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 (e.g., the IOAM Namespace-ID, which is common to all IOAM Option-Types). Without such fields, IOAM-Data-Fields cannot be reliably interpreted. As a consequence, the integrity of any immutable Option-Type header field MUST be protected. As for mutable Option-Type header fields, they do not benefit from any integrity protection since their values can change. With GMAC, the bit length of the AAD MUST be a multiple of 8. In other words, the AAD is made up of whole octets. Masking specific bits of Option-Type header fields allows this constraint to be respected, even for fields that are single bits (e.g., flags) or not aligned on natural boundaries. The list of Option-Type header fields and their corresponding integrity protection masks to be applied (i.e., a logical AND operation) are defined in . For interoperability, having a dynamic registry to specify which header fields participate in integrity protection might not seem optimal at first glance. However, from a vendor perspective, integrity protection is simply a feature built on top of IOAM. Therefore, if two different vendors providing IOAM integrity protection are not interoperable, it probably means that their core IOAM implementations are not interoperable in the first place. Since IOAM has no versions, it does not make sense to introduce versions in the integrity protection feature either. This is the reason why it is acceptable to have a dynamic registry for this purpose and to update it accordingly over time.

The encapsulating node MUST follow the instructions in to generate a new nonce, which is then stored in the Nonce field of the Integrity Protection header (the Nonce Length field is set accordingly). In particular, nonce generation MUST comply with the nonce uniqueness requirements defined in . The Method ID field MUST be set to 0, as defined in . The initial ICV is the result of a GMAC operation, using the encapsulating node's key and the nonce generated by the encapsulating node. The AAD consists of a list of immutable header fields as defined in (depending on the Integrity-Protected Option-Type) and immutable IOAM-Data-Fields added by the encapsulating node. In the case where the Integrity-Protected Pre-allocated Trace Option-Type is used, the encapsulating node includes the IOAM-Data-Fields that correspond to itself, i.e., "node data list [n]" (, Section 4.4). The encapsulating node performs the following operations: AAD = (Header Fields || IOAM-Data-Fields) ICV = GMAC(Key, Nonce, AAD) Fields in the AAD are encoded in network byte order and in the same sequence as they appear on the wire. The encapsulating node then stores the ICV in the corresponding field of the Integrity Protection header.

A transit node MUST NOT generate a new nonce, as this would break the integrity chain and prevent validation of IOAM-Data-Fields contributed by previous nodes. It MUST use the received Nonce field for its own GMAC operation. A transit node MUST NOT reuse a nonce with the same key, as this is critical for GMAC security. Therefore, it MUST be able to detect reuse of nonces with its current key. Details on how this detection is implemented are out of scope. If a transit node receives a Nonce field that has already been used with its current key, it MUST NOT change the contents of the Integrity Protection header and MUST NOT change the contents of the IOAM-Data-Fields. In other words, the transit node must not process the IOAM Integrity-Protected Option-Type. The ICV is the result of a GMAC operation, using the transit node's key and the received nonce. The AAD consists of the received ICV (ICV_rx) and immutable IOAM-Data-Fields added by the transit node. In the case where the Integrity-Protected Pre-allocated Trace Option-Type is used, the transit node includes the IOAM-Data-Fields that correspond to itself, i.e., "node data list [n-i]" (, Section 4.4). The transit node performs the following operations: AAD = (ICV_rx || IOAM-Data-Fields) ICV = GMAC(Key, Nonce, AAD) Fields in the AAD are encoded in network byte order and in the same sequence as they appear on the wire. The transit node then updates the ICV field accordingly in the Integrity Protection header. If the transit node does not add any immutable IOAM-Data-Fields (e.g., it only modifies mutable IOAM-Data-Fields or does nothing), and if the transit node, in case the Integrity-Protected Pre-allocated Trace Option-Type is used, does not update the "node data list" array, then the transit node MUST NOT update the ICV field in the Integrity Protection header. A transit node MUST NOT add or remove the Integrity Protection header. Also, a transit node MUST NOT modify the Method ID field, the Nonce Length field, or the Nonce field in the Integrity Protection header. A transit node does not validate the integrity of previously added IOAM-Data-Fields. Integrity validation is exclusively performed by a Validator as defined in .

The decapsulating node MAY perform the function of the Validator. If it does, ignore this section and refer directly to . If the decapsulating node does not perform the function of the Validator, which is an alternative to put any Validator out of the forwarding path in case of performance concerns, the decapsulating node MUST send the entire IOAM Integrity-Protected Option-Type to a Validator. The method to send it to a Validator is out of scope. The decapsulating node MUST NOT generate a new nonce, as this would break the integrity chain and prevent validation of IOAM-Data-Fields contributed by previous nodes. It MUST use the received Nonce field for its own GMAC operation. A decapsulating node MUST NOT reuse a nonce with the same key, as this is critical for GMAC security. Therefore, it MUST be able to detect reuse of nonces with its current key. Details on how this detection is implemented are out of scope. If a decapsulating node receives a Nonce field that has already been used with its current key, it MUST NOT change the contents of the Integrity Protection header and MUST NOT change the contents of the IOAM-Data-Fields. In other words, the decapsulating node must not process the IOAM Integrity-Protected Option-Type. The decapsulating node updates the ICV field in the Integrity Protection header. The ICV is the result of a GMAC operation, using the decapsulating node's key and the received nonce. The AAD consists of the received ICV (ICV_rx) and immutable IOAM-Data-Fields added by the decapsulating node. In the case where the Integrity-Protected Pre-allocated Trace Option-Type is used, the decapsulating node includes the IOAM-Data-Fields that correspond to itself, i.e., "node data list [n-i]" (, Section 4.4). The decapsulating node performs the following operations: AAD = (ICV_rx || IOAM-Data-Fields) ICV = GMAC(Key, Nonce, AAD) Fields in the AAD are encoded in network byte order and in the same sequence as they appear on the wire. If the decapsulating node does not add any immutable IOAM-Data-Fields (e.g., it only modifies mutable IOAM-Data-Fields or does nothing), and if the decapsulating node, in case the Integrity-Protected Pre-allocated Trace Option-Type is used, does not update the "node data list" array, then the decapsulating node MUST NOT update the ICV field in the Integrity Protection header. The decapsulating node MUST NOT add the Integrity Protection header. Also, the decapsulating node MUST NOT modify the Method ID field, the Nonce Length field, or the Nonce field in the Integrity Protection header.

An IOAM node that performs the validation of the integrity protection is referred to as a Validator. Any Validator is a key trusted entity in this system, as it has access to all of the keying material in use and makes the final determination of whether an ICV is valid. A validator is not vulnerable to key-nonce reuse, since the computed ICV remains internal. However, a protection against replay attacks in general (more specifically, replay of old IOAM-Data-Fields) is still needed. To this end, a Validator MUST be able to detect nonces already used with specific keys during validation to prevent replays. Details on how this detection is implemented are out of scope. If a Validator receives a Nonce field that has already been used with a specific key during validation, it MUST consider the ICV as invalid and ignore the next steps. To validate an ICV, a Validator MUST recompute the cumulative ICV by replaying the sequence of GMAC operations in the same order as performed by the IOAM nodes, using the IOAM-Data-Fields contained in the packet and the correponding keys associated with each node. Since only the latest ICV is carried, each step uses the ICV produced by the previous step as input to the next computation. The recomputed ICV is then compared with the ICV field (ICV_rx) carried in the packet. The Validator performs the following operations: Step 0 (encapsulating node) AAD_0 = (Header Fields || IOAM-Data-Fields_0) ICV_0 = GMAC(Key_0, Nonce, AAD_0) Step i (i-th node) AAD_i = (ICV_i-1 || IOAM-Data-Fields_i) ICV_i = GMAC(Key_i, Nonce, AAD_i) Step n (n-th node, i.e., the Validator) return (ICV_n-1 == ICV_rx) As a result, a Validator can perform an integrity check on the IOAM-Data-Fields and report whether any modification is detected. 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), a Validator MUST be able to identify these transit nodes to look up their respective keys. For that, a unique identifier of the node, such as the "node_id" (, Section 4.4.2) for Trace Option-Types, MUST be included in IOAM-Data-Fields. Regardless of the Option-Type, the Nonce field allows the encapsulating node to be identified (). Details on how the mapping between those identifiers and keys is implemented on a Validator are out of scope.

IANA is requested to add the following new code points in the "IOAM Option-Type" registry available at : (suggested) 64 IOAM Integrity-Protected Pre-allocated Trace Option-Type Pre-allocated Trace with Integrity Protection This document, (suggested) 65 IOAM Integrity-Protected Incremental Trace Option-Type Incremental Trace with Integrity Protection This document, (suggested) 66 IOAM Integrity-Protected POT Option-Type POT with Integrity Protection This document, (suggested) 67 IOAM Integrity-Protected E2E Option-Type E2E with Integrity Protection This document, New IOAM Integrity-Protected Option-Types that intend to use the Integrity Protection Method defined in this document will update the "IOAM Integrity Protection Methods" registry (), more specifically the "Protected Header Fields" column of this Integrity Protection Method, to specify the list of corresponding Option-Type header fields that participate in the integrity protection of IOAM-Data-Fields. discusses the motivations and choices for protecting the integrity of Option-Type header fields in addition to IOAM-Data-Fields.

IANA is requested to define a new registry named "IOAM Integrity Protection Methods", under the "In Situ OAM (IOAM)" registry group . This new registry defines 256 code points to identify different IOAM Integrity Protection Methods. The following initial code points are defined:

specifies a YANG module to manage IOAM profiles with integrity protection.

Each node that applies the Integrity Protection Method defined in this document incurs additional per-packet processing. This overhead is increased for Validators with Integrity-Protected Option-Types that require transit node participation (e.g., Integrity-Protected Trace Option-Types). Improper use of this method can overload nodes and result in service degradation or failure. Implementations SHOULD monitor relevant metrics (e.g., CPU and memory utilization) to detect abnormal behavior. Operators deploying this method MUST ensure that overload conditions are avoided. This can be achieved by limiting IOAM insertion to a subset of traffic, noting that only such traffic is integrity-protected. Processing load MAY be distributed across multiple Validators to enable parallel validation and load sharing.

Option-Types defined in and the Integrity-Protected Option-Types defined in this document are not mutually exclusive and could coexist within the same IOAM-Domain. Integrity protection is an extension to IOAM. An implementation could support multiple IOAM-Namespaces concurrently, for example, one IOAM-Namespace using the Pre-allocated Trace Option-Type and another using the Integrity-Protected Pre-allocated Trace Option-Type.

discusses MTU considerations, as IOAM data is carried within packets. Similarly, the additional space required to provide integrity protection of the IOAM-Data-Fields MUST NOT cause packets to exceed the applicable MTU within the IOAM-Domain and SHOULD minimize adverse effects on packet processing.

provides a threat analysis of integrity-related threats in the context of IOAM. The Integrity Protection Method defined in this document () leverages symmetric keys and uses AES-GMAC . Security considerations regarding key and nonce management are discussed in . In particular, a node MUST NOT reuse a nonce with the same key. Packet reordering or duplication does not compromise the Integrity Protection Method defined in this document, as key-nonce reuse is prohibited. Reordered or duplicated packets are not processed for integrity protection and no IOAM data is inserted. This behavior depends on the replay protection window implemented by a node. Such protection window determines the tolerance for packet reordering. A compromised transit node can remove the Integrity Protection header and replace an IOAM Integrity-Protected Option-Type with its unprotected equivalent to modify IOAM-Data-Fields and bypass validation. It can also reinitialize the Nonce and ICV to impersonate an encapsulating node. To mitigate these threats, a Validator MUST know all IOAM Namespace-IDs with integrity protection enabled, the corresponding encapsulating nodes, and the Option-Types they add. Integrity protection MUST be applied to the entire IOAM set for a given Namespace-ID. Implementation details are out of scope. As noted in , a compromised transit node can remove IOAM Option-Types; mitigation is out of scope and SHOULD be provided by the protocol that encapsulates IOAM. A compromised Validator can forge or modify IOAM-Data-Fields and produce incorrect validation results. As a trusted entity, such behavior cannot be prevented by this Integrity Protection Method. Compromised encapsulating or transit nodes can forge or drop packets but cannot impersonate other IOAM nodes or modify integrity-protected IOAM-Data-Fields without detection by a Validator. A transit node's ability to forge data is limited, as validation includes the encapsulating node's ICV. The Integrity Protection Method defined in this document is intended for Intra-IOAM-Domain use cases (i.e., no confidentiality, integrity protection only). For Inter-IOAM-Domain use cases, operators can use IPSec to securely transfer IOAM-Data-Fields between IOAM-Domains.

The authors would like to thank Santhosh N, Rakesh Kandula, Saiprasad Muchala, Al Morton, Greg Mirsky, Benjamin Kaduk, Mehmet Beyaz, Martin Duke, Tianran Zhou, Giuseppe Fioccola, Mohamed Boucadair, and Yoshifumi Nishida for their comments and advice.