Integrity of In-situ OAM Data Fields

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 it 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 it impacts are similar to Section 3.2.¶

3.5. Replay

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, thus attaching old IOAM data fields to a fresh user packet. This threat is applicable to both on-path and off-path attackers.¶

Impact¶

• As with previous threats, this threat may create a false image of a nonexistent failure, or may overload nodes which process IOAM data fields with unnecessary processing.¶

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 the false illusion of congestion. Delay attacks are well known in the context of deterministic networks [I-D.ietf-detnet-security] and 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. It is noted that this threat is not within the scope of the threats that are mitigated in the scope of 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.¶

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

4.3. Space optimized symmetric key based signing of trace data

This method assumes that symmetric keys have been distributed to the respective nodes as well as the Validator (the Validator receives all the keys). The details of the mechanisms of how keys are distributed are outside the scope of this document. The "Trace Signature" field is populated as follows:¶

1. The first node creates a nonce and signature over the hash of IOAM Option excluding the Signature field, the nonce and its symmetric key. The nonce is included as a field in Integrity Protection sub-header of the corresponding IOAM Option. The resulting signature is included in the corresponding Signature field.¶
2. Intermediate nodes will update the Signature field by creating a signature of data where the data is [Signature || hash(node_data_list[x])] with its symmetric key in case of IOAM Trace Integrity Protected Options. Intermediate nodes updating IOAM POT Option will update the Signature field by creating a signature of data where the data is [Signature || hash(IOAM POT OPTION excluding Signature field)] with its symmetric key in case of IOAM POT Integrity Protected Option.¶
3. The Validator will iteratively recreate the Signature over the IOAM Option fields collected and matches the Signature field to validate the data integrity.¶

This method recommends use of the following algorithms:¶

1. The algorithm to calculate the signature using symmetric key MUST be Advanced Encryption Standard (AES) AES-256. [AES] [NIST.800-38D].¶
2. The digest/hash algorithm used MUST be SHA-256 [SHS].¶

4.4. Space optimized asymmetric key based signing of trace data

This method assumes that asymmetric keys have been generated per IOAM node and the respective nodes can access their keys. The Validator receives all the public keys. The details of the mechanisms of how keys are generated and shared are outside the scope of this document. The " Signature" field is populated as follows:¶

1. The first node creates a nonce and signs over the hash of IOAM Option it populates excluding the Signature field in the option, the nonce and its private key. The resulting signature is included in the Signature field.¶
2. Intermediate nodes will update the Signature field by creating a signature of data where the data is [Signature || hash(node_data_list[x])] with its private key in case of IOAM Trace Integrity Protected Options. Intermediate nodes updating IOAM POT Option will update the Signature field by creating a signature of data where the data is [Signature || hash(IOAM POT OPTION excluding Signature field)] with its private key in case of IOAM POT Integrity Protected Option.¶
3. The Validator will iteratively recreate the Signature over the IOAM Option fields collected and matches the Signature field to validate the data integrity using public keys of the IOAM nodes.¶

This method recommend use of the following algorithms:¶

1. The signature algorithm used MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS].¶
2. The digest/hash algorithm used MUST be SHA-256 [SHS].¶

8.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>.

8.2. Informative References

[AES]

National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, 2001, <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

[BLS]

Wikipedia, "BLS (Boneh–Lynn–Shacham) digital signature", 2021, <https://en.wikipedia.org/wiki/BLS_digital_signature>.

[DSS]

National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.

[EdDSA25519]

Wikipedia, "Edwards-curve Digital Signature Algorithm (EdDSA)", 2021, <https://en.wikipedia.org/wiki/EdDSA#Ed25519>.

[I-D.brockners-ippm-ioam-geneve]

Brockners, F., Bhandari, S., Govindan, V. P., Pignataro, C., Nainar, N. K., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Lapukhov, P., Gafni, B., Kfir, A., and M. Spiegel, "Geneve encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-brockners-ippm-ioam-geneve-05, 19 November 2020, <https://www.ietf.org/archive/id/draft-brockners-ippm-ioam-geneve-05.txt>.

[I-D.ietf-detnet-security]

