Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)
updates
- rfc-5357 — A Two-Way Active Measurement Protocol (TWAMP)
Extracted elements (14)
The motivation for the mixed security mode extension is to permit the low-packet-rate TWAMP-Control protocol to utilize a stronger mode of integrity protection than that used in the TWAMP-Test protocol, where accuracy or efficiency may be prioritized over security.
TWAMP-Control protocol security measures are identical in Authenticated and Encrypted modes; therefore only one new bit position (3) is needed to convey the single mixed security mode rather than multiple new values.
In the original OWAMP and TWAMP Modes field, setting bit position 0, 1, or 2 indicated the security mode of the Control protocol, and the Test protocol inherited the same mode. This extension breaks that inheritance when bit position 3 is set, maintaining backward compatibility for existing implementations.
The Session-Sender packet format and content MUST follow the same procedure and guidelines as defined in RFC 4656 Section 4.1.2 and RFC 5357 Section 4.1.2, and the Session-Sender MUST support the mixed security mode (value 8, bit position 3).
The TWAMP Modes registry must be updated only by 'IETF Review' as specified in RFC 5226. New features are expected to be assigned using monotonically increasing single bit positions in the range [0-31] unless there is good reason to do otherwise.
The TWAMP Session-Reflector is REQUIRED to follow RFC 5357 Section 4.2 procedures and MUST support the mixed security mode (Unauthenticated TEST, Encrypted CONTROL, value 8, bit position 3).
When no other features are activated, the first 28 bits of the 32-bit Modes Field MUST be zero. A client conforming to this extension MAY ignore the values in the first 28 bits or MAY support other features communicated in those bit positions.
When the Control-Client sets Modes Field bit position 3, it SHALL discontinue the inheritance of the security mode in the Test protocol, and each protocol's mode SHALL be as specified in the permissible combinations table.
When the Server and Control-Client have agreed to use the mixed security mode during control connection setup, the Control-Client, Server, Session-Sender, and Session-Reflector MUST all conform to the requirements of mixed mode as described in Sections 3, 4, and 5.
When the Server has identified ability to support mixed security mode, the Control-Client has selected it in Set-Up-Response, and the Server responded with a zero Accept field in Server-Start, the extensions described in Section 4 are REQUIRED.
The complete set of TWAMP Mode values after this extension: 0 (Reserved), 1 (Unauthenticated), 2 (Authenticated), 4 (Encrypted), 8 (Unauthenticated TEST protocol, Encrypted CONTROL). The Server-Greeting Modes field is the bitwise OR of supported modes.
The TWAMP Modes field is extended with bit position 3 (value 8) to indicate 'Unauthenticated TEST protocol, Encrypted CONTROL'. Setting this bit causes the Test and Control protocols to use independent security modes rather than the Test protocol inheriting the Control mode.
IANA created a TWAMP Modes registry containing values specified in TWAMP Server Greeting and Set-up Response messages. The registry can contain up to 2^32 assignments. New values require IETF Review. Initial contents: 0 (Reserved), 1 (Unauthenticated), 2 (Authenticated), 4 (Encrypted), 8 (Unauth. TEST, Encrypted CONTROL).
The extended mixed mode permits stronger security/integrity protection on TWAMP-Control while emphasizing accuracy or efficiency on TWAMP-Test, increasing overall security compared to previous options when resource constraints would have forced less security for TWAMP-Control and unauthenticated TWAMP-Test is not a significant concern.