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
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.
著作権（C）2008 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
このドキュメントは、規範的にアップデートはRFC 3261、セッション開始プロトコル（SIP）は、SIPプロキシの動作で識別されたセキュリティ上の脆弱性に対処します。この脆弱性は、さらに、許可、正当な少数のは、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、および録音は、@ P1、Bの@のP1、P2の@、およびb @ P2の4つのアドレスを考えてみましょう。 （省略さ非本質的な詳細）を次のように通常のREGISTER要求を使用して、これらの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>
P1 SIP / 2.0：<SIP：B @ P1>連絡先：<SIP：@のP2>、<SIP：B @ P2> SIPレジスタ
REGISTER sip:P2 SIP/2.0 To: <sip:a@P2> Contact: <sip:a@P1>, <sip:b@P1>
P2 SIP / 2.0：<SIP：@のP2>連絡先：<SIP：@のP1>、<SIP：B @ P1> SIPレジスタ
REGISTER sip:P2 SIP/2.0 To: <sip:b@P2> Contact: <sip:a@P1>, <sip:b@P1>
P2 SIP / 2.0：<SIP：B @ P2>連絡先：<SIP：@のP1>、<SIP：B @ P1> SIPレジスタ
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のいずれかにINVITEリクエストをご紹介し、@のP1を言います。この要求は、それほどの8つのP2によって処理メッセージ、及びにフォークうP1によって処理4つのリクエストにフォークうP2によって処理2つの要求にフォークであろう。このメッセージフローは、図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つのプロキシは、3261件の勧告のフォローのRFCを関与した場合、ツリーは2 ^ 71-1の要求を表す、深い70行となります。リクエストのツリー全体の価値を処理する時間は、いずれかのプロキシで長いタイマーC以上であれば、メッセージの実際の数ははるかに大きくなることがあります。この場合には、408の応答の嵐および/または要求をキャンセルの嵐はまた、INVITE要求とともにツリーを通って伝播されるであろう。 （シナリオの終わり近くに、少なくとも2 ^ 70同時にアクティブ・トランザクション）、それは見ているすべてのトランザクションの状態を保持するためにそれぞれ有する - このシナリオに関与する唯一の2つのプロキシがあることを覚えておいてください。
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比較の一部として使用されていない場合、攻撃は、一つのサーバに一つのアカウントに簡略化することができます。すべてのURIパラメータはContactヘッダーフィールドからのURIロケーションサービスでそれを見て前に、そのURIから除去されなければならないRFC 3261の任務は、URIの平等を使用して比較しているので、以下の登録が使用して、この攻撃を設定するには十分なものでなければなりません単一のアカウントへの単一のREGISTERリクエスト：
REGISTER sip:P1 SIP/2.0 To: <sip:a@P1> Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud>
<SIP：@のP1;未知-PARAM =ドサッ>;にP1 SIP / 2.0：<SIP：@のP1>連絡先：<不明-PARAM =強打する@ P1 SIP> SIPレジスタ
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）セッションの間に、実際に実現しました。シナリオはつ以上のプロキシを含むように拡張、及び参加プロキシすべての攻撃を構築するメッセージの一握り後、20よりも大きくないことがないように最大前方に制限された、参加プロキシはお互いに衝突し始めました。実験は実行が許可された数時間から外挿すると、シナリオがすぐ下に10日間で完了しているだろう。プロキシが3261は70のマックス・フォワード値をお勧めします、そして、彼らが開催された状態が増加するにつれて、彼らは直線的に行っ仮定RFCを使用していた、それが攻撃を開始し、単一のINVITEリクエストの処理を完了するために、3000000000000年かかったでしょう。 （彼らはリブートして登録状態を維持している限り）、いくつかのプロキシがシナリオ中に再起動し、それらが再起動したときに、攻撃に復帰していることに注意することは興味深いことです。これは、この攻撃は大で、インターネット上で開始されたならば、それはそれを停止するために、影響を受けるすべての要素間の調整を必要とするかもしれないことを指摘しています。
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に減少するであろう、一つのサーバを含む変形例では、刺激されたメッセージの数が10に減少するであろう）が、そこ単独のループ検出が不十分な保護である複数のAORを使用して、攻撃のバリエーションがあります。この変形例では、それぞれが他のすべての参加のAORにAORフォーク参加。得られたツリーを介して参加する（例えば10）のAOR、パスの少数のメッセージの非常に多数が生成されていないループであろうまで。現在利用可能なネットワーク上で、このような攻撃を開始するための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を提供未満又は最大転送しに等しい場合、実際には、攻撃によって生成されたトラフィックの量は、関与するすべてのプロキシがループ検出を実行している場合であっても〕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のAORのセットを、持っていると仮定します。明確にするために、攻撃が始まる場所AOR 1であると仮定します。残りのN-1のAORのすべての順列を定義し、出て再生されます（N-1）！任意のAORを繰り返すことなく異なるパス。次いで、これらの経路の各々は、N個の方法を最後の時間をフォークし、ループは、これらのブランチの各々で検出されるであろう。これらの最後の枝だけで合計N！要求（（N-1）！パス、Nフォーク各パスの終わりに）。
___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.
シナリオの全てにおいて、向けられているトラフィックの膨大な量になり、各フォークプロキシで、追加の分岐が（つまりも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.
唯一の場所にリクエストを転送するSIPプロキシは、ループ検出を行うことができるが、する必要はありません。唯一の場所に転送する際に、利用される増幅リスクは存在せず、（分岐しないながらによる最大転送し排気に定乗数を常に念頭に置いておく）MAX-を転送機構は、それが設計された程度にネットワークを保護します。以前にそのリクエストをフォーク状（ループ検出を行う）ネットワークを介してその進行を有することが起こった場合でも、単一の場所にリクエストを転送するとき、プロキシは、ループ検出を実行するために必要とされません。
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).
このセクションでは、（項目8ページ105で始まり、RFC 3261の106ページ終了）RFC 3261のセクション16.6の項目8のすべてを置き換えます。
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.
プロキシはヘッダーフィールド値を経由して、既存の前に、コピーにViaヘッダーフィールド値を挿入しなければなりません。この値の構築はセクション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.
このセクションの説明の残りの部分は、これらの二つの部分が存在することを前提としています。プロキシは他のいくつかのメカニズムを採用することを選択した場合、これら二つの部分の上に置い要件によって定義された検出特性が達成されていることを確認するために実装者の責任です。
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.
この第二の部分は、リターゲット、またはこの要求を転送する場所を決定する際に、ロケーション・サービス・ロジックによって使用される任意のフィールドに変化しなければなりません。これは、要求の処理に影響を与える値のいずれも変化していない場合は、プロキシが認識できるようにすることで、スパイラルからループしたリクエストを区別する必要があります。したがって、第二部は、受信した要求-URIと、受信した要求を処理する際に使用される任意のRouteヘッダーフィールド値に少なくとも依存しなければなりません。実装者は、その特定の実装ではロケーション・サービス・ロジックによって使用されるすべてのフィールドを含めるように世話をする必要があります。
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).
この第二部ではリクエストメソッドに応じて変動してはなりません。 CANCELと非200のACK要求は、彼らがキャンセル対応する要求と同じブランチパラメータ値を持っているか確認する必要があります。この分岐パラメータ値は（セクション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（項目RFC 3261の95ページ4が表示されます）のセクション16.3の項目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によってループ検出を実行するために必要なプロキシは、要求を転送する前に、次のループ検出テストを実行する必要があります。送信-によって値がこのプロキシによって以前の要求の中に入れた値と一致した場合、この第2の部分は存在しないRFC 5393.のセクション4.2.1で定義された「第二部」を検査しなければならない要求のヘッダフィールド値を介してそのViaヘッダーフィールド値を加えたときにメッセージが二股されませんでした。第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.
リクエストをフォークする際分岐パラメータ値の第二の部分を作成するための一般的な方法は、リクエストURIの連結を介して要求を処理中に使用される任意のRouteヘッダフィールド値、および位置で使用される他の値をハッシュを計算することですサービスロジックは、この要求を処理中。これらのパラメータの二つの別個のセットが衝突する低い確率が存在するようにハッシュが選択されるべきです。比較する必要がある入力の最大数は70であるため、衝突の可能性は、比較的小さなハッシュ値と32ビットのような低いです。 MD5 [RFC1321]であるように[RFC4960]で指定されるようにCRC-32cは、特定的に許容される関数です。 MD5は、非暗号化特性のために純粋に選択されていることに留意されたいです。ハッシュ衝突を生成するために入力を制御することができ、攻撃者は、他のさまざまな方法で接続を攻撃することができます。ハッシュを用いて第2の部分を形成する場合、実装は、ハッシュが衝突べき繰り返し失敗を回避するために、同じ宛先に到達しようとする異なるトランザクション間で変化するハッシュへの入力に少なくとも一つのフィールドを含むべきです。コール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ヘッダフィールド値の内容に反対パーサに起因していました。実装者はいない値を持つパラメータ、未知のパラメータ名とヘッダフィールド値を解析し、特に、RFC 3261によってその形式に配置され、基本的な制約を超えた別の要素のViaヘッダーフィールド値の形式についての仮定をすることを避けるために世話をする必要がある、または引用符で囲まれた文字列の有無にかかわらず、パラメータ値は、失敗する実装を引き起こしてはなりません。
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.
、除去難読化、またはそれを転送する前に受信した要求のViaヘッダフィールド内の分岐パラメータ値を変更する他の方法でループ検出を実行するためにメッセージにそのブランチパラメータを置いノードの能力を除去します。ループに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.
ここで定義された最大巾機構は二股SIPリクエストによって引き起こされる同時分岐の総数を制限します。このメカニズムでは、すべてproxyable要求は、それがその現在の位置から転送されるように、この要求は、パラレルフォーキングを介して出現することができる同時分岐の最大数を表す正の整数最大横幅の値を割り当てられます。プロキシは、要求を転送するとき、その最大横幅値は、発信要求の間で分割されます。ターンでは、転送された要求のそれぞれは、それが出現することがどのように多くの同時枝に制限されています。必要に応じて枝を完全として、マックス・横幅値のその部分は、その後の枝のために利用可能になります。所望の平行フォークを行うには不十分最大横幅がある場合、プロキシは、本文書で定義された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.
このメカニズムは、マックス・フォワードから独立して動作します。最大転送し、それがそれが二股された各宛先への発信ポイントから転送される要求が横断することができる木の深さを制限します。第3に示すように、さらに限定された深さのツリー内の分岐の数は、フォークを活用することにより、（深さ指数）を大きくすることができます。そのようなそれぞれの枝には、それに関連付けられているSIPトランザクション・ステート・マシンのペアを持っています。最大横幅機構は、時間内の任意の所与の時点でアクティブである分岐の数（トランザクション状態マシンを実行しているもの）を制限します。
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.
マックス - 幅はフォーク防ぐことはできません。それだけで、同時並列フォーク分岐の数を制限します。具体的には、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（最大-横幅超過）の応答を受信するクライアントは、その要求は、すべての可能な宛先に到達しなかったことを推測することができます。リカバリー・オプションは、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は、マックス・横幅MF ==マックス-前方に==します
| 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
マックス - 幅と一緒に作業するマックス・フォワード
The Max-Breadth header field takes a single positive integer as its value. The Max-Breadth header field value takes no parameters.
最大巾のヘッダフィールドは、その値として単一の正の整数をとります。最大巾ヘッダフィールド値はパラメータを取りません。
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つの正の整数値を定義します。着信最大幅は応答コンテキストを形成要求における最大巾のヘッダフィールドの値です。発信最大幅は、最終的な応答を受信していない応答コンテキスト内のすべての転送リクエストにおける最大巾ヘッダフィールド値の和です。
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プロキシがない最大巾ヘッダフィールド値を持つリクエストを受信した場合、それは60であることが推奨される最大許容着信最大横幅値を有していなければならない60プロキシすることが推奨されている値と、を追加しなければなりません。この最大値は、受信したリクエストに超えている場合、プロキシはその許容最大値よりも大きくてはならない値で上書きしなければなりません。
All proxied requests MUST contain a single Max-Breadth header field value.
すべてのプロキシ要求は、1つのマックス・横幅ヘッダフィールド値を含まなければなりません。
SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the Incoming Max-Breadth in a given response context.
SIPプロキシは、発信最大幅が所定の応答コンテキストで着信最大幅を超えないようにしなければなりません。
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プロキシは応答コンテキストを決定した場合、所望の平行フォークを行うには不十分着信最大幅を有し、プロキシが直列分岐またはリダイレクトを送信することによって補償することができない/不本意であり、そのプロキシは、超過440（最大幅を返さなければなりません）応答。
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のみフォークシリアル、すべてでフォークする必要はありませんすることができますのマックス・幅広さとの要求を受け取るプロキシを意味することに注意してください - それは代わりに440を返すことができます。したがって、この機構は、ユーザエージェントが直列フォークにリクエストのパス内のすべてのプロキシを強制するために使用できるツールはありません。
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プロキシは、アクティブブランチ間の任意の様式で最大幅を分配することができます。プロキシは、受信最大幅がプロキシの最大許容値を超えない限り、元の要求に存在していたよりも最大巾のより少ない量を使用すべきではありません。プロキシは、各ホップのためにマックス - 幅をデクリメントまたはその他の要求の伝播の「深さ」を制限するためにそれを使用してはなりません。
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）の動作には影響を与えません。要求の処理中に最大巾ヘッダフィールドで要求を受信する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.
要求がプロキシされることはないCANCELので、最大巾ヘッダフィールド値はCANCEL要求に無意味です。送信最大幅は、関連するINVITE応答文脈において決してCANCEL影響送ります。決してCANCELを受信すると、関連INVITE応答コンテキストの着信マックス・広さに影響を与えます。
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つあります。プロキシは、INVITEリクエストを転送し、単一のために複数の2xx応答を受け取ることができます。また、[RFC2543]の実装は、同じブランチ上の2xx続いた6xxを送り返すことができます。彼らは、INVITEリクエストに対する2xx応答を受信したときに発信マックス広さから差し引く実装は、単一の分岐に対して複数回引くことによって引き起こされたバグを避けるために注意しなければなりません。
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.
（型B2BUA、ゲートウェイ、発破、及びプログラム着信SIPトラフィックの結果として、要求を送信し、他の要素を含む）オートマトンユーザエージェント（UAS）の設計者は、最大横幅の制限が発信要求に置かれるべきかどうかを検討すべきです。例えば、結果として送信される要求に着信要求から最大巾値を運ぶために型B2BUAを設計することは合理的です。
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.
このメカニズムの定義に固有順次フォークながら配分最大幅を再利用するプロキシの能力です。出マックス・横幅の制限は、同時枝にのみ適用されます。
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つの目標を持っている場合、送信最大合計1の最大巾で最初にこれらのターゲットの4（各々にフォークを平行にすることができるそのプロキシ、 4の-Breadth）。これらのトランザクションの1つが失敗応答で完了した場合、発信最大幅はプロキシが（1の最大巾と、再び）4つの残りのターゲットの一つに転送することができ、3まで低下します。
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アウトバウンド拡張[OUTBOUND]を使用している知っている場合、これは、例えば、適切であろう。
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)
要求が伝播することができる（ホップで測定）の距離に何ら制約を配置しないながら最大幅は、任意の時点で特定の要求によって生成された活性分岐の総数を制限します。 （すなわち、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
マックス・横幅=「マックス・広さ」HCOLON 1 * DIGIT
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
ヘッダーフィールド名：マックス・横幅
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
デフォルトの理由フレーズ：マックス横幅超過
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.
ここで定義されたマックス・横幅メカニズムはフォークループ攻撃によって引き起こされる集約トラフィックを減少させません。それだけで同時に処理されている同時枝の数を制限することによって、より長い期間にわたって攻撃によって引き起こされたトラフィックを分散するのに役立ちます。攻撃者は、マックス・横幅・メカニズムを使用し、徐々に不合理なレベルへのトラフィックを構築するネットワークに複数の要求を送り出すことができました。展開は慎重に監視し、この可能性から保護するために与えられたリソースに関連する同時の未処理のトランザクションの数の緩やかな増加に反応する必要があります。オペレータは一時的な攻撃に使用されているものとして識別されたリソースを無効にすることができるという予想する必要があります。抜群の同時トランザクションシステム全体の急速な増加は、多くのリソース全体でこの種の攻撃の存在の指標かもしれません。攻撃者は、リソースの非常に大きな数を取得することが可能である展開は特に危険です。検出し、攻撃の各インスタンスに介在する負荷を軽減するには不十分である場合、過負荷が発生する可能性があります。
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ネットワークへ、およびプロトコル変換のいずれかの側に要求の履歴に関する情報が失われ、それが可能となりますマックス・転送したりループ検出のいずれもから守ることができ、ループを構築しました。メカニズムはここにいない攻撃で同時メッセージの数を制限する点に、和らげるません。この文書に記載されているように、これは、ループのSIP側の増幅をフォークと組み合わされ、攻撃をもたらすであろう。これらの考慮事項は、（例えば、型B2BUAに見られるような）SIPからSIPへのゲートウェイの設計者にとって特に重要です。多くの既存のB2BUAの実装では、双方が可能として、それらとの通信に関する多くの情報を非表示にするには、いくつかの圧力を受けています。そのような実装の実装は、ループ（または、この攻撃の形態を検出するための責任を取って、ネットワーク内でループ検出、最大転送し、または他の点で最大巾機構によって使用されるかもしれないデータを除去するように誘惑することができます）。二つのそのような実装は、攻撃に関与している場合は、どちらもそれを検出することができなくなります。
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.
何もしない - 犯罪者の訴えに頼る：アカウントを持っているシステムでは、乱用者を見つけるために採掘可能なログを持っているが、この文書で説明する攻撃に対して信頼できる抑止力や防御力を提供することは明らかではありません。状況を認識し、是正/予防措置を講じていないシステムでは、攻撃の設定を文書レコードの検索を排除する大きさの失敗を経験する可能性が高いです。 （一方のシナリオでは、登録は、INVITEトランザクションより根本的に異なる時間に起こり得る。INVITE要求自体が無実から来ていることができます）。これは、シナリオが意図せずに設定することができることも可能です。さらに、いくつかの既存の展開のために、アカウントのコストと監査能力は、単に電子メールアドレスです。誰かが処罰する見つけることができない場合があります。最後に、法的措置のいかなる脅威に応答しないだろう、とこの種の攻撃の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.
最大転送しに小さなキャップを置く：攻撃の影響は、初期最大転送し値に対して指数関数的です。この値を下に回すと、攻撃の効果を制限します。これは厳しく、おそらく既存のアーキテクチャは失敗し始めますポイントに、ネットワーク内の要求の範囲を制限するのを犠牲にしています。
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.
任意の連絡先に登録バインディングを許可しない：登録バインディングが現在定義されている方法は、ここでは文書化され、攻撃の種類の成功の重要な部分です。のみ多分登録要求に観察されたトランスポート・アーチファクトを支持して接して設けられたビットを無視する極端に、登録を行うネットワーク要素への結合を可能にするために登録バインディングを制限する代替法は、特にの文脈で（考察されています[OUTBOUND]）で定義されている機構。このようなメカニズムは、将来的に再び考慮することができるが、現在は不十分現在の脅威に対処するために開発されています。
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.
廃止フォーク：この攻撃は、元のエンドポイントでのリダイレクトと新しい要求の開始に完全に依存しているシステムに存在しません。この時点で、システムからそのような大型建築成分を除去することは、あまりにも極端な解決策を考えられました。
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エリックレスコラで結果を分析助けたハッシュ推奨ノートの指導やテキストを提供しました。
[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月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[DESIGN] Hilt, V., "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Work in Progress, July 2008.
[デザイン]柄、V.、進歩、2008年7月に仕事「セッション開始プロトコル（SIP）過負荷制御の設計上の考慮点」。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, October 2008.
[OUTBOUND]ジェニングス、C.とR.マーイ、進歩、2008年10月に作品「セッション開始プロトコル（SIP）でのクライアント開始された接続の管理」を参照してください。
[REQS] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", Work in Progress, July 2008.
[REQS]ローゼンバーグ、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]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
Authors' Addresses
著者のアドレス
Robert Sparks (editor) Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
ロバート・スパークス（エディタ）Tekelec 17210キャンベル道スイート250、ダラス、テキサス州75254から4203 USA
EMail: RjS@nostrum.com
メールアドレス：RjS@nostrum.com
Scott Lawrence Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA
スコット・ローレンスノーテルネットワークス株式会社600テクノロジーパークビレリカ、MA 01821 USA
Phone: +1 978 288 5508 EMail: scott.lawrence@nortel.com
電話：+1 978 288 5508 Eメール：scott.lawrence@nortel.com
Alan Hawrylyshen Ditech Networks Inc. 823 E. Middlefield Rd Mountain View, CA 94043 USA
アランHawrylyshen Ditechネットワークス株式会社823 E.ミドルRdのマウンテンビュー、CA 94043 USA
Phone: +1 650 623 1300 EMail: alan.ietf@polyphase.ca
電話：+1 650 623 1300 Eメール：alan.ietf@polyphase.ca
Byron Campen Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
バイロンCampen Tekelec 17210キャンベル道スイート250、ダラス、テキサス州75254から4203 USA
EMail: bcampen@estacado.net
メールアドレス：bcampen@estacado.net