Grossman, E., Mizrahi, T., and A. J. Hacker, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft-ietf-detnet-security-16, 2 March 2021, <https://www.ietf.org/archive/id/draft-ietf-detnet-security-16.txt>.

[I-D.ietf-ippm-ioam-data]

Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-12, 21 February 2021, <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-data-12.txt>.

[I-D.ietf-ippm-ioam-direct-export]

Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ OAM Direct Exporting", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-direct-export-03, 17 February 2021, <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-direct-export-03.txt>.

[I-D.ietf-ippm-ioam-ipv6-options]

Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. Smith, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-05, 21 February 2021, <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-ipv6-options-05.txt>.

[I-D.ietf-nvo3-geneve]

Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, Internet-Draft, draft-ietf-nvo3-geneve-16, 7 March 2020, <https://www.ietf.org/archive/id/draft-ietf-nvo3-geneve-16.txt>.

[I-D.ietf-sfc-ioam-nsh]

Brockners, F. and S. Bhandari, "Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-05, 12 December 2020, <https://www.ietf.org/archive/id/draft-ietf-sfc-ioam-nsh-05.txt>.

[I-D.ietf-sfc-proof-of-transit]

Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. Youell, "Proof of Transit", Work in Progress, Internet-Draft, draft-ietf-sfc-proof-of-transit-08, 1 November 2020, <https://www.ietf.org/archive/id/draft-ietf-sfc-proof-of-transit-08.txt>.

[McEliece]

McEliece, R. J., "A Public-Key Cryptosystem Based on Algebraic Coding Theory", 1978, <https://ipnpr.jpl.nasa.gov/progress_report2/42-44/44N.PDF>.

