4. General Behavior (通用行為)
本セクションには、すべてのTURNメッセージに適用される一般的なTURN処理ルールが含まれています。
TURNはSTUNの拡張です。ChannelDataメッセージを除くすべてのTURNメッセージは、STUN形式のメッセージです。[RFC5389] で説明されているすべての基本処理ルールは、STUN形式のメッセージに適用されます。これは、本文書のすべてのメッセージ構築およびメッセージ処理の説明が、暗黙的に [RFC5389] のルールで前置されることを意味します。
[RFC5389] は、長期クレデンシャルメカニズム (Long-Term Credential Mechanism) と呼ばれる認証メカニズムを規定しています。TURNサーバーとクライアントは、このメカニズムを実装しなければなりません (MUST)。サーバーは、クライアントからのすべてのリクエストがこのメカニズムを使用して認証されること、または同等以上の強度のメカニズムを使用して認証されることを要求しなければなりません (MUST)。
長期クレデンシャルメカニズムはリクエストにのみ適用され、インディケーションの認証には使用できないことに注意してください。したがって、TURNのインディケーションは決して認証されません。サーバーがリクエストの認証を要求する場合、サーバーの管理者は、クライアントが異なる管理下の複数のサーバーを使用する場合でも、クライアントが使用しなければならないユーザー名とパスワードの組み合わせを一意に識別するレルム値を選択しなければなりません (MUST)。サーバーの管理者は、各クライアントに一意のユーザー名を割り当ててもよく (MAY)、または複数のクライアント（たとえば、同じ部門や会社のすべてのクライアント）に同じユーザー名を割り当ててもよいです (MAY)。各アロケーションについて、サーバーは、アロケーションが最初に試行されたときに、[RFC4086] のランダム性の推奨事項に従って新しいランダムなノンスを生成すべきであり (SHOULD)、アロケーションの有効期間中、少なくとも1時間ごとにノンスを期限切れにすべきです (SHOULD)。
初期Allocate後のすべてのリクエストは、攻撃者がクライアントのアロケーションを乗っ取るのを防ぐために、アロケーションの作成に使用されたものと同じユーザー名を使用しなければなりません (MUST)。具体的には、サーバーが長期クレデンシャルメカニズムの使用を要求し、非Allocateリクエストがこのメカニズムの下で認証に合格し、5タプルが既存のアロケーションを識別するが、リクエストがアロケーションの作成に使用されたものと同じユーザー名を使用していない場合、リクエストは441 (Wrong Credentials) エラーで拒否されなければなりません (MUST)。
TURNメッセージがクライアントからサーバーに到着すると、サーバーはメッセージ内の5タプルを使用して、関連するアロケーションを識別します。Allocateリクエスト以外のすべてのTURNメッセージ（ChannelDataを含む）について、5タプルが既存のアロケーションを識別しない場合、メッセージは437 (Allocation Mismatch) エラーで拒否されなければならず (MUST)（リクエストの場合）、または静かに無視されなければなりません（インディケーションまたはChannelDataメッセージの場合）。Allocate以外のリクエストに対する437エラー応答を受信したクライアントは、アロケーションがもはや存在しないと仮定しなければなりません (MUST)。
[RFC5389] は、SOFTWARE属性とFINGERPRINT属性を含む多数の属性を定義しています。クライアントは、すべてのAllocateおよびRefreshリクエストにSOFTWARE属性を含めるべきであり (SHOULD)、他のリクエストまたはインディケーションに含めてもよいです (MAY)。サーバーは、すべてのAllocateおよびRefresh応答（成功または失敗）にSOFTWARE属性を含めるべきであり (SHOULD)、他の応答またはインディケーションに含めてもよいです (MAY)。クライアントとサーバーは、本文書で定義されている任意のSTUN形式のメッセージにFINGERPRINT属性を含めてもよいです (MAY)。
TURNは、[RFC5389] で説明されている後方互換性メカニズムを使用しません。
現在の定義では、TURNはIPv4のみをサポートしています。クライアントのIPアドレス、サーバーのIPアドレス、および中継トランスポートアドレスに現れるすべてのIPアドレスは、IPv4アドレスでなければなりません (MUST)。
デフォルトでは、TURNはSTUNと同じポートで実行されます: UDPおよびTCP上のTURNは3478、TLS上のTURNは5349です。ただし、TURNには独自のサービスレコード (Service Record, SRV) 名のセットがあります: UDPおよびTCPの場合は「turn」、TLSの場合は「turns」です。セクション6で説明されているSRV手順またはALTERNATE-SERVER手順のいずれかを使用して、TURNを異なるポートで実行できます。
相互運用性を確保するために、TURNサーバーは、クライアントとサーバー間でUDPトランスポートの使用をサポートしなければならず (MUST)、TCPおよびTLSトランスポートの使用をサポートすべきです (SHOULD)。
クライアントとサーバー間でUDPトランスポートが使用される場合、クライアントは、特定のタイムアウト期間内に応答を受信しない場合、リクエストを再送信します。このため、サーバーは、同じ5タプルと同じトランザクションIDを持つ2つ（またはそれ以上）のリクエストを受信する可能性があります。STUNは、サーバーがこのケースを認識し、リクエストをべき等として扱うことを要求しています（[RFC5389] を参照）。一部の実装は、受信したすべてのリクエストと対応する応答を40秒間記憶することで、この要件を満たすことを選択する場合があります。他の実装は、リクエストを再処理し、そのような再処理が本質的に同じ応答を返すように手配することを選択する場合があります。後者のアプローチ（いわゆる「ステートレススタックアプローチ」）を選択する実装者を支援するために、本仕様には、その方法に関するいくつかの実装ノートが含まれています。実装は、どちらのアプローチを選択するか、または同じ結果を与える別のアプローチを選択するかは自由です。
クライアントとサーバー間でTCPトランスポートが使用される場合、ビットエラーにより、TURNパケットの長さフィールドが破損し、受信者が着信TURNメッセージストリームとの同期を失う可能性があります。TCPトランスポート上で長いシーケンスの無効なTURNメッセージを検出したクライアントまたはサーバーは、対応するTCP接続を閉じて、相手側がより迅速に状況を検出できるようにすべきです (SHOULD)。
有効なユーザー名とパスワードを持つクライアントによるサーバーに対する意図的または非意図的なサービス拒否攻撃を緩和するために、サーバーは、特定のユーザー名に対して一度にアクティブなアロケーションの数と、それらのアロケーションが使用できる帯域幅の量の両方に制限を課すことが推奨されます (RECOMMENDED)。サーバーは、一度に許可される同時アクティブアロケーション数の制限を超える新しいアロケーションを486 (Allocation Quota Exceeded) で拒否すべきであり (SHOULD)（セクション6.2を参照）、帯域幅クォータを超えるアプリケーションデータトラフィックを破棄すべきです (SHOULD)。