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
Network Working Group R. Sparks, Ed.
Request for Comments: 5393 Tekelec
Updates: 3261 S. Lawrence
Category: Standards Track Nortel Networks, Inc.
A. Hawrylyshen
Ditech Networks Inc.
B. Campen
Tekelec
December 2008
Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
解决会话启动协议（SIP）分叉代理中的放大漏洞
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.
本文档规范性地更新了会话启动协议（SIP）RFC 3261，以解决SIP代理行为中识别的安全漏洞。此漏洞可对SIP网络发起攻击，其中少量合法、甚至授权的SIP请求可刺激大量的代理到代理流量。
This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request.
本文档增强了SIP代理在分叉请求（即，将请求转发到多个目的地）时对循环检测的要求。它还修正和澄清了循环检测算法的描述，这些代理需要实现。此外，本文档定义了一个最大宽度机制，用于限制任何给定请求的并发分支数。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Definitions .....................................3
3. Vulnerability: Leveraging Forking to Flood a Network ............3
4. Updates to RFC 3261 .............................................7
4.1. Strengthening the Requirement to Perform Loop Detection ....7
4.2. Correcting and Clarifying the RFC 3261
Loop-Detection Algorithm ...................................7
4.2.1. Update to Section 16.6 ..............................7
4.2.2. Update to Section 16.3 ..............................8
4.2.3. Impact of Loop Detection on Overall Network
Performance .........................................9
4.2.4. Note to Implementers ................................9
5. Max-Breadth ....................................................10
5.1. Overview ..................................................10
5.2. Examples ..................................................11
5.3. Formal Mechanism ..........................................12
5.3.1. Max-Breadth Header Field ...........................12
5.3.2. Terminology ........................................13
5.3.3. Proxy Behavior .....................................13
5.3.3.1. Reusing Max-Breadth .......................14
5.3.4. UAC Behavior .......................................14
5.3.5. UAS Behavior .......................................14
5.4. Implementer Notes .........................................14
5.4.1. Treatment of CANCEL ................................14
5.4.2. Reclamation of Max-Breadth on 2xx Responses ........14
5.4.3. Max-Breadth and Automaton UAs ......................14
5.5. Parallel and Sequential Forking ...........................15
5.6. Max-Breadth Split Weight Selection ........................15
5.7. Max-Breadth's Effect on Forking-Based
Amplification Attacks .....................................15
5.8. Max-Breadth Header Field ABNF Definition ..................16
6. IANA Considerations ............................................16
6.1. Max-Breadth Header Field ..................................16
6.2. 440 Max-Breadth Exceeded Response .........................16
7. Security Considerations ........................................16
7.1. Alternate Solutions That Were Considered and Rejected .....17
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................19
1. Introduction ....................................................3
2. Conventions and Definitions .....................................3
3. Vulnerability: Leveraging Forking to Flood a Network ............3
4. Updates to RFC 3261 .............................................7
4.1. Strengthening the Requirement to Perform Loop Detection ....7
4.2. Correcting and Clarifying the RFC 3261
Loop-Detection Algorithm ...................................7
4.2.1. Update to Section 16.6 ..............................7
4.2.2. Update to Section 16.3 ..............................8
4.2.3. Impact of Loop Detection on Overall Network
Performance .........................................9
4.2.4. Note to Implementers ................................9
5. Max-Breadth ....................................................10
5.1. Overview ..................................................10
5.2. Examples ..................................................11
5.3. Formal Mechanism ..........................................12
5.3.1. Max-Breadth Header Field ...........................12
5.3.2. Terminology ........................................13
5.3.3. Proxy Behavior .....................................13
5.3.3.1. Reusing Max-Breadth .......................14
5.3.4. UAC Behavior .......................................14
5.3.5. UAS Behavior .......................................14
5.4. Implementer Notes .........................................14
5.4.1. Treatment of CANCEL ................................14
5.4.2. Reclamation of Max-Breadth on 2xx Responses ........14
5.4.3. Max-Breadth and Automaton UAs ......................14
5.5. Parallel and Sequential Forking ...........................15
5.6. Max-Breadth Split Weight Selection ........................15
5.7. Max-Breadth's Effect on Forking-Based
Amplification Attacks .....................................15
5.8. Max-Breadth Header Field ABNF Definition ..................16
6. IANA Considerations ............................................16
6.1. Max-Breadth Header Field ..................................16
6.2. 440 Max-Breadth Exceeded Response .........................16
7. Security Considerations ........................................16
7.1. Alternate Solutions That Were Considered and Rejected .....17
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................19
Interoperability testing uncovered a vulnerability in the behavior of forking SIP proxies as defined in [RFC3261]. This vulnerability can be leveraged to cause a small number of valid SIP requests to generate an extremely large number of proxy-to-proxy messages. A version of this attack demonstrates fewer than ten messages stimulating potentially 2^71 messages.
互操作性测试发现[RFC3261]中定义的分叉SIP代理行为中存在漏洞。此漏洞可导致少量有效SIP请求生成大量代理到代理消息。此攻击的一个版本显示少于10条消息，可能会激发2^71条消息。
This document specifies normative changes to the SIP protocol to address this vulnerability. According to this update, when a SIP proxy forks a request to more than one destination, it is required to ensure it is not participating in a request loop.
本文档规定了SIP协议的规范性更改，以解决此漏洞。根据此更新，当SIP代理将请求分叉到多个目的地时，需要确保它没有参与请求循环。
This normative update alone is insufficient to protect against crafted variations of the attack described here involving multiple Addresses of Record (AORs). To further address the vulnerability, this document defines the Max-Breadth mechanism to limit the total number of concurrent branches caused by a forked SIP request. The mechanism only limits concurrency. It does not limit the total number of branches a request can traverse over its lifetime.
仅此规范性更新不足以防止此处描述的涉及多个记录地址（AOR）的精心设计的攻击变体。为了进一步解决该漏洞，本文定义了最大宽度机制，以限制分叉SIP请求导致的并发分支总数。该机制仅限制并发性。它不限制请求在其生存期内可以遍历的分支总数。
The mechanisms in this update will protect against variations of the attack described here that use a small number of resources, including most unintentional self-inflicted variations that occur through accidental misconfiguration. However, an attacker with access to a sufficient number of distinct resources will still be able to stimulate a very large number of messages. The number of concurrent messages will be limited by the Max-Breadth mechanism, so the entire set will be spread out over a long period of time, giving operators better opportunity to detect the attack and take corrective measures outside the protocol. Future protocol work is needed to prevent this form of the attack.
此更新中的机制将防止此处描述的攻击变体使用少量资源，包括大多数由于意外错误配置而发生的非故意自我造成的变体。但是，能够访问足够数量的不同资源的攻击者仍然能够激发大量消息。并发消息的数量将受到最大宽度机制的限制，因此整个消息集将在很长一段时间内分散，从而使操作员有更好的机会检测攻击并在协议之外采取纠正措施。未来的协议工作需要防止这种形式的攻击。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section describes setting up an attack with a simplifying assumption: that two accounts on each of two different RFC 3261 compliant proxy/registrar servers that do not perform loop detection are available to an attacker. This assumption is not necessary for the attack but makes representing the scenario simpler. The same attack can be realized with a single account on a single server.
本节描述了通过一个简化的假设设置攻击：攻击者可以使用两个不同的RFC 3261兼容代理/注册服务器上的两个帐户（不执行循环检测）。这种假设对于攻击来说是不必要的，但可以简化场景的表示。相同的攻击可以通过单个服务器上的单个帐户实现。
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):
考虑两个代理/注册服务，P1和P2，以及记录的四个地址，a@P1, b@P1, a@P2和b@P2. 使用普通的寄存器请求，按如下方式建立到这些AOR的绑定（省略非必要的详细信息）：
REGISTER sip:P1 SIP/2.0
To: <sip:a@P1>
Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P1 SIP/2.0
To: <sip:a@P1>
Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P1 SIP/2.0
To: <sip:b@P1>
Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P1 SIP/2.0
To: <sip:b@P1>
Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P2 SIP/2.0
To: <sip:a@P2>
Contact: <sip:a@P1>, <sip:b@P1>
REGISTER sip:P2 SIP/2.0
To: <sip:a@P2>
Contact: <sip:a@P1>, <sip:b@P1>
REGISTER sip:P2 SIP/2.0
To: <sip:b@P2>
Contact: <sip:a@P1>, <sip:b@P1>
REGISTER sip:P2 SIP/2.0
To: <sip:b@P2>
Contact: <sip:a@P1>, <sip:b@P1>
With these bindings in place, introduce an INVITE request to any of the four AORs, say a@P1. This request will fork to two requests handled by P2, which will fork to four requests handled by P1, which will fork to eight messages handled by P2, and so on. This message flow is represented in Figure 1.
有了这些绑定，就可以向四个AOR中的任何一个引入INVITE请求，比如a@P1. 这个请求将分叉到由P2处理的两个请求，这将分叉到由P1处理的四个请求，这将分叉到由P2处理的八条消息，依此类推。此消息流如图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：攻击请求传播
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).
请求将继续沿此树向下传播，直到最大转发数达到零。如果所涉及的端点和两个代理遵循RFC3261建议，则树将有70行深，表示2^71-1个请求。如果处理整个树的请求的时间比任一代理上的计时器C都长，则消息的实际数量可能会大得多。在这种情况下，408个响应的风暴和/或取消请求的风暴也将与INVITE请求一起在树中传播。请记住，此场景中只涉及两个代理—每个代理都必须保留其看到的所有事务的状态（在场景结束时至少有2^70个同时处于活动状态的事务）。
The attack can be simplified to one account at one server if the service can be convinced that contacts with varying attributes (parameters, schemes, embedded headers) are sufficiently distinct, and these parameters are not used as part of AOR comparisons when forwarding a new request. Since RFC 3261 mandates that all URI parameters must be removed from a URI before looking it up in a location service and that the URIs from the Contact header field are compared using URI equality, the following registration should be sufficient to set up this attack using a single REGISTER request to a single account:
如果服务能够确信具有不同属性（参数、方案、嵌入头）的联系人足够清晰，并且在转发新请求时这些参数不作为AOR比较的一部分，则攻击可以简化为一台服务器上的一个帐户。由于RFC 3261要求在位置服务中查找URI之前必须删除URI中的所有URI参数，并且使用URI相等性比较联系人标头字段中的URI，因此以下注册应足以使用对单个帐户的单个注册请求设置此攻击：
REGISTER sip:P1 SIP/2.0
To: <sip:a@P1>
Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud>
REGISTER sip:P1 SIP/2.0
To: <sip:a@P1>
Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud>
This attack was realized in practice during one of the SIP Interoperability Test (SIPit) sessions. The scenario was extended to include more than two proxies, and the participating proxies all limited Max-Forwards to be no larger than 20. After a handful of messages to construct the attack, the participating proxies began bombarding each other. Extrapolating from the several hours the experiment was allowed to run, the scenario would have completed in just under 10 days. Had the proxies used the RFC 3261 recommended Max-Forwards value of 70, and assuming they performed linearly as the state they held increased, it would have taken 3 trillion years to complete the processing of the single INVITE request that initiated the attack. It is interesting to note that a few proxies rebooted during the scenario and rejoined in the attack when they restarted (as long as they maintained registration state across reboots). This points out that if this attack were launched on the Internet at large, it might require coordination among all the affected elements to stop it.
这种攻击实际上是在一次SIP互操作性测试（SIPit）会话期间实现的。该场景被扩展为包括两个以上的代理，并且参与代理的最大转发数都限制为不大于20。在发送了几条消息构建攻击后，参与攻击的代理开始相互轰炸。从实验允许运行的几个小时推断，该场景将在不到10天的时间内完成。如果代理使用RFC 3261建议的最大转发值70，并假设它们的性能随着所持有状态的增加而线性增加，则需要3万亿年才能完成发起攻击的单个INVITE请求的处理。值得注意的是，一些代理在场景中重新启动，并在重新启动时重新加入攻击（只要它们在重新启动过程中保持注册状态）。这就指出，如果这起攻击是在互联网上发起的，那么可能需要所有受影响因素之间的协调来阻止它。
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。对于少量参与的AOR（例如10个），在生成大量消息之前，通过结果树的路径不会循环。获取足够数量的AOR以在当前可用的网络上发起此类攻击是非常可行的。
In this scenario, requests will often take many hops to complete a loop, and there are a very large number of different loops that will occur during the attack. In fact, if N is the number of participating AORs, and provided N is less than or equal to Max-Forwards, the amount of traffic generated by the attack is greater than N!, even if all proxies involved are performing loop detection.
在这种情况下，请求通常需要许多跳才能完成一个循环，并且在攻击过程中会出现大量不同的循环。事实上，如果N是参与AOR的数量，并且假设N小于或等于Max Forwards，则攻击生成的通信量大于N！，即使所有涉及的代理都在执行循环检测。
Suppose we have a set of N AORs, all of which are set up to fork to the entire set. For clarity, assume AOR 1 is where the attack begins. Every permutation of the remaining N-1 AORs will play out, defining (N-1)! distinct paths, without repeating any AOR. Then, each of these paths will fork N ways one last time, and a loop will be detected on each of these branches. These final branches alone total N! requests ((N-1)! paths, with N forks at the end of each path).
假设我们有一组N个AOR，所有这些AOR都被设置为分叉到整个集合。为清楚起见，假设AOR 1是攻击开始的位置。剩余N-1个AOR的每一个排列都将播放，定义（N-1）！不同的路径，不重复任何AOR。然后，这些路径中的每一条都将最后一次分叉N个路径，并且在每个分支上都将检测到一个循环。光是这些最后的分支就有N个！请求（（N-1）！路径，每个路径末尾有N个分叉）。
___N____Requests_
| 1 | 1 |
| 2 | 4 |
| 3 | 15 |
| 4 | 64 |
| 5 | 325 |
| 6 | 1956 |
| 7 | 13699 |
| 8 | 109600 |
| 9 | 986409 |
| 10 | 9864100 |
___N____Requests_
| 1 | 1 |
| 2 | 4 |
| 3 | 15 |
| 4 | 64 |
| 5 | 325 |
| 6 | 1956 |
| 7 | 13699 |
| 8 | 109600 |
| 9 | 986409 |
| 10 | 9864100 |
Forwarded Requests vs. Number of Participating AORs
转发请求与参与AOR的数量
In a network where all proxies are performing loop detection, an attacker is still afforded rapidly increasing returns on the number of AORs they are able to leverage. The Max-Breadth mechanism defined in this document is designed to limit the effectiveness of this variation of the attack.
在一个所有代理都在执行循环检测的网络中，攻击者仍然可以利用的AOR数量快速增加。本文档中定义的最大宽度机制旨在限制这种攻击变化的有效性。
In all of the scenarios, it is important to notice that at each forking proxy, an additional branch could be added pointing to a single victim (that might not even be a SIP-aware element), resulting in a massive amount of traffic being directed towards the victim from potentially as many sources as there are AORs participating in the attack.
在所有场景中，需要注意的是，在每个分叉代理上，可能会添加一个指向单个受害者（甚至可能不是SIP感知元素）的额外分支，从而导致大量流量从可能与参与攻击的AOR数量相同的来源定向到受害者。
The following requirements mitigate the risk of a proxy falling victim to the attack described in this document.
以下要求可降低代理成为本文档所述攻击的受害者的风险。
When a SIP proxy forks a particular request to more than one location, it MUST ensure that request is not looping through this proxy. It is RECOMMENDED that proxies meet this requirement by performing the loop-detection steps defined in this document.
当SIP代理将特定请求分叉到多个位置时，它必须确保请求没有通过该代理循环。建议代理通过执行本文档中定义的循环检测步骤来满足此要求。
The requirement to use this document's refinement of the loop-detection algorithm from RFC 3261 is set at should-strength to allow for future Standards-Track mechanisms that will allow a proxy to determine it is not looping. For example, a proxy forking to destinations established using the sip-outbound mechanism [OUTBOUND] would know those branches will not loop.
使用本文档对RFC 3261中循环检测算法的改进的要求设置为应强度，以允许未来的标准跟踪机制，该机制将允许代理确定其是否为循环。例如，使用sip出站机制[outbound]建立的目的地的代理分叉会知道这些分支不会循环。
A SIP proxy forwarding a request to only one location MAY perform loop detection but is not required to. When forwarding to only one location, the amplification risk being exploited is not present, and the Max-Forwards mechanism will protect the network to the extent it was designed (always keep in mind the constant multiplier due to exhausting Max-Forwards while not forking). A proxy is not required to perform loop detection when forwarding a request to a single location even if it happened to have previously forked that request (and performed loop detection) in its progression through the network.
仅将请求转发到一个位置的SIP代理可以执行循环检测，但不需要执行循环检测。当仅转发到一个位置时，不存在被利用的放大风险，并且最大转发机制将在其设计的范围内保护网络（始终记住由于在不分叉时耗尽最大转发而导致的恒定乘数）。代理在将请求转发到单个位置时不需要执行循环检测，即使它之前在网络中的进程中碰巧分叉了该请求（并执行了循环检测）。
This section replaces all of item 8 in Section 16.6 of RFC 3261 (item 8 begins on page 105 and ends on page 106 of RFC 3261).
本节取代RFC 3261第16.6节中的所有第8项（第8项开始于RFC 3261第105页，结束于RFC 3261第106页）。
8. Add a Via Header Field Value
8. 添加一个Via头字段值
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标头字段值插入副本中。该值的构造遵循第8.1.1.7节的相同指南。这意味着代理将计算其自身的分支参数，该参数对于该分支是全局唯一的，并且将包含必需的魔法cookie。请注意，仅遵循第8.1.1.7节中的指导原则将导致分支参数，对于通过代理的螺旋式或循环式请求的不同实例，分支参数将有所不同。
Proxies required to perform loop detection by RFC 5393 have an additional constraint on the value they place in the Via header field. Such proxies SHOULD create a branch value separable into two parts in any implementation-dependent way.
RFC 5393执行循环检测所需的代理对其在Via标头字段中的值具有附加约束。这样的代理应该创建一个分支值，该值可以以任何依赖于实现的方式分为两部分。
The remainder of this section's description assumes the existence of these two parts. If a proxy chooses to employ some other mechanism, it is the implementer's responsibility to verify that the detection properties defined by the requirements placed on these two parts are achieved.
本节描述的其余部分假设存在这两个部分。如果代理选择采用其他机制，则实现者有责任验证是否实现了由这两个部分上的需求定义的检测属性。
The first part of the branch value MUST satisfy the constraints of Section 8.1.1.7. The second part is used to perform loop detection and distinguish loops from spirals.
分支值的第一部分必须满足第8.1.1.7节的约束条件。第二部分用于执行回路检测并区分回路和螺旋。
This second part MUST vary with any field used by the location service logic in determining where to retarget or forward this request. This is necessary to distinguish looped requests from spirals by allowing the proxy to recognize if none of the values affecting the processing of the request have changed. Hence, the second part MUST depend at least on the received Request-URI and any Route header field values used when processing the received request. Implementers need to take care to include all fields used by the location service logic in that particular implementation.
第二部分必须随位置服务逻辑在确定重定目标或转发此请求的位置时使用的任何字段而变化。这对于区分循环请求和螺旋请求是必要的，因为它允许代理识别是否影响请求处理的任何值都没有更改。因此，第二部分必须至少依赖于接收到的请求URI和处理接收到的请求时使用的任何路由头字段值。实现者需要注意在该特定实现中包含位置服务逻辑使用的所有字段。
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).
第二部分不得随请求方法而变化。取消和非200 ACK请求必须具有与其取消或确认的相应请求相同的分支参数值。此分支参数值用于在处理这些请求的服务器上关联这些请求（请参见第17.2.3和9.2节）。
This section replaces all of item 4 in Section 16.3 of RFC 3261 (item 4 appears on page 95 of RFC 3261).
本节取代RFC 3261第16.3节中的所有第4项（第4项出现在RFC 3261第95页）。
4. Loop-Detection Check
4. 环路检测检查
Proxies required to perform loop detection by RFC 5393 MUST perform the following loop-detection test before forwarding a request. Each Via header field value in the request whose sent-by value matches a value placed into previous requests by this proxy MUST be inspected for the "second part" defined in Section 4.2.1 of RFC 5393. This second part will not be present if the message was not forked when that Via header field value was added. If the second field is present, the proxy MUST perform the second-part calculation described in Section 4.2.1 of RFC 5393 on this request and compare the result to the value from the Via header field. If these values are equal, the request has looped and the proxy MUST reject the request with a 482 (Loop Detected) response. If the values differ, the request is spiraling and processing continues to the next step.
RFC 5393执行循环检测所需的代理必须在转发请求之前执行以下循环检测测试。必须针对RFC 5393第4.2.1节中定义的“第二部分”检查请求中的每个Via标头字段值，该字段值的sent by值与该代理在以前请求中放置的值相匹配。如果在添加Via头字段值时消息未分叉，则第二部分将不存在。如果存在第二个字段，则代理必须根据该请求执行RFC 5393第4.2.1节所述的第二部分计算，并将结果与Via标头字段的值进行比较。如果这些值相等，则请求已循环，代理必须以482（循环检测）响应拒绝请求。如果值不同，则请求将螺旋上升，处理将继续到下一步。
These requirements and the recommendation to use the loop-detection mechanisms in this document make the favorable trade of exponential message growth for work that is, at worst, order n^2 as a message crosses n proxies. Specifically, this work is order m*n where m is the number of proxies in the path that fork the request to more than one location. In practice, m is expected to be small.
这些要求和本文件中使用循环检测机制的建议使得工作（最坏情况下，当消息跨越n个代理时，顺序为n^2）具有指数消息增长的优势。具体来说，这项工作的顺序是m*n，其中m是路径中将请求分叉到多个位置的代理数。在实践中，m应该很小。
The loop-detection algorithm expressed in this document requires a proxy to inspect each Via element in a received request. In the worst case, where a message crosses N proxies, each of which loop detect, proxy k does k inspections, and the overall number of inspections spread across the proxies handling this request is the sum of k from k=1 to k=N which is N(N+1)/2.
本文档中表示的循环检测算法需要一个代理来检查接收到的请求中的每个Via元素。在最坏的情况下，当消息跨越N个代理时，每个代理都进行循环检测，代理k执行k次检查，并且跨越处理该请求的代理的检查总数是k=1到k=N的k之和，即N（N+1）/2。
A common way to create the second part of the branch parameter value when forking a request is to compute a hash over the concatenation of the Request-URI, any Route header field values used during processing the request, and any other values used by the location service logic while processing this request. The hash should be chosen so that there is a low probability that two distinct sets of these parameters will collide. Because the maximum number of inputs that need to be compared is 70, the chance of a collision is low even with a relatively small hash value, such as 32 bits. CRC-32c as specified in [RFC4960] is a specific acceptable function, as is MD5 [RFC1321]. Note that MD5 is being chosen purely for non-cryptographic properties. An attacker who can control the inputs in order to produce a hash collision can attack the connection in a variety of other ways. When forming the second part using a hash,
分叉请求时创建分支参数值的第二部分的常用方法是计算请求URI、处理请求期间使用的任何路由头字段值以及位置服务逻辑在处理该请求时使用的任何其他值的串联上的散列。应选择散列，以便两组不同的参数发生冲突的概率较低。因为需要比较的最大输入数是70，所以即使使用相对较小的散列值（例如32位），冲突的可能性也很低。[RFC4960]中规定的CRC-32c与MD5[RFC1321]一样，是一种特定的可接受功能。请注意，选择MD5纯粹是为了非加密属性。可以控制输入以产生哈希冲突的攻击者可以通过多种其他方式攻击连接。当使用散列形成第二部分时，
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.
实现应该在哈希的输入中至少包含一个字段，该字段在试图到达同一目的地的不同事务之间变化，以避免哈希冲突时重复失败。调用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头字段值的内容。实现者需要注意避免对另一个元素的Via头字段值的格式做出超出RFC3261对该格式设置的基本约束的假设。特别是，解析具有未知参数名称的标题字段值、没有值的参数或具有或不具有带引号字符串的参数值，不能导致实现失败。
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标头字段中的分支参数值会使将该分支参数放入消息中的节点无法执行循环检测。如果循环中的两个元素以这种方式修改分支参数，则永远无法检测到循环。
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请求导致的并发分支总数。使用此机制，所有可代理请求都被分配一个正整数Max width值，该值表示该请求从当前点转发时通过并行分叉可能产生的最大并发分支数。当代理转发请求时，其最大宽度值将在传出请求中分配。反过来，每个转发的请求对它可能产生的并发分支数量有一个限制。分支完成后，如果需要，它们的最大宽度值部分将可用于后续分支。如果最大宽度不足，无法执行所需的并行分叉，则代理可以返回本文档中定义的440（超出最大宽度）响应。
This mechanism operates independently from Max-Forwards. Max-Forwards limits the depth of the tree a request may traverse as it is forwarded from its origination point to each destination it is forked to. As Section 3 shows, the number of branches in a tree of even limited depth can be made large (exponential with depth) by leveraging forking. Each such branch has a pair of SIP transaction
该机制独立于Max Forwards运行。Max Forwards限制了请求从其起始点转发到其分支到的每个目的地时可以遍历的树的深度。如第3节所示，通过利用分叉，即使深度有限的树中的分支数量也可以变大（与深度成指数关系）。每个这样的分支都有一对SIP事务
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-width机制限制在任何给定时间点处于活动状态（具有运行事务状态机的分支）的数量。
Max-Breadth does not prevent forking. It only limits the number of concurrent parallel forked branches. In particular, a Max-Breadth of 1 restricts a request to pure serial forking rather than restricting it from being forked at all.
最大宽度不能防止分叉。它只限制并发并行分叉分支的数量。特别是，最大宽度为1时，将请求限制为纯串行分叉，而不是限制其被分叉。
A client receiving a 440 (Max-Breadth Exceeded) response can infer that its request did not reach all possible destinations. Recovery options are similar to those when receiving a 483 (Too Many Hops) response, and include affecting the routing decisions through whatever mechanisms are appropriate to result in a less broad search, or refining the request itself before submission to make the search space smaller.
接收到440（超出最大宽度）响应的客户端可以推断其请求没有到达所有可能的目的地。恢复选项与接收483（跳数过多）响应时的选项类似，包括通过任何适当的机制影响路由决策，以减少搜索范围，或在提交请求之前优化请求本身，以缩小搜索空间。
UAC Proxy A Proxy B Proxy C
| INVITE | | |
| Max-Breadth: 60 | INVITE | |
| Max-Forwards: 70 | Max-Breadth: 30 | |
|-------------------->| Max-Forwards: 69 | |
| |------------------->| |
| | INVITE | |
| | Max-Breadth: 30 | |
| | Max-Forwards: 69 | |
| |--------------------------------------->|
| | | |
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 | |
| |--------------------------------------->|
| | | |
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 |
| | |------------------>|
| | | |
| | | |
| | | |
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 == Max-Breadth MF == Max-Forwards
| MB: 4
| MF: 5
MB: 2 P MB: 2
MF: 4 / \ MF: 4
+---------------+ +------------------+
MB: 1 P MB: 1 MB: 1 P MB: 1
MF: 3 / \ MF: 3 MF: 3 / \ MF: 3
+---+ +-------+ +----+ +-------+
P P P P
MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 2 | MF: 2 | MF: 2 | MF: 2 |
P P P P
MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 1 | MF: 1 | MF: 1 | MF: 1 |
P P P P
.
.
.
| MB: 4
| MF: 5
MB: 2 P MB: 2
MF: 4 / \ MF: 4
+---------------+ +------------------+
MB: 1 P MB: 1 MB: 1 P MB: 1
MF: 3 / \ MF: 3 MF: 3 / \ MF: 3
+---+ +-------+ +----+ +-------+
P P P P
MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 2 | MF: 2 | MF: 2 | MF: 2 |
P P P P
MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 1 | MF: 1 | MF: 1 | MF: 1 |
P P P P
.
.
.
Max-Breadth and Max-Forwards Working Together
最大宽度和最大前锋协同工作
The Max-Breadth header field takes a single positive integer as its value. The Max-Breadth header field value takes no parameters.
“最大宽度标头”字段的值为一个正整数。“最大宽度标头”字段值不接受任何参数。
For each "response context" (see Section 16 of [RFC3261]) in a proxy, this mechanism defines two positive integral values: Incoming Max-Breadth and Outgoing Max-Breadth. Incoming Max-Breadth is the value in the Max-Breadth header field in the request that formed the response context. Outgoing Max-Breadth is the sum of the Max-Breadth header field values in all forwarded requests in the response context that have not received a final response.
对于代理中的每个“响应上下文”（参见[RFC3261]第16节），该机制定义了两个正整数值：传入最大宽度和传出最大宽度。Incoming Max Width是构成响应上下文的请求中最大宽度标头字段中的值。Outgoing Max Width是响应上下文中未收到最终响应的所有转发请求中的最大宽度标头字段值之和。
If a SIP proxy receives a request with no Max-Breadth header field value, it MUST add one, with a value that is RECOMMENDED to be 60. Proxies MUST have a maximum allowable Incoming Max-Breadth value, which is RECOMMENDED to be 60. If this maximum is exceeded in a received request, the proxy MUST overwrite it with a value that SHOULD be no greater than its allowable maximum.
如果SIP代理接收到没有最大宽度标头字段值的请求，它必须添加一个，建议值为60。代理必须具有允许的最大传入最大宽度值，建议为60。如果在接收到的请求中超过此最大值，则代理必须使用不应大于其允许的最大值的值覆盖该请求。
All proxied requests MUST contain a single Max-Breadth header field value.
所有代理请求必须包含单个最大宽度标头字段值。
SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the Incoming Max-Breadth in a given response context.
在给定的响应上下文中，SIP代理不能允许传出的最大宽度超过传入的最大宽度。
If a SIP proxy determines a response context has insufficient Incoming Max-Breadth to carry out a desired parallel fork, and the proxy is unwilling/unable to compensate by forking serially or sending a redirect, that proxy MUST return a 440 (Max-Breadth Exceeded) response.
如果SIP代理确定响应上下文的传入最大宽度不足，无法执行所需的并行分叉，并且该代理不愿意/无法通过串行分叉或发送重定向进行补偿，则该代理必须返回440（超出最大宽度）响应。
Notice that these requirements mean a proxy receiving a request with a Max-Breadth of 1 can only fork serially, but it is not required to fork at all -- it can return a 440 instead. Thus, this mechanism is not a tool a user agent can use to force all proxies in the path of a request to fork serially.
请注意，这些要求意味着接收最大宽度为1的请求的代理只能串行分叉，但根本不需要分叉——它可以返回440。因此，此机制不是用户代理可以用来强制请求路径中的所有代理串行分叉的工具。
A SIP proxy MAY distribute Max-Breadth in an arbitrary fashion between active branches. A proxy SHOULD NOT use a smaller amount of Max-Breadth than was present in the original request unless the Incoming Max-Breadth exceeded the proxy's maximum acceptable value. A proxy MUST NOT decrement Max-Breadth for each hop or otherwise use it to restrict the "depth" of a request's propagation.
SIP代理可以在活动分支之间以任意方式分配最大宽度。代理不应使用比原始请求中更小的最大宽度，除非传入的最大宽度超过代理的最大可接受值。代理不能减少每个跃点的最大宽度，也不能使用它来限制请求传播的“深度”。
Because forwarded requests that have received a final response do not count towards the Outgoing Max-Breadth, whenever a final response arrives, the Max-Breadth that was used on that branch becomes available for reuse. Proxies SHOULD be prepared to reuse this Max-Breadth in cases where there may be elements left in the target-set.
因为接收到最终响应的转发请求不计入传出的最大宽度，所以每当最终响应到达时，该分支上使用的最大宽度就可以重用。代理应该准备好在目标集中可能还有元素的情况下重用这个最大宽度。
A User Agent Client (UAC) MAY place a Max-Breadth header field value in outgoing requests. If so, this value is RECOMMENDED to be 60.
用户代理客户端（UAC）可以在传出请求中放置最大宽度头字段值。如果是，建议该值为60。
This mechanism does not affect User Agent Server (UAS) behavior. A UAS receiving a request with a Max-Breadth header field will ignore that field while processing the request.
此机制不会影响用户代理服务器（UAS）行为。UAS接收到带有最大宽度标头字段的请求时，将在处理该请求时忽略该字段。
Since CANCEL requests are never proxied, a Max-Breadth header field value is meaningless in a CANCEL request. Sending a CANCEL in no way affects the Outgoing Max-Breadth in the associated INVITE response context. Receiving a CANCEL in no way affects the Incoming Max-Breadth of the associated INVITE response context.
由于取消请求从不被代理，因此最大宽度标头字段值在取消请求中没有意义。发送取消不会影响关联的INVITE响应上下文中的传出最大宽度。接收取消不会影响关联INVITE响应上下文的传入最大宽度。
Whether 2xx responses free up Max-Breadth is mostly a moot issue, since proxies are forbidden to start new branches in this case. But, there is one caveat. A proxy may receive multiple 2xx responses for a single forwarded INVITE request. Also, [RFC2543] implementations may send back a 6xx followed by a 2xx on the same branch. Implementations that subtract from the Outgoing Max-Breadth when they receive a 2xx response to an INVITE request must be careful to avoid bugs caused by subtracting multiple times for a single branch.
2xx响应是否释放最大宽度主要是一个有争议的问题，因为在这种情况下，代理被禁止启动新分支。但是，有一个警告。对于单个转发的INVITE请求，代理可以接收多个2xx响应。此外，[RFC2543]实现可能会在同一分支上发回一个6xx，后跟一个2xx。当收到对INVITE请求的2xx响应时，从传出最大宽度中减去的实现必须小心，以避免由于对单个分支多次减去而导致的错误。
Designers of automaton user agents (UAs) (including B2BUAs, gateways, exploders, and any other element that programmatically sends requests as a result of incoming SIP traffic) should consider whether Max-Breadth limitations should be placed on outgoing requests. For example, it is reasonable to design B2BUAs to carry the Max-Breadth value from incoming requests into requests that are sent as a result.
自动机用户代理（UAS）的设计者（包括B2BUAS、网关、解析器和任何其他由于传入SIP流量而发出请求的元素）应该考虑是否应该将马克斯宽度限制放在传出请求上。例如，将B2BUA设计为将传入请求的最大宽度值携带到作为结果发送的请求中是合理的。
Also, it is reasonable to place Max-Breadth constraints on sets of requests sent by exploders when they may be leveraged in an amplification attack.
此外，当爆炸器发送的请求集可能被用于放大攻击时，对这些请求集设置最大宽度约束也是合理的。
Inherent in the definition of this mechanism is the ability of a proxy to reclaim apportioned Max-Breadth while forking sequentially. The limitation on outgoing Max-Breadth is applied to concurrent branches only.
此机制的定义中固有的是代理在按顺序分叉时回收分配的最大宽度的能力。对传出最大宽度的限制仅适用于并发分支。
For example, if a proxy receives a request with a Max-Breadth of 4 and has 8 targets to forward it to, that proxy may parallel fork to 4 of these targets initially (each with a Max-Breadth of 1, totaling an Outgoing Max-Breadth of 4). If one of these transactions completes with a failure response, the outgoing Max-Breadth drops to 3, allowing the proxy to forward to one of the 4 remaining targets (again, with a Max-Breadth of 1).
例如，如果代理接收到最大宽度为4的请求，并且有8个目标要转发到该请求，则该代理最初可能会并行到这些目标中的4个（每个目标的最大宽度为1，总共传出的最大宽度为4）。如果其中一个事务在响应失败时完成，则传出的最大宽度将降至3，从而允许代理转发到剩余4个目标中的一个（同样，最大宽度为1）。
There are a variety of mechanisms for controlling the weight of each fork branch. Fork branches that are given more Max-Breadth are more likely to complete quickly (because it is less likely that a proxy down the line will be forced to fork sequentially). By the same token, if it is known that a given branch will not fork later on, a Max-Breadth of 1 may be assigned with no ill effect. This would be appropriate, for example, if a proxy knows the branch is using the SIP outbound extension [OUTBOUND].
有各种各样的机制来控制每个叉枝的重量。给定更多最大宽度的分叉分支更有可能快速完成（因为不太可能强制代理按顺序分叉）。同样，如果已知给定分支稍后不会分叉，则可以指定最大宽度1，而不会产生不良影响。例如，如果代理知道分支正在使用SIP出站扩展[outbound]，这将是合适的。
Max-Breadth limits the total number of active branches spawned by a given request at any one time, while placing no constraint on the distance (measured in hops) that the request can propagate. (i.e., receiving a request with a Max-Breadth of 1 means that any forking must be sequential, not that forking is forbidden)
“最大宽度”（Max Width）限制给定请求在任何时间生成的活动分支总数，同时不限制请求可以传播的距离（以跳数为单位）。（即，接收最大宽度为1的请求意味着任何分叉必须是连续的，而不是禁止分叉）
This limits the effectiveness of any amplification attack that leverages forking because the amount of state/bandwidth needed to process the traffic at any given point in time is capped.
这限制了利用分叉的任何放大攻击的有效性，因为在任何给定时间点处理流量所需的状态/带宽量都是有限的。
This specification extends the grammar for the Session Initiation Protocol by adding an extension-header. The ABNF [RFC5234] definition is as follows.
此规范通过添加扩展头来扩展会话启动协议的语法。ABNF[RFC5234]的定义如下。
Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT
Max-width=“Max-width”HCOLON 1*位
This specification registers a new SIP header field and a new SIP response according to the processes defined in [RFC3261].
本规范根据[RFC3261]中定义的过程注册新的SIP报头字段和新的SIP响应。
This information appears in the Header Fields sub-registry of the SIP Parameters registry.
此信息显示在SIP参数注册表的头字段子注册表中。
RFC 5393 (this specification)
RFC 5393（本规范）
Header Field Name: Max-Breadth
标题字段名称：最大宽度
Compact Form: none
紧凑型：无
This information appears in the Response Codes sub-registry of the SIP Parameters registry.
此信息显示在SIP参数注册表的响应代码子注册表中。
Response code: 440
回应代码：440
Default Reason Phrase: Max-Breadth Exceeded
默认原因短语：超出最大宽度
This document is entirely about documenting and addressing a vulnerability in SIP proxies as defined by RFC 3261 that can lead to an exponentially growing message exchange attack.
本文档完全是关于记录和解决RFC 3261定义的SIP代理中可能导致消息交换攻击呈指数增长的漏洞。
The Max-Breadth mechanism defined here does not decrease the aggregate traffic caused by the forking-loop attack. It only serves to spread the traffic caused by the attack over a longer period by limiting the number of concurrent branches that are being processed at the same time. An attacker could pump multiple requests into a network that uses the Max-Breadth mechanism and gradually build traffic to unreasonable levels. Deployments should monitor carefully and react to gradual increases in the number of concurrent outstanding transactions related to a given resource to protect
此处定义的最大宽度机制不会减少分叉循环攻击造成的聚合流量。它只会通过限制同时处理的并发分支的数量，将攻击造成的流量传播更长的时间。攻击者可以向使用最大宽度机制的网络中发送多个请求，并逐渐将流量增加到不合理的水平。部署应仔细监控与要保护的给定资源相关的并发未完成事务数量的逐渐增加，并作出反应
against this possibility. Operators should anticipate being able to temporarily disable any resources identified as being used in such an attack. A rapid increase in outstanding concurrent transactions system-wide may be an indication of the presence of this kind of attack across many resources. Deployments in which it is feasible for an attacker to obtain a very large number of resources are particularly at risk. If detecting and intervening in each instance of the attack is insufficient to reduce the load, overload may occur.
反对这种可能性。操作员应该能够临时禁用被识别为在此类攻击中使用的任何资源。系统范围内未完成的并发事务的快速增加可能表明存在跨多个资源的此类攻击。攻击者可以获得大量资源的部署尤其危险。如果检测和干预每个攻击实例不足以减少负载，则可能会发生过载。
Implementers and operators are encouraged to follow the recommendations being developed for handling overload conditions (see [REQS] and [DESIGN]).
鼓励实施者和操作员遵循为处理过载条件而制定的建议（参见[REQS]和[DESIGN]）。
Designers of protocol gateways should consider the implications of this kind of attack carefully. As an example, if a message transits from a SIP network into the Public Switched Telephone Network (PSTN) and subsequently back into a SIP network, and information about the history of the request on either side of the protocol translation is lost, it becomes possible to construct loops that neither Max-Forwards nor loop detection can protect against. This, combined with forking amplification on the SIP side of the loop, will result in an attack as described in this document that the mechanisms here will not abate, not even to the point of limiting the number of concurrent messages in the attack. These considerations are particularly important for designers of gateways from SIP to SIP (as found in B2BUAs, for example). Many existing B2BUA implementations are under some pressure to hide as much information about the two sides communicating with them as possible. Implementers of such implementations may be tempted to remove the data that might be used by the loop-detection, Max-Forwards, or Max-Breadth mechanisms at other points in the network, taking on the responsibility for detecting loops (or forms of this attack). However, if two such implementations are involved in the attack, neither will be able to detect it.
协议网关的设计者应该仔细考虑这种攻击的含义。例如，如果消息从SIP网络传输到公共交换电话网络（PSTN）并随后返回到SIP网络，并且关于协议转换任一侧的请求历史的信息丢失，可以构造Max-Forwards和loop-detection都无法保护的循环。这与循环SIP侧的分叉放大相结合，将导致本文档中描述的攻击，此处的机制不会减弱，甚至不会限制攻击中并发消息的数量。这些注意事项对于从SIP到SIP的网关的设计者来说尤其重要（例如，在B2BUAs中可以找到）。许多现有的B2BUA实现都面临一些压力，需要尽可能多地隐藏与它们通信的双方的信息。此类实现的实现者可能会试图删除网络中其他点的循环检测、最大转发或最大宽度机制可能使用的数据，从而承担检测循环（或这种攻击形式）的责任。但是，如果攻击涉及两个这样的实现，则两个实现都无法检测到它。
Alternative solutions that were discussed include:
讨论的替代解决方案包括：
Doing nothing - rely on suing the offender: While systems that have accounts have logs that can be mined to locate abusers, it isn't clear that this provides a credible deterrent or defense against the attack described in this document. Systems that don't recognize the situation and take corrective/preventative action are likely to experience failure of a magnitude that precludes retrieval of the records documenting the setup of the attack. (In one scenario, the registrations can occur in a radically different time period than the INVITE transaction. The INVITE request
无所作为——依靠起诉罪犯：虽然有账户的系统有日志，可以通过挖掘来定位施虐者，但不清楚这是否能对本文件中描述的攻击提供可信的威慑或防御。不识别情况并采取纠正/预防措施的系统可能会遇到严重故障，从而无法检索记录攻击设置的记录。（在一种情况下，注册可能发生在与INVITE事务截然不同的时间段
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.
它本身可能来自一个无辜的人）。甚至有可能是无意中设置了该场景。此外，对于某些现有部署，帐户的成本和审计能力只是一个电子邮件地址。找人惩罚可能是不可能的。最后，有些人不会对任何法律行动的威胁作出回应，即使是这种攻击的一个成功案例，对服务提供商来说都将是毁灭性的。
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 5.3.3.1). Under this alternative, an introduced request would cause, at most, the initial value of Max-Breadth transactions to be generated in the network. While that approach limits any variant of the amplification vulnerability described here to a constant multiplier, it would dramatically change the potential reach of requests, and there is belief that it would break existing deployments.
不回收宽度：考虑并拒绝的最大宽度机制的替代设计是不允许重复使用已完成分支的宽度（见第5.3.3.1节）。在此替代方案下，引入的请求最多会导致在网络中生成最大宽度事务的初始值。虽然这种方法将此处描述的放大漏洞的任何变体限制为一个恒定的乘数，但它将极大地改变请求的潜在范围，而且人们相信它将破坏现有部署。
Thanks go to the implementers that subjected their code to this scenario and helped analyze the results at SIPit 17. Eric Rescorla provided guidance and text for the hash recommendation note.
感谢将代码置于该场景中并在SIPit 17上帮助分析结果的实现者。Eric Rescorla为哈希建议注释提供了指导和文本。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[DESIGN] Hilt, V., "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Work in Progress, July 2008.
[设计]Hilt，V.，“会话启动协议（SIP）过载控制的设计考虑”，正在进行的工作，2008年7月。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, October 2008.
[OUTBOUND]Jennings，C.和R.Mahy，“在会话启动协议（SIP）中管理客户端启动的连接”，正在进行的工作，2008年10月。
[REQS] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", Work in Progress, July 2008.
[REQS]Rosenberg，J.，“会话启动协议中过载管理的要求”，正在进行的工作，2008年7月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC2543]Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
Authors' Addresses
作者地址
Robert Sparks (editor) Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
Robert Sparks（编辑）Tekelec 17210坎贝尔路250号套房，德克萨斯州达拉斯75254-4203
EMail: RjS@nostrum.com
EMail: RjS@nostrum.com
Scott Lawrence Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA
斯科特·劳伦斯·北电网络有限公司，美国马萨诸塞州比尔里卡科技园600号，邮编01821
Phone: +1 978 288 5508
EMail: scott.lawrence@nortel.com
Phone: +1 978 288 5508
EMail: scott.lawrence@nortel.com
Alan Hawrylyshen Ditech Networks Inc. 823 E. Middlefield Rd Mountain View, CA 94043 USA
Alan Hawrylyshen Ditech Networks Inc.美国加利福尼亚州山景城米德菲尔德东路823号，邮编94043
Phone: +1 650 623 1300
EMail: alan.ietf@polyphase.ca
Phone: +1 650 623 1300
EMail: alan.ietf@polyphase.ca
Byron Campen Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
美国德克萨斯州达拉斯市坎贝尔路250号拜伦坎本特克莱克17210室75254-4203
EMail: bcampen@estacado.net
EMail: bcampen@estacado.net