The STUN protocol allows clients to discover their public IP address and port when they are behind a NAT. It works by having a client send a request to a STUN server, which responds with the client's reflexive transport address as seen by the server. STUN can also be used to check connectivity and maintain NAT bindings over time. It defines a packet format with a header and attributes, as well as request/response and indication transactions. Common usages of STUN include ICE for NAT traversal and SIP outbound for VoIP calls. The document discusses STUN operations, messages, attributes and security considerations.

1. STUN
Studying the STUN protocol
Giacomo Vacca, @giavac

2. STUN: Session Traversal Utilities for NAT
RFC 5389 (8489)
"[STUN] can be used by an endpoint to determine the IP address and port allocated
to it by a NAT. It can also be used to check connectivity between two endpoints, and
as a keep-alive protocol to maintain NAT bindings."
Combination with other protocols:
- Connectivity checks: ICE (RFC 8845)
- Relay: TURN (RFC 5766, 8656) 2

3. Main characteristics
- Extensible packet format
- Several transport protocols
- Two forms of authentication
3

4. STUN “usages”
A “usage” defines:
- When STUN messages get sent
- Optional Attributes to include
- What server is used
- The authentication mechanism
ICE (RFC 8445), SIP OUTBOUND (RFC 5626) and NAT Behaviour Discovery (RFC
5780) are all “STUN usages” and are “complete NAT traversal solutions”.
A STUN extension may define new methods, attributes or response codes. 4

5. STUN operations
STUN is a client-server protocol.
STUN defines 2 types of transactions:
1. Request/Response
2. Indication
Request/Response: client sends a
request, server sends a response.
Indication: either client or server sends
an indication, without the need for a
response.
A 96-bit transaction ID is required.
5

6. STUN messages
All STUN messages start with a fixed header with:
- Method (e.g. Binding)
- Class (Request, Success Response, Error Response or Indication)
- Transaction ID (96-bit number)
After the header there are zero or more Attributes (in the form of
Type-Length-Value). Attributes can be required (“comprehension-required”) or
optional (“comprehension-optional”).
Attributes are always padded to a multiple of 4 Bytes. Optional: FINGERPRINT 6

7. STUN header
Binary, network order, big endian.
20 Bytes header + 0 or more Attributes.
The header contains:
- Message Type (16 bits)
- Message Length (16 bits)
- Magic Cookie (32 bits)
- Transaction ID (96 bits)
Message Type: First 2 most significant
bits: 00, Class (Request, Success
Response, Error Response, Indication),
Method.
7

8. The Magic Cookie
0x2112A442
0010 0001 0001 0010 1010 0100 0100 0010
It’s used to further distinguish a STUN packet from other types, and to XOR the transport addresses.
8

9. Transport Addresses
A Transport Address is the combination of an IP address and port, e.g. 172.17.0.3:44567
Reflexive Transport Address: A Transport Address learned by a STUN client, identifying that client as
seen by another host or network, typically a STUN server. e.g. “What’s my public IP and port?”
Provided in MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attributes in STUN responses.
ç
9

10. STUN Binding method 1/2
Used in Request/Response transactions: to determine what binding a STUN
server has allocated for the client, and keep the binding alive.
Used in Indication transactions: to keep the binding alive.
In Request/Response transactions, a STUN client sends a “Binding Request” to
the STUN server. The STUN server replies with a “Binding Success Response”,
containing an attribute called XOR-MAPPED-ADDRESS, which value is the XOR’d
source transport address, as seen by the STUN server. In this way the STUN
client learns its Reflexive Transport Address allocated by the outermost NAT. 10

11. STUN Binding method 2/2
11

12. STUN mechanisms (optional procedures)
- DNS discovery
- Redirection to an alternate server
- A fingerprint attribute for demultiplexing
- 2 authentication and message integrity exchanges (username, password,
message-integrity)
- long-term credentials (pre-provisioned credentials)
- short-term credentials (out-of-band method before STUN exchange,
credentials expire quickly; e.g. ICE)
12

13. Authentication and message integrity
- long-term credentials (pre-provisioned credentials with digest authentication)
- Server replies with ERROR-CODE 401, REALM and NONCE (for replay protection)
- Client sends request again, with USERNAME, REALM, NONCE and the computed
MESSAGE-INTEGRITY
- Indications cannot be challenged so cannot use this method
- short-term credentials (out-of-band method before STUN, credentials expire; e.g. ICE)
- Authentication requires USERNAME and MESSAGE-INTEGRITY Attributes.
- Responses contain the MESSAGE-INTEGRITY Attribute.
Errors: 401 (unauthorized, failed authentication), 400 (bad request, missing attributes), 438 (stale nonce)
13

14. Multiplexing
STUN Messages can be multiplexed with other protocols, e.g. with RTP.
14

