Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)
Extracted elements (16)
STUN's existing retransmission algorithm (RFC 5389) cannot determine RTT when a request is retransmitted because each request and retransmission packet is bit-wise identical. This attribute makes retransmits distinguishable by incrementing a counter, enabling accurate RTT calculation and directional loss hints.
The mechanism is designed for use with ICE connectivity checks and TURN Allocate requests. For ICE, the controlling agent can use RTT/loss data to influence candidate pair selection, though how ICE uses this information is out of scope.
The Resp field is included so a stateful server can report how many responses it has sent, giving the client a hint about whether loss occurred upstream (client-to-server) or downstream (server-to-client). The document acknowledges it cannot always distinguish loss from reordering, but aggregate metrics over time can reveal patterns.
The TRANSACTION_TRANSMIT_COUNTER attribute is comprehension-optional (type 0x8025), so STUN agents that do not recognize it will safely ignore it. If ICE is in use, it will fall back to normal ICE procedures.
A server that supports the TRANSACTION_TRANSMIT_COUNTER attribute MUST echo back the Req field in the response using a TRANSACTION_TRANSMIT_COUNTER attribute.
Any retransmitted STUN request MUST be bit-wise identical to the previous request except for the values in the TRANSACTION_TRANSMIT_COUNTER attribute. This changes the STUN retransmission rule from RFC 5389 Section 6 for idempotent packets.
The client MUST populate the Req value in the TRANSACTION_TRANSMIT_COUNTER attribute to reflect the number of requests transmitted to the server. The initial value for the first request is 1, incremented by 1 for each retransmission.
The padding bits in the TRANSACTION_TRANSMIT_COUNTER attribute MUST be set to zero to allow for future reuse of those bits.
The Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute MUST be set to zero in request messages.
If the server is stateless or does not wish to track the transaction ID, it populates 0 for the Resp field in the response. If stateful, it populates the Resp field with the number of responses sent for that STUN request, giving the client a directional loss hint.
The TRANSACTION_TRANSMIT_COUNTER attribute is a new comprehension-optional STUN attribute with type 0x8025. It carries a 32-bit value with Req and Resp 8-bit counters (and 16 bits of reserved padding) to track transmission counts for the same transaction ID.
IANA allocated the comprehension-optional codepoint 0x8025 in the STUN Attributes registry for the TRANSACTION_TRANSMIT_COUNTER attribute defined in this document.
An off-path attacker is adequately defended against by the STUN requirement that the 96-bit transaction ID be uniformly and randomly chosen from 0..2^96-1 with cryptographic strength. An attacker could also corrupt, remove, or delay ICE requests/responses to discourage use of a particular path.
An on-path attacker can inject a fake response or modify TRANSACTION_TRANSMIT_COUNTER values to mislead client and server. This attack is mitigated by STUN authentication: ICE uses STUN short-term credentials, and TURN Allocate requests should use the STUN long-term credential mechanism, RFC 7635 third-party authorization, or a TLS/DTLS connection.
If not encrypted, information in STUN packets carrying the TRANSACTION_TRANSMIT_COUNTER attribute can be observed passively and used for reconnaissance and later attacks.
The TRANSACTION_TRANSMIT_COUNTER attribute value is 32 bits: 16 bits Reserved (Padding, MUST be set to zero), 8-bit Req field (request transmit count), and 8-bit Resp field (response transmit count). The padding exists to satisfy STUN's 32-bit attribute boundary requirement.