A Two-Way Active Measurement Protocol (TWAMP)
updated by
- rfc-5618 — Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)
- rfc-5938 — Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)
- rfc-6038 — Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features
- rfc-7717 — IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
- rfc-7750 — Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)
- rfc-8545 — Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)
Extracted elements (30)
Each TWAMP-Test packet in encrypted mode is encrypted as a separate stream with IV=0 and a single chaining operation; chaining does not span multiple packets. This design ensures that lost, duplicated, or reordered packets do not cause problems with deciphering any packet in a session.
In authenticated mode, only the sequence number in the first block is encrypted and subsequent timestamps and sequence numbers are sent in clear text. This allows the timestamp to be fetched after partial encryption, reducing the interval between timestamp capture and packet transmission, thereby improving timestamp accuracy.
TWAMP does not use the Fetch-Session command because two-way measurement methods communicate packet-level data (sequence number, timestamp, TTL) in the reflected test packets themselves, eliminating the need to retrieve data from the Session-Reflector separately.
TWAMP is derived from OWAMP (RFC 4656) and reuses its connection setup, integrity protection, accept field values, and test packet formats. Key differences are: Request-TW-Session replaces Request-Session; Fetch-Session is absent; the Timeout field has a different meaning; and the Session-Reflector replaces the Session-Receiver. Implementations interoperating with OWAMP must account for these differences.
TWAMP Light (Appendix I) is an informative variant where the Session-Reflector operates without TWAMP-Control, configured by non-standard means. If the Reflector lacks session state, it MUST copy the received Sequence Number into the Sequence Number field of the reflected packet rather than maintaining an independent counter.
A Control-Client opens a TCP connection to the Server on well-known port 862 to initiate TWAMP-Control. The host initiating the TCP connection takes the roles of Control-Client and Session-Sender; the host acknowledging takes the roles of Server and Session-Reflector.
If a TWAMP Server receives an unexpected Command Number, it MUST respond with the Accept field set to 3 (meaning 'Some aspect of request is not supported') in the Accept-Session message.
In authenticated mode, the HMAC covers the first block (16 octets); in encrypted mode, the HMAC covers the first six blocks (96 octets). In TWAMP-Test, the HMAC field MUST NOT be encrypted. In authenticated and encrypted modes, HMAC MUST be calculated first, then the appropriate portion is encrypted.
In the Request-TW-Session command, both the Conf-Sender and Conf-Receiver fields MUST be set to 0, since both endpoints send and receive test packets and roles are established by which host initiates the TCP connection. The Server MUST interpret any non-zero value as an improperly formatted command and respond with Accept=3.
In TWAMP, the Timeout field in Request-TW-Session defines the interval that the Session-Reflector MUST wait after receiving a Stop-Sessions message; the Reflector MUST reflect test packets arriving within the Timeout interval and MUST NOT reflect packets arriving after the timeout.
MBZ (Must Be Zero) bits MUST be set to zero by senders and MUST be ignored by receivers throughout all TWAMP messages. All multi-octet quantities are unsigned integers in network byte order unless specified otherwise.
Packet Padding in TWAMP-Test SHOULD be pseudo-random and generated independently of other pseudo-random numbers in the document. Implementations MUST provide a configuration option to make Packet Padding consist of all zeros. Packet Padding MUST NOT be covered by HMAC and MUST NOT be encrypted.
The Number of Scheduled Slots and Number of Packets fields in Request-TW-Session MUST be set to 0 because the Session-Reflector does not process incoming test packets for performance metrics and does not need to know the packet count or timing schedule.
The same DSCP value specified in the Type-P descriptor of Request-TW-Session MUST be used in test packets reflected by the Session-Reflector.
The Server MAY discontinue any established control connection when no packet has been received within SERVWAIT seconds. The default value of SERVWAIT SHALL be 900 seconds and MAY be configurable. The Server SHALL suspend monitoring after receiving Start-Sessions and SHALL resume after Stop-Sessions.
The Server SHOULD use the DSCP value from the Control-Client's TCP SYN in all subsequent packets on that control connection. The Control-Client MAY set a desired DSCP value for all packets of a specific control connection.
The Session-Reflector MAY discontinue any session when no packet associated with that session has been received for REFWAIT seconds. The default value of REFWAIT SHALL be 900 seconds and MAY be configurable.
The Session-Reflector MUST transmit a test packet to the Session-Sender in response to each packet it receives, generating the response as immediately as possible. The Reflector MUST enter the best possible approximation of actual sending time as its Timestamp before transmission.
The Session-Reflector SHOULD fetch the TTL/Hop Limit value from the IP header of received packets to populate the Sender TTL field. If an implementation cannot access the TTL field of arriving packets, it MUST set the Sender TTL value as 255. The Reflector SHOULD set the TTL/Hop Limit to 255 in transmitted UDP packets.
The shared secret passphrase MUST be encoded using Appendix B of RFC 5198 (ASCII Network Virtual Terminal Definition). It MUST NOT contain newlines (CR and/or LF characters), and control characters SHOULD be avoided.
The Stop-Sessions command MUST NOT contain any session description records or skip ranges and is terminated with a single block HMAC. The Number of Sessions field MUST contain the exact count of send sessions started by the Control-Client that have not been previously terminated; if the count does not match, the Stop-Sessions is invalid, the TWAMP-Control connection SHOULD be closed, and results considered invalid.
TWAMP consists of two inter-related protocols: TWAMP-Control, used to initiate, start, and stop test sessions over TCP, and TWAMP-Test, used to exchange test packets between Session-Sender and Session-Reflector over UDP. The Modes field and Command Number field are the two recognized extension mechanisms.
TWAMP defines two logical roles distinct from OWAMP: the Session-Reflector (replacing Session-Receiver) which transmits a measurement packet in response to each received test packet without collecting packet-level data, and the Server which manages sessions but cannot return test results. The Fetch-Client role does not exist in TWAMP because the Session-Reflector retains no data to fetch.
TWAMP-Test AES Session-key derivation: the TWAMP-Control AES Session-key is encrypted with the 16-octet SID as the key using single-block AES-ECB encryption. The TWAMP-Test HMAC Session-key is derived by encrypting the TWAMP-Control HMAC Session-key using AES-CBC (two-block, IV=0) with the SID as the key.
IANA created the TWAMP-Control Command Number registry (first octet of TWAMP-Control messages), containing 16 possible values managed under IETF Consensus. Initial contents: 0=Reserved, 1=Forbidden, 2=Start-Sessions (RFC 4656), 3=Stop-Sessions (RFC 4656), 4=Reserved, 5=Request-TW-Session (RFC 5357), 6=Experimentation. TCP/UDP port 862 is allocated for TWAMP-Control.
The 32-bit Count field in the Server-Greeting message (used as PKCS#5 iteration counter for key derivation) can be exploited for a denial-of-service attack. TWAMP-compliant systems SHOULD have a configuration control to limit the maximum Count value, with a default maximum of 32768. A Control-Client receiving a Count exceeding its configured maximum SHOULD close the control connection.
All TWAMP timestamps use the 64-bit OWAMP format: Integer part of seconds (32 bits) followed by Fractional part of seconds (32 bits), in network byte order.
The TWAMP Stop-Sessions command format: Command Number (1 octet, value 3), Accept (1 octet), MBZ (2 octets), Number of Sessions (4 octets), MBZ (8 octets), HMAC (16 octets); total 32 octets.
TWAMP-Test reflector packet in authenticated/encrypted mode adds MBZ padding between fields and appends an HMAC (16 octets) before Packet Padding; minimum 104 octets. Layout is identical for both modes; the difference is which portion is covered by HMAC and encrypted (first 16 octets in authenticated, first 96 octets in encrypted).
TWAMP-Test reflector packet in unauthenticated mode: Sequence Number (4 octets), Timestamp (8 octets), Error Estimate (2 octets), MBZ (2 octets), Receive Timestamp (8 octets), Sender Sequence Number (4 octets), Sender Timestamp (8 octets), Sender Error Estimate (2 octets), MBZ (2 octets), Sender TTL (1 octet), Packet Padding (variable); minimum 41 octets total.