4. General Behavior
This section contains general TURN processing rules that apply to all TURN messages.
TURN is an extension to STUN. All TURN messages, with the exception of the ChannelData message, are STUN-formatted messages. All the base processing rules described in [RFC5389] apply to STUN-formatted messages. This means that all the message-forming and message-processing descriptions in this document are implicitly prefixed with the rules of [RFC5389].
[RFC5389] specifies an authentication mechanism called the long-term credential mechanism. TURN servers and clients MUST implement this mechanism. The server MUST demand that all requests from the client be authenticated using this mechanism, or using an equally strong or stronger mechanism.
Note that the long-term credential mechanism applies only to requests and cannot be used to authenticate indications; thus, indications in TURN are never authenticated. If the server requires requests to be authenticated, then the server's administrator MUST choose a realm value that will uniquely identify the username and password combination that the client must use, even if the client uses multiple servers under different administrations. The server's administrator MAY choose to allocate a unique username for each client, or MAY choose to allocate the same username for multiple clients (for example, for all clients from the same department or company). For each allocation, the server SHOULD generate a new random nonce when the allocation is first attempted, following the randomness recommendations in [RFC4086], and SHOULD expire the nonce at least once every hour during the lifetime of the allocation.
All requests after the initial Allocate MUST use the same username as used to create the allocation, to prevent an attacker from hijacking the client's allocation. Specifically, if the server requires the use of the long-term credential mechanism, and if a non-Allocate request passes authentication under this mechanism, and if the 5-tuple identifies an existing allocation, but the request does not use the same username as used to create the allocation, then the request MUST be rejected with a 441 (Wrong Credentials) error.
When a TURN message arrives at the server from the client, the server uses the 5-tuple in the message to identify the associated allocation. For all TURN messages (including ChannelData) other than an Allocate request, if the 5-tuple does not identify an existing allocation, then the message MUST be rejected with a 437 (Allocation Mismatch) error (if it is a request) or silently ignored (if it is an indication or a ChannelData message). A client receiving a 437 error response to a request other than Allocate MUST assume the allocation no longer exists.
[RFC5389] defines a number of attributes, including the SOFTWARE and FINGERPRINT attributes. The client SHOULD include the SOFTWARE attribute in all Allocate and Refresh requests and MAY include it in any other requests or indications. The server SHOULD include the SOFTWARE attribute in all Allocate and Refresh responses (either success or failure) and MAY include it in other responses or indications. The client and server MAY include the FINGERPRINT attribute in any STUN-formatted messages defined in this document.
TURN does not use the backwards-compatibility mechanism described in [RFC5389].
As currently defined, TURN supports only IPv4. The IP addresses of the client, the server, and all IP addresses appearing in relayed transport addresses MUST be IPv4 addresses.
By default, TURN runs on the same ports as STUN: 3478 for TURN over UDP and TCP, and 5349 for TURN over TLS. However, TURN has its own set of Service Record (SRV) names: "turn" for UDP and TCP, and "turns" for TLS. Either the SRV procedures or ALTERNATE-SERVER procedures, both described in Section 6, can be used to run TURN on a different port.
To ensure interoperability, a TURN server MUST support the use of UDP transport between the client and the server, and SHOULD support the use of TCP and TLS transports.
When UDP transport is used between the client and the server, the client will retransmit a request if it does not receive a response within a certain timeout period. Because of this, the server may receive two (or more) requests with the same 5-tuple and same transaction id. STUN requires that the server recognize this case and treat the request as idempotent (see [RFC5389]). Some implementations may choose to meet this requirement by remembering all received requests and the corresponding responses for 40 seconds. Other implementations may choose to reprocess the request and arrange that such reprocessing returns essentially the same response. To aid implementors who choose the latter approach (the so-called "stateless stack approach"), this specification includes some implementation notes on how to do so. Implementations are free to choose either approach or to choose another approach that gives the same results.
When TCP transport is used between the client and the server, bit errors can cause the length field in a TURN packet to become corrupted, causing the receiver to lose synchronization with the incoming stream of TURN messages. A client or server that detects a long sequence of invalid TURN messages on a TCP transport SHOULD close the corresponding TCP connection to help the other end detect the situation more quickly.
To mitigate either intentional or unintentional denial-of-service attacks against the server by clients with valid usernames and passwords, it is RECOMMENDED that the server impose both a limit on the number of allocations active at once for a given username and a limit on the amount of bandwidth those allocations can use. The server SHOULD reject new allocations that would exceed the limit on the allowed number of concurrent allocations active at once with a 486 (Allocation Quota Exceeded) (see Section 6.2), and SHOULD discard application data traffic that exceeds the bandwidth quota.