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.
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
4. STUN โusagesโ
A โusageโ de๏ฌnes:
- 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 de๏ฌne new methods, attributes or response codes. 4
5. STUN operations
STUN is a client-server protocol.
STUN de๏ฌnes 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 ๏ฌxed 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 signi๏ฌcant
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
Re๏ฌexive 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 Re๏ฌexive Transport Address allocated by the outermost NAT. 10
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 certi๏ฌcate
- 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 re๏ฌexive 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 re๏ฌexive transport address is obfuscated
through the XOR function (with the Magic Cookie).
X-Port is the Port XORโd with the 16 most signi๏ฌcant 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
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 modi๏ฌes a message in transit. These are detected
through the message-integrity mechanism. Such packets must be dropped.
Subject to o๏ฌine dictionary attacks: use TLS or strong passwords.
Inside attacks: DDoS attack from a malicious client to a STUN server. False
source address to generate tra๏ฌc (responses) to a victim: apply ingress source
๏ฌltering.
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 re๏ฌexive 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 re๏ฌexive address that points nowhere, so
the target canโt receive.
Assuming the identity of a Client: As in โSilencing a Clientโ, but the faked re๏ฌexive address points to the
attacker.
Eavesdropping: The attacker forces the client to use a re๏ฌexive 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