[要約] RFC 5393は、SIPフォーキングプロキシにおける増幅脆弱性に対処するためのガイドラインです。目的は、この脆弱性を理解し、対策を講じることです。
Network Working Group R. Sparks, Ed.
Request for Comments: 5393 Tekelec
Updates: 3261 S. Lawrence
Category: Standards Track Nortel Networks, Inc.
A. Hawrylyshen
Ditech Networks Inc.
B. Campen
Tekelec
December 2008
Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
セッション開始プロトコル（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) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.
このドキュメントは、SIPプロキシの動作で特定されたセキュリティの脆弱性に対処するために、セッション開始プロトコル（SIP）であるRFC 3261を規範的に更新します。この脆弱性により、SIPネットワークに対する攻撃が可能になり、少数の合法的で許可されたSIPリクエストが大量のプロキシからプロキシへのトラフィックを刺激する可能性があります。
This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request.
このドキュメントは、リクエストをフォークするときに、SIPプロキシのループ検出要件を強化します（つまり、複数の宛先にリクエストを転送します）。また、実装に必要なループ検出アルゴリズムの説明を修正および明確にします。さらに、このドキュメントは、特定の要求に対して追求された同時ブランチの数を制限するための最大ブレッドメカニズムを定義します。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Definitions .....................................3
3. Vulnerability: Leveraging Forking to Flood a Network ............3
4. Updates to RFC 3261 .............................................7
4.1. Strengthening the Requirement to Perform Loop Detection ....7
4.2. Correcting and Clarifying the RFC 3261
Loop-Detection Algorithm ...................................7
4.2.1. Update to Section 16.6 ..............................7
4.2.2. Update to Section 16.3 ..............................8
4.2.3. Impact of Loop Detection on Overall Network
Performance .........................................9
4.2.4. Note to Implementers ................................9
5. Max-Breadth ....................................................10
5.1. Overview ..................................................10
5.2. Examples ..................................................11
5.3. Formal Mechanism ..........................................12
5.3.1. Max-Breadth Header Field ...........................12
5.3.2. Terminology ........................................13
5.3.3. Proxy Behavior .....................................13
5.3.3.1. Reusing Max-Breadth .......................14
5.3.4. UAC Behavior .......................................14
5.3.5. UAS Behavior .......................................14
5.4. Implementer Notes .........................................14
5.4.1. Treatment of CANCEL ................................14
5.4.2. Reclamation of Max-Breadth on 2xx Responses ........14
5.4.3. Max-Breadth and Automaton UAs ......................14
5.5. Parallel and Sequential Forking ...........................15
5.6. Max-Breadth Split Weight Selection ........................15
5.7. Max-Breadth's Effect on Forking-Based
Amplification Attacks .....................................15
5.8. Max-Breadth Header Field ABNF Definition ..................16
6. IANA Considerations ............................................16
6.1. Max-Breadth Header Field ..................................16
6.2. 440 Max-Breadth Exceeded Response .........................16
7. Security Considerations ........................................16
7.1. Alternate Solutions That Were Considered and Rejected .....17
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................19
Interoperability testing uncovered a vulnerability in the behavior of forking SIP proxies as defined in [RFC3261]. This vulnerability can be leveraged to cause a small number of valid SIP requests to generate an extremely large number of proxy-to-proxy messages. A version of this attack demonstrates fewer than ten messages stimulating potentially 2^71 messages.
相互運用性テストは、[RFC3261]で定義されているように、SIPプロキシのフォーキングの動作における脆弱性を明らかにしました。この脆弱性を活用して、少数の有効なSIPリクエストを引き起こし、非常に多数のプロキシからプロキシへのメッセージを生成できます。この攻撃のバージョンは、潜在的に2^71メッセージを刺激する10のメッセージ未満を示しています。
This document specifies normative changes to the SIP protocol to address this vulnerability. According to this update, when a SIP proxy forks a request to more than one destination, it is required to ensure it is not participating in a request loop.
このドキュメントは、SIPプロトコルの規範的な変更を指定して、この脆弱性に対処します。この更新によると、SIPプロキシが複数の宛先へのリクエストを分岐する場合、リクエストループに参加しないようにする必要があります。
This normative update alone is insufficient to protect against crafted variations of the attack described here involving multiple Addresses of Record (AORs). To further address the vulnerability, this document defines the Max-Breadth mechanism to limit the total number of concurrent branches caused by a forked SIP request. The mechanism only limits concurrency. It does not limit the total number of branches a request can traverse over its lifetime.
この規範的な更新だけでは、複数のレコード（AOR）を含むここで説明する攻撃の巧妙なバリエーションから保護するには不十分です。脆弱性にさらに対処するために、このドキュメントでは、SIPリクエストによって引き起こされる同時ブランチの総数を制限する最大ブレッドメカニズムを定義します。メカニズムは同時性のみを制限します。リクエストが生涯にわたって移動できるブランチの総数を制限するものではありません。
The mechanisms in this update will protect against variations of the attack described here that use a small number of resources, including most unintentional self-inflicted variations that occur through accidental misconfiguration. However, an attacker with access to a sufficient number of distinct resources will still be able to stimulate a very large number of messages. The number of concurrent messages will be limited by the Max-Breadth mechanism, so the entire set will be spread out over a long period of time, giving operators better opportunity to detect the attack and take corrective measures outside the protocol. Future protocol work is needed to prevent this form of the attack.
この更新のメカニズムは、偶発的な誤解を通じて発生する最も意図しない自己侵入のバリエーションを含む、少数のリソースを使用する攻撃の変動から保護されます。ただし、十分な数の異なるリソースにアクセスできる攻撃者は、非常に多数のメッセージを刺激することができます。同時メッセージの数は最大ブレッドメカニズムによって制限されるため、セット全体が長期間にわたって広がり、オペレーターが攻撃を検出し、プロトコル以外の是正措置を講じる機会を増やします。この形式の攻撃を防ぐには、将来のプロトコル作業が必要です。
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]で説明されているように解釈されます。
This section describes setting up an attack with a simplifying assumption: that two accounts on each of two different RFC 3261 compliant proxy/registrar servers that do not perform loop detection are available to an attacker. This assumption is not necessary for the attack but makes representing the scenario simpler. The same attack can be realized with a single account on a single server.
このセクションでは、単純化された仮定で攻撃のセットアップについて説明します。2つの異なるRFC 3261のそれぞれに2つのアカウントが、ループ検出を実行しない準拠プロキシ/レジストラサーバーが攻撃者が利用できることです。この仮定は攻撃には必要ではありませんが、シナリオをより簡単に表現します。単一のサーバー上の単一のアカウントで同じ攻撃を実現できます。
Consider two proxy/registrar services, P1 and P2, and four Addresses of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER requests, establish bindings to these AORs as follows (non-essential details elided):
2つのプロキシ/レジストラサービス、P1およびP2、および4つのレコードアドレス、A@P1、B@P1、A@P2、およびB@P2を検討してください。通常のレジスタリクエストを使用して、次のようにこれらのAORへのバインディングを確立します（必須ではない詳細が削除されました）：
REGISTER sip:P1 SIP/2.0
To: <sip:a@P1>
Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P1 SIP/2.0
To: <sip:b@P1>
Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P2 SIP/2.0
To: <sip:a@P2>
Contact: <sip:a@P1>, <sip:b@P1>
REGISTER sip:P2 SIP/2.0
To: <sip:b@P2>
Contact: <sip:a@P1>, <sip:b@P1>
With these bindings in place, introduce an INVITE request to any of the four AORs, say a@P1. This request will fork to two requests handled by P2, which will fork to four requests handled by P1, which will fork to eight messages handled by P2, and so on. This message flow is represented in Figure 1.
これらのバインディングを配置して、4つのAORのいずれかに招待リクエストを導入します。たとえば、@P1。このリクエストは、P2によって処理される2つのリクエストに分岐します。これにより、P1が処理する4つのリクエストがフォークされ、P2が処理する8つのメッセージなどが分岐します。このメッセージの流れは図1に示されています。
|
a@P1
/ \
/ \
/ \
/ \
a@P2 b@P2
/ \ / \
/ \ / \
/ \ / \
a@P1 b@P1 a@P1 b@P1
/ \ / \ / \ / \
a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2
/\ /\ /\ /\ /\ /\ /\ /\
.
.
.
Figure 1: Attack Request Propagation
図1：攻撃リクエストの伝播
Requests will continue to propagate down this tree until Max-Forwards reaches zero. If the endpoint and two proxies involved follow RFC 3261 recommendations, the tree will be 70 rows deep, representing 2^71-1 requests. The actual number of messages may be much larger if the time to process the entire tree's worth of requests is longer than Timer C at either proxy. In this case, a storm of 408 responses and/or a storm of CANCEL requests will also be propagating through the tree along with the INVITE requests. Remember that there are only two proxies involved in this scenario - each having to hold the state for all the transactions it sees (at least 2^70 simultaneously active transactions near the end of the scenario).
マックスフォワードがゼロに達するまで、このツリーを延期し続けます。関係するエンドポイントと2つのプロキシがRFC 3261の推奨に従う場合、ツリーは2^71-1リクエストを表す70行になります。ツリー全体のリクエストを処理する時間がいずれかのプロキシでタイマーCよりも長い場合、実際のメッセージの数ははるかに大きくなる可能性があります。この場合、408の応答の嵐および/またはキャンセルリクエストの嵐も、招待リクエストとともにツリーを介して伝播します。このシナリオには2つのプロキシしか関与していないことを忘れないでください - それぞれが表示されるすべてのトランザクションの状態を保持する必要があります（シナリオの終わり近くに少なくとも2^70同時にアクティブトランザクション）。
The attack can be simplified to one account at one server if the service can be convinced that contacts with varying attributes (parameters, schemes, embedded headers) are sufficiently distinct, and these parameters are not used as part of AOR comparisons when forwarding a new request. Since RFC 3261 mandates that all URI parameters must be removed from a URI before looking it up in a location service and that the URIs from the Contact header field are compared using URI equality, the following registration should be sufficient to set up this attack using a single REGISTER request to a single account:
さまざまな属性（パラメーター、スキーム、埋め込みヘッダー）との接触が十分に異なり、これらのパラメーターは新しいリクエストを転送する際のAOR比較の一部として使用されないことをサービスが確信できる場合、攻撃は1つのサーバーで1つのアカウントに簡素化できます。。RFC 3261は、すべてのURIパラメーターをロケーションサービスで調べる前にURIから削除する必要があり、接触ヘッダーフィールドからのURIがURI等式を使用して比較されることを義務付けているため、次の登録は、この攻撃を使用してこの攻撃を設定するのに十分でなければなりません。単一のアカウントへの単一のレジスタリクエスト：
REGISTER sip:P1 SIP/2.0
To: <sip:a@P1>
Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud>
This attack was realized in practice during one of the SIP Interoperability Test (SIPit) sessions. The scenario was extended to include more than two proxies, and the participating proxies all limited Max-Forwards to be no larger than 20. After a handful of messages to construct the attack, the participating proxies began bombarding each other. Extrapolating from the several hours the experiment was allowed to run, the scenario would have completed in just under 10 days. Had the proxies used the RFC 3261 recommended Max-Forwards value of 70, and assuming they performed linearly as the state they held increased, it would have taken 3 trillion years to complete the processing of the single INVITE request that initiated the attack. It is interesting to note that a few proxies rebooted during the scenario and rejoined in the attack when they restarted (as long as they maintained registration state across reboots). This points out that if this attack were launched on the Internet at large, it might require coordination among all the affected elements to stop it.
この攻撃は、SIP相互運用性テスト（SIPIT）セッションの1つで実際に実現されました。シナリオは2つ以上のプロキシを含むように拡張され、参加しているプロキシはすべて20以下に制限されています。数時間から外挿して、実験が実行され、シナリオは10日弱で完了していました。プロキシがRFC 3261を推奨する最大値70を推奨していた場合、彼らが保持している状態が増加するにつれて直線的に実行されたと仮定して、攻撃を開始した単一の招待要求の処理を完了するのに3兆年かかったでしょう。いくつかのプロキシがシナリオ中に再起動し、再起動時に攻撃に再加入したことに注意するのは興味深いことです（再起動全体で登録状態を維持している限り）。これは、この攻撃がインターネット全体で発売された場合、影響を受けるすべての要素間の調整が必要になる可能性があることを指摘しています。
Loop detection, as specified in this document, at any of the proxies in the scenarios described so far would have stopped the attack immediately. (If all the proxies involved implemented this loop detection, the total number of stimulated messages in the first scenario described would be reduced to 14; in the variation involving one server, the number of stimulated messages would be reduced to 10.) However, there is a variant of the attack that uses multiple AORs where loop detection alone is insufficient protection. In this variation, each participating AOR forks to all the other participating AORs. For small numbers of participating AORs (10, for example), paths through the resulting tree will not loop until very large numbers of messages have been generated. Acquiring a sufficient number of AORs to launch such an attack on networks currently available is quite feasible.
このドキュメントで指定されているように、これまでに説明されているシナリオのプロキシのいずれかで、ループ検出はすぐに攻撃を停止しました。（関係するすべてのプロキシがこのループ検出を実装した場合、説明された最初のシナリオの刺激メッセージの総数は14に減少します。1つのサーバーを含むバリエーションでは、刺激されたメッセージの数は10に減ります。ループ検出だけでは保護が不十分な複数のAORを使用する攻撃のバリアントです。このバリエーションでは、参加する各AORが他のすべての参加AORにフォークスします。少数の参加AOR（たとえば10、10、）の場合、結果のツリーを通るパスは、非常に多数のメッセージが生成されるまでループしません。現在利用可能なネットワークに対するこのような攻撃を開始するのに十分な数のAORを取得することは非常に実現可能です。
In this scenario, requests will often take many hops to complete a loop, and there are a very large number of different loops that will occur during the attack. In fact, if N is the number of participating AORs, and provided N is less than or equal to Max-Forwards, the amount of traffic generated by the attack is greater than N!, even if all proxies involved are performing loop detection.
このシナリオでは、リクエストは多くの場合、ループを完成させるために多くのホップがかかり、攻撃中に発生する非常に多数の異なるループがあります。実際、nが参加AORの数であり、提供されたnがmax-forwards以下である場合、攻撃によって生成されるトラフィックの量は、関係するすべてのプロキシがループ検出を実行していても、nよりも大きくなります。
Suppose we have a set of N AORs, all of which are set up to fork to the entire set. For clarity, assume AOR 1 is where the attack begins. Every permutation of the remaining N-1 AORs will play out, defining (N-1)! distinct paths, without repeating any AOR. Then, each of these paths will fork N ways one last time, and a loop will be detected on each of these branches. These final branches alone total N! requests ((N-1)! paths, with N forks at the end of each path).
一連のn aorsがあるとしますが、そのすべてがセット全体に分岐するように設定されています。明確にするために、AOR 1が攻撃が始まる場所であると仮定します。残りのN-1 AORのすべての順列が再生され、（n-1）が定義されます！AORを繰り返すことなく、明確なパス。次に、これらのパスのそれぞれが最後に1つの方法でフォークされ、これらの各ブランチでループが検出されます。これらの最終枝だけで合計n！リクエスト（（n-1）！パス、各パスの端にnがforks）。
___N____Requests_
| 1 | 1 |
| 2 | 4 |
| 3 | 15 |
| 4 | 64 |
| 5 | 325 |
| 6 | 1956 |
| 7 | 13699 |
| 8 | 109600 |
| 9 | 986409 |
| 10 | 9864100 |
Forwarded Requests vs. Number of Participating AORs
転送されたリクエスト対参加AORの数
In a network where all proxies are performing loop detection, an attacker is still afforded rapidly increasing returns on the number of AORs they are able to leverage. The Max-Breadth mechanism defined in this document is designed to limit the effectiveness of this variation of the attack.
すべてのプロキシがループ検出を実行しているネットワークでは、攻撃者が依然として急速に増加しており、活用できるAORの数に対するリターンが増加しています。このドキュメントで定義されている最大巻きメカニズムは、この攻撃の変化の有効性を制限するように設計されています。
In all of the scenarios, it is important to notice that at each forking proxy, an additional branch could be added pointing to a single victim (that might not even be a SIP-aware element), resulting in a massive amount of traffic being directed towards the victim from potentially as many sources as there are AORs participating in the attack.
すべてのシナリオにおいて、各フォーキングプロキシで、1人の犠牲者（SIPに認識された要素でさえないかもしれない）を指す追加のブランチを追加できることに注意することが重要です。攻撃に参加しているAORがあるのと同じくらい多くの情報源からの犠牲者に向けて。
The following requirements mitigate the risk of a proxy falling victim to the attack described in this document.
以下の要件は、この文書に記載されている攻撃の犠牲者の犠牲者のリスクを軽減します。
When a SIP proxy forks a particular request to more than one location, it MUST ensure that request is not looping through this proxy. It is RECOMMENDED that proxies meet this requirement by performing the loop-detection steps defined in this document.
SIPプロキシが複数の場所への特定のリクエストをフォーキングする場合、このプロキシを介してリクエストがループしないようにする必要があります。このドキュメントで定義されているループ検出手順を実行することにより、プロキシはこの要件を満たすことをお勧めします。
The requirement to use this document's refinement of the loop-detection algorithm from RFC 3261 is set at should-strength to allow for future Standards-Track mechanisms that will allow a proxy to determine it is not looping. For example, a proxy forking to destinations established using the sip-outbound mechanism [OUTBOUND] would know those branches will not loop.
RFC 3261からのループ検出アルゴリズムのこのドキュメントの改良を使用する要件は、将来の標準トラックメカニズムを可能にするために、将来の標準トラックメカニズムを可能にするために設定されています。たとえば、SIP-Outboundメカニズム[アウトバウンド]を使用して確立された目的地へのプロキシフォーキングは、それらの枝がループしないことを知っています。
A SIP proxy forwarding a request to only one location MAY perform loop detection but is not required to. When forwarding to only one location, the amplification risk being exploited is not present, and the Max-Forwards mechanism will protect the network to the extent it was designed (always keep in mind the constant multiplier due to exhausting Max-Forwards while not forking). A proxy is not required to perform loop detection when forwarding a request to a single location even if it happened to have previously forked that request (and performed loop detection) in its progression through the network.
リクエストを1つの場所に転送するSIPプロキシは、ループ検出を実行できますが、必要ではありません。1つの場所のみに転送する場合、エクスプロイズされている増幅リスクは存在しません。最大化されたメカニズムは、設計された範囲でネットワークを保護します（フォーキング中に最大値を使い果たしているため、常に一定の乗数に留意してください）。リクエストを単一の場所に転送するときにループ検出を実行するためにプロキシは、以前にネットワークを介してそのリクエスト（およびループ検出を実行した）をフォークしていたとしても、単一の場所に転送する必要はありません。
This section replaces all of item 8 in Section 16.6 of RFC 3261 (item 8 begins on page 105 and ends on page 106 of RFC 3261).
このセクションでは、RFC 3261のセクション16.6のすべての項目8を置き換えます（アイテム8は105ページから始まり、RFC 3261の106ページで終了します）。
8. Add a Via Header Field Value
8. Via Headerフィールド値を追加します
The proxy MUST insert a Via header field value into the copy before the existing Via header field values. The construction of this value follows the same guidelines of Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and will contain the requisite magic cookie. Note that following only the guidelines in Section 8.1.1.7 will result in a branch parameter that will be different for different instances of a spiraled or looped request through a proxy.
プロキシは、既存のヘッダーフィールド値の前に、ヘッダーフィールド値をコピーに挿入する必要があります。この値の構築は、セクション8.1.1.7の同じガイドラインに従います。これは、プロキシが独自のブランチパラメーターを計算することを意味します。これは、そのブランチにとってグローバルにユニークであり、必要なマジッククッキーを含むことを意味します。セクション8.1.1.7のガイドラインのみに従うと、プロキシを介したスパイラルまたはループリクエストの異なるインスタンスで異なるブランチパラメーターが生じることに注意してください。
Proxies required to perform loop detection by RFC 5393 have an additional constraint on the value they place in the Via header field. Such proxies SHOULD create a branch value separable into two parts in any implementation-dependent way.
RFC 5393によるループ検出を実行するために必要なプロキシは、Viaヘッダーフィールドに配置する値に追加の制約があります。このようなプロキシは、実装依存の方法で2つの部分に分離可能な分岐値を作成する必要があります。
The remainder of this section's description assumes the existence of these two parts. If a proxy chooses to employ some other mechanism, it is the implementer's responsibility to verify that the detection properties defined by the requirements placed on these two parts are achieved.
このセクションの説明の残りの部分は、これら2つの部分の存在を想定しています。プロキシが他のメカニズムを使用することを選択した場合、これら2つの部分に配置された要件によって定義された検出プロパティが達成されることを確認するのは実装者の責任です。
The first part of the branch value MUST satisfy the constraints of Section 8.1.1.7. The second part is used to perform loop detection and distinguish loops from spirals.
ブランチ値の最初の部分は、セクション8.1.1.7の制約を満たす必要があります。2番目の部分は、ループ検出を実行し、スパイラルとループを区別するために使用されます。
This second part MUST vary with any field used by the location service logic in determining where to retarget or forward this request. This is necessary to distinguish looped requests from spirals by allowing the proxy to recognize if none of the values affecting the processing of the request have changed. Hence, the second part MUST depend at least on the received Request-URI and any Route header field values used when processing the received request. Implementers need to take care to include all fields used by the location service logic in that particular implementation.
この2番目の部分は、このリクエストをリターゲットまたは転送する場所を決定する際に、ロケーションサービスロジックで使用されるフィールドによって異なる必要があります。これは、リクエストの処理に影響を与える値が変更されていないかどうかをプロキシが認識できるようにすることにより、ループされた要求をスパイラルと区別するために必要です。したがって、2番目の部分は、少なくとも受信したリクエストURIおよび受信リクエストの処理時に使用されるルートヘッダーフィールド値に依存する必要があります。実装者は、その特定の実装でロケーションサービスロジックで使用されるすべてのフィールドを含めるように注意する必要があります。
This second part MUST NOT vary with the request method. CANCEL and non-200 ACK requests MUST have the same branch parameter value as the corresponding request they cancel or acknowledge. This branch parameter value is used in correlating those requests at the server handling them (see Sections 17.2.3 and 9.2).
この2番目の部分は、リクエストメソッドによって変化してはなりません。キャンセルおよび非200ACKリクエストは、キャンセルまたは承認する対応する要求と同じブランチパラメーター値を持つ必要があります。このブランチパラメーター値は、それらを処理するサーバーのリクエストを相関させる際に使用されます（セクション17.2.3および9.2を参照）。
This section replaces all of item 4 in Section 16.3 of RFC 3261 (item 4 appears on page 95 of RFC 3261).
このセクションでは、RFC 3261のセクション16.3のアイテム4のすべてを置き換えます（アイテム4は、RFC 3261の95ページに表示されます）。
4. Loop-Detection Check
4. ループ検出チェック
Proxies required to perform loop detection by RFC 5393 MUST perform the following loop-detection test before forwarding a request. Each Via header field value in the request whose sent-by value matches a value placed into previous requests by this proxy MUST be inspected for the "second part" defined in Section 4.2.1 of RFC 5393. This second part will not be present if the message was not forked when that Via header field value was added. If the second field is present, the proxy MUST perform the second-part calculation described in Section 4.2.1 of RFC 5393 on this request and compare the result to the value from the Via header field. If these values are equal, the request has looped and the proxy MUST reject the request with a 482 (Loop Detected) response. If the values differ, the request is spiraling and processing continues to the next step.
RFC 5393によるループ検出を実行するために必要なプロキシは、リクエストを転送する前に、次のループ検出テストを実行する必要があります。セントごとの値がこのプロキシによって以前のリクエストに配置された値と一致するリクエストのヘッダーフィールド値は、RFC 5393のセクション4.2.1で定義されている「セカンドパート」について検査する必要があります。ヘッダーフィールド値を介して追加された場合、メッセージはフォークされませんでした。2番目のフィールドが存在する場合、プロキシは、このリクエストでRFC 5393のセクション4.2.1で説明されている2番目の部分計算を実行し、結果をViaヘッダーフィールドの値と比較する必要があります。これらの値が等しい場合、リクエストがループし、プロキシは482（ループ検出）応答でリクエストを拒否する必要があります。値が異なる場合、リクエストはスパイラルであり、処理は次のステップまで続きます。
These requirements and the recommendation to use the loop-detection mechanisms in this document make the favorable trade of exponential message growth for work that is, at worst, order n^2 as a message crosses n proxies. Specifically, this work is order m*n where m is the number of proxies in the path that fork the request to more than one location. In practice, m is expected to be small.
これらの要件と、このドキュメントでループ検出メカニズムを使用することを推奨することにより、最悪の場合、メッセージがnプロキシを越えてn^2を順序付ける作業の指数関数的なメッセージの成長の好ましい取引を行います。具体的には、この作業はM*Nの注文であり、Mは複数の場所に要求を分岐するパスのプロキシの数です。実際には、Mは小さいと予想されます。
The loop-detection algorithm expressed in this document requires a proxy to inspect each Via element in a received request. In the worst case, where a message crosses N proxies, each of which loop detect, proxy k does k inspections, and the overall number of inspections spread across the proxies handling this request is the sum of k from k=1 to k=N which is N(N+1)/2.
このドキュメントで表現されたループ検出アルゴリズムには、受信したリクエストで各要素を介して各要素を検査するプロキシが必要です。最悪の場合、メッセージがnプロキシを通過し、それぞれがループを検出し、プロキシkがKを検査し、この要求を処理するプロキシ全体に広がる検査の総数は、k = 1からk = nまでのkの合計です。これはn（n 1）/2です。
A common way to create the second part of the branch parameter value when forking a request is to compute a hash over the concatenation of the Request-URI, any Route header field values used during processing the request, and any other values used by the location service logic while processing this request. The hash should be chosen so that there is a low probability that two distinct sets of these parameters will collide. Because the maximum number of inputs that need to be compared is 70, the chance of a collision is low even with a relatively small hash value, such as 32 bits. CRC-32c as specified in [RFC4960] is a specific acceptable function, as is MD5 [RFC1321]. Note that MD5 is being chosen purely for non-cryptographic properties. An attacker who can control the inputs in order to produce a hash collision can attack the connection in a variety of other ways. When forming the second part using a hash, implementations SHOULD include at least one field in the input to the hash that varies between different transactions attempting to reach the same destination to avoid repeated failure should the hash collide. The Call-ID and CSeq fields would be good inputs for this purpose.
リクエストを分岐するときにブランチパラメーター値の2番目の部分を作成する一般的な方法は、リクエスト-URIの連結、リクエストの処理中に使用されるルートヘッダーフィールド値、および場所で使用されるその他の値を介してハッシュを計算することです。このリクエストの処理中のサービスロジック。これらのパラメーターの2つの異なるセットが衝突する可能性が低くなるように、ハッシュを選択する必要があります。比較する必要がある入力の最大数は70であるため、32ビットなどの比較的小さなハッシュ値でも衝突の可能性は低くなります。[RFC4960]で指定されているCRC-32Cは、MD5 [RFC1321]と同様に、特定の許容機能です。MD5は、非暗号化特性のために純粋に選択されていることに注意してください。ハッシュ衝突を生成するために入力を制御できる攻撃者は、他のさまざまな方法で接続を攻撃する可能性があります。ハッシュを使用して2番目の部分を形成する場合、実装には、ハッシュが衝突した場合に繰り返し障害を回避するために同じ宛先に到達しようとする異なるトランザクションの間に変化するハッシュへの入力に少なくとも1つのフィールドを含める必要があります。Call-IDおよびCSEQフィールドは、この目的のための適切な入力になります。
A common point of failure to interoperate at SIPit events has been due to parsers objecting to the contents of another element's Via header field values when inspecting the Via stack for loops. Implementers need to take care to avoid making assumptions about the format of another element's Via header field value beyond the basic constraints placed on that format by RFC 3261. In particular, parsing a header field value with unknown parameter names, parameters with no values, or parameter values with or without quoted strings must not cause an implementation to fail.
SIPITイベントで相互運用しなかったという一般的な点は、ループのviaスタックを検査する際に、別の要素Viaヘッダーフィールド値の内容に反対するパーサーによるものです。実装者は、RFC 3261によってその形式に配置された基本的な制約を超えて、ヘッダーフィールド値を介して別の要素の形式について仮定を避けるように注意する必要があります。引用された文字列の有無にかかわらずパラメーター値は、実装を失敗させてはなりません。
Removing, obfuscating, or in any other way modifying the branch parameter values in Via header fields in a received request before forwarding it removes the ability for the node that placed that branch parameter into the message to perform loop detection. If two elements in a loop modify branch parameters this way, a loop can never be detected.
削除、難読化、またはその他の方法で、転送する前に受け取った要求でヘッダーフィールドを介してブランチパラメーター値を変更すると、そのブランチパラメーターをメッセージに配置してループ検出を実行するノードの機能が削除されます。ループ内の2つの要素がこの方法で分岐パラメーターを変更すると、ループを検出することはできません。
The Max-Breadth mechanism defined here limits the total number of concurrent branches caused by a forked SIP request. With this mechanism, all proxyable requests are assigned a positive integral Max-Breadth value, which denotes the maximum number of concurrent branches this request may spawn through parallel forking as it is forwarded from its current point. When a proxy forwards a request, its Max-Breadth value is divided among the outgoing requests. In turn, each of the forwarded requests has a limit on how many concurrent branches it may spawn. As branches complete, their portion of the Max-Breadth value becomes available for subsequent branches, if needed. If there is insufficient Max-Breadth to carry out a desired parallel fork, a proxy can return the 440 (Max-Breadth Exceeded) response defined in this document.
ここで定義されている最大巻きメカニズムは、FRKED SIPリクエストによって引き起こされる同時ブランチの総数を制限します。このメカニズムを使用すると、すべてのプロキシ可能なリクエストには、積極的な積分の最大値値が割り当てられます。これは、現在のポイントから転送されるため、このリクエストが並列フォーキングを介して生成される可能性があることを示します。プロキシがリクエストを転送すると、その最大値は発信リクエストに分割されます。次に、転送された各リクエストには、発生する可能性のある同時ブランチの数に制限があります。ブランチが完了すると、必要に応じて、後続のブランチで最大値の一部が利用可能になります。目的のパラレルフォークを実行するのに最大ブレッドスが不十分な場合、プロキシはこのドキュメントで定義されている440（最大ブレッドを超えた）応答を返すことができます。
This mechanism operates independently from Max-Forwards. Max-Forwards limits the depth of the tree a request may traverse as it is forwarded from its origination point to each destination it is forked to. As Section 3 shows, the number of branches in a tree of even limited depth can be made large (exponential with depth) by leveraging forking. Each such branch has a pair of SIP transaction state machines associated with it. The Max-Breadth mechanism limits the number of branches that are active (those that have running transaction state machines) at any given point in time.
このメカニズムは、最大層から独立して動作します。Max-forwardsは、その出典ポイントからフォークされた各宛先に転送されるため、リクエストが通過する可能性があるツリーの深さを制限します。セクション3に示すように、フォーキングを活用することにより、さらに限られた深さの木の枝の数を大きくすることができます（深さとともに指数関数的に）。そのような各ブランチには、それに関連付けられたSIPトランザクション状態マシンのペアがあります。Max-Breadthメカニズムは、特定の時点でアクティブなブランチ（トランザクションステートマシンを実行しているもの）の数を制限します。
Max-Breadth does not prevent forking. It only limits the number of concurrent parallel forked branches. In particular, a Max-Breadth of 1 restricts a request to pure serial forking rather than restricting it from being forked at all.
Max-Breadthはフォーキングを妨げません。同時の平行分岐ブランチの数のみを制限します。特に、最大1の1つは、純粋なシリアルフォークへの要求を制限するのではなく、純粋なシリアルフォーキングを制限します。
A client receiving a 440 (Max-Breadth Exceeded) response can infer that its request did not reach all possible destinations. Recovery options are similar to those when receiving a 483 (Too Many Hops) response, and include affecting the routing decisions through whatever mechanisms are appropriate to result in a less broad search, or refining the request itself before submission to make the search space smaller.
440（Max-Breadthを超えた）応答を受け取ったクライアントは、その要求がすべての可能な目的地に到達しなかったと推測できます。リカバリオプションは、483（ホップが多すぎる）応答を受信する場合のオプションに似ており、検索スペースを小さくするために提出する前に、あまり幅広い検索になるために適切なメカニズムを介してルーティングの決定に影響を与えるか、リクエスト自体を改良することが含まれます。
UAC Proxy A Proxy B Proxy C
| INVITE | | |
| Max-Breadth: 60 | INVITE | |
| Max-Forwards: 70 | Max-Breadth: 30 | |
|-------------------->| Max-Forwards: 69 | |
| |------------------->| |
| | INVITE | |
| | Max-Breadth: 30 | |
| | Max-Forwards: 69 | |
| |--------------------------------------->|
| | | |
Parallel Forking
並列フォーキング
UAC Proxy A Proxy B Proxy C
| INVITE | | |
| Max-Breadth: 60 | INVITE | |
| Max-Forwards: 70 | Max-Breadth: 60 | |
|-------------------->| Max-Forwards: 69 | |
| |------------------->| |
| | some error response| |
| |<-------------------| |
| | INVITE | |
| | Max-Breadth: 60 | |
| | Max-Forwards: 69 | |
| |--------------------------------------->|
| | | |
Sequential Forking
シーケンシャルフォーキング
UAC Proxy A Proxy B Proxy C
| INVITE | | |
| Max-Breadth: 60 | INVITE | |
| Max-Forwards: 70 | Max-Breadth: 60 | INVITE |
|-------------------->| Max-Forwards: 69 | Max-Breadth: 60 |
| |------------------->| Max-Forwards: 68 |
| | |------------------>|
| | | |
| | | |
| | | |
No Forking
フォーキングはありません
MB == Max-Breadth MF == Max-Forwards
| MB: 4
| MF: 5
MB: 2 P MB: 2
MF: 4 / \ MF: 4
+---------------+ +------------------+
MB: 1 P MB: 1 MB: 1 P MB: 1
MF: 3 / \ MF: 3 MF: 3 / \ MF: 3
+---+ +-------+ +----+ +-------+
P P P P
MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 2 | MF: 2 | MF: 2 | MF: 2 |
P P P P
MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 1 | MF: 1 | MF: 1 | MF: 1 |
P P P P
.
.
.
Max-Breadth and Max-Forwards Working Together
Max-BreadthとMax-Forwardsが一緒に動作します
The Max-Breadth header field takes a single positive integer as its value. The Max-Breadth header field value takes no parameters.
Max-Breadth Headerフィールドは、その値として単一の正の整数を採用します。Max-Breadth Headerフィールド値にはパラメーターが含まれません。
For each "response context" (see Section 16 of [RFC3261]) in a proxy, this mechanism defines two positive integral values: Incoming Max-Breadth and Outgoing Max-Breadth. Incoming Max-Breadth is the value in the Max-Breadth header field in the request that formed the response context. Outgoing Max-Breadth is the sum of the Max-Breadth header field values in all forwarded requests in the response context that have not received a final response.
プロキシの各「応答コンテキスト」（[RFC3261]のセクション16を参照）について、このメカニズムは2つの正の積分値を定義します。着信Max-Breadthは、応答コンテキストを形成する要求のMax-Breadthヘッダーフィールドの値です。発信Max-Breadthは、最終的な応答を受信していない応答コンテキストで、すべての転送された要求におけるMax-Breadth Headerフィールド値の合計です。
If a SIP proxy receives a request with no Max-Breadth header field value, it MUST add one, with a value that is RECOMMENDED to be 60. Proxies MUST have a maximum allowable Incoming Max-Breadth value, which is RECOMMENDED to be 60. If this maximum is exceeded in a received request, the proxy MUST overwrite it with a value that SHOULD be no greater than its allowable maximum.
SIPプロキシがMax-Breadth Headerフィールド値のないリクエストを受信した場合、60であることをお勧めする値を追加する必要があります。プロキシは、60になることをお勧めします。受信した要求でこの最大値を超えた場合、プロキシは、許容最大値よりも大きくない値でそれを上書きする必要があります。
All proxied requests MUST contain a single Max-Breadth header field value.
すべてのプロキシリクエストには、単一のMax-Breadthヘッダーフィールド値が含まれている必要があります。
SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the Incoming Max-Breadth in a given response context.
SIPプロキシは、発信するMax-Breadthが特定の応答コンテキストで着信最大ブレッドスを超えることを許可してはなりません。
If a SIP proxy determines a response context has insufficient Incoming Max-Breadth to carry out a desired parallel fork, and the proxy is unwilling/unable to compensate by forking serially or sending a redirect, that proxy MUST return a 440 (Max-Breadth Exceeded) response.
SIPプロキシが応答コンテキストが受信する最大ブレッドスが不十分であると判断した場合、目的の並列フォークを実行することができ、プロキシは連続的にフォーキングまたはリダイレクトを送信することで補償することができません。） 応答。
Notice that these requirements mean a proxy receiving a request with a Max-Breadth of 1 can only fork serially, but it is not required to fork at all -- it can return a 440 instead. Thus, this mechanism is not a tool a user agent can use to force all proxies in the path of a request to fork serially.
これらの要件は、1の最大ブレッドスでリクエストを受信するプロキシが連続的にフォークのみをフォークできることを意味することに注意してください。ただし、フォークする必要はまったくありません。したがって、このメカニズムは、ユーザーエージェントが連続的にフォークするリクエストのパスですべてのプロキシを強制するために使用できるツールではありません。
A SIP proxy MAY distribute Max-Breadth in an arbitrary fashion between active branches. A proxy SHOULD NOT use a smaller amount of Max-Breadth than was present in the original request unless the Incoming Max-Breadth exceeded the proxy's maximum acceptable value. A proxy MUST NOT decrement Max-Breadth for each hop or otherwise use it to restrict the "depth" of a request's propagation.
SIPプロキシは、アクティブブランチ間で最大ブレッドスを任意の方法で配布する場合があります。プロキシは、入ってくるMax-Breadthがプロキシの最大許容値を超えない限り、元のリクエストに存在していたよりも少量のMax-Breadthを使用してはなりません。プロキシは、各ホップの最大ブレッドを減少させたり、それを使用して要求の伝播の「深さ」を制限してはなりません。
Because forwarded requests that have received a final response do not count towards the Outgoing Max-Breadth, whenever a final response arrives, the Max-Breadth that was used on that branch becomes available for reuse. Proxies SHOULD be prepared to reuse this Max-Breadth in cases where there may be elements left in the target-set.
最終的な応答を受け取った転送された要求は、最終的な応答が到着するたびに、そのブランチで使用された最大ブレッドスが再利用できるようになるようになります。ターゲットセットに要素が残っている可能性がある場合に、この最大ブレッドを再利用するためにプロキシを準備する必要があります。
A User Agent Client (UAC) MAY place a Max-Breadth header field value in outgoing requests. If so, this value is RECOMMENDED to be 60.
ユーザーエージェントクライアント（UAC）は、発信リクエストに最大ブレッドヘッダーフィールド値を配置する場合があります。その場合、この値は60になることをお勧めします。
This mechanism does not affect User Agent Server (UAS) behavior. A UAS receiving a request with a Max-Breadth header field will ignore that field while processing the request.
このメカニズムは、ユーザーエージェントサーバー（UAS）の動作には影響しません。Max-Breadthヘッダーフィールドでリクエストを受信するUASは、リクエストの処理中にそのフィールドを無視します。
Since CANCEL requests are never proxied, a Max-Breadth header field value is meaningless in a CANCEL request. Sending a CANCEL in no way affects the Outgoing Max-Breadth in the associated INVITE response context. Receiving a CANCEL in no way affects the Incoming Max-Breadth of the associated INVITE response context.
キャンセルリクエストは決してプロキシではないため、キャンセルリクエストでは最大ブレッドヘッダーフィールド値は無意味です。キャンセルを送信することは、関連するInvite Responseコンテキストの発信Max-Breadthに決して影響しません。キャンセルを受け取ることは、関連する招待対応コンテキストの入ってくる最大ブリードに決して影響しません。
Whether 2xx responses free up Max-Breadth is mostly a moot issue, since proxies are forbidden to start new branches in this case. But, there is one caveat. A proxy may receive multiple 2xx responses for a single forwarded INVITE request. Also, [RFC2543] implementations may send back a 6xx followed by a 2xx on the same branch. Implementations that subtract from the Outgoing Max-Breadth when they receive a 2xx response to an INVITE request must be careful to avoid bugs caused by subtracting multiple times for a single branch.
2xxの応答が最大ブレッドを解放するかどうかは、この場合、プロキシが新しいブランチを開始することを禁じられているため、主に否定的な問題です。しかし、1つの注意事項があります。プロキシは、単一の転送された招待リクエストに対して複数の2xx応答を受信する場合があります。また、[RFC2543]実装は、6xxを返送し、その後同じブランチで2xxを送信する場合があります。招待リクエストに対する2xx応答を受け取ったときに発信されるMax-Breadthから減算する実装は、単一のブランチの複数回を減算することにより生じるバグを避けるように注意する必要があります。
Designers of automaton user agents (UAs) (including B2BUAs, gateways, exploders, and any other element that programmatically sends requests as a result of incoming SIP traffic) should consider whether Max-Breadth limitations should be placed on outgoing requests. For example, it is reasonable to design B2BUAs to carry the Max-Breadth value from incoming requests into requests that are sent as a result.
Automatonユーザーエージェント（UAS）の設計者（B2BUA、ゲートウェイ、爆発器、およびSIPトラフィックの結果としてリクエストをプログラム的に送信するその他の要素を含む）は、最大ブレッドの制限を発行リクエストに配置する必要があるかどうかを検討する必要があります。たとえば、B2BUASを設計して、その結果として送信されるリクエストから最大値の値を導入することが合理的です。
Also, it is reasonable to place Max-Breadth constraints on sets of requests sent by exploders when they may be leveraged in an amplification attack.
また、増幅攻撃でレバレッジされる可能性がある場合、爆発者から送信されたリクエストのセットに最大ブレッドスの制約を配置することは合理的です。
Inherent in the definition of this mechanism is the ability of a proxy to reclaim apportioned Max-Breadth while forking sequentially. The limitation on outgoing Max-Breadth is applied to concurrent branches only.
このメカニズムの定義に固有のものは、配分されたMax-Breadthを順番に分岐しながらプロキシの能力です。発信マックスブレッドスの制限は、同時ブランチのみに適用されます。
For example, if a proxy receives a request with a Max-Breadth of 4 and has 8 targets to forward it to, that proxy may parallel fork to 4 of these targets initially (each with a Max-Breadth of 1, totaling an Outgoing Max-Breadth of 4). If one of these transactions completes with a failure response, the outgoing Max-Breadth drops to 3, allowing the proxy to forward to one of the 4 remaining targets (again, with a Max-Breadth of 1).
たとえば、プロキシが4の最大ブリードスでリクエストを受信し、それを転送する8つのターゲットを持っている場合、そのプロキシは最初にこれらのターゲットのうち4つに並列フォークを使用できます（それぞれが最大ブレッドスが1の1で、合計で最大値を合計します-4のブレッドス）。これらのトランザクションのいずれかが障害応答で完了した場合、発信マックスブレッド型は3に低下し、プロキシが残りの4つのターゲットのいずれかに転送できるようにします（再び、最大ブレッドスター1の1）。
There are a variety of mechanisms for controlling the weight of each fork branch. Fork branches that are given more Max-Breadth are more likely to complete quickly (because it is less likely that a proxy down the line will be forced to fork sequentially). By the same token, if it is known that a given branch will not fork later on, a Max-Breadth of 1 may be assigned with no ill effect. This would be appropriate, for example, if a proxy knows the branch is using the SIP outbound extension [OUTBOUND].
各フォークブランチの重量を制御するためのさまざまなメカニズムがあります。より多くの最大ブレッドを与えられるフォークブランチは、迅速に完了する可能性が高くなります（ラインのプロキシが順番にフォークを余儀なくされる可能性が低いため）。同様に、特定のブランチが後で分岐しないことがわかっている場合、1の最大ブリードスが不正な効果なしで割り当てられる場合があります。これは、たとえば、プロキシがブランチがSIPアウトバウンド拡張子を使用していることを知っている場合、適切です[アウトバウンド]。
Max-Breadth limits the total number of active branches spawned by a given request at any one time, while placing no constraint on the distance (measured in hops) that the request can propagate. (i.e., receiving a request with a Max-Breadth of 1 means that any forking must be sequential, not that forking is forbidden)
Max-Breadthは、特定の要求によって一度に生成されたアクティブブランチの総数を制限しますが、要求が伝播できる距離（HOPSで測定）に制約を課されません。（つまり、最大ブレッドスの1でリクエストを受信することは、フォーキングが順次でなければならないことを意味します。
This limits the effectiveness of any amplification attack that leverages forking because the amount of state/bandwidth needed to process the traffic at any given point in time is capped.
これにより、特定の時点でトラフィックを処理するために必要な状態/帯域幅の量が制限されるため、フォーキングを活用する増幅攻撃の有効性が制限されます。
This specification extends the grammar for the Session Initiation Protocol by adding an extension-header. The ABNF [RFC5234] definition is as follows.
この仕様は、拡張ヘッダーを追加することにより、セッション開始プロトコルの文法を拡張します。ABNF [RFC5234]定義は次のとおりです。
Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT
max-breadth = "max-breadth" hcolon 1*桁
This specification registers a new SIP header field and a new SIP response according to the processes defined in [RFC3261].
この仕様は、[RFC3261]で定義されたプロセスに従って、新しいSIPヘッダーフィールドと新しいSIP応答を登録します。
This information appears in the Header Fields sub-registry of the SIP Parameters registry.
この情報は、SIPパラメーターレジストリのヘッダーフィールドサブレジストリに表示されます。
RFC 5393 (this specification)
RFC 5393（この仕様）
Header Field Name: Max-Breadth
ヘッダーフィールド名：Max-Breadth
Compact Form: none
コンパクトフォーム：なし
This information appears in the Response Codes sub-registry of the SIP Parameters registry.
この情報は、SIPパラメータレジストリの応答コードのサブレジストリに表示されます。
Response code: 440
応答コード：440
Default Reason Phrase: Max-Breadth Exceeded
デフォルトの理由フレーズ：Max-Breadthを超えました
This document is entirely about documenting and addressing a vulnerability in SIP proxies as defined by RFC 3261 that can lead to an exponentially growing message exchange attack.
このドキュメントは、RFC 3261で定義されているSIPプロキシの脆弱性を文書化し、対処し、メッセージ交換攻撃の成長につながる可能性があることです。
The Max-Breadth mechanism defined here does not decrease the aggregate traffic caused by the forking-loop attack. It only serves to spread the traffic caused by the attack over a longer period by limiting the number of concurrent branches that are being processed at the same time. An attacker could pump multiple requests into a network that uses the Max-Breadth mechanism and gradually build traffic to unreasonable levels. Deployments should monitor carefully and react to gradual increases in the number of concurrent outstanding transactions related to a given resource to protect against this possibility. Operators should anticipate being able to temporarily disable any resources identified as being used in such an attack. A rapid increase in outstanding concurrent transactions system-wide may be an indication of the presence of this kind of attack across many resources. Deployments in which it is feasible for an attacker to obtain a very large number of resources are particularly at risk. If detecting and intervening in each instance of the attack is insufficient to reduce the load, overload may occur.
ここで定義されている最大ブリードのメカニズムは、フォークループ攻撃によって引き起こされる総トラフィックを減少させません。それは、同時に処理されている同時ブランチの数を制限することにより、攻撃によって引き起こされるトラフィックを長期間にわたって広めるのに役立ちます。攻撃者は、Max-Breadthメカニズムを使用するネットワークに複数のリクエストを送り込み、トラフィックを不合理なレベルに徐々に構築できます。展開は慎重に監視し、この可能性から保護するために、特定のリソースに関連する同時の発行済みトランザクションの数が徐々に増加するように反応する必要があります。オペレーターは、そのような攻撃で使用されていると特定されたリソースを一時的に無効にすることができることを予測する必要があります。システム全体の未解決の同時トランザクションの急速な増加は、多くのリソースにわたるこの種の攻撃の存在を示している可能性があります。攻撃者が非常に多数のリソースを取得することが実行可能な展開は特に危険にさらされています。攻撃の各インスタンスで検出と介入が負荷を減らすには不十分である場合、過負荷が発生する可能性があります。
Implementers and operators are encouraged to follow the recommendations being developed for handling overload conditions (see [REQS] and [DESIGN]).
実装者とオペレーターは、過負荷条件を処理するために開発されている推奨事項に従うことをお勧めします（[reqs]および[design]を参照）。
Designers of protocol gateways should consider the implications of this kind of attack carefully. As an example, if a message transits from a SIP network into the Public Switched Telephone Network (PSTN) and subsequently back into a SIP network, and information about the history of the request on either side of the protocol translation is lost, it becomes possible to construct loops that neither Max-Forwards nor loop detection can protect against. This, combined with forking amplification on the SIP side of the loop, will result in an attack as described in this document that the mechanisms here will not abate, not even to the point of limiting the number of concurrent messages in the attack. These considerations are particularly important for designers of gateways from SIP to SIP (as found in B2BUAs, for example). Many existing B2BUA implementations are under some pressure to hide as much information about the two sides communicating with them as possible. Implementers of such implementations may be tempted to remove the data that might be used by the loop-detection, Max-Forwards, or Max-Breadth mechanisms at other points in the network, taking on the responsibility for detecting loops (or forms of this attack). However, if two such implementations are involved in the attack, neither will be able to detect it.
プロトコルゲートウェイの設計者は、この種の攻撃の意味を慎重に考慮する必要があります。例として、メッセージがSIPネットワークからパブリックスイッチネットワーク（PSTN）に通過し、その後SIPネットワークに戻り、プロトコル翻訳の両側でのリクエストの履歴に関する情報が失われると、可能になります。Max-ForwardsもLoop検出も保護できないループを構築する。これは、ループのSIP側でのフォーク増幅と組み合わさって、このドキュメントで説明されているように、ここでのメカニズムは衰えず、攻撃の同時メッセージの数を制限する点までさえも攻撃になります。これらの考慮事項は、SIPからSIPまでのゲートウェイのデザイナーにとって特に重要です（たとえば、B2Buasに見られるように）。既存のB2BUAの実装の多くは、できるだけ通信している両者に関する情報を隠すように圧力をかけられています。このような実装の実装者は、ネットワーク内の他のポイントでループ検出、最大、または最大巻きメカニズムで使用される可能性のあるデータを削除するように誘惑され、ループ（またはこの攻撃の形式を検出する責任を負います）。ただし、2つのそのような実装が攻撃に関与している場合、どちらもそれを検出することはできません。
Alternative solutions that were discussed include:
議論された代替ソリューションは次のとおりです。
Doing nothing - rely on suing the offender: While systems that have accounts have logs that can be mined to locate abusers, it isn't clear that this provides a credible deterrent or defense against the attack described in this document. Systems that don't recognize the situation and take corrective/preventative action are likely to experience failure of a magnitude that precludes retrieval of the records documenting the setup of the attack. (In one scenario, the registrations can occur in a radically different time period than the INVITE transaction. The INVITE request itself may have come from an innocent). It's even possible that the scenario may be set up unintentionally. Furthermore, for some existing deployments, the cost and audit ability of an account is simply an email address. Finding someone to punish may be impossible. Finally, there are individuals who will not respond to any threat of legal action, and the effect of even a single successful instance of this kind of attack would be devastating to a service provider.
何もしない - 犯罪者の訴訟に依存する：アカウントを持つシステムには虐待者を見つけるために採掘できるログがありますが、これがこの文書に記載されている攻撃に対する信頼できる抑止力または防御を提供することは明らかではありません。状況を認識せず、是正/予防措置を講じるシステムは、攻撃のセットアップを文書化する記録の取得を妨げる大きさの失敗を経験する可能性があります。（1つのシナリオでは、登録は招待状のトランザクションとは根本的に異なる期間に発生する可能性があります。招待リクエスト自体は、無実から来た可能性があります）。シナリオが意図せずに設定される可能性もあります。さらに、一部の既存の展開の場合、アカウントのコストと監査能力は単なるメールアドレスです。罰する人を見つけることは不可能かもしれません。最後に、法的措置の脅威に対応しない個人がいます。この種の攻撃の単一の成功したインスタンスでさえ、サービスプロバイダーにとって壊滅的なものになるでしょう。
Putting a smaller cap on Max-Forwards: The effect of the attack is exponential with respect to the initial Max-Forwards value. Turning this value down limits the effect of the attack. This comes at the expense of severely limiting the reach of requests in the network, possibly to the point that existing architectures will begin to fail.
より小さなキャップをMax-Forwardsに置く：攻撃の効果は、初期の最大値に対して指数関数的です。この値を下げると、攻撃の効果が制限されます。これは、ネットワーク内の要求の範囲を厳しく制限することを犠牲にして、おそらく既存のアーキテクチャが失敗し始めたという点までもたらされます。
Disallowing registration bindings to arbitrary contacts: The way registration binding is currently defined is a key part of the success of the kind of attack documented here. The alternative of limiting registration bindings to allow only binding to the network element performing the registration, perhaps to the extreme of ignoring bits provided in the Contact in favor of transport artifacts observed in the registration request, has been discussed (particularly in the context of the mechanisms being defined in [OUTBOUND]). Mechanisms like this may be considered again in the future, but are currently insufficiently developed to address the present threat.
登録バインディングの任意の連絡先への禁止：登録バインディングが現在定義されている方法は、ここで文書化された種類の攻撃の成功の重要な部分です。登録バインディングを制限する代替手段は、登録を実行するネットワーク要素にのみバインドすることを可能にします。おそらく、登録要求で観察された輸送アーティファクトを優先して、連絡先で提供されたビットを無視することが極端になりました。[アウトバウンド]で定義されているメカニズム）。このようなメカニズムは将来再び考慮されるかもしれませんが、現在、現在の脅威に対処するために不十分に開発されています。
Deprecate forking: This attack does not exist in a system that relies entirely on redirection and initiation of new requests by the original endpoint. Removing such a large architectural component from the system at this time was deemed too extreme a solution.
Deprecate Forking：この攻撃は、元のエンドポイントによる新しい要求のリダイレクトと開始に完全に依存するシステムには存在しません。この時点で、このような大きな建築コンポーネントをシステムから削除することは、あまりにも極端な解決策と見なされました。
Don't reclaim breadth: An alternative design of the Max-Breadth mechanism that was considered and rejected was to not allow the breadth from completed branches to be reused (see Section 5.3.3.1). Under this alternative, an introduced request would cause, at most, the initial value of Max-Breadth transactions to be generated in the network. While that approach limits any variant of the amplification vulnerability described here to a constant multiplier, it would dramatically change the potential reach of requests, and there is belief that it would break existing deployments.
幅を取り戻さないでください：考慮され拒否された最大巻きメカニズムの代替設計は、完成した枝からの幅を再利用できるようにしないことでした（セクション5.3.3.1を参照）。この代替案では、導入された要求が、せいぜいネットワークで最大ブレッドトランザクションの初期値を生成することになります。このアプローチは、ここで説明されている増幅脆弱性のバリアントを一定の乗数に制限しますが、要求の潜在的な範囲を劇的に変化させ、既存の展開を破るという信念があります。
Thanks go to the implementers that subjected their code to this scenario and helped analyze the results at SIPit 17. Eric Rescorla provided guidance and text for the hash recommendation note.
このシナリオにコードをかけ、SIPIT 17での結果の分析を支援した実装者に感謝します。EricRescorlaは、ハッシュ推奨ノートのガイダンスとテキストを提供しました。
[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月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[DESIGN] Hilt, V., "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Work in Progress, July 2008.
[Design] Hilt、V。、「セッション開始プロトコル（SIP）過負荷制御のための設計上の考慮事項」、2008年7月の進行中の作業。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, October 2008.
[Autbound] Jennings、C。and R. Mahy、「マネージングクライアントはセッション開始プロトコル（SIP）で接続を開始しました」、2008年10月、進行中の作業。
[REQS] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", Work in Progress, July 2008.
[Reqs] Rosenberg、J。、「セッション開始プロトコルにおける過負荷の管理の要件」、2008年7月の作業。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC2543] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INITIATION Protocol」、RFC 2543、1999年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
Authors' Addresses
著者のアドレス
Robert Sparks (editor) Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
ロバートスパークス（編集者）テケレック17210キャンベルロードスイート250ダラス、テキサス75254-4203 USA
EMail: RjS@nostrum.com
Scott Lawrence Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA
Scott Lawrence Nortel Networks、Inc。600 Technology Park Billerica、MA 01821 USA
Phone: +1 978 288 5508
EMail: scott.lawrence@nortel.com
Alan Hawrylyshen Ditech Networks Inc. 823 E. Middlefield Rd Mountain View, CA 94043 USA
Alan Hawrylyshen Ditech Networks Inc. 823 E. Middlefield Rd Mountain View、CA 94043 USA
Phone: +1 650 623 1300
EMail: alan.ietf@polyphase.ca
Byron Campen Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
バイロン・カンペン・テケレック17210キャンベル・ロード・スイート250ダラス、テキサス75254-4203 USA
EMail: bcampen@estacado.net