doc: Add RFC documents

1 files changed, 742 insertions, 0 deletions

diff --git a/doc/rfc/rfc8762.txt b/doc/rfc/rfc8762.txt
new file mode 100644
index 0000000..7792d32
--- /dev/null
+++ b/doc/rfc/rfc8762.txt
@@ -0,0 +1,742 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         G. Mirsky
+Request for Comments: 8762                                        G. Jun
+Category: Standards Track                                      ZTE Corp.
+ISSN: 2070-1721                                                H. Nydell
+                                                       Accedian Networks
+                                                                R. Foote
+                                                                   Nokia
+                                                              March 2020
+
+
+               Simple Two-Way Active Measurement Protocol
+
+Abstract
+
+   This document describes the Simple Two-way Active Measurement
+   Protocol (STAMP), which enables the measurement of both one-way and
+   round-trip performance metrics, like delay, delay variation, and
+   packet loss.
+
+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/rfc8762.
+
+Copyright Notice
+
+   Copyright (c) 2020 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 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
+   2.  Conventions Used in This Document
+     2.1.  Terminology
+     2.2.  Requirements Language
+   3.  Operation and Management of Performance Measurement Based on
+           STAMP
+   4.  Theory of Operation
+     4.1.  UDP Port Numbers in STAMP Testing
+     4.2.  Session-Sender Behavior and Packet Format
+       4.2.1.  Session-Sender Packet Format in Unauthenticated Mode
+       4.2.2.  Session-Sender Packet Format in Authenticated Mode
+     4.3.  Session-Reflector Behavior and Packet Format
+       4.3.1.  Session-Reflector Packet Format in Unauthenticated Mode
+       4.3.2.  Session-Reflector Packet Format in Authenticated Mode
+     4.4.  Integrity Protection in STAMP
+     4.5.  Confidentiality Protection in STAMP
+     4.6.  Interoperability with TWAMP Light
+   5.  Operational Considerations
+   6.  IANA Considerations
+   7.  Security Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   Development and deployment of the Two-Way Active Measurement Protocol
+   (TWAMP) [RFC5357] and its extensions (e.g., [RFC6038], which defines
+   Symmetrical Size for TWAMP) provided invaluable experience.  Several
+   independent implementations of both TWAMP and TWAMP Light exist, have
+   been deployed, and provide important operational performance
+   measurements.
+
+   At the same time, there has been noticeable interest in using a more
+   straightforward mechanism for active performance monitoring that can
+   provide deterministic behavior and inherent separation of control
+   (vendor-specific configuration or orchestration) and test functions.
+   Recent work on "Performance Measurement from IP Edge to Customer
+   Equipment using TWAMP Light" [BBF.TR-390] by the Broadband Forum
+   demonstrates that interoperability among implementations of TWAMP
+   Light is difficult because the composition and operation of TWAMP
+   Light were not sufficiently specified in [RFC5357].  According to
+   [RFC8545], TWAMP Light includes a subset of TWAMP-Test functions.
+   Thus, to have a comprehensive tool to measure packet loss and delay
+   requires support by other applications that provide, for example,
+   control and security.
+
+   This document defines an active performance measurement test
+   protocol, Simple Two-way Active Measurement Protocol (STAMP), that
+   enables measurement of both one-way and round-trip performance
+   metrics, like delay, delay variation, and packet loss.  Support of
+   some optional TWAMP extensions, e.g., [RFC7750], is discussed in
+   [STAMP-OPTION].
+
+2.  Conventions Used in This Document
+
+2.1.  Terminology
+
+   STAMP:      Simple Two-way Active Measurement Protocol
+
+   NTP:        Network Time Protocol
+
+   PTP:        Precision Time Protocol
+
+   HMAC:       Hashed Message Authentication Code
+
+   OWAMP:      One-Way Active Measurement Protocol
+
+   TWAMP:      Two-Way Active Measurement Protocol
+
+   MBZ:        Must be Zero
+
+   PDU:        Protocol Data Unit
+
+2.2.  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.
+
+3.  Operation and Management of Performance Measurement Based on STAMP
+
+   Figure 1 presents the Simple Two-way Active Measurement Protocol
+   (STAMP) Session-Sender and Session-Reflector with a measurement
+   session.  In this document, a measurement session, also referred to
+   as a "STAMP session", is the bidirectional packet flow between one
+   specific Session-Sender and one particular Session-Reflector for a
+   time duration.  The configuration and management of the STAMP
+   Session-Sender, Session-Reflector, and sessions are outside the scope
+   of this document and can be achieved through various means.  A few
+   examples are Command Line Interface, telecommunication services'
+   Operational Support System (OSS) / Business Support System (BSS),
+   SNMP, and NETCONF/YANG-based Software-Defined Networking (SDN)
+   controllers.
+
+         o----------------------------------------------------------o
+         |                      Configuration and                   |
+         |                         Management                       |
+         o----------------------------------------------------------o
+                ||                                          ||
+                ||                                          ||
+                ||                                          ||
+     +----------------------+                +-------------------------+
+     | STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector |
+     +----------------------+                +-------------------------+
+
+                      Figure 1: STAMP Reference Model
+
+4.  Theory of Operation
+
+   The STAMP Session-Sender transmits test packets over UDP transport
+   toward the STAMP Session-Reflector.  The STAMP Session-Reflector
+   receives the Session-Sender's packet and acts according to the
+   configuration.  Two modes of the STAMP Session-Reflector characterize
+   the expected behavior and, consequently, performance metrics that can
+   be measured:
+
+   Stateless:
+      The STAMP Session-Reflector does not maintain test state and will
+      use the value in the Sequence Number field in the received packet
+      as the value for the Sequence Number field in the reflected
+      packet.  As a result, values in the Sequence Number and Session-
+      Sender Sequence Number fields are the same, and only round-trip
+      packet loss can be calculated while the reflector is operating in
+      stateless mode.
+
+   Stateful:
+      STAMP Session-Reflector maintains the test state, thus allowing
+      the Session-Sender to determine directionality of loss using the
+      combination of gaps recognized in the Session Sender Sequence
+      Number and Sequence Number fields, respectively.  As a result,
+      both near-end (forward) and far-end (backward) packet loss can be
+      computed.  That implies that the STAMP Session-Reflector MUST
+      maintain a state for each configured STAMP-Test session, thereby
+      uniquely associating STAMP-Test packets with one such session
+      instance and, thus, enabling the addition of a sequence number in
+      the test reply that is individually incremented by one on a per-
+      session basis.
+
+   STAMP supports two authentication modes: unauthenticated and
+   authenticated.  Unauthenticated STAMP-Test packets, defined in
+   Sections 4.2.1 and 4.3.1, ensure interworking between STAMP and TWAMP
+   Light, as described in Section 4.6 regarding packet formats.
+
+   By default, STAMP uses symmetrical packets, i.e., the size of the
+   packet transmitted by the Session-Reflector equals the size of the
+   packet received by the Session-Reflector.
+
+4.1.  UDP Port Numbers in STAMP Testing
+
+   A STAMP Session-Sender MUST use UDP port 862 (TWAMP-Test Receiver
+   Port) as the default destination UDP port number.  A STAMP
+   implementation of the Session-Sender MUST be able to be used as the
+   destination UDP port numbers from the User Ports (aka Registered
+   Ports) and Dynamic Ports (aka Private or Ephemeral Ports) ranges
+   defined in [RFC6335].  Before using numbers from the User Ports
+   range, the possible impact on the network MUST be carefully studied
+   and agreed on by all users of the network domain where the test has
+   been planned.
+
+   By default, an implementation of the STAMP Session-Reflector MUST
+   receive STAMP-Test packets on UDP port 862.  An implementation of the
+   Session-Reflector that supports this specification MUST be able to
+   define the port number to receive STAMP-Test packets from User Ports
+   and Dynamic Ports ranges, which are defined in [RFC6335].  STAMP
+   defines two different test packet formats: one for packets
+   transmitted by the STAMP Session-Sender and one for packets
+   transmitted by the STAMP Session-Reflector.
+
+4.2.  Session-Sender Behavior and Packet Format
+
+   A STAMP Session-Reflector supports the symmetrical size of test
+   packets, as defined in Section 3 of [RFC6038], as the default
+   behavior.  A reflected base test packet includes information from the
+   Session-Reflector and, thus, is larger.  To maintain the symmetry
+   between base STAMP packets, the base STAMP Session-Sender packet
+   includes the Must-Be-Zero (MBZ) field to match to the size of a base
+   reflected STAMP test packet.  Hence, the base STAMP Session-Sender
+   packet has a minimum size of 44 octets in unauthenticated mode (see
+   Figure 2) and 112 octets in the authenticated mode (see Figure 4).
+   Generating variable length of a test packet in STAMP is defined in
+   [STAMP-OPTION].
+
+4.2.1.  Session-Sender Packet Format in Unauthenticated Mode
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Sequence Number                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Timestamp                            |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Error Estimate        |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                                                               |
+      |                                                               |
+      |                        MBZ  (30 octets)                       |
+      |                                                               |
+      |                                                               |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Figure 2: STAMP Session-Sender Test Packet Format in
+                            Unauthenticated Mode
+
+   The fields are defined as following:
+
+   *  The Sequence Number field is four octets long.  For each new
+      session, its value starts at zero and is incremented by one with
+      each transmitted packet.
+
+   *  The Timestamp field is eight octets long.  The STAMP node MUST
+      support the Network Time Protocol (NTP) version 4 64-bit timestamp
+      format [RFC5905], the format used in [RFC5357].  The STAMP node
+      MAY support the IEEE 1588v2 Precision Time Protocol (PTP)
+      truncated 64-bit timestamp format [IEEE.1588.2008], the format
+      used in [RFC8186].  The use of the specific format, NTP or PTP, is
+      part of configuration of the Session-Sender or the particular test
+      session.
+
+   *  The Error Estimate field is two octets long with the format
+      displayed in Figure 3:
+
+               0                   1
+               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              |S|Z|   Scale   |   Multiplier  |
+              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 3: Error Estimate Format
+
+      The S, Scale, and Multiplier fields are interpreted as they are
+      defined in Section 4.1.2 of [RFC4656].  The Z field is interpreted
+      as it is defined in Section 2.3 of [RFC8186]:
+
+      0:  NTP 64-bit format of a timestamp
+
+      1:  PTPv2 truncated format of a timestamp
+
+      The default behavior of the STAMP Session-Sender and Session-
+      Reflector is to use the NTP 64-bit timestamp format (Z field value
+      of 0).  An operator using configuration/management function MAY
+      configure the STAMP Session-Sender and Session-Reflector to use
+      the PTPv2 truncated format of a timestamp (Z field value of 1).
+      Note that an implementation of a Session-Sender that supports this
+      specification MAY be configured to use the PTPv2 format of a
+      timestamp even though the Session-Reflector is configured to use
+      NTP format.
+
+   *  The MBZ field in the Session-Sender unauthenticated packet is 30
+      octets long.  It MUST be all zeroed on the transmission and MUST
+      be ignored on receipt.
+
+4.2.2.  Session-Sender Packet Format in Authenticated Mode
+
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      Sequence Number                          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                      MBZ (12 octets)                          |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Timestamp                              |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |        Error Estimate         |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+    ~                                                               ~
+    |                         MBZ (70 octets)                       |
+    ~                                                               ~
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                       HMAC (16 octets)                        |
+    |                                                               |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Figure 4: STAMP Session-Sender Test Packet Format in
+                             Authenticated Mode
+
+   The field definitions are the same as the unauthenticated mode,
+   listed in Section 4.2.1.  Also, MBZ fields are used to make the
+   packet length a multiple of 16 octets.  The value of the field MUST
+   be zeroed on transmission and MUST be ignored on receipt.  Note, that
+   both MBZ fields are used to calculate a key hashed message
+   authentication code (HMAC) [RFC2104] hash.  Also, the packet includes
+   an HMAC hash at the end of the PDU.  The detailed use of the HMAC
+   field is described in Section 4.4.
+
+4.3.  Session-Reflector Behavior and Packet Format
+
+   The Session-Reflector receives the STAMP-Test packet and verifies it.
+   If the base STAMP-Test packet is validated, the Session-Reflector
+   that supports this specification prepares and transmits the reflected
+   test packet symmetric to the packet received from the Session-Sender
+   copying the content beyond the size of the base STAMP packet (see
+   Section 4.2).
+
+4.3.1.  Session-Reflector Packet Format in Unauthenticated Mode
+
+
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Sequence Number                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Timestamp                            |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |         Error Estimate        |            MBZ                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Receive Timestamp                    |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                 Session-Sender Sequence Number                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                  Session-Sender Timestamp                     |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Session-Sender Error Estimate |            MBZ                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |Ses-Sender TTL |                      MBZ                      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 5: STAMP Session-Reflector Test Packet Format in
+                            Unauthenticated Mode
+
+   Fields are defined as the following:
+
+   *  The Sequence Number field is four octets long.  The value of the
+      Sequence Number field is set according to the mode of the STAMP
+      Session-Reflector:
+
+      -  In the stateless mode, the Session-Reflector copies the value
+         from the received STAMP-Test packet's Sequence Number field.
+
+      -  In the stateful mode, the Session-Reflector counts the
+         transmitted STAMP-Test packets.  It starts with zero and is
+         incremented by one for each subsequent packet for each test
+         session.  The Session-Reflector uses that counter to set the
+         value of the Sequence Number field.
+
+   *  The Timestamp and Receive Timestamp fields are each eight octets
+      long.  The format of these fields, NTP or PTPv2, is indicated by
+      the Z field of the Error Estimate field, as described in
+      Section 4.2.1.  Receive Timestamp is the time the test packet was
+      received by the Session-Reflector.  Timestamp is the time taken by
+      the Session-Reflector at the start of transmitting the test
+      packet.
+
+   *  The Error Estimate field has the same size and interpretation as
+      described in Section 4.2.1.  It is applicable to both Timestamp
+      and Receive Timestamp.
+
+   *  The Session-Sender Sequence Number, Session-Sender Timestamp, and
+      Session-Sender Error Estimate fields are copies of the
+      corresponding fields in the STAMP-Test packet sent by the Session-
+      Sender.
+
+   *  The Session-Sender TTL field is one octet long, and its value is
+      the copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the
+      received STAMP-Test packet.
+
+   *  The MBZ fields are used to achieve alignment of fields within the
+      packet on a four-octet boundary.  The value of each MBZ field MUST
+      be zeroed on transmission and MUST be ignored on receipt.
+
+4.3.2.  Session-Reflector Packet Format in Authenticated Mode
+
+
+      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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Sequence Number                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        MBZ (12 octets)                        |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Timestamp                            |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Error Estimate        |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                        MBZ (6 octets)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Receive Timestamp                      |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        MBZ (8 octets)                         |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Session-Sender Sequence Number                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        MBZ (12 octets)                        |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Session-Sender Timestamp                      |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Session-Sender Error Estimate |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                        MBZ (6 octets)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |Ses-Sender TTL |                                               |
+      +-+-+-+-+-+-+-+-+                                               +
+      |                                                               |
+      |                        MBZ (15 octets)                        |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        HMAC (16 octets)                       |
+      |                                                               |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 6: STAMP Session-Reflector Test Packet Format in
+                             Authenticated Mode
+
+   The field definitions are the same as the unauthenticated mode,
+   listed in Section 4.3.1.  Additionally, the MBZ field is used to make
+   the packet length a multiple of 16 octets.  The value of the field
+   MUST be zeroed on transmission and MUST be ignored on receipt.  Note
+   that the MBZ field is used to calculate the HMAC hash value.  Also,
+   the STAMP Session-Reflector test packet format in authenticated mode
+   includes the HMAC [RFC2104] hash at the end of the PDU.  The detailed
+   use of the HMAC field is in Section 4.4.
+
+4.4.  Integrity Protection in STAMP
+
+   Authenticated mode provides integrity protection to each STAMP
+   message by adding Hashed Message Authentication Code (HMAC).  STAMP
+   uses HMAC-SHA-256 truncated to 128 bits (similarly to the use of it
+   in IPsec defined in [RFC4868]); hence, the length of the HMAC field
+   is 16 octets.  In the authenticated mode, HMAC covers the first six
+   blocks (96 octets).  HMAC uses its own key, which may be unique for
+   each STAMP-Test session; key management and the mechanisms to
+   distribute the HMAC key are outside the scope of this specification.
+   One example is to use an orchestrator to configure the HMAC key based
+   on the STAMP YANG data model [STAMP-YANG].  HMAC MUST be verified as
+   early as possible to avoid using or propagating corrupted data.
+
+   Future specifications may define the use of other, more advanced
+   cryptographic algorithms, possibly providing an update to the STAMP
+   YANG data model [STAMP-YANG].
+
+4.5.  Confidentiality Protection in STAMP
+
+   If confidentiality protection for STAMP is required, a STAMP-Test
+   session MUST use a secured transport.  For example, STAMP packets
+   could be transmitted in the dedicated IPsec tunnel or share the IPsec
+   tunnel with the monitored flow.  Also, the Datagram Transport Layer
+   Security protocol would provide the desired confidentiality
+   protection.
+
+4.6.  Interoperability with TWAMP Light
+
+   One of the essential requirements to STAMP is the ability to
+   interwork with a TWAMP Light device.  Because STAMP and TWAMP use
+   different algorithms in authenticated mode (HMAC-SHA-256 versus HMAC-
+   SHA-1), interoperability is only considered for unauthenticated mode.
+   There are two possible combinations for such a use case:
+
+   *  STAMP Session-Sender with TWAMP Light Session-Reflector
+
+   *  TWAMP Light Session-Sender with STAMP Session-Reflector
+
+   In the former case, the Session-Sender might not be aware that its
+   Session-Reflector does not support STAMP.  For example, a TWAMP Light
+   Session-Reflector may not support the use of UDP port 862, as
+   specified in [RFC8545].  Thus, Section 4 permits a STAMP Session-
+   Sender to use alternative ports.  If any of STAMP extensions are
+   used, the TWAMP Light Session-Reflector will view them as the Packet
+   Padding field.
+
+   In the latter scenario, if a TWAMP Light Session-Sender does not
+   support the use of UDP port 862, the test management system MUST set
+   the STAMP Session-Reflector to use UDP port number, as permitted by
+   Section 4.  The Session-Reflector MUST be set to use the default
+   format for its timestamps, NTP.
+
+   A STAMP Session-Reflector that supports this specification will
+   transmit the base packet (Figure 5) if it receives a packet smaller
+   than the STAMP base packet.  If the packet received from the TWAMP
+   Session-Sender is larger than the STAMP base packet, the STAMP
+   Session-Reflector that supports this specification will copy the
+   content of the remainder of the received packet to transmit a
+   reflected packet of symmetrical size.
+
+5.  Operational Considerations
+
+   STAMP is intended to be used on production networks to enable the
+   operator to assess service level agreements based on packet delay,
+   delay variation, and loss.  When using STAMP over the Internet,
+   especially when STAMP-Test packets are transmitted with the
+   destination UDP port number from the User Ports range, the possible
+   impact of the STAMP-Test packets MUST be thoroughly analyzed.  The
+   use of STAMP for each case MUST be agreed by users of nodes hosting
+   the Session-Sender and Session-Reflector before starting the STAMP-
+   Test session.
+
+   Also, the use of the well-known port number as the destination UDP
+   port number in STAMP-Test packets transmitted by a Session-Sender
+   would not impede the ability to measure performance in an Equal-Cost
+   Multipath environment, and analysis in Section 5.3 of [RFC8545] fully
+   applies to STAMP.
+
+6.  IANA Considerations
+
+   This document has no IANA actions.
+
+7.  Security Considerations
+
+   [RFC5357] does not identify security considerations specific to
+   TWAMP-Test but refers to security considerations identified for OWAMP
+   in [RFC4656].  Since both OWAMP and TWAMP include control-plane and
+   data-plane components, only security considerations related to OWAMP-
+   Test discussed in Sections 6.2 and 6.3 of [RFC4656] apply to STAMP.
+
+   STAMP uses the well-known UDP port number allocated for the OWAMP-
+   Test/TWAMP-Test Receiver Port.  Thus, the security considerations and
+   measures to mitigate the risk of the attack using the registered port
+   number documented in Section 6 of [RFC8545] equally apply to STAMP.
+   Because of the control and management of a STAMP-Test being outside
+   the scope of this specification, only the more general requirement is
+   set:
+
+      To mitigate the possible attack vector, the control and management
+      of a STAMP-Test session MUST use the secured transport.
+
+      The load of the STAMP-Test packets offered to a network MUST be
+      carefully estimated, and the possible impact on the existing
+      services MUST be thoroughly analyzed before launching the test
+      session.  Section 3.1.5 of [RFC8085] provides guidance on handling
+      network load for UDP-based protocol.  While the characteristic of
+      test traffic depends on the test objective, it is highly
+      recommended to stay in the limits, as provided in [RFC8085].
+
+   Use of HMAC-SHA-256 in the authenticated mode protects the data
+   integrity of the STAMP-Test packets.
+
+8.  References
+
+8.1.  Normative References
+
+   [IEEE.1588.2008]
+              IEEE, "IEEE Standard for a Precision Clock Synchronization
+              Protocol for Networked Measurement and Control Systems",
+              IEEE Standard 1588, July 2008.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <https://www.rfc-editor.org/info/rfc2104>.
+
+   [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>.
+
+   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
+              Zekauskas, "A One-way Active Measurement Protocol
+              (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
+              <https://www.rfc-editor.org/info/rfc4656>.
+
+   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
+              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
+              RFC 5357, DOI 10.17487/RFC5357, October 2008,
+              <https://www.rfc-editor.org/info/rfc5357>.
+
+   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+              "Network Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
+              <https://www.rfc-editor.org/info/rfc5905>.
+
+   [RFC6038]  Morton, A. and L. Ciavattone, "Two-Way Active Measurement
+              Protocol (TWAMP) Reflect Octets and Symmetrical Size
+              Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
+              <https://www.rfc-editor.org/info/rfc6038>.
+
+   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+              Cheshire, "Internet Assigned Numbers Authority (IANA)
+              Procedures for the Management of the Service Name and
+              Transport Protocol Port Number Registry", BCP 165,
+              RFC 6335, DOI 10.17487/RFC6335, August 2011,
+              <https://www.rfc-editor.org/info/rfc6335>.
+
+   [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>.
+
+   [RFC8186]  Mirsky, G. and I. Meilik, "Support of the IEEE 1588
+              Timestamp Format in a Two-Way Active Measurement Protocol
+              (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
+              <https://www.rfc-editor.org/info/rfc8186>.
+
+   [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>.
+
+8.2.  Informative References
+
+   [BBF.TR-390]
+              Broadband Forum, "Performance Measurement from IP Edge to
+              Customer Equipment using TWAMP Light", TR-390 Issue 1, May
+              2017.
+
+   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
+              384, and HMAC-SHA-512 with IPsec", RFC 4868,
+              DOI 10.17487/RFC4868, May 2007,
+              <https://www.rfc-editor.org/info/rfc4868>.
+
+   [RFC7750]  Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated
+              Service Code Point and Explicit Congestion Notification
+              Monitoring in the Two-Way Active Measurement Protocol
+              (TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016,
+              <https://www.rfc-editor.org/info/rfc7750>.
+
+   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
+
+   [STAMP-OPTION]
+              Mirsky, G., Xiao, M., Nydell, H., Foote, R., Masputra, A.,
+              and E. Ruffini, "Simple Two-way Active Measurement
+              Protocol Optional Extensions", Work in Progress, Internet-
+              Draft, draft-ietf-ippm-stamp-option-tlv-03, 21 February
+              2020, <https://tools.ietf.org/html/draft-ietf-ippm-stamp-
+              option-tlv-03>.
+
+   [STAMP-YANG]
+              Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
+              Measurement Protocol (STAMP) Data Model", Work in
+              Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-05,
+              25 October 2019, <https://tools.ietf.org/html/draft-ietf-
+              ippm-stamp-yang-05>.
+
+Acknowledgments
+
+   The authors express their appreciation to Jose Ignacio Alvarez-
+   Hamelin and Brian Weis for their great insights into the security and
+   identity protection as well as the most helpful and practical
+   suggestions.  Also, our sincere thanks to David Ball, Rakesh Gandhi,
+   and Xiao Min for their thorough reviews and helpful comments.
+
+Authors' Addresses
+
+   Greg Mirsky
+   ZTE Corp.
+
+   Email: gregimirsky@gmail.com
+
+
+   Guo Jun
+   ZTE Corp.
+   68# Zijinghua Road
+   Nanjing
+   Jiangsu, 210012
+   China
+
+   Phone: +86 18105183663
+   Email: guo.jun2@zte.com.cn
+
+
+   Henrik Nydell
+   Accedian Networks
+
+   Email: hnydell@accedian.com
+
+
+   Richard Foote
+   Nokia
+
+   Email: footer.foote@nokia.com