5. Requirements, Security Operations, and Optional Checksum
Questa sezione conserva il testo RFC su UDPSTP, includendo One-Way IP Capacity metrics, Control and Data phases, Load and Status Feedback PDUs, KDF/HMAC authentication, optional checksum handling, IANA registries e security considerations.
Testo RFC originale
5. Requirements, Security Operations, and Optional Checksum
Security and checksum operations aren't covered by [RFC9097], which
only defines the Method of Measurement. This section adds the
operational specification related to security and the optional
checksum. Due to the additional complexities, and loss of the direct
mapping of packets to datagrams between Layer 3 and Layer 4, it is
recommended that Layer 3 fragmentation be avoided. A simplified
approach is to choose the default datagram size that is small enough
to prevent fragmentation. This version of the specification does not
support Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)
[RFC8899]. A future version could specify how to support this.
DPLPMTUD support will require a carefully adapted protocol design to
ensure interoperability. Unless IP fragmentation is expected, and is
one of the attributes being measured, the IPv4 Don't Fragment (DF)
bit SHOULD be set for all tests.
Note: When this specification is used for network debugging, it may
be useful for fragmentation to be under the control of the test
administrator.
This section specifies generic requirements, which a measurement load
rate adjustment algorithm conforming to this specification MUST
fulfill.
5.1. Load Rate Adjustment Algorithm Requirements
This document specifies an active capacity measurement method using a
load rate adjustment algorithm. The requirements listed in this
section and the currently standardized load rate adjustment
algorithms B [Y.1540Amd2] and C [TR-471] result from years of
experiments and testing by the original authors. These tests were
performed in labs, and also in the Internet, and covered a set of
different fixed, broadband, mobile, and wireless access types and
technologies in different countries and continents. Further, the
load rate adjustment algorithm requirements listed below reflect
feedback from performance measurement experts, as well as changes
resulting from the standardization of [RFC9097] (reflected also in
algorithm B [Y.1540Amd2], which updates a prior version of this
algorithm).
Load rate adjustment algorithms for capacity measurement MUST comply
with the requirements specified by this section. New standard load
rate adjustment algorithms for capacity measurement MUST be reviewed
by IETF designated experts prior to assignment of a code point in the
"Test Activation PDU Rate Adjustment Algo" registry.
The load rate adjustment algorithm for capacity measurement
requirements are as follows:
1. The measurement load rate adjustment algorithm described in this
section MUST NOT be used as a general CCA.
2. This specification MUST only be used in the application of
diagnostic and operations measurements.
3. Both Load PDU messages and Status Feedback PDU messages MUST
contain sequence numbers.
4. The nominal duration of a measurement interval at the
Destination, parameter testIntTime ("I" in [RFC9097]), MUST
default to a value of no more than 10 seconds.
5. A high-speed mode to achieve high sending rates quickly MUST
reduce the measurement load below a level for which the first
feedback interval inferred "congestion" from the measurements.
Consecutive feedback intervals that have a supra-threshold count
of sequence number anomalies and/or contain an upper delay
variation threshold exception in all of the consecutive
intervals indicate "congestion" within a test. The threshold of
consecutive feedback intervals SHALL be configurable with a
default of 3 intervals and a maximum duration to infer
congestion of 500 ms (milliseconds).
6. Congestion MUST be indicated if the Status Feedback PDUs
indicate that either sequence number anomalies were detected OR
the delay range was above the upper delay variation threshold.
The RECOMMENDED threshold values are 10 for sequence number
gaps, 30 ms for lower delay variation thresholds, and 90 ms for
upper delay variation thresholds.
7. The load rate adjustment algorithm MUST include a Load PDU
timeout and a Status PDU timeout, which both stop the test when
received PDU streams cease unexpectedly.
8. The Load PDU timeout SHALL be reset to the configured value each
time a Load PDU is received. If the Load PDU timeout expires,
the receiver SHALL be closed and no further Status PDU feedback
sent. The default Load PDU timeout MUST be no more than 1
second.
9. The Status PDU timeout SHALL be reset to the configured value
each time a feedback message is received. If the Status PDU
timeout expires, the sender SHALL be closed and no further load
packets sent. The default Status PDU timeout MUST be no more
than 1 second.
10. A network operator who is certain of the IP-Layer Capacity to be
validated MAY start with a fixed-rate test at the IP-Layer
Capacity and avoid activating the measurement load rate
adjustment algorithm (see Section 8.1 of [RFC9097]). However,
the stimulus for a diagnostic test (such as a subscriber
request) strongly implies that there is no certainty, and the
load adjustment algorithm is RECOMMENDED.
11. This specification MUST only be used in circumstances consistent
with Section 10 (Security Considerations) of [RFC9097].
12. Further measurement load rate adjustment algorithm requirements
are specified by [RFC9097].
The following measurement load rate adjustment algorithms are subject
to these requirements:
* Measurement load rate adjustment algorithm B [Y.1540Amd2].
* Measurement load rate adjustment algorithm C [TR-471].
5.2. Parameters and Definitions
Please refer to Section 4 of [RFC9097] for an overview of parameters
related to the Maximum IP-Layer Capacity Metric and Method. A set of
error codes to support debugging are provided in Section 12.3.5.
5.3. Security Mode Operations
There are two security modes of operation that perform authentication
of the client/server messaging. The two modes are:
1. A REQUIRED mode with authentication during the Control phase
(Test Setup and Test Activation exchanges). This mode may be
preferred for large-scale servers or low-end client devices where
processing power is a consideration (see Section 3).
2. An OPTIONAL mode with the additional authentication of the Status
Feedback messages during the Data phase. This mode may be
preferred for environments that desire an additional level of
message integrity verification throughout the test (see
Section 3).
The requirements discussed hereafter refer to the PDUs in Sections 6
and 7 below, primarily the authMode, keyId, authUnixTime, and
authDigest fields. 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 by other sections within this document. Each
successive mode increases security but comes with additional
performance impacts and complexity. The protocol is used with
unsubstantial payload, and it may operate on very low-end devices.
Offering the flexibility of various security operation modes allows
for accommodation of available end-device resources. In general, an
active measurement technique as the one defined by this document is
better suited to protect the privacy of those involved in
measurements [RFC7594].
A load rate adjustment method needs to satisfy the requirements
listed in Section 5.1. This is necessary also to avoid potentially
inducing congestion after there is an overload or loss (including
loss on the control path).
5.3.1. Mode 1: Required Authenticated Mode
In this mode, the client and the server SHALL be configured to use
one of a number of shared secret keys, designated via the numeric
keyId field (see Section 5.4). This key SHALL be used as input to
the KDF, as specified in Section 5.4.1, to obtain the actual keys
used by the client and server for authentication.
During the Control phase, the sender SHALL read the current system
(wall-clock) time and populate the authUnixTime field and next
calculate the 32-octet HMAC-SHA-256 hash of the entire PDU according
to Section 6 of [RFC6234] (with the authDigest and checkSum preset to
all zeroes). The authDigest field is filled by the result, then the
packet is sent to the receiver. The value in the authUnixTime field
is a 32-bit timestamp, and a 10-second tolerance window (+/- 5
seconds) SHALL be used by the receiver to distinguish a subsequent
replay of a PDU. See Table 2 of [TR-471] for a recommended timestamp
resolution.
Upon reception, the receiver SHALL validate the message PDU for
correct length, validity of authDigest, immediacy of authUnixTime,
and expected formatting (PDU-specific fields are also checked, such
as protocol version). Validation of the authDigest requires that it
be extracted from the PDU and the field, along with the checkSum
field, zeroed prior to the Hashed Message Authentication Code (HMAC)
calculation used for comparison (see Section 7.2 of [RFC9145]).
If the validation fails, the receiver SHOULD NOT continue with the
Control phase and SHOULD implement silent rejection (no further
packets sent on the address/port pairs). The exception is when the
testing hosts have been configured for troubleshooting 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 conditions identified (if any).
This process SHALL be executed for the request and response in the
Test Setup exchange, including the Null Request (Section 6) and the
Test Activation exchange (Section 7).
5.3.2. Mode 2: Optional Authenticated Mode for Data Phase
This mode incorporates Authenticated mode 1. When using the optional
authentication during the Data phase, authentication SHALL also be
applied to the Status Feedback PDU (see Section 8.2). The client
sends the Status PDU in a downstream test, and the server sends it in
an upstream test.
The Status PDU sender SHALL 1) read the current system (wall-clock)
time and populate the authUnixTime field, 2) calculate the authDigest
field of the entire Status PDU (with the authDigest and checkSum
preset to all zeroes), and 3) send the packet to the receiver. The
values of authUnixTime field and authDigest field are determined as
defined by Section 5.3.1.
Upon reception, the receiver SHALL validate the message PDU for
correct length, validity of authDigest, immediacy of authUnixTime,
and expected formatting (PDU-specific fields are also checked, such
as protocol version). Validation of the authDigest will require that
it be extracted from the PDU and the field, along with the checkSum
field, zeroed prior to the HMAC calculation used for comparison.
If the authentication validation fails, the receiver SHALL ignore the
message. If the watchdog timer expires (due to successive failed
validations), the test session will prematurely terminate (and no
further load traffic SHALL be transmitted). This is necessary also
to avoid potentially inducing congestion after there is an overload
or loss on the control path.
If this optional mode has not been selected, then the keyId,
authUnixTime, and authDigest fields of the Status PDU (see
Section 8.2) SHALL be set to all zeroes.
5.4. Key Management
Section 2 of [RFC7210] specifies a conceptual database for long-lived
cryptographic keys. The key table SHALL be used with the REQUIRED
authentication mode and the OPTIONAL authentication mode (using the
same key). For authentication, this key SHALL only be used as input
to the KDF, as specified in Section 5.4.1, to derive the actual keys
used for authentication processing. Key rotation and related
management specifics are beyond the scope of this document.
The key table SHALL have (at least) the following fields per
Section 2 of [RFC7210]:
* AdminKeyName
* LocalKeyName
* KDF
* AlgID
* Key
* SendLifetimeStart
* SendLifeTimeEnd
* AcceptLifeTimeStart
* AcceptLifeTimeEnd
The LocalKeyName SHALL be determined from the corresponding keyId
field in the PDUs that follow.
5.4.1. Key Derivation Function (KDF)
A KDF is a one-way function that provides cryptographic separation of
key material. The protocol requires a KDF to securely derive
cryptographic keys used for authentication of protocol messages. The
inclusion of a KDF ensures that keys are generated in a standardized,
cryptographically secure manner, reducing the risk of key compromise
and enabling interoperability across implementations. The benefits
of using a KDF include:
* Security: A KDF produces keys with high entropy, resistant to
brute-force and related-key attacks, ensuring robust protection
for protocol communications.
* Flexibility: The KDF allows derivation of multiple keys from a
single shared secret, supporting distinct keys for client and
server authentication.
* Standardization: By adhering to established cryptographic
standards, the KDF ensures compatibility with existing security
frameworks and facilitates implementation audits.
* Efficiency: The KDF enables efficient key generation without
requiring additional key exchange mechanisms, minimizing protocol
overhead.
The KDF algorithm SHALL be a Key Derivation Function in Counter Mode,
as specified in Section 4.1 of [NIST800-108]. This algorithm uses a
counter-based mechanism to generate key material from a shared
secret, ensuring deterministic and secure key derivation. The
Pseudorandom Function (PRF) used in the KDF SHALL be HMAC-SHA-256, as
defined in Section 6 of [RFC6234]. IANA has assigned "HMAC-SHA-256"
as a new KeyTable KDF (Section 12.2).
The KDF SHALL use the following parameters:
* Kin (key-derivation key): The shared key as identified by the
keyId field in the PDU.
* Label: The fixed string "UDPSTP" (without quotes), encoded as a
UTF-8 string, used to bind the derived keys to this specific
protocol.
* Context: The UTF-8 string representation of the authUnixTime field
received in the very first Setup Request PDU sent from the client
to the server. This ensures that the derived keys are unique to
the session and tied to the temporal context of the initial setup
exchange. The authUnixTime field serves as a nonce and is
protected from modification by the HMAC-SHA-256 hash present in
the authDigest field.
* r: The length of the binary encoding of the counter SHALL be 32
(bits).
The total derived key material SHALL be 512 bits (64 octets) in
length. The key material SHALL be structured as follows, from most
significant bit (MSB) to least significant bit (LSB):
* Client Authentication Key: 256 bits (32 octets); used for
authenticating messages sent by the client.
* Server Authentication Key: 256 bits (32 octets); used for
authenticating messages sent by the server.
This structure ensures that the derived keys are sufficient for
securing authentication operations within the protocol, while
maintaining clear separation of function and directionality.
If authentication of the initial Setup Request PDU received by the
server fails, due to an invalid authDigest field, any and all derived
keying material and keys SHALL be considered invalid.
The key material derived from the initial Setup Request PDU, either
at the client prior to transmission or at the server upon reception,
SHALL be used for all subsequent PDUs sent between them for that test
connection. As such, the KDF is only required to be executed once by
the client and server for each test connection.
Appendix A, Figure 12 provides a code snippet demonstrating
derivation of the specified keys from key material using the OpenSSL
cryptographic library, specifically the high-level Key-Based EVP_KDF
implementation (Key-Based Envelope Key Derivation Function); see
[EVP_KDF-KB] for details.
5.5. Configuration of Network Functions with Stateful Filtering
Successful interaction with a local firewall assumes the firewall is
configured to allow a host to open a bidirectional connection using
unique source and destination addresses as well as port numbers
(i.e., a 4-tuple) by sending a packet using that 4-tuple for a given
transport protocol. The client's interaction with its firewall
depends on this configuration.
The firewall at the server MUST be configured with an open pinhole
for the server IP address and standard UDP port number of the server.
All messages sent by the client to the server use this standard UDP
port number.
The server uses one ephemeral UDP port number per test connection.
Assuming that the firewall administration at the server does not
allow an open UDP ephemeral port range, then the server MUST send a
Null Request to the client from the ephemeral port number
communicated to the client in the Test Setup Response. The Null
Request 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 Null Request is not strictly necessary.
However, the availability of an open port range policy cannot be
assumed.
Network Address Translators (NATs) are expected to offer support of a
wider set of operational configurations as compared to firewalls.
Specifications covering NAT behavior, apart from the above, are out
of the scope of this document, as are combined implementations of NAT
and firewalls too.
5.6. Optional Checksum
The protocol MUST utilize the standard UDP checksum for all IPv4 and
IPv6 datagrams it sends. The purpose of this checksum is to protect
the intended recipient as well as other recipients to whom a
corrupted packet may be delivered. This provides:
* Protection of the endpoint transport state from unnecessary extra
state (e.g., Invalid state from rogue packets).
* Protection of the endpoint transport state from corruption of
internal state.
* Pre-filtering by the endpoint of erroneous data, to protect the
transport from unnecessary processing and from corruption that it
cannot itself reject.
* Pre-filtering of incorrectly addressed destination packets, before
responding to a source address.
All of the PDUs exchanged between the client and server support an
optional header checksum that covers the various fields in the UDPSTP
PDU (excluding the payload content of the Load PDU and, to be clear,
also the IP and UDP headers). The calculation is the same as the
16-bit one's complement Internet checksum used in the IPv4 packet
Header Checksum specification (see Section 3.1 of [RFC0791]). This
checksum is intended for environments where UDP data integrity may be
uncertain. This includes situations where the standard UDP checksum
is not verified upon reception or a nonstandard network API is in use
(things typically done to improve performance on low-end devices).
However, all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL
include a standard UDP checksum to protect other potential recipients
to whom a corrupted packet may be delivered. In the case of a
nonstandard network API, one option to reduce processing overhead may
be to restrict testing to only utilize a payload content of all zeros
so that the UDP checksum calculation need not include it for Load
PDUs.
If a PDU sender is populating the checkSum field, it SHALL do so as
the last step after the PDU is built in all other respects (with the
checkSum field set to zero prior to the calculation). The PDU
receiver SHALL subsequently verify the PDU checksum whenever checksum
processing has been configured and the field is populated. If PDU
checksum validation fails, the PDU SHALL be discarded.
Because of the redundancy when used in conjunction with
authentication, it is OPTIONAL for a PDU sender to utilize the UDPSTP
checkSum field. However, because authentication is not applicable to
the Load PDU, the checkSum field SHALL be utilized by the sender
whenever UDP data integrity may be uncertain (as outlined above).