< draft-ietf-ippm-ioam-data-05.txt   draft-ietf-ippm-ioam-data-06.txt >
ippm F. Brockners ippm F. Brockners
Internet-Draft S. Bhandari Internet-Draft S. Bhandari
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: September 11, 2019 Cisco Expires: January 5, 2020 Cisco
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Leddy J. Leddy
Comcast
S. Youell S. Youell
JPMC JPMC
T. Mizrahi T. Mizrahi
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
D. Mozes D. Mozes
P. Lapukhov P. Lapukhov
Facebook Facebook
R. Chang R. Chang
Barefoot Networks Barefoot Networks
D. Bernier D. Bernier
Bell Canada Bell Canada
J. Lemon J. Lemon
Broadcom Broadcom
March 10, 2019 July 04, 2019
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-05 draft-ietf-ippm-ioam-data-06
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document traverses a path between two points in the network. This document
discusses the data fields and associated data types for in-situ OAM. discusses the data fields and associated data types for in-situ OAM.
In-situ OAM data fields can be embedded into a variety of transports In-situ OAM data fields can be embedded into a variety of transports
such as NSH, Segment Routing, Geneve, native IPv6 (via extension such as NSH, Segment Routing, Geneve, native IPv6 (via extension
header), or IPv4. In-situ OAM can be used to complement OAM header), or IPv4. In-situ OAM can be used to complement OAM
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2019. This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4 3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4
4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5 4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5
4.1. IOAM Namespaces . . . . . . . . . . . . . . . . . . . . . 7 4.1. IOAM Namespaces . . . . . . . . . . . . . . . . . . . . . 7
4.2. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 9 4.2. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 9
4.2.1. Pre-allocated and Incremental Trace Options . . . . . 11 4.2.1. Pre-allocated and Incremental Trace Options . . . . . 11
4.2.2. IOAM node data fields and associated formats . . . . 17 4.2.2. IOAM node data fields and associated formats . . . . 15
4.2.3. Examples of IOAM node data . . . . . . . . . . . . . 22 4.2.3. Examples of IOAM node data . . . . . . . . . . . . . 21
4.3. IOAM Proof of Transit Option . . . . . . . . . . . . . . 24 4.3. IOAM Proof of Transit Option . . . . . . . . . . . . . . 22
4.3.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 26 4.3.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 24
4.4. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 27 4.4. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 25
5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 29 5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 27
5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 29 5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 27
5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 30 5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 28
5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 31 5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 29
6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 33 6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7.1. Creation of a new In-Situ OAM Protocol Parameters 7.1. Creation of a new In-Situ OAM Protocol Parameters
Registry (IOAM) Protocol Parameters IANA registry . . . . 33 Registry (IOAM) Protocol Parameters IANA registry . . . . 31
7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 34 7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 32
7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 34 7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 32
7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 35 7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 33
7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 35 7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 33
7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 35 7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 33
7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 36 7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 33
7.8. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 36 7.8. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document defines data fields for "in-situ" Operations, This document defines data fields for "in-situ" Operations,
Administration, and Maintenance (IOAM). In-situ OAM records OAM Administration, and Maintenance (IOAM). In-situ OAM records OAM
information within the packet while the packet traverses a particular information within the packet while the packet traverses a particular
network domain. The term "in-situ" refers to the fact that the OAM 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 data is added to the data packets rather than is being sent within
packets specifically dedicated to OAM. IOAM is to complement packets specifically dedicated to OAM. IOAM is to complement
mechanisms such as Ping or Traceroute, or more recent active probing mechanisms such as Ping or Traceroute, or more recent active probing
skipping to change at page 5, line 34 skipping to change at page 5, line 34
document. document.
Layering: If several encapsulation protocols (e.g., in case of Layering: If several encapsulation protocols (e.g., in case of
tunneling) are stacked on top of each other, IOAM data-records could tunneling) are stacked on top of each other, IOAM data-records could
be present at every layer. The behavior follows the ships-in-the- be present at every layer. The behavior follows the ships-in-the-
night model, i.e. IOAM data in one layer is independent from IOAM night model, i.e. IOAM data in one layer is independent from IOAM
data in another layer. Layering allows operators to instrument the data in another layer. Layering allows operators to instrument the
protocol layer they want to measure. The different layers could, but protocol layer they want to measure. The different layers could, but
do not have to share the same IOAM encapsulation and decapsulation. do not have to share the same IOAM encapsulation and decapsulation.
Combination with active OAM mechanisms: IOAM should be usable for
active network probing, enabling for example a customized version of
traceroute. IOAM may also be carried out on cloned or sampled copies
of data packets, when the operator prefers not to directly modify
data packets for IOAM purposes. Decapsulating IOAM nodes must have
the ability to discard active IOAM packets, potentially in addition
to retrieving the IOAM information.
IOAM implementation: The IOAM data-field definitions take the IOAM implementation: The IOAM data-field definitions take the
specifics of devices with hardware data-plane and software data-plane specifics of devices with hardware data-plane and software data-plane
into account. into account.
4. IOAM Data Types and Formats 4. IOAM Data Types and Formats
This section defines IOAM data types and data fields and associated This section defines IOAM data types and data fields and associated
data types required for IOAM. data types required for IOAM.
To accommodate the different uses of IOAM, IOAM data fields fall into To accommodate the different uses of IOAM, IOAM data fields fall into
skipping to change at page 7, line 15 skipping to change at page 7, line 7
packet, and cannot change an IOAM Edge-to-Edge Option. packet, and cannot change an IOAM Edge-to-Edge Option.
An IOAM decapsulating node removes all the IOAM-Types from packets. An IOAM decapsulating node removes all the IOAM-Types from packets.
The role of a node (i.e. encapsulating, transit, decapsulating) is The role of a node (i.e. encapsulating, transit, decapsulating) is
defined within an IOAM namespace (see below). A node can have defined within an IOAM namespace (see below). A node can have
different roles in different IOAM namespaces. different roles in different IOAM namespaces.
4.1. IOAM Namespaces 4.1. IOAM Namespaces
IOAM data fields are defined within an IOAM namespace. An IOAM A subset or all of the IOAM option types and associated IOAM data
namespace is identified by a 16-bit namespace identifier (Namespace- fields can be associated to an IOAM namespace. Namespaces add
ID). Namespace identifiers MUST be present and populated in all IOAM further context to IOAM option types and associated IOAM data fields.
option headers. The Namespace-ID value is divided into two sub- Any IOAM namespace MUST interpret the IOAM option types and
ranges: associated IOAM data fields per the definition in this document.
Namespaces group nodes to support different deployment approaches of
IOAM (see a few example use-cases below) as well as resolve issues
which can occur due to IOAM data fields not being globally unique
(e.g. IOAM node identifiers do not have to be globally unique).
IOAM data fields are defined within an IOAM namespace.
An IOAM namespace is identified by a 16-bit namespace identifier
(Namespace-ID). Namespace identifiers MUST be present and populated
in all IOAM option headers. The Namespace-ID value is divided into
two sub-ranges:
o An operator-assigned range from 0x0001 to 0x7FFF o An operator-assigned range from 0x0001 to 0x7FFF
o An IANA-assigned range from 0x8000 to 0xFFFF o An IANA-assigned range from 0x8000 to 0xFFFF
The IANA-assigned range is intended to allow future extensions to The IANA-assigned range is intended to allow future extensions to
have new and interoperable IOAM functionality, while the operator- have new and interoperable IOAM functionality, while the operator-
assigned range is intended to be domain specific, and managed by the assigned range is intended to be domain specific, and managed by the
network operator. The Namespace-ID value of 0x0000 is default and network operator. The Namespace-ID value of 0x0000 is default and
known to all the nodes implementing IOAM. known to all the nodes implementing IOAM.
skipping to change at page 9, line 15 skipping to change at page 9, line 19
the two namespaces need to be correlated. the two namespaces need to be correlated.
4.2. IOAM Tracing Options 4.2. IOAM Tracing Options
"IOAM tracing data" is expected to be collected at every node that a "IOAM tracing data" is expected to be collected at every node that a
packet traverses to ensure visibility into the entire path a packet packet traverses to ensure visibility into the entire path a packet
takes within an IOAM domain, i.e., in a typical deployment all nodes takes within an IOAM domain, i.e., in a typical deployment all nodes
in an in-situ OAM-domain would participate in IOAM and thus be IOAM in an in-situ OAM-domain would participate in IOAM and thus be IOAM
transit nodes, IOAM encapsulating or IOAM decapsulating nodes. If transit nodes, IOAM encapsulating or IOAM decapsulating nodes. If
not all nodes within a domain are IOAM capable, IOAM tracing not all nodes within a domain are IOAM capable, IOAM tracing
information will only be collected on those nodes which are IOAM information (i.e., node data) will only be collected on those nodes
capable. Nodes which are not IOAM capable will forward the packet which are IOAM capable. Nodes which are not IOAM capable will
without any changes to the IOAM data fields. The maximum number of forward the packet without any changes to the IOAM data fields. The
hops and the minimum path MTU of the IOAM domain is assumed to be maximum number of hops and the minimum path MTU of the IOAM domain is
known. assumed to be known.
To optimize hardware and software implementations tracing is defined To optimize hardware and software implementations tracing is defined
as two separate options. Any deployment MAY choose to configure and as two separate options. Any deployment MAY choose to configure and
support one or both of the following options. An implementation of support one or both of the following options. An implementation of
the transport protocol that carries these in-situ OAM data MAY choose the transport protocol that carries these in-situ OAM data MAY choose
to support only one of the options. In the event that both options to support only one of the options. In the event that both options
are utilized at the same time, the Incremental Trace Option MUST be are utilized at the same time, the Incremental Trace Option MUST be
placed before the Pre-allocated Trace Option. Given that the placed before the Pre-allocated Trace Option. Given that the
operator knows which equipment is deployed in a particular IOAM, the operator knows which equipment is deployed in a particular IOAM, the
operator will decide by means of configuration which type(s) of trace operator will decide by means of configuration which type(s) of trace
skipping to change at page 13, line 17 skipping to change at page 13, line 17
For example, if 3 IOAM-Trace-Type bits are set and none of them For example, if 3 IOAM-Trace-Type bits are set and none of them
are wide, then NodeLen would be 3. If 3 IOAM-Trace-Type bits are are wide, then NodeLen would be 3. If 3 IOAM-Trace-Type bits are
set and 2 of them are wide, then NodeLen would be 5. set and 2 of them are wide, then NodeLen would be 5.
An IOAM encapsulating node must set NodeLen. An IOAM encapsulating node must set NodeLen.
A node receiving an IOAM Pre-allocated or Incremental Trace Option A node receiving an IOAM Pre-allocated or Incremental Trace Option
may rely on the NodeLen value, or it may ignore the NodeLen value may rely on the NodeLen value, or it may ignore the NodeLen value
and calculate the node length from the IOAM-Trace-Type bits. and calculate the node length from the IOAM-Trace-Type bits.
Flags 4-bit field. The following flags are defined: Flags 4-bit field. Flags are allocated by IANA, as specified in
Section 7.4. The current document allocates a single flag as
follows:
Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set
by the network element if there is not enough number of octets by the network element if there are not enough octets left to
left to record node data, no field is added and the overflow record node data, no field is added and the overflow "O-bit"
"O-bit" must be set to "1" in the header. This is useful for must be set to "1" in the header. This is useful for transit
transit nodes to ignore further processing of the option. nodes to ignore further processing of the option.
Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy
of a packet back towards the source. Loopback mode assumes
that a return path from transit nodes and destination nodes
towards the source exists. The encapsulating node decides
(e.g., using a filter) which packets loopback mode is enabled
for by setting the loopback bit. The encapsulating node also
needs to ensure that sufficient space is available in the IOAM
header for loopback operation, which includes intermediate
nodes adding trace data on the original path and then again on
the return path. A loopback bit that is set indicates to the
transit nodes processing this option that they are to create a
copy of the received packet and send the copy back to the
source of the packet. The copy has its metadata added after
being copied in order to allow any egress-dependent information
to be set based on the egress of the copy rather than the
original. The original packet continues towards its
destination. The source address of the original packet is used
as the destination address in the copied packet. The address
of the node performing the copy operation is used as the source
address. The L-bit MUST be cleared in the copy of the packet
that a node sends back towards the source. On its way back
towards the source, the copied packet is processed like any
other packet with IOAM information, including adding any
requested data at each transit node (assuming there is
sufficient space). Once the return packet reaches the IOAM
domain boundary, IOAM decapsulation occurs as with any other
packet containing IOAM information. Because any intermediate
node receiving such a packet would not know how to process the
original packet, and because there would be a risk of the
original packet leaking past the initiator of the IOAM
loopback, the initiator of an IOAM loopback MUST be the
initiator of the packet. Once a loopback packet is received
back at the initiator, it is a local matter how it is
recognized as a loopback packet.
Bit 2 "Active" (A-bit). When set, this indicates that this is an
active OAM packet, where "active" is used in the sense defined
in [RFC7799], rather than a data packet. For example, the
packet may be a probe, or it may be a (possibly truncated) copy
of a data packet. At the IOAM decapsulating node, in addition
to processing and/or exporting the metadata, the packet must be
discarded rather than forwarded. If this bit is not set, then
the decapsulating node should attempt to forward the packet
after IOAM decapsulation.
Bit 3 "Immediate Export" (I-bit). Immediate export mode is used
to export IOAM data fields immediately at every IOAM supported
network node, instead of adding the IOAM data fields to the
packet traversing the network. The various types of IOAM nodes
MUST process packets with the I-bit set as follows:
1. An encapsulating IOAM node configured to set the I-bit
encapsulates the packet with the IOAM header and sets the
I-bit, leaving the IOAM header without locally collected
data, and exports the requested IOAM data immediately. The
encapsulating IOAM node is the only type of node allowed to
set the I-bit.
2. A transit node that processes a packet with the I-bit set
is expected to export the requested IOAM data, and not
incorporate it into the IOAM header.
3. A decapsulating IOAM node that processes a packet with the
I-bit set is expected to export the requested IOAM data,
and decapsulate the IOAM header.
Note that in case of "Immediate Export" being employed, no IOAM
trace data is added to the packets traversing the network. As
a means to support correlation of exported IOAM data different
nodes in the network, a deployment could consider attaching an
IOAM E2E option in addition to the trace option, that includes
a sequence number. See Bit 1 in the IOAM-E2E-Types. Please
refer to Section 6 for a discussion of IOAM data export and
associated formats.
RemainingLen: 7-bit unsigned integer. This field specifies the data RemainingLen: 7-bit unsigned integer. This field specifies the data
space in multiples of 4-octets remaining for recording the node space in multiples of 4-octets remaining for recording the node
data, before the node data list is considered to have overflowed. data, before the node data list is considered to have overflowed.
When RemainingLen reaches 0, nodes are no longer allowed to add When RemainingLen reaches 0, nodes are no longer allowed to add
node data. Given that the sender knows the minimum path MTU, the node data. Given that the sender knows the minimum path MTU, the
sender MAY set the initial value of RemainingLen according to the sender MAY set the initial value of RemainingLen according to the
number of node data bytes allowed before exceeding the MTU. number of node data bytes allowed before exceeding the MTU.
Subsequent nodes can carry out a simple comparison between Subsequent nodes can carry out a simple comparison between
RemainingLen and NodeLen, along with the length of the "Opaque RemainingLen and NodeLen, along with the length of the "Opaque
skipping to change at page 35, line 18 skipping to change at page 33, line 18
Bit 11 buffer occupancy Bit 11 buffer occupancy
Bit 23 checksum complement Bit 23 checksum complement
The meaning for Bits 12 - 22 are available for assignment via RFC The meaning for Bits 12 - 22 are available for assignment via RFC
Required process as per [RFC8126]. Required process as per [RFC8126].
7.4. IOAM Trace Flags Registry 7.4. IOAM Trace Flags Registry
This registry defines code points for each bit in the 4 bit flags for This registry defines code points for each bit in the 4 bit flags for
Pre-allocated trace option and Incremental trace option defined in the Pre-allocated trace option and for the Incremental trace option
Section 4.2. The meaning of Bit 0 - 2 for trace flags are defined in defined in Section 4.2. The meaning of Bit 0 (the most significant
this document in Paragraph 3 of Section 4.2.1: bit) for trace flags is defined in this document in Paragraph 3 of
Section 4.2.1:
Bit 0 "Overflow" (O-bit) Bit 0 "Overflow" (O-bit)
Bit 1 "Loopback" (L-bit)
Bit 2 "Active" (A-bit)
Bit 3 "Immediate Export" (I-bit)
7.5. IOAM POT Type Registry 7.5. IOAM POT Type Registry
This registry defines 256 code points to define IOAM POT Type for This registry defines 256 code points to define IOAM POT Type for
IOAM proof of transit option Section 4.3. The code point value 0 is IOAM proof of transit option Section 4.3. The code point value 0 is
defined in this document: defined in this document:
0: 16 Octet POT data 0: 16 Octet POT data
1 - 255 are available for assignment via RFC Required process as per 1 - 255 are available for assignment via RFC Required process as per
[RFC8126]. [RFC8126].
skipping to change at page 36, line 52 skipping to change at page 34, line 46
failures or anomalies, or create a false illusion of nonexistent failures or anomalies, or create a false illusion of nonexistent
ones. ones.
The Proof of Transit option (Section Section 4.3) is used for The Proof of Transit option (Section Section 4.3) is used for
verifying the path of data packets. The security considerations of verifying the path of data packets. The security considerations of
POT are further discussed in [I-D.brockners-proof-of-transit]. POT are further discussed in [I-D.brockners-proof-of-transit].
The data elements of IOAM can be used for network reconnaissance, The data elements of IOAM can be used for network reconnaissance,
allowing attackers to collect information about network paths, allowing attackers to collect information about network paths,
performance, queue states, buffer occupancy and other information. performance, queue states, buffer occupancy and other information.
Note that in case IOAM is used in "immediate export" mode, the IOAM Note that in case IOAM is used in "immediate export" mode (reference
related trace information would not be available in the customer data to be added in a future revision), the IOAM related trace information
packets, but would be exported by every IOAM node. IOAM data export would not be available in the customer data packets, but would
and securing IOAM data export is outside the scope of this document. trigger export of packet related IOAM information at every node.
IOAM data export and securing IOAM data export is outside the scope
of this document.
IOAM can be used as a means for implementing Denial of Service (DoS) IOAM can be used as a means for implementing Denial of Service (DoS)
attacks, or for amplifying them. For example, a malicious attacker attacks, or for amplifying them. For example, a malicious attacker
can add an IOAM header to packets in order to consume the resources can add an IOAM header to packets in order to consume the resources
of network devices that take part in IOAM or collectors that analyze of network devices that take part in IOAM or collectors that analyze
the IOAM data. Another example is a packet length attack, in which the IOAM data. Another example is a packet length attack, in which
an attacker pushes IOAM headers into data packets, causing these an attacker pushes IOAM headers into data packets, causing these
packets to be increased beyond the MTU size, resulting in packets to be increased beyond the MTU size, resulting in
fragmentation or in packet drops. fragmentation or in packet drops.
skipping to change at page 37, line 34 skipping to change at page 35, line 31
enables other attacks. Thus, IOAM configuration should be secured in enables other attacks. Thus, IOAM configuration should be secured in
a way that authenticates authorized users and verifies the integrity a way that authenticates authorized users and verifies the integrity
of configuration procedures. of configuration procedures.
Notably, IOAM is expected to be deployed in specific network domains, Notably, IOAM is expected to be deployed in specific network domains,
thus confining the potential attack vectors to within the network thus confining the potential attack vectors to within the network
domain. Indeed, in order to limit the scope of threats to within the domain. Indeed, in order to limit the scope of threats to within the
current network domain the network operator is expected to enforce current network domain the network operator is expected to enforce
policies that prevent IOAM traffic from leaking outside of the IOAM policies that prevent IOAM traffic from leaking outside of the IOAM
domain, and prevent IOAM data from outside the domain to be processed domain, and prevent IOAM data from outside the domain to be processed
and used within the domain. Another way to prevent the data to get and used within the domain. Note that the Immediate Export mode
leaked is using the Immediate Export mode of the trace option. (reference to be added in a future revision) can mitigate the
potential threat of IOAM data leaking through data packets.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew
Yourtchenko, Aviv Kfir, Tianran Zhou, Haoyu song and Robin Yourtchenko, Aviv Kfir, Tianran Zhou, Haoyu song and Robin
<lizhenbin@huawei.com> for the comments and advice. <lizhenbin@huawei.com> for the comments and advice.
This document leverages and builds on top of several concepts This document leverages and builds on top of several concepts
skipping to change at page 39, line 13 skipping to change at page 37, line 13
progress), May 2018. progress), May 2018.
[I-D.ietf-ntp-packet-timestamps] [I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet- Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-06 (work in progress), February 2019. timestamps-06 (work in progress), February 2019.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-11 (work in progress), March 2019. nvo3-geneve-13 (work in progress), March 2019.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work
in progress), April 2018. in progress), April 2019.
[I-D.kitamura-ipv6-record-route] [I-D.kitamura-ipv6-record-route]
Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop
Option Extension", draft-kitamura-ipv6-record-route-00 Option Extension", draft-kitamura-ipv6-record-route-00
(work in progress), November 2000. (work in progress), November 2000.
[I-D.lapukhov-dataplane-probe] [I-D.lapukhov-dataplane-probe]
Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane
probe for in-band telemetry collection", draft-lapukhov- probe for in-band telemetry collection", draft-lapukhov-
dataplane-probe-01 (work in progress), June 2016. dataplane-probe-01 (work in progress), June 2016.
skipping to change at page 41, line 10 skipping to change at page 39, line 10
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
United States United States
Email: cpignata@cisco.com Email: cpignata@cisco.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
John Leddy John Leddy
Comcast
United States United States
Email: John_Leddy@cable.comcast.com Email: john@leddy.net
Stephen Youell Stephen Youell
JP Morgan Chase JP Morgan Chase
25 Bank Street 25 Bank Street
London E14 5JP London E14 5JP
United Kingdom United Kingdom
Email: stephen.youell@jpmorgan.com Email: stephen.youell@jpmorgan.com
Tal Mizrahi Tal Mizrahi
 End of changes. 20 change blocks. 
148 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/