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
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.
このドキュメントは、規範的にアップデートRFC 3261、セッション開始プロトコル（SIP）、INVITEリクエストする成功（2xxのクラス）応答の指定された処理にエラーに対処します。 RFC 3261、以下の要素が正確に新しい、関連付けられていない要求としての要求の再送信を誤認します。補正は、INVITEトランザクション状態マシンを変更する必要があります。補正は、既存のトランザクションに一致させることができない応答は、セキュリティ上のリスクに対処するための処理方法を変更します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）に不可欠な補正を記述する。変更は、新しい要求として扱われるINVITEの再送信につながるINVITE要求するの2xxクラス応答の処理にエラーに対処し、浮遊INVITE応答を転送禁止します。
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におけるINVITE方法の1つの用途は、新しいセッションを確立することです。これらの「初期」のINVITEは仲介でforkして、そして複数の受信エンドポイントは、要求を受け入れることを選択することもできます。 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]で要件の二組は、複数の2xx応答が依頼者によって正しく処理できるようにするために一緒に働きます。まず、すべての要素は、直ちにを破壊するために必要とされるのマッチングの2xxクラスの応答を転送する時に、クライアントのトランザクション状態をINVITE。この要件は、両方のUA（ユーザエージェント）とプロキシ（プロキシがその「UAコア」に応答転送し、上流のユーザエージェントでトランザクション層応答を転送する）に適用されます。第二に、すべてのプロキシは、既存のトランザクションとも呼ばれる浮遊応答と一致しないの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.
動作を指定するこの技術は、正しい動作を指定するための簡単な方法として、クライアントトランザクションのステート・マシンをINVITE調整の上に選ばれました。
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.
時間が経つにつれて、実装経験は、既存のテキストがエラーである証明されました。サーバートランザクションを持つ任意の要素（例えば、INVITEの経路内のプロキシ）はそのトランザクションの状態を削除すると、INVITEの任意の再送信は、潜在的に、元とは異なる場所に転送され、新しいリクエストとして扱われます。フィールド内の多くの実装では、このエラーを回避するために彼らのトランザクションロジックに独自の調整を行ってきました。
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]は、クライアントのトランザクションに応答を送信している間であれば、回復不可能な転送エラーがトランザクションは「終端」状態にすぐに移行していること、遭遇されている必要があります。これは、このようなエラーではなく、再送信として吸収されているの新しい要求として処理されるように遭遇した後に受信した任意の再送信されたINVITEリクエストになります。
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]、状態を追加し、INVITEクライアントトランザクションが複数の2xx応答を受け取るために所定の位置に残るようINVITEクライアント・ステート・マシンの遷移を変更します。それは2xx応答が送られた後、INVITEの再送を吸収するために、INVITEサーバーステートマシンの状態を追加します。これは、応答を送信する際に、回復不可能な転送エラーが発生した後に、INVITE要求の再送信を吸収するために、INVITEサーバーステートマシンで状態遷移を変更します。また、3261が必要とするRFC要求（だけでなく、2xx応答）を、INVITEする浮遊応答を転送禁止します。
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]に厳密に準拠した実装は、新しい要求として再送信された初期のINVITEリクエストを処理します。プロキシは、オリジナルとは異なる場所にそれらを転送することができます。プロキシは、バルクトラフィックの匿名化フォワーダとして使用することができます。実装はエラーで応答結果を送信しようとした後、新たな要求として任意の再送信されたINVITEリクエストを処理します。
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.
INVITEトランザクションへの2xxを送信または受信要素は、任意のマッチングがトランザクション状態をINVITE破壊してはなりません。この状態は、要求及び従う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.
INVITE要求に対する応答を送信しようとしたときに、回復不可能な転送エラーが発生した要素は、すぐに関連するINVITEサーバートランザクションの状態を破壊してはなりません。この状態は、要求の再送信の適正な処理を確保する必要があります。
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.
既存のサーバーのトランザクションを招待しているが、RFC 3261で定義されたマジッククッキーを含む分岐パラメータが含まれていないと一致したACKを受信すると、一致するトランザクションは、それが「受け入れられた」状態にあるかどうかを確認するためにチェックしなければなりません。そうである場合、ACKは、トランザクション・ユーザーに直接渡さなければならない代わりに、トランザクション・ステート・マシンによって吸収されます。 RFCからの要求2543のクライアントは独自の分岐パラメータは含まれません、そして、そのような要求からトランザクションIDを計算するためのメカニズムはINVITEと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節で詳述されるこのセクションでは、見直しを容易にし、実装を簡素化するために、より簡潔に、INVITEステート・マシン上で特に影響、変更の詳細を説明します。
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要素ではなく、新しい要求を再送信すると、INVITEの再送を認識できるようにするには、新しい状態、「受理」は、INVITEサーバートランザクションのステートマシンに追加されます。新しいタイマー、タイマーLは、また、最終的にステートマシンを終了できるようにするために追加されます。それは2xx応答を発行し、ちょうど十分な長INVITEのいずれかの再送を吸収するために、その状態のままになりますと、「Proceeding」ステートにあるサーバートランザクションは「受け入れられた」状態に移行します。
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].
ステートマシンは「Proceeding」ステートにある間、SIP要素のTU（トランザクションユーザー）がこのトランザクションの2xx応答を発行した場合、ステートマシンは64 * T1、T1に「受理」状態に移行し、タイマーLを設定しなければなりません[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.
「受理」状態の間に、INVITE受信のいずれかの再送信は、このトランザクション・ステート・マシンにマッチしますし、その状態を変更することなく、マシンによって吸収されることになります。これらの再送はTUに渡されていません。 RFC 3261は、ACKを受信するまで、定期的に2xx応答を再送するTUが必要です。サーバートランザクションは、独自に2xxの再送を発生させてはいけません。 「承認」状態で送信するためのトランスポート層に渡さなければならないがトランザクションにTUから渡された2xx応答の任意の再送。 「受理」状態のTUに直接渡され、吸収されないする必要がありますが、任意のACKがネットワークから受信しました。
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サーバートランザクションのステートマシンは、現在の状態のままでなければなりません。 （タイマーは、最終的には「終端」状態に遷移します）。これは、INVITEの再送信ではなく、新たな要求として処理されているのを吸収することができます。
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サーバ状態機械の部品を示します。全体の新しいINVITEサーバー・ステート・マシンを図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：INVITEサーバートランザクションのステートマシンへの変更の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：転送エラーに遭遇した上INVITEサーバートランザクションのステートマシンへの変更
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応答の再送信を区別するために、INVITEクライアントステートマシンは、2xx応答の受信時に「終端」にすぐに移行しないように修正されます。代わりに、マシンは新しい「受理」状態に移行します、そしてそこには、2xx応答のいずれかの再送信や他のブランチからの任意の追加の2xx応答を受信してTUに渡し、新しいタイマーMによって決まる、ちょうど十分な長さのままマッチング要求の下流フォーク。クライアントは、状態マシンが「呼び出し」または「進み」状態にあるINVITEながら2xx応答を受信した場合、それは64 * T1にタイマMを、「承認済み」状態に遷移TUに2xx応答を渡し、設定しなければなりません。 「承認」状態にある間に受信された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は、変更されたINVITEクライアントステートマシンの一部を示しています。全体の新しいINVITEクライアントステートマシンを図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：INVITEクライアントトランザクションのステートマシンへの変更
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.
この文書では、浮遊INVITE応答を転送しないようにトランザクションステートフルプロキシの動作を変更します。任意の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にそのテキストを正確に示しています。図5および図7のラベルは、それらがRFC 3261で交換する数字のラベルと同一であるように、このドキュメントは、意図的に、図4または図6を含みません。
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サーバートランザクションに渡されます。応答の信頼できるエンドツーエンドの輸送を確保するためには、ACKが到着するまで、定期的に輸送に直接応答を渡す必要があります。 2xx応答は、T1秒で開始し、T2秒（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を構築するためのガイドラインは、セクション17.1.1.3に記載されている）トランスポートが信頼性がある場合でも、ACK要求を生成して、合格しなければなりません送信用のトランスポート層への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.
それが何らかの理由で、「完了」状態になったとき、クライアントトランザクションは信頼性の低いトランスポートのために少なくとも32秒の値、および信頼性の高いトランスポートの0秒の値で、タイマーDを起動する必要があります。タイマーDは、信頼性のないトランスポートが使用されている場合、サーバートランザクションは「完了」状態のままにできる時間の量を反映しています。これは、そのデフォルト64 * T1であり、またそれは2xx応答を送信したら、UASコアはACKを待つ時間に等しいINVITEサーバートランザクションにタイマーHに等しいです。しかし、クライアントのトランザクションので32秒の絶対的な最小値ではなくT1にタイマDを基づかのに使用される、サーバートランザクションが使用中のT1の値又は任意の下流UASコアを知りません。
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.
「完成した」状態でACKが再送のためのトランスポート層に再渡すことはなく、新たに受信した応答はTUに渡されてはならない原因となる必要がありますが受信されたステータスコード300から699と応答のいずれかの再送信。
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応答とそれが下流フォーク場合INVITEの他の枝からの追加の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.
「受理」状態のTUに渡されなければならない一方で、このクライアントトランザクションにマッチし、任意の2xx応答が受信されています。クライアントトランザクションは、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：クライアントトランザクションをINVITE
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.
「Proceeding」ステートに、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：サーバーのINVITEトランザクション
In Section 17.2.1, replace the last paragraph (starting "Once the transaction") with:
セクション17.2.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.
「受理」状態の目的は、受け入れられたINVITEリクエストの再送を吸収することです。そのような任意の再送信は、サーバーのトランザクション内に完全に吸収されています。彼らは要求を受け入れた任意の下流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サーバートランザクションが「受理」状態になると、タイマーLは、すべてのトランスポートのための64 * T1で起動するように設定しなければなりません。この値は、両方のタイマ次の上流のクライアントステートマシンでB（前のホップがないprovisionalsが送信されていない応答を待機する時間の量）と時間この量（または下流）UASコアが再送信されるかもしれないと一致します2XXはACKを待っている間に。 INVITEサーバートランザクションは「受け入れられた」状態にあるときにACKが受信された場合、ACKはTUに渡されなければなりません。 INVITEサーバートランザクションは「受け入れられた」状態にあるときにタイマー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では、第二段落をと交換してください：
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項では、第二段落をと交換してください：
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
受け入れられたINVITEリクエストの再送信のためのタイマー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のセクションフォークINVITEの他のブランチからのINVITEまたは追加の2xxするの2xxの再送のため17.1.1待機時間
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.
この文書では、それは、トランザクション・ステート・マシンをINVITEクライアントとサーバーの両方の動作を変更する第3節で述べたエラーに対処するために、セッション開始プロトコルには、2つの変更を行い、それが道「迷」回答（一致しないものを変更します既存のトランザクション）は、トランザクションのステートフル要素で処理されます。
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秒長いトランザクションの状態をINVITE受け入れシステム。しかし、この追加の状態が正しい動作を達成するために必要です。 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は、上流ステートレスINVITE要求への浮遊の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節の一つの方法事業者で議論虐待にさらされやすいです。
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.
ペッカPessiは、INVITE再送の不適切な取り扱いを報告しました。ブレット・テイトは、クライアント・トランザクション・ステート・マシンの「受け入れられた」状態とタイマーMの必要性を暴く慎重に検討を行いました。ヤンKolomaznikは、サーバートランザクションは、それがの2xxクラスの応答を送信しようとしたときにTUは、転送エラーを知らせる必要があることに気づきました。マイケル・プロクターは、いくつかのニットを修正しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
Authors' Addresses
著者のアドレス
Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75252 USA
ロバート・スパークスTekelec 17210キャンベル道スイート250、ダラス、テキサス州75252 USA
EMail: RjS@nostrum.com
メールアドレス：RjS@nostrum.com
Theo Zourzouvillys Skype 3rd Floor 8000 Marina Blvd Brisbane, California 84005 US
テオZourzouvillysスカイプ3階8000マリーナブルバードブリスベン、カリフォルニア州84005米国
EMail: theo@crazygreek.co.uk
メールアドレス：theo@crazygreek.co.uk