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
                                                           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 ( 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ドキュメント(ライセンス情報)に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。



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.


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
         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
1. Introduction
1. はじめに

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.


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.


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.


2. Conventions and Definitions

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]に記載されているように解釈されます。

3. Vulnerability: Leveraging Forking to Flood a Network

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.


                                   /       \
                                 /           \
                               /               \
                             /                   \
                          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


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フォーク各パスの終わりに)。

                        |  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


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.


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.


4. Updates to
4.1. Strengthening the Requirement to Perform Loop Detection
4.1. ループの検出を実行するための要件を強化

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.


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.


4.2. Correcting and Clarifying the Loop-Detection Algorithm
4.2. ループ検出アルゴリズムを修正し、明確化
4.2.1. Update to
4.2.1. Updateへ

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のすべてを置き換えます。

8. Add a Via Header Field Value

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 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 will result in a branch parameter that will be different for different instances of a spiraled or looped request through a proxy.


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 The second part is used to perform loop detection and distinguish loops from spirals.


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.


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を参照)、それらを処理するサーバーにそれらの要求を相関に使用されています。

4.2.2. Update to
4.2.2. Updateへ

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のすべてを置き換えます。

4. Loop-Detection Check

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(ループ検出)応答で要求を拒絶しなければなりません。値が異なる場合、リクエストはスパイラルされ、処理は次のステップに進みます。

4.2.3. Impact of Loop Detection on Overall Network Performance
4.2.3. ネットワーク全体のパフォーマンス上のループ検出の影響

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です。

4.2.4. Note to Implementers
4.2.4. 実装者への注意

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.


5. Max-Breadth
5.1. Overview
5.1. 概要

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.


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-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.


5.2. Examples
5.2. 例
    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

マックス - 幅と一緒に作業するマックス・フォワード

5.3. Formal Mechanism
5.3. 正式なメカニズム
5.3.1. Max-Breadth Header Field
5.3.1. マックス・横幅ヘッダーフィールド

The Max-Breadth header field takes a single positive integer as its value. The Max-Breadth header field value takes no parameters.


5.3.2. Terminology
5.3.2. 用語

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.


5.3.3. Proxy Behavior
5.3.3. プロキシの挙動

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.


All proxied requests MUST contain a single Max-Breadth header field value.


SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the Incoming Max-Breadth in a given response context.


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.


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プロキシは、アクティブブランチ間の任意の様式で最大幅を分配することができます。プロキシは、受信最大幅がプロキシの最大許容値を超えない限り、元の要求に存在していたよりも最大巾のより少ない量を使用すべきではありません。プロキシは、各ホップのためにマックス - 幅をデクリメントまたはその他の要求の伝播の「深さ」を制限するためにそれを使用してはなりません。 Reusing 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.

最終的な応答を受け取った転送要求が最終的な応答が到着するたび発信マックス広さ、にはカウントされませんので、そのブランチで使用されていたマックス - 幅は再利用のために利用可能になります。プロキシは、ターゲットセットに残っ要素が存在し得る場合には、この最大幅を再使用するために準備されるべきです。

5.3.4. UAC Behavior
5.3.4. UACの動作

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.


5.3.5. UAS Behavior
5.3.5. その振る舞い

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.


5.4. Implementer Notes
5.4. 実装者ノート
5.4.1. Treatment of CANCEL
5.4.1. CANCELの治療

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.


5.4.2. Reclamation of Max-Breadth on 2xx Responses
5.4.2. 2xx応答のマックス・横幅の干拓

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.


5.4.3. Max-Breadth and Automaton UAs
5.4.3. マックス - 幅とオートマトンのUA

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.


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.


5.5. Parallel and Sequential Forking
5.5. パラレルおよびシーケンシャルフォーク

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まで低下します。

5.6. Max-Breadth Split Weight Selection
5.6. マックス・横幅スプリット重み選択

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]を使用している知っている場合、これは、例えば、適切であろう。

5.7. Max-Breadth's Effect on Forking-Based Amplification Attacks
5.7. フォークに基づく増幅の攻撃にマックス・横幅の影響

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.


5.8. Max-Breadth Header Field ABNF Definition
5.8. マックス・横幅ヘッダーフィールドABNFの定義

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

6. IANA Considerations
6. IANAの考慮事項

This specification registers a new SIP header field and a new SIP response according to the processes defined in [RFC3261].


6.1. Max-Breadth Header Field
6.1. マックス・横幅ヘッダーフィールド

This information appears in the Header Fields sub-registry of the SIP Parameters registry.


RFC 5393 (this specification)

RFC 5393(この仕様)

Header Field Name: Max-Breadth


Compact Form: none


6.2. 440 Max-Breadth Exceeded Response
6.2. 440マックス・横幅超過レスポンス

This information appears in the Response Codes sub-registry of the SIP Parameters registry.


Response code: 440


Default Reason Phrase: Max-Breadth Exceeded


7. Security Considerations

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]).


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.


7.1. Alternate Solutions That Were Considered and Rejected
7.1. みなされ、拒否された代替ソリューション

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.


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 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.


8. Acknowledgments

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エリックレスコラで結果を分析助けたハッシュ推奨ノートの指導やテキストを提供しました。

9. References
9.1. Normative References
9.1. 引用規格

[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月。

9.2. Informative References
9.2. 参考文献

[DESIGN] Hilt, V., "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Work in Progress, July 2008.


[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, October 2008.


[REQS] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", Work in Progress, July 2008.


[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



Scott Lawrence Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA

スコット・ローレンスノーテルネットワークス株式会社600テクノロジーパークビレリカ、MA 01821 USA

Phone: +1 978 288 5508 EMail:

電話:+1 978 288 5508 Eメール

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:

電話:+1 650 623 1300 Eメール

Byron Campen Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA

バイロンCampen Tekelec 17210キャンベル道スイート250、ダラス、テキサス州75254から4203 USA