The STUN nonce cookie bid-down prevention mechanism was added because the new password algorithm selection and username anonymity features are optional and backwards-compatible, making them vulnerable to an on-path attacker stripping the capabilities. The nonce cookie encodes which features are active, allowing the client to detect tampering.

nat, security

The XOR-MAPPED-ADDRESS attribute was introduced alongside MAPPED-ADDRESS to defeat NAT Application Layer Gateways (ALGs) that rewrite IP addresses found in packet payloads. XOR-encoding the address with the magic cookie and transaction ID obscures the address from ALGs that scan for recognizable IP address patterns.

nat

DTLS MUST NOT be used with RFC 3489 (classic STUN). Any STUN request or indication without the magic cookie received over DTLS MUST be considered invalid: requests generate a 500 (Server Error) response and indications are discarded.

nat, tls

Agents MUST ignore all attributes that follow MESSAGE-INTEGRITY, except MESSAGE-INTEGRITY-SHA256 and FINGERPRINT. Agents MUST ignore all attributes that follow MESSAGE-INTEGRITY-SHA256 (when MESSAGE-INTEGRITY is absent), except FINGERPRINT.

nat, security

DNS server discovery uses SRV records per RFC 2782. The default port for STUN over UDP and TCP is 3478; the default port for STUN over TLS and DTLS is 5349. A 'stuns' URI containing an IP address MUST be rejected. Dual-stack clients MUST query both A and AAAA records and try all received addresses.

nat, dns, ip

For subsequent long-term credential requests, the client MUST include USERNAME or USERHASH, REALM, NONCE, PASSWORD-ALGORITHM, and MESSAGE-INTEGRITY-SHA256 (or MESSAGE-INTEGRITY) using cached values. If the response contains a PASSWORD-ALGORITHMS attribute, all subsequent requests MUST use MESSAGE-INTEGRITY-SHA256 only.

nat, security

Over TCP and TLS-over-TCP, transaction reliability is provided by TCP itself with no STUN-level retransmissions. If no response is received within Ti (default 39.5 s), the transaction is considered timed out. A server MUST NOT open a connection back to the client to send a response.

nat, tcp, tls

Over UDP or DTLS-over-UDP, a client SHOULD retransmit STUN requests starting with an RTO of at least 500 ms, doubling after each retransmission. The retransmit count Rc SHOULD default to 7; the client SHOULD consider the transaction failed after Rm (default 16) times the RTO without a response. STUN indications over UDP are not retransmitted.

nat, udp, congestion

The Magic Cookie field MUST contain the fixed value 0x2112A442 in network byte order. This value enables servers to detect RFC 5389-era clients and aids demultiplexing when STUN is mixed with other protocols on the same port.

nat

The most significant 2 bits of every STUN message MUST be zeroes. This allows STUN packets to be distinguished from other protocols when multiplexed on the same port.

nat

The transaction ID MUST be uniformly and cryptographically randomly chosen from the interval 0..2^96-1. The client MUST choose a new transaction ID for each new transaction; resends of the same request reuse the same ID.

nat, security

To signal compliance with RFC 8489, a server MUST prepend the NONCE attribute value with the 13-character 'nonce cookie' ('obMatJos2' concatenated with a 4-character base64 encoding of the 24-bit STUN Security Features). This enables detection of bid-down attacks on new security features.

nat, security

Unknown comprehension-optional attributes MUST be ignored. Unknown comprehension-required attributes in a request cause the server to reply with error 420 (Unknown Attribute) and include an UNKNOWN-ATTRIBUTES attribute listing them. Unknown comprehension-required attributes in a response cause the transaction to be considered failed.

nat

When STUN runs over TLS-over-TCP or DTLS-over-UDP, Perfect Forward Secrecy (PFS) ciphersuites MUST be preferred, ciphersuites with known weaknesses (e.g., DES, RC4) MUST NOT be used, and TLS-level compression MUST be disabled. Implementations MUST follow BCP195.

tls, security, nat

When verifying a TLS certificate, the client MUST verify certificate validity and identity per RFC 6125, accepting identifiers of type DNS-ID or CN-ID (optionally with wildcards) but not SRV-ID or URI-ID. The client MUST NOT send the STUN message if the certificate is invalid, revoked, or identifies the wrong party.

tls, pkix, security, nat

