[要約] RFC 6026は、SIP INVITEリクエストへの2xx応答の正しいトランザクション処理に関するガイドラインです。このRFCの目的は、SIPセッションの確立と終了のプロトコルを適切に処理するための手順を提供することです。
Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 6026 Tekelec
Updates: 3261 T. Zourzouvillys
Category: Standards Track Skype
ISSN: 2070-1721 September 2010
Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests
セッション開始プロトコル（SIP）への2xx応答のための正しいトランザクション処理招待リクエスト
Abstract
概要
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk.
このドキュメントは、セッション開始プロトコル（SIP）であるRFC 3261を規範的に更新し、指定された成功（2xxクラス）応答のエラーに対処し、リクエストを招待します。RFC 3261に続く要素は、正確にリクエストの再送信を誤認します。修正には、Invite Transaction Stateマシンの変更が含まれます。修正は、セキュリティリスクに対処するために既存のトランザクションに一致できない応答が処理される方法も変更します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6026.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6026で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Definitions .....................................3
3. Reason for Change ...............................................3
4. Summary of Change ...............................................4
5. Consequences if Not Implemented .................................4
6. The Change ......................................................4
7. Change Details ..................................................5
7.1. Server Transaction Impacts .................................5
7.2. Client Transaction Impacts .................................9
7.3. Proxy Considerations ......................................10
8. Exact Changes to RFC 3261 ......................................11
8.1. Page 85 ...................................................11
8.2. Page 107 ..................................................11
8.3. Page 114 ..................................................11
8.4. Pages 126 through 128 .....................................12
8.5. Pages 134 to 135 ..........................................15
8.6. Page 136 ..................................................15
8.7. Page 137 ..................................................17
8.8. Page 141 ..................................................17
8.9. Page 144 ..................................................18
8.10. Page 146 .................................................18
8.11. Page 265 .................................................18
9. IANA Considerations ............................................18
10. Security Considerations .......................................19
11. Acknowledgments ...............................................20
12. Normative References ..........................................20
This document describes an essential correction to the Session Initiation Protocol (SIP), defined in [RFC3261]. The change addresses an error in the handling of 2xx class responses to INVITE requests that leads to retransmissions of the INVITE being treated as new requests and forbids forwarding stray INVITE responses.
このドキュメントでは、[RFC3261]で定義されているセッション開始プロトコル（SIP）に対する本質的な修正について説明します。この変更は、2XXクラスの応答の処理におけるエラーに対処し、招待状の再送信につながる招待リクエストに触れて、新しい要求として扱われ、招待招待の回答を転送します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
One use of the INVITE method in SIP is to establish new sessions. These "initial" INVITEs may fork at intermediaries, and more than one receiving endpoint may choose to accept the request. SIP is designed such that the requester receives all of these success responses.
SIPでの招待方法の1つの使用は、新しいセッションを確立することです。これらの「初期」は、仲介者に招待される可能性があり、複数の受信エンドポイントがリクエストを受け入れることを選択する場合があります。SIPは、リクエスターがこれらの成功応答をすべて受信するように設計されています。
Two sets of requirements in [RFC3261] work together to allow multiple 2xx responses to be processed correctly by the requester. First, all elements are required to immediately destroy any INVITE client transaction state upon forwarding a matching 2xx class response. This requirement applies to both UAs (user agents) and proxies (proxies forward the response upstream, the transaction layer at user agents forwards the response to its "UA core"). Second, all proxies are required to statelessly forward upstream any 2xx class responses that do not match an existing transaction, also called stray responses. The transaction layer at user agents is required to forward these responses to its UA core. Logic in the UA core deals with acknowledging each of these responses.
[RFC3261]の2セットの要件は、リクエスターによって複数の2XX応答を正しく処理できるようにするために連携します。まず、すべての要素は、一致する2xxクラスの応答を転送する際に、招待クライアントトランザクション状態を直ちに破壊する必要があります。この要件は、UAS（ユーザーエージェント）とプロキシの両方に適用されます（プロキシは上流の応答を転送し、ユーザーエージェントのトランザクションレイヤーは「UA Core」に対する応答を転送します）。第二に、すべてのプロキシは、Stray Responseとも呼ばれる既存のトランザクションとも一致しない2XXクラスの応答をステートレレスに転送する必要があります。ユーザーエージェントのトランザクションレイヤーは、これらの応答をUAコアに転送するために必要です。UAコアのロジックは、これらの各応答の認識を扱っています。
This technique for specifying the behavior was chosen over adjusting INVITE client transaction state machines as a simpler way to specify the correct behavior.
動作を指定するためのこの手法は、正しい動作を指定するためのより簡単な方法として、招待クライアントトランザクションステートマシンの調整よりも選択されました。
Over time, implementation experience demonstrated the existing text is in error. Once any element with a server transaction (say, a proxy in the path of the INVITE) deletes that transaction state, any retransmission of the INVITE will be treated as a new request, potentially forwarded to different locations than the original. Many implementations in the field have made proprietary adjustments to their transaction logic to avoid this error.
時間が経つにつれて、実装の経験は、既存のテキストが誤っていることを実証しました。サーバートランザクションを持つ要素（たとえば、招待のパスのプロキシ）がトランザクション状態を削除すると、招待の再送信は新しい要求として扱われ、潜在的にオリジナルとは異なる場所に転送されます。この分野での多くの実装により、このエラーを回避するために、トランザクションロジックを独自の調整を行いました。
The requirement to statelessly forward stray responses has also been identified as a security risk. Through it, elements compliant to [RFC3261] are compelled to do work (forward packets) that is not protected by the admission policies applied to requests. This can be leveraged to, for instance, use a SIP proxy as an anonymizing forwarder of packets in a distributed denial-of-service attack. General Internet endpoints can also collude to tunnel non-SIP content through such proxies by wrapping them in an SIP response envelope.
ステートレスに迷いの応答を妨げる要件も、セキュリティリスクとして特定されています。それを通して、[RFC3261]に準拠した要素は、リクエストに適用される入場ポリシーによって保護されていない作業（フォワードパケット）を行うことを余儀なくされます。これは、たとえば、分散型サービス拒否攻撃でパケットの匿名の転送者としてSIPプロキシを使用することができます。一般的なインターネットエンドポイントは、SIP応答エンベロープにラッピングすることにより、そのようなプロキシを通じて非SIPコンテンツをトンネルするために共謀することもできます。
Additionally, [RFC3261] requires that if an unrecoverable transport error is encountered while sending a response in a client transaction, that the transaction moves immediately into the "Terminated" state. This will result in any retransmitted INVITE requests received after such an error was encountered to be processed as a new request instead of being absorbed as a retransmission.
さらに、[RFC3261]では、クライアントトランザクションで応答を送信している間に回復不可能な輸送エラーが発生した場合、トランザクションがすぐに「終了」状態に移動することが必要です。これにより、再送信として吸収される代わりに、そのようなエラーが新しいリクエストとして処理されるために遭遇した後に受け取った再送信招待リクエストが発生します。
This correction document updates [RFC3261], adding a state and changing the transitions in the INVITE client state machine such that the INVITE client transaction remains in place to receive multiple 2xx responses. It adds a state to the INVITE server state machine to absorb retransmissions of the INVITE after a 2xx response has been sent. It modifies state transitions in the INVITE server state machine to absorb retransmissions of the INVITE request after encountering an unrecoverable transport error when sending a response. It also forbids forwarding stray responses to INVITE requests (not just 2xx responses), which RFC 3261 requires.
この修正ドキュメントは[RFC3261]を更新し、状態を追加し、招待クライアント状態マシンの遷移を変更して、招待クライアントトランザクションが継続され、複数の2XX応答を受け取るようにします。2xxの応答が送信された後、招待状の再送信を吸収するために招待サーバー状態マシンに状態を追加します。Invite Server Stateマシンの状態遷移を変更して、応答を送信する際に回収不能な輸送エラーに遭遇した後、Invite Requestの再送信を吸収します。また、RFC 3261が必要とするリクエスト（2xxの応答だけでなく）への迷惑応答の転送も禁止しています。
Implementations strictly conformant to [RFC3261] will process retransmitted initial INVITE requests as new requests. Proxies may forward them to different locations than the original. Proxies may also be used as anonymizing forwarders of bulk traffic. Implementations will process any retransmitted INVITE request as a new request after an attempt to send a response results in an unrecoverable error.
[RFC3261]に厳密に適合した実装は、新しいリクエストとして再送信された初期招待要求を処理します。プロキシは、オリジナルとは異なる場所に転送できます。プロキシは、バルクトラフィックの匿名のフォワーダーとしても使用できます。実装は、応答を送信しようとすると、回復不可能なエラーが発生した後、新しいリクエストとして再送信された招待リクエストを処理します。
An element sending or receiving a 2xx to an INVITE transaction MUST NOT destroy any matching INVITE transaction state. This state is necessary to ensure correct processing of retransmissions of the request and the retransmission of the 2xx and ACK that follow.
招待トランザクションに2xxを送信または受信する要素は、一致する招待状のトランザクション状態を破壊してはなりません。この状態は、リクエストの再送信の正しい処理と、続く2XXおよびACKの再送信を確保するために必要です。
An element encountering an unrecoverable transport error when trying to send a response to an INVITE request MUST NOT immediately destroy the associated INVITE server transaction state. This state is necessary to ensure correct processing of retransmissions of the request.
招待状リクエストに応答を送信しようとするときに回復不可能なトランスポートエラーに遭遇する要素は、関連する招待サーバートランザクション状態をすぐに破壊してはなりません。この状態は、リクエストの再送信の正しい処理を確保するために必要です。
When receiving any SIP response, a transaction-stateful proxy MUST compare the transaction identifier in that response against its existing transaction state machines. The proxy MUST NOT forward the response if there is no matching transaction state machine.
SIP応答を受信する場合、トランザクション状態のプロキシは、既存のトランザクション状態マシンに対してその応答のトランザクション識別子を比較する必要があります。一致するトランザクションステートマシンがない場合、プロキシは応答を転送してはなりません。
When receiving an ACK that matches an existing INVITE server transaction and that does not contain a branch parameter containing the magic cookie defined in RFC 3261, the matching transaction MUST be checked to see if it is in the "Accepted" state. If it is, then the ACK must be passed directly to the transaction user instead of being absorbed by the transaction state machine. This is necessary as requests from RFC 2543 clients will not include a unique branch parameter, and the mechanisms for calculating the transaction ID from such a request will be the same for both INVITE and ACKs.
既存のInvite Serverトランザクションに一致するACKを受信し、RFC 3261で定義されたマジッククッキーを含むブランチパラメーターを含まない場合、一致するトランザクションをチェックして、「受け入れられた」状態にあるかどうかを確認する必要があります。もしそうなら、ACKは、トランザクションステートマシンに吸収されるのではなく、トランザクションユーザーに直接渡す必要があります。これは、RFC 2543のクライアントからの要求に一意のブランチパラメーターが含まれていないため、これが必要であり、そのようなリクエストからトランザクションIDを計算するためのメカニズムは、招待とACKの両方で同じになります。
These changes impact requirements in several sections of RFC 3261. The exact effect on that text is detailed in Section 8. This section describes the details of the change, particularly the impact on the INVITE state machines, more succinctly to facilitate review and simplify implementation.
これらの変更は、RFC 3261のいくつかのセクションの要件に影響を与えます。このテキストに対する正確な影響については、セクション8で詳しく説明します。このセクションでは、このセクションでは、特に招待状態マシンへの影響について説明します。
To allow a SIP element to recognize retransmissions of an INVITE as retransmissions instead of new requests, a new state, "Accepted", is added to the INVITE server transaction state machine. A new timer, Timer L, is also added to ultimately allow the state machine to terminate. A server transaction in the "Proceeding" state will transition to the "Accepted" state when it issues a 2xx response and will remain in that state just long enough to absorb any retransmissions of the INVITE.
SIP要素が、新しいリクエストの代わりに再送信として招待の再送信を認識できるようにするために、新しい状態「Accepted」が招待サーバートランザクションステートマシンに追加されます。新しいタイマーであるタイマーLも追加され、最終的にステートマシンが終了するようにします。「手続き」状態でのサーバートランザクションは、2XX応答を発行すると「受け入れられた」状態に移行し、招待の再送信を吸収するのに十分な長さの状態にとどまります。
If the SIP element's TU (Transaction User) issues a 2xx response for this transaction while the state machine is in the "Proceeding" state, the state machine MUST transition to the "Accepted" state and set Timer L to 64*T1, where T1 is the round-trip time estimate defined in Section 17.1.1.1 of [RFC3261].
SIP要素のTU（トランザクションユーザー）がこのトランザクションの2XX応答を発行している場合、状態マシンが「進行中」状態にある場合、状態マシンは「受け入れられた」状態に移行し、タイマーLを64*T1に設定する必要があります。[RFC3261]のセクション17.1.1.1で定義されている往復時間推定値です。
While in the "Accepted" state, any retransmissions of the INVITE received will match this transaction state machine and will be absorbed by the machine without changing its state. These retransmissions are not passed onto the TU. RFC 3261 requires the TU to periodically retransmit the 2xx response until it receives an ACK. The server transaction MUST NOT generate 2xx retransmissions on its own. Any retransmission of the 2xx response passed from the TU to the transaction while in the "Accepted" state MUST be passed to the transport layer for transmission. Any ACKs received from the network while in the "Accepted" state MUST be passed directly to the TU and not absorbed.
「受け入れられた」状態では、受け取った招待の再送信はこのトランザクション状態マシンと一致し、状態を変更せずにマシンに吸収されます。これらの再送信はTUに渡されません。RFC 3261では、TUがACKを受信するまで2xx応答を定期的に再送信する必要があります。サーバートランザクションは、2xxの再送信を単独で生成してはなりません。「受け入れられている」状態では、TUからトランザクションに渡された2XX応答の再送信は、伝送のために輸送層に渡す必要があります。「受け入れられた」状態にある間にネットワークから受け取ったACKは、TUに直接渡され、吸収されない必要があります。
When Timer L fires and the state machine is in the "Accepted" state, the machine MUST transition to the "Terminated" state. Once the transaction is in the "Terminated" state, it MUST be destroyed immediately. Timer L reflects the amount of time the server transaction could receive 2xx responses for retransmission from the TU while it is waiting to receive an ACK.
タイマーLが発火し、状態マシンが「受け入れられた」状態にある場合、マシンは「終了した」状態に移行する必要があります。トランザクションが「終了」状態になったら、すぐに破壊する必要があります。タイマーLは、ACKを受信するのを待っている間に、サーバートランザクションがTUからの再送信のために2xx応答を受信できる時間を反映しています。
A server transaction MUST NOT discard transaction state based only on encountering a non-recoverable transport error when sending a response. Instead, the associated INVITE server transaction state machine MUST remain in its current state. (Timers will eventually cause it to transition to the "Terminated" state). This allows retransmissions of the INVITE to be absorbed instead of being processed as a new request.
サーバートランザクションは、応答を送信する際に再回復不可のトランスポートエラーに遭遇することにのみ遭遇することに基づいて、トランザクション状態を破棄してはなりません。代わりに、関連するInvite Server Transaction Stateマシンは、現在の状態にとどまる必要があります。（タイマーは最終的にそれを「終了した」状態に移行させます）。これにより、新しいリクエストとして処理される代わりに、招待の再送信を吸収することができます。
Figures 1 and 2 show the parts of the INVITE server state machine that have changed. The entire new INVITE server state machine is shown in Figure 5.
図1と2は、変更されたInvite Server Stateマシンの部分を示しています。新しいInvite Server Stateマシン全体を図5に示します。
BEFORE AFTER
ビフォアーアフター
+-----------+ +-----------+
| | | |
| Proceeding| | Proceeding|
| | | |
| | | |
| | | |
| | | |
+-----------+ +-----------+
|2xx from TU |2xx from TU
|send response |send response
+-------------->+ +------->+
| |
| |
| |
| | Transport
| INVITE | Error
| - | Inform TU
| +-----+ | +--+
| | | V | v
| | +------------+
| | | |<--+
| +->| Accepted | | ACK
| | |---+ to TU
| +------------+
| | ^ |
| +--+ | |
| | +-----+
| | 2xx from TU
| | send response
| |
| | Timer L fires
| | -
| |
| V
+-----------+ | +------------+
| | | | |
| Terminated|<-----------+ | Terminated |
| | | |
+-----------+ +------------+
Figure 1: Changes to the INVITE server transaction state machine when sending 2xx
図1：2xxを送信するときに招待サーバートランザクションステートマシンに変更
BEFORE AFTER
ビフォアーアフター
+-----------+ +------------+
| | | |
| Proceeding| | Proceeding | Transport Err.
| | | | Inform TU
| | Transport Err. | |----------+
| | Inform TU | | |
| |--------------->+ | |<---------+
+-----------+ | +------------+
|
|
|
|
| Transport Err.
+-----------+ | +-----------+ Inform TU
| | | | |---------+
| Completed | | | Completed | |
| | | | |<--------+
+-----------+ | +-----------+
| |
| |
+------------------>+
Transport Err.|
Inform TU |
|
|
|
|
|
|
|
|
|
+-----------+ |
| | |
| Terminated|<---------------+
| |
+-----------+
Figure 2: Changes to the INVITE server transaction state machine on encountering transport error
図2：輸送エラーの遭遇に関する招待サーバートランザクションステートマシンの変更
In order to correctly distinguish retransmissions of 2xx responses from stray 2xx responses, the INVITE client state machine is modified to not transition immediately to "Terminated" on receipt of a 2xx response. Instead, the machine will transition to a new "Accepted" state, and remain there just long enough, determined by a new timer M, to receive and pass to the TU any retransmissions of the 2xx response or any additional 2xx responses from other branches of a downstream fork of the matching request. If a 2xx response is received while the client INVITE state machine is in the "Calling" or "Proceeding" states, it MUST transition to the "Accepted" state, pass the 2xx response to the TU, and set Timer M to 64*T1. A 2xx response received while in the "Accepted" state MUST be passed to the TU and the machine remains in the "Accepted" state. The client transaction MUST NOT generate an ACK to any 2xx response on its own. The TU responsible for the transaction will generate the ACK.
2xx応答の再送信を迷った2xx応答と正しく区別するために、招待クライアントステートマシンは、2xx応答の受信時に「終了」するようにすぐに移行しないように変更されます。代わりに、マシンは新しい「受け入れられた」状態に移行し、2xx応答の再送信または他のブランチからの追加の2xx応答の再送信を受信して渡すために、新しいタイマーMによって決定された十分な長さにとどまります。マッチングリクエストのダウンストリームフォーク。クライアントがステートマシンを「呼び出し」または「進行」状態に招待しているときに2xxの応答が受信された場合、「受け入れられた」状態に移行し、2xx応答をTUに渡し、タイマーMを64*T1に設定する必要があります。。「受け入れられた」状態で受け取った2XX応答はTUに渡され、マシンは「受け入れられた」状態にとどまる必要があります。クライアントトランザクションは、自体で2xx応答に対するACKを生成してはなりません。トランザクションの原因となるTUがACKを生成します。
When Timer M fires and the state machine is in the "Accepted" state, the machine MUST transition to the "Terminated" state. Once the transaction is in the "Terminated" state, it MUST be destroyed immediately.
タイマーMが火災と状態マシンが「受け入れられた」状態にある場合、マシンは「終了した」状態に移行する必要があります。トランザクションが「終了」状態になったら、すぐに破壊する必要があります。
Any response received that does not match an existing client transaction state machine is simply dropped. (Implementations are, of course, free to log or do other implementation-specific things with such responses, but the implementer should be sure to consider the impact of large numbers of malicious stray responses.)
既存のクライアントトランザクションステートマシンと一致しない受信した応答は、単純に削除されます。（もちろん、実装は、そのような応答を使用して他の実装固有のことを自由に記録するか、他の実装固有のことを実行できますが、実装者は、多数の悪意のある浮遊応答の影響を必ず考慮する必要があります。）
Note that it is not necessary to preserve client transaction state upon the detection of unrecoverable transport errors. Existing requirements ensure the TU has been notified, and the new requirements in this document ensure that any received retransmitted response will be dropped since there will no longer be any matching transaction state.
回復不可能な輸送エラーの検出時に、クライアントトランザクション状態を保持する必要はないことに注意してください。既存の要件がTUに通知されることを保証し、このドキュメントの新しい要件は、一致するトランザクション状態がなくなるため、受信した再送信応答が削除されることを保証します。
Figure 3 shows the part of the INVITE client state machine that has changed. The entire new INVITE client state machine is shown in Figure 5.
図3は、変更された招待クライアントステートマシンの一部を示しています。新しい招待クライアントステートマシン全体を図5に示します。
+-----------+ +-----------+
| | | |
| Calling | | Calling |
| |----------->+ | |-----------+
+-----------+ 2xx | +-----------+ 2xx |
2xx to TU | 2xx to TU |
| |
| |
| |
| |
+-----------+ | +-----------+ |
| | | | | |
|Proceeding |----------->| |Proceeding |---------->|
| | 2xx | | | 2xx |
+-----------+ 2xx to TU | +-----------+ 2xx to TU |
| |
| |
| |
| V
| +-----------+
| | |
| | Accepted |
| +---| |
| 2xx | +-----------+
| 2xx to TU | ^ |
| | | |
| +-----+ |
| |
| +-----------------+
| | Timer M fires
| | -
| V
+-----------+ | +-----------+
| | | | |
| Terminated|<-----------+ | Terminated|
| | | |
+-----------+ +-----------+
Figure 3: Changes to the INVITE client transaction state machine
図3：招待クライアントトランザクションステートマシンの変更
This document changes the behavior of transaction-stateful proxies to not forward stray INVITE responses. When receiving any SIP response, a transaction-stateful proxy MUST compare the transaction identifier in that response against its existing transaction state machines. The proxy MUST NOT forward the response if there is no matching transaction state machine.
このドキュメントは、トランザクション状態のプロキシの動作を変更して、招待された応答を転送しないようにします。SIP応答を受信する場合、トランザクション状態のプロキシは、既存のトランザクション状態マシンに対してその応答のトランザクション識別子を比較する必要があります。一致するトランザクションステートマシンがない場合、プロキシは応答を転送してはなりません。
This section describes exactly the same changes as above, but shows exactly which text in RFC 3261 is affected. This document intentionally does not contain a Figure 4 or Figure 6 so that the labels for Figures 5 and 7 are identical to the labels of the figures they are replacing in RFC 3261.
このセクションでは、上記とまったく同じ変更について説明しますが、RFC 3261のどのテキストが影響を受けるかを正確に示しています。このドキュメントには意図的に図4または図6が含まれていないため、図5と7のラベルは、RFC 3261で置き換えられている数値のラベルと同一になります。
Section 13.3.1.4, paragraph 4, is replaced entirely by:
セクション13.3.1.4、パラグラフ4は、完全に置き換えられます。
Once the response has been constructed, it is passed to the INVITE server transaction. In order to ensure reliable end-to-end transport of the response, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response.
応答が構築されると、Invite Serverトランザクションに渡されます。応答の信頼できるエンドツーエンドの輸送を確保するために、ACKが到着するまで、応答を輸送に定期的に直接渡す必要があります。2XX応答は、T2秒にT1秒で始まり、T2秒に達するまで2倍になる間隔でトランスポートに渡されます（T1とT2がセクション17で定義されます）。応答再送信は、応答のACK要求が受信されたときに停止します。これは、応答を送信するために使用される輸送プロトコルとは無関係です。
Section 16.7, paragraphs 1 and 2, are replaced entirely by:
セクション16.7、パラグラフ1および2は、完全に置き換えられます。
When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If a transaction is found, the response is handed to the client transaction. If none is found, the element MUST NOT forward the response.
応答が要素によって受信されると、最初に応答に一致するクライアントトランザクション（セクション17.1.3）を見つけようとします。トランザクションが見つかった場合、応答はクライアントトランザクションに渡されます。何も見つかっていない場合、要素は応答を転送してはなりません。
Section 16.7, part 9, first paragraph. Replace this sentence:
セクション16.7、パート9、最初の段落。この文を置き換えます：
If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport.
サーバートランザクションが送信を処理するために使用できなくなった場合、要素はそれをサーバートランスポートに送信することにより、応答をステートルに転送する必要があります。
with
と
If the server transaction is no longer available to handle the transmission, the response is simply discarded.
サーバートランザクションが送信を処理するために使用できなくなった場合、応答は単に破棄されます。
Section 17.1.1.2. Replace paragraph 7 (starting "When in either") through the end of the section with:
セクション17.1.1.2。セクションの最後まで、次のように段落7（「どちらかで」開始します）を置き換えます。
When in either the "Calling" or "Proceeding" states, reception of a response with status code from 300-699 MUST cause the client transaction to transition to "Completed". The client transaction MUST pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3), and then pass the ACK to the transport layer for transmission. The ACK MUST be sent to the same address, port, and transport to which the original request was sent.
「呼び出し」または「手続き」状態のいずれかで、300-699のステータスコードを使用した応答の受信により、クライアントトランザクションが「完了」に移行する必要があります。クライアントトランザクションは、受信した応答をTUに合わせて渡す必要があり、クライアントトランザクションは、トランスポートが信頼できる場合でもACK要求を生成する必要があります（応答からACKを構築するためのガイドラインはセクション17.1.1.3に記載されています）。トランスミッションのための輸送層へのACK。ACKは、元のリクエストが送信された同じアドレス、ポート、およびトランスポートに送信する必要があります。
The client transaction MUST start Timer D when it enters the "Completed" state for any reason, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used. This is equal to Timer H in the INVITE server transaction, whose default is 64*T1, and is also equal to the time a UAS core will wait for an ACK once it sends a 2xx response. However, the client transaction does not know the value of T1 in use by the server transaction or any downstream UAS cores, so an absolute minimum of 32 s is used instead of basing Timer D on T1.
クライアントトランザクションは、何らかの理由で「完了した」状態に入るときにタイマーDを開始する必要があり、信頼性の低い輸送では少なくとも32秒、信頼できる輸送の値はゼロの値です。タイマーDは、信頼できないトランスポートが使用されている場合、サーバートランザクションが「完了した」状態にとどまることができる時間を反映しています。これは、招待サーバートランザクションのタイマーHに等しく、そのデフォルトは64*T1であり、2XX応答を送信するとUASコアがACKを待つ時間と等しくなります。ただし、クライアントトランザクションは、サーバートランザクションまたはダウンストリームUASコアで使用されているT1の値を知らないため、T1に基づいたタイマーDの代わりに、絶対最小32秒が使用されます。
Any retransmissions of a response with status code 300-699 that are received while in the "Completed" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU.
「完了」状態で受信されたステータスコード300-699を使用した応答の再送信は、ACKを再送信のために輸送層に再パスする必要がありますが、新しく受信した応答をTUに渡すべきではありません。。
A retransmission of the response is defined as any response that would match the same client transaction based on the rules of Section 17.1.3.
応答の再送信は、セクション17.1.3のルールに基づいて同じクライアントトランザクションに一致する応答として定義されます。
If Timer D fires while the client transaction is in the "Completed" state, the client transaction MUST move to the "Terminated" state.
クライアントトランザクションが「完了」状態にある間にタイマーDが発火する場合、クライアントトランザクションは「終了した」状態に移動する必要があります。
When a 2xx response is received while in either the "Calling" or "Proceeding" states, the client transaction MUST transition to the "Accepted" state, and Timer M MUST be started with a value of 64*T1. The 2xx response MUST be passed up to the TU. The client transaction MUST NOT generate an ACK to the 2xx response -- its handling is delegated to the TU. A UAC core will send an ACK to the 2xx response using a new transaction. A proxy core will always forward the 2xx response upstream.
「呼び出し」または「進行」状態のいずれかで2xxの応答が受信された場合、クライアントトランザクションは「受け入れられた」状態に移行する必要があり、タイマーMは64*T1の値で開始する必要があります。2XX応答はTUに渡す必要があります。クライアントトランザクションは、2XX応答に対してACKを生成してはなりません。その取り扱いはTUに委任されます。UACコアは、新しいトランザクションを使用して2xx応答にACKを送信します。プロキシコアは、常に上流の2xx応答を転送します。
The purpose of the "Accepted" state is to allow the client transaction to continue to exist to receive, and pass to the TU, any retransmissions of the 2xx response and any additional 2xx responses from other branches of the INVITE if it forked downstream. Timer M reflects the amount of time that the transaction user will wait for such messages.
「受け入れられた」状態の目的は、クライアントトランザクションが引き続き存在し、TUに存在し、2xx応答の再送信を渡すことを許可することです。タイマーMは、トランザクションユーザーがそのようなメッセージを待つ時間を反映しています。
Any 2xx responses that match this client transaction and that are received while in the "Accepted" state MUST be passed up to the TU. The client transaction MUST NOT generate an ACK to the 2xx response. The client transaction takes no further action.
このクライアントトランザクションに一致し、「受け入れられた」状態で受信される2xx応答は、TUに渡す必要があります。クライアントトランザクションは、2XX応答に対してACKを生成してはなりません。クライアントトランザクションはそれ以上のアクションを取りません。
If Timer M fires while the client transaction is in the "Accepted" state, the client transaction MUST move to the "Terminated" state.
クライアントトランザクションが「受け入れられた」状態にある間にタイマーMが発火する場合、クライアントトランザクションは「終了した」状態に移動する必要があります。
The client transaction MUST be destroyed the instant it enters the "Terminated" state.
クライアントトランザクションは、「終了した」状態に入る瞬間に破壊する必要があります。
Replace Figure 5 with:
図5を次のように置き換えます。
|INVITE from TU
Timer A fires |INVITE sent Timer B fires
Reset A, V or Transport Err.
INVITE sent +-----------+ inform TU
+---------| |--------------------------+
| | Calling | |
+-------->| |-----------+ |
300-699 +-----------+ 2xx | |
ACK sent | | 2xx to TU | |
resp. to TU | |1xx | |
+-----------------------------+ |1xx to TU | |
| | | |
| 1xx V | |
| 1xx to TU +-----------+ | |
| +---------| | | |
| | |Proceeding | | |
| +-------->| | | |
| +-----------+ 2xx | |
| 300-699 | | 2xx to TU | |
| ACK sent, +--------+ +---------------+ |
| resp. to TU| | |
| | | |
| V V |
| +-----------+ +----------+ |
+------------->| |Transport Err. | | |
| Completed |Inform TU | Accepted | |
+--| |-------+ | |-+ |
300-699 | +-----------+ | +----------+ | |
ACK sent| ^ | | | ^ | |
| | | | | | | |
+----+ | | | +-----+ |
|Timer D fires | Timer M fires| 2xx |
|- | - | 2xx to TU |
+--------+ | +-----------+ |
NOTE: V V V |
Transitions +------------+ |
are labeled | | |
with the event | Terminated |<-----------------------+
over the action | |
to take. +------------+
Figure 5: INVITE client transaction
図5：クライアントトランザクションを招待します
Section 17.2.1, paragraph 4, is replaced with:
セクション17.2.1、パラグラフ4は次のものに置き換えられます。
If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the "Accepted" state.
「進行中」状態で、TUがサーバートランザクションに対する2xx応答を渡す場合、サーバートランザクションはこの応答を輸送層に伝達層に渡す必要があります。サーバートランザクションによって再送信されません。2XX応答の再送信はTUによって処理されます。サーバートランザクションは、「受け入れられた」状態に移行する必要があります。
Replace Figure 7 with:
図7を次のように置き換えます。
|INVITE
|pass INV to TU
INVITE V send 100 if TU won't in 200 ms
send response+------------+
+--------| |--------+ 101-199 from TU
| | | | send response
+------->| |<-------+
| Proceeding |
| |--------+ Transport Err.
| | | Inform TU
| |<-------+
+------------+
300-699 from TU | |2xx from TU
send response | |send response
+--------------+ +------------+
| |
INVITE V Timer G fires |
send response +-----------+ send response |
+--------| |--------+ |
| | | | |
+------->| Completed |<-------+ INVITE | Transport Err.
| | - | Inform TU
+--------| |----+ +-----+ | +---+
| +-----------+ | ACK | | v | v
| ^ | | - | +------------+
| | | | | | |---+ ACK
+----------+ | | +->| Accepted | | to TU
Transport Err. | | | |<--+
Inform TU | V +------------+
| +-----------+ | ^ |
| | | | | |
| | Confirmed | | +-----+
| | | | 2xx from TU
Timer H fires | +-----------+ | send response
- | | |
| | Timer I fires |
| | - | Timer L fires
| V | -
| +------------+ |
| | |<----+
+------->| Terminated |
| |
+------------+
Figure 7: INVITE server transaction
図7：サーバートランザクションを招待します
In Section 17.2.1, replace the last paragraph (starting "Once the transaction") with:
セクション17.2.1では、最後の段落（「トランザクションの1つを開始」）を次のものに置き換えます。
The purpose of the "Accepted" state is to absorb retransmissions of an accepted INVITE request. Any such retransmissions are absorbed entirely within the server transaction. They are not passed up to the TU since any downstream UAS cores that accepted the request have taken responsibility for reliability and will already retransmit their 2xx responses if necessary.
「受け入れられた」状態の目的は、受け入れられた招待要求の再送信を吸収することです。このような再送信は、サーバートランザクション内で完全に吸収されます。リクエストを受け入れた下流のUASコアは、信頼性の責任を負い、必要に応じて2xxの応答をすでに再送信するため、TUに渡されません。
While in the "Accepted" state, if the TU passes a 2xx response, the server transaction MUST pass the response to the transport layer for transmission.
「受け入れられた」状態では、TUが2XX応答に合格した場合、サーバートランザクションは伝送のために輸送層への応答を渡す必要があります。
When the INVITE server transaction enters the "Accepted" state, Timer L MUST be set to fire in 64*T1 for all transports. This value matches both Timer B in the next upstream client state machine (the amount of time the previous hop will wait for a response when no provisionals have been sent) and the amount of time this (or any downstream) UAS core might be retransmitting the 2xx while waiting for an ACK. If an ACK is received while the INVITE server transaction is in the "Accepted" state, then the ACK must be passed up to the TU. If Timer L fires while the INVITE server transaction is in the "Accepted" state, the transaction MUST transition to the "Terminated" state.
Invite Serverトランザクションが「受け入れられた」状態に入る場合、すべてのトランスポートで64*T1でタイマーLを発射するように設定する必要があります。この値は、次のアップストリームクライアントステートマシンのタイマーBと一致します（暫定ホップが暫定的なものが送信されていない場合に応答を待つ時間）と、この（または下流）UASコアが再送信される可能性があるこの時間の時間ACKを待っている間、2xx。招待サーバートランザクションが「受け入れられた」状態にあるときにACKが受信された場合、ACKはTUに渡す必要があります。招待サーバートランザクションが「受け入れられた」状態にある間にタイマーLが発火する場合、トランザクションは「終了した」状態に移行する必要があります。
Once the transaction is in the "Terminated" state, it MUST be destroyed immediately.
トランザクションが「終了」状態になったら、すぐに破壊する必要があります。
In Section 17.2.4, replace the second paragraph with:
セクション17.2.4で、2番目の段落を次のものに置き換えます。
First, the procedures in [4] are followed, which attempt to deliver the response to a backup. If those should all fail, based on the definition of failure in [4], the server transaction SHOULD inform the TU that a failure has occurred, and MUST remain in the current state.
まず、[4]の手順に従います。これにより、バックアップへの応答が提供されます。[4]の障害の定義に基づいてすべてが失敗する必要がある場合、サーバートランザクションは、障害が発生したことをTUに通知し、現在の状態にとどまる必要があります。
In Section 18.1.2, replace the second paragraph with:
セクション18.1.2で、2番目の段落を次のものに置き換えます。
The client transport uses the matching procedures of Section 17.1.3 to attempt to match the response to an existing transaction. If there is a match, the response MUST be passed to that transaction. Otherwise, any element other than a stateless proxy MUST silently discard the response.
クライアントトランスポートは、セクション17.1.3のマッチング手順を使用して、既存のトランザクションへの応答を一致させようとします。一致がある場合、そのトランザクションに応答を渡す必要があります。それ以外の場合、ステートレスプロキシ以外の要素は、応答を静かに破棄する必要があります。
In Section 18.2.1, replace the last paragraph with:
セクション18.2.1で、最後の段落を次のものに置き換えます。
Next, the server transport attempts to match the request to a server transaction. It does so using the matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed to that transaction for processing. If no match is found, the request is passed to the core, which may decide to construct a new server transaction for that request.
次に、サーバートランスポートは、リクエストをサーバートランザクションに一致させようとします。セクション17.2.3で説明した一致するルールを使用して行います。一致するサーバートランザクションが見つかった場合、リクエストは処理のためにそのトランザクションに渡されます。一致が見つからない場合、リクエストはコアに渡され、その要求のために新しいサーバートランザクションを構築することを決定する場合があります。
Add to Table 4:
表4に追加：
Timer L 64*T1 Section 17.2.1 Wait time for accepted INVITE request retransmits
タイマーL 64*T1セクション17.2.1受け入れられた招待リクエスト再送信の待機時間
Timer M 64*T1 Section 17.1.1 Wait time for retransmission of 2xx to INVITE or additional 2xx from other branches of a forked INVITE
タイマーM 64*T1セクション17.1.1 2XXの再送信の待ち時間、フォークされた招待の他のブランチから招待または追加の2XX
IANA has updated the SIP Parameters: Method and Response Codes registry as follows:
IANAは、SIPパラメーターを更新しました：メソッドおよび応答コードレジストリは次のとおりです。
OLD:
年：
Methods Reference
------- ---------
INVITE [RFC3261]
NEW:
Methods Reference
------- ---------
INVITE [RFC3261][RFC6026]
This document makes two changes to the Session Initiation Protocol to address the error discussed in Section 3. It changes the behavior of both the client and server INVITE transaction state machines, and it changes the way "stray" responses (those that don't match any existing transaction) are handled at transaction-stateful elements.
このドキュメントは、セッション開始プロトコルに2つの変更を加えてセクション3で説明したエラーに対処します。クライアントとサーバーの両方の動作がトランザクションステートマシンを招待し、「迷い」応答（一致しないもの）を変更します。既存のトランザクション）は、トランザクション状態の要素で処理されます。
The changes to the state machines cause elements to hold onto each accepted INVITE transaction state 32 seconds longer than what was specified in RFC 3261. This will have a direct impact on the amount of work an attacker that is leveraging state exhaustion will have to exert against the system. However, this additional state is necessary to achieve correct operation. There is some discussion of avoiding state exhaustion and other denial-of-service attacks in RFC 3261, Section 26.3.2.4.
状態マシンの変更により、要素はRFC 3261で指定されたものよりも32秒長く受け入れられている各招待状のトランザクション状態を保持します。システム。ただし、正しい操作を達成するには、この追加の状態が必要です。RFC 3261、セクション26.3.2.4で、州の疲労やその他のサービス拒否攻撃を回避することについての議論があります。
RFC 3261 required SIP proxies to forward any stray 2xx class responses to an INVITE request upstream statelessly. As a result, conformant proxies can be forced to forward packets (that look sufficiently like SIP responses) to destinations of the sender's choosing. Section 3 discusses some of the malicious behavior this enables. This document reverses the stateless forwarding requirement, making it a violation of the specification to forward stray responses.
RFC 3261は、SIPプロキシを必要として、2xxクラスの迷惑な応答を招待状のリクエストにステートレレスに転送する必要がありました。その結果、コンフォーマントプロキシは、送信者の選択の目的地に対して（SIP応答のように十分に見える）パケット（SIP応答のように見えます）を強制することができます。セクション3では、これが可能にする悪意のある動作について説明します。このドキュメントは、ステータスの転送要件を逆転させ、迷った応答を転送するための仕様に違反しています。
RFC 3261 defines a "stateless proxy", which forwards requests and responses without creating or maintaining any transaction state. The requirements introduced in this document do not change the behavior of these elements in any way. Stateless proxies are inherently vulnerable to the abuses discussed in Section 3. One way operators might mitigate this vulnerability is to carefully control which peer elements can present traffic to a given stateless proxy.
RFC 3261は、トランザクション状態を作成または維持せずにリクエストと応答を転送する「ステートレスプロキシ」を定義します。このドキュメントで導入された要件は、これらの要素の動作を決して変更しません。ステートレスプロキシは、セクション3で説明した虐待に対して本質的に脆弱です。この脆弱性を軽減する1つの方法は、特定のステートレスプロキシにトラフィックを提示できるピア要素を慎重に制御することです。
The changes introduced by this document are backward-compatible. Transaction behavior will be no less correct, and possibly more correct, when only one peer in a transaction implements these changes. Except for the considerations mentioned earlier in this section, introducing elements implementing these changes into deployments with RFC 3261 implementations adds no additional security concerns.
このドキュメントによって導入された変更は、後方互換性があります。トランザクションの動作は、トランザクションのピアだけがこれらの変更を実装する場合、それほど正しくなく、おそらくより正確ではありません。このセクションで前述した考慮事項を除き、RFC 3261の実装でこれらの変更を展開する要素を導入すると、追加のセキュリティ上の懸念は追加されません。
Pekka Pessi reported the improper handling of INVITE retransmissions. Brett Tate performed a careful review uncovering the need for the "Accepted" state and Timer M in the client transaction state machine. Jan Kolomaznik noticed that a server transaction should let a TU know about transport errors when it attempts to send a 2xx class response. Michael Procter corrected several nits.
Pekka Pessiは、招待状の再送信の不適切な取り扱いを報告しました。Brett Tateは、クライアントトランザクション状態マシンで「受け入れられた」状態とタイマーMの必要性を発見した慎重なレビューを実行しました。Jan Kolomaznikは、サーバートランザクションが2xxクラスの応答を送信しようとするときにTUに輸送エラーを知らせる必要があることに気付きました。マイケル・プロクターはいくつかのnitを修正しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
Authors' Addresses
著者のアドレス
Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75252 USA
ロバートスパークステケレック17210キャンベルロードスイート250ダラス、テキサス75252 USA
EMail: RjS@nostrum.com
Theo Zourzouvillys Skype 3rd Floor 8000 Marina Blvd Brisbane, California 84005 US
Theo Zourzouvillys Skype 3rd Floor 8000 Marina Blvd Brisbane、California 84005 US
EMail: theo@crazygreek.co.uk