[要約] RFC 4320は、SIPの非INVITEトランザクションに関連する問題を解決するためのアクションを提案しています。その目的は、SIPの非INVITEトランザクションの信頼性とパフォーマンスを向上させることです。
Network Working Group R. Sparks
Request for Comments: 4320 Estacado Systems
Updates: 3261 January 2006
Category: Standards Track
Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
セッション開始プロトコル（SIP）非インバイトトランザクションで特定された問題に対処するアクション
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261.
このドキュメントでは、SIP非インバイトトランザクションで特定された問題に対処するために、セッション開始プロトコル（SIP）の変更について説明します。これらの変更は、非インバイトトランザクションに固有の人種状態を失うメッセージの可能性を減らし、役に立たないネットワークトラフィックを減らします。また、要素が応答を停止したときに、SIPネットワークの堅牢性を向上させます。これらの変更RFC 3261で定義された動作を更新します。
Table of Contents
目次
1. Introduction ....................................................2
2. Improving the Situation When Responses Are Only Delayed .........2
2.1. Action 1: Make the best use of provisional responses .......2
2.2. Action 2: Remove the useless late-response storm ...........3
3. Improving the Situation When an Element Is Not Going to
Respond .........................................................4
4. Normative Updates to RFC 3261 ...................................4
4.1. Action 1 ...................................................4
4.2. Action 2 ...................................................5
5. Security Considerations .........................................5
6. Contributors ....................................................5
7. Normative References ............................................6
There are a number of unpleasant edge conditions created by the SIP non-INVITE transaction (NIT) model's fixed duration. The negative aspects of some of these are exacerbated by the effect that provisional responses have on the non-INVITE transaction state machines. These problems are documented in [3]. In summary:
SIP非インバイトトランザクション（NIT）モデルの固定期間によって作成された不快なエッジ条件が多数あります。これらのいくつかのネガティブな側面は、暫定的な反応が非インバイトトランザクション状態マシンに与える影響によって悪化します。これらの問題は[3]に文書化されています。要約すれば：
A non-INVITE transaction must complete immediately or risk losing a race
非インバイトの取引はすぐに完了するか、レースを失う危険を冒す必要があります
Losing the race will cause the requester to stop sending traffic to the responder (the responder will be temporarily blacklisted)
レースを失うと、リクエスターはレスポンダーへのトラフィックの送信を停止します（レスポンダーは一時的にブラックリストに登録されます）
Provisional responses can delay recovery from lost final responses
暫定的な回答は、失われた最終応答からの回復を遅らせる可能性があります
The 408 response is useless for the non-INVITE transaction
408の応答は、非インバイトトランザクションでは役に立たない
As non-INVITE transactions through N proxies time-out, there can be an O(N^2) storm of the useless 408 responses
nプロキシタイムアウトを介した非インバイトトランザクションとして、役に立たない408応答のo（n^2）ストームが発生する可能性があります
This document specifies updates to RFC 3261 [1] to improve the behavior of SIP elements when these edge conditions arise.
このドキュメントは、RFC 3261 [1]の更新を指定して、これらのエッジ条件が発生したときにSIP要素の動作を改善します。
There are two goals to achieve when we constrain the problem to those cases where all elements are ultimately responsive and networks ultimately deliver messages:
すべての要素が最終的にレスポンシブであり、最終的にネットワークがメッセージを配信する場合に問題を制約するときに達成すべき2つの目標があります。
o Reduce the probability of losing the race, preferably to the point that it is negligible
o レースを失う可能性を減らし、できればそれが無視できるようになるまで減少します
o Reduce or eliminate useless messaging
o 役に立たないメッセージングを削減または排除します
o Disallow non-100 provisionals to non-INVITE requests
o 非インバイト要求に対する非100の暫定的な暫定を禁止します
o Disallow 100 Trying to non-INVITE requests before Timer E reaches T2 (for UDP hops)
o タイマーEがT2に到達する前に、非インバイトの要求を試みることを許可しません（UDPホップ用）
o Allow 100 Trying after Timer E reaches T2 (for UDP hops)
o タイマーEがT2に到達した後に100を試してみてください（UDPホップ用）
o Allow 100 Trying for hops over reliable transports Since non-INVITE transactions must complete rapidly ([3]), any information beyond "I'm here" (which can be provided by a 100 Trying) can be just as usefully delayed to the final response. Sending non-100 provisionals wastes bandwidth.
o 非インバイトトランザクションが迅速に完了する必要があるため（[3]）、「I'm Here」（100試行で提供できる）を超える情報は、最終まで有用に遅れる可能性があるため、信頼できる輸送を100回試行することを許可します。応答。100以外の暫定廃棄物の帯域幅を送信します。
As shown in [3], sending any provisional response inside a NIT before Timer E reaches T2 damages recovery from failure of an unreliable transport.
[3]に示すように、タイマーEがT2の損害に達する前に、NIT内に暫定的な応答を送信して、信頼できない輸送の障害からの回復に達します。
Without a provisional, a late final response is the same as no response at all and will likely result in blacklisting the late-responding element ([3]). If an element is delaying its final response at all, sending a 100 Trying after Timer E reaches T2 prevents this blacklisting without damaging recovery from unreliable transport failure.
暫定的なものがなければ、最終的な最終応答はまったく反応とまったく同じであり、後期回答要素をブラックリストに登録する可能性があります（[3]）。要素が最終応答をまったく遅らせている場合、タイマーEがT2に達した後、100の試行を送信して、信頼できない輸送障害からの回復を損なうことなくこのブラックリストを妨げます。
Blacklisting on a late response occurs even over reliable transports. Thus, if an element processing a request received over a reliable transport is delaying its final response at all, sending a 100 Trying well in advance of the timeout will prevent blacklisting. Sending a 100 Trying immediately will not harm the transaction as it would over UDP, but a policy of always sending such a message results in unnecessary traffic. A policy of sending a 100 Trying after the period of time in which Timer E reaches T2 had this been a UDP hop is one reasonable compromise.
遅い応答のブラックリストは、信頼できる輸送でも発生します。したがって、信頼性の高い輸送で受信した要求を処理する要素が最終的な応答をまったく遅らせている場合、タイムアウトのかなり前に100の試行を送信すると、ブラックリストが妨げられます。すぐに100の試行を送信しても、UDPを超えるようにトランザクションに害を及ぼすことはありませんが、常にそのようなメッセージを送信するというポリシーにより、不必要なトラフィックが生じます。タイマーEがT2に到達した期間後に100を送信するポリシーは、これがUDPホップであったため、1つの合理的な妥協です。
o Disallow 408 to non-INVITE requests
o 408を非インバイトリクエストに禁止します
o Absorb stray non-INVITE responses at proxies
o プロキシでの野良気性の非インバイト応答を吸収します
A 408 to non-INVITE will always arrive too late to be useful ([3]), The client already has full knowledge of the timeout. The only information this message would convey is whether or not the server believed the transaction timed out. However, with the current design of the NIT, a client cannot do anything with this knowledge. Thus, the 408 is simply wasting network resources and contributes to the response bombardment illustrated in [3].
408から非インバイトが到着するには常に遅すぎて役立つには届きません（[3]）、クライアントはすでにタイムアウトについて完全な知識を持っています。このメッセージが伝える唯一の情報は、サーバーがトランザクションがタイムアウトすると信じているかどうかです。ただし、NITの現在の設計により、クライアントはこの知識で何もできません。したがって、408は単にネットワークリソースを無駄にしており、[3]に示されている応答爆撃に貢献しています。
Late non-INVITE responses by definition arrive after the client transaction's Timer F has fired and the client transaction has entered the Terminated state. Thus, these responses cannot be distinguished from strays. Changing the protocol behavior to prohibit forwarding non-INVITE stray responses stops the late-response storm. It also improves the proxy's defenses against malicious users counting on the RFC 3261 requirement to forward such strays.
定義による後期非インバイト応答は、クライアントトランザクションのタイマーFが解雇され、クライアントトランザクションが終了した状態に入った後に到着します。したがって、これらの応答は迷走と区別することはできません。プロトコルの動作を変更して転送を禁止して、非インバイトの迷路応答を禁止すると、遅い反応の嵐が止まります。また、そのような迷子を転送するためにRFC 3261要件を頼りにする悪意のあるユーザーに対するプロキシの防御を改善します。
When we expand the scope of the problem to also deal with element or network failure, we have more goals to achieve:
問題の範囲を拡大して、要素またはネットワークの障害にも対処するとき、達成すべき目標が増えます。
o Identifying when an element is non-responsive
o 要素が反応しない場合を識別します
o Minimizing or eliminating falsely identifying responsive elements as non-responsive
o 応答性のない要素を非応答性として誤って識別することを最小化または排除します
o Avoiding non-responsive elements with future requests
o 将来のリクエストで非応答要素を回避します
Action 1 helps with the first two goals, dramatically improving an element's ability to distinguish between failure and delayed response from the next downstream element. Some response, either provisional or final, will almost certainly be received before the transaction times out. So, an element can more safely assume that no response at all indicates that the peer is not available and follow the existing requirements in [1] and [2] for that case.
アクション1は、最初の2つの目標に役立ち、障害と遅延応答を次のダウンストリーム要素と区別する要素の能力を劇的に改善します。暫定または最終のいずれかの応答は、トランザクションが外出する前にほぼ確実に受信されます。したがって、要素は、ピアが利用できないことをまったく示していないことを示し、その場合の[1]および[2]の既存の要件に従うことをより安全に仮定することができます。
Achieving the third goal requires more aggressive changes to the protocol. As noted in [3], future non-INVITE transactions are likely to fail again unless the implementation takes steps beyond what is defined in [1] and [2] to remember non-responsive destinations between transactions. Standardizing these extra steps is left to future work.
3番目の目標を達成するには、プロトコルをより積極的に変更する必要があります。[3]で述べたように、将来の非インバイトトランザクションは、実装が[1]および[2]で定義されているものを超えて、トランザクション間の非応答的な目的地を覚えていない場合を除き、再び失敗する可能性があります。これらの余分なステップを標準化することは、将来の仕事に任されています。
An SIP element MUST NOT send any provisional response with a Status-Code other than 100 to a non-INVITE request.
SIP要素は、100以外のステータスコードを使用して暫定的な応答を非インバイトリクエストに送信してはなりません。
An SIP element MUST NOT respond to a non-INVITE request with a Status-Code of 100 over any unreliable transport, such as UDP, before the amount of time it takes a client transaction's Timer E to be reset to T2.
SIP要素は、クライアントトランザクションのタイマーEがT2にリセットされる時間の前に、UDPなどの信頼性の低いトランスポートを介して100のステータスコードを使用して、非インバイト要求に応答してはなりません。
An SIP element MAY respond to a non-INVITE request with a Status-Code of 100 over a reliable transport at any time.
SIP要素は、いつでも信頼性の高い輸送を介して100のステータスコードで非インバイト要求に応答する場合があります。
Without regard to transport, an SIP element MUST respond to a non-INVITE request with a Status-Code of 100 if it has not otherwise responded after the amount of time it takes a client transaction's Timer E to be reset to T2.
輸送に関係なく、SIP要素は、クライアントトランザクションのタイマーEがT2にリセットする時間がかかった後に応答しなかった場合、100のステータスコードで非インバイト要求に応答する必要があります。
A transaction-stateful SIP element MUST NOT send a response with Status-Code of 408 to a non-INVITE request. As a consequence, an element that cannot respond before the transaction expires will not send a final response at all.
トランザクション状態のSIP要素は、408のステータスコードを含む応答を非インバイトリクエストに送信してはなりません。結果として、トランザクションの有効期限が切れる前に応答できない要素は、最終的な応答をまったく送信しません。
A transaction-stateful SIP proxy MUST NOT send any response to a non-INVITE request unless it has a matching server transaction that is not in the Terminated state. As a consequence, this proxy will not forward any "late" non-INVITE responses.
トランザクション状態のSIPプロキシは、終了状態にないマッチングサーバートランザクションがない限り、非インバイトリクエストに応答を送信してはなりません。結果として、このプロキシは「遅い」非インバイト応答を転送しません。
This document makes a number of small changes to the core SIP specification [1] to improve the robustness of SIP non-INVITE transactions. Many of these actions also prevent flooding and denial-of-service attacks.
このドキュメントは、SIP非インバイトトランザクションの堅牢性を改善するために、コアSIP仕様[1]にいくつかの小さな変更を加えます。これらのアクションの多くは、洪水やサービス拒否攻撃も妨げています。
One change prohibits proxies and user agents from sending 408 responses to non-INVITE transactions. Without this change, proxies automatically generate a storm of useless responses as described in [3]. An attacker could capitalize on this by enticing user agents to send non-INVITE requests to a black hole (through social engineering or DNS poisoning) or by selectively dropping responses.
1つの変更により、プロキシとユーザーエージェントは、非インバイトトランザクションに対する408の応答を送信することを禁止しています。この変更がなければ、プロキシは[3]で説明されているように、役に立たない応答の嵐を自動的に生成します。攻撃者は、ユーザーエージェントに非インバイトリクエストをブラックホールに（ソーシャルエンジニアリングまたはDNS中毒を通じて）送信するか、選択的に応答を削除することで、これを活用できます。
Another change prohibits proxies from forwarding late responses. Without this change, an attacker could easily forge messages that appear to be late responses. All proxies compliant with RFC 3261 are required to forward these responses, wasting bandwidth and CPU and potentially overwhelming target user agents (especially those with low-speed connections).
別の変更により、プロキシは遅い応答を転送することを禁止しています。この変更がなければ、攻撃者は遅い応答のように見えるメッセージを簡単に偽造できます。RFC 3261に準拠したすべてのプロキシは、これらの応答を転送し、帯域幅とCPUを無駄にし、潜在的に圧倒的なターゲットユーザーエージェント（特に低速接続のあるもの）を転送する必要があります。
The remainder of these changes do not affect the security of the SIP protocol.
これらの変更の残りの部分は、SIPプロトコルのセキュリティに影響しません。
Rohan Mahy provided the Security Considerations section.
Rohan Mahyは、セキュリティ上の考慮事項セクションを提供しました。
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[3] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, January 2006.
[3] Sparks、R。、「セッション開始プロトコル（SIP）非インバイトトランザクションに関連する問題」、RFC 4321、2006年1月。
Author's Address
著者の連絡先
Robert J. Sparks Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252-4203
ロバートJ.スパークスエスタカドシステム17210キャンベルロードスイート250ダラス、テキサス75252-4203
EMail: rjsparks@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。