rfc9378v2.txt | rfc9378.txt | |||
---|---|---|---|---|
skipping to change at line 78 ¶ | skipping to change at line 78 ¶ | |||
5.5. Geneve | 5.5. Geneve | |||
5.6. Segment Routing | 5.6. Segment Routing | |||
5.7. Segment Routing for IPv6 | 5.7. Segment Routing for IPv6 | |||
5.8. VXLAN-GPE | 5.8. VXLAN-GPE | |||
6. IOAM Data Export | 6. IOAM Data Export | |||
7. IOAM Deployment Considerations | 7. IOAM Deployment Considerations | |||
7.1. IOAM-Namespaces | 7.1. IOAM-Namespaces | |||
7.2. IOAM Layering | 7.2. IOAM Layering | |||
7.3. IOAM Trace Option-Types | 7.3. IOAM Trace Option-Types | |||
7.4. Traffic-Sets That IOAM Is Applied To | 7.4. Traffic-Sets That IOAM Is Applied To | |||
7.5. IOAM Loopback | 7.5. Loopback Flag | |||
7.6. IOAM Active Mode | 7.6. Active Flag | |||
7.7. Brown Field Deployments: IOAM-Unaware Nodes | 7.7. Brown Field Deployments: IOAM-Unaware Nodes | |||
8. IOAM Manageability | 8. IOAM Manageability | |||
9. IANA Considerations | 9. IANA Considerations | |||
10. Security Considerations | 10. Security Considerations | |||
11. Informative References | 11. Informative References | |||
Acknowledgements | Acknowledgements | |||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
skipping to change at line 238 ¶ | skipping to change at line 238 ¶ | |||
differentiated by the type of IOAM data fields that are being carried | differentiated by the type of IOAM data fields that are being carried | |||
in the packet, the data being collected, the type of nodes that | in the packet, the data being collected, the type of nodes that | |||
collect or update data, and if and how nodes export IOAM information. | collect or update data, and if and how nodes export IOAM information. | |||
Per-hop tracing: OAM information about each IOAM node a packet | Per-hop tracing: OAM information about each IOAM node a packet | |||
traverses is collected and stored within the user data packet as | traverses is collected and stored within the user data packet as | |||
the packet progresses through the IOAM-Domain. Potential uses of | the packet progresses through the IOAM-Domain. Potential uses of | |||
IOAM per-hop tracing include: | IOAM per-hop tracing include: | |||
* Understanding the different paths that different packets | * Understanding the different paths that different packets | |||
traverse between an IOAM encapsulating and an IOAM | traverse between an IOAM encapsulating node and an IOAM | |||
decapsulating node in a network that uses load balancing, such | decapsulating node in a network that uses load balancing, such | |||
as Equal Cost Multi-Path (ECMP). This information could be | as Equal Cost Multi-Path (ECMP). This information could be | |||
used to tune the algorithm for ECMP for optimized network | used to tune the algorithm for ECMP for optimized network | |||
resource usage. | resource usage. | |||
* With regard to operations and troubleshooting, understanding | * With regard to operations and troubleshooting, understanding | |||
which path a particular packet or set of packets take as well | which path a particular packet or set of packets take as well | |||
as what amount of jitter and delay different IOAM nodes in the | as what amount of jitter and delay different IOAM nodes in the | |||
path contribute to the overall delay and jitter between the | path contribute to the overall delay and jitter between the | |||
IOAM encapsulating node and the IOAM decapsulating node. | IOAM encapsulating node and the IOAM decapsulating node. | |||
skipping to change at line 673 ¶ | skipping to change at line 673 ¶ | |||
configured by the operator on the IOAM encapsulating node. The | configured by the operator on the IOAM encapsulating node. The | |||
operator has to ensure that the packet with the pre-allocated | operator has to ensure that the packet with the pre-allocated | |||
array that carries the IOAM Data-Fields does not exceed the MTU of | array that carries the IOAM Data-Fields does not exceed the MTU of | |||
any of the links in the IOAM-Domain. | any of the links in the IOAM-Domain. | |||
Incremental Trace Option: Looking up a pointer contained in the | Incremental Trace Option: Looking up a pointer contained in the | |||
packet and inserting/updating information at a flexible location | packet and inserting/updating information at a flexible location | |||
in the packet as a result of the pointer lookup is costly for some | in the packet as a result of the pointer lookup is costly for some | |||
forwarding infrastructures. Hardware-based packet-forwarding | forwarding infrastructures. Hardware-based packet-forwarding | |||
infrastructures often fall into this category. Consequently, | infrastructures often fall into this category. Consequently, | |||
hardware-based packet forwarders could choose to support the | hardware-based packet forwarders could choose to support the IOAM | |||
incremental IOAM Trace Option-Type. The incremental IOAM Trace | Incremental Trace Option-Type. The IOAM Incremental Trace Option- | |||
Option-Type eliminates the need for the IOAM transit nodes to read | Type eliminates the need for the IOAM transit nodes to read the | |||
the full array in the Trace Option-Type and allows packets to grow | full array in the Trace Option-Type and allows packets to grow to | |||
to the size of the MTU of the IOAM-Domain. IOAM transit nodes | the size of the MTU of the IOAM-Domain. IOAM transit nodes will | |||
will expand the packet and insert the IOAM-Data-Fields as long as | expand the packet and insert the IOAM-Data-Fields as long as there | |||
there is space available in the packet, i.e., as long as the size | is space available in the packet, i.e., as long as the size of the | |||
of the packet stays within the bounds of the MTU of the links in | packet stays within the bounds of the MTU of the links in the | |||
the IOAM-Domain. There is no need for the operator to configure | IOAM-Domain. There is no need for the operator to configure the | |||
the IOAM encapsulation node with the maximum number of nodes that | IOAM encapsulation node with the maximum number of nodes that IOAM | |||
IOAM information could be collected from. The operator has to | information could be collected from. The operator has to ensure | |||
ensure that the minimum MTU of the links in the IOAM-Domain is | that the minimum MTU of the links in the IOAM-Domain is known to | |||
known to all IOAM transit nodes. | all IOAM transit nodes. | |||
7.4. Traffic-Sets That IOAM Is Applied To | 7.4. Traffic-Sets That IOAM Is Applied To | |||
IOAM can be deployed on all or only on subsets of the live user | IOAM can be deployed on all or only on subsets of the live user | |||
traffic, e.g., per interface, based on an access control list or flow | traffic, e.g., per interface, based on an access control list or flow | |||
specification defining a specific set of traffic, etc. | specification defining a specific set of traffic, etc. | |||
7.5. IOAM Loopback | 7.5. Loopback Flag | |||
IOAM Loopback is used to trigger each transit device along the path | IOAM Loopback is used to trigger each transit device along the path | |||
of a packet to send a copy of the data packet back to the source. | of a packet to send a copy of the data packet back to the source. | |||
Loopback allows an IOAM encapsulating node to trace the path to a | Loopback allows an IOAM encapsulating node to trace the path to a | |||
given destination and to receive per-hop data about both the forward | given destination and to receive per-hop data about both the forward | |||
and the return path. Loopback is enabled by the encapsulating node | and the return path. Loopback is enabled by the encapsulating node | |||
setting the Loopback flag. Looped-back packets use the source | setting the Loopback flag. Looped-back packets use the source | |||
address of the original packet as a destination address and the | address of the original packet as a destination address and the | |||
address of the node that performs the Loopback operation as source | address of the node that performs the Loopback operation as source | |||
address. Nodes that loop back a packet clear the Loopback flag | address. Nodes that loop back a packet clear the Loopback flag | |||
before sending the copy back towards the source. Loopack applies to | before sending the copy back towards the source. Loopack applies to | |||
IOAM deployments where the encapsulating node is either a host or the | IOAM deployments where the encapsulating node is either a host or the | |||
start of a tunnel. For details on IOAM Loopback, please refer to | start of a tunnel. For details on IOAM Loopback, please refer to | |||
[RFC9322]. | [RFC9322]. | |||
7.6. IOAM Active Mode | 7.6. Active Flag | |||
The Active flag indicates that a packet is an active OAM packet as | The Active flag indicates that a packet is an active OAM packet as | |||
opposed to regular user data traffic. Active mode is expected to be | opposed to regular user data traffic. Active flag is expected to be | |||
used for active measurement using IOAM. For details on IOAM active | used for active measurement using IOAM. For details on the Active | |||
mode, please refer to [RFC9322]. | flag, please refer to [RFC9322]. | |||
Example use cases for IOAM Active Mode include: | Example use cases for the Active flag include: | |||
Endpoint detailed active measurement: Synthetic probe packets are | Endpoint detailed active measurement: Synthetic probe packets are | |||
sent between the source and destination. These probe packets | sent between the source and destination. These probe packets | |||
include a Trace Option-Type (i.e., either incremental or pre- | include a Trace Option-Type (i.e., either incremental or pre- | |||
allocated). Since the probe packets are sent between the | allocated). Since the probe packets are sent between the | |||
endpoints, these packets are treated as data packets by the IOAM- | endpoints, these packets are treated as data packets by the IOAM- | |||
Domain and do not require special treatment at the IOAM layer. | Domain and do not require special treatment at the IOAM layer. | |||
The source, which is also the IOAM encapsulating node, can choose | The source, which is also the IOAM encapsulating node, can choose | |||
to set the Active flag, providing an explicit indication that | to set the Active flag, providing an explicit indication that | |||
these probe packets are meant for telemetry collection. | these probe packets are meant for telemetry collection. | |||
skipping to change at line 816 ¶ | skipping to change at line 816 ¶ | |||
confidentiality of the user data is not at risk in this context, the | confidentiality of the user data is not at risk in this context, the | |||
IOAM data elements can be used for network reconnaissance, allowing | IOAM data elements can be used for network reconnaissance, allowing | |||
attackers to collect information about network paths, performance, | attackers to collect information about network paths, performance, | |||
queue states, buffer occupancy, and other information. Recon is an | queue states, buffer occupancy, and other information. Recon is an | |||
improbable security threat in an IOAM deployment that is within a | improbable security threat in an IOAM deployment that is within a | |||
confined physical domain. However, in deployments that are not | confined physical domain. However, in deployments that are not | |||
confined to a single LAN but span multiple interconnected sites (for | confined to a single LAN but span multiple interconnected sites (for | |||
example, using an overlay network), the inter-site links are expected | example, using an overlay network), the inter-site links are expected | |||
to be secured (e.g., by IPsec) in order to avoid external | to be secured (e.g., by IPsec) in order to avoid external | |||
eavesdropping and introduction of malicious or false data. Another | eavesdropping and introduction of malicious or false data. Another | |||
possible mitigation approach is to use the "Direct Exporting" mode | possible mitigation approach is to use "Direct Exporting" [RFC9326]. | |||
[RFC9326]. In this case, the IOAM-related trace information would | In this case, the IOAM-related trace information would not be | |||
not be available in the customer data packets but would trigger the | available in the customer data packets but would trigger the | |||
exporting of (secured) packet-related IOAM information at every node. | exporting of (secured) packet-related IOAM information at every node. | |||
IOAM data export and securing IOAM data export is outside the scope | IOAM data export and securing IOAM data export is outside the scope | |||
of this document. | of this document. | |||
IOAM can be used as a means for implementing or amplifying Denial-of- | IOAM can be used as a means for implementing or amplifying Denial-of- | |||
Service (DoS) attacks. For example, a malicious attacker can add an | Service (DoS) attacks. For example, a malicious attacker can add an | |||
IOAM header to packets or modify an IOAM header in en route packets | IOAM header to packets or modify an IOAM header in en route packets | |||
in order to consume the resources of network devices that take part | in order to consume the resources of network devices that take part | |||
in IOAM or collectors that analyze the IOAM data. Another example is | in IOAM or collectors that analyze the IOAM data. Another example is | |||
a packet-length attack, in which an attacker pushes headers | a packet-length attack, in which an attacker pushes headers | |||
skipping to change at line 871 ¶ | skipping to change at line 871 ¶ | |||
limited domain. Indeed, in order to limit the scope of threats | limited domain. Indeed, in order to limit the scope of threats | |||
within the current network domain, the network operator is expected | within the current network domain, the network operator is expected | |||
to enforce policies that prevent IOAM traffic from leaking outside | to enforce policies that prevent IOAM traffic from leaking outside | |||
the IOAM-Domain and prevent an attacker from introducing malicious or | the IOAM-Domain and prevent an attacker from introducing malicious or | |||
false IOAM data to be processed and used within the IOAM-Domain. | false IOAM data to be processed and used within the IOAM-Domain. | |||
IOAM data leakage could lead to privacy issues. Consider an IOAM | IOAM data leakage could lead to privacy issues. Consider an IOAM | |||
encapsulating node that is a home gateway in an operator's network. | encapsulating node that is a home gateway in an operator's network. | |||
A home gateway is often identified with an individual. Revealing | A home gateway is often identified with an individual. Revealing | |||
IOAM data, such as "IOAM node identifier" or geolocation information | IOAM data, such as "IOAM node identifier" or geolocation information | |||
outside of the limited domain, could be harmful for that user. Note | outside of the limited domain, could be harmful for that user. Note | |||
that the Direct Exporting mode [RFC9326] can mitigate the potential | that Direct Exporting [RFC9326] can mitigate the potential threat of | |||
threat of IOAM data leaking through data packets. | IOAM data leaking through data packets. | |||
11. Informative References | 11. Informative References | |||
[BIER-IOAM] | [BIER-IOAM] | |||
Min, X., Zhang, Z., Liu, Y., Nainar, N., and C. Pignataro, | Min, X., Zhang, Z., Liu, Y., Nainar, N., and C. Pignataro, | |||
"BIER Encapsulation for IOAM Data", Work in Progress, | "BIER Encapsulation for IOAM Data", Work in Progress, | |||
Internet-Draft, draft-xzlnp-bier-ioam-05, 27 January 2023, | Internet-Draft, draft-xzlnp-bier-ioam-05, 27 January 2023, | |||
<https://datatracker.ietf.org/doc/html/draft-xzlnp-bier- | <https://datatracker.ietf.org/doc/html/draft-xzlnp-bier- | |||
ioam-05>. | ioam-05>. | |||
skipping to change at line 912 ¶ | skipping to change at line 912 ¶ | |||
S., Mizrahi, T., Lapukhov, P., Gafni, B., Kfir, A., and M. | S., Mizrahi, T., Lapukhov, P., Gafni, B., Kfir, A., and M. | |||
Spiegel, "Geneve encapsulation for In-situ OAM Data", Work | Spiegel, "Geneve encapsulation for In-situ OAM Data", Work | |||
in Progress, Internet-Draft, draft-brockners-ippm-ioam- | in Progress, Internet-Draft, draft-brockners-ippm-ioam- | |||
geneve-05, 19 November 2020, | geneve-05, 19 November 2020, | |||
<https://datatracker.ietf.org/doc/html/draft-brockners- | <https://datatracker.ietf.org/doc/html/draft-brockners- | |||
ippm-ioam-geneve-05>. | ippm-ioam-geneve-05>. | |||
[IOAM-IPV6-OPTIONS] | [IOAM-IPV6-OPTIONS] | |||
Bhandari, S., Ed. and F. Brockners, Ed., "In-situ OAM IPv6 | Bhandari, S., Ed. and F. Brockners, Ed., "In-situ OAM IPv6 | |||
Options", Work in Progress, Internet-Draft, draft-ietf- | Options", Work in Progress, Internet-Draft, draft-ietf- | |||
ippm-ioam-ipv6-options-09, 11 October 2022, | ippm-ioam-ipv6-options-10, 28 February 2023, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm- | <https://datatracker.ietf.org/doc/html/draft-ietf-ippm- | |||
ioam-ipv6-options-09>. | ioam-ipv6-options-10>. | |||
[IOAM-NSH] Brockners, F., Ed. and S. Bhandari, Ed., "Network Service | [IOAM-NSH] Brockners, F., Ed. and S. Bhandari, Ed., "Network Service | |||
Header (NSH) Encapsulation for In-situ OAM (IOAM) Data", | Header (NSH) Encapsulation for In-situ OAM (IOAM) Data", | |||
Work in Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh- | Work in Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh- | |||
11, 30 September 2022, | 11, 30 September 2022, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc- | <https://datatracker.ietf.org/doc/html/draft-ietf-sfc- | |||
ioam-nsh-11>. | ioam-nsh-11>. | |||
[IOAM-PROFILES] | [IOAM-PROFILES] | |||
Mizrahi, T., Brockners, F., Bhandari, S., Ed., | Mizrahi, T., Brockners, F., Bhandari, S., Ed., | |||
skipping to change at line 969 ¶ | skipping to change at line 969 ¶ | |||
Zhou, T., Ed., Guichard, J., Brockners, F., and S. | Zhou, T., Ed., Guichard, J., Brockners, F., and S. | |||
Raghavan, "A YANG Data Model for In-Situ OAM", Work in | Raghavan, "A YANG Data Model for In-Situ OAM", Work in | |||
Progress, Internet-Draft, draft-ietf-ippm-ioam-yang-06, 27 | Progress, Internet-Draft, draft-ietf-ippm-ioam-yang-06, 27 | |||
February 2023, <https://datatracker.ietf.org/doc/html/ | February 2023, <https://datatracker.ietf.org/doc/html/ | |||
draft-ietf-ippm-ioam-yang-06>. | draft-ietf-ippm-ioam-yang-06>. | |||
[MPLS-IOAM] | [MPLS-IOAM] | |||
Gandhi, R., Ed., Brockners, F., Wen, B., Decraene, B., and | Gandhi, R., Ed., Brockners, F., Wen, B., Decraene, B., and | |||
H. Song, "MPLS Data Plane Encapsulation for In Situ OAM | H. Song, "MPLS Data Plane Encapsulation for In Situ OAM | |||
Data", Work in Progress, Internet-Draft, draft-gandhi- | Data", Work in Progress, Internet-Draft, draft-gandhi- | |||
mpls-ioam-09, 10 January 2023, | mpls-ioam-10, 10 March 2023, | |||
<https://datatracker.ietf.org/doc/html/draft-gandhi-mpls- | <https://datatracker.ietf.org/doc/html/draft-gandhi-mpls- | |||
ioam-09>. | ioam-10>. | |||
[PROOF-OF-TRANSIT] | [PROOF-OF-TRANSIT] | |||
Brockners, F., Ed., Bhandari, S., Ed., Mizrahi, T., Ed., | Brockners, F., Ed., Bhandari, S., Ed., Mizrahi, T., Ed., | |||
Dara, S., and S. Youell, "Proof of Transit", Work in | Dara, S., and S. Youell, "Proof of Transit", Work in | |||
Progress, Internet-Draft, draft-ietf-sfc-proof-of-transit- | Progress, Internet-Draft, draft-ietf-sfc-proof-of-transit- | |||
08, 31 October 2020, | 08, 31 October 2020, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc- | <https://datatracker.ietf.org/doc/html/draft-ietf-sfc- | |||
proof-of-transit-08>. | proof-of-transit-08>. | |||
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. | [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. | |||
End of changes. 13 change blocks. | ||||
31 lines changed or deleted | 31 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |