RFC5393 日本語訳
5393 Addressing an Amplification Vulnerability in Session InitiationProtocol (SIP) Forking Proxies. R. Sparks, Ed., S. Lawrence, A.Hawrylyshen, B. Campen. December 2008. (Format: TXT=48722 bytes) (Updates RFC3261) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
エド、ネットワークワーキンググループR.をスパークさせます。コメントのために以下を要求してください。 5393のTekelecアップデート: 3261秒間ローレンスCategory: 標準化過程ノーテルは株式会社B.Campen Tekelec2008年12月にInc.A.Hawrylyshen Ditechネットワークをネットワークでつなぎます。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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.
このドキュメントは標準にRFC3261をアップデートします、Session Initiationプロトコル(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.
彼らが要求(すなわち、1つ以上の目的地に要求を転送する)を分岐させるとき、このドキュメントはSIPプロキシに関する輪検出要件を強化します。 また、それは、そのようなプロキシが実装していなければならない輪検出アルゴリズムの記述を修正して、はっきりさせます。 さらに、このドキュメントは、どんな与えられた要求のためにも追求された同時発生のブランチの数を制限するためにマックス-幅のメカニズムを定義します。
Sparks, et al. Standards Track [Page 1] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[1ページ]。
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
1. 序論…3 2. コンベンションと定義…3 3. 脆弱性: ネットワークをあふれさせるように分岐しながら、力を入れます…3 4. RFC3261に、アップデートします。7 4.1. 働くという要件を強化して、検出を輪にしてください…7 4.2. RFC3261輪検出アルゴリズムを修正して、はっきりさせます…7 4.2.1. セクション16.6に、アップデートします。7 4.2.2. セクション16.3に、アップデートします。8 4.2.3. 総合的なネットワークパフォーマンスの輪の検出の影響…9 4.2.4. Implementersに、注意します。9 5. マックス-幅…10 5.1. 概要…10 5.2. 例…11 5.3. 正式なメカニズム…12 5.3.1. マックス-幅のヘッダーフィールド…12 5.3.2. 用語…13 5.3.3. プロキシの振舞い…13 5.3.3.1. マックス-幅を再利用します…14 5.3.4. UACの振舞い…14 5.3.5. UASの振舞い…14 5.4. Implementer注意…14 5.4.1. キャンセルの処理…14 5.4.2. 2xx応答のマックス-幅の改善…14 5.4.3. マックス-幅とオートマトンUAs…14 5.5. 平行で連続した分岐…15 5.6. マックス-幅は重さの選択を分けました…15 5.7. 分岐ベースの増幅へのマックス-幅の効果は攻撃されます…15 5.8. マックス-幅のヘッダーフィールドABNF定義…16 6. IANA問題…16 6.1. マックス-幅のヘッダーフィールド…16 6.2. 440 マックス-幅は応答を超えていました…16 7. セキュリティ問題…16 7.1. 考えられて、拒絶されたソリューションを交替してください…17 8. 承認…19 9. 参照…19 9.1. 標準の参照…19 9.2. 有益な参照…19
Sparks, et al. Standards Track [Page 2] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[2ページ]。
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.
このドキュメントは、この脆弱性を扱うためにSIPプロトコルへの標準の変化を指定します。 SIPプロキシが1つ以上の目的地に要求を分岐させるときのこのアップデートに従って、それが、要求輪に参加していないのを保証するのに必要です。
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.
この標準のアップデートだけが、ここで説明された攻撃の作られた変化から守るためにはRecord(AORs)の複数のAddressesにかかわるのにおいて不十分です。 さらに脆弱性を扱うなら、このドキュメントは、股状の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.
このアップデートにおけるメカニズムは少ない数のリソースを使用するここで説明された攻撃の変化から守るでしょう、偶然のmisconfigurationを通して起こるほとんどの意図的でない自己によって加えられた変化を含んでいて。 しかしながら、十分な数の異なったリソースへのアクセスの攻撃者はまだ非常に多くのメッセージを刺激できるでしょう。 同時発生のメッセージの数がマックス-幅のメカニズムによって制限されるので、全体のセットは長期の間、時間の普及になるでしょう、攻撃を検出して、プロトコルの外で善後策を講じるより良い機会をオペレータに与えて。 今後のプロトコル仕事が、攻撃のこのフォームを防ぐのに必要です。
2. Conventions and Definitions
2. コンベンションと定義
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Vulnerability: Leveraging Forking to Flood a Network
3. 脆弱性: ネットワークをあふれさせるように分岐しながら、力を入れます。
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の異なったRFC3261対応することのプロキシ/記録係サーバに関する2つのアカウントが利用可能です。 この仮定で、攻撃に必要ではありませんが、シナリオを表すのは、より簡単になります。 ただ一つのサーバに関するただ一つのアカウントで同じ攻撃を実現できます。
Sparks, et al. Standards Track [Page 3] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[3ページ]。
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プロキシ/記録係がRecord、 a@P1 、 b@P1 、 a@P2 、および b@P2 のサービスと、P1と、P2と、4Addressesであると考えてください。 通常のREGISTER要求を使用して、以下のこれらのAORs(削除された不要不急な詳細)に結合を確立してください:
REGISTER sip:P1 SIP/2.0
To: <sip:a@P1>
Contact: <sip:a@P2>, <sip:b@P2>
レジスタ一口: P1一口/2.0To: <一口: a@P1 、gt;、接触: <一口: a@P2 、gt;、<一口: b@P2 、gt。
REGISTER sip:P1 SIP/2.0
To: <sip:b@P1>
Contact: <sip:a@P2>, <sip:b@P2>
レジスタ一口: P1一口/2.0To: <一口: b@P1 、gt;、接触: <一口: a@P2 、gt;、<一口: b@P2 、gt。
REGISTER sip:P2 SIP/2.0
To: <sip:a@P2>
Contact: <sip:a@P1>, <sip:b@P1>
レジスタ一口: P2一口/2.0To: <一口: a@P2 、gt;、接触: <一口: a@P1 、gt;、<一口: b@P1 、gt。
REGISTER sip:P2 SIP/2.0
To: <sip:b@P2>
Contact: <sip:a@P1>, <sip:b@P1>
レジスタ一口: P2一口/2.0To: <一口: b@P2 、gt;、接触: <一口: a@P1 、gt;、<一口: b@P1 、gt。
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.
これらの結合が適所にあった状態で、4AORsのどれかにINVITE要求を紹介してください、そして、 a@P1 を言ってください。 この要求はP2によって扱われた2つの要求に分岐するでしょう。P2はP2によって扱われた8つのメッセージに分岐するP1などによって扱われた4つの要求に分岐するでしょう。 このメッセージ流動は図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
/\ /\ /\ /\ /\ /\ /\ /\
.
.
.
| 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: 攻撃要求伝播
Sparks, et al. Standards Track [Page 4] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[4ページ]。
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つのプロキシがRFC3261推薦の後をつけると、木は深く70の行になるでしょう、2^71-1の要求を表して。 全体の木の要求の価値を処理する時間がTimer Cより長い間プロキシにあるなら、メッセージの実数ははるかに大きいかもしれません。 また、この場合、408の応答の嵐、そして/または、キャンセル要求の嵐はINVITE要求に伴う木を通して伝播されるでしょう。 このシナリオにかかわる2つのプロキシしかなかったのを覚えていてください--それぞれそれが見るすべてのトランザクション(シナリオの終わり頃の少なくとも2^70の同時にアクティブなトランザクション)のための状態を保持しなければならないこと。
The attack can be simplified to one account at one server if the service can be convinced that contacts with varying attributes (parameters, schemes, embedded headers) are sufficiently distinct, and these parameters are not used as part of AOR comparisons when forwarding a new request. Since RFC 3261 mandates that all URI parameters must be removed from a URI before looking it up in a location service and that the URIs from the Contact header field are compared using URI equality, the following registration should be sufficient to set up this attack using a single REGISTER request to a single account:
サービスが異なった属性(パラメタ(体系)はヘッダーを埋め込んだ)との接触が十分異なっていると確信できるなら、1つのサーバで1つのアカウントに攻撃を簡素化できます、そして、新しい要求を転送するとき、これらのパラメタはAOR比較の一部として使用されません。 RFC3261が、位置のサービスでそれを調べる前に、URIからすべてのURIパラメタを取り除かなければならなくて、ContactヘッダーフィールドからのURIが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>
レジスタ一口: P1一口/2.0To: <一口: a@P1 、gt;、接触: <一口: a@P1;unknown-param は強打>、<一口と等しいです: a@P1;unknown-param は地響きの>と等しいです。
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 Interoperability Test(SIPit)セッションの1つの間、実現されました。 シナリオは2つ以上のプロキシを含むように広げられました、そして、参加しているプロキシは皆、20より大きくならないように前方へマックスを制限しました。 攻撃を構成する一握りのメッセージの後に、参加しているプロキシは互いを砲撃し始めました。 実験が実行できた数時間から推定して、シナリオはちょうど10未満で何日も完成したでしょう。 70の前方へマックス値が推薦されて、彼らが保持した状態が増加するのに従って彼らが直線的に働いたと仮定しながらプロキシがRFC3261を使用したなら、攻撃を開始したただ一つのINVITE要求の処理を終了するには3兆年かかったでしょうに。 彼らが再開したとき(彼らがリブートの向こう側に登録状態を維持した限り)、いくつかのプロキシがシナリオの間、リブートして、攻撃で再び加わったことに注意するのはおもしろいです。 これは、この攻撃が全体のインターネットで着手されるなら、それを止めるのがすべての影響を受ける要素の中でコーディネートを必要とすると指摘します。
Loop detection, as specified in this document, at any of the proxies in the scenarios described so far would have stopped the attack immediately. (If all the proxies involved implemented this loop
攻撃がすぐに遠くに止まったように説明されたシナリオのプロキシのいずれでも本書では指定されるとしての検出を輪にしてください。 (プロキシがかかわったすべてがこの輪を実装しました。
Sparks, et al. Standards Track [Page 5] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[5ページ]。
detection, the total number of stimulated messages in the first scenario described would be reduced to 14; in the variation involving one server, the number of stimulated messages would be reduced to 10.) However, there is a variant of the attack that uses multiple AORs where loop detection alone is insufficient protection. In this variation, each participating AOR forks to all the other participating AORs. For small numbers of participating AORs (10, for example), paths through the resulting tree will not loop until very large numbers of messages have been generated. Acquiring a sufficient number of AORs to launch such an attack on networks currently available is quite feasible.
検出、説明されたシナリオが14まで減少するだろうという1番目の刺激となっているメッセージの総数。 1つのサーバにかかわる変化では、刺激となっているメッセージの数は10まで減少するでしょう。) しかしながら、複数のAORsを使用する攻撃の異形が唯一の輪の検出が不十分な保護であるところにあります。 この変化では、それぞれ参加しているAORは他のすべての参加AORsに分岐します。 参加AORs(例えば、10)の少ない数のために、非常に多くのメッセージが生成されるまで、結果として起こる木を通した経路は輪にされないでしょう。 AORsのネットワークに対する現在利用可能なそのような攻撃に着手できるくらいの数を取得するのはかなり可能です。
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が参加AORsの数であり、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 AORsの1セットを全体のセットに分岐するように上がるようにすると仮定してください。 明快には、AOR1が攻撃が始まるところであると仮定してください。 どんなAORも繰り返さないで(N-1!)異なった経路を定義して、残っているN-1 AORsのあらゆる順列が展開するでしょう。 次に、それぞれのこれらの経路は最後の1回の間、N方法を分岐させるでしょう、そして、輪はそれぞれのこれらの支店に検出されるでしょう。 単独の合計N!が要求するこれらの最終的なブランチ(Nフォークがそれぞれの経路の端にある(N-1!)経路)。
___N____Requests_
| 1 | 1 |
| 2 | 4 |
| 3 | 15 |
| 4 | 64 |
| 5 | 325 |
| 6 | 1956 |
| 7 | 13699 |
| 8 | 109600 |
| 9 | 986409 |
| 10 | 9864100 |
___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
参加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.
すべてのプロキシが輪の検出を実行しているネットワークでは、急速に彼らが利用することができるAORsの数へのリターンを増強しながら、まだ攻撃者を都合しています。 本書では定義されたマックス-幅のメカニズムは、攻撃のこの変化の有効性を制限するように設計されています。
Sparks, et al. Standards Track [Page 6] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[6ページ]。
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意識している要素になりさえしないかもしれません)、攻撃に参加するAORsがあるのと潜在的に同じくらい多くのソースから犠牲者に向けられる大規模な量のトラフィックをもたらして。
4. Updates to RFC 3261
4. RFC3261へのアップデート
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.
SIPプロキシが特定の要求を複数の位置に分岐させると、それは、このプロキシを通して要求を輪にしているのを確実にしてはいけません。 プロキシが本書では定義された輪検出ステップを実行することによってこの必要条件を満たすのは、RECOMMENDEDです。
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.
このドキュメントのRFC3261からの検出アルゴリズムが設定される輪の気品を使用するという要件、-、強さ、プロキシがそれを決定できる将来のStandards-道のメカニズムを考慮するのは輪にされるべきではありません。 例えば、一口外国行きのメカニズム[OUTBOUND]を使用することで設置された目的地に分岐するプロキシは、それらのブランチが輪にしないのを知っているでしょう。
A SIP proxy forwarding a request to only one location MAY perform loop detection but is not required to. When forwarding to only one location, the amplification risk being exploited is not present, and the Max-Forwards mechanism will protect the network to the extent it was designed (always keep in mind the constant multiplier due to exhausting Max-Forwards while not forking). A proxy is not required to perform loop detection when forwarding a request to a single location even if it happened to have previously forked that request (and performed loop detection) in its progression through the network.
1つの位置だけに要求を転送するSIPプロキシは、輪の検出を実行するかもしれませんが、必要ではありません。 位置を1つだけに送るとき、利用される増幅危険は存在していません、そして、前方へマックスメカニズムはそれが設計されたという(分岐していない間、前方へマックスを疲れ果てさせるためいつも一定の乗数を覚えておきます)範囲にネットワークを保護するでしょう。 プロキシは、以前にネットワークを通して進行でその要求を分岐させたのが(そして、輪の検出を実行します)起こったとしても単一の位置に要求を転送するとき、輪の検出を実行するのに必要ではありません。
4.2. Correcting and Clarifying the RFC 3261 Loop-Detection Algorithm
4.2. RFC3261輪検出アルゴリズムを修正して、はっきりさせます。
4.2.1. Update to Section 16.6
4.2.1. セクション16.6へのアップデート
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).
このセクションはRFC3261のセクション16.6の項目8のすべてを取り替えます(項目8は、105ページで始まって、106RFCページで3261終わります)。
Sparks, et al. Standards Track [Page 7] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[7ページ]。
8. Add a Via Header Field Value
8. ヘッダーフィールド値でaを加えてください。
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ヘッダーフィールド値の前にViaヘッダーフィールド価値をコピーに挿入しなければなりません。 この価値の工事は.7にセクション8.1.1の同じガイドラインに従います。 これは、プロキシがそのブランチにグローバルにユニークになるそれ自身のブランチパラメタを計算して、必要な魔法のクッキーを含むのを含意します。 .7がプロキシを通してらせん状に動かされたか輪にされた要求の異なったインスタンスにおいて異なるようになるブランチパラメタをもたらして、セクション8.1.1におけるガイドラインだけに従うことに注意してください。
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.
RFC5393による輪の検出を実行しなければならなかったプロキシが彼らがViaヘッダーフィールドに置く値に追加規制を持っています。 そのようなプロキシSHOULDはどんな実装依存する方法でも2つの部品に分離できた状態でブランチ値を作成します。
The remainder of this section's description assumes the existence of these two parts. If a proxy chooses to employ some other mechanism, it is the implementer's responsibility to verify that the detection properties defined by the requirements placed on these two parts are achieved.
このセクションの記述の残りはこれらの2つの部品の存在を仮定します。 プロキシが、ある他のメカニズムを使うのを選ぶなら、これらの2つの部品に置かれた要件によって定義された検出特性が獲得されることを確かめるのは、implementerの責任です。
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.
ブランチ価値の最初の一部分が.7にセクション8.1.1の規制を満たさなければなりません。 第二部は、輪の検出を実行して、らせんと輪を区別するのに使用されます。
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.
この第二部は、どんな分野も位置のサービス論理によって決定に使用されている状態で「再-目標」に異ならなければならないか、またはこの要求を転送しなければなりません。 要求の処理に影響する値のいずれも変化していないなら、これが、認識するのに区別するのがプロキシを許容することによってらせんからの要求を輪にしたのが必要です。 したがって、第二部は少なくとも容認されたRequest-URIと受信された要求を処理するとき使用されるどんなRouteヘッダーフィールド値にも依存しなければなりません。 Implementersは、位置のサービス論理によってその特定の実装に使用されるすべての分野を含むように注意する必要があります。
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).
この第二部は要求メソッドで異なってはいけません。 キャンセルと非200ACK要求には、彼らが中止するか、または承諾する対応する要求と同じブランチパラメタ価値がなければなりません。 このブランチパラメタ価値はそれらを扱うサーバでそれらの要求を関連させる際に使用されます(セクション17.2 .3と9.2を見てください)。
4.2.2. Update to Section 16.3
4.2.2. セクション16.3へのアップデート
This section replaces all of item 4 in Section 16.3 of RFC 3261 (item 4 appears on page 95 of RFC 3261).
このセクションはRFC3261のセクション16.3の項目4のすべてを取り替えます(商品4は95RFCページに3261現れます)。
Sparks, et al. Standards Track [Page 8] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[8ページ]。
4. Loop-Detection Check
4. 輪検出チェック
Proxies required to perform loop detection by RFC 5393 MUST perform the following loop-detection test before forwarding a request. Each Via header field value in the request whose sent-by value matches a value placed into previous requests by this proxy MUST be inspected for the "second part" defined in Section 4.2.1 of RFC 5393. This second part will not be present if the message was not forked when that Via header field value was added. If the second field is present, the proxy MUST perform the second-part calculation described in Section 4.2.1 of RFC 5393 on this request and compare the result to the value from the Via header field. If these values are equal, the request has looped and the proxy MUST reject the request with a 482 (Loop Detected) response. If the values differ, the request is spiraling and processing continues to the next step.
要求を転送する前に、RFC5393による輪の検出を実行しなければならなかったプロキシは以下の輪検出テストを実行しなければなりません。 それぞれのViaヘッダーフィールドは要求で発信していた状態でだれのものを評価します。.1セクション4.2RFC5393で定義された「第二部」がないかどうか値がこのプロキシによる前の要求に置いた値のマッチを点検しなければなりません。 そのViaヘッダーフィールド価値が高められたとき、メッセージが分岐しなかったなら、この第二部は存在しないでしょう。 2番目の分野が存在しているなら、プロキシは、.1セクション4.2RFC5393で説明された第二部計算をこの要求に実行して、結果をViaヘッダーフィールドから値にたとえなければなりません。 これらの値が等しいなら、要求は輪にされました、そして、プロキシは482(輪のDetected)応答で要求を拒絶しなければなりません。 値が異なるなら、要求はらせん形になっています、そして、処理は次のステップに続きます。
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が経路の1つ以上の位置に要求を分岐させるプロキシの数であるオーダーm*nです。 実際には、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.
本書では言い表された輪検出アルゴリズムは、プロキシが受信された要求におけるそれぞれのVia要素を点検するのを必要とします。 輪がメッセージがNプロキシに交差しているところのそれのそれぞれを検出する最悪の場合では、プロキシkはk点検をします、そして、この要求を扱っているプロキシの向こう側に広げられた点検の総合的な数はk=1からN(N+1)/2であるk=Nまでのkの合計です。
4.2.4. Note to Implementers
4.2.4. Implementersへの注意
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,
要求を分岐させるときブランチパラメタ価値の第二部を作成する一般的な方法はRequest-URIの連結、要求を処理している間に使用されるどんなRouteヘッダーフィールド値、およびこの要求を処理している間に位置のサービス論理によって使用されるいかなる他の値に関してもハッシュを計算することです。 ハッシュは、これらのパラメタの異なった2セットが衝突するという低い確率があるように、選ばれるべきです。 比較される必要がある入力の最大数が70であるので、衝突の機会は比較的小さいハッシュ値があっても低いです、32ビットなどのように。 [RFC4960]の指定されるとしてのCRC-32cはMD5のように特定の許容できる機能[RFC1321]です。 MD5が純粋に非暗号の特性に選ばれていることに注意してください。 ハッシュ衝突を起こすために入力を制御できる攻撃者は他のさまざまな方法で接続を攻撃できます。 ハッシュを使用することで第二部を形成するとき
Sparks, et al. Standards Track [Page 9] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[9ページ]。
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.
実装SHOULDはハッシュが衝突するなら繰り返された失敗を避けるために同じ目的地に達するのを試みながら異なったトランザクションの間で異なるハッシュに入力における少なくとも1つの分野を含めます。 Call-IDとCSeq分野はこのために良い入力でしょう。
A common point of failure to interoperate at SIPit events has been due to parsers objecting to the contents of another element's Via header field values when inspecting the Via stack for loops. Implementers need to take care to avoid making assumptions about the format of another element's Via header field value beyond the basic constraints placed on that format by RFC 3261. In particular, parsing a header field value with unknown parameter names, parameters with no values, or parameter values with or without quoted strings must not cause an implementation to fail.
SIPitイベントで共同利用しないことの一般的なポイントは点検するとき、別の要素のViaヘッダーフィールド値のコンテンツに反対して、パーサのため、Viaが輪のために積み重ねるということです。 Implementersは、RFC3261に基本的な規制を超えた別の要素の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つの要素がこのようにブランチパラメタを変更するなら、輪を決して検出できません。
5. Max-Breadth
5. マックス-幅
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.
マックス-幅のメカニズムはここで同時発生のブランチの総数が股状のSIP要求で引き起こした限界を定義しました。 このメカニズムで、上向きの不可欠のマックス-幅の値はすべての「プロキシ-可能」要求に割り当てられます。(現在のポイントからそれを進めるとき、それは、この要求が平行な分岐で量産するかもしれない同時発生のブランチの最大数を指示します)。 プロキシが要求を転送するとき、マックス-幅の値は送信する要求の中で分割されます。 順番に、それぞれの転送された要求には、それがいくつの同時発生のブランチを量産するかもしれないかに関して限界があります。 ブランチとして、完全であることで、必要であるなら、それらのマックス-幅の価値の部分はその後のブランチに利用可能になります。 必要な平行なフォークを行うために不十分なマックス-幅があれば、プロキシは本書では定義された440(マックス-幅のExceeded)応答を返すことができます。
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
このメカニズムは独自に前方へマックスを中心に活動します。 マックスそれは要求が横断するかもしれない木の深さですが、創作ポイントからそれが分岐する各目的地まで進めて、限界を進めます。 セクション3が示すように、分岐に投機することによって、限られた深ささえの木のブランチの数を大きく(深さによる指数の)することができます。 そのような各ブランチには、1組のSIP取引があります。
Sparks, et al. Standards Track [Page 10] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[10ページ]。
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.
440(マックス-幅のExceeded)応答を受けるクライアントは、要求がすべての可能な目的地に達したというわけではないと推論できます。 また、483を受け取るとき、回復オプションがそれらと同様である、(Manyホップス) 応答、およびそれほど広くない検索をもたらすのが適切であるいかなるメカニズムを通してもルーティング決定に影響するか、または服従の前に検索スペースをより小さくするように要求自体を洗練するインクルード。
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 | |
| |--------------------------------------->|
| | | |
UACプロキシはプロキシBプロキシCです。| 招待| | | | マックス-幅: 60 | 招待| | | マックス-フォワード: 70 | マックス-幅: 30 | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| マックス-フォワード: 69 | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 招待| | | | マックス-幅: 30 | | | | マックス-フォワード: 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 | |
| |--------------------------------------->|
| | | |
UACプロキシはプロキシBプロキシCです。| 招待| | | | マックス-幅: 60 | 招待| | | マックス-フォワード: 70 | マックス-幅: 60 | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| マックス-フォワード: 69 | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 何らかの誤り応答| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 招待| | | | マックス-幅: 60 | | | | マックス-フォワード: 69 | | | |--------------------------------------->| | | | |
Sequential Forking
連続した分岐
Sparks, et al. Standards Track [Page 11] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[11ページ]。
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 |
| | |------------------>|
| | | |
| | | |
| | | |
UACプロキシはプロキシBプロキシCです。| 招待| | | | マックス-幅: 60 | 招待| | | マックス-フォワード: 70 | マックス-幅: 60 | 招待| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| マックス-フォワード: 69 | マックス-幅: 60 | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| マックス-フォワード: 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
.
.
.
| MB: 4 | mf: 5MB: 2P MB: 2mf: 4/\mf: 4 +---------------+ +------------------+ MB: 1P MB: 1MB: 1P MB: 1回のmf: 3/\mf: 3mf: 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.
マックス-幅のヘッダーフィールドは値としてただ一つの正の整数をみなします。 マックス-幅のヘッダーフィールド価値はパラメタを全く取りません。
Sparks, et al. Standards Track [Page 12] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[12ページ]。
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.
プロキシの各「応答文脈」([RFC3261]のセクション16を見る)に関しては、このメカニズムは2つの上向きの整数値を定義します: 入って来るマックスBreadthと外向的なマックス-幅。 入って来るマックス-幅は応答文脈を形成した要求におけるマックス-幅のヘッダーフィールドにおいて値です。 外向的なマックス-幅は応答文脈における最終的な応答を受けていないすべての転送された要求で、マックス-幅のヘッダーフィールド値の合計です。
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.
SIPプロキシがマックス-幅のヘッダーフィールド価値なしで要求を受け取るなら、それは、60になるようにRECOMMENDEDである値がある1つを加えなければなりません。 プロキシには、最大の許容できるIncomingマックス-幅の価値がなければなりません。(それは、60であるRECOMMENDEDです)。 受信された要求で超えられていて、プロキシはこの最大がそうならSHOULDがある値でそれを上書きしなければなりません。許容できるより最大。
All proxied requests MUST contain a single Max-Breadth header field value.
すべてのproxied要求がただ一つのマックス-幅のヘッダーフィールド価値を含まなければなりません。
SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the Incoming Max-Breadth in a given response context.
SIPプロキシはOutgoingマックス-幅に与えられた応答文脈のIncomingマックス-幅を超えさせてはいけません。
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プロキシが、必要な平行なフォーク、およびプロキシが不本意であるか、または順次、分岐するか、または再直接でaを送ることによって代償できないアウトを運ぶために応答文脈には不十分なIncomingマックス-幅があると決心しているなら、そのプロキシは440(マックス-幅のExceeded)応答を返さなければなりません。
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プロキシは活動的な支店の間の任意のファッションでマックス-幅を分配するかもしれません。 SHOULD NOTがIncomingマックス-幅がプロキシの最大の許容値を超えていなかったならオリジナルの要求に存在していたよりわずかな量のマックス-幅に使用するプロキシ。 プロキシは、各ホップのためにマックス-幅を減少させてはいけませんし、またそうでなければ、要求の伝播の「深さ」を制限するのにそれを使用してはいけません。
Sparks, et al. Standards Track [Page 13] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[13ページ]。
5.3.3.1. Reusing Max-Breadth
5.3.3.1. マックス-幅を再利用します。
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.
最終的な応答が到着するときはいつも、最終的な応答を受けた転送された要求がOutgoingマックス-幅に向かって重要でないので、その支店で使用されたマックス-幅は再利用に利用可能になります。 プロキシSHOULD、要素が目標セットに残るかもしれない場合におけるこのマックスBreadthを再利用するように用意してください。
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.
UserエージェントClient(UAC)はマックス-幅のヘッダーフィールド価値を送信する要求に置くかもしれません。 そうだとすれば、この値は60であるRECOMMENDEDです。
5.3.5. UAS Behavior
5.3.5. UASの振舞い
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.
このメカニズムはUserエージェントServer(UAS)の振舞いに影響しません。 マックス-幅のヘッダーフィールドで要求を受け取るUASは要求を処理している間、その分野を無視するでしょう。
5.4. Implementer Notes
5.4. Implementer注意
5.4.1. Treatment of CANCEL
5.4.1. キャンセルの処理
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.
キャンセル要求が決してproxiedされないので、マックス-幅のヘッダーフィールド価値はキャンセル要求で無意味です。 キャンセルを送るのは関連INVITE応答文脈のOutgoingマックス-幅に決して影響しません。 キャンセル決して感情Incomingマックスのa関連INVITE応答文脈の幅を受けます。
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.
プロキシがこの場合新しいブランチを始めるのが禁じられるので、2xx応答がマックス-幅を開けるかどうかが、ほとんど議論の余地のある問題です。 しかし、1つの警告があります。 プロキシは独身の進められたINVITEのための応答が要求する複数の2xxを受け取るかもしれません。 また、[RFC2543]実現は同じブランチで2xxによって続かれた6xxを返送するかもしれません。 INVITE要求への2xx応答を受けるときOutgoingマックス-幅から引かれる実現は単一のブランチのために複数の回を引き算することによって引き起こされたバグを避けるのに慎重であるに違いありません。
5.4.3. Max-Breadth and Automaton UAs
5.4.3. マックス-幅とオートマトンUAs
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.
オートマトンユーザエージェント(UAs)(B2BUAs、ゲートウェイ、発破器、および入って来るSIP交通の結果、プログラムに基づいて要求を送るいかなる他の要素も含んでいる)のデザイナーは、マックスの幅の制限が送信する要求に置かれるべきであるかどうか考えるべきです。 例えば、入って来る要求からその結果送られる要求までマックス-幅の値を運ぶようにB2BUAsを設計するのは妥当です。
Sparks, et al. Standards Track [Page 14] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[14ページ]。
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のOutgoingマックス-幅を合計する)、これらの4個の目標にフォークに沿うかもしれません。 プロキシが4つのものの1つに残っている目標を送るのを許容して、これらの取引の1つが失敗応答、3への出発しているマックス-幅の低下で完成する、(再び、1の)マックス-幅で。
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.
これは時間内に任意な与えられた点で交通を処理するのに必要である状態/帯域幅の量がふたをされるので分岐しながら力を入れるどんな増幅攻撃の有効性も制限します。
Sparks, et al. Standards Track [Page 15] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[15ページ]。
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.
この仕様は、Session Initiationプロトコルのために拡張ヘッダーを加えることによって、文法を広げています。 ABNF[RFC5234]定義は以下の通りです。
Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT
「マックス-幅」HCOLON1*マックス-幅=ケタ
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].
[RFC3261]で定義された過程に従って、この仕様は新しいSIPヘッダーフィールドと新しいSIP応答を示します。
6.1. Max-Breadth Header Field
6.1. マックス-幅のヘッダーフィールド
This information appears in the Header Fields sub-registry of the SIP Parameters registry.
この情報はSIP Parameters登録のHeaderフィールズサブ登録に現れます。
RFC 5393 (this specification)
RFC5393(この仕様)
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.
この情報はSIP Parameters登録のResponse Codesサブ登録に現れます。
Response code: 440
応答コード: 440
Default Reason Phrase: Max-Breadth Exceeded
デフォルト理由句: 超えられていたマックス-幅
7. Security Considerations
7. セキュリティ問題
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.
このドキュメントは指数関数的に増加している交換処理攻撃に通じることができるRFC3261によって定義されるように、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
ここで定義されたマックス-幅のメカニズムは分岐輪の攻撃で引き起こされた集合交通を静まらせません。 それは、より長い期間にわたって同時に処理される予定である同時発生のブランチの数を制限することによって攻撃で引き起こされた交通を広げるのに役立つだけです。 攻撃者は、マックス-幅のメカニズムを使用するネットワークに複数の要求をポンプで送って、徐々に交通を無理なレベルに組み込むことができました。 展開は、保護するために与えられたリソースに関連する同時発生の傑出している取引の数における漸増に慎重にモニターして、反応するべきです。
Sparks, et al. Standards Track [Page 16] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[16ページ]。
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]).
Implementersとオペレータが取り扱い過負荷条件のために開発される推薦に続くよう奨励されます([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ネットワークからPublic Switched Telephone Network(PSTN)の中と、そして、次にSIPネットワークの中に通過して戻って、プロトコル変換のどちらかの側の要求の歴史の情報が無くなるなら、マックスフォワードも輪の検出も守ることができない輪を構成するのは可能になります。 輪のSIP側面で増幅を分岐させると結合したこれは攻撃における、同時発生のメッセージの数を制限さえするのではなく、ここのメカニズムが減少させない本書では説明される攻撃に結果として生じるでしょう。 SIPからSIPへのゲートウェイのデザイナーには、これらの問題は特に重要です(例えば、B2BUAsで見つけられるように)。 多くの既存のB2BUA実現が彼らとコミュニケートする2つの側のできるだけ多くの情報を隠すようにいくつか圧力をかけられています。 そのような実現のImplementersが他のポイントで輪検出、前方へマックス、またはマックス-幅のメカニズムによってネットワークに使用されるかもしれないデータを取り除くように誘惑されるかもしれません、輪(または、この攻撃のフォーム)を検出するために責任を負って。 しかしながら、そのような2つの実現が攻撃にかかわると、どちらもそれを検出できないでしょう。
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
何もしません--犯罪者を訴えるのを当てにしてください: アカウントを持っているシステムが虐待者の居場所を見つけるように採掘できるログを持っていますが、これが本書では説明された攻撃に対して確かな抑止力かディフェンスを提供するのは、明確ではありません。 状況を認識して、調整策/予防処置を取らないシステムは攻撃のセットアップを記録する記録の検索を排除する大きさの失敗を経験しそうです。 (1つのシナリオでは、登録証明書は根本的に. INVITEが要求するINVITE取引と異なった期間に起こることができます。
Sparks, et al. Standards Track [Page 17] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[17ページ]。
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.
それ自体、純潔な人から来たかもしれない、) シナリオが何気なくセットアップされるのは、可能でさえあります。 その上、いくつかの既存の展開のために、アカウントの費用と監査能力は単にEメールアドレスです。 罰するだれかを見つけるのは不可能であるかもしれません。 最終的に、訴訟のどんな脅威にも応じない個人がいます、そして、この種類の攻撃のただ一つのうまくいっている例さえの効果はサービスプロバイダーに破壊的でしょう。
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.
登録結合を任意に禁じると、以下は連絡されます。 登録結合が現在定義される方法はここに記録された攻撃の種類の成功の主要な部分です。 登録要求で観測された輸送人工物を支持して付くだけであるのを登録を実行するネットワーク要素と、そして、恐らくContactに提供されたビットを無視する極端に許容するために登録結合を制限する代替手段について議論しました(特に[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)。 この代替手段の下では、導入された要求で、大部分でネットワークでマックス-幅の取引の初期の値を発生させるでしょう。 そのアプローチがここで一定の乗数まで説明された増幅脆弱性のどんな異形も制限している間、要求の潜在的範囲を劇的に変えるでしょう、そして、既存の展開を壊すだろうという信念があります。
Sparks, et al. Standards Track [Page 18] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[18ページ]。
8. Acknowledgments
8. 承認
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.
感謝では、それがかけたimplementersに、このシナリオであって助けられることへのそれらのコードがSIPit17で結果を分析すると言われています。 エリック・レスコラは細切れ肉料理推薦注意に指導とテキストを提供しました。
9. References
9. 参照
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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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"、STD68、RFC5234、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.
[デザイン] つかを付けてください、そして、V.、「セッション開始プロトコル(一口)のためのデザイン問題はコントロールを積みすぎること」が進歩、2008年7月に働いています。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
Work in Progress, October 2008.
[外国行き]のジョニングス、C.、およびR.マーイ、「クライアントを管理すると、セッション開始プロトコル(一口)のコネクションズは開始しました」、処理中の作業、2008年10月。
[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メッセージダイジェストアルゴリズム」、RFC1321、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.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4960] スチュワート、R.、「流れの制御伝動プロトコル」、RFC4960、2007年9月。
Sparks, et al. Standards Track [Page 19] RFC 5393 Amplification Vulnerability in SIP December 2008
スパーク、他 規格は2008年12月に一口におけるRFC5393増幅脆弱性を追跡します[19ページ]。
Authors' Addresses
作者のアドレス
Robert Sparks (editor) Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
ロバートは(エディタ)Tekelec17210キャンベル道路スイート250ダラス、テキサス75254-4203米国をかきたてます。
EMail: RjS@nostrum.com
メール: RjS@nostrum.com
Scott Lawrence Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA
スコットローレンスノーテルはInc.600技術Park MA01821ビルリカ(米国)をネットワークでつなぎます。
Phone: +1 978 288 5508 EMail: scott.lawrence@nortel.com
以下に電話をしてください。 +1 5508年の978 288メール: scott.lawrence@nortel.com
Alan Hawrylyshen Ditech Networks Inc. 823 E. Middlefield Rd Mountain View, CA 94043 USA
アランHawrylyshen Ditechは株式会社823E.Middlefieldカリフォルニア94043第マウンテンビュー(米国)をネットワークでつなぎます。
Phone: +1 650 623 1300 EMail: alan.ietf@polyphase.ca
以下に電話をしてください。 +1 1300年の650 623メール: alan.ietf@polyphase.ca
Byron Campen Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
バイロンCampen Tekelec17210キャンベル・道路Suite250テキサス75254-4203ダラス(米国)
EMail: bcampen@estacado.net
メール: bcampen@estacado.net
Sparks, et al. Standards Track [Page 20]
スパーク、他 標準化過程[20ページ]
一覧
スポンサーリンク
