Network Working Group L. Ciavattone Internet-Draft A. Morton Intended status: Standards Track AT&T Labs Expires: 5 April 2023 2 October 2022 Test Protocol for One-way IP Capacity Measurement draft-ietf-ippm-capacity-protocol-03 Abstract This memo addresses the problem of protocol support for measuring Network Capacity metrics in RFC 9097, where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This memo defines a simple protocol to perform the RFC 9097 (and other) measurements. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 April 2023. Copyright Notice Copyright (c) 2022 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. Ciavattone & Morton Expires 5 April 2023 [Page 1] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Parameters and Security-related Operations . . . . . . . . . 6 4.1. Parameters and Definitions . . . . . . . . . . . . . . . 6 4.2. Security Mode Operations . . . . . . . . . . . . . . . . 6 4.2.1. Mode 0: OPTIONAL unauthenticated mode . . . . . . . . 7 4.2.2. Mode 1: REQUIRED authentication mode . . . . . . . . 7 4.2.3. Mode 2: OPTIONAL authentication for Data phase . . . 8 4.2.4. Mode: 3 OPTIONAL encrypted mode . . . . . . . . . . . 8 4.3. Key Management . . . . . . . . . . . . . . . . . . . . . 8 4.4. Firewall Configuration . . . . . . . . . . . . . . . . . 9 5. Test Setup Request and Response Exchange . . . . . . . . . . 9 5.1. Client Generates Test Setup Request . . . . . . . . . . . 9 5.1.1. Authenticated Modes . . . . . . . . . . . . . . . . . 12 5.1.2. Unauthenticated Mode . . . . . . . . . . . . . . . . 12 5.1.3. Encrypted Mode . . . . . . . . . . . . . . . . . . . 12 5.2. Server Processes Test Setup Request and Generates Response . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.1. Test Setup Request Processing - Rejection . . . . . . 12 5.2.2. Test Setup Request Processing - Acceptance . . . . . 16 5.3. Setup Response Processing at the Client . . . . . . . . . 18 6. Test Activation Request and Response . . . . . . . . . . . . 19 6.1. Client Generates Test Activation Request . . . . . . . . 19 6.1.1. Authenticated Modes . . . . . . . . . . . . . . . . . 23 6.1.2. Unauthenticated Mode . . . . . . . . . . . . . . . . 23 6.1.3. Encrypted Mode . . . . . . . . . . . . . . . . . . . 23 6.2. Server Processes Test Activation Request and Generates Response . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2.1. Server Rejects or Modifies Request . . . . . . . . . 23 6.2.2. Server Accepts Request and Generates Response . . . . 25 6.3. Client Processes Test Activation Response . . . . . . . . 27 7. Test Stream Transmission and Measurement Feedback Messages . 28 7.1. Test Packet PDU and Roles . . . . . . . . . . . . . . . . 28 7.2. Status PDU . . . . . . . . . . . . . . . . . . . . . . . 31 8. Stopping the Test . . . . . . . . . . . . . . . . . . . . . . 36 9. Method of Measurement . . . . . . . . . . . . . . . . . . . . 37 9.1. Running Code . . . . . . . . . . . . . . . . . . . . . . 37 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 11.1. New System? Port Assignment . . . . . . . . . . . . . . 40 11.2. New UDPST Registry Group . . . . . . . . . . . . . . . . 40 11.2.1. PDU Identifier Registry . . . . . . . . . . . . . . 40 11.2.2. Test Setup PDU Modifier Bitmap Registry . . . . . . 41 11.2.3. Test Setup PDU Authentication Mode Registry . . . . 41 Ciavattone & Morton Expires 5 April 2023 [Page 2] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 11.2.4. Test Setup PDU Command Response Field Registry . . . 42 11.2.5. Test Activation PDU Modifier Bitmap Registry . . . . 42 11.2.6. Test Activation PDU Command Request Registry . . . . 43 11.2.7. Test Activation PDU Rate Adjustment Algo. Registry . . . . . . . . . . . . . . . . . . . . . . 43 11.2.8. Test Activation PDU Command Response Field Registry . . . . . . . . . . . . . . . . . . . . . . 43 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction The IETF's efforts to define Network and Bulk Transport Capacity have been chartered and finally progressed after over twenty years. In that time, the performance community has seen development of Informative definitions in [RFC3148] for Framework for Bulk Transport Capacity (BTC), RFC 5136 for Network Capacity and Maximum IP-layer Capacity, and the Experimental metric definitions and methods in [RFC8337], Model-Based Metrics for BTC. This memo looks at the problem of measuring Network Capacity metrics defined in [RFC9097] where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real- time. Although there are several test protocols already available for support and management of active measurements, this protocol is a major departure from their operation: 1. UDP transport, not TCP, is used for Control phase messages (e.g., Test Setup, Test Activation) and Data phase messages (e.g., Load, Status Feedback). 2. TWAMP [RFC5357] and STAMP [RFC8762] use the philosophy that one host is a Session-Reflector, sending test packets every time they receive a test packet. This protocol supports a one-way test with periodic status messages returned to the sender. These messages are also a basis for on-path Round-trip delay measurements, which are a key input to the load adjustment search algorithm. Ciavattone & Morton Expires 5 April 2023 [Page 3] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 3. OWAMP [RFC4656] supports one-way testing with results Fetch at the end of the test session. This protocol supports a one-way test and requires periodic status messages returned to the sender to support the load adjustment search algorithm. 4. The security features of OWAMP [RFC4656] and TWAMP [RFC5357] have been described as "unusual", to the point that IESG approved their use while also asking that these methods not be used again. Further, the common OWAMP [RFC4656] and TWAMP [RFC5357] approach to security is over 15 years old at this time. Note: the -00 update of this draft will be the last that describes version 8 of the protocol in the running code. Updates -01 and -02 of the draft correspond to version 9 of the protocol, which strives to allow interoperability with version 8. The -03 update of the draft incorporates new security modes of operation. 1.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. Scope, Goals, and Applicability The scope of this memo is to define a protocol to measure the Maximum IP-Layer Capacity metric and according to the standardized method. We note that aspects of this protocol and end-host configuration can lead to support of additional forms of measurement, such as application emulation enabled by creative use of the Load Adjustment algorithm. The continued goal is to harmonize the specified IP-Layer Capacity metric and method across the industry, and this protocol supports the specifications of IETF and other Standards Development Organizations. All active testing protocols currently defined by the IPPM WG are UDP-based, but this protocol specifies both control and test protocols using UDP transport. Also, a feedback message stream continues operating during testing to convey results and dynamic configurations. The primary application of the protocol described here is the same as in Section 2 of [RFC7497] where: Ciavattone & Morton Expires 5 April 2023 [Page 4] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 * The access portion of the network is the focus of this problem statement. The user typically subscribes to a service with bidirectional access partly described by rates in bits per second. 3. Protocol Overview This section gives an informative overview of the communication protocol between two test end-points (without expressing requirements: later sections provide details and requirements). One end-point takes the role of server, listening for connection requests on a well-known destination port from the other end-point, the client. The client requires configuration of a test direction parameter (upstream or downstream test, where the client performs the role of sender or receiver, respectively) as well as the hostname or IP address of the server in order to begin the setup and configuration exchanges with the server. The protocol uses UDP transport and has four types of exchanges in two phases. Exchanges 1 and 2 constitute the Control phase, while exchanges 3 and 4 constitute the Data phase. 1. Setup Request and Response Exchange: The client requests to begin a test by communicating its protocol version, intended security mode, and jumbo datagram support. The server either confirms matching configuration or rejects the connection. The server also communicates the ephemeral port for further communication when accepting the client's request. 2. Test Activation Request and Response: the client composes a request conveying parameters such as the testing direction, the duration of the test interval and test sub-intervals, and various thresholds. The server then chooses to accept, ignore or modify any of the test parameters, and communicates the set that will be used unless the client rejects the modifications. Note that the client assumes that the Test Activation exchange has opened any co-located firewalls and network address/port translators for the test connection (in response to the Request packet on the ephemeral port) and the traffic that follows. If the Test Activation Request is rejected or fails, the client assumes that the firewall will close the address/port combination after the firewall's configured idle traffic time-out. 3. Test Stream Transmission and Measurement Feedback Messages: Testing proceeds with one end-point sending load PDUs and the other end-point receiving the load PDUs and sending frequent Ciavattone & Morton Expires 5 April 2023 [Page 5] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 status messages to communicate status and transmission conditions there. The feedback messsages are input to a load-control algorithm at the server, which controls future sending rates at either end-point as needed. The choice to locate the load- control algorithm at the server, regardlesss of transmiision direction, means that the algorithm can be updated more easily at a host within the network, and at a fewer number of hosts than the number of clients. 4. Stopping the Test: When the specified test duration has been reached, the server initiates the exchange to stop the test by setting the STOP1 indication in load PDUs or status feedback messages. The client acknowledges by setting the STOP2 in further load PDUs or messages, and a graceful connection termination at each end-point follows. (Since the load PDUs and feedback messages are used, this exchange is kind of a sub- exchange of 3.) If the Test traffic stops or the communication path fails, the client assumes that the firewall will close the address/port combination after the firewall's configured idle traffic time-out. 4. Parameters and Security-related Operations 4.1. Parameters and Definitions For Parameters related to the Maximum IP-Layer Capacity Metric and Method, please see Section 4 of [RFC9097]. 4.2. Security Mode Operations There are four security modes of operation: 1. a REQUIRED mode with authentication during the Control phase: Test Setup and Test Activation exchanges. 2. An OPTIONAL mode with additional authentication during the Data phase: applicable only to the Status Feedback messages. 3. An OPTIONAL unauthenticated mode for all messages. 4. If Required for approval, a mode with encryption of the Control phase exchanges only. OR, Operation of both Control and Data phases inside an encrypted tunnel (using IPsec?, or OpenVPN in the OpenSSL library). Ciavattone & Morton Expires 5 April 2023 [Page 6] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 The requirements below refer to the PDUs in the sections that follow, primarily the authUnixTime field and the authDigest field. The roles in this section have been generalized so that the requirements for the PDU sender and receiver can be re-used and referred to elsewhere. 4.2.1. Mode 0: OPTIONAL unauthenticated mode In the OPTIONAL unauthenticated mode, all PDU senders SHALL set the authUnixTime field and the authDigest field of all packets to all zeroes. Any errors (configuration miss-match between client and server) found in the Test Setup exchange or the Test Activation exchange SHOULD result in silent rejection (no further packets sent on the address/ port pairs). The exception is when the testing hosts have been configured for trouble-shooting Control phase failures and rejection messages will aid in the process. 4.2.2. Mode 1: REQUIRED authentication mode In the REQUIRED authentication mode, the client and the server SHALL be configured to use one of a number of shared secret keys. During the Control phase, the sender SHALL read the current time and populate the authUnixTime field, then calculate the authDigest field of the request packet (with the authDigest field set to all zeroes) according to [RFC6234] and send the packet to the receiver. Upon reception, the receiver SHALL validate the message PDU for validity of the authDigest, correct length, and formatting (PDU- specific fields are also checked, such as protocol version). If the validation fails, the receiver SHOULD NOT continue with the Control phase and implement silent rejection (no further packets sent on the address/port pairs). The exception is when the testing hosts have been configured for trouble-shooting Control phase failures and rejection messages will aid in the process. If the validation succeeds, the receiver SHALL continue with the Control phase and compose a successful response or a response indicating the error condtions identified. This process SHALL be executed for each request and response in the Test Setup exchange (Section 5) and the Test Activation exchange (Section 6), amounting to four packets exchanged (plus any "dummy" packets needed). Ciavattone & Morton Expires 5 April 2023 [Page 7] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 4.2.3. Mode 2: OPTIONAL authentication for Data phase When using the OPTIONAL authentication during the Data Phase, the receiver reads the current time and populates the authUnixTime field, then calculates the authDigest field of the Status Feedback message (see Section 7.2). If the authentication validation fails, the receiver SHALL ignore the message. If or when the watchdog timer expires (due to successive failed vaildations, the test session will prematurely terminate (no further load traffic from sender). If this optional mode has not been selected, then the authUnixTime field and the authDigest field of the Status Feedback message (see Section 7.2) SHALL be populated with all zeroes. 4.2.4. Mode: 3 OPTIONAL encrypted mode DTLS could be the basis for a mode with encryption of the Control phase exchanges only. This would require the exchange of "dummy packets" to open pinholes on the ephemeral port pair at the client and server firewalls. Alternatively, operation of both Control and Data phases inside an encrypted tunnel (using IPsec? or OpenVPN in the OpenSSL Library? Still evaluating trade-offs.) would provide a measure of privacy for all protocol operations, but the cost could be inaccurate measurements and a greatly reduced scale. 4.3. Key Management Section 2 of [RFC7210] specifies a conceptual database for long-lived cryptographic keys. The database is implemented as a plaintext table, to allow text editor maintenance of the key table. The key table SHALL be used with the REQUIRED authentication mode, and the same key table and key SHALL be used with the OPTIONAL authentication mode, when used. The Key table SHALL have (at least) the following fields, referring to Section 2 of [RFC7210]: * AdminKeyName * LocalKeyName * AlgID * Key Ciavattone & Morton Expires 5 April 2023 [Page 8] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 * SendLifetimeStart * SendLifetimeEnd * AcceptLifetimeStart * AcceptLifetimeStart The LocalKeyName SHALL be determined from the corresponding protocol field in the PDUs that follow, KeyID. 4.4. Firewall Configuration Normal firewall configuration allows a host to open a bidirectional connection using unique source and destination addresses and port numbers by sending a packet using that set of 4-tuple values. The client's interaction with its firewall depends on this configuration. The firewall at the server MUST be cofigured with an open pinhole for the server IP address and well-known UDP port of the server. Assuming that the firewall administration at the server does not allow an open UDP ephemeral port range, then the server MUST send a dummy packet to the client with the ephemeral port selected by the server and communicated to the client in the Test Setup Response. The dummy packet may not reach the client: it may be discarded by the client's firewall. If the server firewall administration allows an open UDP ephemeral port range, then the dummy packet operation is not strictly necessary. However, the availability of an open port range policy cannot be assumed. 5. Test Setup Request and Response Exchange All messages defined in this section SHALL use UDP transport. The hosts SHALL calculate and include the UDP checksum, or check the UDP checksum as neccessary. 5.1. Client Generates Test Setup Request The client SHALL begin the Control phase exchanges by sending a Test Setup Request message to the server's control (well-known) port. Ciavattone & Morton Expires 5 April 2023 [Page 9] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 The client SHALL simultaneously start a test initiation timer so that if the Control phase fails to complete Test Setup and Test Activation exchanges in the allocated time, the client software SHALL exit (close the UDP socket and indicate an error message to the user). Lost messages SHALL NOT be retransmitted. Note: In version 9 and 10, the watchdog time-out is configured as: #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 2) or 3 seconds. end note. The Setup Request message PDU SHALL be organized as follows: uint16_t controlId; // Control ID = 0xACE1 uint16_t protocolVer; // Protocol version = 10 uint8_t cmdRequest; // Command request (=1 for Request) uint8_t cmdResponse; // Command response (=0 for Request) uint16_t maxBandwidth;// Required max. bit rate for the test uint16_t testPort; // Test port on server (=0 for Request) uint8_t modifierBitmap;// Modifier bitmap uint8_t authMode; // Authentication mode uint16_t testSessionId; // a pseudo-random number, see below. uint8_t keyId; // localKeyName, the numeric key identifier in the shared Key table uint8_t reserved; // reserved octet uint32_t authUnixTime;// Authentication time stamp unsigned char authDigest[AUTH_DIGEST_LENGTH] // SHA256_DIGEST_LENGTH = 32 oct The UDP PDU format layout SHALL be as follows (big-endian AB): Figure 1 Test Setup PDU with Request fields populated, others explained below Ciavattone & Morton Expires 5 April 2023 [Page 10] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | controlId | protocolVer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cmdRequest | cmdResponse | maxBandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | testPort |modifierBitmap | authMode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | testSessionId | keyId | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authUnixTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | authDigest[AUTH_DIGEST_LENGTH](256 bits) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Test Setup Message PDU Layout maxBandwith: when this field is non-zero, it is a specification of the maximum bit rate the client expects to send or receive during the requested test. The server compares this value to a configured limit. modifierBitmap: There are two bits currently assigned in this bitmap: 0x01 Do not use Jumbo Frames above sending rates of 1Gbps 0x02 Use Traditional MTU (1500 bytes with IP-header) Other bit positions are currently undefined. A new registry will be needed for modifierBitmap assignments; see the IANA Considerations Section. @@@@ testSessionId: This is a pseudo-random number. The client SHALL select an identifier (ID) for the test session which is unlikely to match values used by other clients or previous sessions of the local client (e.g., the software's process ID or ephemeral source port number). keyId: This is a localKeyName, the numeric key identifier for a key in the shared Key table. Ciavattone & Morton Expires 5 April 2023 [Page 11] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 authMode: The authMode field currently has four values assigned: 0: OPTIONAL unauthenticated mode 1: REQUIRED authentication for Control phase 2: OPTIONAL authentication for Data phase, in the Status Feedback PDU (added to Mode 1 requirements) 3: OPTIONAL encrypted mode plus, a range of values for experimentation: 60 through 63. A new registry will be needed for mode values; see the IANA Considerations Section. @@@@ 5.1.1. Authenticated Modes When operating in either of the authenticated modes (authMode 1 and authMode 2), the client SHALL follow the requirements of Section 4.2.2 (and 4.2.3 if applicable), and SHALL generate the authDigest field. The SHA-256 calculation SHALL cover the 12 preceding fields. The current Unix time SHALL be read and inserted immediately prior to the calculation (as immediately as possible). Computation of authDigest SHA-256 is specified in [RFC6234]. 5.1.2. Unauthenticated Mode When operating in Unauthenticated mode (authMode 0), the requirements of Section 4.2.1 SHALL be followed. 5.1.3. Encrypted Mode @@@@ Operation in authMode 3 is TBD 5.2. Server Processes Test Setup Request and Generates Response This Section describes the processes at the server to evaluate the Test Setup Request and determine the next steps. 5.2.1. Test Setup Request Processing - Rejection When the server receives the Setup Request it SHALL process/validate the request by checking the authDigest (if in one of the Authenticated modes), and then proceed to evaluate the other fields in the protocol header, such as the protocol version, the controlID (to validate the type of message, Setup), the maximum Bandwidth requested for the test, and the modifierBitmap for use of options such as Jumbo datagram status and traditional MTU (1500 bytes). The Ciavattone & Morton Expires 5 April 2023 [Page 12] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 value in the authUnixTime field is a 32-bit time stamp and a 5 minute tolerance window (+/- 2.5 minutes) SHALL be used (if in one of the Authenticated modes) to distinguish a subsequent replay of a Test Setup Request. Replay of most other fields would remain valid if there was no authUnixTime field in the PDU, although the testSessionId MUST be unique as well. The authUnixTime is covered by the authDigest hash, as specified earlier. If the client has selected options for: * Jumbo datagram support status (modifierBitmap), * Traditional MTU (modifierBitmap), * Authentication mode (authMode) that do not match the server configuration, the server MUST reject the Setup Request. @@@@ (Note: in protocol version 10 in the running code, the watchdog time is configured, in udpst.h, as: #define WARNING_NOTRAFFIC 1 // Receive traffic stopped warning threshold (sec) #define TIMEOUT_NOTRAFFIC (WARNING_NOTRAFFIC + 2) or 3 seconds) If the Setup Request must be rejected (due to the reasons in the Command Response, CRSP, codes listed below), and * If the authDigest is valid, a Test Setup Response SHALL be sent back to the client with a corresponding command response value indicating the reason for the rejection. * If the authDigest is invalid, then the Test Setup Request SHOULD fail silently. The exception is for operations support: server administrators using Authentication are permitted to send a Setup Response to support operations and troubleshooting. * If unauthenticated mode is selected, the Test Setup Request SHALL fail silently. * If Encrypted mode is used, only valid Setup request packets will be forwarded up the stack for processing and a Test Setup Response is REQUIRED. Ciavattone & Morton Expires 5 April 2023 [Page 13] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 The additional, non-authentication and non-encryption-related circumstances when a server SHALL not communicate the appropriate Command Response Code for an error condition (fail silently) are when: 1. the Setup Request PDU size is not correct, 2. the control ID is invalid, or 3. a directed attack has been detected, in which case the server will allow setup attempts to terminate silently. Attack detection is beyond the scope of this specification. When the server replies to the Test Setup Request message, the PDU SHALL be organized as follows: Ciavattone & Morton Expires 5 April 2023 [Page 14] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 uint16_t controlId; // Control ID = 0xACE1 uint16_t protocolVer; // Protocol version = 10 uint8_t cmdRequest; // Command request = 2 (reply) uint8_t cmdResponse; // Command response = uint16_t maxBandwidth;// Required bandwidth uint16_t testPort; // Test port on server (available port in Response) uint8_t modifierBitmap;// Modifier bitmap (see table below) uint8_t authMode; // Authentication mode uint16_t testSessionId; // client-selected pseudo-random number for the test session uint8_t keyId; // localKeyName, an index to the shared Key table uint8_t reserved; // reserved octet uint32_t authUnixTime;// Authentication time stamp unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets cmdResponse Code Field: Command Server Response Codes (CSRP) (decimal) CHSR_CRSP_NONE 0 = None (value used by client in Request) CHSR_CRSP_ACKOK 1 = Acknowledgement CHSR_CRSP_BADVER 2 = Bad Protocol Version CHSR_CRSP_BADJS 3 = Invalid Jumbo datagram option CHSR_CRSP_AUTHNC 4 = Unexpected Authentication in Setup Request CHSR_CRSP_AUTHREQ 5 = Authentication missing in Setup Request CHSR_CRSP_AUTHINV 6 = Invalid authentication method CHSR_CRSP_AUTHFAIL 7 = Authentication failure CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request CHSR_CRSP_NOMAXBW 9 = No Maximum test Bit rate specified CHSR_CRSP_CAPEXC 10 = Server Maximum Bit rate exceeded CHSR_CRSP_BADTMTU 11 = MTU option does not match Server maxBandwidth Field MSB Code Bit: CHSR_USDIR_BIT 0x8000 Bandwidth upstream direction bit, Set for Upstream modifierBitmap Code Field: Setup CHSR_JUMBO_STATUS 0x01 = set to use Jumbo datagram sizes above 1Gbps CHSR_TRADITIONAL_MTU 0x02 = set to use datagrams for 1500 byte packets Figure 3 Organization of Server Test Setup Response - Rejection There is a set of Command Response codes, beginning with: "2 = Bad Protocol Version", one of which SHOULD be communicated to indicate the cause when an error condition detected and testing cannot proceed: Ciavattone & Morton Expires 5 April 2023 [Page 15] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Decimal values 2 = Bad Protocol Version 3 = Invalid Jumbo datagram option 5 = Authentication missing in Setup Request 4 = Unexpected Authentication in Setup Request 6 = Invalid authentication method (SHA-256 not used) 7 = Authentication failure (both shared secret and time) 8 = Authentication time is invalid in Setup Request (replay attack) 9 = No Maximum test Bit rate specified 10 = Server Maximum Bit rate exceeded 11 = MTU option does not match Server Figure 4 Command Response Error Codes @@@@ Need Registries for the tables in Figure 3 and Figure 4 When indicating a Bad Protocol Version error and sending a response, the server SHALL update the protocolVer field in the Test Setup Response to indicate the current version supported. 5.2.2. Test Setup Request Processing - Acceptance If the server finds that the Setup Request matches its configuration and is otherwise acceptable, the server SHALL initiate a new connection to receive the Test Activation Request and other traffic from the client, using a new UDP socket allocated from the UDP ephemeral port range. Then, the server SHALL start a watchdog timer (to terminate the connection in case the client goes silent), and sends the Setup Response back to the client (see below for composition). When the Setup Request is accepted by the server, a Setup Response SHALL be sent back to the client with a corresponding command response value indicating 1 = Acknowledgement. Ciavattone & Morton Expires 5 April 2023 [Page 16] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 uint16_t controlId; // Control ID = 0xACE1 uint16_t protocolVer; // Protocol version = 10 uint8_t cmdRequest; // Command request = 2 (reply) uint8_t cmdResponse; // Command response = 1 (Acknowledgement) uint16_t maxBandwidth;// Required bandwidth (added in v9) uint16_t testPort; // Test port on server (available port in Response) uint8_t modifierBitmap;// Modifier bitmap (see table below) uint8_t authMode; // Authentication mode uint16_t testSessionId; // client-selected pseudo-random number for the test session uint8_t keyId; // localKeyName, an index to the shared Key table uint8_t reserved; // reserved octet uint32_t authUnixTime;// Authentication time stamp unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets uint8_t keyId; // localKeyName, a numeric identifier of a key in the shared Key table uint8_t reserved; // reserved octet uint32_t authUnixTime;// Authentication time stamp unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets Figure 5 Organization of Server Test Setup Response - Acceptance The Setup Response SHALL include the server-selected ephemeral port number (testPort field) for the new socket, and this server-selected UDP port SHALL be used for all subsequent communication. The server SHALL confirm, coerce, or populate the values of: * protocolVersion * Jumbo datagram support status (modifierBitmap), * Traditional MTU (modifierBitmap), * authMode (will be all zeroes if unauthenticated) * maxBandwidth * testPort (ephemeral port) * testSessionId * keyId * authUnixTime (will be all zeroes if unauthenticated mode) * authDigest (will be all zeroes if unauthenticated) for the client's use on the new connection in its Setup Response, and calculate authDigest in the authenticated modes. Ciavattone & Morton Expires 5 April 2023 [Page 17] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Finally, the new UDP connection associated with the new socket and port number is opened, and the server awaits communication there. To ensure that the server's local firewall will successfully deliver packets received for the new ephemeral port, the server SHALL immediately send a "dummy" packet with the corresponding 4-tuple values including the source and destination IP addresses and port numbers. The source port SHALL be the new ephemeral port. This operation allows communication to the server even when the server's local firewall prohibits open ranges of ephemeral ports. The packet is not expected to arrive successfully at the client if the client- side firewall blocks unexpected traffic. If the "dummy" packet arrives at the client, it is a confirmation that further exchanges are possible on the new port-pair (but this is not strictly necessary). The four Test Setup PDU fields shown below SHALL be used as the "dummy" packet PDU. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | controlId | protocolVer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cmdRequest | cmdResponse | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 The "dummy" packet PDU If a Test Activation Request is not subsequently received from the client on this new ephemeral port number before the watchdog timer expires, the server SHALL close the socket and deallocate the port. 5.3. Setup Response Processing at the Client When the server receives the Setup Request it SHALL validate the request by checking the authDigest if in one of the Authenticated modes, and then proceed to evaluate the protocol version, the controlID (to validate the type of message, Test Setup), cmdRequest for the role of the message (SHOULD be 2, Test Setup Response), the maxBandwidth requested for the test (if in use), and the modifierBitmap for use of options such as Jumbo datagram status and traditional MTU (1500 bytes). The value in the authUnixTime field is a 32-bit time stamp and a 5 minute tolerance window (+/- 2.5 minutes) SHALL be used (if in one of the Authenticated modes) to distinguish a subsequent replay of a Test Setup Response. Replay of most other fields would remain valid if there was no authUnixTime field in the PDU, although the testSessionId MUST be unique as well. The Ciavattone & Morton Expires 5 April 2023 [Page 18] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 authUnixTime is covered by the authDigest hash, as specified earlier. The authUnixTime field is MBZ in unauthenticated and Encrypted modes. IF the cmdResponse value indicates an error (values >1) the client SHALL display/report a relevant message to the user or management process and exit. If the client receives a Command Server Response code (CRSP) that is not equal to one of the codes defined above, then the client MUST terminate the connection and terminate operation of the current Setup Request. If the Command Server Response code (CRSP) value indicates success (cmdResponse=1) the client SHALL compose a Test Activation Request with all the test parameters it desires, such as the test direction, the test duration, etc., as described below. 6. Test Activation Request and Response This section is divided according to the sending and processing of the client, server, and again at the client. All messages defined in this section SHALL use UDP transport. The hosts SHALL calculate and include the UDP checksum, or check the UDP checksum as neccessary. 6.1. Client Generates Test Activation Request Upon a successful setup exchange, the client SHALL then compose and send the Test Activation Request to the UDP port number the server communicated in the Test Setup Response (the new ephemeral port, and not the well-known port). The client SHALL compose Test Activation Request as follows: Ciavattone & Morton Expires 5 April 2023 [Page 19] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 uint16_t controlId; // Control ID = 0xACE2 uint16_t protocolVer; // Protocol version uint8_t cmdRequest; // Command request, 1 = upstream, 2 = downstream uint8_t cmdResponse; // Command response (set to 0 by client) uint16_t lowThresh; // Low delay variation threshold uint16_t upperThresh; // Upper delay variation threshold uint16_t trialInt; // Status feedback/trial interval (ms) uint16_t testIntTime; // Test interval time (sec) (duration, T) uint8_t subIntPeriod; // Sub-interval period (sec) uint8_t ipTosByte; // IP ToS byte for testing uint16_t srIndexConf; // Configured sending rate index (see Note below) uint8_t useOwDelVar; // Use one-way delay instead of RTT uint8_t highSpeedDelta; // High-speed row adjustment delta uint16_t slowAdjThresh; // Slow rate adjustment threshold uint16_t seqErrThresh; // Sequence error threshold uint8_t ignoreOooDup; // Ignore Out-of-Order/Duplicate datagrams uint8_t modifierBitmap; // Modifier bitmap uint8_t rateAdjAlgo; // Rate adjustment algo. uint8_t reserved1; // reserved octet (alignment) MBZ 28 Octets uint16_t testSessionId; // a pseudo-random number, see below. uint8_t keyId; // localKeyName, a numeric identifier of a key in the shared Key table uint8_t reserved2; // reserved octet (alignment) uint32_t authUnixTime;// Authentication time stamp unsigned char authDigest[AUTH_DIGEST_LENGTH] // SHA256_DIGEST_LENGTH = 32 oct Control Header Test Activation Command Request Values: CHTA_CREQ_NONE 0 = No Request CHTA_CREQ_TESTACTUS 1 = Request test in Upstream direction (client to server, client takes the role of sending test packets) CHTA_CREQ_TESTACTDS 2 = Request test in Downstream direction (server to client, client takes the role of receiving test packets) modifierBitmap Code Field: Test Activation CHTA_SRIDX_ISSTART 0x01 = Set when srIndexConf IS START rate for search CHTA_RAND_PAYLOAD 0x02 = Set for RANDOMIZED UDP payload rateAdjAlgo Values: CHTA_RA_ALGO_B = 0 // 0 = Algo. B, allows Algo. expansion CHTA_RA_ALGO_MIN = CHTA_RA_ALGO_B // Limit check (with Algo B) CHTA_RA_ALGO_MAX = CHTA_RA_ALGO_C// Limit check (with Algo C) Control Header Test Activation Command Response Values: CHTA_CRSP_NONE 0 = Used by client when making a Request CHTA_CRSP_ACKOK 1 = Used by Server in affirmative Response CHTA_CRSP_BADPARAM 2 = Used by Server to indicate an error; bad parameter; reject; Figure 7 Organization of Client Test Activation Request Ciavattone & Morton Expires 5 April 2023 [Page 20] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 The content of many of the unique fields in Figure 7 is defined above, or defined in Section 4 of [RFC9097] and Appendix A of [RFC9097]. Additional definitions are given below. srIndexConf srIndexConf is the Send Rate table index of the configured fixed or starting send rate (depending on whether CHTA_SRIDX_ISSTART is cleared or set respectively). The UDP PDU format of the Test Activation Request is as follows (big- endian AB): Ciavattone & Morton Expires 5 April 2023 [Page 21] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | controlId | protocolVer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cmdRequest | cmdResponse | lowThresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | upperThresh | trialInt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | testIntTime | subIntPeriod | ipTosByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | srIndexConf | useOwDelVar |highSpeedDelta | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | slowAdjThresh | seqErrThresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ignoreOooDup |modifierBitmap | rateAdjAlgo | reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . MBZ (28 octets) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | testSessionId | keyId | reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authUnixTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | authDigest[AUTH_DIGEST_LENGTH](256 bits) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The 28 MBZ octets are replaced by the Send Rate Structure in a Test Activation Response for an upstream test. The client SHALL apply the configuration for * testPort * modifierBitmap * authMode * testSessionID Ciavattone & Morton Expires 5 April 2023 [Page 22] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 * keyID * and the remaining fields are populated based on default values or command-line options requested in the Test Setup Request and communicated/confirmed by the server in the Test Setup Response. 6.1.1. Authenticated Modes When operating in either of the authenticated modes (authMode 1 and authMode 2), the client SHALL follow the requirements of Section 4.2.2 (and 4.2.3 if applicable), and SHALL generate the authDigest field. The SHA-256 calculation SHALL cover the 24 preceding fields. The current Unix time SHALL be read and inserted immediately prior to the calculation (as immediately as possible). Computation of authDigest SHA-256 is specified in [RFC6234]. 6.1.2. Unauthenticated Mode When operating in Unauthenticated mode (authMode 0), the requirements of Section 4.2.1 SHALL be followed. 6.1.3. Encrypted Mode @@@@ Operation in authMode 3 is TBD 6.2. Server Processes Test Activation Request and Generates Response After the server receives the Test Activation Request on the new connection, it MUST choose to accept, ignore or modify any of the test parameters. 6.2.1. Server Rejects or Modifies Request When evaluating the Test Activation Request, the server MAY allow the client to specify its own fixed or starting send rate. Alternatively, the server MAY enforce a maximum limit of the fixed or starting send rate which the client can successfully request. If the client's Test Activation Request exceeds the server's configured maximum (or remaining maximum if other tests are in-progress), the server MUST either reject the request or coerce the value to the configured/remaining maximum bit rate, and communicate that maximum to the client in the Test Activation Response. The client can of course choose to end the test, as appropriate. Ciavattone & Morton Expires 5 April 2023 [Page 23] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Other parameters where the server has the OPTION to coerce the client to use values other than those in the Test Activation Request are (grouped by role): * Load Adjustment Algo: lowThresh, upperThresh, useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh, highSpeedDelta, ignoreOooDup, rateAdjAlgo. * Test duration/intervals: trialInt, testIntTime, subIntPeriod * Packet marking: ipTosByte Coersion is a step toward performing a test with the server- configured values; even though the client might prefer certain values the server gives the client an opportunity to run a test with different values than the preferred set. Note that the server has the option of completely rejecting the request and sending back an appropriate command response value: uint8_t cmdResponse; // Command response (set to 2, error) Whether this error response is sent or not depends on the Security mode of operation and the outcome of authDigest validation. If the Test Activation Request must be rejected (due to the reasons in the Command Response value=2 listed above), and * If the authDigest is valid, a Test Activation Response SHALL be sent back to the client with a corresponding command response value indicating error. * If the authDigest is invalid, then the Test Activation Request SHOULD fail silently. The exception is for operations support: server administrators using Authentication are permitted to send a Activation Response to support operations and troubleshooting. * If unauthenticated mode is selected, the Test Setup Request SHALL fail silently. * If Encrypted mode is in used, only valid Setup request packets will be forwarded up the stack for processing and a Test Setup Response is REQUIRED. Ciavattone & Morton Expires 5 April 2023 [Page 24] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 The additional, non-authentication and non-encryption-related circumstances when a server would not communicate the appropriate Command Response Code for an error condition (fail silently) are when: 1. the Test Activation Request PDU size is not correct, 2. the control ID is invalid, or 3. a directed attack has been detected, in which case the server will allow Test Activation Requests to terminate silently. Attack detection is beyond the scope of this specification. 6.2.2. Server Accepts Request and Generates Response When the server sends the Test Activation Response, it SHALL set the cmd Response field to: uint8_t cmdResponse;// Command response (set to 1, ACK) The server SHALL generate the Test Activation Response, populating all parameters in the Test Activation Response to indicate each value acceptance/changes/coersion to the client. If the client has requested an upstream test, the server SHALL: * include the transmission parameters from the first row of the sending rate table in the Sending Rate Structure (defined below), OR * use the parameters from the configured send rate index (srIndexConf) of the sending rate table for a fixed rate test, or the starting rate index for a test with Load Adjustment (this option indicated in the Test Activation modifierBitmap) when these options are present. When generating the Test Activation Response (acceptance) the server SHALL replace the 28 MBZ octets of the of the Test Activation Request with the Sending Rate Structure, which SHALL be organized as follows: Ciavattone & Morton Expires 5 April 2023 [Page 25] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 uint32_t txInterval1; // Transmit interval (us) uint32_t udpPayload1; // UDP payload (bytes) uint32_t burstSize1; // UDP burst size per interval uint32_t txInterval2; // Transmit interval (us) uint32_t udpPayload2; // UDP payload (bytes) uint32_t burstSize2; // UDP burst size per interval uint32_t udpAddon2; // UDP add-on (bytes) with +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | txInterval1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | udpPayload1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burstSize1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | txInterval2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | udpPayload2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burstSize2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | udpAdddon2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The values of the Sending Rate Structure are usually derived from the first row of the Send Rate Table, or another row corresponding to the fixed-rate or start sending rate options. If activation continues, server prepares the new connection for an upstream OR downstream test. In the case of a downstream test, the server SHALL prepare to send with either a single timer to send status PDUs at the specified interval OR dual timers to send load PDUs based on * the transmission parameters from the first row of the sending rate table in the Sending Rate Structure, OR * the transmission parameters of the configured send rate index (srIndexConf) of the sending rate table, or starting rate index (indicated in the Test Activation modifierBitmap) when these options are present. The server SHALL then send the Test Activation Response back to the client, update the watchdog timer with a new time-out value, and set a test duration timer to eventually stop the test. Ciavattone & Morton Expires 5 April 2023 [Page 26] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Once the requirements of the chosen sercurity mode have been met, the new connection is now ready for testing: 6.2.2.1. Authenticated Modes When operating in either of the authenticated modes (authMode 1 and authMode 2), the server SHALL follow the requirements of Section 4.2.2 (and 4.2.3 if applicable), and SHALL generate the authDigest field. The SHA-256 calculation SHALL cover the 24 preceding fields. The current Unix time SHALL be read and inserted immediately prior to the calculation (as immediately as possible). Computation of authDigest SHA-256 is specified in [RFC6234]. 6.2.2.2. Unauthenticated Mode When operating in Unauthenticated mode (authMode 0), the requirements of Section 4.2.1 SHALL be followed. 6.2.2.3. Encrypted Mode @@@@ Operation in authMode 3 is TBD 6.3. Client Processes Test Activation Response When the client receives the Test Activation Response, it first checks the command response value. If the client receives a Test Activation Command Response value that indicates an error, the client SHALL display/report a relevant message to the user or management process and exit. If the client receives a Test Activation Command Response value that is not equal to one of the codes defined above, then the client MUST terminate the connection and terminate operation of the current Setup Request. If the client receives a Test Activation Command Response value that indicates success (CHTA_CRSP_ACKOK) the client SHALL update its configuration to use any test parameters modified by the server. Next, the client SHALL prepare its connection for either an upstream test with dual timers set to send load PDUs (based on the starting transmission parameters sent by the server), OR a downstream test with a single timer to send status PDUs at the specified interval. Then, the client SHALL stop the test initiation timer, set a new time-out value for the watchdog timer and start the timer (to detect if the server goes quiet). Ciavattone & Morton Expires 5 April 2023 [Page 27] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 The connection is now ready for testing. 7. Test Stream Transmission and Measurement Feedback Messages This section describes the Data phase of the protocol. The roles of sender and receiver vary depending whether the direction of testing is from server to client, or the reverse. All messages defined in this section SHALL use UDP transport. The hosts SHALL calculate and include the UDP checksum, or check the received UDP checksum before further processing, as neccessary. 7.1. Test Packet PDU and Roles Testing proceeds with one end point sending load PDUs, based on transmission parameters from the sending rate table, and the other end point receiving the load PDUs and sending status messages to communicate the traffic measurements at the receiver (or to control the receiver). The watchdog timer at the receiver SHALL be reset each time a test PDU is received. See non-graceful test stop in Section 8 for handling the watchdog/NOTRAFFIC time-out expiration at each end- point. When the server is sending Load PDUs in the role of sender, it SHALL use the transmission parameters directly from the sending rate table via the index that is currently selected (which was based on the feedback in its received status messages). However, when the client is sending load PDUs in the role of sender, it SHALL use the discreet transmission parameters that were communicated by the server in its periodic status messages (and not referencing a sending rate table row). This approach allows the server to control the individual sending rates as well as the algorithm used to decide when and how to adjust the rate. The server uses a load adjustment algorithm which evaluates measurements, either its local measurements or the contents of received feedback messages. This approach is unique to this protocol; it provides the ability to search for the Maximum IP Capacity and specify specific sender behaviors that is absent from other testing tools. Although the algorithm depends on the protocol, it is not part of the protocol per se. The default algorithm (B) has three paths to its decision on the next sending rate: Ciavattone & Morton Expires 5 April 2023 [Page 28] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 1. When there are no impairments present (no sequence errors, low delay variation), resulting in sending rate increase. 2. When there are low impairments present (no sequence errors but higher levels of delay variation), so the same sending rate is retained. 3. When the impairment levels are above the thresholds set for this purpose and "congestion" is inferred, resulting in sending rate decrease. The algorithm (B) also has two modes for increasing/decreasing the sending rate: * A high-speed mode to achieve high sending rates quickly, but also back-off quickly when "congestion" is inferred from the measurements. Any two consecutive feedback intervals that have a sequence number anomaly and/or contain an upper delay variation threshold exception in both of the two consecutive intervals, count as the two consecutive feedback measurements required to declare "congestion" within a test. * A single-step mode where all rate adjustments use the minimum increase or decrease of one step in the sending rate table. The single step mode continues after the first inference of "congestion" from measured impairments. On the other hand, the test configuration MAY use a fixed sending rate requested by the client, using the field below: uint16_t srIndexConf; // Configured sending rate index The client MAY communicate the desired fixed rate in its activation request. The reasons to conduct a fixed-rate test include stable measurement at the maximum determined by the load adjustment (search) algorithm, or the desire to test at a known subscribed rate without searching. The Load PDU SHALL have the following format and field definitions: Ciavattone & Morton Expires 5 April 2023 [Page 29] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 uint16_t loadId; // Load ID (=0xBEEF for the Load PDU) uint8_t testAction; // Test action (= 0x00 normally, until test stop) uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) uint32_t lpduSeqNo; // Load PDU sequence number (starts at 1) uint16_t udpPayload; // UDP payload LENGTH (bytes) uint16_t spduSeqErr; // Status PDU sequence error count // uint32_t spduTime_sec; // Send time in last received status PDU uint32_t spduTime_nsec; // Send time in last received status PDU uint32_t lpduTime_sec; // Send time of this load PDU uint32_t lpduTime_nsec; // Send time of this load PDU Test Action Codes TEST_ACT_TEST 0 // normal TEST_ACT_STOP1 1 // normal stop at end of test: server sends in STATUS or Test PDU TEST_ACT_STOP2 2 // ACK of STOP1: sent by client in STATUS or Test PDU The Test Load UDP PDU format is as follows (big-endian AB): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loadId | testAction | rxStopped | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lpduSeqNo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | udpPayload | spduSeqErr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | spduTime_sec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | spduTime_nsec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lpduTime_sec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lpduTime_nsec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . udpPayloadContent = udpPayload - 28 octets . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . (@@@@ the remaining fields are deleted) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . The field udpPayloadContent is all zeroes, all ones, or a pseudo random binary sequence. Ciavattone & Morton Expires 5 April 2023 [Page 30] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 7.2. Status PDU The receiver SHALL send a Status PDU to the sender during a test at the configured feedback interval. The watchdog timer at the test PDU sender SHALL be reset each time a Status PDU is received. See non-graceful test stop in Section 8 for handling the watchdog/NOTRAFFIC time-out expiration at each end- point. @@@@ To Do: What protections from bit errors (checksum) or on-path attacks (something stronger) are warrented for the Status PDUs? These PDUs are a key part of the server-client control loop. Added a requirement to calculate and include/check the UDP checksum. Answer: AUTH mode 2 will detect bit errors or attmpts to replace values in the original packets. The Status Header PDU SHALL have the following format and field definitions: Ciavattone & Morton Expires 5 April 2023 [Page 31] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 // Status feedback header for UDP payload of status PDUs // uint16_t statusId; // Status ID = 0xFEED uint8_t testAction; // Test action uint8_t rxStopped; // Receive traffic stopped indicator (BOOL) uint32_t spduSeqNo; // Status PDU sequence number (starts at 1) // struct sendingRate srStruct; // Sending Rate Structure (28 octets) // uint32_t subIntSeqNo; // Sub-interval sequence number struct subIntStats sisSav; // Sub-interval Saved Stats Structure (52 octets) // uint32_t seqErrLoss; // Loss sum uint32_t seqErrOoo; // Out-of-Order sum uint32_t seqErrDup; // Duplicate sum // uint32_t clockDeltaMin; // Clock delta minimum (either RTT or 1-way delay) uint32_t delayVarMin; // Delay variation minimum uint32_t delayVarMax; // Delay variation maximum uint32_t delayVarSum; // Delay variation sum uint32_t delayVarCnt; // Delay variation count uint32_t rttMinimum; // Minimum round-trip time sampled uint32_t rttSample; // Last round-trip time sample uint8_t delayMinUpd; // Delay minimum(s) updated observed, communicated in both directions. uint8_t reserved2; // (alignment) uint16_t reserved3; // (alignment) // uint32_t tiDeltaTime; // Trial interval delta time uint32_t tiRxDatagrams; // Trial interval receive datagrams uint32_t tiRxBytes; // Trial interval receive bytes // uint32_t spduTime_sec; // Send time of this status PDU uint32_t spduTime_nsec; // Send time of this status PDU The Status feedback UDP payload PDUs format is as follows (big-endian AB): Ciavattone & Morton Expires 5 April 2023 [Page 32] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | statusId | testAction | rxStopped | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | spduSeqNo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Sending Rate Structure (28 octets) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subIntSeqNo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Sub-interval Saved Stats Structure (52 octets) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | seqErrLoss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | seqErrOoo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | seqErrDup | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | clockDeltaMin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarMin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarMax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarSum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rttMinimum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rttSample | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayMinUpd | reserved2 | reserved3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tiDeltaTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tiRxDatagrams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tiRxBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | spduTime_sec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | spduTime_nsec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Authentication Fields (40 octets) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ciavattone & Morton Expires 5 April 2023 [Page 33] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Note that the Sending Rate Structure (28 octets) is defined in the Test Activation section. Also note that the Sub-interval Saved Stats Structure (52 octets) SHALL be included (and populated as required when the server is in the receiver role) as defined below. The Sub-interval saved statistics structure for received traffic measurements SHALL be organized and formatted as follows: Ciavattone & Morton Expires 5 April 2023 [Page 34] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 uint32_t rxDatagrams; // Received datagrams uint32_t rxBytes; // Received bytes uint32_t deltaTime; // Time delta uint32_t seqErrLoss; // Loss sum uint32_t seqErrOoo; // Out-of-Order sum uint32_t seqErrDup; // Duplicate sum uint32_t delayVarMin; // Delay variation minimum uint32_t delayVarMax; // Delay variation maximum uint32_t delayVarSum; // Delay variation sum uint32_t delayVarCnt; // Delay variation count uint32_t rttMinimum; // Minimum round-trip time uint32_t rttMaximum; // Maximum round-trip time uint32_t accumTime; // Accumulated time ---------------------------------------------------------------------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rxDatagrams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rxBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | deltaTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | seqErrLoss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | seqErrOoo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | seqErrDup | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarMin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarMax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarSum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delayVarCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rttMinimum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rttMaximum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | accumTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the 52 octet saved statistics structure above has slight differences from the 40 octets that follow in the status feedback PDU, particularly the time-related fields. Ciavattone & Morton Expires 5 April 2023 [Page 35] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 The Authentication Fields appear at the end of the PDU and SHALL be organized as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | testSessionId | keyId | reserved4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authUnixTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | authDigest[AUTH_DIGEST_LENGTH](256 bits) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields and their operation are as defined previously in Sections 5 and 6 (authUnixTime and authDigest are populated when using the authentication mode 2, and MBZ when using authentication mode 1, unathenticated mode or encrypted mode). Figure Organization of authModeFields Upon receiving a valid Status Feedback PDU or expiration of the feedback interval, the server SHALL perform calculations required by the Load adjustment algorithm and adjust its sending rate, or signal that the client do so in its role as as sender. @@@@ To Do: Additional measurements, like interface byte counters from a client at a residential gateway, would change the Status Feedback PDU (and the protocol version number as a result). Interface byte counters seem useful for specific circumstances, such as when the client application has access to an interface that sees all traffic to/from a service subscriber's location. We could add a byte counter at the client, for download only. Can't trust that the client has the CPU for both. This counter is available in the Text and JSON output at end of test. 8. Stopping the Test When the test duration timer on the server expires, it SHALL set the connection test action to STOP and mark all outgoing load or status PDUs with a test action of STOP1. uint8_t testAction; // Test action (server sets STOP1) Ciavattone & Morton Expires 5 April 2023 [Page 36] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 This is simply a non-reversible state for all future messages sent from the server. When the client receives a load or status PDU with the STOP1 indication, it SHALL finalize testing, display the test results, and also mark its connection with a test action of STOP (so that any PDUs received subsequent to the STOP1 are ignored). With the test action of the client's connection set to STOP, the very next expiry of a send timer for either a load or status PDU SHALL cause the client to schedule an immediate end time to exit. The client SHALL then send all subsequent load or status PDUs with a test action of STOP2. uint8_t testAction; // Test action (client sets STOP2) as confirmation to the server, and a graceful termination of the test can begin. When the server receives the STOP2 confirmation in the load or status PDU, the server SHALL schedule an immediate end time for the connection which closes the socket and deallocates it. In a non-graceful test stop due to path failure, the watchdog/ NOTRAFFIC time-outs at each end-point will expire (sometimes at one end-point first), notifications in logs, STDOUT, and/or formateed output SHALL be made, and the test action of each end-point's connection SHALL be set to STOP. If an attacker clears STOP1 or STOP2 bits, then the configured testIntTime (test duration) value at the server and/or client will take action and stop sending its test stream. 9. Method of Measurement The architecture of the method REQUIRES two cooperating hosts operating in the roles of Src (test packet sender) and Dst (receiver), with a measured path and return path between them. The duration of a test duration, parameter I, MUST be constrained in a production network, since this is an active test method and it will likely cause congestion on the Src to Dst host path during a test. 9.1. Running Code This section is for the benefit of the Document Shepherd's form, and will be deleted prior to publication. Ciavattone & Morton Expires 5 April 2023 [Page 37] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Much of the development of the method and comparisons with existing methods conducted at IETF Hackathons and elsewhere have been based on the example udpst Linux measurement tool (which is a working reference for further development) [udpst]. The current project: * is a utility that can function as a client or server daemon * requires a successful client-initiated setup handshake between cooperating hosts and allows firewalls to control inbound unsolicited UDP which either go to a control port [expected and w/ authentication] or to ephemeral ports on the client and server that are only created as needed. * permits firewalls protecting each host to continue to do their job normally. This aspect is similar to many other test utilities available. The firewall at the server will need to open a pin- hole for the control port, the dynamic ephemeral port in response to the "dummy packet" (or open a limited range of ephemeral ports) to complete the second control exchange: Test Activtion, where the client communicates to the server on an ephemeral destination port *assigned by the server*. * has Authentication modes that require a secret key included in the SHA-256 HMAC calculation which utilizes the OpenSSL HMAC macro (https://www.openssl.org/docs/man3.0/man3/HMAC.html). * is written in C, and built with gcc (release 9.3) and its standard run-time libraries * allows configuration of most of the parameters described in Sections 4 through 8. * supports IPv4 and IPv6 address families. * supports IP-layer packet marking. 10. Security Considerations Active metrics and measurements have a long history of security considerations. The security considerations that apply to any active measurement of live paths are relevant here. See [RFC4656] and [RFC5357]. When considering privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques which are within this scope of work. Passive observations of user Ciavattone & Morton Expires 5 April 2023 [Page 38] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 traffic for measurement purposes raise many privacy issues. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) Framework [RFC7594], which covers active and passive techniques. There are some new considerations for Capacity measurement as described in this memo. 1. Cooperating client and server hosts and agreements to test the path between the hosts are REQUIRED. Hosts perform in either the server or client roles. One way to assure a cooperative agreement employs the optional Authorization mode through the use of the authDigest field and the known identity associated with the key used to create the authDigest field. Other means are also possible, such as access control lists at the server. 2. It is REQUIRED to have a user client-initiated setup handshake between cooperating hosts that allows firewalls to control inbound unsolicited UDP traffic which either goes to a control port [expected and w/authentication] or to ephemeral ports that are only created as needed. Firewalls protecting each host can both continue to do their job normally. 3. Client-server authentication and integrity protection for feedback messages conveying measurements is REQUIRED. To accomodate different host limitations and testing circumstances, different modes of operation are recommended, as described in Section 4 above. 4. Hosts MUST limit the number of simultaneous tests to avoid resource exhaustion and inaccurate results. 5. Senders MUST be rate-limited. This can be accomplished using a pre-built table defining all the offered load rates that will be supported (Section 8.1). The default and optional load-control search algorithm result in "ramp up" from the lowest rate in the table. 6. Service subscribers with limited data volumes who conduct extensive capacity testing might experience the effects of Service Provider controls on their service. Testing with the Service Provider's measurement hosts SHOULD be limited in frequency and/or overall volume of test traffic (for example, the range of test interval duration values SHOULD be limited). (@@@@ The exact specification of these features was hopefully accomplished during this protocol development. ) Ciavattone & Morton Expires 5 April 2023 [Page 39] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 One specific attack that has been recognized is an on-path attack on the Test STOP bits where the attacker would clear or set the bits. Adding the STOP bits to successive packets terminates the test prematurely, with no threat to the Internet but annoyance for the testers. Clearing the STOP bits relies on knowledge of the test duration at the client and server, where these hosts cease all traffic when the specified test duration is complete. 11. IANA Considerations This memo requests IANA to assign a "well-known" UDP port for the Test Setup exhange in the Control phase of protocol operation, and to create a new registry group for the UDPST protocol. 11.1. New System? Port Assignment Service: udpst-control Transport Protocol: UDP Assignee: IESG Contact: IETF Chair Description: UDP-based IP-Layer Capacity and performance measurement protocol Reference: This RFC, RFCYYYY. The protocol uses IP-Layer Unicast. Port Number: 11.2. New UDPST Registry Group The new registry group SHALL be named, "PERFORMANCE METRICS Group". Registration Procedure: Specification Required Reference: Experts: Performance Metrics Experts Note: TBD 11.2.1. PDU Identifier Registry The first two octets of the PDUs used in the UDPST protocol identify the role and format of PDU that follows. Ciavattone & Morton Expires 5 April 2023 [Page 40] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Identifier Value Reference Change Description Name Controller =================================================================== controlId 0xACE1 IETF Test Setup PDU controlId 0xACE2 IETF Test Activation PDU loadId 0xBEEF IETF Load PDU statusId 0xFEED IETF Status Feedback PDU 11.2.2. Test Setup PDU Modifier Bitmap Registry The Test Setup PDU layout contains a modifierBitmap field. The table below defines the initial bit assignments in the registry. Field Value Reference Change Description Name Controller =================================================================== modifierBitmap 0x01 IETF Do not use Jumbo Frames above sending rates of 1Gbps modifierBitmap 0x02 IETF Use Traditional MTU (1500 bytes with IP-header) 11.2.3. Test Setup PDU Authentication Mode Registry The Test Setup PDU layout contains an authMode field. The table below defines the four assigned decimal values in the registry. Field Value Reference Change Description Name Controller =================================================================== authMode 0 IETF OPTIONAL unauthenticated mode authMode 1 IETF REQUIRED authentication for the Control phase authMode 2 IETF OPTIONAL authentication for the Data phase, in addition to the Control phase authMode 3 IETF OPTIONAL encrypted mode authMode 60-63 IETF Range for experimentation Ciavattone & Morton Expires 5 April 2023 [Page 41] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 11.2.4. Test Setup PDU Command Response Field Registry The Test Setup PDU layout contains an cmdResponse field. The table below defines the assigned decimal values in the registry. Field Value Reference Change Description Name Controller =================================================================== cmdResponse 0 IETF None (value used by client in Request) cmdResponse 1 IETF Acknowledgement cmdResponse 2 IETF Bad Protocol Version cmdResponse 3 IETF Invalid Jumbo datagram option cmdResponse 4 IETF Unexpected Authentication in Setup Request cmdResponse 5 IETF Authentication missing in Setup Request cmdResponse 6 IETF Invalid authentication method cmdResponse 7 IETF Authentication failure cmdResponse 8 IETF Authentication time is invalid in Setup Request cmdResponse 9 IETF No Maximum test Bit rate specified cmdResponse 10 IETF Server Maximum Bit rate exceeded cmdResponse 11 IETF MTU option does not match Server 11.2.5. Test Activation PDU Modifier Bitmap Registry The Test Activation PDU layout (also) contains a modifierBitmap field. The table below defines the initial bit assignments in the registry. Field Value Reference Change Description Name Controller =================================================================== modifierBitmap 0x01 IETF Set when srIndexConf is START rate for search modifierBitmap 0x02 IETF Set for RANDOMIZED UDP payload Ciavattone & Morton Expires 5 April 2023 [Page 42] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 11.2.6. Test Activation PDU Command Request Registry The Test Activation PDU layout contains a cmdRequest field. The table below defines the assigned decimal values in the registry. Field Value Reference Change Description Name Controller =================================================================== cmdRequest 0 IETF No Request cmdRequest 1 IETF Request test in Upstream direction (client to server) cmdRequest 2 IETF Request test in Downstream direction (server to client) 11.2.7. Test Activation PDU Rate Adjustment Algo. Registry The Test Activation PDU layout contains a rateAdjAlgo field. The table below defines the assigned UTF-8 @@@@ values in the registry. Field Value Reference Change Description Name Controller =================================================================== rateAdjAlgo A IETF Not used rateAdjAlgo B IETF Rate algorithm Type B rateAdjAlgo C IETF Request test in Downstream 11.2.8. Test Activation PDU Command Response Field Registry The Test Activation PDU layout (also) contains an cmdResponse field. The table below defines the assigned decimal values in the registry. Field Value Reference Change Description Name Controller =================================================================== cmdResponse 0 IETF None (value used by client in Request) cmdResponse 1 IETF Server Acknowledgement cmdResponse 2 IETF Server indicates an error Ciavattone & Morton Expires 5 April 2023 [Page 43] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 12. Acknowledgments Thanks to Ruediger Geib, Lincoln Lavoie, Can Desem, and Greg Mirsky for reviewing this draft and providing helpful suggestions and areas for further development. Ken Kerpez and Chen Li have provided helpful reviews. Brian Weis provided an early SEC-DIR review; version 02 captures clarifications and verson 03 takes on the protocol changes the Brian suggested. 13. References 13.1. Normative References [I-D.ietf-ippm-capacity-metric-method] Morton, A., Geib, R., and L. Ciavattone, "Metrics and Methods for One-Way IP Capacity", Work in Progress, Internet-Draft, draft-ietf-ippm-capacity-metric-method-12, 9 June 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, . Ciavattone & Morton Expires 5 April 2023 [Page 44] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, DOI 10.17487/RFC7210, April 2014, . [RFC7497] Morton, A., "Rate Measurement Test Protocol Problem Statement and Requirements", RFC 7497, DOI 10.17487/RFC7497, April 2015, . [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework", RFC 8468, DOI 10.17487/RFC8468, November 2018, . [RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and Methods for One-Way IP Capacity", RFC 9097, DOI 10.17487/RFC9097, November 2021, . 13.2. Informative References [copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, "copycat: Testing Differential Treatment of New Transport Protocols in the Wild (ANRW '17)", 15 July 2017, . [LS-SG12-A] 12, I. S., "LS - Harmonization of IP Capacity and Latency Parameters: Revision of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab Evaluation Plan", May 2019, . Ciavattone & Morton Expires 5 April 2023 [Page 45] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 [LS-SG12-B] 12, I. S., "LS on harmonization of IP Capacity and Latency Parameters: Consent of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab & Field Evaluation Plans", March 2019, . [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, . [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, DOI 10.17487/RFC3148, July 2001, . [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, . [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, . [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, . [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, . [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, . [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, . Ciavattone & Morton Expires 5 April 2023 [Page 46] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 2018, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [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, . [TR-471] Morton, A., "Broadband Forum TR-471: IP Layer Capacity Metrics and Measurement", 10 July 2020, . [udpst] udpst Project Collaborators, "UDP Speed Test Open Broadband project", December 2020, . [Y.1540] Y.1540, I. R., "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2019, . [Y.Sup60] Morton, A., Rapporteur., "Recommendation Y.Sup60, (09/20) Interpreting ITU-T Y.1540 maximum IP-layer capacity measurements", 11 September 2020, . Authors' Addresses Len Ciavattone AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 United States of America Email: lencia@att.com Ciavattone & Morton Expires 5 April 2023 [Page 47] Internet-Draft Test Protocol for IP Capacity Measuremen October 2022 Al Morton AT&T Labs Chicago,, IL 60660 United States of America Phone: +1 732 420 1571 Email: acmorton@att.com Ciavattone & Morton Expires 5 April 2023 [Page 48]