Skip to main content

14. STUN Usages

STUN by itself is not a solution to the NAT traversal problem. Rather, STUN defines a tool that can be used inside a larger solution. The term "STUN usage" is used for any solution that uses STUN as a component.

At the time of writing, three STUN usages are defined: Interactive Connectivity Establishment (ICE) [MMUSIC-ICE], Client-initiated connections for SIP [SIP-OUTBOUND], and NAT Behavior Discovery [BEHAVE-NAT]. Other STUN usages may be defined in the future.

A STUN usage defines how STUN is actually utilized -- when to send requests, how to handle responses, and which optional procedures defined here (or in an extension to STUN) are to be used. A usage would also define:

  • Which STUN methods are used.

  • What authentication and message-integrity mechanisms are used.

  • The considerations around manual versus automatic key derivation for the integrity mechanism, as discussed in [RFC4107].

  • What mechanisms are used to distinguish STUN messages from other messages. When STUN is run over TCP, a framing mechanism may be required.

  • How a STUN client determines the IP address and port of the STUN server.

  • Whether backwards compatibility to RFC 3489 is required.

  • What optional attributes defined here (such as FINGERPRINT and ALTERNATE-SERVER) or in other extensions are required.

In addition, any STUN usage must consider the security implications of using STUN in that usage. A number of attacks against STUN are known (see the Security Considerations section in this document), and any usage must consider how such attacks are thwarted or mitigated.

Finally, a usage must consider whether its use of STUN is an example of the Unilateral Self-Address Fixing approach to NAT traversal, and if so, address the questions raised in RFC 3424 [RFC3424].

Last updated on