Network Working Group V. Lehtovirta
Request for Comments: 4771 M. Naslund
Category: Standards Track K. Norrman
Ericsson
January 2007
Network Working Group V. Lehtovirta
Request for Comments: 4771 M. Naslund
Category: Standards Track K. Norrman
Ericsson
January 2007
Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)
安全实时传输协议（SRTP）的完整性转换携带滚动计数器
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) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization.
本文档定义了安全实时传输协议（SRTP；参见RFC 3711）的完整性转换，该协议允许在SRTP数据包中传输滚动计数器（ROC），作为身份验证标签的一部分。在接收机加入正在进行的SRTP会话并且需要快速且可靠地同步的情况下，需要在SRTP分组中发送ROC。该机制还增强了SRTP在存在丢失发送方-接收方同步风险的情况下的运行。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. The Transform ...................................................3
3. Transform Modes .................................................5
4. Parameter Negotiation ...........................................5
5. Security Considerations .........................................7
6. IANA Considerations ............................................10
7. Acknowledgements ...............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. The Transform ...................................................3
3. Transform Modes .................................................5
4. Parameter Negotiation ...........................................5
5. Security Considerations .........................................7
6. IANA Considerations ............................................10
7. Acknowledgements ...............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
When a receiver joins an ongoing SRTP [RFC3711] session, out-of-band signaling must provide the receiver with the value of the ROC the sender is currently using. For instance, it can be transferred in the Common Header Payload of a MIKEY [RFC3830] message. In some cases, the receiver will not be able to synchronize his ROC with the one used by the sender, even if it is signaled to him out of band. Examples of where synchronization failure will appear are:
当接收器加入正在进行的SRTP[RFC3711]会话时，带外信令必须向接收器提供发送方当前使用的ROC值。例如，它可以在MIKEY[RFC3830]消息的公共报头有效载荷中传输。在某些情况下，接收方将无法将其ROC与发送方使用的ROC同步，即使在带外向其发送信号。出现同步失败的示例有：
1. The receiver receives the ROC in a MIKEY message together with a key required for a particular continuous service. He does not, however, join the service until after a few hours, at which point the sender's sequence number (SEQ) has wrapped around, and so the sender, meanwhile, has increased the value of ROC. When the user joins the service, he grabs the SEQ from the first seen SRTP packet and prepends the ROC to build the index. If integrity protection is used, the packet will be discarded. If there is no integrity protection, the packet may (if key derivation rate is non-zero) be decrypted using the wrong session key, as ROC is used as input in session key derivation. In either case, the receiver will not have its ROC synchronized with the sender, and it is not possible to recover without out-of-band signaling.
1. 接收器接收MIKEY消息中的ROC以及特定连续服务所需的密钥。然而，他直到几个小时后才加入该服务，此时发送者的序列号（SEQ）已经结束，因此发送者同时增加了ROC的值。当用户加入服务时，他从第一个看到的SRTP数据包中获取SEQ，并预先准备ROC以构建索引。如果使用完整性保护，数据包将被丢弃。如果没有完整性保护，则可能会使用错误的会话密钥对数据包（如果密钥派生率为非零）进行解密，因为ROC被用作会话密钥派生中的输入。在任何一种情况下，接收机都不会使其ROC与发送方同步，并且在没有带外信令的情况下不可能恢复。
2. If the receiver leaves the session (due to being out of radio coverage or because of a user action), and does not start receiving traffic from the service again until after 2^15 packets have been sent, the receiver will be out of synchronization (for the same reasons as in example 1).
2. 如果接收器离开会话（由于超出无线电覆盖范围或由于用户操作），并且直到发送了2^15个数据包后才再次开始接收来自服务的通信量，则接收器将失去同步（原因与示例1相同）。
3. The receiver joins a service when the SEQ has recently wrapped around (say, SEQ = 0x0001). The sender generates a MIKEY message and includes the current value of ROC (say, ROC = 1) in the MIKEY message. The MIKEY message reaches the receiver, who reads the ROC value and initializes its local ROC to 1. Now, if an SRTP packet prior to wraparound, i.e., with a SEQ lower than 0 (say, SEQ = 0xffff), was delayed and reaches the receiver as the first SRTP packet he sees, the receiver will initialize its highest received sequence number, s_l, to 0xffff. Next, the receiver will receive SRTP packets with sequence numbers larger than zero, and will deduce that the SEQ has wrapped. Hence, the receiver will incorrectly update the ROC and be out of synchronization.
3. 当SEQ最近已结束时（例如，SEQ=0x0001），接收方加入服务。发送方生成MIKEY消息，并在MIKEY消息中包含ROC的当前值（例如，ROC=1）。MIKEY消息到达接收者，接收者读取ROC值并将其本地ROC初始化为1。现在，如果在环绕之前的SRTP数据包（即，SEQ小于0（例如，SEQ=0xffff））被延迟并作为他看到的第一个SRTP数据包到达接收器，则接收器将其最高接收序列号s_l初始化为0xffff。接下来，接收器将接收序列号大于零的SRTP包，并将推断SEQ已包装。因此，接收器将不正确地更新ROC并且不同步。
4. Similarly to (3), since the initial SEQ is selected at random by the sender, it may happen to be selected as a value very close to 0xffff. In this case, should the first few packets be lost, the receiver may similarly end up out of synchronization.
4. 与（3）类似，由于发送方随机选择初始SEQ，因此它可能恰好被选择为非常接近0xffff的值。在这种情况下，如果前几个数据包丢失，则接收机可能类似地结束不同步。
These problems have been recognized in, e.g., 3GPP2 and 3GPP, where SRTP is used for streaming media protection in their respective multicast/broadcast solutions [BCMCS][MBMS]. Problem 4 actually exists inherently due to the way SEQ initialization is done in RTP.
例如，在3GPP2和3GPP中已经认识到这些问题，其中SRTP在其各自的多播/广播解决方案[BCMCS][MBMS]中用于流媒体保护。由于在RTP中进行SEQ初始化的方式，问题4实际上固有地存在。
One possible approach to address the issue could be to carry the ROC in the MKI (Master Key Identifier) field of each SRTP packet. This has the advantage that the receiver immediately knows the entire index for a packet. Unfortunately, the MKI has no semantics in RFC 3711 (other than specifying master key), and a regular RFC 3711 compliant implementation would not be able to make use of the information carried in the MKI. Furthermore, the MKI field is not integrity protected; hence, care must be taken to avoid obvious attacks against the synchronization.
解决该问题的一种可能方法是在每个SRTP分组的MKI（主密钥标识符）字段中携带ROC。这样做的优点是，接收方立即知道数据包的整个索引。不幸的是，MKI在RFC3711中没有语义（除了指定主密钥之外），常规的RFC3711兼容实现将无法使用MKI中携带的信息。此外，MKI字段没有完整性保护；因此，必须注意避免对同步的明显攻击。
In this document, a solution is presented where the ROC is carried in the authentication tag of a special integrity transform in selected SRTP packets.
在本文中，提出了一种解决方案，其中ROC携带在选定SRTP数据包中的特殊完整性转换的认证标签中。
The benefit of this approach is that the functionality of fast and robust synchronization can be achieved as a separate integrity transform, using the hooks existing in SRTP. Furthermore, when the ROC is transmitted to the receiver it needs to be integrity protected to avoid persistent denial-of-service (DoS) attacks or transmission errors that could bring the receiver out of synchronization. (A DoS attack is regarded as persistent if it can last after the attacker has left the area; in this particular case, an attacker could modify the ROC in one packet and the victim would be out of synchronization until the next ROC is transmitted). The above discussion leads to the conclusion that it makes sense to carry the ROC inside the authentication tag of an integrity transform.
这种方法的好处是，使用SRTP中现有的钩子，可以通过单独的完整性转换实现快速和健壮的同步功能。此外，当ROC被传输到接收机时，需要对其进行完整性保护，以避免可能导致接收机不同步的持续拒绝服务（DoS）攻击或传输错误。（如果DoS攻击能够在攻击者离开该区域后持续，则认为该攻击是持续的；在这种特殊情况下，攻击者可以在一个数据包中修改ROC，而受害者将在下一个ROC传输之前失去同步）。上面的讨论得出这样的结论：在完整性转换的身份验证标记中携带ROC是有意义的。
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]中所述进行解释。
The transform, hereafter called Roll-over Counter Carrying Transform (or RCC for short), works as follows.
转换，以下称为滚动计数器携带转换（简称RCC），工作原理如下。
The sender processes the RTP packet according to RFC 3711. When applying the message integrity transform, the sender checks if the SEQ is equal to 0 modulo some non-zero integer constant R. If that is the case, the sender computes the MAC in the same way as is done when using the default integrity transform (i.e., HMAC-SHA1(auth_key,
发送方根据RFC 3711处理RTP分组。应用消息完整性转换时，发送方检查SEQ是否等于0乘以某个非零整数常量R。如果是这种情况，发送方计算MAC的方式与使用默认完整性转换时相同（即HMAC-SHA1（auth_key，
Authenticated_portion || ROC)). Next, the sender truncates the MAC by 32 bits to generate MAC_tr, i.e., MAC_tr is the tag_length - 32 most significant bits of the MAC. Next, the sender constructs the tag as TAG = ROC_sender || MAC_tr, where ROC_sender is the value of his local ROC, and appends the tag to the packet. See the security considerations section for discussions on the effects of shortening the MAC. In particular, note that a tag-length of 32 bits gives no security at all.
经认证的（U部分| | ROC））。接下来，发送方将MAC截断32位以生成MAC_tr，即MAC_tr是标记长度-MAC的32个最高有效位。接下来，发送方将标记构造为tag=ROC|u sender | MAC|tr，其中ROC|u sender是其本地ROC的值，并将标记附加到包中。有关缩短MAC的影响的讨论，请参见安全注意事项部分。特别要注意的是，32位的标记长度根本不提供安全性。
If the SEQ is not equal to 0 mod R, the sender just proceeds to process the packet according to RFC 3711 without performing the actions in the previous paragraph.
如果SEQ不等于0 mod R，则发送方仅根据RFC 3711处理分组，而不执行上一段中的操作。
The value R is the rate at which the ROC is included in the SRTP packets. Since the ROC consumes four octets, this gives the possibility to use it sparsely.
值R是在SRTP分组中包括ROC的速率。由于ROC消耗四个八位字节，因此可以稀疏地使用它。
When the receiver receives an SRTP packet, it processes the packet according to RFC 3711 except that during authentication processing ROC_local is replaced by ROC_sender (retrieved from the packet). This works as follows. In the step where integrity protection is to be verified, if the SEQ is equal to 0 modulo R, the receiver extracts ROC_sender from the TAG and verifies the MAC computed (in the same way as if the default integrity transform was used) over the authenticated portion of the packet (as defined in [RFC3711]), but concatenated with ROC_sender instead of concatenated with the local_ROC. The receiver generates MAC_tr for the MAC verification in the same way the sender did. Note that the session key used in the MAC calculation is dependent on the ROC, and during the derivation of the session integrity key, the ROC found in the packet under consideration MUST be used. If the verification is successful, the receiver sets his local ROC equal to the ROC carried in the packet. If the MAC does not verify, the packet MUST be dropped. The rationale for using the ROC from the packet in the MAC calculation is that if the receiver has an incorrect ROC value, MAC verification will fail, so the receiver will not correct his ROC.
当接收机接收到SRTP分组时，它根据RFC 3711处理分组，除了在认证处理期间ROC_local被ROC_发送方（从分组检索）替换之外。其工作原理如下。在验证完整性保护的步骤中，如果SEQ等于0模R，则接收机从标签中提取ROC_发送方，并验证在分组的认证部分（如[RFC3711]中所定义）上计算的MAC（与使用默认完整性转换的方式相同），但是与ROC\u发送方连接，而不是与本地ROC连接。接收方以与发送方相同的方式为MAC验证生成MAC_tr。注意，MAC计算中使用的会话密钥取决于ROC，并且在会话完整性密钥的推导过程中，必须使用在所考虑的分组中找到的ROC。如果验证成功，接收器将其本地ROC设置为与数据包中携带的ROC相等。如果MAC未验证，则必须丢弃数据包。在MAC计算中使用来自分组的ROC的基本原理是，如果接收器具有不正确的ROC值，MAC验证将失败，因此接收器将不会纠正其ROC。
If the SEQ is not equal to 0 mod R, the receiver just proceeds to process the packet according to RFC 3711 without performing the actions in the previous paragraph.
如果SEQ不等于0 mod R，则接收器仅根据RFC 3711处理分组，而不执行上一段中的动作。
Since Secure Real-time Transport Control Protocol (SRTCP) already carries the entire index in-band, there is no reason to apply this transform to SRTCP. Hence, the transform SHALL only be applied to SRTP, and SHALL NOT be used with SRTCP.
由于安全实时传输控制协议（SRTCP）已在频带内承载整个索引，因此没有理由将此转换应用于SRTCP。因此，转换只能应用于SRTP，不得与SRTCP一起使用。
The above transform only provides integrity protection for the packets that carry the ROC (this will be referred to as mode 1). In the cases where there is a need to integrity protect all the packets, the packets that do not have SEQ equal to 0 mod R MUST be protected using the default integrity transform (this will be referred to as mode 2).
上述转换仅为携带ROC的分组提供完整性保护（这将被称为模式1）。在需要完整性保护所有数据包的情况下，SEQ不等于0 mod R的数据包必须使用默认完整性转换进行保护（这将被称为模式2）。
Under some circumstances, it may be acceptable not to use integrity protection on any of the packets; this will be referred to as mode 3. Without integrity protection of the packets carrying the ROC, a DoS attack, which will prevail until the next correctly received ROC, is possible. Make sure to carefully read the security considerations in Section 5 before using mode 3.
在某些情况下，不在任何数据包上使用完整性保护是可以接受的；这将被称为模式3。如果没有对携带ROC的数据包的完整性保护，则可能发生DoS攻击，直到下一个正确接收到的ROC。在使用模式3之前，请务必仔细阅读第5节中的安全注意事项。
In case no integrity protection is offered, i.e., mode 3, the following applies. The receiver's SRTP layer SHOULD ignore the ROC value from the packet if the application layer can indicate to it that the local ROC is synchronized with the sender (hence, the packet would be processed using the local ROC). Note that the received ROC still MUST be removed from the packet before continued processing. In this scenario, the application layer feedback to the SRTP layer need not be on a per-packet basis, and it can consist merely of a boolean value set by the application layer and read by the SRTP layer.
如果未提供完整性保护，即模式3，则以下情况适用。如果应用层可以向接收方指示本地ROC与发送方同步，则接收方的SRTP层应该忽略来自分组的ROC值（因此，将使用本地ROC处理分组）。注意，在继续处理之前，仍然必须从数据包中删除接收到的ROC。在这种情况下，向SRTP层反馈的应用层不需要基于每个数据包，它可以仅由应用层设置并由SRTP层读取的布尔值组成。
Thus, note the following difference. Using mode 2 will integrity protect all RTP packets, but only add ROC to those having SEQ divisible by R. Using mode 1 and setting R equal to one will also integrity protect all packets, but will in addition to that add ROC to each packet. Modes 1 and 2 MUST compute the MAC in the same way as the pre-defined authentication transform for SRTP, i.e., HMAC-SHA1.
因此，请注意以下区别。使用模式2将完整性保护所有RTP数据包，但仅将ROC添加到SEQ可被R整除的数据包。使用模式1并将R设置为1也将完整性保护所有数据包，但除此之外，还将向每个数据包添加ROC。模式1和2必须以与SRTP的预定义身份验证转换相同的方式计算MAC，即HMAC-SHA1。
To comply with this specification, mode 1, mode 2, and mode 3 are MANDATORY to implement. However, it is up to local policy to decide which mode(s) are allowed to be used.
为符合本规范，必须实施模式1、模式2和模式3。但是，由当地政策决定允许使用哪种模式。
RCC requires that a few parameters are signaled out of band. The parameters that must be in place before the transform can be used are integrity transform mode and the rate, R, at which the ROC will be transmitted. This can be done using, e.g., MIKEY [RFC3830].
RCC要求在带外发送一些参数的信号。在可以使用转换之前必须到位的参数是完整性转换模式和ROC将被传输的速率R。这可以使用MIKEY[RFC3830]等工具完成。
To perform the parameter negotiation using MIKEY, three integrity transforms have been registered -- RCCm1, RCCm2, and RCCm3 in Table 6.10.1.c of [RFC3830] -- for the three modes defined.
为了使用MIKEY执行参数协商，已针对定义的三种模式注册了三种完整性转换，[RFC3830]表6.10.1.c中的RCCm1、RCCm2和RCCm3。
Table 1. Integrity transforms
表1。完整性转换
SRTP auth alg | Value
--------------+------
RCCm1 | 2
RCCm2 | 3
RCCm3 | 4
SRTP auth alg | Value
--------------+------
RCCm1 | 2
RCCm2 | 3
RCCm3 | 4
Furthermore, the parameter R has been registered in Table 6.10.1.a of [RFC3830].
此外，参数R已记录在[RFC3830]的表6.10.1.a中。
Table 2. Integrity transform parameter
表2。完整性变换参数
Type | Meaning | Possible values
-----+-----------------------------+----------------
13 | ROC transmission rate | 16-bit integer
Type | Meaning | Possible values
-----+-----------------------------+----------------
13 | ROC transmission rate | 16-bit integer
The ROC transmission rate, R, is given in network byte order. R MUST be a non-zero unsigned integer. If the ROC transmission rate is not included in the negotiation, the default value of 1 SHALL be used.
ROC传输速率R以网络字节顺序给出。R必须是非零无符号整数。如果协商中不包括ROC传输速率，则应使用默认值1。
To have the ability to use different integrity transforms for SRTP and SRTCP, which is needed in connection to the use of RCC, the following additional parameters have been registered in Table 6.10.1.a of [RFC3830]:
为了能够对SRTP和SRTCP使用不同的完整性转换，这是使用RCC所需的，以下附加参数已在[RFC3830]的表6.10.1.a中登记：
Table 3. Integrity parameters
表3。完整性参数
Type | Meaning | Possible values
-----+-----------------------------+----------------
14 | SRTP Auth. algorithm | see below
15 | SRTCP Auth. algorithm | see below
16 | SRTP Session Auth. key len | see below
17 | SRTCP Session Auth. key len | see below
18 | SRTP Authentication tag len | see below
19 | SRTCP Authentication tag len| see below
Type | Meaning | Possible values
-----+-----------------------------+----------------
14 | SRTP Auth. algorithm | see below
15 | SRTCP Auth. algorithm | see below
16 | SRTP Session Auth. key len | see below
17 | SRTCP Session Auth. key len | see below
18 | SRTP Authentication tag len | see below
19 | SRTCP Authentication tag len| see below
The possible values for authentication algorithms (types 14 and 15) are the same as for the "Authentication algorithm" parameter (type 2) in Table 6.10.1.a of RFC 3830 with the addition of the values found in Table 1 above.
认证算法（类型14和15）的可能值与RFC 3830表6.10.1.a中“认证算法”参数（类型2）的可能值相同，加上上面表1中的值。
The possible values for session authentication key lengths (types 16 and 17) are the same as for the "Session Auth. key length" parameter (type 3) in Table 6.10.1.a of RFC 3830.
会话身份验证密钥长度（类型16和17）的可能值与RFC 3830表6.10.1.a中“会话身份验证密钥长度”参数（类型3）的可能值相同。
The possible values for authentication tag lengths (types 18 and 19) are the same as for the "Authentication tag length" parameter (type 11) in Table 6.10.1.a of RFC 3830 with the addition that the length of ROC MUST be included in the "Authentication tag length" parameter. This means that the minimum tag length when using RCC is 32 bits.
认证标签长度（类型18和19）的可能值与RFC 3830表6.10.1.a中“认证标签长度”参数（类型11）的可能值相同，此外，ROC的长度必须包含在“认证标签长度”参数中。这意味着使用RCC时的最小标记长度为32位。
To avoid ambiguities when introducing these new parameters that have overlapping functionality to existing parameters in Table 6.10.1.a of RFC 3830, the following approach MUST be taken: If any of the parameter types 14-19 (specifying behavior specific to SRTP or SRTCP) and a corresponding general parameter (type 2, 3, or 11) are both present in the policy, the more specific parameter SHALL have precedence. For example, if the "Authentication algorithm" parameter (type 2) is set to HMAC-SHA-1, and the "SRTP Auth. Algorithm" (type 14) is set to RCCm1, SRTP will use the RCCm1 algorithm, but since there is no specific algorithm chosen for SRTCP, the more generally specified one (HMAC-SHA-1) is used.
为避免在引入这些新参数时产生歧义，这些新参数与RFC 3830表6.10.1.a中的现有参数具有重叠功能，必须采取以下方法：如果参数类型14-19（指定特定于SRTP或SRTCP的行为）和相应的一般参数（类型2、3或11）如果两者都存在于保单中，则更具体的参数应具有优先权。例如，如果“身份验证算法”参数（类型2）设置为HMAC-SHA-1，“SRTP身份验证算法”（类型14）设置为RCCm1，SRTP将使用RCCm1算法，但由于没有为SRTCP选择特定算法，因此使用更通用的指定算法（HMAC-SHA-1）。
An analogous method already exists in SRTCP (the SRTCP index is carried in each packet under integrity protection). To the best of our knowledge, the only security consideration introduced here is that the entire SRTP index (ROC || SEQ) will become public since it is transferred without encryption. (In normal SRTP operation, only the SEQ-part of the index is disclosed.) However, RFC 3711 does not identify a need for encrypting the SRTP index.
SRTCP中已经存在类似的方法（SRTCP索引在完整性保护下的每个数据包中携带）。据我们所知，这里介绍的唯一安全考虑是整个SRTP索引（ROC | | SEQ）将公开，因为它是在不加密的情况下传输的。（在正常的SRTP操作中，仅公开索引的SEQ部分。）然而，RFC 3711不确定加密SRTP索引的需要。
It is important to realize that only every Rth packet is integrity protected in mode 1, so unless R = 1, the mechanism should be seen for what it is: a way to improve sender-receiver synchronization, and not a replacement for integrity protection.
重要的是要认识到，在模式1中，只有每个Rth数据包都受到完整性保护，因此，除非R=1，否则应了解该机制的本质：一种改进发送方-接收方同步的方法，而不是完整性保护的替代品。
The use of mode 3 (NULL-MAC) introduces a vulnerability not present in RFC 3711; namely, if an attacker modifies the ROC, the modification will go undetected by the receiver, and the receiver will lose cryptographic synchronization until the next correct ROC is received. This implies that an attacker can perform a DoS attack by only modifying every Rth packet. Because of this, mode 3 MUST only be used after proper risk assessment of the underlying network. Besides the considerations in Section 9.5 and 9.5.1 of RFC 3711, additional requirements of the underlying transport network must be met.
模式3（NULL-MAC）的使用引入了RFC 3711中不存在的漏洞；也就是说，如果攻击者修改了ROC，那么接收方将无法检测到修改，并且接收方将丢失加密同步，直到收到下一个正确的ROC。这意味着攻击者只需修改每个Rth数据包即可执行DoS攻击。因此，只有在对基础网络进行适当的风险评估后，才能使用模式3。除了RFC 3711第9.5节和第9.5.1节中的考虑因素外，还必须满足基础运输网络的其他要求。
o The transport network must only consist of trusted domains. That means that everyone on the path from the source to the destination is trusted not to modify or inject packets.
o 传输网络必须仅由受信任的域组成。这意味着从源到目标的路径上的每个人都被信任不会修改或注入数据包。
o The transport network must be protected from packet injection, i.e., it must be ensured that the only packets present on the path from the source to the destination(s) originate from trusted sources.
o 必须保护传输网络不受数据包注入的影响，即，必须确保从源到目的地的路径上仅存在来自可信源的数据包。
o If the packets, on their way from the source to the destination(s), travel outside of a trusted domain, their integrity must be ensured (e.g., by using a Virtual Private Network (VPN) connection or a trusted leased line).
o 如果数据包在从源到目的地的途中在受信任域之外移动，则必须确保其完整性（例如，通过使用虚拟专用网络（VPN）连接或受信任的租用线路）。
In the (assumed common) case that the last link to the destination(s) is a wireless link, the possibility that an attacker injects forged packets here must be carefully considered before using mode 3. Especially, if used in a broadcast setting, many destinations would be affected by the attack. However, unless R is big, this DoS attack would be similar in effect to radio jamming, which would be easier to perform.
在（假设常见）情况下，到目的地的最后一条链路是无线链路，在使用模式3之前，必须仔细考虑攻击者在此处注入伪造数据包的可能性。特别是，如果在广播环境中使用，许多目的地都会受到攻击的影响。然而，除非R很大，否则这种DoS攻击在效果上类似于无线电干扰，更容易执行。
It must also be noted that if the ROC is modified by an attacker and no integrity protection is used, the output of the decryption will not be useful to the upper layers, and these must be able to cope with data that appears random. In the case integrity protection is used on the packets containing the ROC, and the ROC is modified by an attacker (and the receiver already has an approximation of the ROC, e.g., by getting it previously), the packet will be discarded and the receiver will not be able to decrypt correctly. Note, however, that the situation is better in the latter case, since the receiver now can try different ROC values in a neighborhood around the approximate value he already has.
还必须注意的是，如果攻击者修改了ROC，并且没有使用完整性保护，则解密的输出对上层将没有用处，而上层必须能够处理看似随机的数据。如果攻击者已经在ROC上正确使用了数据包，那么接收方将无法对其进行解密（例如，ROC将不会正确使用数据包的完整性）。然而，请注意，在后一种情况下，情况会更好，因为接收者现在可以在其已有的近似值附近尝试不同的ROC值。
As RCC is expected to be used in a broadcast setting where group membership will be based on access to a symmetric group key, it is important to point out the following. With symmetric-key-based integrity protection, it may be as easy, if not easier, to get access to the integrity key (often a combination of a low-cost activity of purchasing a subscription and breaking the security of a terminal to extract the integrity key) as being able to transmit.
由于RCC预计将用于广播设置，其中组成员资格将基于对对称组密钥的访问，因此必须指出以下几点。使用基于对称密钥的完整性保护，访问完整性密钥（通常是购买订阅和破坏终端安全以提取完整性密钥的低成本活动的组合）可能与能够传输相同容易（如果不是更容易的话）。
A word of warning regarding the choice of length of the authentication tag: Note that, in contrast to common MAC tags, there is a clear distinction made between the RCC authentication tag and the RCC MAC. The tag is the container holding the MAC (and for some packets also the ROC), and the MAC is the output from the MAC-algorithm (i.e., HMAC-SHA1). The length of the authentication tag
关于认证标签长度选择的警告：注意，与普通MAC标签相比，RCC认证标签和RCC MAC之间有明确的区别。标签是保存MAC的容器（对于某些数据包也是ROC），MAC是MAC算法（即HMAC-SHA1）的输出。身份验证标记的长度
with the RCC transform includes the four-octet ROC in some packets. This means that for a tag-length of n octets, there is only room for a MAC of length n - 4, i.e., a tag-length of n octets does not provide a full n-octet integrity protection on all packets. There are five cases:
在RCC转换中，在一些数据包中包含四个八位组ROC。这意味着对于长度为n个八位字节的标签，只有空间容纳长度为n-4的MAC，即，长度为n个八位字节的标签不能对所有数据包提供完整的n个八位字节完整性保护。有五种情况：
1. RCCm1 is used and tag-length is n. For those packets that SEQ = 0 mod R, the ROC is carried in the tag and occupies four octets. This leaves n - 4 octets for the MAC.
1. 使用RCCm1，标签长度为n。对于那些SEQ=0 mod R的数据包，ROC携带在标签中并占据四个八位组。这就为MAC留下了n-4个八位组。
2. RCCm1 is used and tag-length is n. For those packets that SEQ != 0 mod R, there is no ROC carried in the tag. For RCCm1 there is no MAC on packets not carrying the ROC, so neither the length of the MAC nor the length of the tag has any relevance.
2. 使用RCCm1，标签长度为n。对于以下数据包！=0 mod R，标签中没有携带ROC。对于RCCm1，不携带ROC的数据包上没有MAC，因此MAC的长度和标签的长度都没有任何相关性。
3. RCCm2 is used and tag-length is n. For those packets that SEQ = 0 mod R, the ROC is carried in the tag and occupies four octets. This leaves n - 4 octets for the MAC (this is equivalent to case 1).
3. 使用RCCm2，标签长度为n。对于那些SEQ=0 mod R的数据包，ROC携带在标签中并占据四个八位组。这就为MAC留下了n-4个八位字节（这相当于情况1）。
4. RCCm2 is used and tag-length is n. For those packets that SEQ != 0 mod R, there is no ROC carried in the tag. This leaves n octets for the MAC.
4. 使用RCCm2，标签长度为n。对于以下数据包！=0 mod R，标签中没有携带ROC。这就为MAC留下了n个八位字节。
5. RCCm3 is used. RCCm3 does not use any MAC, but the ROC still occupies four octets in the tag for packets with SEQ = 0 mod R, so the tag-length MUST be set to four. For packets with SEQ != 0 mod R, neither the length of the MAC nor the length of the tag has any relevance.
5. 使用RCCm3。RCCm3不使用任何MAC，但对于SEQ=0 mod R的数据包，ROC仍然占据标签中的四个八位字节，因此标签长度必须设置为四。对于带有SEQ！=0 mod R，MAC的长度和标记的长度都没有任何相关性。
The conclusion is that in cases 1 and 3, the length of the MAC is shorter than the length of the authentication tag. To achieve the same (or less) MAC forgery success probability on all packets when using RCCm1 or RCCm2, as with the default integrity transform in RFC 3711, the tag-length must be set to 14 octets, which means that the length of MAC_tr is 10 octets.
结论是，在情况1和3中，MAC的长度比认证标签的长度短。为了在使用RCCm1或RCCm2时在所有数据包上实现相同（或更小）的MAC伪造成功概率，与RFC 3711中的默认完整性转换一样，标签长度必须设置为14个八位字节，这意味着MAC_tr的长度为10个八位字节。
It is recommended to set the tag-length to 14 octets when RCCm1 or RCCm2 is used, and the tag-length MUST be set to four octets when RCCm3 is used.
当使用RCCm1或RCCm2时，建议将标签长度设置为14个八位字节，当使用RCCm3时，标签长度必须设置为4个八位字节。
According to Section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the SRTP auth alg namespace and the SRTP Type namespace.
根据RFC 3830第10节，IETF共识要求在SRTP auth alg命名空间和SRTP类型命名空间中注册0-240范围内的值。
The value 2 for RCCm1, the value 3 for RCCm2, and the value 4 for RCCm3 have been registered in the SRTP auth alg namespace as specified in Table 1 in Section 4.
RCCm1的值2、RCCm2的值3和RCCm3的值4已在SRTP auth alg命名空间中注册，如第4节表1所示。
The value 13 for ROC transmission rate has been registered in the SRTP Type namespace as specified in Table 2 in Section 4.
ROC传输速率的值13已在第4节表2中规定的SRTP类型名称空间中注册。
The values 14 to 19 have been registered in the SRTP Type namespace according to Table 3 in Section 4.
根据第4节中的表3，已在SRTP类型名称空间中注册了值14至19。
We would like to thank Nigel Dallard, Lakshminath Dondeti, and David McGrew for fruitful comments and discussions.
我们要感谢奈杰尔·达拉德、拉克希米纳·唐德蒂和大卫·麦克格鲁的富有成效的评论和讨论。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[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月。
[MBMS] 3GPP TS 33.246, "3G Security; Security of Multimedia Broadcast/ Multicast Service (MBMS)", October 2006.
[MBMS]3GPP TS 33.246，“3G安全；多媒体广播/多播服务（MBMS）的安全”，2006年10月。
[BCMCS] 3GPP2 X.S0022-0, "Broadcast and Multicast Service in cdma2000 Wireless IP Network", February 2005.
[BCMCS]3GPP2 X.S0022-0，“cdma2000无线IP网络中的广播和多播服务”，2005年2月。
Authors' Addresses
作者地址
Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland
Vesa Lehtovirta Ericsson Research 02420 Jorvas芬兰
Phone: +358 9 2993314
EMail: vesa.lehtovirta@ericsson.com
Phone: +358 9 2993314
EMail: vesa.lehtovirta@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
Mats Naslund Ericsson Research SE-16480瑞典斯德哥尔摩
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.com
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
卡尔·诺尔曼·爱立信研究所SE-16480瑞典斯德哥尔摩
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。