diff options
Diffstat (limited to 'doc/rfc/rfc9503.txt')
| -rw-r--r-- | doc/rfc/rfc9503.txt | 828 |
1 files changed, 828 insertions, 0 deletions
diff --git a/doc/rfc/rfc9503.txt b/doc/rfc/rfc9503.txt new file mode 100644 index 0000000..fa07cd6 --- /dev/null +++ b/doc/rfc/rfc9503.txt @@ -0,0 +1,828 @@ + + + + +Internet Engineering Task Force (IETF) R. Gandhi, Ed. +Request for Comments: 9503 C. Filsfils +Category: Standards Track Cisco Systems, Inc. +ISSN: 2070-1721 M. Chen + Huawei + B. Janssens + Colt + R. Foote + Nokia + October 2023 + + + Simple Two-Way Active Measurement Protocol (STAMP) Extensions for + Segment Routing Networks + +Abstract + + Segment Routing (SR) leverages the source routing paradigm. SR is + applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 + (SRv6) forwarding planes. This document specifies Simple Two-Way + Active Measurement Protocol (STAMP) extensions (as described in RFC + 8762) for SR networks, for both the SR-MPLS and SRv6 forwarding + planes, by augmenting the optional extensions defined in RFC 8972. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9503. + +Copyright Notice + + Copyright (c) 2023 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 + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions Used in This Document + 2.1. Requirements Language + 2.2. Abbreviations + 2.3. Reference Topology + 3. Destination Node Address TLV + 4. Return Path TLV + 4.1. Return Path Sub-TLVs + 4.1.1. Return Path Control Code Sub-TLV + 4.1.2. Return Address Sub-TLVs + 4.1.3. Return Path Segment List Sub-TLVs + 5. Interoperability with TWAMP Light + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Appendix A. Destination Node Address TLV Use-Case Example + Acknowledgments + Contributors + Authors' Addresses + +1. Introduction + + Segment Routing (SR) leverages the source routing paradigm for + Software-Defined Networks (SDNs). SR is applicable to both + Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding + planes [RFC8402]. SR Policies as defined in [RFC9256] are used to + steer traffic through specific, user-defined paths using a stack of + Segments. A comprehensive SR Performance Measurement (PM) toolset is + one of the essential requirements to measure network performance to + provide Service Level Agreements (SLAs). + + The Simple Two-Way Active Measurement Protocol (STAMP) provides + capabilities for the measurement of various performance metrics in IP + networks [RFC8762] without the use of a control channel to pre-signal + session parameters. [RFC8972] defines optional extensions, in the + form of TLVs, for STAMP. Note that the YANG data model defined in + [IPPM-STAMP-YANG] can be used to provision the STAMP Session-Sender + and STAMP Session-Reflector. + + STAMP test packets are transmitted along an IP path between a + Session-Sender and a Session-Reflector to measure performance delay + and packet loss along that IP path. In SR networks, it may be + desired that the same path (same set of links and nodes) between the + Session-Sender and Session-Reflector be used for the STAMP test + packets in both directions. This is achieved by using the STAMP + [RFC8762] extensions for SR-MPLS and SRv6 networks as specified in + this document by augmenting the optional extensions defined in + [RFC8972]. + +2. Conventions Used in This Document + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.2. Abbreviations + + MPLS: Multiprotocol Label Switching + + SID: Segment Identifier + + SR: Segment Routing + + SR-MPLS: Segment Routing over MPLS + + SRv6: Segment Routing over IPv6 + + SSID: STAMP Session Identifier + + STAMP: Simple Two-Way Active Measurement Protocol + +2.3. Reference Topology + + In the reference topology shown below, the STAMP Session-Sender S1 + initiates a STAMP test packet and the STAMP Session-Reflector R1 + transmits a reply STAMP test packet. The reply test packet may be + transmitted to the Session-Sender S1 on the same path (same set of + links and nodes) or a different path in the reverse direction from + the path taken towards the Session-Reflector R1. + + T1 is a transmit timestamp, and T4 is a receive timestamp added by + node S1. T2 is a receive timestamp, and T3 is a transmit timestamp + added by node R1. + + The nodes S1 and R1 may be connected via a link or an SR path + [RFC8402]. The link may be a physical interface, virtual link, Link + Aggregation Group (LAG) [IEEE802.1AX], or LAG member. The SR path + may be an SR Policy [RFC9256] on node S1 (called "head-end") with a + destination to node R1 (called "tail-end"). + + T1 T2 + / \ + +-------+ Test Packet +-------+ + | | - - - - - - - - - ->| | + | S1 |=====================| R1 | + | |<- - - - - - - - - - | | + +-------+ Reply Test Packet +-------+ + \ / + T4 T3 + + STAMP Session-Sender STAMP Session-Reflector + + Figure 1: Reference Topology + +3. Destination Node Address TLV + + The Session-Sender may need to transmit test packets to the Session- + Reflector with a Destination Address that is not a routable address + (i.e., not suitable for use as the Source Address of the reply test + packet) of the Session-Reflector. This can be facilitated, for + example, by encapsulating the STAMP packet by a tunneling protocol; + see Appendix A for an example. + + [RFC8972] defines STAMP Session-Sender and Session-Reflector test + packets that can include one or more optional TLVs. In this + document, the TLV Type (value 9 for IPv4 and IPv6) is defined for the + Destination Node Address TLV for the STAMP test packet [RFC8972]. + The formats of the Destination Node Address TLVs are shown in + Figure 2: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=9 | Length=4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=9 | Length=16 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IPv6 Address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Destination Node Address TLV Formats + + The TLV fields are defined as follows: + + STAMP TLV Flags: The STAMP TLV Flags follow the procedures described + in [RFC8972] and this document. + + Type: Type (value 9) for the IPv4 Destination Node Address TLV or + IPv6 Destination Node Address TLV. + + Length: A 2-octet field equal to the length of the Address field in + octets. The length is 4 octets for an IPv4 address and 16 octets + for an IPv6 address. + + The Destination Node Address TLV indicates an address of the intended + Session-Reflector node of the test packet. If the received + Destination Node Address is one of the addresses of the Session- + Reflector, it SHOULD be used as the Source Address in the IP header + of the reply test packet. If the Destination Node Address TLV is + sent, the SSID MUST also be sent. + + A Session-Reflector that recognizes this TLV MUST set the U flag + [RFC8972] in the reply test packet to 1 if the Session-Reflector + determined that it is not the intended destination as identified in + the Destination Node Address TLV. In this case, the Session- + Reflector does not use the received Destination Node Address as the + Source Address in the IP header of the reply test packet. Otherwise, + the Session-Reflector MUST set the U flag in the Destination Node + Address TLV in the reply test packet to 0. + +4. Return Path TLV + + For end-to-end SR paths, the Session-Reflector may need to transmit + the reply test packet on a specific Return Path. The Session-Sender + can request this in the test packet to the Session-Reflector using a + Return Path TLV. With this TLV carried in the Session-Sender test + packet, signaling and maintaining dynamic SR network state for the + STAMP sessions on the Session-Reflector are avoided. + + There are two modes defined for the behaviors on the Session- + Reflector in Section 4 of [RFC8762]: Stateless and Stateful. A + Stateful Session-Reflector requires configuration that must match all + Session-Sender parameters, including the Source Address, Destination + Address, Source UDP Port, Destination UDP Port, and possibly SSID + (assuming the SSID is configurable and not auto-generated). In this + case, a local policy can be used to direct the test packet by + creating additional states for the STAMP sessions on the Session- + Reflector. In the case of promiscuous operation, the Stateless + Session-Reflector will require an indication of how to return the + test packet on a specific path, for example, for measurement in an + ECMP environment. + + For links, the Session-Reflector may need to transmit the reply test + packet on the same incoming link in the reverse direction. The + Session-Sender can request this in the test packet to the Session- + Reflector using a Return Path TLV. + + [RFC8972] defines STAMP test packets that can include one or more + optional TLVs. In this document, the TLV Type (value 10) is defined + for the Return Path TLV that carries the Return Path for the Session- + Sender test packet. The format of the Return Path TLV is shown in + Figure 3: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=10 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Return Path Sub-TLVs | + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Return Path TLV Format + + The TLV fields are defined as follows: + + STAMP TLV Flags: The STAMP TLV Flags follow the procedures described + in [RFC8972] and this document. + + Type: Type (value 10) for the Return Path TLV. + + Length: A 2-octet field equal to the length of the Return Path Sub- + TLVs field in octets. + + Return Path Sub-TLVs: As defined in Section 4.1. + + A Session-Sender MUST NOT insert more than one Return Path TLV in the + STAMP test packet. A Session-Reflector that supports this TLV MUST + only process the first Return Path TLV in the test packet and ignore + other Return Path TLVs if present. A Session-Reflector that supports + this TLV MUST reply using the Return Path received in the Session- + Sender test packet, if no error was encountered while processing the + TLV. + + A Session-Reflector that recognizes this TLV MUST set the U flag + [RFC8972] in the reply test packet to 1 if the Session-Reflector + determined that it cannot use the Return Path in the test packet to + transmit the reply test packet. Otherwise, the Session-Reflector + MUST set the U flag in the reply test packet to 0. + +4.1. Return Path Sub-TLVs + + The Return Path TLV contains one or more Sub-TLVs to carry the + information for the requested Return Path. A Return Path Sub-TLV can + carry a Return Path Control Code, Return Path IP Address, or Return + Path Segment List. + + The STAMP Sub-TLV Flags are set using the procedures described in + [RFC8972]. + + A Return Path TLV MUST NOT contain more than one Control Code Sub- + TLV, Return Address Sub-TLV, or Return Path Segment List Sub-TLV in a + Session-Sender test packet. + + A Return Path TLV MUST NOT contain both a Control Code Sub-TLV and a + Return Address or Return Path Segment List Sub-TLV in a Session- + Sender test packet. + + A Return Path TLV MAY contain both a Return Address and a Return Path + Segment List Sub-TLV in a Session-Sender test packet. + +4.1.1. Return Path Control Code Sub-TLV + + The format of the Control Code Sub-TLV in the Return Path TLV is + shown in Figure 4. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=1 | Length=4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Code Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Format of the Control Code Sub-TLV in the Return Path TLV + + The TLV fields are defined as follows: + + Type: Type (value 1) for the Return Path Control Code. The Session- + Sender can request the Session-Reflector to transmit the reply + test packet based on the flags defined in the Control Code Flags + field. + + STAMP TLV Flags: The STAMP TLV Flags follow the procedures described + in [RFC8972] and this document. + + Length: A 2-octet field equal to the length of the Control Code + flags, which is 4 octets. + + Control Code Flags (32 bits): Reply Request Flag at bit 31 (least + significant bit) is defined as follows. + + 0x0: No Reply Requested + + 0x1: Reply Requested on the Same Link + + All other bits are reserved and must be transmitted as 0 and ignored + by the receiver. + + When Control Code flag for Reply Request is set to 0x0 in the + Session-Sender test packet, the Session-Reflector does not transmit a + reply test packet to the Session-Sender and terminates the STAMP test + packet. Only the one-way measurement is applicable in this case. + Optionally, the Session-Reflector may locally stream performance + metrics via telemetry using the information from the received test + packet. All other Return Path Sub-TLVs MUST be ignored in this case. + + When Control Code flag for Reply Request is set to 0x1 in the + Session-Sender test packet, the Session-Reflector transmits the reply + test packet over the same incoming link where the test packet is + received in the reverse direction towards the Session-Sender. The + link may be a physical interface, virtual link, LAG [IEEE802.1AX], or + LAG member. All other Return Path Sub-TLVs MUST be ignored in this + case. When using LAG member links, the STAMP extension for the + Micro-Session ID TLV defined in [STAMP-ON-LAG] can be used to + identify the link. + +4.1.2. Return Address Sub-TLVs + + The STAMP reply test packet may be transmitted to the Session-Sender + to the specified Return Address in the Return Address Sub-TLV instead + of transmitting to the Source Address in the Session-Sender test + packet. + + The formats of the IPv4 and IPv6 Return Address Sub-TLVs in the + Return Path TLV are shown in Figure 5. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=2 | Length=4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Return IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=2 | Length=16 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Return IPv6 Address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Formats of the Return Address Sub-TLVs in the Return + Path TLV + + The TLV fields are defined as follows: + + Type: Type (value 2) for the Return IPv4 Address or Return IPv6 + Address. + + The Return Address requests that the Session-Reflector reply test + packet be sent to the specified address rather than to the Source + Address in the Session-Sender test packet. + + STAMP TLV Flags: The STAMP TLV Flags follow the procedures described + in [RFC8972] and this document. + + Length: A 2-octet field equal to the length of the Return Address + field in octets. The length is 4 octets for an IPv4 address and + 16 octets for an IPv6 address. + +4.1.3. Return Path Segment List Sub-TLVs + + The format of the Segment List Sub-TLVs in the Return Path TLV is + shown in Figures 6 and 7. The Segments carried in Segment List Sub- + TLVs are described in [RFC8402]. The segment entries MUST be in + network order. + + The Session-Sender MUST only insert one Return Path Segment List Sub- + TLV in the test packet, and the Segment List MUST contain at least + one Segment. The Session-Reflector MUST only process the first + Return Path Segment List Sub-TLV in the test packet and ignore other + Return Path Segment List Sub-TLVs if present. + + The TLV fields are defined as follows: + + The Return Path Segment List Sub-TLV can be one of the following + Types: + + Type (value 3): SR-MPLS Label Stack of the Return Path + + Type (value 4): SRv6 Segment List of the Return Path + + STAMP TLV Flags: The STAMP TLV Flags follow the procedures described + in [RFC8972] and this document. + + Length: A 2-octet field equal to the length of the Segment List + field in octets. The length MUST NOT be 0. + +4.1.3.1. Return Path SR-MPLS Label Stack Sub-TLV + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=3 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Segment(1) | TC |S| TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Segment(n) (bottom of stack) | TC |S| TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Format of the SR-MPLS Label Stack Sub-TLV in the Return + Path TLV + + The SR-MPLS Label Stack contains a list of 32-bit Label Stack Entries + (LSEs) that includes a 20-bit label value, an 8-bit Time-To-Live + (TTL) value, a 3-bit Traffic Class (TC) value, and a 1-bit End-of- + Stack (S) field. The length of the Sub-TLV modulo 4 MUST be 0. + + As an example, an SR-MPLS Label Stack Sub-TLV could carry only the + Binding SID Label [PCE-BINDING-LABEL-SID] of the Return SR-MPLS + Policy. The Binding SID Label of the Return SR-MPLS Policy is local + to the Session-Reflector. The mechanism to signal the Binding SID + Label to the Session-Sender is outside the scope of this document. + + As another example, an SR-MPLS Label Stack Sub-TLV could include the + Path Segment Identifier Label of the Return SR-MPLS Policy in the + Segment List of the SR-MPLS Policy. + +4.1.3.2. Return Path SRv6 Segment List Sub-TLV + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |STAMP TLV Flags| Type=4 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Segment(1) (128-bit IPv6 Address) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Segment(n) (128-bit IPv6 Address) (bottom of stack) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Format of the SRv6 Segment List Sub-TLV in the Return + Path TLV + + The SRv6 Segment List contains a list of 128-bit IPv6 addresses + representing the SRv6 SIDs. The length of the Sub-TLV modulo 16 MUST + be 0. + + As an example, a Return Path SRv6 Segment List Sub-TLV could carry + only the SRv6 Binding SID [PCE-BINDING-LABEL-SID] of the Return SRv6 + Policy. The SRv6 Binding SID of the Return SRv6 Policy is local to + the Session-Reflector. The mechanism to signal the SRv6 Binding SID + to the Session-Sender is outside the scope of this document. + + As another example, a Return Path SRv6 Segment List Sub-TLV could + include the SRv6 Path Segment Identifier of the Return SRv6 Policy in + the Segment List of the SRv6 Policy. + +5. Interoperability with TWAMP Light + + This document does not introduce any additional considerations for + interoperability with the Two-Way Active Measurement Protocol (TWAMP) + Light than those described in Section 4.6 of [RFC8762]. + + As described in [RFC8762], there are two possible combinations for + such an interoperability use case: + + * STAMP Session-Sender with TWAMP Light Session-Reflector + + * TWAMP Light Session-Sender with STAMP Session-Reflector + + If any of the STAMP extensions defined in this document are used by + STAMP Session-Sender, the TWAMP Light Session-Reflector will view + them as the Packet Padding field. + +6. Security Considerations + + The security considerations specified in [RFC8762] and [RFC8972] also + apply to the extensions defined in this document. Specifically, the + authenticated mode and the message integrity protection using Hashed + Message Authentication Code (HMAC), as defined in Section 4.4 of + [RFC8762], also apply to the procedures described in this document. + + STAMP uses the well-known UDP port number that could become a target + of denial of service (DoS) or could be used to aid on-path attacks. + Thus, the security considerations and measures to mitigate the risk + of the attack documented in Section 6 of [RFC8545] equally apply to + the STAMP extensions in this document. + + If desired, attacks can be mitigated by performing basic validation + checks of the timestamp fields (such as T2 is later than T1 in the + reference topology in Section 2.3) in received reply test packets at + the Session-Sender. The minimal state associated with these + protocols also limit the extent of measurement disruption that can be + caused by a corrupt or invalid test packet to a single test cycle. + + The usage of STAMP extensions defined in this document is intended + for deployment in a single network administrative domain. As such, + the Session-Sender address, Session-Reflector address, and Return + Path are provisioned by the operator for the STAMP session. It is + assumed that the operator has verified the integrity of the Return + Path and identity of the far-end Session-Reflector. + + The STAMP extensions defined in this document may be used for + potential address spoofing. For example, a Session-Sender may + specify a Return Path IP Address that is different from the Session- + Sender address. The Session-Reflector MAY drop the Session-Sender + test packet when it cannot determine whether the Return Path IP + Address is local on the Session-Sender. To help the Session- + Reflector to make that determination, the Return Path IP Address may + also be provisioned by the operator, for example, in an access + control list. + +7. IANA Considerations + + IANA has allocated a value for the Destination Address TLV Type and a + value for the Return Path TLV Type from the IETF Review TLV range in + the "STAMP TLV Types" registry [RFC8972] as follows. + + +=======+=======================================+===========+ + | Value | Description | Reference | + +=======+=======================================+===========+ + | 9 | Destination Node IPv4 or IPv6 Address | RFC 9503 | + +-------+---------------------------------------+-----------+ + | 10 | Return Path | RFC 9503 | + +-------+---------------------------------------+-----------+ + + Table 1: STAMP TLV Types + + IANA has created the "Return Path Sub-TLV Types" registry. All code + points in the range 1 through 175 in this registry shall be allocated + according to the "IETF Review" procedure as specified in [RFC8126]. + Code points in the range 176 through 239 shall be allocated according + to the "First Come First Served" procedure as specified in [RFC8126]. + Remaining code points shall be allocated according to Table 2: + + +=========+=========================+ + | Range | Registration Procedures | + +=========+=========================+ + | 1-175 | IETF Review | + +---------+-------------------------+ + | 176-239 | First Come First Served | + +---------+-------------------------+ + | 240-251 | Experimental Use | + +---------+-------------------------+ + | 252-254 | Private Use | + +---------+-------------------------+ + + Table 2: Return Path Sub-TLV + Types Registry + + IANA has allocated values for the following Sub-TLV Types in the + "Return Path Sub-TLV Types" registry. + + +=======+========================================+===========+ + | Value | Description | Reference | + +=======+========================================+===========+ + | 0 | Reserved | RFC 9503 | + +-------+----------------------------------------+-----------+ + | 1 | Return Path Control Code | RFC 9503 | + +-------+----------------------------------------+-----------+ + | 2 | Return IPv4 or IPv6 Address | RFC 9503 | + +-------+----------------------------------------+-----------+ + | 3 | SR-MPLS Label Stack of the Return Path | RFC 9503 | + +-------+----------------------------------------+-----------+ + | 4 | SRv6 Segment List of the Return Path | RFC 9503 | + +-------+----------------------------------------+-----------+ + | 255 | Reserved | RFC 9503 | + +-------+----------------------------------------+-----------+ + + Table 3: Return Path Sub-TLV Types + + IANA has created the "Return Path Control Code Flags" registry for + Return Path Control Code Sub-TLVs. All code points in the bit + position 31 (counting from bit 31 as the least significant bit) + through 12 in this registry shall be allocated according to the "IETF + Review" procedure as specified in [RFC8126]. Code points in the bit + position 11 through 8 shall be allocated according to the "First Come + First Served" procedure as specified in [RFC8126]. Remaining code + points shall be allocated according to Table 4: + + +=======+=========================+ + | Range | Registration Procedures | + +=======+=========================+ + | 31-12 | IETF Review | + +-------+-------------------------+ + | 11-8 | First Come First Served | + +-------+-------------------------+ + | 7-4 | Experimental Use | + +-------+-------------------------+ + | 3-0 | Private Use | + +-------+-------------------------+ + + Table 4: Return Path Control + Code Flags Registry + + IANA has allocated a value in the "Return Path Control Code Flags" + registry as follows. + + +=======+===============+===========+ + | Value | Description | Reference | + +=======+===============+===========+ + | 31 | Reply Request | RFC 9503 | + +-------+---------------+-----------+ + + Table 5: Return Path Control Code + Flags + +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>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple + Two-Way Active Measurement Protocol", RFC 8762, + DOI 10.17487/RFC8762, March 2020, + <https://www.rfc-editor.org/info/rfc8762>. + + [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., + and E. Ruffini, "Simple Two-Way Active Measurement + Protocol Optional Extensions", RFC 8972, + DOI 10.17487/RFC8972, January 2021, + <https://www.rfc-editor.org/info/rfc8972>. + +8.2. Informative References + + [IEEE802.1AX] + IEEE, "IEEE Standard for Local and metropolitan area + networks -- Link Aggregation", IEEE Std 802.1AX-2014, + DOI 10.1109/IEEESTD.2014.7055197, December 2014, + <https://doi.org/10.1109/IEEESTD.2014.7055197>. + + [IPPM-STAMP-YANG] + Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active + Measurement Protocol (STAMP) Data Model", Work in + Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-11, + 13 March 2023, <https://datatracker.ietf.org/doc/html/ + draft-ietf-ippm-stamp-yang-11>. + + [PCE-BINDING-LABEL-SID] + Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., + and C. Li, Ed., "Carrying Binding Label/Segment Identifier + (SID) in PCE-based Networks.", Work in Progress, Internet- + Draft, draft-ietf-pce-binding-label-sid-16, 27 March 2023, + <https://datatracker.ietf.org/doc/html/draft-ietf-pce- + binding-label-sid-16>. + + [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>. + + [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, + July 2018, <https://www.rfc-editor.org/info/rfc8402>. + + [RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port + Assignments for the One-Way Active Measurement Protocol + (OWAMP) and the Two-Way Active Measurement Protocol + (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, + <https://www.rfc-editor.org/info/rfc8545>. + + [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, + A., and P. Mattes, "Segment Routing Policy Architecture", + RFC 9256, DOI 10.17487/RFC9256, July 2022, + <https://www.rfc-editor.org/info/rfc9256>. + + [STAMP-ON-LAG] + Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi, + "Simple Two-Way Active Measurement Protocol Extensions for + Performance Measurement on LAG", Work in Progress, + Internet-Draft, draft-ietf-ippm-stamp-on-lag-05, 17 + October 2023, <https://datatracker.ietf.org/doc/html/ + draft-ietf-ippm-stamp-on-lag-05>. + +Appendix A. Destination Node Address TLV Use-Case Example + + STAMP test packets can be encapsulated with 1) an SR-MPLS Label Stack + and IPv4 header containing an IPv4 Destination Address from the 127/8 + range or 2) an outer IPv6 header and a Segment Routing Header (SRH) + with an inner IPv6 header containing an IPv6 Destination Address from + the ::1/128 range. + + In an ECMP environment, the hashing function in forwarding may decide + the outgoing path using the Source Address, Destination Address, UDP + ports, IPv6 flow-label, etc. from the packet. Hence, for IPv4, for + example, different values of an IPv4 Destination Address from the + 127/8 range may be used in the IPv4 header of the STAMP test packets + to measure different ECMP paths. For IPv6, for example, different + values of flow-label may be used in the IPv6 header of the STAMP test + packets to measure different ECMP paths. + + In those cases, the STAMP test packets may reach a node that is not + the Session-Reflector for this STAMP session in an error condition, + and this unintended node may transmit a reply test packet that can + result in the reporting of invalid measurement metrics. The intended + Session-Reflector address can be carried in the Destination Node + Address TLV to help detect this error. + +Acknowledgments + + The authors would like to thank Thierry Couture for the discussions + on the use cases for Performance Measurement in Segment Routing. The + authors would also like to thank Greg Mirsky, Mike Koldychev, Gyan + Mishra, Tianran Zhou, Al Morton, Reshad Rahman, Zhenqiang Li, Frank + Brockners, Henrik Nydell, and Cheng Li for providing comments and + suggestions. Thank you to Joel Halpern for the Gen-ART review, + Martin Duke for the AD review, and Kathleen Moriarty for the Security + review. The authors would also like to thank Robert Wilton, Éric + Vyncke, Paul Wouters, John Scudder, Roman Danyliw, Lars Eggert, Erik + Kline, Warren Kumari, and Jim Guichard for the IESG review. + +Contributors + + The following person has contributed substantially to this document: + + Daniel Voyer + Bell Canada + Email: daniel.voyer@bell.ca + + +Authors' Addresses + + Rakesh Gandhi (editor) + Cisco Systems, Inc. + Canada + Email: rgandhi@cisco.com + + + Clarence Filsfils + Cisco Systems, Inc. + Email: cfilsfil@cisco.com + + + Mach(Guoyi) Chen + Huawei + Email: mach.chen@huawei.com + + + Bart Janssens + Colt + Email: Bart.Janssens@colt.net + + + Richard Foote + Nokia + Email: footer.foote@nokia.com |