Integrity of In-situ OAM Data Fields

"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 "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 , 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 proving 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 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 for more details on IOAM-Domains. The following considerations and requirements are to be taken into account in addition to addressing the problem of detectability of any integrity breach of the IOAM-Data-Fields collected: 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). IOAM data is carried within packets. Additional space required to prove integrity of the IOAM-Data-Fields needs to be optimal, i.e. should not exceed the Maximum Transmission Unit (MTU) or have adverse effect 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, using the IOAM Option-Types specified in and as an example. The method will similarly apply to future IOAM Option-Types.

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.

Abbreviations used in this document: Operations, Administration, and Maintenance In-situ OAM Proof of Transit Edge to Edge Direct Exporting

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. 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 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 is a false 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 false 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.

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. Impact By systematically modifying the IOAM-Data-Fields of some or all of the in-transit packets, an attacker can create a false picture of the paths in the network, the existence of faulty nodes and their location, and the network performance.

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 Changing the header of IOAM Option-Types may have several implications. An attacker can maliciously increase the processing overhead in nodes that process IOAM-Data-Fields and increase the on-the-wire overhead of IOAM-Data-Fields, for example by modifying the IOAM-Trace-Type field in the IOAM Trace Option-Type header. An attacker can 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 context of IOAM-Data-Fields by modifying the Namespace-ID field in IOAM Option-Type headers, which makes the integrity protection of IOAM-Data-Fields completely useless.

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 .

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 .

Threat 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 By replaying old IOAM-Data-Fields, an attacker can create a false picture of the network status. The attacker could simulate a nonexistent failure, or incur non-required processing load on nodes that process these IOAM-Data-Fields.

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.

Threat An on-path attacker may delay some or all of the in-transit packets that include IOAM-Data-Fields in order to create the false illusion of congestion. Delay attacks are well known in the context of deterministic networks and synchronization , 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. It is noted that this threat is not within the scope of the threats that are mitigated in this document. 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 |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 | | + | +-------------------------------------------+--------+------------+

This section defines new IOAM Option-Types. Their purpose is to carry IOAM-Data-Fields with integrity protection. Each of the IOAM Option-Types defined in and is extended as follows: IOAM Pre-allocated Trace Integrity Protected Option-Type: corresponds to the IOAM Pre-allocated Trace Option-Type () with integrity protection. IOAM Incremental Trace Integrity Protected Option-Type: corresponds to the IOAM Incremental Trace Option-Type () with integrity protection. IOAM POT Integrity Protected Option-Type: corresponds to the IOAM POT Option-Type () with integrity protection. IOAM E2E Integrity Protected Option-Type: corresponds to the IOAM E2E Option-Type () with integrity protection. IOAM DEX Integrity Protected Option-Type: corresponds to the IOAM DEX Option-Type () with integrity protection. The IOAM Integrity Protection Header follows the IOAM Option-Type header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Signature-suite| Nonce length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Signature ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-bit unsigned integer. This field defines the algorithm pair used to compute the digest and the signature over the IOAM-Data-Fields, as defined in . 8-bit unsigned integer. This field specifies the length of the Nonce in octets. 16-bit Reserved field. MUST be set to zero upon transmission and ignored upon receipt. Variable length field with length specified in Nonce length. Digital signature value generated by the algorithm pair specified by Signature-suite. The Signature length depends on the Signature-suite value.

Both the IOAM Pre-allocated Trace Option-Type header and the IOAM Incremental Trace Option-Type header, as defined in , are followed by the 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:

The following IOAM Pre-allocated or Incremental Option-Type header fields are involved in the integrity protection of IOAM-Data-Fields: Namespace-ID NodeLen Flags: only bits 1 (Loopback) and 2 (Active) IOAM-Trace-Type

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

The following IOAM POT Option-Type header fields are involved in the integrity protection of IOAM-Data-Fields: Namespace-ID IOAM-POT-Type

The IOAM E2E Option-Type header, as defined in , is followed by the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Signature-suite| Nonce length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Signature ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following IOAM E2E Option-Type header fields are involved in the integrity protection of IOAM-Data-Fields: Namespace-ID IOAM-E2E-Type

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

The following IOAM DEX Option-Type header fields are involved in the integrity protection of IOAM-Data-Fields: Namespace-ID Extension-Flags: only bits 0 (Flow ID) and 1 (Sequence Number) IOAM-Trace-Type The optional fields (i.e., Flow ID and Sequence Number) are treated as optional IOAM-Data-Fields, not header fields.

This section defines a method that uses a symmetric key based signature algorithm for integrity protection of IOAM-Data-Fields. In case of performance concerns, the method can be applied to a subset of the traffic by using sampling of data. The symmetric key based signature algorithm MUST use SHA-256 () as the Digest Algorithm, and MUST use Advanced Encryption Standard () with a key length of 256 bits and the Galois/Counter Mode () as the Signature Algorithm (AES-256-GCM). The corresponding Signature Suite Identifier is 1, as defined in . As a consequence, the signature consumes 32 octets. The Integrity Protection Method is defined by the following steps: The encapsulating node creates a nonce and stores it in the Nonce field of the IOAM Integrity Protection Header (the Nonce length field is set accordingly). The Signature-suite field is set to 1. The signature is generated over the hash of header fields (see , , , or , for the exact list of header fields to include in the signature, depending on the IOAM Integrity Protected Option-Type) and IOAM-Data-Fields it has inserted, i.e., sign(hash(Header-Fields || IOAM-Data-Fields)), with the Nonce field provided as the nonce. IOAM-Data-Fields supposed to be modified by other IOAM nodes on the path MUST be excluded from the signature (e.g., the POT Cumulative field). The signature is stored in the Signature field of the IOAM Integrity Protection Header. A transit node generates a signature over the hash of IOAM-Data-Fields it has inserted, i.e., sign(hash(IOAM-Data-Fields)), with the Signature field provided as the nonce. IOAM-Data-Fields modified in-place by the transit node MUST be excluded from the signature (e.g., the POT Cumulative field). The signature is stored in the Signature field of the IOAM Integrity Protection Header. If the transit node does not insert IOAM-Data-Fields (e.g., it only modifies IOAM-Data-Fields in-place, or does nothing), then the transit node MUST NOT generate a signature and MUST NOT update the Signature field. In the context of the Integrity Protection Method, a node that performs the validation of the integrity protection is referred to as a "Validator". The role of a Validator is to recompute the signature by iteratively following the previous steps of the method, in the same order and up to itself, using the respective symmetric keys. The recomputed signature is then compared to the Signature field. As a result, the Validator can detect if the IOAM-Data-Fields integrity is intact or was altered. The validation is trivial in some cases (e.g., with POT Type-0, E2E or DEX Option-Types), where only the encapsulating node generates a signature, as specified above by this method. For other cases where transit nodes also generate a signature (e.g., with Trace Option-Types), node-ids MUST be included in IOAM-Data-Fields. Details on how the mapping between node-ids and keys is implemented on a Validator are outside the scope of this document. Each node that takes actions triggered by fields in the IOAM Integrity Protected Option-Type header MUST act as a Validator. Otherwise, an attacker could modify the IOAM header along the path and change the actions a node performs. Examples: For an Integrity Protected Trace Option-Type (Pre-allocated or Incremental), each transit node MUST act as a Validator, if either the IOAM Loopback or Active mode is used. For an Integrity Protected DEX Option-Type, each transit node MUST act as a Validator. The decapsulating node MUST act as a Validator. The decapsulating node MUST NOT generate a signature based on IOAM-Data-Fields it has inserted, if any, and therefore MUST NOT update the Signature field. The method assumes that symmetric keys have been distributed to the respective nodes as well as the Validator(s). The details of the mechanisms used for key distribution are outside the scope of this document.

IANA is requested to define the following new code points in the "IOAM Option-Type" registry: IOAM Pre-allocated Trace Integrity Protected Option-Type (see ) IOAM Incremental Trace Integrity Protected Option-Type (see ) IOAM POT Integrity Protected Option-Type (see ) IOAM E2E Integrity Protected Option-Type (see ) IOAM DEX Integrity Protected Option-Type (see ) A document defining a new IOAM Integrity Protected Option-Type MUST define the IOAM Option-Type header fields involved in the integrity protection of IOAM-Data-Fields, as done in , , , and of this document.

IANA is requested to define a new registry named "IOAM Integrity Protection Signature Suite", inside the "In Situ OAM (IOAM)" registry group. The new registry defines 256 code points to identify the digest and signature algorithms used in the Signature-suite field, as explained in . The following code points are defined in this document:

Signature Suite Digest Signature Specification Identifier Algorithm Algorithm Pointer +-----------+------------+-------------+----------------+ | 0x00 | Reserved | Reserved | This document | +-----------+------------+-------------+----------------+ | 0x01 | SHA-256 | AES-256-GCM | This document | +-----------+------------+-------------+----------------+ | 0x02 | | | | | ... | Unassigned | Unassigned | | | 0xFE | | | | +-----------+------------+-------------+----------------+ | 0xFF | Reserved | Reserved | This document | +-----------+------------+-------------+----------------+ Code points 2-254 are available for assignment via the "IETF Review" process, as per . New registration requests MUST use the following template: the value of the requested code point, the associated digest algorithm name and signature algorithm name, and a reference to the document that defines the requested code point.

Please refer to for a threat analysis of integrity-related threats in the context of IOAM. The Integrity Protection Method defined in this document (see ) 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. The Integrity Protection Method defined in this document requires additional per-packet processing by each node that uses it. Inappropriate use of the Integrity Protection Method might overload nodes and cause them to stop functioning properly. Operators deploying IOAM with the 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. The Nonce makes a signature chain unique but does not necessarily prevent replay attacks. To enable replay protection, the encapsulating node and the Validator(s) 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.

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