ippm F. Brockners
Internet-Draft Cisco
Intended status: Informational S. Bhandari
Expires: January 8, 2022 Thoughtspot
T. Mizrahi
Huawei
July 7, 2021
Integrity of In-situ OAM Data Fields
draft-brockners-ippm-ioam-data-integrity-02
Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document is
to assist the IPPM WG in designing a solution for those deployments
where the integrity of IOAM data fields is a concern. This document
proposes several methods to ensure the integrity of IOAM data fields.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Brockners, et al. Expires January 8, 2022 [Page 1]
Internet-Draft IOAM Data Fields Integrity July 2021
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Modification: IOAM Data Fields . . . . . . . . . . . . . 5
3.2. Modification: IOAM Option-Type Headers . . . . . . . . . 6
3.3. Injection: IOAM Data Fields . . . . . . . . . . . . . . . 6
3.4. Injection: IOAM Option-Type Headers . . . . . . . . . . . 6
3.5. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Management and Exporting . . . . . . . . . . . . . . . . 7
3.7. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Threat Summary . . . . . . . . . . . . . . . . . . . . . 8
4. Methods of providing integrity to IOAM data fields . . . . . 8
4.1. Integrity Protected IOAM Options . . . . . . . . . . . . 9
4.2. Integrity Protected IOAM Options sub-header . . . . . . . 9
4.3. Space optimized symmetric key based signing of trace data 11
4.3.1. Overhead consideration . . . . . . . . . . . . . . . 12
4.4. Space optimized asymmetric key based signing of trace
data . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Overhead consideration . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 13
5.2. IOAM Integrity Protection Algorithm Suite Registry . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Appendix - Alternate methods for integrity
protection and validation . . . . . . . . . . . . . 17
A.1. Method 1: Using asymmetric keys for signing node trace
data . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.1.1. Overhead consideration for Method 1 . . . . . . . . . 19
A.2. Method 2: Using symmetric keys for signing node trace
data . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.2.1. Overhead consideration for Method 2 . . . . . . . . . 19
A.3. Method 4: Dynamic symmetric keys based signing of trace
data . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3.1. Overhead consideration for Method 4 . . . . . . . . . 22
A.4. Method 5: Leverage IP Authentication Header . . . . . . . 22
A.4.1. Overhead consideration for Method 5 . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Brockners, et al. Expires January 8, 2022 [Page 2]
Internet-Draft IOAM Data Fields Integrity July 2021
1. Introduction
"In-situ" Operations, Administration, and Maintenance (IOAM) records
OAM information within the packet while the packet traverses a
particular network domain. The term "in-situ" refers to the fact
that the OAM data is added to the data packets rather than is being
sent within packets specifically dedicated to OAM. IOAM is to
complement mechanisms such as Ping, Traceroute, or other active
probing mechanisms. 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 [RFC7799] IOAM
could be portrayed as Hybrid Type 1. 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 live 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.
The current [I-D.ietf-ippm-ioam-data] assumes that IOAM is deployed
in specific network domains, where an operator has means to select,
monitor, and control the access to all the networking devices, making
the domain a trusted network. As such, IOAM tracing data is carried
in the packets in clear and there are no protections against any node
or middlebox tampering with the data. As a consequence, IOAM tracing
data collected in an untrusted or semi-trusted environments cannot be
trusted for critical operational decisions. Any rogue or
unauthorized change to IOAM data fields in a user packet cannot be
detected.
Recent discussions following the IETF last call on
[I-D.ietf-ippm-ioam-data] revealed that there might be uses of IOAM
where integrity protection of IOAM data fields is at least desirable,
knowing that IOAM data fields integrity protection would incur extra
effort in the data path of a device processing IOAM data fields. As
such, the following additional considerations and requirements are to
be taken into account in addition to addressing the problem of
detectability of any integrity breach of the IOAM trace data
collected:
1. IOAM trace data is processed by the data plane, hence viability
of any method to prove integrity of the IOAM trace data must be
feasible at data plane processing/forwarding rates (IOAM data
might be applied to all traffic a router forwards).
Brockners, et al. Expires January 8, 2022 [Page 3]
Internet-Draft IOAM Data Fields Integrity July 2021
2. IOAM trace data is carried within data packets. Additional space
required to prove integrity of the data needs to be optimal, i.e.
should not exceed the MTU or have adverse affect on packet
processing.
3. Replay protection of older IOAM trace data should be possible.
Without replay protection a rogue node can present the old IOAM
trace data masking any ongoing network issues/activity making the
IOAM trace data collection useless.
This document is to assist the IPPM working group in designing and
specifying a solution for those deployments where the integrity of
IOAM data fields is a concern. This document proposes several
methods to achieve integrity protection for IOAM data fields.
The discussion of the different methods to protect the integrity of
IOAM data fields focuses mostly on protecting the integrity of IOAM
trace data fields, though the outlined methods are not limited to
protecting IOAM trace data fields only. The methods could be applied
to other IOAM Option-Types, such as the E2E Option-Type or the DEX
Option-Type. If methods only apply to a specific set of IOAM Option-
Types, like e.g. the method 5 discussed below, those limits are
discussed and explained explicitly.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Abbreviations used in this document:
Geneve: Generic Network Virtualization Encapsulation
[I-D.ietf-nvo3-geneve]
GRE Generic Routing Encapsulation
IOAM: In-situ Operations, Administration, and Maintenance
MTU: Maximum Transmit Unit
NSH: Network Service Header [RFC8300]
OAM: Operations, Administration, and Maintenance
POT: Proof of Transit
SFC: Service Function Chain
Brockners, et al. Expires January 8, 2022 [Page 4]
Internet-Draft IOAM Data Fields Integrity July 2021
3. Threat Analysis
This section presents a threat analysis of integrity-related threats
in the context of IOAM. The threats that are discussed are assumed
to be independent of the lower layer protocols; it is assumed that
threats at other layers are handled by security mechanisms that are
deployed at these layers.
This document is focused on integrity protection for IOAM data
fields. Thus the threat analysis includes threats that are related
to or result from compromising the integrity of IOAM data fields.
Other security aspects such as confidentiality are not within the
scope of this document.
Throughout the analysis there is a distinction between on-path and
off-path attackers. As discussed in [I-D.ietf-detnet-security], on-
path attackers are located in a position that allows interception and
modification of in-flight protocol packets, whereas off-path
attackers can only attack by generating protocol packets.
The analysis also includes the impact of each of the threats.
Generally speaking, the impact of a successful attack on an OAM
protocol [RFC7276] is 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.
3.1. Modification: IOAM Data Fields
Threat
An attacker can maliciously 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. This threat is applicable to on-path attackers.
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.
Brockners, et al. Expires January 8, 2022 [Page 5]
Internet-Draft IOAM Data Fields Integrity July 2021
3.2. Modification: IOAM Option-Type Headers
Threat
An on-path attacker can modify IOAM data fields in one or more of
the IOAM Option-Type headers 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 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.
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.
Brockners, et al. Expires January 8, 2022 [Page 6]
Internet-Draft IOAM Data Fields Integrity July 2021
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
Brockners, et al. Expires January 8, 2022 [Page 7]
Internet-Draft IOAM Data Fields Integrity July 2021
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 | | + |
+-------------------------------------------+--------+------------+
Figure 1: Threat Analysis Summary
4. Methods of providing integrity to IOAM data fields
This section describes enhancements to IOAM Options to carry an
intergrity data fields. This can be achieved using symmetric or
asymetric key based signatures as described below sub-sections.
Brockners, et al. Expires January 8, 2022 [Page 8]
Internet-Draft IOAM Data Fields Integrity July 2021
4.1. Integrity Protected IOAM Options
Each of the IOAM Options defined in [I-D.ietf-ippm-ioam-data] are
extended to include Integrity Protected (IP) options by allocating
the following IOAM Option-Types in the IOAM Option-Type registry.
64 IOAM Pre-allocated Trace Intergrity Protected Option-Type
corresponds to IOAM Pre-allocated Trace Option-Type with integrity
protection.
65 IOAM Incremental Trace Intergrity Protected Option-Type
corresponds to IOAM Incremental Trace Option-Type with integrity
protection.
66 IOAM POT Intergrity Protected Option-Type corresponds to IOAM POT
Option-Type with integrity protection.
67 IOAM E2E Intergrity Protected Option-Type corresponds to IOAM E2E
Option-Type with integrity protection.
4.2. Integrity Protected IOAM Options sub-header
The integrity data sub-header is included in IOAM Integrity Protected
Options 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signature-suite: 8-bit unsigned integer. This field defines the
algorithms used to compute digest and signature over the Option
header and data excluding the Signature field.
Nonce length: 8-bit unsigned integer. This field specifies the
length of the Nonce field in octets.
Reserved: 16-bit Reserved field MUST be set to zero upon
transmission and ignored upon receipt.
Brockners, et al. Expires January 8, 2022 [Page 9]
Internet-Draft IOAM Data Fields Integrity July 2021
Nonce: Variable length field with length specified in Nonce length.
Signature: is the digital signature value generated by the method
and algorithm specified by Signature-suite.
The Integrity sub-header will follow the IOAM Option header when the
IOAM Option Type is Intergrity Protected Option. Pre-allocated and
incremental Trace option headers are as defined in
[I-D.ietf-ippm-ioam-data]. When IOAM Option Type is set to IOAM Pre-
allocated Trace Intergrity Protected Option-Type or IOAM Incremental
Trace Intergrity Protected Option-Type then Integrity Protection
subheader follows the original IOAM Option Type header: :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID |NodeLen | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Signature-suite| Nonce length | Reserved. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM POT option header as defined in [I-D.ietf-ippm-ioam-data] is
followed by Integrity Protection subheader when IOAM Option Type is
set to IOAM POT Intergrity 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 POT Type | IOAM POT flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Signature-suite| Nonce length | Reserved. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM E2E option header as defined in [I-D.ietf-ippm-ioam-data] is
followed by Integrity Protection subheader when IOAM Option Type is
set to IOAM E2E Intergrity Protected Option-Type:
Brockners, et al. Expires January 8, 2022 [Page 10]
Internet-Draft IOAM Data Fields Integrity July 2021
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
Brockners, et al. Expires January 8, 2022 [Page 11]
Internet-Draft IOAM Data Fields Integrity July 2021
4.3.1. Overhead consideration
The Signature would consume 32 bytes with AES-256 - though with this
method the Signature is only carried once for the entire packet. As
there are dedicated options for carrying IOAM data with integrity
protection, in case of performance concerns in calculating signature
and validating it, these options can be used for a subset of the
packets by using sampling of data to enable IOAM with integrity
protection.
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].
4.4.1. Overhead consideration
The Signature would consume 32 bytes based on the SHA-256 ECDSA P-256
algorithm employed - though with this method the Signature is only
carried once for the entire packet. As there are dedicated options
Brockners, et al. Expires January 8, 2022 [Page 12]
Internet-Draft IOAM Data Fields Integrity July 2021
for carrying IOAM data with integrity protection, in case of
performance concerns in calculating signature and validating it,
these options can be used for a subset of the packets by using
sampling of data to enable IOAM with integrity protection.
5. IANA Considerations
5.1. IOAM Option-Type Registry
The following code points are defined in this draft in "IOAM Option-
Type Registry" :
64 IOAM Pre-allocated Trace Intergrity Protected Option-Type
65 IOAM Incremental Trace Intergrity Protected Option-Type
66 IOAM POT Intergrity Protected Option-Type
67 IOAM E2E Intergrity Protected Option-Type
5.2. IOAM Integrity Protection Algorithm Suite Registry
"IOAM Integrity Protection Algorithm Suite Registry" in the "In-Situ
OAM (IOAM) Protocol Parameters" group. The one-octet "IOAM Integrity
Protection Algorithm Suite Registry" identifiers assigned by IANA
identify the digest algorithm and signature algorithm used in the
Signature Suite Identifier field. IANA has registered the following
algorithm suite identifiers for the digest algorithm and for the
signature algorithm.
IOAM Integrity Protection Algorithm Suite Registry
Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer
Identifier
+------------+------------+-------------+-----------------------+
| 0x0 | Reserved | Reserved | This document |
+------------+------------+-------------+-----------------------+
| 0x1 | SHA-256 | ECDSA P-256 | [SHS] [DSS] [RFC6090] |
| | | | This document |
+------------+------------+-------------+-----------------------+
| 0x2 | SHA-256 | AES-256 | [AES] [NIST.800-38D] |
| | | | This document |
+------------+------------+-------------+-----------------------+
| 0xEF-0xFF | Unassigned | Unassigned | |
+------------+------------+-------------+-----------------------+
Brockners, et al. Expires January 8, 2022 [Page 13]
Internet-Draft IOAM Data Fields Integrity July 2021
Future assignments are to be made using the Standards Action process
defined in [RFC8126]. Assignments consist of the one-octet algorithm
suite identifier value and the associated digest algorithm name and
signature algorithm name.
6. Security Considerations
This section will be completed in a future revision of this document.
7. Acknowledgements
The authors would like to thank Santhosh N, Rakesh Kandula, Saiprasad
Muchala, Greg Mirsky, Benjamin Kaduk and Martin Duke for their
comments and advice.
8. References
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>.
Brockners, et al. Expires January 8, 2022 [Page 14]
Internet-Draft IOAM Data Fields Integrity July 2021
[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",
draft-brockners-ippm-ioam-geneve-05 (work in progress),
November 2020.
[I-D.ietf-detnet-security]
Grossman, E., Mizrahi, T., and A. J. Hacker,
"Deterministic Networking (DetNet) Security
Considerations", draft-ietf-detnet-security-16 (work in
progress), March 2021.
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in
progress), February 2021.
[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", draft-ietf-ippm-ioam-direct-
export-03 (work in progress), February 2021.
[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", draft-ietf-ippm-ioam-
ipv6-options-05 (work in progress), February 2021.
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-16 (work in progress), March 2020.
[I-D.ietf-sfc-ioam-nsh]
Brockners, F. and S. Bhandari, "Network Service Header
(NSH) Encapsulation for In-situ OAM (IOAM) Data", draft-
ietf-sfc-ioam-nsh-05 (work in progress), December 2020.
Brockners, et al. Expires January 8, 2022 [Page 15]
Internet-Draft IOAM Data Fields Integrity July 2021
[I-D.ietf-sfc-proof-of-transit]
Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.
Youell, "Proof of Transit", draft-ietf-sfc-proof-of-
transit-08 (work in progress), November 2020.
[McEliece]
McEliece, R., "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>.
Brockners, et al. Expires January 8, 2022 [Page 16]
Internet-Draft IOAM Data Fields Integrity July 2021
[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>.
Appendix A. Appendix - Alternate methods for integrity protection and
validation
This section outlines three different methods that are to provide
integrity protection of IOAM data fields. As noted earlier, this
document is to support the IPPM working group in designing and
specifying a method for protecting the integrity of IOAM data fields.
It isn't expected that all four methods would be chosen for a
solution specification.
As already stated in the introduction, the discussion of the
different methods focuses mostly on protecting the integrity of IOAM
trace data fields, though the outlined methods are not limited to
protecting IOAM trace data fields only. The methods could be applied
to other IOAM Option-Types, such as the E2E Option-Type or the DEX
Option-Type.
IOAM trace data can be embedded in a variety of protocols. There are
specific drafts that cover the encapsulation of IOAM data into
different protocols, like IPv6 [I-D.ietf-ippm-ioam-ipv6-options], NSH
[I-D.ietf-sfc-ioam-nsh], Geneve [I-D.brockners-ippm-ioam-geneve],
etc.
The IOAM Option-Types for tracing (Pre-allocated Trace-Option and
Incremental Trace-Option) organize the collected data in an array,
the "node data list". See [I-D.ietf-ippm-ioam-data] for further
details).
The basic idea is to introduce a new "signed node-data hash field"
added by each node along with the node data to prove the integrity of
the node data inserted.
The following sections describe different methods of how such a
"signed node-data field" could be used and populated. The methods
assume an IOAM-Domain containing IOAM-encapsulating nodes, IOAM-
decapsulating nodes and IOAM-transit nodes. In addition, it is
assumed that traffic also traverses a Validator node, which verifies
the integrity of the IOAM data fields. In a typical deployment, the
IOAM-decapsulating node would also serve as the Validator. The setup
also includes a network management entity/controller which handles
key distributions to the network nodes and also serves as a receiver
for validation results provided by the Validator. Protocols and
Brockners, et al. Expires January 8, 2022 [Page 17]
Internet-Draft IOAM Data Fields Integrity July 2021
procedures for the exchange of keys and validation results between
the network management entity/controller and the nodes are outside
the scope of this document.
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
Brockners, et al. Expires January 8, 2022 [Page 18]
Internet-Draft IOAM Data Fields Integrity July 2021
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.1.1. Overhead consideration for Method 1
Assuming e.g Ed25519, the public keys would have a size of 256 bits /
32 bytes, and as such signatures would be 512 bits / 64 bytes wide.
node_data_sign[x] would consume 64 bytes per hop. Note that
depending on the deployment, weaker keys might well apply, given that
the provided integrity check is an online method, i.e. packets are
verified as they arrive. This allows an attacker only a short time-
window.
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.2.1. Overhead consideration for Method 2
Different types of cryptographic message authentication codes could
be chosen, such as HMAC-SHA256 or Poly1305-AES.
HMAC-SHA256 would take a secret key of any size and provide a 32 byte
authenticator. Consequently, node_data_sign[x] would consume 32
bytes per hop.
Poly1305-AES would use a 32 bytes secret key and provide a 16 byte
authenticator. Consequently, node_data_sign[x] would consume 16
bytes per hop.
Brockners, et al. Expires January 8, 2022 [Page 19]
Internet-Draft IOAM Data Fields Integrity July 2021
Methods 1 and 2 add a node_data_sign field at every IOAM node the
packet traverses. While feasible for network domains with only a few
IOAM enabled hops, the number of bytes consumed in case of larger
networks might not be acceptable.
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:
Brockners, et al. Expires January 8, 2022 [Page 20]
Internet-Draft IOAM Data Fields Integrity July 2021
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.
Brockners, et al. Expires January 8, 2022 [Page 21]
Internet-Draft IOAM Data Fields Integrity July 2021
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.3.1. Overhead consideration for Method 4
Like with method 3, the Signature is only carried once for the entire
packet and could be 32 bytes total. In addition, the KeyID needs to
be added on a per hop basis. For sizing the Key ID, similar
considerations like those for proof-of-transit packet random numbers
apply - i.e. it depends on the packet rates of quickly keys are
consumed. E.g. assuming a packet rate of 100Gbps and a KeyID space
of 64 bits / 8 bytes, the system would need to be re-keyed after 3100
years (see also [I-D.ietf-sfc-proof-of-transit]). If frequent re-
keying is feasible, 32 bits for KeyID might well be feasible.
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.
Brockners, et al. Expires January 8, 2022 [Page 22]
Internet-Draft IOAM Data Fields Integrity July 2021
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.
A.4.1. Overhead consideration for Method 5
This method involves overhead of setting up and maintaining SA for
the AH IOAM-encapsulating nodes and IOAM-decapsulating nodes. The
anti-replay mechanism supported by IP AH must be enabled for this
method to effectively protect IOAM data fields whose integrity and
freshness needs to be guarenteed. The anti-replay mechanism of IP AH
has the overhead of maintaining and validating sequence numbers as
part of the IP AH validation. In cases where IOAM-transit nodes have
to validate IOAM Option-Types e.g. the DEX Option-Type, then there
will be additional overhead to distribute shared secrets to the
transit nodes when the integrity algorithm is based on shared
secrets.
Authors' Addresses
Frank Brockners
Cisco Systems, Inc.
Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEIN-WESTFALEN 40549
Germany
Email: fbrockne@cisco.com
Brockners, et al. Expires January 8, 2022 [Page 23]
Internet-Draft IOAM Data Fields Integrity July 2021
Shwetha Bhandari
Thoughtspot
3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout
Bangalore, KARNATAKA 560 102
India
Email: shwetha.bhandari@thoughtspot.com
Tal Mizrahi
Huawei
8-2 Matam
Haifa 3190501
Israel
Email: tal.mizrahi.phd@gmail.com
Brockners, et al. Expires January 8, 2022 [Page 24]