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 IOAM 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 "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. Transit 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. Transit 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 uses 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. Transit 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. Transit 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 uses 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>.

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

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

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

[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-15, 3 October 2021, <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-data-15.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-07, 13 October 2021, <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-direct-export-07.txt>.

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

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

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