15. Sending Requests or Indications over UDP
Requests can be retransmitted until a Response is received. Exponential backoff
with RTO (Retransmission TimeOut)
Indications are not retransmitted and so are not reliable.
15

16. Sending Requests or Indications over TCP or
TLS-over-TCP
The STUN client opens a TCP connection to the STUN server.
TLS:
- Minimum TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite
- The client SHOULD verify the server certificate
- The client MUST verify the server identity
The STUN server should not close TCP connections (nor open connections
towards the client).
16

17. Sending Responses (Success or Error)
The Method is the same as the Request. Class is either “Success Response” or “Error Response”.
For Success Response to Binding method:
- The server adds a XOR-MAPPED-ADDRESS Attribute with source Transport Address.
For Error Response:
- The server adds an ERROR-CODE Attribute.
- Add the authentication Attributes if applicable (e.g. error 401)
- Add other applicable Attributes (e.g. UNKNOWN-ATTRIBUTES for error 420)
17

18. DNS discovery
SRV records: the service type is stun (stuns for TLS-over-TCP)
Default port for UDP and TCP: 3478
Default port for TLS: 5349
No SRV record: perform A or AAAA lookup.
18

19. ALTERNATE-SERVER mechanism
Used to redirect STUN clients to another STUN server.
ERROR-CODE is 300
ALTERNATE-SERVER Attribute present in response
19

20. STUN Attributes
A STUN message can have 0 or more Attributes, after the header. Attributes can
appear more than once inside a message
Each Attribute is a Type-Length-Value structure.
Type: 16 bits - 0x0000 to 0x7FFF are comprehension-required, 0x8000 to 0xFFFF
are comprehension-optional
Length: 16 bits
Value: variable, padded to multiple of 32 bits. 20

21. MAPPED-ADDRESS
A reflexive transport address of the client.
First 8 bits set to 0
Address family: 8 bits (0x01: IPv4, 0x02: IPv6)
Port: 16 bits
IP address: 32 bits if IPv4, 128 bits if IPv6
Network byte order
21

22. XOR-MAPPED-ADDRESS
Same as MAPPED-ADDRESS, but the reflexive transport address is obfuscated
through the XOR function (with the Magic Cookie).
X-Port is the Port XOR’d with the 16 most significant bits of the Magic Cookie.
X-Address:
- IPv4: XOR’d Address with Magic Cookie (32 bits)
- IPv6: XOR-d Address with Magic Cookie (32 bits) + Transaction ID (96 bits)
22

23. MESSAGE-INTEGRITY
HMAC-SHA1 of the STUN message
20 Bytes
For long-term credentials: key = MD5(username ":" realm ":" SASLprep(password))
For short-term credentials: key = SASLprep(password)
23

24. FINGERPRINT
CRC-32 of the STUN message (excluding the FINGERPRINT Attribute itself),
XOR’d with 0x5354554E.
When present must be the last Attribute, so also after MESSAGE-INTEGRITY.
This means FINGERPRINT depends on MESSAGE-INTEGRITY value.
24

25. Other Attributes
- USERNAME
- ERROR-CODE
- REALM
- NONCE
- UNKNOWN-ATTRIBUTES (in 420 error responses)
- SOFTWARE
- ALTERNATE-SERVER
25

26. Security
Considerations
1. Attacks against the protocol
- Outside attacks
- Inside attacks
2. Attacks affecting the usage
- DDoS against a Target
- Silencing a Client
- Assuming the identity of a
Client
- Eavesdropping
3. Hash agility plan
- In case HMAC-SHA1
becomes compromised
26

27. Attacks against the protocol
Outside attacks: an attacker modifies a message in transit. These are detected
through the message-integrity mechanism. Such packets must be dropped.
Subject to offline dictionary attacks: use TLS or strong passwords.
Inside attacks: DDoS attack from a malicious client to a STUN server. False
source address to generate traffic (responses) to a victim: apply ingress source
filtering.
Revealing software versions in SOFTWARE attribute: make it optional.
27

28. Attacks affecting the usage
DDoS against a Target: The attacker provides one or more clients with a faked reflexive address that
points to the target. Only possible if the packets from the server pass through the attacker.
Silencing a Client: The attacker provides a client with a faked reflexive address that points nowhere, so
the target can’t receive.
Assuming the identity of a Client: As in “Silencing a Client”, but the faked reflexive address points to the
attacker.
Eavesdropping: The attacker forces the client to use a reflexive address that routes to the attacker itself,
then the attacker forwards any client it receives to the client. The attacker sees all the packets received
by the target.
28

29. References
https://tools.ietf.org/html/rfc5389, “Session Traversal Utilities for NAT”
29

30. Thanks!
Giacomo Vacca
@giavac
30