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
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.
この文書は、RFC 2385（TCP MD5）のTCP MD5署名オプションを廃止TCP認証オプション（TCP-AO）を指定します。 TCP-AOは、より強力なメッセージ認証コード（MAC）の使用を指定しても長寿命のTCP接続のためにリプレイに対する保護、およびTCP MD5よりもTCP接続とセキュリティの関連についての詳細を提供します。 TCP-AOは、静的マスターキータプル（MKT）構成または外部のいずれかと互換性があり、アウト・オブ・バンドMKT管理機構。いずれの場合も、TCP-AOはまた、MKTに由来するトラフィックキーを使用して、接続の繰り返しインスタンス間で同じMKTを使用する場合の接続を保護し、エンドポイント間のMKT変化を調整します。結果は、（使用されるように、例えば、BGPおよびLDP）長寿命の接続を保護するよう、TCP MD5を使用する現在のインフラストラクチャをサポートするように意図され、そして最小限の他のシステムおよび操作上の変更とMACのより大きなセットをサポートします。 TCP-AOは、TCP-AOおよびTCP MD5を同時に使用することを許可されることはありませんにもかかわらず、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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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のIPv4擬似ヘッダ、TCPヘッダ、およびTCPデータを含むTCPセグメントを、認証TCPオプションです。これは、BGPデータやTCP接続自体[RFC2385] [RFC4953]の堅牢性に影響を与える可能性が偽装されたTCPセグメントからのBGPセッションを保護するために開発されました。
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セグメントが（7.6節を参照）、このようなネゴシエーションを処理するのに十分な空き容量が不足しているので、それはしかし、TCPのバンドで処理される完全な暗号鍵管理のために提供されていません。この文書では、より一般的な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 MD5で保護された接続は、TCP-AOに移行することはできません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
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は、BGPやLDPなどのルーティングプロトコルのための長命接続を保護するなど、TCP MD5の現在の用途をサポートすることを目的としています。また、プロキシキャッシュ間で使用されるかもしれないとして、たとえば、任意の長寿命の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の使用を置き換える（ひいては廃止）することを意図しています。セクション1.3にまとめたようにTCP-AOは、TCP MD5の機能を強化します。この文書では、全体的なことをお勧めします。
>> 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).
>> TCP-AOは、TCP認証による保護が必要とされるIPsecがサポートされていないいずれかのために、実装されるべき、または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は、TCPコネクション[RFC4301] [RFC4306]を保護するためのIPsecスイート（IPsecとインターネット鍵交換プロトコル（IKE））の使用に代わるものではありません。具体的な違いは、セクション1.3に記載されています。実際には、我々は、パラメータのネゴシエーション、セッションキー交渉、または再入力のための既存のサポートのIKEのレベルが所望され、特にIPsecと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）またはSecure起源BGP（soBGP）[Le09]、または唯一のTCPデータストリームを保護する任意の他のメカニズムの使用に代わるものではありません。 TCP-AOは、TCP接続自体[RFC4953]を無効からの攻撃を防ぐ、輸送層を保護します。データ・ストリーム・メカニズムは、TCPセグメントの内容のみを保護し、接続が影響を受けているときに破壊することができます。これらのデータ保護プロトコルの一部 - 特にTLS - TCP-AOよりも鍵管理および認証メカニズムのより豊富なセットを提供しますので、異なる方法でデータストリームを保護します。 TCP-AOは、お互いの強みを補完するために、これらのデータ・ストリームの保護と一緒に使用することができます。
This document replaces TCP MD5 as follows [RFC2385]:
[RFC2385]を次のようにこのドキュメントでは、TCP MD5を置き換えます。
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は別の文書で指定されたMACとTCP MD5の単一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 MD5における重要な変更がチェンジ時輸送中にセグメントを失うか、明示的なキーIDを欠いているので、鍵の使用の重複の間に各受信セグメント上の複数のキーを試す必要とすることができ、一方、さらに、TCP-AOは、ゼロセグメント損失がキー変更をサポート。 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 TCP-AOは、TCP MD5よりも2バイト短い（16のバイト全体ではなく18）（96ビットMACを使用して）最初に指定されたデフォルトの場合です。
TCP-AO differs from an IPsec/IKE solution as follows [RFC4301][RFC4306]:
[RFC4306]、[RFC4301]を以下のようにTCP-AOは、IPsec / IKE溶液とは異なります：
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は、[Ed07]（IPアドレスとポート番号）TCPソケットペアを再利用する場合であっても、計算されたMACの変更を強制します。
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メッセージは、構成に応じて、IPsecを使用するときに認証されてもよい）ICMPメッセージを認証しません。
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-AOを説明し、比較のためにTCP MD5のレビューを提供する29のTCPオプションの種類の値を使用します。
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) |
+-------------------+
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ビット[RFC1321]の完全なMD5ダイジェストを使用して、種類及び長さフィールド（各1バイト）は、次の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送信元および宛先アドレス、プロトコル番号、及びセグメント長）。
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の機能のスーパーセットを提供し、[SDNS88] SP4の精神に最小です。図2に示すように、TCP-AOは、TCP MD5、KeyIDをフィールド、及びRNextKeyIDフィールドに新しい種類フィールド、及び同様の長さフィールドを使用します。
+------------+------------+------------+------------+
| Kind=29 | Length | KeyID | RNextKeyID |
+------------+------------+------------+------------+
| MAC ...
+-----------------------------------...
...-----------------+
... 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長さ：種類、長さ、KeyIDを、RNextKeyID、及びMACフィールドを含むバイト単位のオプションの長さを示す符号なしの1バイトのフィールド。
>> 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未満であると、TCPセグメントを捨てなければなりませんより大きいまたは4に等しくなければなりません。
>> The Length value MUST be consistent with the TCP header length. When the Length value is invalid, TCP MUST discard the segment.
>>長さ値は、TCPヘッダ長と一致していなければなりません。 Length値が無効である場合は、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ヘッダに示されるように部分的検証は、TCPヘッダの先頭からのオフセットTCP-AOに加えTCP-AOの長さは、TCPヘッダのサイズを超えないように、唯一のTCP-AOを確認するために制限することができますオフセットフィールド。
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を：（セクション3.1で定義されるようにMKT）マスターキータプルを示す符号なしの1バイトのフィールドは、このセグメントを認証MACを生成するために使用されたトラフィックキーを生成するために使用されます。
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節でさらに議論する接続時の効率的なキーの変更をサポートしています。それはランダムである必要はなく、またいかなる予約値があります - 鍵IDは何の暗号化の性質を持っていないことに注意してください。
>> 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.
>>鍵ID値は、接続の両方向で同じであってもよいが、である必要はありませんし、彼らは特別な意味はありません。
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).
これはMKTsは、あらかじめ、そのセット全体KeyIDsを調整することなく、デバイスのセットにインストールすることができ、新しいデバイスは、後KeyIDsのリナンバリングを必要とせずMKTsのグループを使用してそのセットに追加されることを可能にします。 （セクション3.1で述べたように）MKTパターンによって指定されたデバイスのセット間で使用され、すなわちMKTのTCPソケットのペアにワイルドカードで使用される場合、これらの2つの機能は、特に重要です。
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：送信側の準備ができているMKTを示す符号なしの1バイトフィールドは、すなわち、受信したセグメントを、認証するために使用する、鍵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バイト）であるが、認証されたセグメントのヘッダに収まる任意の長さが許容されます。 MAC計算は、セクション5.1でさらに説明されます。
>> Required support for TCP-AO MACs is defined in [RFC5926]; other MACs MAY be supported.
>> TCP-AOのMACに必要なサポートは、[RFC5926]で定義されています。他の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オプションの[Bo09]の場合のようにTCP-AOの使用は、TCPの宣伝最大セグメントサイズ（MSS）には影響しませんのでご注意ください。
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.
マスターキータプル（MKTs）とトラフィックキー：TCP-AOは、着信と発信のセグメントを認証するためのキーの二組に依存しています。 MKTsは、固有のトラフィックキーを導出するために使用され、キーイングそれらトラフィックキーを生成するために使用される材料、ならびにトラフィックキーが使用されるの下に関連するパラメータを示すが含まれます。そのようなパラメータは、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）は、1つの以上の接続に関連付けられて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 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).
O TCPオプションフラグ。このフラグは、TCP-AO以外のTCPオプションがMACの計算に含まれるか否かを示します。オプションが含まれている場合はTCP-AOのMACフィールドはゼロにして、すべてのオプションの内容は、注文の存在に、MACに含まれています。オプションが含まれていない場合は、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のID。 TCP-AOのKeyIDを又はRNextKeyIDで使用される値。同時使用（KeyIDを）でMKTsを区別するために、ならびにMKTsが反対方向（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.
- SENDIDとRECVID - 各MKTは、2つのIDを持っています。 SENDID発信セグメントのTCP-AOオプションのKeyIDをとして挿入され、そしてRECVID着信セグメントのTCP-AO KeyIDを照合します。これら2つのIDのこれらおよび他の使用は、セクション7.4および7.5にさらに記載されています。
>> 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.
TCP状態は、接続確立時に調整されているため、MKT成分値は、接続中に変更することはできません。 TCP接続が確立された後、その状態を変更するためのハンドシェイクを欠いています。
>> The set of MKTs MAY change during a connection.
>> MKTsのセットは、接続中に変更されることがあります。
MKT parameters are not changed. Instead, new MKTs can be installed, and a connection can change which MKT it uses.
MKTパラメータは変更されません。代わりに、新しいMKTsをインストールすることができ、接続は、使用MKTどの変更することができます。
>> The IDs of MKTs MUST NOT overlap where their TCP connection identifiers overlap.
そのTCPコネクション識別子が重複するところ>> MKTsのIDが重複してはなりません。
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.
この文書では、MKTsがユーザーまたはプロセスによって作成される方法を扱っていません。特定の接続に影響を与える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の）に由来するキーです。接続は、未知の値（例えば、ISNをまだ調整されていない）のためにゼロを代入し、使用して、同じ情報が確立される前にセグメントを交換しました。
A single MKT can be used to derive any of four different traffic keys:
単一MKTは、4つの異なるトラフィックキーのいずれかを導出するために使用することができます。
o Send_SYN_traffic_key
O Send_SYN_traffic_key
o Receive_SYN_traffic_key
O Receive_SYN_traffic_key
o Send_other_traffic_key
O Send_other_traffic_key
o Receive_other_traffic_key
O Receive_other_traffic_key
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キーの一方のみが典型的に使用されているため、指定された接続は、典型的には、これらのキーの3つだけを使用します。接続が「同時オープン」[RFC793]を通過する場合にのみ、すべての4が使用されています。
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は、4つのトラフィックキーのいずれかを導出するために使用することができますが、唯一の実際の接続のセグメントを処理するために必要なキーを計算する必要があります。 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 |
+------------------+ +------------------+ +------------------+
Figure 3: Relationship between MKTs and Traffic Keys
図3：市場と交通のキーとの関係
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セグメントが正確に一致する1 MKTことが必要です。発信セグメントがMKTと一致する場合、TCP-AOが使用されます。一致が発生していない場合は、TCP-AOは使用されません。 MKTsが変更されるとき、複数のMKTsは、例えば、単一の発信セグメントと一致してもよいです。 （他の場所で述べたように）それらMKTs競合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セグメントは、セグメントのソケットのペアによって示される最大1つの所望のMKTを、一致しなければなりません。セグメントは、所望のように正確に一つMKTが指示されていれば、複数MKTsを一致させることができます。セグメント内の他の情報は、複数MKTsが一致したときに所望の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.
我々は、複数のMKTsの中から選択するのに使用されるメカニズムは、TCP-AOが認証することを情報のみを使用することをお勧めします。 MKTsはTCP-AO以外のオプションは、MAC計算では無視されていることを示すことがありますので、我々は、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は正確に一つのMKTと一致しなければならないなど、着信TCPセグメントは、セグメントのソケットペアとその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.
KeyIDをフィールド - 着信セグメントは、複数のマッチングMKTsの中から選択するためのTCP-AO内部インジケータを含みます。 TCP-AOは、MKTの変更はTCP-AOキーチェンジ調整メカニズムを使用してコーディネートすることができるように単独の鍵IDは、複数の一致MKTsを区別するために使用されている必要があります。
>> 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（7.4節、ステップ2.F参照）KeyIDをとして発信セグメントに挿入された発信セグメントを認証するために使用されます。 MKT TCP接続識別子とMKT RECVID照合として受信セグメントは、セグメントとそのTCP-AO KeyIDを（セクション7.5、ステップ2.C参照）に対応するMKTを使用して認証されています。特定の接続上の任意の時点で一つだけcurrent_keyがあります。
>> Every TCP connection in a non-IDLE state MUST have at most one current_key specified.
>>非アイドル状態のすべてのTCP接続は最大で1つcurrent_key指定を持たなければなりません。
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_key - MKTは、現在、そのRECVIDはRNextKeyIDとして発信セグメント（セクション7.4、ステップ2.D参照）に挿入される着信（受信）セグメントのために好ましいです。
>> Each TCP connection in a non-IDLE state MUST have at most one rnext_key specified.
>>非アイドル状態の各TCP接続は最大1つのrnext_key指定を持たなければなりません。
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.シーケンス番号拡張（SNES）のペア。 6.2節で説明したようにSNESは、リプレイ攻撃を防ぐために使用されています。各SNEは、接続確立時にゼロに初期化されます。 MAC計算におけるその使用は、セクション5.1に記載されています。
4. One or more MKTs. These are the MKTs that match this connection's socket pair.
4.一つ以上のMKTs。これらは、この接続のソケットのペアに一致するMKTsあります。
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で説明したようにMKTsは、各接続に一意トラフィックキーを作成するために、一緒に接続の他のパラメータと、使用されています。これらのトラフィックキーは、計算後にキャッシュすることができ、対応する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アルゴリズムと呼ばれ、プロトコル[RFC5926]から独立アルゴリズム要件を更新容易にするために、別の文書で指定されています。 TCP-AOはまた、それぞれの接続のためのユニークなトラフィックキーに、接続で共有することができMKTsを、変換するために、暗号化アルゴリズムを使用しています。これらは、鍵導出関数（KDFs）と呼ばれ、[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_alg（traffic_key、メッセージ）
INPUT: MAC_alg, traffic_key, message
INPUT：MAC_alg、traffic_key、メッセージ
OUTPUT: MAC
OUTPUT：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では、これはセクション5.1で説明したように、IPの擬似ヘッダとTCPヘッダオプションで付加TCPセグメントです。
o MAC - the fixed-length output of the MAC algorithm, given the parameters provided.
提供されたパラメータ与えられたMACアルゴリズムの固定長出力、 - O 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].
接続にMACの計算に用いられるMACアルゴリズムは[RFC5926]で定義ごとに、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.
TCP-AOとの使用のために強制的に実装MACアルゴリズムは別個RFC [RFC5926]に記載されています。これは、TCP-AO仕様は変更はの進化し続ける世界の結果として、それに関連するアルゴリズムとそのラベル（ユーザーインターフェースまたは自動MKT管理プロトコルで使用されるかもしれないよう）に必要とされている場合でも、IETF標準化過程に沿って進行することができます暗号。
>> 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 |
+--------+--------+--------+--------+
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のいずれかでのTCPチェックサム[RFC793] [RFC2460]のために使用するのと同じようです。
+--------+--------+--------+--------+
| 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 |
+--------+--------+--------+--------+
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オプションフラグは、TCPオプションがMACに含まれているかどうかを示します。含まれる場合、唯一の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オプションが含まれていない場合は、TCP-AOを除くすべてのTCPオプションは、MAC処理から省略されています。ここでも、TCP-AO MACフィールドは、MAC処理のためにゼロにされます。
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アルゴリズムはHMACsは、[RFC2403] [RFC2104]を行うと、例えば、トラフィックキーを使用する方法を示します。 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のトラフィックキーは、キー導出関数を使用してMKTs（KDFs）に由来しています。 TCP-AOで使用KDFsは、次のインタフェースを持っています：
traffic_key = KDF_alg(master_key, context, output_length)
traffic_key = KDF_alg（master_keyに、コンテキスト、OUTPUT_LENGTH）
INPUT: KDF_alg, master_key, context, output_length
INPUT：KDF_alg、master_keyに、コンテキスト、OUTPUT_LENGTH
OUTPUT: traffic_key
OUTPUT：traffic_key
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 - MKTに示すように、トラフィックキーを構成するのに使用される基本的なビルディング・ブロックである特定の鍵導出関数（KDF）。 [RFC5926]に記載されているように、これは指定されています。
o Master_key - The master_key string, as will be stored into the associated MKT.
関連MKTに格納されるようにmaster_keyに列、 - O master_keyに。
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]で指定されるように、traffic_keyを構築する際に入力として使用されるコンテキスト。この状況は、KDFへの生の入力を作成するために、他の情報と組み合わせて、使用される特定の方法はまた、[RFC5926]でさらに説明されます。
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].
OUTPUT_LENGTH O - 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 - セクション5.1で説明したようにKDFの所望の出力は、長さOUTPUT_LENGTHの、MACアルゴリズムへの入力として使用されます。
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への入力として使用されるコンテキストは、接続のエンドポイントの初期シーケンス番号（ISNの）とのTCPソケットのペアを組み合わせます。このデータは、さらに多くの異なる接続間またはソケットのペアを共有繰り返し接続で使用MKTから、その接続のためのユニークなトラフィックキーを生成するために、TCP-AOを可能各TCP接続インスタンスに固有のものです。ユニークなトラフィックキーは、外部キーの管理プロパティに頼らずに生成されます。 KDFコンテキストは、図7および8に定義されています。
+--------+--------+--------+--------+
| 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 |
+--------+--------+--------+--------+
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'dされていないことができて、領収書の上でドロップされていたであろう。
>> 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のための4つの異なるトラフィックキーまで使用することを意味します：
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アルゴリズムは、ソース（S）と宛先IPアドレス、TCPポート、およびISNの（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
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].
>>エンドポイントは、[RFC1948]のように、例えば、擬似ランダムISNを選択すべきです。
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が知られていないが、2つのエンドポイントは、セグメントを認証するために十分な情報を持っていない可能性がある場合にセグメントは、そのようなエンドポイント再起動後など、放出される他の場合があります。これは、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.
我々は、合理的なマスター鍵長の使用を含む適切なMKTsを生成する限られたトラフィックキーの共有、および使用MKTの持続時間を制限するための公知の技術を適用するTCP-AOのユーザーを促す[RFC3562]。 5.2節で提案されているように、これはまた、接続ごとのナンスの使用を含みます。
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は、新しいMKTsがどちらのプロトコルまたは手動手順[RFC4808]を経由して、帯域外で交渉と協調している鍵の変更をサポートしています。新MKTの使用は、両方のTCPエンドポイントを更新するために、アウトオブバンドメカニズムを使用して調整されています。単一MKTが一度に使用される場合、無効MKTsの一時的な使用は、廃棄されたセグメントにつながる可能性があり、 TCPはすでに、このような水滴に強いものの、TCP-AOは、このようなドロップを避けるために、鍵IDフィールドを使用しています。所与の接続は、KeyIDをフィールドはシーケンス内MKTsの高価な試行錯誤試験の必要性を回避するために、セグメントに使用されるトラフィックキーに対応MKTを識別するために使用される複数のマッチングMKTsを有することができます。
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は、6.1節で説明した明示的なMKTの調整メカニズムを提供します。そのような機構は、新しいMKTsがインストールされている場合に有用である、又はMKTsが変更された場合、インストールMKTsを使用開始する時を決定します。
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.
ユーザーは、適切なキーの長さ（12〜24バイト）を使用すると、複数のBGPピアリング手配間MKTsを共有避けるために、特に、TCP MD5 [RFC3562]を使用して鍵管理のための助言の精神次MKTsを管理することをお勧めします。
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.
MKTsは宿主内、またはホスト内のソケットのペアの異なるインスタンス間で異なるソケットのペアで再利用することができます。いずれの場合も、再生保護が維持されています。
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 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.
TCPソケットのペアをMACで、だけでなく、トラフィック鍵の生成に含まれているため、異なるソケットのペアで再利用MKTsは、リプレイ攻撃を有効にすることはできません。接続のISNは、トラフィック鍵生成アルゴリズムに含まれ、ISNのペアが有用期間にわたり繰り返すことはほとんどありませんされているので、与えられたソケットペアの繰り返しインスタンス間で再利用MKTsは、リプレイ攻撃を有効にすることはできません。
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は、長寿命の接続中にリプレイ攻撃を防ぐために一連番号拡大（SNES）を使用しています。明示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は特にだけ手動キー入力が利用できる環境では、効率的な使用をサポートするためのメカニズムが追加されます。これらは、（KDFを介して）（KeyIDをフィールドを介して）複数の同時MKTsを支持するためのユニークな接続ごとのトラフィックキーを生成するための前述の機構を含みます。このセクションでは、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接続は、各セグメントの方向（着信、発信）に指定された複数MKTsを有していてもよいです。 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を削除する際に決定することは、セキュリティ上の問題です。無効なMKTsは削除されることが期待されます。私たちは、この鍵管理操作考慮するとして、TCP-AOは、それらの除去を調整するメカニズムを提供していません。
New MKT use is coordinated through two ID fields in the header:
新MKTの使用はヘッダ内の2つのIDフィールドを通じて調整されます。
o KeyID
O鍵ID
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情報を表します。すなわち、セグメント受信機がMKTs（したがってそのKeyIDsと関連するトラフィックキー）を切り替えることときに知ることができるように、セグメントの送信者は、それが受信する将来のセグメントの準備ができて着信MKTを指示するための方法です。これはMKTのRECVID着信セグメントの所望示します。
There are two pointers kept by each side of a connection, as noted in the per-connection information (see Section 4):
接続ごとの情報（セクション4を参照）に記載されているように、接続のそれぞれの側が保持二つのポインタがあります。
o Currently active outgoing MKT (current_key)
O現在アクティブの発信MKT（current_key）
o Current preference for incoming MKT (rnext_key)
着信MKT（rnext_key）のためのO現在の優先
Current_key indicates an MKT that is used to authenticate outgoing segments. Upon connection establishment, it points to the first MKT selected for use.
Current_key発信セグメントを認証するために使用される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).
使用可能な状態と好ましい着信MKTにRnext_keyポイント。コネクション確立時に、これは現在アクティブな着信MKTを指します。新しいMKTsがインストールされている場合には、変更することができる（例えば、いずれかの自動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_keyは手動ユーザーの介入やMKT管理プロトコルの動作によって変更されます。これは、TCP-AOによって操作されていません。 7.5節にセグメント処理の説明で説明したように受信したTCPセグメントを処理する際Current_keyはTCP-AOによって更新されます。アルゴリズムはcurrent_keyは、その後、新しいMKTに変更（「バックアップ」として知られている）以前に使用MKTに戻って変更することができますことに注意してください。並べ替えが低下をもたらさないので、これは、セグメントが順序が狂って受信され、TCP-AOの特徴であると考えられるMKTの変更時に発生することができます。以前に使用MKTsの再利用を回避する唯一の方法は、それはもはや許さ考慮した場合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 differentiate these legitimate replays from each other, and so it adds a 32-bit Sequence Number Extension (SNE) for transmitted and received segments.
TCPは、長寿命の接続のために、ロールオーバーを繰り返して32ビットのシーケンス番号を、使用しています。これは意図的かつ合法的に接続内で再生されてTCPセグメントにつながる可能性があります。 TCP-AOは、リプレイ攻撃を防止し、従って互いからこれらの正当なリプレイを区別する方法を必要とし、それを送信し、受信セグメントの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は、両方ともゼロに初期化。これらのSNESの意図は、64ビットの全体的なシーケンス番号空間を提供するために、一緒にTCPの32ビットのシーケンス番号と、です。
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は64ビットにTCPのシーケンス番号を拡張することによって実現することができます。 SND.SNEは、その数の上面（上位）32ビットであろう。受信されたセグメントは、TCP-AOは、64ビットの番号空間の使用をエミュレートし、正しく受信された32ビットのシーケンス番号と現在の接続コンテキストからRCV.SNEとしてその数の適切な上位32ビットを推定する必要があります。
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.
RCV.SNE、SND.SNE、あるいはその両方に使用することができるSNESの実装は、この文書で指定されていませんが、1つの可能な方法がここに記述されています。
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):
下記のようにゼロに初期化全て、2つの必須（SND.SNE、RCV SNE）としてSNES、および追加の変数との実装を考えるだけでなく、現在の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
SND.SNEを増加することを示しO SND.SNE_FLAG、
o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE
RCV.SNEを増加することを示しO RCV.SNE_FLAG、
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;
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の説明を増強することを意図し、そのプレゼンテーションは結果[RFC793]とRFC 793のことを反映しています。
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のユーザ・インタフェースは、CLOSE、STATUS、およびコマンドを中止し、RECEIVE、SENDは、アクティブおよびパッシブOPENをサポートしています。それはTCPに適用されるTCP-AOは、このインタフェースを変更しませんが、インターフェースのいくつかのコマンドまたはコマンド・シーケンスは、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ユーザインタフェースがMKTsを設定するだけでなく、アクティブであるMKTs管理するための継続的な接続を可能にすることを可能にするように拡張されることを必要とします。 MKTsは、接続確立の前に設定する必要があり、そしてMKTsのセットは、接続中に変更することができます。
>> 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.
MKTを構成することができるように>> TCP OPEN、またはアクティブまたはパッシブオープン状態になるように接続を設定するコマンドのシーケンスは、拡張されなければなりません。
>> 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接続のMKTsのセット（すなわち、しない閉じた状態で）を変更することを許容しなければなりません。
The MKTs associated with a connection need to be available for confirmation; this includes the ability to read the MKTs:
接続に関連付けられたMKTsは、確認のために利用できるようにする必要があります。これはMKTsを読み取る能力が含まれています。
>> TCP STATUS SHOULD be augmented to allow the MKTs of a current or pending connection to be read (for confirmation).
>> TCPステータスは（確認のため）現在または保留中の接続のMKTsを読むことができるように拡張されるべきです。
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.
好適発信MKT（current_key）および/または接続の好ましい着信MKT（rnext_key）を示すことができるように>> TCP送信、またはSENDもたらすコマンドのシーケンスは、拡張されなければなりません。
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.
それによって、長さゼロのバッファを送信することによって、または非送信インターフェース（UNIXの場合、例えば、ソケットオプション）を使用することによって達成することができるデータが送信されていないにも発信アクティブMKT（current_key）を、変更することが有用であり得ます実装上。
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:
受け取った最近のセグメント鍵IDと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).
最近受信セグメントのKeyIDをとRNextKeyIDは帯域外ユーザに利用可能であるように>> TCP受信、または受信をもたらす一連のコマンド、例えば、受信するために追加のパラメータとして、またはSTATUSを介して（拡張しなければなりませんコール）。
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-RECEIVED、ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT、およびCLOSEDをLISTEN含みます。
>> 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.
>>すべてのTCPセグメントは、TCPコネクション識別子を一致させるためMKTsのセットに対してチェックしなければなりません。
>> 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と一致していません。この構成の初期のデフォルトは静かな接続を受け入れるようにすべきである（SHOULD）。これが所望でない場合、MKTは、このような接続を一致させるために含めることができ、または接続がTCP-AOが必要であることを示すことができます。代替的に、構成はMKTに一致しないAOオプションを使用してセグメントを廃棄するように変更することができます。
>> 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.
>>サイレント破棄イベントは警告としてユーザに通知する必要があり、静かなイベントが警告としてユーザに通知されるかもしれない受け入れます。どちらの警告は、利用可能な場合、STATUSインタフェースを介してアクセス可能でなければなりません。どちらの信号が非同期であってもよいし、しかしそうならば、彼らは、レート制限しなければなりません。どちらの信号が記録されることがあります。ロギングが律速にも許可する必要があります。
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内で交渉されていない接続上のTCP-AOの使用に注意してください。 TCP-AOは、他の手段を介して要求されるときを決定するために（例えば、バンドのうち、手動または鍵管理プロトコル）とその要件を強制するために受信機の責任です。
The following procedure describes the modifications to TCP to support inserting TCP-AO when a segment departs.
次の手順は、セグメントが離れるときにTCP-AOを挿入支持するためにTCPへの変更を記載しています。
>> 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.
>>そのMACの計算は、他のTCPオプションの値を含む可能性があるため、TCP-AOは、送信セグメントに処理された最後のTCPオプションでなければならないことに注意してください。
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.
i. If there is no matching MKT, omit TCP-AO. Proceed with transmitting the segment.
私。一致する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.
II。マッチング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は、接続のために使用されているかどうかを判断し、接続ごとのパラメータからcurrent_key値によって示されるようにMKTを使用する（セクション4を参照）、ステップ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.
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にキャッシュ）current_keyで指されるよう、適切なトラフィックキー、すなわちを決定します。すなわち、SYNセグメントのsend_SYN_traffic_key及び他のセグメントのsend_other_traffic_keyを使用することです。
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。 （6.1節で述べたように）rnext_keyポインタが示すようRNextKeyIDを決定し、そして（TCP-AO鍵IDとしてrnext_keyのMKTのRECVIDを使用して）TCP-AO RNextKeyIDフィールドに挿入します。
e. Compute the MAC using the MKT (and cached traffic key) and data from the segment as specified in Section 5.1.
電子。 MKT（キャッシュされたトラフィックキー）とセクション5.1で指定されたセグメントからのデータを使用してMACを計算します。
f. Insert the MAC in the TCP-AO MAC field.
F。 TCP-AO MACフィールドにMACを挿入します。
g. Proceed with transmitting the segment.
グラム。セグメントの送信を続行します。
The following procedure describes the modifications to TCP to support TCP-AO when a segment arrives.
次の手順は、セグメントが到着したときにTCP-AOをサポートするために、TCPの変更を記載しています。
>> 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.
>>そのMAC計算は、TCPオプションの処理中に変更することができ、他のTCPオプションの値を含む可能性があるため、TCP-AOは、着信セグメント上で処理最初の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.
>> TCP-AOのチェックが必要なTCP-AOを欠く受諾のSYNを避けるために、すべての着信のSYNのために実行しなければなりませんので注意してください。他のセグメントは、TCP-AOがTCBで必要とされているかどうかをキャッシュすることができます。
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.
i. If there is no matching MKT, remove TCP-AO from the segment. Proceed with further TCP handling of the segment.
私。一致する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.
II。マッチングMKTがある場合、必要に応じて、次に（セクション4を参照）ごとの接続パラメータを設定します。ステップ2に進みます。
a. Check that the segment's TCP-AO Length matches the length
indicated by the MKT.
i. If the lengths differ, silently discard the segment. Log and/or signal the event as indicated in Section 7.3.
私。長さが異なる場合、サイレントセグメントを捨てます。ログインして、/または第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で説明した（そしておそらくTCBにキャッシュされた）としてMKTからセグメントのトラフィックキーを決定します。すなわち、SYNセグメントのreceive_SYN_traffic_key及び他のセグメントのreceive_other_traffic_keyを使用することです。
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。セクション5.1に示されているようにMKT（およびその派生トラフィックキー）を使用して、セグメントの部分セグメントの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.
私。計算されたMACは、TCP-AO MACフィールドの値と異なる場合、サイレントセグメントを捨てます。ログインして、/または第7.3節に示されるように、イベントを知らせます。
e. Compare the received RNextKeyID value to the currently active outgoing KeyID value (current_key MKT's SendID).
電子。 （MKTのSENDID current_key）現在アクティブな送信鍵ID値に受信RNextKeyID値の比較。
i. If they match, no further action is required.
私。それらが一致した場合、それ以上のアクションは必要ありません。
ii. If they differ, determine whether the RNextKeyID MKT is ready.
II。それらが異なる場合は、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).
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にcurrent_key設定してください。
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実装は無効TCP-AOフィールドと偽装されたセグメントによって発生するオーバーヘッドを減らすためにMACを計算する前に、セグメントの長さフィールドを検証することが示唆されます。
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で指定されていません。それはランダム想定していないため、鍵IDは、それ自体の接続検証に使用することができないことに注意してください。
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を使用して、TCPヘッダスペース[RFC5926]の16バイトの合計を使用します。 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は、未知のセグメントを無視しているので、しかし、後方互換性を壊すことなく、SYNのオプション空間を拡張することはできません。
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ビットのデータは、オフセットヘッダ開始後のオプションは20バイトのヘッダを含む、60バイト（15 32ビットワード）を終了することを必要とします。これは、他の用途のためにせいぜい25を残して、15（下記）は、現在の実装では期待されたオプション、40のバイトを残します。 TCP-AOは、（最大で別の2つのバイトを消費する可能性が実装依存のアライメントパディングに応じて）追加のSYNオプションの9つのバイトを残して、16のバイトを消費します。
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（10bytes）[RFC2018]、[RFC3517]（18のバイトD-SACK [RFC2883]であれば）
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
タイムスタンプは10これは、10が単一のSACKブロックのために使用される14のバイトを、葉を消費するのTCP-AOは、他のオプションのための24バイトの合計を残し、非SYNセグメント内の16のバイトを消費し続けます。 2つの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のMACの長さが固定され、十分なオプション空間を残すには大きすぎるので、D-SACKは、タイムスタンプの存在下で、TCP MD5でサポート可能ではないことに注意してください。
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 MD5が意図したのと同様の用途のための接続レベルでTCPを認証するための願望と一致していると信じています。
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キープアライブ[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キープアライブの使用は、キーが失われている接続が有限の時間後に終了されることが保証されます。同様の効果は、BGPキープアライブ[RFC4271]を用いて、例えば、アプリケーション層で達成することができます。キープアライブのいずれかの種類、状態は、このような場合には一掃された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:
キープアライブは、接続が再起動してもドロップされることを保証するが、これはいくつかのプロトコルに有害な影響を持つことができます。具体的には、BGPはBGPキープアライブを使用することによって引き起こされる場合でも、そのような接続滴に乏しい反応します。 「グレースフルリスタートは、」この効果[RFC4724]を対処するために導入され、MPLS [RFC4781]でBGPをサポートするように拡張されました。結果として：
>> 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を使用することができます。 ICMPパケットはTCP-AOのメカニズムを使用して保護することはできません。しかし、この方法では、TCP-AOとIPsecの両方が直接保護されたICMPシグナリングの必要性を解決しません。 TCP-AOは、IPsecが必要とするものを超えて、特定のICMPを処理する方法の具体的な提言を行うし、および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をドロップするか、それらが他の人にエンドポイント認証されることを要求に関する提言[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（宛先到達不能）の着信ICMPv4のメッセージを無視するデフォルトコード2-4（到達不能プロトコル到達不能、ポート、および断片化が必要 - 「ハードエラー」）しなければならない、とのICMPv6タイプ1（先到達不能）、同期状態（ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACKに接続するためのものコード1（管理上禁止）とコード4（ポート到達不能）は、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の実装は、[Go10]で議論されているいくつかの例がICMP「パケットが大きすぎる」のメッセージを保護するための対策を実装する必要があります。
>> 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].
このコントロールは、現在のTCPコネクション[RFC1122]を中止します「ハードエラー」を、必要のみのICMPに影響を与えます。この勧告は、追加のデフォルトは[RFC4301]を想定してIPsecは、それらのメッセージを処理する方法をと類似であることを意図しています。
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 MD5を使用するかもしれその時点で、接続のためにTCP-AOを使用しなければなりません。
>> 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 MD5のレガシー使用をサポートするために）異なる接続のために同時にTCP-AOおよび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.
MKTsの使用がRFC 2385に記述されていないが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-AOなど）を変更TCPオプションは、直接または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-AOは、その要素を横断する接続でMAC計算のすべてのオプションを無視するように設定する必要があります。その場合には、いくつかのTCPオプションを変更することができます。
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は、IPアドレスおよび/またはポート番号を変更するデバイス、（ネットワークポート変換アドレス）NAT / NAPT越えてネイティブに相互運用することはできません。我々は、[RFC2663]、[RFC3947]のIPsecで行われるような装置を横断する、別の輸送セグメント（例えば、UDP）におけるTCP-AO-保護セグメントの、例えば、カプセル、既存のNAT / NAPTトラバーサル機構の変異体を必要とするかもしれないことを予想しています。そのような変異体は、NATトラバーサルとTCP-AO、またはIPsecで使用するために適合させることができるような場合、[RFC3947]にTCP-AOの代わりに使用することができます。
An alternate proposal for accommodating NATs extends TCP-AO independently of this specification [To10].
収容NATのための代替案は、独立して、本明細書[TO10]のTCP-AOを拡張します。
TCP-AO satisfies all the current requirements for a revision to TCP MD5, as summarized below [Ed07].
TCP-AOを満たす[Ed07]以下にまとめたようにTCP MD5の改正のためのすべての現在の要件。
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。 IPv4とIPv6のバージョンを含むIP擬似ヘッダ、。
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-AOカバレッジからTCPオプションの除外を可能にすることに注意してください。第9章を参照してください。
d. TCP payload data.
D。 TCPペイロードデータ。
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アルゴリズムに相当し、MKTに指定されている）より長いオプションの長さを使用して、しかし、短いMACの長さを指定することによって隠されることに留意されたいです。 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.
MKTsのセットは、いくつかの接続ではなく他の人に合うようにインストールすることができますので、これはサポートされています。任意の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.
MKTsのセットは、いくつかの接続ではなく他の人に合うようにインストールすることができますので、これはサポートされています。任意の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.
電子。大きな窓と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の使用を可能にすることを意図しています。 TCP-AOは、96ビットMACを仮定すると、デフォルトの場合にTCP MD5よりも短い2バイトであることを示し、1.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は、このドキュメントのセクション5.1で述べたように、[RFC5926]で指定されたデフォルトに必要なアルゴリズムを使用しています。
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]).
[RFC5926]に示されているようにTCP-AOは、MACを使用します。 KDFはまた、[RFC5926]で指定されています。 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オプション空間の制限を受け、任意の所望のアルゴリズムを、可能にします。 MKTsのセットの使用は、別の接続が両方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セグメントの処理を可能にしなければならない、独立正しい順序の処理されるべきです。これは、処理の前に並べ替えの必要性を回避し、そしてオプションのmisorderedセグメントの影響を回避します。
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処理はさらに、必要とされることに留意されたいです。多くのそのようなセグメントは、廃棄されたものの、ホストは[RFC793]、例えば、最後の有効なACKの再生に応答させます。また、（セクション6.2で）並べ替えの必要性を回避するデモアルゴリズムを使用して受信機に再構成されるSNEの導出を参照。
e. Security parameter changes require key changes.
電子。セキュリティパラメータの変更は、キーの変更が必要となります。
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節を参照してください。
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。 Intraconnectionの鍵の変更。
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.
これは、IDと複数のMKTsの使用によってサポートされています。第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.
これは、鍵IDを使用することによってサポートされています。 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の使用は、外部自動および手動キーイングすることができます。この機能は、5.2節で述べたように、自動的に生成されたトラフィックキーでマニュアルMKTsの使用を可能にする、ユニークな接続ごとの鍵の生成によって強化されたセクション3を参照してください。
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.
これはMKTsのセットを使用することによってサポートされています。第3節を参照してください。
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。セグメントごとに最大1つのそのようなオプションで。
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。すべてまたはnoneを発信。
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.
電子。 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フィールドセット）、すなわち、エンドポイントの失敗を示すものでなければなりませんコミュニケーションをとること。
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.
グラム。ソケットペアだけでは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 MD5やIPsecを使用するようにTCP-AOの使用は、ホストのパフォーマンスに影響を与えます。 TCP-AOを使用することが知られている接続が無効のMACとのセグメントを送信することにより、攻撃することができます。攻撃者は、実質的に、ホストの処理能力に影響を与えるだけTCPコネクションIDおよびTCP-AOの長さの値を知っている必要があります。これは、IPアドレスとSPIが見えるであろうオンパス攻撃へのIPsecの感受性に類似しています。ルーティングプロトコルの送信元ポート（16ビット）は、典型的にのみ、任意の（典型的にはランダム未満の16ビット[LA10]を有する）であるのに対し、IPsecのため、全体SPI空間（32ビット）は、任意です。その結果、受信機の検証努力を引き起こす可能性があるTCP-AOセグメントを偽装するために、オフパス攻撃者にとって容易になるだろう。しかし、我々はインターネットルータ間、両方のポートは任意とすることができることに注意任意の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.
SYN-ACKが予想TCP-AOなしで受信され、接続を迅速にリセットするか中止されるTCP-AOは、例えば、高速減少能力を備えていません。通常の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は、TLS、sBGP / soBGP、および他のデータ・ストリームの保護機構がないことを攻撃からTCPプロトコル自体を保護することを意図しています。 IPsecのと同じように、TCP-AOは、TCP上のICMP攻撃の全体的な問題に対処しませんが、7.8節で述べたように、のICMPの影響を制限ありません。
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 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.
TCP-AOは、MAC計算におけるTCPコネクションID（ソケットのペア）を含みます。これは、潜在つのソケットのペアにセグメントが異なるソケットのペアを攻撃するために流用されたトラフィック交差攻撃を可能にするから（何らかの理由で）同じMKTを使用して別の同時接続を防止します。複数の接続が同じMKTを使用する場合、1つのIDを意図セグメントがトランジットで変更および他のIDで認証されてしまう（故意又はそれ以外）であることができなかったことを知ることは有用であろう。その要件はendsystems内MKTsに一意の追加負担を置き、潜在的にendsystems間でしょう。得られた攻撃が低い確率ではあるが、受信した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の労力を費やし偽、ランダムセグメントを送信CPUサービス拒否（DoS）攻撃のための機会を提示することができます。 CPUサイクルが投資される前のIPsecでは、このような攻撃は、一部のセグメントを検証するために大規模なセキュリティパラメータインデックス（SPI）とシーケンス番号フィールドを使用することによって削減されインテグリティチェック値（ICV）を検証しました。 TCP-AOでは、ソケットペアがIPSecのSPIの機能のほとんどを実行し、リプレイ攻撃を回避するために使用されるIPSecのシーケンス番号が、により受信されたセグメントを並べ替えるために使用されるTCPのシーケンス番号に必要とされない（順序番号を提供TCP-AO）はセクション6.2でSNEを追加する理由である、ラップアラウンドしません。 TCPは、既に（例えば、SYN、FIN、ACKビット）それでも本物リプレイは、TCP輻輳制御[Sa99]を影響する可能性が本物のセグメントデータ並びに本物の明示的なTCP制御のリプレイから自身を保護します。 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プロトコルの動作（例えば、ACK再送）を引き起こす可能性があるので、[RFC793]、TCP-AOの認証計算を実行する前に、TCPのシーケンス番号を検証するために有用ではありません。そうすることは、セグメントが有効な場合でも、TCPの挙動の変化を引き起こす可能性があるため、TCP-AOに別々のシーケンス番号フィールドを追加することも同様に有用ではありません。
The TCP Authentication Option (TCP-AO) was assigned TCP option 29 by IANA action.
TCP認証オプション（TCP-AO）は、IANAの作用により、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]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、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]マティス、M.、Mahdavi、J.、フロイド、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.グレン、 "ESPおよびAH内のHMAC-MD5-96の使用"、RFC 2403、1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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]フロイド、S.、Mahdavi、J.、マティス、M.、およびM.ポドルスキー、 "TCPのための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年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]ブラントン、E.、オールマン、M.、秋、K.、およびL.王は、 "保守的な選択的確認応答（SACK）はTCPのために損失回復アルゴリズムをベース"、RFC 3517、2003年4月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724]サングリ、S.、チェン、E.、フェルナンド、R.、スカダー、J.、およびY. Rekhter、 "BGPのためのグレースフルリスタート機構"、RFC 4724、2007年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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS", RFC 4781, January 2007.
[RFC4781] Rekhter、Y.、およびR.アガルワル、 "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.レスコラ、RFC 5926、2010年6月 "TCP認証オプション（TCP-AO）の暗号化アルゴリズム"。
[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.、ヴァイス、B.、Viswanathanの、S.、ランゲ、A.、およびO.ウィーラー、 "TCPベースのルーティングと管理プロトコルの認証"、進歩、2007年2月での作業。
[Bo09] Borman, D., "TCP Options and MSS", Work in Progress, July 2009.
[Bo09]ボーマン、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]エディ、W.、エド。、Bellovin氏、S.、タッチ、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]ラーセン、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.ケント、進歩、2009年10月に作品「安全なインターネットルーティングをサポートするインフラストラクチャ」。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのための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.、ベラー、M.、およびR.カネッティ、 "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.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]リーチ、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.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年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]タッチ、J.、RFC 4953、2007年7月 "なりすまし攻撃に対するTCPを防衛"。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]サベージ、S.、N.カードウェル、D. Wetherall、T.アンダーソン、 "ふらちなレシーバーとのTCP輻輳制御"、ACMコンピュータコミュニケーションレビュー、V29、N5、pp71-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]タッチ、J.およびA.マンキン、 "TCP簡易認証オプション"、進歩、2007年7月の作業。
[To10] Touch, J., "A TCP Authentication Option NAT Extension", Work in Progress, January 2010.
[TO10]タッチ、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]王、X.、H.ゆうは、 "どのようにMD5および他のハッシュ関数を破る"、PROC。 IACR EUROCRYPT 2005、デンマーク、pp.19-35。
[We05] Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, "TCP Message Authentication Code Option", Work in Progress, December 2005.
[WE05]ヴァイス、B.、Appanna、C.、マグリュー、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）、のコラボレーションの結果として進化：マーク・オールマン、スティーブBellovin氏、ロンBonica、ウェス・エディ、ラースEggertの、チャーリー・カウフマン、アンドリュー・ラング、アリソンマンキン、サンディマーフィー、ジョー・タッチ、スリラムViswanathanの、ブライアン・ワイス、およびマグヌスウェスター。この文書のテキストは両方に触発し、TCP MD5の改正に対案はロンBonicaによって文書で提案されているように意図されていたジョー・タッチとアリソンマンキンの提案[TO07]（元々は2006年6月から）、から誘導され、ブライアン・ワイス、Sriran Viswanathanの、アンドリュー・ラング、およびオーウェンウィーラー[Bo07]（元々は2005年9月から）とブライアン・ワイス[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.
ラスHousleyは、マスターキーのタプルのL4 /アプリケーション層の管理を示唆しました。スティーブBellovin氏は、鍵IDフィールドをやる気。エリックレスコラは、リプレイ攻撃を回避するために、トラフィックキー計算とSNESにおけるTCPの初期シーケンス番号（ISNが）の使用を提案し、ブライアン・ワイスは、全体の接続IDを組み込むために、計算を拡張し、トラフィックキー計算の詳細を提供します。マーク・オールマン、ウェス・エディ、ラースEggertの、テッド・フェーバー、ラスHousley、グレゴリーLebovitz、ティムポーク、エリックレスコラ、ジョー・タッチ、そしてブライアン・ワイスは、マスターキーの調整メカニズムを開発しました。
Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other members of the TCPM WG also provided substantial feedback on this document.
アルフレッドHoenes、チャーリー・カウフマン、アダム・ラングレー、およびTCPM WGの多数の他のメンバーも、この文書にかなりのフィードバックを提供します。
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.
ジョー・タッチUSC / ISI 4676アドミラルティWayマリナデルレイ、カリフォルニア州90292から6695 U.S.A.
Phone: +1 (310) 448-9151 EMail: touch@isi.edu URL: http://www.isi.edu/touch
電話：+1（310）448-9151 Eメール：touch@isi.edu URL：http://www.isi.edu/touch
Allison Mankin Johns Hopkins Univ. Baltimore, MD U.S.A.
アリソンマンキンジョンズ・ホプキンス大学。ボルチモア、MD U.S.A.
Phone: 1 301 728 7199 EMail: mankin@psg.com URL: http://www.psg.com/~mankin/
電話番号：1 301 728 7199 Eメール：mankin@psg.com URL：http://www.psg.com/~mankin/
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 U.S.A.
ロナルドP. Bonicaジュニパーネットワークスの2251年コーポレートパークドライブハーンドン、VA 20171 U.S.A.
EMail: rbonica@juniper.net
メールアドレス：rbonica@juniper.net