STUN protocol

Giacomo Vacca
Giacomo VaccaVoIP/WebRTC Developer, Founder at RTCSoft
STUN
Studying the STUN protocol
Giacomo Vacca, @giavac
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
Main characteristics
- Extensible packet format
- Several transport protocols
- Two forms of authentication
3
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
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
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
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
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
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
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
STUN Binding method 2/2
11
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
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
Multiplexing
STUN Messages can be multiplexed with other protocols, e.g. with RTP.
14
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
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
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
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
ALTERNATE-SERVER mechanism
Used to redirect STUN clients to another STUN server.
ERROR-CODE is 300
ALTERNATE-SERVER Attribute present in response
19
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
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
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
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
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
Other Attributes
- USERNAME
- ERROR-CODE
- REALM
- NONCE
- UNKNOWN-ATTRIBUTES (in 420 error responses)
- SOFTWARE
- ALTERNATE-SERVER
25
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
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
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
References
https://tools.ietf.org/html/rfc5389, “Session Traversal Utilities for NAT”
29
Thanks!
Giacomo Vacca
@giavac
30
1 of 30

More Related Content

What's hot(20)

ICE basicICE basic
ICE basic
Vu Nguyen1.4K views
Gsm protlGsm protl
Gsm protl
Sai Sankar Gochhayat3.4K views
Nat traversal in WebRTC contextNat traversal in WebRTC context
Nat traversal in WebRTC context
AudioCodes5.8K views
IMS Registration FlowIMS Registration Flow
IMS Registration Flow
Houman Sadeghi Kaji1.9K views
From NAT to NAT TraversalFrom NAT to NAT Traversal
From NAT to NAT Traversal
Li-Wei Yao3.6K views
Juniper BgpJuniper Bgp
Juniper Bgp
Hussein Elmenshawy1.2K views
Réseau sémaphore 7Réseau sémaphore 7
Réseau sémaphore 7
Mohamed Alaeddin Turki1.6K views
IMS Naming IdentityIMS Naming Identity
IMS Naming Identity
Kent Loh7.3K views
MPLS Traffic EngineeringMPLS Traffic Engineering
MPLS Traffic Engineering
APNIC1.8K views
IMS + VoLTE OverviewIMS + VoLTE Overview
IMS + VoLTE Overview
Hamidreza Bolhasani4.1K views
volte ims network architecturevolte ims network architecture
volte ims network architecture
Vikas Shokeen5.4K views
Multicast Routing ProtocolsMulticast Routing Protocols
Multicast Routing Protocols
Ram Dutt Shukla38.4K views
IoT Coap IoT Coap
IoT Coap
Rajanikanth U1.2K views
CS Services in LTECS Services in LTE
CS Services in LTE
Darshan Patil12.4K views

Similar to STUN protocol

Computer network (4)Computer network (4)
Computer network (4)NYversity
512 views44 slides
Ipv6upIpv6up
Ipv6upasimnawaz54
631 views40 slides
Radius ProtocolRadius Protocol
Radius ProtocolNetwax Lab
1.9K views9 slides
CCNA Interview.pdfCCNA Interview.pdf
CCNA Interview.pdfhoang971
5 views33 slides

Similar to STUN protocol(20)

Introduction to DIAMETERIntroduction to DIAMETER
Introduction to DIAMETER
Hossein Yavari663 views
Ssl (Secure Socket Layer)Ssl (Secure Socket Layer)
Ssl (Secure Socket Layer)
Sandeep Gupta8.6K views
Computer network (4)Computer network (4)
Computer network (4)
NYversity512 views
Ipv6upIpv6up
Ipv6up
asimnawaz54631 views
Radius ProtocolRadius Protocol
Radius Protocol
Netwax Lab1.9K views
CCNA Interview.pdfCCNA Interview.pdf
CCNA Interview.pdf
hoang9715 views
Bt0072 computer networks  2Bt0072 computer networks  2
Bt0072 computer networks 2
Techglyphs114 views
FirewallFirewall
Firewall
Manikyala Rao3.5K views
Training Day SlidesTraining Day Slides
Training Day Slides
adam_merritt690 views
Lecture set 7Lecture set 7
Lecture set 7
Gopi Saiteja1.3K views
FirewallsFirewalls
Firewalls
hemantag13 views
TransportsecTransportsec
Transportsec
Bogdan Korniyenko75 views
Network protocolsNetwork protocols
Network protocols
Abiud Orina144 views
4 vpn s4 vpn s
4 vpn s
Swarup Kumar Mall826 views
Lecture9Lecture9
Lecture9
Sheikh Amjad Zia195 views
Remote access serviceRemote access service
Remote access service
Apoorw Pandey16.4K views
tcpheader-151221111244.pdftcpheader-151221111244.pdf
tcpheader-151221111244.pdf
EnumulaBhargava14 views

More from Giacomo Vacca(13)

Modern VoIP in modern infrastructuresModern VoIP in modern infrastructures
Modern VoIP in modern infrastructures
Giacomo Vacca399 views
RIPP NotesRIPP Notes
RIPP Notes
Giacomo Vacca544 views
Modern VoIP in Modern InfrastructuresModern VoIP in Modern Infrastructures
Modern VoIP in Modern Infrastructures
Giacomo Vacca666 views
Homer - Workshop at Kamailio World 2017Homer - Workshop at Kamailio World 2017
Homer - Workshop at Kamailio World 2017
Giacomo Vacca1.7K views
[workshop] The Revolutionary WebRTC[workshop] The Revolutionary WebRTC
[workshop] The Revolutionary WebRTC
Giacomo Vacca584 views
Continuous Integration and KamailioContinuous Integration and Kamailio
Continuous Integration and Kamailio
Giacomo Vacca2.4K views
Docker - From Walking To RunningDocker - From Walking To Running
Docker - From Walking To Running
Giacomo Vacca720 views
Docker From ScratchDocker From Scratch
Docker From Scratch
Giacomo Vacca15.4K views

STUN protocol

  • 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
  • 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