[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>.

[RFC4302]

Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.

[RFC6090]

McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>.

[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>.

[RFC8300]

Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.

[SHS]

National Institute of Standards and Technology, "Secure Hash Standard (SHS)", NIST FIPS Publication 180-4, DOI 10.6028/NIST.FIPS.180-4, 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

A.1. Method 1: Using asymmetric keys for signing node trace data

Method 1 uses asymmetric keys for signing node trace data. This is the procedure to be followed by each node:¶

1. Each IOAM capable node creates a key pair and shares the public key with the controller, the Validator and the network management system responsible for using the IOAM trace information in the network domain. The detailed mechanisms how keys are exchanged between nodes are outside the scope of this document. For optimal performance, use of algorithms like BLS [BLS] or ED25519 [EdDSA25519] are suggested, resulting in fast signing for small keys and limited overhead (see below for an overhead calculation).¶

2. Each node data list [x] field is extended with an additional "signed node-data" field: node_data_sign[x]. Node_data_sign includes a signature using the private key of the node over the hash of node data list[x] of the node and the previous node's node data sign node_data_sign[x-1]. This couples the signature of the current field to the earlier field and creates a chain of trust. This way of chaining the node data signatures provides protection against replay of a previous node trace of a specific node.¶

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        node_data_sign [x]                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        node data list [x]                     |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   

   ¶
3. The IOAM encapsulating node (the node that inserts IOAM data fields into the packet) will add a seed in its node data list that is used in its node_data_sign. So the first IOAM node inserting the IOAM trace data will add node_data_sign over a "seed" || [hash of node data of first node]. The seed can be included as a field in first node data or the seed can be the trailer of the IOAM Trace-Option.¶
4. The validating node - will use the public key of each node to validate the signed node data elements in the same way the node Trace signatures were created, i.e. it'll repeat the individual operations of the IOAM nodes traversed and will compare the result to the last node's node_data-sign value. If the two values match, the IOAM data was not tampered with.¶

A.2. Method 2: Using symmetric keys for signing node trace data

The same procedure as Method 1 can be followed by using a MAC (Message Authentication Code) algorithm for node signature. This involves distributing a secret key to the individual IOAM nodes and the Validator. Steps 1 to 4 of Method 1 apply in a similar way, the only difference is that symmetric keys are used. As such, each node data list [x] field is extended with an additional "signed node-data" field: node_data_sign[x]. The size of the node_data_sign[x] field depends on the cryptographic message authentication code used.¶

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        node_data_sign [x]                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        node data list [x]                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.3. Method 4: Dynamic symmetric keys based signing of trace data

This method builds on top of Method 3 leverages Post-quantum Secure Pre-shared key distribution for deriving a dynamic symmetric key for every packet or a set of packets. The method utilizes the dynamic keys to provide for replay protection and does not require a seed to be added to the trace data to protect from replays because a private key is derived for each packet. The method relies on a local service that generates common Key/KeyID pairs for the participating Node and Validator (see the figure below). This common key generator uses ratcheting cryptography to generate the next secret while forgetting about the previous one. A unique ID is paired with each secret generated. Given the same seed secret as input parameter, two implementations of the common key generator will generate the exact same key and associated ID. The common key generator can be queried for the next key or for a specific key ID.¶

The figure below illustrates the concept:¶

      Validator                                         Node
          |                                              |
          |                                              |
    Generate McEliece                                    |
    public/private key-pair                              |
          |                                              |
          |<---Establ. classic secure connection---------|
          |               (e.g. TLS)                     |
          |---Send public key over secure connection---->|
          |                                              |
          |                             Generate random secret nonce
          |                               and encrypt w/ Validator
          |                                        public key
          |                                              |
          |<--Send encrypted seed over secure connection-|
          |                                              |
   Decrypt secret nonce sent from Node                   |
      using Validator's private key                      |
          |                                              |
          (-- Common secret nonce established between  --)
          (--       Node and Validator                 --)
          |                                              |
          |                             Generate Node's KeyID pair
          |                             based on common secret nonce
          |                                              |
          |           Use Node's key to update  Signature field
          | in  Integrity protection option header. Include Node's
          |                       KeyID in the extended node data.
          |                                              |
          (--        Packet reaches Validator          --)
          |                                              |
    Get Node's key using Node's KeyID                    |
    present in extended node data.                       |
    Validate  Signature using Node's key.                |

The main steps of method 4 are:¶

1. Each node will establish a common secret seed establishment using McEliece [McEliece] with the Validator.¶

2. Each node will then use the seed to generate a symmetric key per packet and use it in updating the Signature field in the IOAM Trace-Option header over its node data hash. The node data is extended to include the KeyID of the dynamic key generated.¶

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            KeyID [x]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        node data list [x]                     |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   

   ¶
3. The Validator will validate the Signature by deducing the key for each node using the KeyID.¶

The detailed mechanisms how keys and seeds are exchanged between nodes are outside the scope of this document.¶

A.4. Method 5: Leverage IP Authentication Header

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays as defined in RFC4302 [RFC4302]. The AH provides authentication for as much of the IP header as possible, by classifying and including the immutable fields in the integrity calculation. To protect the IOAM data in the IP header, the AH may be employed in transport mode by setting up an IP AH Security Association (SA) with supported integrity algorithms between IOAM encapsulating nodes, IOAM decapsulating nodes and IOAM transit nodes. Method 5 utilizes the IP AH for integrity protection of IOAM options that are immutable enroute between IOAM entities that are required to validate the integrity of the IOAM data. It is applicable to IOAM Option-Types as follows:¶

1. IOAM Edge-to-Edge Option-Type: The data for this IOAM Option-Type is immutable enroute and can be integrity checked using an IP AH between IOAM-encapsulating nodes and IOAM-decapsulating nodes.¶
2. The Direct Exporting (DEX) IOAM Option-Type ([I-D.ietf-ippm-ioam-direct-export]): The data for this IOAM Option-Type is immutable enroute and can be integrity checked using an IP AH between IOAM-encapsulating nodes and IOAM-decapsulating nodes. IOAM-transit nodes, that use the IOAM DEX Option-Type as a trigger to export IOAM data fields, and which are to validate the IOAM DEX Option-Type data fields may have to be configured with shared secrets, in case the AH negotiated integrity algorithm relies on shared secrets. These shared secrets correspond to those secrets that result from the IP AH integrity algorithm negotiated during SA setup.¶
3. IOAM Proof of Transit Option-Type: This IOAM Option-Type is mutable by IOAM-transit nodes enroute that participate in proof of transit operation. Hence the IP AH based integrity protection method does not apply.¶
4. IOAM Pre-allocated and Incremental Trace Option-Types: These IOAM Option-Types are mutable by IOAM-transit nodes encroute that process IOAM tracing Option-Types. Hence the IP AH based integrity protection method does not apply.¶