Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 5925 USC/ISI
Obsoletes: 2385 A. Mankin
Category: Standards Track Johns Hopkins Univ.
ISSN: 2070-1721 R. Bonica
Juniper Networks
June 2010
Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 5925 USC/ISI
Obsoletes: 2385 A. Mankin
Category: Standards Track Johns Hopkins Univ.
ISSN: 2070-1721 R. Bonica
Juniper Networks
June 2010
The TCP Authentication Option
TCP身份验证选项
Abstract
摘要
This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.
本文件规定了TCP认证选项（TCP-AO），该选项废除了RFC 2385（TCP MD5）的TCP MD5签名选项。TCP-AO指定使用更强的消息身份验证码（MAC），即使对于长寿命的TCP连接也可以防止重播，并提供了比TCP MD5更详细的关于安全性与TCP连接关联的信息。TCP-AO与静态主密钥元组（MKT）配置或外部带外MKT管理机制兼容；在这两种情况下，TCP-AO还可以在连接的重复实例中使用相同的MKT时保护连接，使用从MKT派生的通信密钥，并协调端点之间的MKT更改。其结果旨在支持TCP MD5的当前基础设施使用，例如保护长寿命连接（如在BGP和LDP中使用的），并在其他系统和操作更改最少的情况下支持更大的MAC集。TCP-AO使用与TCP MD5不同的选项标识符，即使TCP-AO和TCP MD5永远不允许同时使用。TCP-AO支持IPv6，并且完全符合替换TCP MD5的建议要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5925.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5925.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Applicability Statement ....................................5
1.3. Executive Summary ..........................................6
2. The TCP Authentication Option ...................................7
2.1. Review of TCP MD5 Option ...................................7
2.2. The TCP Authentication Option Format .......................8
3. TCP-AO Keys and Their Properties ...............................10
3.1. Master Key Tuple ..........................................10
3.2. Traffic Keys ..............................................12
3.3. MKT Properties ............................................13
4. Per-Connection TCP-AO Parameters ...............................14
5. Cryptographic Algorithms .......................................15
5.1. MAC Algorithms ............................................15
5.2. Traffic Key Derivation Functions ..........................18
5.3. Traffic Key Establishment and Duration Issues .............22
5.3.1. MKT Reuse Across Socket Pairs ......................22
5.3.2. MKTs Use within a Long-Lived Connection ............23
6. Additional Security Mechanisms .................................23
6.1. Coordinating Use of New MKTs ..............................23
6.2. Preventing Replay Attacks within Long-Lived Connections ...24
7. TCP-AO Interaction with TCP ....................................26
7.1. TCP User Interface ........................................27
7.2. TCP States and Transitions ................................28
7.3. TCP Segments ..............................................28
7.4. Sending TCP Segments ......................................29
7.5. Receiving TCP Segments ....................................30
7.6. Impact on TCP Header Size .................................32
7.7. Connectionless Resets .....................................33
7.8. ICMP Handling .............................................34
8. Obsoleting TCP MD5 and Legacy Interactions .....................35
9. Interactions with Middleboxes ..................................35
9.1. Interactions with Non-NAT/NAPT Middleboxes ................36
9.2. Interactions with NAT/NAPT Devices ........................36
10. Evaluation of Requirements Satisfaction .......................36
11. Security Considerations .......................................42
12. IANA Considerations ...........................................43
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................45
14. Acknowledgments ...............................................47
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Applicability Statement ....................................5
1.3. Executive Summary ..........................................6
2. The TCP Authentication Option ...................................7
2.1. Review of TCP MD5 Option ...................................7
2.2. The TCP Authentication Option Format .......................8
3. TCP-AO Keys and Their Properties ...............................10
3.1. Master Key Tuple ..........................................10
3.2. Traffic Keys ..............................................12
3.3. MKT Properties ............................................13
4. Per-Connection TCP-AO Parameters ...............................14
5. Cryptographic Algorithms .......................................15
5.1. MAC Algorithms ............................................15
5.2. Traffic Key Derivation Functions ..........................18
5.3. Traffic Key Establishment and Duration Issues .............22
5.3.1. MKT Reuse Across Socket Pairs ......................22
5.3.2. MKTs Use within a Long-Lived Connection ............23
6. Additional Security Mechanisms .................................23
6.1. Coordinating Use of New MKTs ..............................23
6.2. Preventing Replay Attacks within Long-Lived Connections ...24
7. TCP-AO Interaction with TCP ....................................26
7.1. TCP User Interface ........................................27
7.2. TCP States and Transitions ................................28
7.3. TCP Segments ..............................................28
7.4. Sending TCP Segments ......................................29
7.5. Receiving TCP Segments ....................................30
7.6. Impact on TCP Header Size .................................32
7.7. Connectionless Resets .....................................33
7.8. ICMP Handling .............................................34
8. Obsoleting TCP MD5 and Legacy Interactions .....................35
9. Interactions with Middleboxes ..................................35
9.1. Interactions with Non-NAT/NAPT Middleboxes ................36
9.2. Interactions with NAT/NAPT Devices ........................36
10. Evaluation of Requirements Satisfaction .......................36
11. Security Considerations .......................................42
12. IANA Considerations ...........................................43
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................45
14. Acknowledgments ...............................................47
The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates TCP segments, including the TCP IPv4 pseudoheader, TCP header, and TCP data. It was developed to protect BGP sessions from spoofed TCP segments, which could affect BGP data or the robustness of the TCP connection itself [RFC2385][RFC4953].
TCP MD5签名（TCP MD5）是一个TCP选项，用于验证TCP段，包括TCP IPv4伪头、TCP头和TCP数据。开发它是为了保护BGP会话不受伪造TCP段的影响，这可能会影响BGP数据或TCP连接本身的健壮性[RFC2385][RFC4953]。
There have been many recent concerns about TCP MD5. Its use of a simple keyed hash for authentication is problematic because there have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 also lacks both key-management and algorithm agility. This document adds the latter, and provides a simple key coordination mechanism giving the ability to move from one key to another within the same connection. It does not however provide for complete cryptographic key management to be handled in band of TCP, because TCP SYN segments lack sufficient remaining space to handle such a negotiation (see Section 7.6). This document obsoletes the TCP MD5 option with a more general TCP Authentication Option (TCP-AO). This new option supports the use of other, stronger hash functions, provides replay protection for long-lived connections and across repeated instances of a single connection, coordinates key changes between endpoints, and provides a more explicit recommendation for external key management. The result is compatible with IPv6, and is fully compatible with proposed requirements for a replacement for TCP MD5 [Ed07].
最近有很多关于TCP MD5的问题。它使用简单的密钥散列进行身份验证是有问题的，因为对算法本身的攻击不断升级[Wa05]。TCP MD5还缺乏密钥管理和算法灵活性。本文档添加了后者，并提供了一个简单的密钥协调机制，允许在同一连接中从一个密钥移动到另一个密钥。但是，由于TCP SYN段缺少足够的剩余空间来处理此类协商，因此它没有提供在TCP频带内处理的完整加密密钥管理（参见第7.6节）。本文档使用更通用的TCP身份验证选项（TCP-AO）淘汰了TCP MD5选项。此新选项支持使用其他更强大的哈希函数，为长期存在的连接和单个连接的重复实例提供重播保护，协调端点之间的密钥更改，并为外部密钥管理提供更明确的建议。其结果与IPv6兼容，并且完全符合替换TCP MD5的建议要求[Ed07]。
TCP-AO obsoletes TCP MD5, although a particular implementation may support both mechanisms for backward compatibility. For a given connection, only one can be in use. TCP MD5-protected connections cannot be migrated to TCP-AO because TCP MD5 does not support any changes to a connection's security algorithm once established.
TCP-AO淘汰了TCP MD5，尽管特定实现可能支持这两种机制以实现向后兼容性。对于给定的连接，只能使用一个。TCP MD5保护的连接无法迁移到TCP-AO，因为TCP MD5不支持在建立连接后对连接的安全算法进行任何更改。
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]中所述进行解释。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying RFC 2119 significance.
在本文件中，只有在所有大写字母中，这些单词才会以该解释出现。这些词语的小写用法不得解释为具有RFC 2119的意义。
In this document, the characters ">>" preceeding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC.
在本文档中，缩进行前面的字符“>>”表示使用上述关键字的合规性要求声明。本公约有助于审查人员快速确定或找到本RFC的明确合规要求。
TCP-AO is intended to support current uses of TCP MD5, such as to protect long-lived connections for routing protocols, such as BGP and LDP. It is also intended to provide similar protection to any long-lived TCP connection, as might be used between proxy caches, for example, and is not designed solely or primarily for routing protocol uses.
TCP-AO旨在支持TCP MD5的当前使用，例如保护路由协议（如BGP和LDP）的长寿命连接。它还旨在为任何长寿命TCP连接提供类似的保护，例如，可能在代理缓存之间使用，而不是专门或主要为路由协议使用而设计。
TCP-AO is intended to replace (and thus obsolete) the use of TCP MD5. TCP-AO enhances the capabilities of TCP MD5 as summarized in Section 1.3. This document recommends overall that:
TCP-AO旨在取代（并因此淘汰）TCP MD5的使用。TCP-AO增强了TCP MD5的功能，如第1.3节所述。本文件总体建议：
>> TCP implementations that support TCP MD5 MUST support TCP-AO.
>>支持TCP MD5的TCP实现必须支持TCP-AO。
>> TCP-AO SHOULD be implemented where the protection afforded by TCP authentication is needed, because either IPsec is not supported or TCP-AO's particular properties are needed (e.g., per-connection keys).
>>由于不支持IPsec或需要TCP-AO的特定属性（例如，每个连接密钥），在需要TCP身份验证提供保护的情况下，应实施TCP-AO。
>> TCP-AO MAY be implemented elsewhere.
>>TCP-AO可以在其他地方实现。
TCP-AO is not intended to replace the use of the IPsec suite (IPsec and Internet Key Exchange Protocol (IKE)) to protect TCP connections [RFC4301][RFC4306]. Specific differences are noted in Section 1.3. In fact, we recommend the use of IPsec and IKE, especially where IKE's level of existing support for parameter negotiation, session key negotiation, or rekeying are desired. TCP-AO is intended for use only where the IPsec suite would not be feasible, e.g., as has been suggested is the case to support some routing protocols [RFC4953], or in cases where keys need to be tightly coordinated with individual transport sessions [Ed07].
TCP-AO并不打算取代IPsec套件（IPsec和Internet密钥交换协议（IKE））的使用来保护TCP连接[RFC4301][RFC4306]。具体差异见第1.3节。事实上，我们建议使用IPsec和IKE，特别是在需要IKE对参数协商、会话密钥协商或密钥更新的现有支持级别的情况下。TCP-AO仅适用于IPsec套件不可行的情况，如支持某些路由协议[RFC4953]的情况，或密钥需要与单个传输会话紧密协调的情况[Ed07]。
TCP-AO is not intended to replace the use of Transport Layer Security (TLS) [RFC5246], Secure BGP (sBGP) or Secure Origin BGP (soBGP) [Le09], or any other mechanisms that protect only the TCP data stream. TCP-AO protects the transport layer, preventing attacks from disabling the TCP connection itself [RFC4953]. Data stream mechanisms protect only the contents of the TCP segments, and can be disrupted when the connection is affected. Some of these data protection protocols -- notably TLS -- offer a richer set of key management and authentication mechanisms than TCP-AO, and thus protect the data stream in a different way. TCP-AO may be used together with these data stream protections to complement each other's strengths.
TCP-AO不打算取代传输层安全（TLS）[RFC5246]、安全BGP（sBGP）或安全源BGP（soBGP）[Le09]或仅保护TCP数据流的任何其他机制。TCP-AO保护传输层，防止攻击禁用TCP连接本身[RFC4953]。数据流机制仅保护TCP段的内容，并且在连接受到影响时可能会中断。其中一些数据保护协议（尤其是TLS）提供了比TCP-AO更丰富的密钥管理和身份验证机制，从而以不同的方式保护数据流。TCP-AO可与这些数据流保护一起使用，以互补彼此的优势。
This document replaces TCP MD5 as follows [RFC2385]:
本文档取代TCP MD5的内容如下[RFC2385]：
o TCP-AO uses a separate option Kind (29).
o TCP-AO使用单独的选项类型（29）。
o TCP-AO allows TCP MD5 to continue to be used concurrently for legacy connections.
o TCP-AO允许TCP MD5继续同时用于传统连接。
o TCP-AO replaces TCP MD5's single MAC algorithm with MACs specified in a separate document and can be extended to include other MACs.
o TCP-AO将TCP MD5的单一MAC算法替换为单独文档中指定的MAC，并可扩展为包括其他MAC。
o TCP-AO allows rekeying during a TCP connection, assuming that an out-of-band protocol or manual mechanism provides the new keys. The option includes a 'key ID', which allows the efficient concurrent use of multiple keys, and a key coordination mechanism using a 'receive next key ID' manages the key change within a connection. Note that TCP MD5 does not preclude rekeying during a connection, but does not require its support either. Further, TCP-AO supports key changes with zero segment loss, whereas key changes in TCP MD5 can lose segments in transit during the changeover or require trying multiple keys on each received segment during key use overlap because it lacks an explicit key ID. Although TCP recovers lost segments through retransmission, loss can have a substantial impact on performance.
o TCP-AO允许在TCP连接期间重新设置密钥，前提是带外协议或手动机制提供了新密钥。该选项包括一个“密钥ID”，允许有效地同时使用多个密钥，以及一个使用“接收下一个密钥ID”的密钥协调机制，用于管理连接内的密钥更改。请注意，TCP MD5并不排除在连接过程中重新设置密钥，但也不需要它的支持。此外，TCP-AO支持零段丢失的密钥更改，而TCP MD5中的密钥更改可能会在转换过程中丢失段，或者在密钥使用重叠期间需要在每个接收段上尝试多个密钥，因为它缺少明确的密钥ID。尽管TCP通过重传恢复丢失的段，损失可能会对性能产生重大影响。
o TCP-AO provides automatic replay protection for long-lived connections using sequence number extensions.
o TCP-AO使用序列号扩展为长期存在的连接提供自动重播保护。
o TCP-AO ensures per-connection traffic keys as unique as the TCP connection itself, using TCP's Initial Sequence Numbers (ISNs) for differentiation, even when static master key tuples are used across repeated instances of connections on a single socket pair.
o TCP-AO使用TCP的初始序列号（ISN）进行区分，确保每个连接的通信密钥与TCP连接本身一样唯一，即使在单个套接字对上的重复连接实例中使用静态主密钥元组也是如此。
o TCP-AO specifies the details of how this option interacts with TCP's states, event processing, and user interface.
o TCP-AO指定此选项如何与TCP的状态、事件处理和用户界面交互的详细信息。
o TCP-AO is 2 bytes shorter than TCP MD5 (16 bytes overall, rather than 18) in the initially specified default case (using a 96-bit MAC).
o 在最初指定的默认情况下（使用96位MAC），TCP-AO比TCP MD5短2个字节（总共16个字节，而不是18个字节）。
TCP-AO differs from an IPsec/IKE solution as follows [RFC4301][RFC4306]:
TCP-AO与IPsec/IKE解决方案的区别如下[RFC4301][RFC4306]：
o TCP-AO does not support dynamic parameter negotiation.
o TCP-AO不支持动态参数协商。
o TCP-AO includes TCP's socket pair (source address, destination address, source port, destination port) as a security parameter index (together with the KeyID), rather than using a separate field as an index (IPsec's Security Parameter Index (SPI)).
o TCP-AO包括TCP的套接字对（源地址、目标地址、源端口、目标端口）作为安全参数索引（连同密钥ID），而不是使用单独的字段作为索引（IPsec的安全参数索引（SPI））。
o TCP-AO forces a change of computed MACs when a connection restarts, even when reusing a TCP socket pair (IP addresses and port numbers) [Ed07].
o 当连接重新启动时，TCP-AO强制更改计算的MAC，即使重新使用TCP套接字对（IP地址和端口号）[Ed07]。
o TCP-AO does not support encryption.
o TCP-AO不支持加密。
o TCP-AO does not authenticate ICMP messages (some ICMP messages may be authenticated when using IPsec, depending on the configuration).
o TCP-AO不会对ICMP消息进行身份验证（某些ICMP消息在使用IPsec时可能会进行身份验证，具体取决于配置）。
The TCP Authentication Option (TCP-AO) uses a TCP option Kind value of 29. The following sections describe TCP-AO and provide a review of TCP MD5 for comparison.
TCP身份验证选项（TCP-AO）使用TCP选项种类值29。以下各节介绍TCP-AO，并回顾TCP MD5以进行比较。
For review, the TCP MD5 option is shown in Figure 1.
为了便于查看，TCP MD5选项如图1所示。
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| ...digest (con't)... |
+---------------------------------------+
| ... |
+---------------------------------------+
| ... |
+-------------------+-------------------+
| ...digest (con't) |
+-------------------+
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| ...digest (con't)... |
+---------------------------------------+
| ... |
+---------------------------------------+
| ... |
+-------------------+-------------------+
| ...digest (con't) |
+-------------------+
Figure 1: The TCP MD5 Option [RFC2385]
图1:TCP MD5选项[RFC2385]
In the TCP MD5 option, the length is fixed, and the MD5 digest occupies 16 bytes following the Kind and Length fields (each one byte), using the full MD5 digest of 128 bits [RFC1321].
在TCP MD5选项中，长度是固定的，MD5摘要使用128位的完整MD5摘要[RFC1321]，在种类和长度字段之后占用16个字节（每个字节）。
The TCP MD5 option specifies the use of the MD5 digest calculation over the following values in the following order:
TCP MD5选项指定按以下顺序对以下值使用MD5摘要计算：
1. The IP pseudoheader (IP source and destination addresses, protocol number, and segment length).
1. IP伪报头（IP源和目标地址、协议号和段长度）。
2. The TCP header excluding options and checksum.
2. TCP标头不包括选项和校验和。
3. The TCP data payload.
3. TCP数据有效负载。
4. A key.
4. 钥匙。
TCP-AO provides a superset of the capabilities of TCP MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field, and similar Length field to TCP MD5, a KeyID field, and a RNextKeyID field as shown in Figure 2.
TCP-AO提供了TCP MD5功能的超集，在SP4的精神下是最小的[SDNS88]。TCP-AO使用一个新的种类字段和与TCP MD5类似的长度字段、一个KeyID字段和一个RNextKeyID字段，如图2所示。
+------------+------------+------------+------------+
| Kind=29 | Length | KeyID | RNextKeyID |
+------------+------------+------------+------------+
| MAC ...
+-----------------------------------...
+------------+------------+------------+------------+
| Kind=29 | Length | KeyID | RNextKeyID |
+------------+------------+------------+------------+
| MAC ...
+-----------------------------------...
...-----------------+
... MAC (con't) |
...-----------------+
...-----------------+
... MAC (con't) |
...-----------------+
Figure 2: The TCP Authentication Option (TCP-AO)
图2:TCP身份验证选项（TCP-AO）
TCP-AO defines these fields as follows:
TCP-AO将这些字段定义如下：
o Kind: An unsigned 1-byte field indicating TCP-AO. TCP-AO uses a new Kind value of 29.
o 种类：表示TCP-AO的无符号1字节字段。TCP-AO使用新的种类值29。
>> An endpoint MUST NOT use TCP-AO for the same connection in which TCP MD5 is used. When both options appear, TCP MUST silently discard the segment.
>>端点不得对使用TCP MD5的同一连接使用TCP-AO。当两个选项都出现时，TCP必须以静默方式放弃该段。
>> A single TCP segment MUST NOT have more than one TCP-AO in its options sequence. When multiple TCP-AOs appear, TCP MUST discard the segment.
>>单个TCP段的选项序列中不得有多个TCP-AO。当出现多个TCP AO时，TCP必须放弃该段。
o Length: An unsigned 1-byte field indicating the length of the option in bytes, including the Kind, Length, KeyID, RNextKeyID, and MAC fields.
o 长度：一个无符号的1字节字段，以字节表示选项的长度，包括种类、长度、KeyID、RNextKeyID和MAC字段。
>> The Length value MUST be greater than or equal to 4. When the Length value is less than 4, TCP MUST discard the segment.
>>长度值必须大于或等于4。当长度值小于4时，TCP必须放弃该段。
>> The Length value MUST be consistent with the TCP header length. When the Length value is invalid, TCP MUST discard the segment.
>>长度值必须与TCP标头长度一致。当长度值无效时，TCP必须放弃该段。
This Length check implies that the sum of the sizes of all options, when added to the size of the base TCP header (5 words), matches the TCP Offset field exactly. This full verification can be computed because RFC 793 specifies the size of the required options, and RFC 1122 requires that all new options follow a common format with a fixed-length field location [RFC793][RFC1122]. A partial verification can be limited to check only TCP-AO, so that the TCP-AO length, when added to the TCP-AO offset from the start of the TCP header, does not exceed the TCP header size as indicated in the TCP header Offset field.
此长度检查意味着，当添加到基本TCP标头（5个字）的大小时，所有选项的大小之和与TCP偏移量字段完全匹配。可以计算此完全验证，因为RFC 793指定了所需选项的大小，而RFC 1122要求所有新选项遵循具有固定长度字段位置[RFC793][RFC1122]的通用格式。可以将部分验证限制为仅检查TCP-AO，以便将TCP-AO长度添加到从TCP标头开始的TCP-AO偏移量时，不会超过TCP标头偏移量字段中指示的TCP标头大小。
Values of 4 and other small values larger than 4 (e.g., indicating MAC fields of very short length) are of dubious utility but are not specifically prohibited.
4的值和其他大于4的小值（例如，表示长度非常短的MAC字段）具有可疑的实用性，但没有明确禁止。
o KeyID: An unsigned 1-byte field indicating the Master Key Tuple (MKT, as defined in Section 3.1) used to generate the traffic keys that were used to generate the MAC that authenticates this segment.
o KeyID：一个无符号的1字节字段，指示用于生成用于生成验证该段的MAC的流量密钥的主密钥元组（MKT，如第3.1节所定义）。
It supports efficient key changes during a connection and/or to help with key coordination during connection establishment, to be discussed further in Section 6.1. Note that the KeyID has no cryptographic properties -- it need not be random, nor are there any reserved values.
它支持连接过程中的有效关键更改和/或帮助连接建立过程中的关键协调，将在第6.1节中进一步讨论。请注意，KeyID没有加密属性——它不需要是随机的，也没有任何保留值。
>> KeyID values MAY be the same in both directions of a connection, but do not have to be and there is no special meaning when they are.
>>KeyID值在连接的两个方向上可能相同，但不一定必须相同，并且在相同的情况下没有特殊意义。
This allows MKTs to be installed on a set of devices without coordinating the KeyIDs across that entire set in advance, and allows new devices to be added to that set using a group of MKTs later without requiring renumbering of KeyIDs. These two capabilities are particularly important when used with wildcards in the TCP socket pair of the MKT, i.e., when an MKT is used among a set of devices specified by a pattern (as noted in Section 3.1).
这允许在一组设备上安装MKT，而无需事先协调整个设备上的KEYID，并允许在以后使用一组MKT将新设备添加到该设备上，而无需重新编号KEYID。当与MKT的TCP套接字对中的通配符一起使用时，这两种功能尤其重要，即当在模式指定的一组设备中使用MKT时（如第3.1节所述）。
o RNextKeyID: An unsigned 1-byte field indicating the MKT that is ready at the sender to be used to authenticate received segments, i.e., the desired 'receive next' key ID.
o RNextKeyID：一个无符号的1字节字段，指示发送方准备好用于验证接收段的MKT，即所需的“接收下一个”密钥ID。
It supports efficient key change coordination, to be discussed further in Section 6.1. Note that the RNextKeyID has no cryptographic properties -- it need not be random, nor are there any reserved values.
它支持有效的关键变更协调，将在第6.1节中进一步讨论。请注意，RNextKeyID没有加密属性——它不需要是随机的，也没有任何保留值。
o MAC: Message Authentication Code. Its contents are determined by the particulars of the security association. Typical MACs are 96-128 bits (12-16 bytes), but any length that fits in the header of the segment being authenticated is allowed. The MAC computation is described further in Section 5.1.
o MAC：消息身份验证代码。其内容由证券协会的具体情况决定。典型的MAC是96-128位（12-16字节），但允许任何适合正在验证的段头的长度。第5.1节将进一步描述MAC计算。
>> Required support for TCP-AO MACs is defined in [RFC5926]; other MACs MAY be supported.
>>[RFC5926]中定义了TCP-AO MAC所需的支持；可能支持其他Mac。
TCP-AO fields do not indicate the MAC algorithm either implicitly (as with TCP MD5) or explicitly. The particular algorithm used is considered part of the configuration state of the connection's security and is managed separately (see Section 3).
TCP-AO字段不隐式（与TCP MD5一样）或显式指示MAC算法。所使用的特定算法被视为连接安全性配置状态的一部分，并单独管理（参见第3节）。
Please note that the use of TCP-AO does not affect TCP's advertised Maximum Segment Size (MSS), as is the case for all TCP options [Bo09].
请注意，使用TCP-AO不会影响TCP公布的最大段大小（MSS），所有TCP选项都是如此[Bo09]。
The remainder of this document explains how TCP-AO is handled and its relationship to TCP.
本文档的其余部分将解释如何处理TCP-AO及其与TCP的关系。
TCP-AO relies on two sets of keys to authenticate incoming and outgoing segments: Master Key Tuples (MKTs) and traffic keys. MKTs are used to derive unique traffic keys, and include the keying material used to generate those traffic keys, as well as indicating the associated parameters under which traffic keys are used. Such parameters include whether TCP options are authenticated, and indicators of the algorithms used for traffic key derivation and MAC calculation. Traffic keys are the keying material used to compute the MAC of individual TCP segments.
TCP-AO依赖两组密钥对传入和传出段进行身份验证：主密钥元组（MKT）和流量密钥。MKT用于导出唯一的流量密钥，并包括用于生成这些流量密钥的密钥材料，以及指示使用流量密钥的相关参数。这些参数包括TCP选项是否经过身份验证，以及用于流量密钥推导和MAC计算的算法指标。流量密钥是用于计算各个TCP段的MAC的密钥材料。
A Master Key Tuple (MKT) describes TCP-AO properties to be associated with one or more connections. It is composed of the following:
主密钥元组（MKT）描述与一个或多个连接关联的TCP-AO属性。它由以下部分组成：
o TCP connection identifier. A TCP socket pair, i.e., a local IP address, a remote IP address, a TCP local port, and a TCP remote port. Values can be partially specified using ranges (e.g., 2-30), masks (e.g., 0xF0), wildcards (e.g., "*"), or any other suitable indication.
o TCP连接标识符。TCP套接字对，即本地IP地址、远程IP地址、TCP本地端口和TCP远程端口。可以使用范围（例如2-30）、掩码（例如0xF0）、通配符（例如“*”）或任何其他合适的指示部分指定值。
o TCP option flag. This flag indicates whether TCP options other than TCP-AO are included in the MAC calculation. When options are included, the content of all options, in the order present, is included in the MAC, with TCP-AO's MAC field zeroed out. When the
o TCP选项标志。此标志指示MAC计算中是否包括TCP-AO以外的TCP选项。当包含选项时，所有选项的内容按当前顺序包含在MAC中，TCP-AO的MAC字段归零。当
options are not included, all options other than TCP-AO are excluded from all MAC calculations (skipped over, not zeroed). Note that TCP-AO, with its MAC field zeroed out, is always included in the MAC calculation, regardless of the setting of this flag; this protects the indication of the MAC length as well as the key ID fields (KeyID, RNextKeyID). The option flag applies to TCP options in both directions (incoming and outgoing segments).
选项不包括在内，除TCP-AO之外的所有选项都从所有MAC计算中排除（跳过，不归零）。请注意，无论此标志的设置如何，MAC字段为零的TCP-AO始终包含在MAC计算中；这可以保护MAC长度的指示以及密钥ID字段（KeyID、RNextKeyID）。选项标志应用于两个方向（传入和传出段）的TCP选项。
o IDs. The values used in the KeyID or RNextKeyID of TCP-AO; used to differentiate MKTs in concurrent use (KeyID), as well as to indicate when MKTs are ready for use in the opposite direction (RNextKeyID).
o 身份证。TCP-AO的KeyID或RNextKeyID中使用的值；用于区分并发使用中的MKT（KeyID），以及指示MKT何时准备在相反方向上使用（RNextKeyID）。
Each MKT has two IDs - -- a SendID and a RecvID. The SendID is inserted as the KeyID of the TCP-AO option of outgoing segments, and the RecvID is matched against the TCP-AO KeyID of incoming segments. These and other uses of these two IDs are described further in Sections 7.4 and 7.5.
每个MKT有两个ID---一个SendID和一个RecvID。SendID作为传出段的TCP-AO选项的KeyID插入，RecvID与传入段的TCP-AO KeyID匹配。第7.4节和第7.5节进一步描述了这两个ID的这些用途和其他用途。
>> MKT IDs MUST support any value, 0-255 inclusive. There are no reserved ID values.
>>MKT ID必须支持任何值，包括0-255。没有保留的ID值。
ID values are assigned arbitrarily, i.e., the values are not monotonically increasing, have no reserved values, and are otherwise not meaningful. They can be assigned in sequence, or based on any method mutually agreed by the connection endpoints (e.g., using an external MKT management mechanism).
ID值是任意分配的，即，值不是单调递增的，没有保留值，并且在其他方面没有意义。它们可以按顺序分配，也可以基于连接端点相互同意的任何方法分配（例如，使用外部MKT管理机制）。
>> IDs MUST NOT be assumed to be randomly assigned.
>>不得假设ID是随机分配的。
o Master key. A byte sequence used for generating traffic keys, this may be derived from a separate shared key by an external protocol over a separate channel. This sequence is used in the traffic key generation algorithm described in Section 5.2.
o 万能钥匙。一种用于生成通信密钥的字节序列，可由外部协议通过单独的信道从单独的共享密钥中导出。该序列用于第5.2节所述的流量密钥生成算法。
Implementations are advised to keep master key values in a private, protected area of memory or other storage.
建议实现将主密钥值保存在内存或其他存储的私有、受保护区域中。
o Key Derivation Function (KDF). Indicates the key derivation function and its parameters, as used to generate traffic keys from master keys. It is explained further in Section 5.2 of this document and specified in detail in [RFC5926].
o 密钥派生函数（KDF）。指示用于从主密钥生成流量密钥的密钥派生函数及其参数。本文件第5.2节对此作了进一步解释，并在[RFC5926]中作了详细说明。
o Message Authentication Code (MAC) algorithm. Indicates the MAC algorithm and its parameters as used for this connection. It is explained further in Section 5.1 of this document and specified in detail in [RFC5926].
o 消息认证码（MAC）算法。指示用于此连接的MAC算法及其参数。本文件第5.1节对此作了进一步解释，并在[RFC5926]中作了详细说明。
>> Components of an MKT MUST NOT change during a connection.
>>连接期间，MKT的组件不得更改。
MKT component values cannot change during a connection because TCP state is coordinated during connection establishment. TCP lacks a handshake for modifying that state after a connection has been established.
MKT组件值在连接过程中无法更改，因为TCP状态在连接建立过程中得到协调。TCP缺少在建立连接后修改该状态的握手。
>> The set of MKTs MAY change during a connection.
>>在连接过程中，MKT集可能会发生变化。
MKT parameters are not changed. Instead, new MKTs can be installed, and a connection can change which MKT it uses.
MKT参数不会更改。相反，可以安装新的MKT，并且连接可以更改它使用的MKT。
>> The IDs of MKTs MUST NOT overlap where their TCP connection identifiers overlap.
>>MKT的ID不得在其TCP连接标识符重叠的地方重叠。
This document does not address how MKTs are created by users or processes. It is presumed that an MKT affecting a particular connection cannot be destroyed during an active connection -- or, equivalently, that its parameters are copied to an area local to the connection (i.e., instantiated) and so changes would affect only new connections. The MKTs can be managed by a separate application protocol.
本文档不说明用户或流程如何创建MKT。假设在活动连接期间，影响特定连接的MKT不能被破坏——或者，等效地，其参数被复制到连接的本地区域（即实例化），因此更改只会影响新连接。MKTs可以通过单独的应用程序协议进行管理。
A traffic key is a key derived from the MKT and the local and remote IP address pairs and TCP port numbers, and, for established connections, the TCP Initial Sequence Numbers (ISNs) in each direction. Segments exchanged before a connection is established use the same information, substituting zero for unknown values (e.g., ISNs not yet coordinated).
流量密钥是从MKT、本地和远程IP地址对、TCP端口号以及每个方向的TCP初始序列号（ISN）派生的密钥。在建立连接之前交换的段使用相同的信息，用零代替未知值（例如，ISNs尚未协调）。
A single MKT can be used to derive any of four different traffic keys:
单个MKT可用于导出四个不同的流量密钥中的任意一个：
o Send_SYN_traffic_key
o 发送\u同步\u流量\u密钥
o Receive_SYN_traffic_key
o 接收\u同步\u流量\u密钥
o Send_other_traffic_key
o 发送\u其他\u流量\u密钥
o Receive_other_traffic_key
o 接收\u其他\u流量\u密钥
Note that the keys are unidirectional. A given connection typically uses only three of these keys, because only one of the SYN keys is typically used. All four are used only when a connection goes through 'simultaneous open' [RFC793].
请注意，这些键是单向的。给定的连接通常只使用这些键中的三个，因为通常只使用一个SYN键。只有当连接通过“同时打开”[RFC793]时，才使用这四个选项。
The relationship between MKTs and traffic keys is shown in Figure 3. Traffic keys are indicated with a "*". Note that every MKT can be used to derive any of the four traffic keys, but only the keys actually needed to handle the segments of a connection need to be computed. Section 5.2 provides further details on how traffic keys are derived.
MKTs和流量密钥之间的关系如图3所示。交通钥匙用“*”表示。请注意，每个MKT都可以用于派生四个流量密钥中的任何一个，但只需要计算处理连接段实际需要的密钥。第5.2节提供了有关如何导出交通密钥的更多详细信息。
MKT-A MKT-B
+---------------------+ +------------------------+
| SendID = 1 | | SendID = 5 |
| RecvID = 2 | | RecvID = 6 |
| MAC = HMAC-SHA1 | | MAC = AES-CMAC |
| KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC |
+---------------------+ +------------------------+
| |
+----------+----------+ |
| | |
v v v
Connection 1 Connection 2 Connection 3
+------------------+ +------------------+ +------------------+
| * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key |
| * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key |
| * Send_Other_key | | * Send_Other_key | | * Send_Other_key |
| * Recv_Other_key | | * Recv_Other_key | | * Recv_Other_key |
+------------------+ +------------------+ +------------------+
MKT-A MKT-B
+---------------------+ +------------------------+
| SendID = 1 | | SendID = 5 |
| RecvID = 2 | | RecvID = 6 |
| MAC = HMAC-SHA1 | | MAC = AES-CMAC |
| KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC |
+---------------------+ +------------------------+
| |
+----------+----------+ |
| | |
v v v
Connection 1 Connection 2 Connection 3
+------------------+ +------------------+ +------------------+
| * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key |
| * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key |
| * Send_Other_key | | * Send_Other_key | | * Send_Other_key |
| * Recv_Other_key | | * Recv_Other_key | | * Recv_Other_key |
+------------------+ +------------------+ +------------------+
Figure 3: Relationship between MKTs and Traffic Keys
图3:MKTs和流量密钥之间的关系
TCP-AO requires that every protected TCP segment match exactly one MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no match occurs, TCP-AO is not used. Multiple MKTs may match a single outgoing segment, e.g., when MKTs are being changed. Those MKTs cannot have conflicting IDs (as noted elsewhere), and some mechanism must determine which MKT to use for each given outgoing segment.
TCP-AO要求每个受保护的TCP段恰好匹配一个MKT。当传出段与MKT匹配时，使用TCP-AO。如果不匹配，则不使用TCP-AO。多个MKT可能与单个传出段匹配，例如，当MKT被更改时。这些MKT不能有冲突的ID（如其他地方所述），并且某些机制必须确定每个给定的传出段使用哪个MKT。
>> An outgoing TCP segment MUST match at most one desired MKT, indicated by the segment's socket pair. The segment MAY match multiple MKTs, provided that exactly one MKT is indicated as desired. Other information in the segment MAY be used to determine the desired MKT when multiple MKTs match; such information MUST NOT include values in any TCP option fields.
>>传出TCP段必须最多匹配一个所需的MKT，由段的套接字对指示。该段可匹配多个MKT，前提是根据需要仅指示一个MKT。当多个MKT匹配时，段中的其他信息可用于确定所需MKT；此类信息不得包含任何TCP选项字段中的值。
We recommend that the mechanism used to select from among multiple MKTs use only information that TCP-AO would authenticate. Because MKTs may indicate that options other than TCP-AO are ignored in the MAC calculation, we recommend that TCP options should not be used to determine MKTs.
我们建议用于从多个MKT中进行选择的机制仅使用TCP-AO将进行身份验证的信息。由于MKTs可能表示在MAC计算中忽略TCP-AO以外的选项，因此我们建议不要使用TCP选项来确定MKTs。
>> An incoming TCP segment including TCP-AO MUST match exactly one MKT, indicated solely by the segment's socket pair and its TCP-AO KeyID.
>>包含TCP-AO的传入TCP段必须完全匹配一个MKT，仅由段的套接字对及其TCP-AO密钥ID指示。
Incoming segments include an indicator inside TCP-AO to select from among multiple matching MKTs -- the KeyID field. TCP-AO requires that the KeyID alone be used to differentiate multiple matching MKTs, so that MKT changes can be coordinated using the TCP-AO key change coordination mechanism.
传入段在TCP-AO中包含一个指示符，用于从多个匹配的MKT中进行选择——KeyID字段。TCP-AO要求仅使用KeyID来区分多个匹配的MKT，以便可以使用TCP-AO密钥更改协调机制协调MKT更改。
>> When an outgoing TCP segment matches no MKTs, TCP-AO is not used.
>>当传出TCP段不匹配MKTs时，不使用TCP-AO。
TCP-AO is always used when outgoing segments match an MKT, and is not used otherwise.
TCP-AO总是在传出段与MKT匹配时使用，否则不使用。
TCP-AO uses a small number of parameters associated with each connection that uses TCP-AO, once instantiated. These values can be stored in the Transport Control Block (TCB) [RFC793]. These values are explained in subsequent sections of this document as noted; they include:
一旦实例化，TCP-AO将使用少量与使用TCP-AO的每个连接相关联的参数。这些值可存储在传输控制块（TCB）[RFC793]中。这些值在本文件后续章节中解释，如所述；这些措施包括：
1. Current_key - the MKT currently used to authenticate outgoing segments, whose SendID is inserted in outgoing segments as KeyID (see Section 7.4, step 2.f). Incoming segments are authenticated using the MKT corresponding to the segment and its TCP-AO KeyID (see Section 7.5, step 2.c), as matched against the MKT TCP connection identifier and the MKT RecvID. There is only one current_key at any given time on a particular connection.
1. Current_key—当前用于验证传出段的MKT，其SendID作为KeyID插入传出段（参见第7.4节，步骤2.f）。使用对应于段及其TCP-AO密钥ID（参见第7.5节，步骤2.c）的MKT对传入段进行身份验证，并与MKT TCP连接标识符和MKT RecvID进行匹配。特定连接在任何给定时间只有一个当前_键。
>> Every TCP connection in a non-IDLE state MUST have at most one current_key specified.
>>处于非空闲状态的每个TCP连接必须最多指定一个当前\u密钥。
2. Rnext_key - the MKT currently preferred for incoming (received) segments, whose RecvID is inserted in outgoing segments as RNextKeyID (see Section 7.4, step 2.d).
2. Rnext_键-当前首选用于传入（接收）段的MKT，其RecvID作为RNextKeyID插入传出段（见第7.4节，步骤2.d）。
>> Each TCP connection in a non-IDLE state MUST have at most one rnext_key specified.
>>处于非空闲状态的每个TCP连接最多必须指定一个rnext_密钥。
3. A pair of Sequence Number Extensions (SNEs). SNEs are used to prevent replay attacks, as described in Section 6.2. Each SNE is initialized to zero upon connection establishment. Its use in the MAC calculation is described in Section 5.1.
3. 一对序列号扩展（SNE）。SNE用于防止重播攻击，如第6.2节所述。每个SNE在建立连接时初始化为零。第5.1节描述了其在MAC计算中的使用。
4. One or more MKTs. These are the MKTs that match this connection's socket pair.
4. 一个或多个MKT。这些是与此连接的套接字对匹配的mkt。
MKTs are used, together with other parameters of a connection, to create traffic keys unique to each connection, as described in Section 5.2. These traffic keys can be cached after computation, and can be stored in the TCB with the corresponding MKT information. They can be considered part of the per-connection parameters.
如第5.2节所述，MKT与连接的其他参数一起用于创建每个连接独有的通信密钥。这些流量密钥可在计算后缓存，并可与相应的MKT信息一起存储在TCB中。它们可以被视为每个连接参数的一部分。
TCP-AO uses cryptographic algorithms to compute the MAC (Message Authentication Code) that is used to authenticate a segment and its headers; these are called MAC algorithms and are specified in a separate document to facilitate updating the algorithm requirements independently from the protocol [RFC5926]. TCP-AO also uses cryptographic algorithms to convert MKTs, which can be shared across connections, into unique traffic keys for each connection. These are called Key Derivation Functions (KDFs) and are specified [RFC5926]. This section describes how these algorithms are used by TCP-AO.
TCP-AO使用加密算法来计算MAC（消息认证码），该MAC用于对段及其头进行认证；这些被称为MAC算法，并在单独的文件中指定，以便于独立于协议更新算法要求[RFC5926]。TCP-AO还使用加密算法将可跨连接共享的MKT转换为每个连接的唯一通信密钥。这些函数称为密钥派生函数（KDF），并在[RFC5926]中指定。本节介绍TCP-AO如何使用这些算法。
MAC algorithms take a variable-length input and a key and output a fixed-length number. This number is used to determine whether the input comes from a source with that same key, and whether the input has been tampered with in transit. MACs for TCP-AO have the following interface:
MAC算法采用可变长度输入和密钥，并输出固定长度的数字。此数字用于确定输入是否来自具有相同密钥的源，以及输入是否在传输过程中被篡改。TCP-AO的MAC具有以下接口：
MAC = MAC_alg(traffic_key, message)
MAC=MAC\u alg（流量密钥、消息）
INPUT: MAC_alg, traffic_key, message
输入：MAC\u alg、流量密钥、消息
OUTPUT: MAC
输出：MAC
where:
哪里：
o MAC_alg - the specific MAC algorithm used for this computation. The MAC algorithm specifies the output length, so no separate output length parameter is required. This is specified as described in [RFC5926].
o MAC_alg-用于此计算的特定MAC算法。MAC算法指定输出长度，因此不需要单独的输出长度参数。这是按照[RFC5926]中所述进行规定的。
o Traffic_key - traffic key used for this computation. This is computed from the connection's current MKT as described in Section 5.2.
o Traffic_key—用于此计算的流量密钥。这是根据第5.2节所述连接的当前MKT计算得出的。
o Message - input data over which the MAC is computed. In TCP-AO, this is the TCP segment prepended by the IP pseudoheader and TCP header options, as described in Section 5.1.
o 消息-计算MAC的输入数据。在TCP-AO中，这是由IP伪标头和TCP标头选项预先设置的TCP段，如第5.1节所述。
o MAC - the fixed-length output of the MAC algorithm, given the parameters provided.
o MAC-给定提供的参数，MAC算法的固定长度输出。
At the time of this writing, the algorithms' definitions for use in TCP-AO, as described in [RFC5926], are each truncated to 96 bits. Though the algorithms each output a larger MAC, 96 bits provides a reasonable trade-off between security and message size. However, this could change in the future, so TCP-AO size should not be assumed as fixed length.
在撰写本文时，如[RFC5926]所述，TCP-AO中使用的算法定义均被截断为96位。虽然每个算法都输出一个更大的MAC，但96位在安全性和消息大小之间提供了合理的权衡。但是，这在将来可能会改变，因此TCP-AO大小不应假定为固定长度。
The MAC algorithm employed for the MAC computation on a connection is done so by definition in the MKT, per the definition in [RFC5926].
根据[RFC5926]中的定义，连接上MAC计算采用的MAC算法由MKT中的定义完成。
The mandatory-to-implement MAC algorithms for use with TCP-AO are described in a separate RFC [RFC5926]. This allows the TCP-AO specification to proceed along the IETF Standards Track even if changes are needed to its associated algorithms and their labels (as might be used in a user interface or automated MKT management protocol) as a result of the ever evolving world of cryptography.
在单独的RFC[RFC5926]中描述了实现用于TCP-AO的MAC算法的强制性要求。这使得TCP-AO规范能够沿着IETF标准的轨道前进，即使由于密码学的不断发展，其相关算法及其标签（可能用于用户界面或自动MKT管理协议）需要更改。
>> Additional algorithms, beyond those mandated for TCP-AO, MAY be supported.
>>除了TCP-AO强制使用的算法外，还可能支持其他算法。
The data input to the MAC is in the following fields in the following sequence, interpreted in network-standard byte order:
输入到MAC的数据按以下顺序位于以下字段中，按网络标准字节顺序解释：
1. The Sequence Number Extension (SNE), in network-standard byte order, as follows (described further in Section 6.2):
1. 序列号扩展（SNE），按网络标准字节顺序，如下所示（在第6.2节中进一步描述）：
+--------+--------+--------+--------+
| SNE |
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| SNE |
+--------+--------+--------+--------+
Figure 4: Sequence Number Extension
图4：序列号扩展
The SNE for transmitted segments is maintained locally in the SND.SNE value; for received segments, a local RCV.SNE value is used. The details of how these values are maintained and used are in Sections 6.2, 7.4, and 7.5.
发送段的SNE在SND.SNE值中本地保持；对于接收的段，使用本地RCV.SNE值。第6.2、7.4和7.5节详细介绍了如何维护和使用这些值。
2. The IP pseudoheader: IP source and destination addresses, protocol number, and segment length, all in network byte order, prepended to the TCP header below. The IP pseudoheader is exactly as used for the TCP checksum in either IPv4 or IPv6 [RFC793][RFC2460]:
2. IP伪头：IP源地址和目标地址、协议号和段长度，全部按网络字节顺序，在下面的TCP头前面。IP伪标头与IPv4或IPv6[RFC793][RFC2460]中的TCP校验和完全相同：
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Zero | Proto | TCP Length |
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Zero | Proto | TCP Length |
+--------+--------+--------+--------+
Figure 5: TCP IPv4 Pseudoheader [RFC793]
图5:TCP IPv4伪头[RFC793]
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Upper-Layer Payload Length |
+--------+--------+--------+--------+
| Zero | Next Header |
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Upper-Layer Payload Length |
+--------+--------+--------+--------+
| Zero | Next Header |
+--------+--------+--------+--------+
Figure 6: TCP IPv6 Pseudoheader [RFC2460]
图6:TCP IPv6伪头[RFC2460]
3. The TCP header, by default including options, and where the TCP checksum and TCP-AO MAC fields are set to zero, all in network-byte order.
3. TCP报头，默认情况下包括选项，其中TCP校验和和和TCP-AO MAC字段设置为零，全部按网络字节顺序。
The TCP option flag of the MKT indicates whether the TCP options are included in the MAC. When included, only the TCP-AO MAC field is zeroed.
MKT的TCP选项标志指示MAC中是否包含TCP选项。包括时，只有TCP-AO MAC字段为零。
When TCP options are not included, all TCP options except for TCP-AO are omitted from MAC processing. Again, the TCP-AO MAC field is zeroed for the MAC processing.
如果不包括TCP选项，则MAC处理中会忽略除TCP-AO之外的所有TCP选项。对于MAC处理，TCP-AO MAC字段再次归零。
4. The TCP data, i.e., the payload of the TCP segment.
4. TCP数据，即TCP段的有效负载。
Note that the traffic key is not included as part of the data; the MAC algorithm indicates how to use the traffic key, for example, as HMACs do [RFC2104][RFC2403]. The traffic key is derived from the current MKT as described in Section 5.2.
注意，流量密钥不包括在数据中；MAC算法指示如何使用流量密钥，例如，与HMAC一样[RFC2104][RFC2403]。如第5.2节所述，流量密钥源自当前MKT。
TCP-AO's traffic keys are derived from the MKTs using Key Derivation Functions (KDFs). The KDFs used in TCP-AO have the following interface:
TCP-AO的流量密钥是使用密钥派生函数（KDF）从MKTs派生的。TCP-AO中使用的KDF具有以下接口：
traffic_key = KDF_alg(master_key, context, output_length)
流量密钥=KDF alg（主密钥、上下文、输出长度）
INPUT: KDF_alg, master_key, context, output_length
输入：KDF_alg、主密钥、上下文、输出长度
OUTPUT: traffic_key
输出：流量\ U键
where:
哪里：
o KDF_alg - The specific Key Derivation Function (KDF) that is the basic building block used in constructing the traffic key, as indicated in the MKT. This is specified as described in [RFC5926].
o KDF_alg-特定密钥派生函数（KDF），它是用于构造流量密钥的基本构造块，如MKT中所示。这是按照[RFC5926]中所述进行规定的。
o Master_key - The master_key string, as will be stored into the associated MKT.
o 主密钥-主密钥字符串，将存储在相关的MKT中。
o Context - The context used as input in constructing the traffic_key, as specified in [RFC5926]. The specific way this context is used, in conjunction with other information, to create the raw input to the KDF is also explained further in [RFC5926].
o 上下文-按照[RFC5926]中的规定，在构造流量密钥时用作输入的上下文。[RFC5926]中还进一步解释了该上下文与其他信息一起用于创建KDF原始输入的具体方式。
o Output_length - The desired output length of the KDF, i.e., the length to which the KDF's output will be truncated. This is specified as described in [RFC5926].
o Output_length—KDF的所需输出长度，即KDF输出将被截断的长度。这是按照[RFC5926]中所述进行规定的。
o Traffic_key - The desired output of the KDF, of length output_length, to be used as input to the MAC algorithm, as described in Section 5.1.
o Traffic_key-KDF的期望输出，长度输出_length，用作MAC算法的输入，如第5.1节所述。
The context used as input to the KDF combines the TCP socket pair with the endpoint Initial Sequence Numbers (ISNs) of a connection. This data is unique to each TCP connection instance, which enables TCP-AO to generate unique traffic keys for that connection, even from an MKT used across many different connections or across repeated connections that share a socket pair. Unique traffic keys are generated without relying on external key management properties. The KDF context is defined in Figures 7 and 8.
用作KDF输入的上下文将TCP套接字对与连接的端点初始序列号（ISN）组合在一起。此数据对于每个TCP连接实例都是唯一的，这使TCP-AO能够为该连接生成唯一的通信密钥，即使是从跨多个不同连接使用的MKT或跨共享套接字对的重复连接使用的MKT。在不依赖外部密钥管理属性的情况下生成唯一的通信密钥。图7和图8定义了KDF上下文。
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
Figure 7: KDF Context for an IPv4 Connection
图7:IPv4连接的KDF上下文
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
Figure 8: KDF Context for an IPv6 Connection
图8:IPv6连接的KDF上下文
Traffic keys are directional, so "source" and "destination" are interpreted differently for incoming and outgoing segments. For incoming segments, source is the remote side; whereas for outgoing segments, source is the local side. This further ensures that connection keys generated for each direction are unique.
流量键是定向的，因此对于传入和传出段，“源”和“目的地”的解释不同。对于传入段，源是远程端；而对于传出段，源是本地端。这进一步确保为每个方向生成的连接键是唯一的。
For SYN segments (segments with the SYN set, but the ACK not set), the destination ISN is not known. For these segments, the connection key is computed using the context shown above, in which the destination ISN value is zero. For all other segments, the ISN pair is used when known. If the ISN pair is not known, e.g., when sending a reset (RST) after a reboot, the segment should be sent without authentication; if authentication was required, the segment cannot have been MAC'd properly anyway and would have been dropped on receipt.
对于SYN段（设置了SYN但未设置ACK的段），目标ISN未知。对于这些段，使用上面显示的上下文计算连接键，其中目标ISN值为零。对于所有其他段，已知时使用ISN对。如果不知道ISN对，例如，在重新启动后发送重置（RST）时，应在不进行身份验证的情况下发送该段；如果需要身份验证，那么该段无论如何都无法正确MAC，并且在收到时会被删除。
>> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination ISN of zero (whether sent or received); all other segments use the known ISN pair.
>>TCP-AO SYN段（SYN集，无ACK集）必须使用目标ISN为零（无论发送还是接收）；所有其他段使用已知的ISN对。
Overall, this means that each connection will use up to four distinct traffic keys for each MKT:
总的来说，这意味着每个连接将为每个MKT使用多达四个不同的通信密钥：
o Send_SYN_traffic_key - the traffic key used to authenticate outgoing SYNs. The source ISN is known (the TCP connection's local ISN), and the destination (remote) ISN is unknown (and so the value 0 is used).
o Send_SYN_traffic_key-用于验证传出SYN的流量密钥。源ISN已知（TCP连接的本地ISN），目标（远程）ISN未知（因此使用值0）。
o Receive_SYN_traffic_key - the traffic key used to authenticate incoming SYNs. The source ISN is known (the TCP connection's remote ISN), and the destination (remote) ISN is unknown (and so the value 0 is used).
o Receive_SYN_traffic_key-用于验证传入SYN的流量密钥。源ISN已知（TCP连接的远程ISN），目标（远程）ISN未知（因此使用值0）。
o Send_other_traffic_key - the traffic key used to authenticate all other outgoing TCP segments.
o Send_other_traffic_key-用于验证所有其他传出TCP段的流量密钥。
o Receive_other_traffic_key - the traffic key used to authenticate all other incoming TCP segments.
o Receive_other_traffic_key-用于验证所有其他传入TCP段的流量密钥。
The following table describes how each of these traffic keys is computed, where the TCP-AO algorithms refer to source (S) and destination (D) values of the IP address, TCP port, and ISN, and each segment (incoming or outgoing) has a value that refers to the local side of the connection (l) and remote side (r):
下表描述了如何计算这些通信密钥中的每一个，其中TCP-AO算法引用IP地址、TCP端口和ISN的源（S）和目标（D）值，并且每个段（传入或传出）都有一个引用连接的本地侧（l）和远程侧（r）的值：
S-IP S-port S-ISN D-IP D-port D-ISN
----------------------------------------------------------------
Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0
Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0
Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN
Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN
S-IP S-port S-ISN D-IP D-port D-ISN
----------------------------------------------------------------
Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0
Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0
Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN
Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN
The use of both ISNs in the traffic key computations ensures that segments cannot be replayed across repeated connections reusing the same socket; their 32-bit space avoids repeated use except under reboot, and reuse assumes both sides repeat their use on the same connection. We do expect that:
在流量密钥计算中使用两个iSN可确保不能在重复使用同一套接字的连接之间重放数据段；它们的32位空间避免了重复使用，除非在重新启动的情况下，重复使用假定双方在同一连接上重复使用。我们期望：
>> Endpoints should select ISNs pseudorandomly, e.g., as in [RFC1948].
>>端点应伪随机选择ISNs，如[RFC1948]中所述。
A SYN is authenticated using a destination ISN of zero (whether sent or received), and all other segments would be authenticated using the ISN pair for the connection. There are other cases in which the destination ISN is not known, but segments are emitted, such as after an endpoint reboots, when it is possible that the two endpoints would not have enough information to authenticate segments. This is addressed further in Section 7.7.
SYN使用零的目标ISN（无论是发送的还是接收的）进行身份验证，所有其他段将使用连接的ISN对进行身份验证。在其他情况下，目标ISN未知，但会发出段，例如在端点重新启动后，两个端点可能没有足够的信息来验证段。第7.7节对此作了进一步说明。
TCP-AO does not provide a mechanism for traffic key negotiation or parameter negotiation (MAC algorithm, length, or use of TCP-AO on a connection), or for coordinating rekeying during a connection. We assume out-of-band mechanisms for MKT establishment, parameter negotiation, and rekeying. This separation of MKT use from MKT management is similar to that in the IPsec suite [RFC4301][RFC4306].
TCP-AO不提供用于流量密钥协商或参数协商（MAC算法、长度或TCP-AO在连接上的使用）的机制，也不提供用于在连接期间协调密钥更新的机制。我们假设带外机制用于MKT建立、参数协商和密钥更新。这种MKT使用与MKT管理的分离类似于IPsec套件[RFC4301][RFC4306]中的分离。
We encourage users of TCP-AO to apply known techniques for generating appropriate MKTs, including the use of reasonable master key lengths, limited traffic key sharing, and limiting the duration of MKT use [RFC3562]. This also includes the use of per-connection nonces, as suggested in Section 5.2.
我们鼓励TCP-AO用户应用已知技术生成适当的MKT，包括使用合理的主密钥长度、有限的通信密钥共享和限制MKT使用的持续时间[RFC3562]。这还包括使用第5.2节中建议的每个连接的nonce。
TCP-AO supports rekeying in which new MKTs are negotiated and coordinated out of band, either via a protocol or a manual procedure [RFC4808]. New MKT use is coordinated using the out-of-band mechanism to update both TCP endpoints. When only a single MKT is used at a time, the temporary use of invalid MKTs could result in segments being dropped; although TCP is already robust to such drops, TCP-AO uses the KeyID field to avoid such drops. A given connection can have multiple matching MKTs, where the KeyID field is used to identify the MKT that corresponds to the traffic key used for a segment, to avoid the need for expensive trial-and-error testing of MKTs in sequence.
TCP-AO支持通过协议或手动程序在带外协商和协调新MKT的密钥更新[RFC4808]。使用带外机制协调新的MKT使用，以更新两个TCP端点。当一次仅使用一个MKT时，临时使用无效MKT可能会导致删除段；虽然TCP已经对此类丢弃具有鲁棒性，但TCP-AO使用KeyID字段来避免此类丢弃。一个给定的连接可以有多个匹配的MKT，其中KeyID字段用于识别与用于一个段的流量密钥相对应的MKT，以避免对MKT进行昂贵的顺序试错测试。
TCP-AO provides an explicit MKT coordination mechanism, described in Section 6.1. Such a mechanism is useful when new MKTs are installed, or when MKTs are changed, to determine when to commence using installed MKTs.
TCP-AO提供了明确的MKT协调机制，如第6.1节所述。当安装了新的MKT或MKT发生变化时，这种机制非常有用，可以确定何时开始使用已安装的MKT。
Users are advised to manage MKTs following the spirit of the advice for key management when using TCP MD5 [RFC3562], notably to use appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among multiple BGP peering arrangements.
建议用户在使用TCP MD5[RFC3562]时按照密钥管理建议的精神管理MKT，特别是使用适当的密钥长度（12-24字节），并避免在多个BGP对等安排之间共享MKT。
MKTs can be reused across different socket pairs within a host, or across different instances of a socket pair within a host. In either case, replay protection is maintained.
MKT可以跨主机内的不同套接字对重用，也可以跨主机内套接字对的不同实例重用。在这两种情况下，都会保持重播保护。
MKTs reused across different socket pairs cannot enable replay attacks because the TCP socket pair is included in the MAC, as well as in the generation of the traffic key. MKTs reused across repeated
跨不同套接字对重用的MKT无法启用重播攻击，因为TCP套接字对包含在MAC中，也包含在流量密钥的生成中。MKTs在重复的系统中重复使用
instances of a given socket pair cannot enable replay attacks because the connection ISNs are included in the traffic key generation algorithm, and ISN pairs are unlikely to repeat over useful periods.
给定套接字对的实例无法启用重播攻击，因为连接ISN包含在流量密钥生成算法中，并且ISN对不太可能在有用的时间段内重复。
TCP-AO uses Sequence Number Extensions (SNEs) to prevent replay attacks within long-lived connections. Explicit MKT rollover, accomplished by external means and indexed using the KeyID field, can be used to change keying material for various reasons (e.g., personnel turnover), but is not required to support long-lived connections.
TCP-AO使用序列号扩展（SNE）来防止长寿命连接中的重播攻击。明确的MKT滚动，通过外部方式完成，并使用KeyID字段进行索引，可用于出于各种原因（如人员流动）更改键控材料，但不需要支持长期连接。
TCP-AO adds mechanisms to support efficient use, especially in environments where only manual keying is available. These include the previously described mechanisms for supporting multiple concurrent MKTs (via the KeyID field) and for generating unique per-connection traffic keys (via the KDF). This section describes additional mechanisms to coordinate MKT changes and to prevent replay attacks when a traffic key is not changed for long periods of time.
TCP-AO增加了支持高效使用的机制，特别是在只有手动键控可用的环境中。这些包括前面描述的用于支持多个并发mkt（通过KeyID字段）和用于生成唯一的每连接流量密钥（通过KDF）的机制。本节描述了协调MKT更改以及在长时间未更改流量密钥时防止重播攻击的其他机制。
At any given time, a single TCP connection may have multiple MKTs specified for each segment direction (incoming, outgoing). TCP-AO provides a mechanism to indicate when a new MKT is ready, which allows the sender to commence use of that new MKT. This mechanism allows new MKT use to be coordinated, to avoid unnecessary loss due to sender authentication using an MKT not yet ready at the receiver.
在任何给定时间，单个TCP连接可能会为每个段方向（传入、传出）指定多个MKT。TCP-AO提供了一种机制，用于指示新MKT何时准备就绪，从而允许发送方开始使用该新MKT。该机制允许协调新的MKT使用，以避免由于发送方使用尚未在接收方准备好的MKT进行身份验证而导致的不必要的丢失。
Note that this is intended as an optimization. Deciding when to start using a key is a performance issue. Deciding when to remove an MKT is a security issue. Invalid MKTs are expected to be removed. TCP-AO provides no mechanism to coordinate their removal, as we consider this a key management operation.
请注意，这是一种优化。决定何时开始使用密钥是一个性能问题。决定何时删除MKT是一个安全问题。预期将删除无效的MKT。TCP-AO没有提供协调它们移除的机制，因为我们认为这是一个关键的管理操作。
New MKT use is coordinated through two ID fields in the header:
新的MKT使用通过标题中的两个ID字段进行协调：
o KeyID
o 钥匙
o RNextKeyID
o RNextKeyID
KeyID represents the outgoing MKT information used by the segment sender to create the segment's MAC (outgoing), and the corresponding incoming keying information used by the segment receiver to validate that MAC. It contains the SendID of the MKT in active use in that direction.
KeyID表示段发送方用于创建段的MAC（传出）的传出MKT信息，以及段接收方用于验证该MAC的相应传入键控信息。它包含在该方向上活动使用的MKT的SendID。
RNextKeyID represents the preferred MKT information to be used for subsequent received segments ('receive next'). That is, it is a way for the segment sender to indicate a ready incoming MKT for future segments it receives, so that the segment receiver can know when to switch MKTs (and thus their KeyIDs and associated traffic keys). It indicates the RecvID of the MKT desired for incoming segments.
RNextKeyID表示用于后续接收段（“接收下一个”）的首选MKT信息。也就是说，这是段发送方为其接收的未来段指示准备好的传入MKT的一种方式，以便段接收方可以知道何时切换MKT（以及它们的密钥ID和相关的通信密钥）。它表示传入段所需的MKT的RecvID。
There are two pointers kept by each side of a connection, as noted in the per-connection information (see Section 4):
如per connection信息（参见第4节）中所述，连接的每一侧保留两个指针：
o Currently active outgoing MKT (current_key)
o 当前激活的传出MKT（当前_键）
o Current preference for incoming MKT (rnext_key)
o 传入MKT的当前首选项（rnext_键）
Current_key indicates an MKT that is used to authenticate outgoing segments. Upon connection establishment, it points to the first MKT selected for use.
当前_密钥表示用于验证传出段的MKT。连接建立后，它指向选择使用的第一个MKT。
Rnext_key points to an incoming MKT that is ready and preferred for use. Upon connection establishment, this points to the currently active incoming MKT. It can be changed when new MKTs are installed (e.g., by either automatic MKT management protocol operation or user manual selection).
Rnext_指向准备好并首选使用的传入市场的关键点。连接建立后，这指向当前活动的传入MKT。当安装新的MKT时，可以更改它（例如，通过自动MKT管理协议操作或用户手动选择）。
Rnext_key is changed only by manual user intervention or MKT management protocol operation. It is not manipulated by TCP-AO. Current_key is updated by TCP-AO when processing received TCP segments as discussed in the segment processing description in Section 7.5. Note that the algorithm allows the current_key to change to a new MKT, then change back to a previously used MKT (known as "backing up"). This can occur during an MKT change when segments are received out of order, and is considered a feature of TCP-AO, because reordering does not result in drops. The only way to avoid reuse of previously used MKTs is to remove the MKT when it is no longer considered permitted.
Rnext_密钥只能通过手动用户干预或MKT管理协议操作进行更改。它不是由TCP-AO操纵的。如第7.5节中的段处理说明所述，当处理接收到的TCP段时，TCP-AO会更新当前的_密钥。请注意，该算法允许当前_密钥更改为新的MKT，然后更改回以前使用的MKT（称为“备份”）。这可能发生在MKT更改期间，当接收到的数据段顺序不正确时，这被视为TCP-AO的一项功能，因为重新排序不会导致数据丢失。避免重复使用以前使用的MKT的唯一方法是在认为不再允许时移除MKT。
TCP uses a 32-bit sequence number, which may, for long-lived connections, roll over and repeat. This could result in TCP segments being intentionally and legitimately replayed within a connection. TCP-AO prevents replay attacks, and thus requires a way to
TCP使用32位序列号，对于长寿命连接，该序列号可能会滚动和重复。这可能导致TCP段在连接中被有意地合法地重播。TCP-AO可防止重播攻击，因此需要一种
differentiate these legitimate replays from each other, and so it adds a 32-bit Sequence Number Extension (SNE) for transmitted and received segments.
将这些合法的回放彼此区分开来，因此它为传输和接收的片段添加了一个32位序列号扩展（SNE）。
The SNE extends the TCP sequence number so that segments within a single connection are always unique. When the TCP's sequence number rolls over, there is a chance that a segment could be repeated in total; using an SNE differentiates even identical segments sent with identical sequence numbers at different times in a connection. TCP-AO emulates a 64-bit sequence number space by inferring when to increment the high-order 32-bit portion (the SNE) based on transitions in the low-order portion (the TCP sequence number).
SNE扩展TCP序列号，以便单个连接中的段始终是唯一的。当TCP的序列号翻滚时，有可能一个段会全部重复；使用SNE可以区分在连接的不同时间使用相同序列号发送的甚至相同的段。TCP-AO通过基于低阶部分（TCP序列号）中的转换推断何时递增高阶32位部分（SNE）来模拟64位序列号空间。
TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE for received segments, both initialized as zero when a connection begins. The intent of these SNEs is, together with TCP's 32-bit sequence numbers, to provide a 64-bit overall sequence number space.
因此，TCP-AO为传输段维护SND.SNE，为接收段维护RCV.SNE，两者在连接开始时都初始化为零。这些SNE的目的是，与TCP的32位序列号一起，提供64位的总序列号空间。
For transmitted segments, SND.SNE can be implemented by extending TCP's sequence number to 64 bits; SND.SNE would be the top (high-order) 32 bits of that number. For received segments, TCP-AO needs to emulate the use of a 64-bit number space and correctly infer the appropriate high-order 32-bits of that number as RCV.SNE from the received 32-bit sequence number and the current connection context.
对于传输段，SND.SNE可以通过将TCP的序列号扩展到64位来实现；SND.SNE将是该数字的顶部（高阶）32位。对于接收到的段，TCP-AO需要模拟64位数字空间的使用，并根据接收到的32位序列号和当前连接上下文正确推断该数字的适当高阶32位为RCV.SNE。
The implementation of SNEs is not specified in this document, but one possible way is described here that can be used for either RCV.SNE, SND.SNE, or both.
本文件未规定SNE的实施，但此处描述了一种可能的方法，可用于RCV.SNE、SND.SNE或两者。
Consider an implementation with two SNEs as required (SND.SNE, RCV. SNE), and additional variables as listed below, all initialized to zero, as well as a current TCP segment field (SEG.SEQ):
考虑一个具有两个SNE的实现（SND.SNE，RCV.SNE），以及下面列出的其他变量，所有初始化为零，以及当前TCP段字段（SEG.SEQ）：
o SND.PREV_SEQ, needed to detect rollover of SND.SEQ
o SND.PREV_SEQ，需要检测SND.SEQ的滚动
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o RCV.PREV_SEQ，需要检测RCV.SEQ的滚动
o SND.SNE_FLAG, which indicates when to increment the SND.SNE
o SND.SNE_标志，指示何时增加SND.SNE
o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE
o RCV.SNE_标志，指示何时增加RCV.SNE
When a segment is received, the following algorithm (in C-like pseudocode) computes the SNE used in the MAC; this is the "RCV" side, and an equivalent algorithm can be applied to the "SND" side:
当接收到段时，以下算法（在类C伪码中）计算MAC中使用的SNE；这是“RCV”侧，等效算法可应用于“SND”侧：
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1;
}
/* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value
} else {
SNE = RCV.SNE; # use the current value
}
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.SNE_FLAG = 0;
}
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1;
}
/* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value
} else {
SNE = RCV.SNE; # use the current value
}
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.SNE_FLAG = 0;
}
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;
In the above code, the first time the sequence number rolls over, i.e., when the new number is low (in the bottom half of the number space) and the old number is high (in the top half of the number space), the SNE is incremented and a flag is set.
在上述代码中，序列号第一次滚动时，即，当新编号较低（在数字空间的下半部分）而旧编号较高（在数字空间的上半部分）时，SNE递增并设置标志。
If the flag is set and a high number is seen, it must be a reordered segment, so use the pre-increment SNE; otherwise, use the current SNE.
如果设置了标志并且看到一个高数字，那么它必须是一个重新排序的段，因此使用预增量SNE；否则，请使用当前的SNE。
The flag will be cleared by the time the number rolls all the way around.
该标志将在数字滚动到所有位置时清除。
The flag prevents the SNE from being incremented again until the flag is reset, which happens in the middle of the window (when the old number is in the bottom half and the new is in the top half). Because the receive window is never larger than half of the number space, it is impossible to both set and reset the flag at the same time -- outstanding segments, regardless of reordering, cannot straddle both regions simultaneously.
该标志防止SNE再次被重置直到旗子重置，该标志发生在窗口的中间（当旧的数字在下半部，而新的在上半部）。因为接收窗口永远不会大于数字空间的一半，所以不可能同时设置和重置标志——未完成的段，无论重新排序如何，都不能同时跨两个区域。
The following is a description of how TCP-AO affects various TCP states, segments, events, and interfaces. This description is intended to augment the description of TCP as provided in RFC 793, and its presentation mirrors that of RFC 793 as a result [RFC793].
以下描述TCP-AO如何影响各种TCP状态、段、事件和接口。本说明旨在补充RFC 793中提供的TCP说明，因此其表示方式与RFC 793的表示方式一致[RFC793]。
The TCP user interface supports active and passive OPEN, SEND, RECEIVE, CLOSE, STATUS, and ABORT commands. TCP-AO does not alter this interface as it applies to TCP, but some commands or command sequences of the interface need to be modified to support TCP-AO. TCP-AO does not specify the details of how this is achieved.
TCP用户界面支持主动和被动打开、发送、接收、关闭、状态和中止命令。TCP-AO不会改变此接口，因为它适用于TCP，但需要修改接口的某些命令或命令序列以支持TCP-AO。TCP-AO没有详细说明如何实现这一点。
TCP-AO requires that the TCP user interface be extended to allow the MKTs to be configured, as well as to allow an ongoing connection to manage which MKTs are active. The MKTs need to be configured prior to connection establishment, and the set of MKTs may change during a connection:
TCP-AO要求扩展TCP用户界面，以允许配置MKT，并允许进行连接以管理哪些MKT处于活动状态。需要在建立连接之前配置MKT，并且MKT集可能在连接过程中发生变化：
>> TCP OPEN, or the sequence of commands that configure a connection to be in the active or passive OPEN state, MUST be augmented so that an MKT can be configured.
>>必须扩充TCP OPEN或将连接配置为主动或被动打开状态的命令序列，以便可以配置MKT。
>> A TCP-AO implementation MUST allow the set of MKTs for ongoing TCP connections (i.e., not in the CLOSED state) to be modified.
>>TCP-AO实现必须允许修改正在进行的TCP连接（即未处于关闭状态）的MKT集。
The MKTs associated with a connection need to be available for confirmation; this includes the ability to read the MKTs:
需要提供与连接相关的MKT以供确认；这包括读取MKTs的能力：
>> TCP STATUS SHOULD be augmented to allow the MKTs of a current or pending connection to be read (for confirmation).
>>应增加TCP状态，以允许读取当前或挂起连接的MKT（用于确认）。
Senders may need to be able to determine when the outgoing MKT changes (KeyID) or when a new preferred MKT (RNextKeyID) is indicated; these changes immediately affect all subsequent outgoing segments:
发送方可能需要能够确定传出MKT何时更改（KeyID）或何时指示新的首选MKT（RNextKeyID）；这些更改会立即影响所有后续传出段：
>> TCP SEND, or a sequence of commands resulting in a SEND, MUST be augmented so that the preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection can be indicated.
>>TCP SEND或导致发送的一系列命令必须增加，以便可以指示连接的首选传出MKT（当前_键）和/或首选传入MKT（rnext_键）。
It may be useful to change the outgoing active MKT (current_key) even when no data is being sent, which can be achieved by sending a zero-length buffer or by using a non-send interface (e.g., socket options in Unix), depending on the implementation.
即使未发送数据，更改传出活动MKT（当前_键）也可能很有用，这可以通过发送零长度缓冲区或使用非发送接口（例如Unix中的套接字选项）来实现，具体取决于实现。
It is also useful to indicate recent segment KeyID and RNextKeyID values received; although there could be a number of such values, they are not expected to change quickly, so any recent sample should be sufficient:
指示最近收到的段KeyID和RNextKeyID值也很有用；虽然可能有许多这样的值，但它们不会很快改变，因此任何最近的样本都应该足够：
>> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, MUST be augmented so that the KeyID and RNextKeyID of a recently received segment is available to the user out of band (e.g., as an additional parameter to RECEIVE or via a STATUS call).
>>TCP接收或产生接收的命令序列必须增加，以便最近接收的段的KeyID和RNextKeyID可供带外用户使用（例如，作为接收的附加参数或通过状态调用）。
TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and CLOSED.
TCP包括侦听、SYN-SENT、SYN-RECEIVE、已建立、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT和CLOSED状态。
>> An MKT MAY be associated with any TCP state.
>>MKT可以与任何TCP状态相关联。
TCP includes control (at least one of SYN, FIN, RST flags set) and data (none of SYN, FIN, or RST flags set) segments. Note that some control segments can include data (e.g., SYN).
TCP包括控制（至少设置了一个SYN、FIN、RST标志）和数据（未设置任何SYN、FIN或RST标志）段。注意，一些控制段可以包括数据（例如，SYN）。
>> All TCP segments MUST be checked against the set of MKTs for matching TCP connection identifiers.
>>必须对照MKT集检查所有TCP段，以匹配TCP连接标识符。
>> TCP segments whose TCP-AO does not validate MUST be silently discarded.
>>必须以静默方式丢弃其TCP-AO未验证的TCP段。
>> A TCP-AO implementation MUST allow for configuration of the behavior of segments with TCP-AO but that do not match an MKT. The initial default of this configuration SHOULD be to silently accept such connections. If this is not the desired case, an MKT can be included to match such connections, or the connection can indicate that TCP-AO is required. Alternately, the configuration can be changed to discard segments with the AO option not matching an MKT.
>>TCP-AO实现必须允许配置具有TCP-AO但与MKT不匹配的段的行为。此配置的初始默认值应该是静默地接受此类连接。如果这不是期望的情况，则可以包括一个MKT以匹配此类连接，或者该连接可以指示需要TCP-AO。或者，配置可以更改为丢弃AO选项与MKT不匹配的段。
>> Silent discard events SHOULD be signaled to the user as a warning, and silent accept events MAY be signaled to the user as a warning. Both warnings, if available, MUST be accessible via the STATUS interface. Either signal MAY be asynchronous, but if so, they MUST be rate-limited. Either signal MAY be logged; logging SHOULD allow rate-limiting as well.
>>静默丢弃事件应作为警告通知用户，静默接受事件可作为警告通知用户。这两个警告（如果可用）必须可通过状态界面访问。任何一个信号都可能是异步的，但如果是，它们必须是速率受限的。可记录任一信号；日志记录也应该允许速率限制。
All TCP-AO processing occurs between the interface of TCP and IP; for incoming segments, this occurs after validation of the TCP checksum. For outgoing segments, this occurs before computation of the TCP checksum.
所有TCP-AO处理都发生在TCP和IP的接口之间；对于传入段，这发生在TCP校验和验证之后。对于传出段，这发生在TCP校验和计算之前。
Note that use of TCP-AO on a connection is not negotiated within TCP. It is the responsibility of the receiver to determine when TCP-AO is required via other means (e.g., out of band, manually or with a key management protocol) and to enforce that requirement.
请注意，在连接上使用TCP-AO不是在TCP内协商的。接收方负责通过其他方式（例如带外、手动或使用密钥管理协议）确定何时需要TCP-AO，并执行该要求。
The following procedure describes the modifications to TCP to support inserting TCP-AO when a segment departs.
以下过程描述了对TCP的修改，以支持在段离开时插入TCP-AO。
>> Note that TCP-AO MUST be the last TCP option processed on outgoing segments, because its MAC calculation may include the values of other TCP options.
>>请注意，TCP-AO必须是在传出段上处理的最后一个TCP选项，因为其MAC计算可能包括其他TCP选项的值。
1. Find the per-connection parameters for the segment:
1. 查找段的每个连接参数：
a. If the segment is a SYN, then this is the first segment of a new connection. Find the matching MKT for this segment based on the segment's socket pair.
a. 如果该段是SYN，则这是新连接的第一段。根据段的套接字对查找此段的匹配MKT。
i. If there is no matching MKT, omit TCP-AO. Proceed with transmitting the segment.
i. 如果没有匹配的MKT，则省略TCP-AO。继续传输该段。
ii. If there is a matching MKT, then set the per-connection parameters as needed (see Section 4). Proceed with the step 2.
二,。如果存在匹配的MKT，则根据需要设置每个连接参数（参见第4节）。继续执行步骤2。
b. If the segment is not a SYN, then determine whether TCP-AO is being used for the connection and use the MKT as indicated by the current_key value from the per-connection parameters (see Section 4) and proceed with the step 2.
b. 如果该段不是SYN，则确定TCP-AO是否用于连接，并根据per连接参数（参见第4节）中的当前_键值使用MKT，然后继续执行步骤2。
2. Using the per-connection parameters:
2. 使用每个连接参数：
a. Augment the TCP header with TCP-AO, inserting the appropriate Length and KeyID based on the MKT indicated by current_key (using the current_key MKT's SendID as the TCP-AO KeyID). Update the TCP header length accordingly.
a. 使用TCP-AO扩充TCP头，根据当前_键指示的MKT插入适当的长度和密钥ID（使用当前_键MKT的SendID作为TCP-AO密钥ID）。相应地更新TCP头长度。
b. Determine SND.SNE as described in Section 6.2.
b. 按照第6.2节所述确定SND.SNE。
c. Determine the appropriate traffic key, i.e., as pointed to by the current_key (as noted in Section 6.1, and as probably cached in the TCB). That is, use the send_SYN_traffic_key for SYN segments and the send_other_traffic_key for other segments.
c. 确定适当的流量密钥，即当前_密钥所指向的流量密钥（如第6.1节所述，可能缓存在TCB中）。也就是说，对于SYN段使用send_SYN_traffic_键，对于其他段使用send_other_traffic_键。
d. Determine the RNextKeyID as indicated by the rnext_key pointer, and insert it in the TCP-AO RNextKeyID field (using the rnext_key MKT's RecvID as the TCP-AO KeyID) (as noted in Section 6.1).
d. 确定由rnext_密钥指针指示的RNextKeyID，并将其插入TCP-AO RNextKeyID字段（使用rnext_密钥MKT的RecvID作为TCP-AO密钥ID）（如第6.1节所述）。
e. Compute the MAC using the MKT (and cached traffic key) and data from the segment as specified in Section 5.1.
e. 根据第5.1节的规定，使用MKT（和缓存的流量密钥）和数据段计算MAC。
f. Insert the MAC in the TCP-AO MAC field.
f. 在TCP-AO MAC字段中插入MAC。
g. Proceed with transmitting the segment.
g. 继续传输该段。
The following procedure describes the modifications to TCP to support TCP-AO when a segment arrives.
以下过程描述了对TCP的修改，以在段到达时支持TCP-AO。
>> Note that TCP-AO MUST be the first TCP option processed on incoming segments, because its MAC calculation may include the values of other TCP options that could change during TCP option processing. This also protects the behavior of all other TCP options from the impact of spoofed segments or modified header information.
>>请注意，TCP-AO必须是在传入段上处理的第一个TCP选项，因为其MAC计算可能包括在TCP选项处理期间可能更改的其他TCP选项的值。这还可以保护所有其他TCP选项的行为不受伪造段或修改的标头信息的影响。
>> Note that TCP-AO checks MUST be performed for all incoming SYNs to avoid accepting SYNs lacking TCP-AO where required. Other segments can cache whether TCP-AO is needed in the TCB.
>>请注意，必须对所有传入SYN执行TCP-AO检查，以避免在需要时接受缺少TCP-AO的SYN。其他段可以缓存TCB中是否需要TCP-AO。
1. Find the per-connection parameters for the segment:
1. 查找段的每个连接参数：
a. If the segment is a SYN, then this is the first segment of a new connection. Find the matching MKT for this segment, using the segment's socket pair and its TCP-AO KeyID, matched against the MKT's TCP connection identifier and the MKT's RecvID.
a. 如果该段是SYN，则这是新连接的第一段。使用段的套接字对及其TCP-AO密钥ID（与MKT的TCP连接标识符和MKT的RecvID相匹配）查找此段的匹配MKT。
i. If there is no matching MKT, remove TCP-AO from the segment. Proceed with further TCP handling of the segment.
i. 如果没有匹配的MKT，则从段中删除TCP-AO。继续对段进行进一步的TCP处理。
NOTE: this presumes that connections that do not match any MKT should be silently accepted, as noted in Section 7.3.
注：如第7.3节所述，这假定不匹配任何MKT的连接应被静默接受。
ii. If there is a matching MKT, then set the per-connection parameters as needed (see Section 4). Proceed with step 2.
二,。如果存在匹配的MKT，则根据需要设置每个连接参数（参见第4节）。继续执行步骤2。
2. Using the per-connection parameters:
2. 使用每个连接参数：
a. Check that the segment's TCP-AO Length matches the length indicated by the MKT.
a. 检查段的TCP-AO长度是否与MKT指示的长度匹配。
i. If the lengths differ, silently discard the segment. Log and/or signal the event as indicated in Section 7.3.
i. 如果长度不同，则自动放弃该段。如第7.3节所示记录和/或发出事件信号。
b. Determine the segment's RCV.SNE as described in Section 6.2.
b. 如第6.2节所述，确定分段的RCV.SNE。
c. Determine the segment's traffic key from the MKT as described in Section 5.1 (and as likely cached in the TCB). That is, use the receive_SYN_traffic_key for SYN segments and the receive_other_traffic_key for other segments.
c. 如第5.1节所述，从MKT中确定段的通信密钥（可能缓存在TCB中）。也就是说，对SYN段使用receive_SYN_traffic_键，对其他段使用receive_other_traffic_键。
d. Compute the segment's MAC using the MKT (and its derived traffic key) and portions of the segment as indicated in Section 5.1.
d. 使用MKT（及其导出的流量密钥）和第5.1节中所示的段部分计算段的MAC。
i. If the computed MAC differs from the TCP-AO MAC field value, silently discard the segment. Log and/or signal the event as indicated in Section 7.3.
i. 如果计算的MAC与TCP-AO MAC字段值不同，则自动放弃该段。如第7.3节所示记录和/或发出事件信号。
e. Compare the received RNextKeyID value to the currently active outgoing KeyID value (current_key MKT's SendID).
e. 将接收到的RNextKeyID值与当前活动的传出KeyID值（当前密钥市场的SendID）进行比较。
i. If they match, no further action is required.
i. 如果它们匹配，则无需采取进一步措施。
ii. If they differ, determine whether the RNextKeyID MKT is ready.
二,。如果它们不同，确定RNextKeyID MKT是否准备就绪。
1. If the MKT corresponding to the segment's socket pair and RNextKeyID is not available, no action is required (RNextKeyID of a received segment needs to match the MKT's SendID).
1. 如果与段的套接字对和RNextKeyID对应的MKT不可用，则无需执行任何操作（接收段的RNextKeyID需要与MKT的SendID匹配）。
2. If the matching MKT corresponding to the segment's socket pair and RNextKeyID is available:
2. 如果段的套接字对和RNextKeyID对应的匹配MKT可用：
a. Set current_key to the RNextKeyID MKT.
a. 将当前_键设置为RNextKeyID MKT。
f. Proceed with TCP processing of the segment.
f. 继续对段进行TCP处理。
It is suggested that TCP-AO implementations validate a segment's Length field before computing a MAC to reduce the overhead incurred by spoofed segments with invalid TCP-AO fields.
建议TCP-AO实现在计算MAC之前验证段的长度字段，以减少使用无效TCP-AO字段欺骗段所产生的开销。
Additional reductions in MAC validation overhead can be supported in the MAC algorithms, e.g., by using a computation algorithm that prepends a fixed value to the computed portion and a corresponding validation algorithm that verifies the fixed value before investing in the computed portion. Such optimizations would be contained in the MAC algorithm specification, and thus are not specified in TCP-AO explicitly. Note that the KeyID cannot be used for connection validation per se, because it is not assumed random.
MAC算法中可以支持MAC验证开销的额外减少，例如，通过使用向计算部分预先提供固定值的计算算法和在投资于计算部分之前验证固定值的相应验证算法。这种优化将包含在MAC算法规范中，因此在TCP-AO中没有明确规定。请注意，KeyID本身不能用于连接验证，因为它不是随机的。
TCP-AO, using the initially required 96-bit MACs, uses a total of 16 bytes of TCP header space [RFC5926]. TCP-AO is thus 2 bytes smaller than the TCP MD5 option (18 bytes).
TCP-AO使用最初需要的96位MAC，总共使用16字节的TCP报头空间[RFC5926]。因此，TCP-AO比TCP MD5选项（18字节）小2字节。
Note that the TCP option space is most critical in SYN segments, because flags in those segments could potentially increase the option space area in other segments. Because TCP ignores unknown segments, however, it is not possible to extend the option space of SYNs without breaking backward compatibility.
请注意，TCP选项空间在SYN段中最为关键，因为这些段中的标志可能会增加其他段中的选项空间面积。但是，由于TCP忽略未知段，因此不可能在不破坏向后兼容性的情况下扩展SYNs的选项空间。
TCP's 4-bit data offset requires that the options end 60 bytes (15 32-bit words) after the header begins, including the 20-byte header. This leaves 40 bytes for options, of which 15 are expected in current implementations (listed below), leaving at most 25 for other uses. TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options (depending on implementation dependant alignment padding, which could consume another 2 bytes at most).
TCP的4位数据偏移量要求选项在标头开始后结束60字节（15个32位字），包括20字节标头。这就为选项留下了40个字节，其中15个在当前的实现中（如下所列），剩下最多25个用于其他用途。TCP-AO消耗16个字节，剩下9个字节用于其他SYN选项（取决于依赖于实现的对齐填充，最多可能消耗另外2个字节）。
o SACK permitted (2 bytes) [RFC2018][RFC3517]
o 允许SACK（2字节）[RFC2018][RFC3517]
o Timestamps (10 bytes) [RFC1323]
o 时间戳（10字节）[RFC1323]
o Window scale (3 bytes) [RFC1323]
o 窗口比例（3字节）[RFC1323]
After a SYN, the following options are expected in current implementations of TCP:
在SYN之后，当前TCP实现中需要以下选项：
o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883])
o SACK（10字节）[RFC2018][RFC3517]（如果是D-SACK[RFC2883]，则为18字节）
o Timestamps (10 bytes) [RFC1323]
o 时间戳（10字节）[RFC1323]
TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a total of 24 bytes for other options, of which the timestamp consumes 10. This leaves 14 bytes, of which 10 are used for a single SACK block. When two SACK blocks are used, such as to handle D-SACK, a smaller TCP-AO MAC would be required to make room for the additional SACK block (i.e., to leave 18 bytes for the D-SACK variant of the
TCP-AO在非SYN段中继续消耗16个字节，为其他选项总共留下24个字节，其中时间戳消耗10个字节。剩下14个字节，其中10个用于单个SACK块。当使用两个SACK块时，例如用于处理D-SACK，则需要较小的TCP-AO MAC为额外的SACK块腾出空间（即，为数据的D-SACK变体保留18个字节）
SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP MD5 in the presence of timestamps, because TCP MD5's MAC length is fixed and too large to leave sufficient option space.
SACK选项）[RFC2883]。请注意，在存在时间戳的情况下，TCP MD5中不支持D-SACK，因为TCP MD5的MAC长度是固定的，并且太大，无法留下足够的选项空间。
Although TCP option space is limited, we believe TCP-AO is consistent with the desire to authenticate TCP at the connection level for similar uses as were intended by TCP MD5.
尽管TCP选项空间有限，但我们相信TCP-AO符合在连接级别对TCP进行身份验证的愿望，以用于TCP MD5所预期的类似用途。
TCP-AO allows TCP resets (RSTs) to be exchanged provided both sides have established valid connection state. After such state is established, if one side reboots, TCP-AO prevents TCP's RST mechanism from clearing out old state on the side that did not reboot. This happens because the rebooting side has lost its connection state, and thus its traffic keys.
TCP-AO允许交换TCP重置（RST），前提是双方都建立了有效的连接状态。在这种状态建立之后，如果一方重新启动，TCP-AO将阻止TCP的RST机制清除未重新启动的一方的旧状态。发生这种情况的原因是重新启动端已失去其连接状态，从而失去其通信密钥。
It is important that implementations are capable of detecting excesses of TCP connections in such a configuration and can clear them out if needed to protect its memory usage [Ba10]. To protect against such state from accumulating and not being cleared out, a number of recommendations are made:
重要的是，在这种配置中，实现能够检测到过度的TCP连接，并在需要时清除这些连接，以保护其内存使用[Ba10]。为了防止这种状态累积而不被清除，提出了一些建议：
>> Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122].
>>使用TCP-AO的连接也应使用TCP keepalives[RFC1122]。
The use of TCP keepalives ensures that connections whose keys are lost are terminated after a finite time; a similar effect can be achieved at the application layer, e.g., with BGP keepalives [RFC4271]. Either kind of keepalive helps ensure the TCP state is cleared out in such a case; the alternative, of allowing unauthenticated RSTs to be received, would allow one of the primary vulnerabilities that TCP-AO is intended to prevent.
TCP keepalives的使用确保密钥丢失的连接在有限时间后终止；在应用层可以实现类似的效果，例如，使用BGP keepalives[RFC4271]。任何一种keepalive都有助于确保在这种情况下清除TCP状态；另一种方法是允许接收未经验证的RST，这将允许TCP-AO旨在防止的主要漏洞之一。
Keepalives ensure that connections are dropped across reboots, but this can have a detrimental effect on some protocols. Specifically, BGP reacts poorly to such connection drops, even if caused by the use of BGP keepalives; "graceful restart" was introduced to address this effect [RFC4724], and extended to support BGP with MPLS [RFC4781]. As a result:
Keepalives确保在重新启动时断开连接，但这可能会对某些协议产生不利影响。具体来说，BGP对此类连接断开的反应很差，即使是由使用BGP keepalives引起的；引入“优雅重启”是为了解决这个问题[RFC4724]，并扩展到支持带有MPLS的BGP[RFC4781]。因此：
>> BGP connections SHOULD require support for graceful restart when using TCP-AO.
>>使用TCP-AO时，BGP连接应要求支持优雅重启。
We recognize that support for graceful restart is not always feasible. As a result:
我们认识到，支持优雅重启并不总是可行的。因此：
>> When BGP without graceful restart is used with TCP-AO, both sides of the connection SHOULD save traffic keys in storage that persists across reboots and restore them after a reboot, and SHOULD limit any performance impacts that result from this storage/restoration.
>>当不带正常重新启动的BGP与TCP-AO一起使用时，连接的双方应将在重新启动期间持续存在的通信密钥保存在存储器中，并在重新启动后恢复它们，并且应限制此存储/恢复导致的任何性能影响。
TCP can be attacked both in band, using TCP segments, or out of band using ICMP. ICMP packets cannot be protected using TCP-AO mechanisms; however, in this way, both TCP-AO and IPsec do not directly solve the need for protected ICMP signaling. TCP-AO does make specific recommendations on how to handle certain ICMPs, beyond what IPsec requires, and these are made possible because TCP-AO operates inside the context of a TCP connection.
TCP可以在带内、使用TCP段或使用ICMP在带外受到攻击。无法使用TCP-AO机制保护ICMP数据包；然而，通过这种方式，TCP-AO和IPsec都不能直接解决受保护ICMP信令的需要。TCP-AO确实就如何处理某些ICMP提出了具体的建议，超出了IPsec的要求，这些建议是可能的，因为TCP-AO在TCP连接的上下文中运行。
IPsec makes recommendations regarding dropping ICMPs in certain contexts or requiring that they are endpoint authenticated in others [RFC4301]. There are other mechanisms proposed to reduce the impact of ICMP attacks by further validating ICMP contents and changing the effect of some messages based on TCP state, but these do not provide the level of authentication for ICMP that TCP-AO provides for TCP [Go10]. As a result, we recommend a conservative approach to accepting ICMP messages as summarized in [Go10]:
IPsec建议在某些上下文中删除ICMP，或要求在其他上下文中对ICMP进行端点身份验证[RFC4301]。还提出了其他机制，通过进一步验证ICMP内容和根据TCP状态更改某些消息的效果来减少ICMP攻击的影响，但这些机制不提供TCP-AO为TCP提供的ICMP身份验证级别[Go10]。因此，我们建议采用[Go10]中总结的保守方法来接受ICMP消息：
>> A TCP-AO implementation MUST default to ignore incoming ICMPv4 messages of Type 3 (destination unreachable), Codes 2-4 (protocol unreachable, port unreachable, and fragmentation needed -- 'hard errors'), and ICMPv6 Type 1 (destination unreachable), Code 1 (administratively prohibited) and Code 4 (port unreachable) intended for connections in synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT) that match MKTs.
>>TCP-AO实现必须默认忽略类型3（目标不可访问）、代码2-4（协议不可访问、端口不可访问和所需碎片--“硬错误”）和ICMPv6类型1（目标不可访问）、代码1（管理禁止）和代码4（端口不可访问）的传入ICMPv4消息用于同步状态（已建立、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSE、LAST-ACK、TIME-WAIT）中与MKTs匹配的连接。
>> A TCP-AO implementation SHOULD allow whether such ICMPs are ignored to be configured on a per-connection basis.
>>TCP-AO实现应允许在每个连接的基础上配置是否忽略此类ICMP。
>> A TCP-AO implementation SHOULD implement measures to protect ICMP "packet too big" messages, some examples of which are discussed in [Go10].
>>TCP-AO实现应实施保护ICMP“数据包太大”消息的措施，其中一些示例在[Go10]中讨论。
>> An implementation SHOULD allow ignored ICMPs to be logged.
>>实现应允许记录被忽略的ICMP。
This control affects only ICMPs that currently require 'hard errors', which would abort the TCP connection [RFC1122]. This recommendation is intended to be similar to how IPsec would handle those messages, with an additional default assumed [RFC4301].
此控件仅影响当前需要“硬错误”的ICMP，这将中止TCP连接[RFC1122]。本建议旨在类似于IPsec处理这些消息的方式，并假定了一个附加的默认值[RFC4301]。
TCP-AO obsoletes TCP MD5. As we have noted earlier:
TCP-AO淘汰了TCP MD5。正如我们早些时候指出的那样：
>> TCP implementations that support TCP MD5 MUST support TCP-AO.
>>支持TCP MD5的TCP实现必须支持TCP-AO。
Systems implementing TCP MD5 only are considered legacy, and ought to be upgraded when possible. In order to support interoperation with such legacy systems until upgrades are available:
仅实现TCP MD5的系统被视为遗留系统，应该在可能的情况下进行升级。为了在升级可用之前支持与此类遗留系统的互操作：
>> TCP MD5 SHOULD be supported where interactions with legacy systems are needed.
>>如果需要与遗留系统进行交互，则应支持TCP MD5。
>> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for connections unless not supported by its peer, at which point it MAY use TCP MD5 instead.
>>同时支持TCP-AO和TCP MD5的系统必须使用TCP-AO进行连接，除非其对等方不支持，此时可以使用TCP MD5。
>> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a particular TCP connection, but MAY support TCP-AO and TCP MD5 simultaneously for different connections (notably to support legacy use of TCP MD5).
>>TCP实现不能对特定TCP连接同时使用TCP-AO和TCP MD5，但可以对不同的连接同时支持TCP-AO和TCP MD5（特别是支持TCP MD5的传统使用）。
The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used for a particular connection in TCP segments.
种类值明确指示TCP-AO或TCP MD5是否用于TCP段中的特定连接。
It is possible that MKTs could be augmented to support TCP MD5, although use of MKTs is not described in RFC 2385.
虽然RFC 2385中没有描述MKTs的使用，但MKTs可能会被扩展以支持TCP MD5。
It is possible to require TCP-AO for a connection or TCP MD5, but it is not possible to require 'either'. When an endpoint is configured to require TCP MD5 for a connection, it must be added to all outgoing segments and validated on all incoming segments [RFC2385]. TCP MD5's requirements prohibit the speculative use of both options for a given connection, e.g., to be decided by the other end of the connection.
连接或TCP MD5可能需要TCP-AO，但不可能要求“或”。当端点配置为需要TCP MD5进行连接时，必须将其添加到所有传出段，并在所有传入段上进行验证[RFC2385]。TCP MD5的要求禁止对给定连接推测性地使用这两个选项，例如，由连接的另一端决定。
TCP-AO may interact with middleboxes, depending on their behavior [RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO) directly or alter the information TCP-AO includes in its MAC calculation. TCP-AO may interfere with these devices, exactly where the device modifies information TCP-AO is designed to protect.
TCP-AO可能会与中间盒交互，具体取决于它们的行为[RFC3234]。一些中间盒要么直接改变TCP选项（如TCP-AO），要么改变TCP-AO在其MAC计算中包含的信息。TCP-AO可能会干扰这些设备，而这些设备正是在修改TCP-AO旨在保护的信息。
TCP-AO supports middleboxes that do not change the IP addresses or ports of segments. Such middleboxes may modify some TCP options, in which case TCP-AO would need to be configured to ignore all options in the MAC calculation on connections traversing that element.
TCP-AO支持不更改段的IP地址或端口的中间盒。此类中间盒可能会修改某些TCP选项，在这种情况下，需要将TCP-AO配置为忽略MAC计算中通过该元素的连接的所有选项。
Note that ignoring TCP options may provide less protection, i.e., TCP options could be modified in transit, and such modifications could be used by an attacker. Depending on the modifications, TCP could have compromised efficiency (e.g., timestamp changes), or could cease correct operation (e.g., window scale changes). These vulnerabilities affect only the TCP connections for which TCP-AO is configured to ignore TCP options.
请注意，忽略TCP选项可能会提供较少的保护，即TCP选项可能会在传输过程中被修改，攻击者可能会使用这些修改。根据修改情况，TCP可能会影响效率（例如，时间戳更改），或者可能会停止正确的操作（例如，窗口比例更改）。这些漏洞仅影响TCP-AO配置为忽略TCP选项的TCP连接。
TCP-AO cannot interoperate natively across NAT/NAPT (Network Address Port Translation) devices, which modify the IP addresses and/or port numbers. We anticipate that traversing such devices may require variants of existing NAT/NAPT traversal mechanisms, e.g., encapsulation of the TCP-AO-protected segment in another transport segment (e.g., UDP), as is done in IPsec [RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO, or IPsec with NAT traversal can be used instead of TCP-AO in such cases [RFC3947].
TCP-AO无法在NAT/NAPT（网络地址端口转换）设备之间进行本机互操作，这些设备会修改IP地址和/或端口号。我们预计，遍历此类设备可能需要现有NAT/NAPT遍历机制的变体，例如，将TCP AO保护段封装在另一个传输段（例如UDP）中，就像IPsec[RFC2663][RFC3947]中所做的那样。此类变体可适用于TCP-AO，或在此类情况下，可使用带NAT遍历的IPsec代替TCP-AO[RFC3947]。
An alternate proposal for accommodating NATs extends TCP-AO independently of this specification [To10].
另一种适应NAT的方案是独立于本规范扩展TCP-AO[10]。
TCP-AO satisfies all the current requirements for a revision to TCP MD5, as summarized below [Ed07].
TCP-AO满足TCP MD5修订版的所有当前要求，总结如下[Ed07]。
1. Protected Elements
1. 受保护元素
A solution to revising TCP MD5 should protect (authenticate) the following elements.
修改TCP MD5的解决方案应该保护（验证）以下元素。
This is supported -- see Section 5.1.
这是受支持的——参见第5.1节。
a. IP pseudoheader, including IPv4 and IPv6 versions.
a. IP伪标头，包括IPv4和IPv6版本。
Note that optional coverage is not allowed because IP addresses define a connection. If they can be coordinated across a NAT/NAPT, the sender can compute the MAC based on the received values; if not, a tunnel is required, as noted in Section 9.2.
请注意，由于IP地址定义了连接，因此不允许使用可选覆盖率。如果它们可以跨NAT/NAPT进行协调，则发送方可以基于接收到的值计算MAC；如果没有，则需要隧道，如第9.2节所述。
b. TCP header.
b. TCP头。
Note that optional port coverage is not allowed because ports define a connection. If they can be coordinated across a NAT/NAPT, the sender can compute the MAC based on the received values; if not, a tunnel is required, as noted in Section 9.2.
请注意，由于端口定义了连接，因此不允许使用可选端口覆盖率。如果它们可以跨NAT/NAPT进行协调，则发送方可以基于接收到的值计算MAC；如果没有，则需要隧道，如第9.2节所述。
c. TCP options.
c. TCP选项。
Note that TCP-AO allows the exclusion of TCP options from coverage, to enable use with middleboxes that modify options (except when they modify TCP-AO itself). See Section 9.
请注意，TCP-AO允许将TCP选项排除在覆盖范围之外，以允许使用修改选项的中间盒（除非它们修改TCP-AO本身）。见第9节。
d. TCP payload data.
d. TCP有效负载数据。
2. Option Structure Requirements
2. 期权结构要求
A solution to revising TCP MD5 should use an option with the following structural requirements.
修改TCP MD5的解决方案应使用具有以下结构要求的选项。
This is supported -- see Section 5.1.
这是受支持的——参见第5.1节。
a. Privacy.
a. 隐私
The option should not unnecessarily expose information about the TCP-AO mechanism. The additional protection afforded by keeping this information private may be of little value, but also helps keep the option size small.
该选项不应不必要地公开有关TCP-AO机制的信息。将此信息保密所提供的额外保护可能没有什么价值，但也有助于使选项的大小保持较小。
TCP-AO exposes only the MKT IDs, MAC, and overall option length on the wire. Note that short MACs could be obscured by using longer option lengths but specifying a short MAC length (this is equivalent to a different MAC algorithm, and is specified in the MKT). See Section 2.2.
TCP-AO仅在线路上公开MKT ID、MAC和总选项长度。请注意，短MAC可以通过使用更长的选项长度但指定较短的MAC长度来遮挡（这相当于不同的MAC算法，并且在MKT中指定）。见第2.2节。
b. Allow optional per connection.
b. 允许每个连接可选。
The option should not be required on every connection; it should be optional on a per-connection basis.
不应在每个连接上都需要该选项；在每个连接的基础上，它应该是可选的。
This is supported because the set of MKTs can be installed to match some connections and not others. Connections not matching any MKT do not require TCP-AO. Further, incoming segments with TCP-AO are not discarded solely because they include the option, provided they do not match any MKT.
这是受支持的，因为可以安装MKT集以匹配某些连接，而不是其他连接。不匹配任何MKT的连接不需要TCP-AO。此外，具有TCP-AO的传入段不会被丢弃，因为它们包含选项，前提是它们不匹配任何MKT。
c. Require non-optional.
c. 要求非可选。
The option should be able to be specified as required for a given connection.
该选项应能够根据给定连接的需要指定。
This is supported because the set of MKTs can be installed to match some connections and not others. Connections matching any MKT require TCP-AO.
这是受支持的，因为可以安装MKT集以匹配某些连接，而不是其他连接。与任何MKT匹配的连接都需要TCP-AO。
d. Standard parsing.
d. 标准解析。
The option should be easily parseable, i.e., without conditional parsing, and follow the standard RFC 793 option format.
该选项应易于解析，即无条件解析，并遵循标准RFC 793选项格式。
This is supported -- see Section 2.2.
这是受支持的——参见第2.2节。
e. Compatible with Large Windows and SACK.
e. 与大窗口和SACK兼容。
The option should be compatible with the use of the Large Windows and SACK options.
该选项应与大窗口和SACK选项的使用兼容。
This is supported -- see Section 7.6. The size of the option is intended to allow use with Large Windows and SACK. See also Section 1.3, which indicates that TCP-AO is 2 bytes shorter than TCP MD5 in the default case, assuming a 96-bit MAC.
这是受支持的——参见第7.6节。该选项的大小旨在允许与大窗口和SACK一起使用。另请参见第1.3节，该节指出，在默认情况下，假设为96位MAC，TCP-AO比TCP MD5短2字节。
3. Cryptography requirements
3. 密码要求
A solution to revising TCP MD5 should support modern cryptography capabilities.
修改TCP MD5的解决方案应支持现代加密功能。
a. Baseline defaults.
a. 基线默认值。
The option should have a default that is required in all implementations.
该选项应具有所有实现中都需要的默认值。
TCP-AO uses a default required algorithm as specified in [RFC5926] and as noted in Section 5.1 of this document.
TCP-AO使用[RFC5926]中规定的以及本文件第5.1节中说明的默认所需算法。
b. Good algorithms.
b. 好的算法。
The option should use algorithms considered accepted by the security community, which are considered appropriately safe. The use of non-standard or unpublished algorithms should be avoided.
该选项应使用被安全社区认为是适当安全的算法。应避免使用非标准或未发布的算法。
TCP-AO uses MACs as indicated in [RFC5926]. The KDF is also specified in [RFC5926]. The KDF input string follows the typical design (see [RFC5926]).
TCP-AO使用[RFC5926]中所示的MAC。[RFC5926]中也规定了KDF。KDF输入字符串遵循典型设计（请参见[RFC5926]）。
c. Algorithm agility.
c. 算法灵活性。
The option should support algorithms other than the default, to allow agility over time.
该选项应支持除默认算法之外的其他算法，以允许随时间变化的灵活性。
TCP-AO allows any desired algorithm, subject to TCP option space limitations, as noted in Section 2.2. The use of a set of MKTs allows separate connections to use different algorithms, both for the MAC and the KDF.
如第2.2节所述，TCP-AO允许任何需要的算法，但受TCP选项空间的限制。使用一组MKT允许单独的连接使用不同的算法，包括MAC和KDF。
d. Order-independent processing.
d. 订单独立处理。
The option should be processed independently of the proper order, i.e., they should allow processing of TCP segments in the order received, without requiring reordering. This avoids the need for reordering prior to processing, and avoids the impact of misordered segments on the option.
该选项应独立于正确的顺序进行处理，即，它们应允许按照接收的顺序处理TCP段，而无需重新排序。这避免了在处理之前需要重新排序，并避免了错误排序的段对选项的影响。
This is supported -- see Sections 7.3, 7.4, and 7.5. Note that pre-TCP processing is further required, because TCP segments cannot be discarded solely based on a combination of connection state and out-of-window checks; many such segments, although discarded, cause a host to respond with a replay of the last valid ACK, e.g., [RFC793]. See also the derivation of the SNE, which is reconstituted at the receiver using a demonstration algorithm that avoids the need for reordering (in Section 6.2).
这是受支持的——请参见第7.3、7.4和7.5节。请注意，还需要进行TCP前处理，因为不能仅基于连接状态和窗口外检查的组合来丢弃TCP段；许多这样的段虽然被丢弃，但会导致主机以最后一个有效ACK的重播进行响应，例如[RFC793]。另请参见SNE的推导，该推导在接收器处使用避免重新排序的演示算法进行重构（见第6.2节）。
e. Security parameter changes require key changes.
e. 安全参数更改需要更改密钥。
The option should require that the MKT change whenever the security parameters change. This avoids the need for coordinating option state during a connection, which is typical for TCP options. This also helps allow "bump in the stack" implementations that are not integrated with endpoint TCP implementations.
该选项应要求在安全参数更改时更改MKT。这避免了在连接过程中协调选项状态的需要，这是TCP选项的典型情况。这也有助于允许未与端点TCP实现集成的“堆栈中的凹凸”实现。
Parameters change only when a new MKT is used. See Section 3.
参数仅在使用新MKT时更改。见第3节。
4. Keying requirements.
4. 键控要求。
A solution to revising TCP MD5 should support manual keying, and should support the use of an external automated key management system (e.g., a protocol or other mechanism).
修改TCP MD5的解决方案应支持手动键控，并应支持使用外部自动密钥管理系统（例如，协议或其他机制）。
Note that TCP-AO does not specify an MKT management system.
请注意，TCP-AO没有指定MKT管理系统。
a. Intraconnection rekeying.
a. 连接内重新键控。
The option should support rekeying during a connection, to avoid the impact of long-duration connections.
该选项应支持在连接期间重新设置密钥，以避免长时间连接的影响。
This is supported by the use of IDs and multiple MKTs; see Section 3.
这是由IDs和多个MKT的使用所支持的；见第3节。
b. Efficient rekeying.
b. 高效的密钥更新。
The option should support rekeying during a connection without the need to expend undue computational resources. In particular, the options should avoid the need to try multiple keys on a given segment.
该选项应支持在连接过程中重新设置密钥，而无需花费过多的计算资源。特别是，这些选项应避免在给定段上尝试多个关键点。
This is supported by the use of the KeyID. See Section 6.1.
这通过使用KeyID得到支持。见第6.1节。
c. Automated and manual keying.
c. 自动和手动键控。
The option should support both automated and manual keying.
该选项应支持自动和手动键控。
The use of MKTs allows external automated and manual keying. See Section 3. This capability is enhanced by the generation of unique per-connection keys, which enables use of manual MKTs with automatically generated traffic keys as noted in Section 5.2.
MKTs的使用允许外部自动和手动键控。见第3节。该功能通过生成唯一的每连接密钥而得到增强，该密钥允许使用手动MKT和自动生成的流量密钥，如第5.2节所述。
d. Key management agnostic.
d. 密钥管理不可知。
The option should not assume or require a particular key management solution.
该选项不应假定或要求特定的密钥管理解决方案。
This is supported by use of a set of MKTs. See Section 3.
这通过使用一组MKT得到支持。见第3节。
5. Expected Constraints
5. 预期约束
A solution to revising TCP MD5 should also abide by typical safe security practices.
修改TCP MD5的解决方案还应遵守典型的安全实践。
a. Silent failure.
a. 无声的失败。
Receipt of segments failing authentication must result in no visible external action and must not modify internal state, and those events should be logged.
接收未通过身份验证的段必须不会导致任何可见的外部操作，并且不得修改内部状态，并且应记录这些事件。
This is supported - see Sections 7.3, 7.4, and 7.5.
这是受支持的-参见第7.3、7.4和7.5节。
b. At most one such option per segment.
b. 每个段最多一个这样的选项。
Only one authentication option can be permitted per segment.
每个段只能允许一个身份验证选项。
This is supported by the protocol requirements - see Section 2.2.
这得到协议要求的支持-见第2.2节。
c. Outgoing all or none.
c. 传出全部或无。
Segments out of a TCP connection are either all authenticated or all not authenticated.
TCP连接之外的段要么全部经过身份验证，要么全部未经身份验证。
This is supported - see Section 7.4.
这是受支持的-参见第7.4节。
d. Incoming all checked.
d. 所有来电都已检查。
Segments into a TCP connection are always checked to determine whether their authentication should be present and valid.
始终检查TCP连接中的段，以确定其身份验证是否应存在且有效。
This is supported - see Section 7.5.
这是支持的-参见第7.5节。
e. Non-interaction with TCP MD5.
e. 与TCP MD5不交互。
The use of this option for a given connection should not preclude the use of TCP MD5, e.g., for legacy use, for other connections.
对给定连接使用此选项不应排除对其他连接使用TCP MD5，例如，传统使用。
This is supported - see Section 8.
这是支持的-见第8节。
f. "Hard" ICMP discard.
f. “硬”ICMP丢弃。
The option should allow certain ICMPs to be discarded, notably Type 3 (destination unreachable), Codes 2-4 (transport protocol unreachable, port unreachable, or fragmentation needed and IP DF field set), i.e., the ones indicating the failure of the endpoint to communicate.
该选项应允许丢弃某些ICMP，特别是类型3（目标不可访问）、代码2-4（传输协议不可访问、端口不可访问或所需碎片和IP DF字段集），即指示端点通信失败的ICMP。
This is supported - see Section 7.8.
这是支持的-参见第7.8节。
g. Maintain TCP connection semantics, in which the socket pair alone defines a TCP association and all its security parameters.
g. 维护TCP连接语义，其中套接字对单独定义TCP关联及其所有安全参数。
This is supported - see Sections 3 and 9.
这是支持的-参见第3节和第9节。
Use of TCP-AO, like the use of TCP MD5 or IPsec, will impact host performance. Connections that are known to use TCP-AO can be attacked by transmitting segments with invalid MACs. Attackers would need to know only the TCP connection ID and TCP-AO Length value to substantially impact the host's processing capacity. This is similar to the susceptibility of IPsec to on-path attacks, where the IP addresses and SPI would be visible. For IPsec, the entire SPI space (32 bits) is arbitrary, whereas for routing protocols typically only the source port (16 bits) is arbitrary (typically with less than 16 bits of randomness [La10]). As a result, it would be easier for an off-path attacker to spoof a TCP-AO segment that could cause receiver validation effort. However, we note that between Internet routers, both ports could be arbitrary (i.e., determined a priori out of band), which would constitute roughly the same off-path antispoofing protection of an arbitrary SPI.
使用TCP-AO，就像使用TCP MD5或IPsec一样，会影响主机性能。已知使用TCP-AO的连接可以通过传输带有无效MAC的段而受到攻击。攻击者只需知道TCP连接ID和TCP-AO长度值，即可显著影响主机的处理能力。这类似于IPsec对路径攻击的敏感性，其中IP地址和SPI是可见的。对于IPsec，整个SPI空间（32位）是任意的，而对于路由协议，通常只有源端口（16位）是任意的（通常随机性小于16位[La10]）。因此，路径外攻击者更容易欺骗TCP-AO段，从而导致接收器验证工作。然而，我们注意到，在Internet路由器之间，两个端口都可以是任意的（即，预先确定带外），这将构成对任意SPI的大致相同的非路径反屏蔽保护。
TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets typically occur after peer crashes, either in response to new connection attempts or when data is sent on stale connections; in either case, the recovering endpoint may lack the connection key required (e.g., if lost during the crash). This may result in timeouts, rather than a more responsive recovery after such a crash. Recommendations for mitigating this effect are discussed in Section 7.7.
TCP-AO与TCP MD5一样，可能会禁止无连接重置。此类重置通常发生在对等崩溃后，响应新的连接尝试或在陈旧连接上发送数据时；在任何一种情况下，恢复端点都可能缺少所需的连接密钥（例如，如果在崩溃期间丢失）。这可能会导致超时，而不是在发生此类崩溃后进行响应更快的恢复。第7.7节讨论了缓解这种影响的建议。
TCP-AO does not include a fast decline capability, e.g., where a SYN-ACK is received without an expected TCP-AO and the connection is quickly reset or aborted. Normal TCP operation will retry and timeout, which is what should be expected when the intended receiver is not capable of the TCP variant required anyway. Backoff is not optimized because it would present an opportunity for attackers on the wire to abort authenticated connection attempts by sending spoofed SYN-ACKs without TCP-AO.
TCP-AO不包括快速下降功能，例如，在没有预期TCP-AO的情况下接收SYN-ACK，并且快速重置或中止连接。正常的TCP操作将重试并超时，这是当预期的接收器无论如何都不能使用所需的TCP变体时所期望的。退避未得到优化，因为它会使连线上的攻击者有机会通过发送不带TCP-AO的伪造SYN ACK来中止经过身份验证的连接尝试。
TCP-AO is intended to provide similar protections to IPsec, but is not intended to replace the use of IPsec or IKE either for more robust security or more sophisticated security management. TCP-AO is intended to protect the TCP protocol itself from attacks that TLS, sBGP/soBGP, and other data stream protection mechanisms cannot. Like IPsec, TCP-AO does not address the overall issue of ICMP attacks on TCP, but does limit the impact of ICMPs, as noted in Section 7.8.
TCP-AO旨在提供与IPsec类似的保护，但并不打算取代IPsec或IKE的使用，以实现更强健的安全性或更复杂的安全管理。TCP-AO旨在保护TCP协议本身不受TLS、sBGP/soBGP和其他数据流保护机制无法保护的攻击。与IPsec一样，TCP-AO并没有解决ICMP攻击TCP的总体问题，但确实限制了ICMP的影响，如第7.8节所述。
TCP-AO includes the TCP connection ID (the socket pair) in the MAC calculation. This prevents different concurrent connections using the same MKT (for whatever reason) from potentially enabling a traffic-crossing attack, in which segments to one socket pair are
TCP-AO在MAC计算中包括TCP连接ID（套接字对）。这可以防止使用同一MKT的不同并发连接（无论出于何种原因）潜在地启用流量交叉攻击，在这种攻击中，一个套接字对的段被删除
diverted to attack a different socket pair. When multiple connections use the same MKT, it would be useful to know that segments intended for one ID could not be (maliciously or otherwise) modified in transit and end up being authenticated for the other ID. That requirement would place an additional burden of uniqueness on MKTs within endsystems, and potentially across endsystems. Although the resulting attack is low probability, the protection afforded by including the received ID warrants its inclusion in the MAC, and does not unduly increase the MAC calculation or MKT management.
转移以攻击不同的套接字对。当多个连接使用同一个MKT时，了解一个ID的段不能（恶意或其他）在传输过程中被修改并最终被认证为另一个ID是很有用的。这一要求将给终端系统内的MKT带来额外的唯一性负担，并可能跨终端系统。尽管由此产生的攻击的概率很低，但通过包括接收到的ID而提供的保护保证其包含在MAC中，并且不会过度增加MAC计算或MKT管理。
The use of any security algorithm can present an opportunity for a CPU Denial-of-Service (DoS) attack, where the attacker sends false, random segments that the receiver under attack expends substantial CPU effort to reject. In IPsec, such attacks are reduced by the use of a large Security Parameter Index (SPI) and Sequence Number fields to partly validate segments before CPU cycles are invested validated the Integrity Check Value (ICV). In TCP-AO, the socket pair performs most of the function of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay attacks, isn't needed due to TCP's Sequence Number, which is used to reorder received segments (provided the sequence number doesn't wrap around, which is why TCP-AO adds the SNE in Section 6.2). TCP already protects itself from replays of authentic segment data as well as authentic explicit TCP control (e.g., SYN, FIN, ACK bits) but even authentic replays could affect TCP congestion control [Sa99]. TCP-AO does not protect TCP congestion control from this last form of attack due to the cumbersome nature of layering a windowed security sequence number within TCP in addition to TCP's own sequence number; when such protection is desired, users are encouraged to apply IPsec instead.
任何安全算法的使用都可能带来CPU拒绝服务（DoS）攻击的机会，在这种情况下，攻击者发送虚假、随机的数据段，受攻击的接收者会花费大量CPU精力来拒绝这些数据段。在IPsec中，通过使用大型安全参数索引（SPI）和序列号字段，在CPU周期被投入验证完整性检查值（ICV）之前部分验证段，可以减少此类攻击。在TCP-AO中，套接字对执行IPsec的SPI的大部分功能，并且由于TCP的序列号用于重新排列接收的段（如果序列号不环绕，这就是TCP-AO在第6.2节中添加SNE的原因），因此不需要用于避免重播攻击的IPsec序列号。TCP已经保护自己不受真实段数据以及真实显式TCP控制（例如，SYN、FIN、ACK位）的重放的影响，但即使是真实重放也可能影响TCP拥塞控制[Sa99]。TCP-AO不能保护TCP拥塞控制免受最后一种形式的攻击，这是因为除了TCP自身的序列号之外，还要在TCP中分层一个窗口安全序列号，这一点很麻烦；当需要此类保护时，鼓励用户改为应用IPsec。
Further, it is not useful to validate TCP's Sequence Number before performing a TCP-AO authentication calculation, because out-of-window segments can still cause valid TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is similarly not useful to add a separate Sequence Number field to TCP-AO, because doing so could cause a change in TCP's behavior even when segments are valid.
此外，在执行TCP-AO身份验证计算之前验证TCP的序列号是没有用的，因为窗口外段仍然可以导致有效的TCP协议操作（例如，ACK重传）[RFC793]。同样，向TCP-AO中添加单独的序列号字段也没有用，因为这样做可能会导致TCP行为发生变化，即使在段有效的情况下也是如此。
The TCP Authentication Option (TCP-AO) was assigned TCP option 29 by IANA action.
IANA操作为TCP认证选项（TCP-AO）分配了TCP选项29。
This document defines no new namespaces.
此文档未定义新名称空间。
To specify MAC and KDF algorithms, TCP-AO refers to a separate document [RFC5926].
为了指定MAC和KDF算法，TCP-AO参考单独的文档[RFC5926]。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[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月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]Floyd，S.，Mahdavi，J.，Mathis，M.，和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]Blanton，E.，Allman，M.，Fall，K.，和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 3517，2003年4月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724]Sangli，S.，Chen，E.，Fernando，R.，Scudder，J.，和Y.Rekhter，“BGP的优雅重启机制”，RFC 47242007年1月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS", RFC 4781, January 2007.
[RFC4781]Rekhter，Y.和R.Aggarwal，“带MPLS的BGP的优雅重启机制”，RFC 4781，2007年1月。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926]Lebovitz，G.和E.Rescorla，“TCP认证选项（TCP-AO）的加密算法”，RFC 5926，2010年6月。
[Ba10] Bashyam, M., Jethanandani, M., and A. Ramaiah "Clarification of sender behaviour in persist condition", Work in Progress, January 2010.
[Ba10]Bashyam，M.，Jethanandani，M.，和A.Ramaiah，“持续状态下发送者行为的澄清”，正在进行的工作，2010年1月。
[Bo07] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. Wheeler, "Authentication for TCP-based Routing and Management Protocols", Work in Progress, February 2007.
[Bo07]Bonica，R.，Weis，B.，Viswanathan，S.，Lange，A.，和O.Wheeler，“基于TCP的路由和管理协议的认证”，正在进行的工作，2007年2月。
[Bo09] Borman, D., "TCP Options and MSS", Work in Progress, July 2009.
[Bo09]Borman，D.，“TCP选项和MSS”，正在进行的工作，2009年7月。
[Ed07] Eddy, W., Ed., Bellovin, S., Touch, J., and R. Bonica, "Problem Statement and Requirements for a TCP Authentication Option", Work in Progress, July 2007.
[Ed07]Eddy，W.，Ed.，Bellovin，S.，Touch，J.，和R.Bonica，“TCP认证选项的问题陈述和要求”，正在进行的工作，2007年7月。
[Go10] Gont, F., "ICMP Attacks against TCP", Work in Progress, March 2010.
[Go10]Gont，F.，“针对TCP的ICMP攻击”，正在进行的工作，2010年3月。
[La10] Larsen, M. and F. Gont, "Transport Protocol Port Randomization Recommendations", Work in Progress, April 2010.
[La10]Larsen，M.和F.Gont，“运输协议端口随机化建议”，正在进行的工作，2010年4月。
[Le09] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Work in Progress, October 2009.
[Le09]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，正在进行的工作，2009年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007.
[RFC4808]Bellovin，S.，“TCP-MD5的关键变化策略”，RFC 4808，2007年3月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communications Review, V29, N5, pp71-78, October 1999.
[Sa99]Savage，S.，N.Cardwell，D.Weterral，T.Anderson，“具有不正常接收器的TCP拥塞控制”，ACM计算机通信评论，V29，N5，第71-78页，1999年10月。
[SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)", Specification SDN.401, Revision 1.2, July 12, 1988.
[SDNS88]安全数据网络系统，“安全协议4（SP4）”，规范SDN.401，修订版1.2，1988年7月12日。
[To07] Touch, J. and A. Mankin, "The TCP Simple Authentication Option", Work in Progress, July 2007.
[To07]Touch，J.和A.Mankin，“TCP简单身份验证选项”，正在进行的工作，2007年7月。
[To10] Touch, J., "A TCP Authentication Option NAT Extension", Work in Progress, January 2010.
[To10]Touch，J.，“TCP认证选项NAT扩展”，正在进行的工作，2010年1月。
[Wa05] Wang, X., H. Yu, "How to break MD5 and other hash functions", Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.
[Wa05]Wang，X.，H.Yu，“如何破解MD5和其他哈希函数”，Proc。IACR Eurocrypt 2005，丹麦，第19-35页。
[We05] Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, "TCP Message Authentication Code Option", Work in Progress, December 2005.
[We05]Weis，B.，Appanna，C.，McGrew，D.，和A.Ramaiah，“TCP消息验证代码选项”，正在进行的工作，2005年12月。
This document evolved as the result of collaboration of the TCP Authentication Design team (tcp-auth-dt), whose members were (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus Westerlund. The text of this document is derived from a proposal by Joe Touch and Allison Mankin [To07] (originally from June 2006), which was both inspired by and intended as a counterproposal to the revisions to TCP MD5 suggested in a document by Ron Bonica, Brian Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] (originally from September 2005) and in a document by Brian Weis [We05].
本文件是TCP认证设计团队（TCP auth dt）合作的结果，其成员（按字母顺序排列）：马克·奥尔曼、史蒂夫·贝洛文、罗恩·博尼卡、韦斯·埃迪、拉尔斯·艾格特、查理·考夫曼、安德鲁·兰格、埃里森·曼金、桑迪·墨菲、乔·图奇、斯利拉姆·维斯瓦纳坦、布赖恩·维斯和马格纳斯·韦斯特隆德。本文件的文本来源于Joe Touch和Allison Mankin[To07]（最初于2006年6月）的提案，该提案受Ron Bonica、Brian Weis、Sriran Viswanathan、Andrew Lange和Owen Wheeler[Bo07]在一份文件中建议的TCP MD5修订的启发，并旨在作为其反提案（最初于2005年9月）和Brian Weis[We05]的一份文件。
Russ Housley suggested L4/application layer management of the master key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the use of TCP's Initial Sequence Numbers (ISNs) in the traffic key computation and SNEs to avoid replay attacks, and Brian Weis extended the computation to incorporate the entire connection ID and provided the details of the traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and Brian Weis developed the master key coordination mechanism.
Russ Housley建议主密钥元组的L4/应用层管理。史蒂夫·贝洛文激励了凯伊德球场。Eric Rescorla建议在流量密钥计算和SNE中使用TCP的初始序列号（ISN）以避免重播攻击，Brian Weis扩展了计算以包含整个连接ID，并提供了流量密钥计算的详细信息。马克·奥尔曼、韦斯·艾迪、拉尔斯·艾格特、特德·费伯、罗斯·霍斯利、格雷戈里·勒博维茨、蒂姆·波尔克、埃里克·雷科拉、乔·图奇和布赖恩·韦斯开发了主密钥协调机制。
Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other members of the TCPM WG also provided substantial feedback on this document.
阿尔弗雷德·霍恩斯、查理·考夫曼、亚当·兰利和TCPM工作组的许多其他成员也对本文件提供了大量反馈。
This document was originally prepared using 2-Word-v2.0.template.dot.
本文件最初使用2-Word-v2.0.template.dot编制。
Authors' Addresses
作者地址
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676美国加利福尼亚州玛丽娜·德雷海军部路90292-6695号。
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Allison Mankin Johns Hopkins Univ. Baltimore, MD U.S.A.
美国马里兰州巴尔的摩艾利森·曼金·约翰·霍普金斯大学。
Phone: 1 301 728 7199
EMail: mankin@psg.com
URL: http://www.psg.com/~mankin/
Phone: 1 301 728 7199
EMail: mankin@psg.com
URL: http://www.psg.com/~mankin/
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 U.S.A.
Ronald P.Bonica Juniper Networks 2251美国弗吉尼亚州赫恩登市企业园大道20171。
EMail: rbonica@juniper.net
EMail: rbonica@juniper.net