STUN defines two transaction types: request/response (client sends request, server returns success or error response) and indication (either agent sends, no response generated). Both types carry a 96-bit transaction ID. This document defines a single method, Binding; other methods may be defined in extensions.

nat

The ALTERNATE-SERVER mechanism allows a server to redirect a client using a 300 (Try Alternate) error response with at least one ALTERNATE-SERVER attribute carrying an IP address of the same family as the source address. A client MUST NOT follow a redirection to a server it has already contacted within the last five minutes, preventing redirect loops.

nat

The FINGERPRINT mechanism optionally appends a FINGERPRINT attribute containing a CRC-32 of the message XOR'd with 0x5354554e, enabling more reliable demultiplexing of STUN from other protocols (e.g., RTP). When used, agents verify its presence and correctness upon receipt. This mechanism is not backwards-compatible with RFC 3489.

nat

The long-term credential mechanism uses a provisioned username/password with digest challenge/response. The client first sends an unauthenticated request, receives a 401 with REALM and NONCE, then retries including USERNAME (or USERHASH), REALM, NONCE, and a message-integrity attribute. The HMAC key is MD5(username:OpaqueString(realm):OpaqueString(password)) by default. Long-term credentials cannot protect indications.

nat, security, crypto

The short-term credential mechanism uses a pre-exchanged username/password (obtained out-of-band, e.g., via ICE signaling). The HMAC key is OpaqueString(password). Requests and responses MUST include USERNAME and MESSAGE-INTEGRITY-SHA256 (plus MESSAGE-INTEGRITY) unless an external mechanism restricts the choice to one integrity attribute.

nat, security

This document creates the STUN Password Algorithms Registry for use with the PASSWORD-ALGORITHM attribute. Initial entries are MD5 (0x0001, key length 16 bytes) and SHA-256 (0x0002, key length 32 bytes). New algorithms require Expert Review.

registry, nat, crypto

This document creates the STUN Security Features Registry, a 24-bit field embedded in the long-term credential nonce cookie. Bit 0 (most significant of byte 0) = Password algorithms; Bit 1 = Username anonymity. New features require IETF Review or IESG Approval.

registry, nat, security

This document updates the STUN Attributes Registry and adds new attributes: USERHASH (0x001E), MESSAGE-INTEGRITY-SHA256 (0x001C), PASSWORD-ALGORITHMS (0x8002), PASSWORD-ALGORITHM (0x001D), and ALTERNATE-DOMAIN (0x8003). Attributes 0x0000–0x7FFF are comprehension-required; 0x8000–0xFFFF are comprehension-optional.

registry, nat

This document updates the STUN Error Codes Registry. Codes include 300 (Try Alternate), 400 (Bad Request), 401 (Unauthenticated), 420 (Unknown Attribute), 438 (Stale Nonce), and 500 (Server Error). New error codes require Expert Review.

registry, nat

This document updates the STUN Methods Registry. The Binding method (0x001) is defined here. New methods require Expert Review. Extensions defining new methods MUST indicate which message classes (request, response, indication) are permitted.

registry, nat

Bid-down attacks allow an on-path attacker to remove PASSWORD-ALGORITHMS or Username anonymity capability indicators, forcing the client and server to use weaker security. The nonce cookie mechanism is designed to detect such stripping, but requires both client and server to implement RFC 8489.

nat, security, crypto

Outside attackers can spoof STUN error responses to abort in-progress transactions, or inject forged STUN responses. The MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 attributes provide HMAC protection against such attacks; without authentication, STUN is vulnerable to on-path injection.

nat, security

STUN servers on the public Internet can be abused to launch amplification DDoS attacks (Attack I): an attacker spoofs the source address of Binding requests so that STUN responses are directed at a victim. The long-term credential mechanism mitigates this by requiring authentication before responses are sent.

nat, security

STUN messages comprise a 20-byte fixed header followed by zero or more TLV attributes. The header contains: STUN Message Type (16 bits), Message Length (16 bits, not including the header), Magic Cookie (32 bits, fixed value 0x2112A442), and Transaction ID (96 bits). All fields are big-endian.

nat, udp, tcp

The STUN Message Type field is 14 bits, decomposed into a 12-bit method (M11–M0) and a 2-bit class (C1–C0): 0b00=request, 0b01=indication, 0b10=success response, 0b11=error response. The Binding method is encoded as 0b000000000001; a Binding request is 0x0001 and a Binding success response is 0x0101.

nat