[要約] RFC 5925は、TCP認証オプションの仕様を定義しています。その目的は、TCP接続のセキュリティを向上させ、認証された通信を確保することです。
Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 5925 USC/ISI
Obsoletes: 2385 A. Mankin
Category: Standards Track Johns Hopkins Univ.
ISSN: 2070-1721 R. Bonica
Juniper Networks
June 2010
The TCP Authentication Option
TCP認証オプション
Abstract
概要
This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.
このドキュメントは、RFC 2385（TCP MD5）のTCP MD5署名オプションを廃止するTCP認証オプション（TCP-AO）を指定します。TCP-AOは、より強力なメッセージ認証コード（MACS）の使用を指定し、長命のTCP接続でもリプレイから保護し、TCP MD5よりもセキュリティの関連性とTCP接続の関連性の詳細を提供します。TCP-AOは、静的マスターキータプル（MKT）構成または外部の帯域外MKT管理メカニズムのいずれかと互換性があります。どちらの場合でも、TCP-AOは、MKTから派生したトラフィックキーを使用して、接続の繰り返しインスタンスで同じMKTを使用する場合、接続を保護し、エンドポイント間のMKTの変化を調整します。結果は、長寿命の接続を保護するなど、TCP MD5の現在のインフラストラクチャの使用をサポートすることを目的としています（BGPやLDPなど）、他のシステムや運用上の変更を最小限に抑えたMACのより大きなセットをサポートすることを目的としています。TCP-AOとTCP MD5を同時に使用することは許可されていない場合でも、TCP-AOはTCP MD5とは異なるオプション識別子を使用します。TCP-AOはIPv6をサポートしており、TCP MD5の交換に関する提案された要件と完全に互換性があります。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5925.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 Pseudoheader、TCPヘッダー、TCPデータを含むTCPセグメントを認証するTCPオプションです。これは、BGPデータまたはTCP接続自体の堅牢性に影響を与える可能性のあるスプーフィングされたTCPセグメントからBGPセッションを保護するために開発されました[RFC2385] [RFC4953]。
There have been many recent concerns about TCP MD5. Its use of a simple keyed hash for authentication is problematic because there have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 also lacks both key-management and algorithm agility. This document adds the latter, and provides a simple key coordination mechanism giving the ability to move from one key to another within the same connection. It does not however provide for complete cryptographic key management to be handled in band of TCP, because TCP SYN segments lack sufficient remaining space to handle such a negotiation (see Section 7.6). This document obsoletes the TCP MD5 option with a more general TCP Authentication Option (TCP-AO). This new option supports the use of other, stronger hash functions, provides replay protection for long-lived connections and across repeated instances of a single connection, coordinates key changes between endpoints, and provides a more explicit recommendation for external key management. The result is compatible with IPv6, and is fully compatible with proposed requirements for a replacement for TCP MD5 [Ed07].
TCP MD5に関する最近の多くの懸念がありました。認証のための単純なキー付きハッシュの使用は、アルゴリズム自体に対する攻撃のエスカレートがあったため問題があります[WA05]。TCP MD5には、キー管理とアルゴリズムの俊敏性の両方もありません。このドキュメントは後者を追加し、同じ接続内であるキーから別のキーに移動する能力を与える単純なキー調整メカニズムを提供します。ただし、TCP Synセグメントにはそのような交渉を処理するのに十分な残りのスペースがないため、TCPのバンドで処理される完全な暗号化キー管理を提供することはできません（セクション7.6を参照）。このドキュメントは、より一般的なTCP認証オプション（TCP-AO）でTCP MD5オプションを廃止します。この新しいオプションは、他のより強力なハッシュ関数の使用をサポートし、長寿命の接続と単一の接続の繰り返しインスタンスにわたってリプレイ保護を提供し、エンドポイント間のキー変更を調整し、外部キー管理のより明確な推奨事項を提供します。結果はIPv6と互換性があり、TCP MD5 [ED07]の代替品の提案された要件と完全に互換性があります。
TCP-AO obsoletes TCP MD5, although a particular implementation may support both mechanisms for backward compatibility. For a given connection, only one can be in use. TCP MD5-protected connections cannot be migrated to TCP-AO because TCP MD5 does not support any changes to a connection's security algorithm once established.
TCP-AO OBESOLETES TCP MD5。ただし、特定の実装は、後方互換性の両方のメカニズムをサポートする場合があります。特定の接続では、1つだけが使用できます。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の使用を置き換える（したがって廃止される）ことを目的としています。TCP-AOは、セクション1.3で要約されているように、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は、IPSECがサポートされていないか、TCP-AOの特定のプロパティが必要であるため、TCP認証によって提供される保護が必要な場合に実装する必要があります。
>> 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に記載されています。実際、特にIPSECとIKEの使用をお勧めします。特に、IKEのパラメーター交渉、セッションキーネゴシエーション、または再キーイングに対する既存のサポートのレベルが必要です。TCP-AOは、IPSECスイートが実行不可能な場合にのみ使用することを目的としています。たとえば、いくつかのルーティングプロトコル[RFC4953]をサポートする場合、またはキーを個々の輸送セッションと緊密に調整する必要がある場合[ED07]。
TCP-AO is not intended to replace the use of Transport Layer Security (TLS) [RFC5246], Secure BGP (sBGP) or Secure Origin BGP (soBGP) [Le09], or any other mechanisms that protect only the TCP data stream. TCP-AO protects the transport layer, preventing attacks from disabling the TCP connection itself [RFC4953]. Data stream mechanisms protect only the contents of the TCP segments, and can be disrupted when the connection is affected. Some of these data protection protocols -- notably TLS -- offer a richer set of key management and authentication mechanisms than TCP-AO, and thus protect the data stream in a different way. TCP-AO may be used together with these data stream protections to complement each other's strengths.
TCP-AOは、輸送層セキュリティ（TLS）[RFC5246]、セキュアBGP（SBGP）または安全な原点BGP（SOBGP）[LE09]、またはTCPデータストリームのみを保護するその他のメカニズムの使用を交換することを目的としていません。TCP-AOは輸送層を保護し、攻撃がTCP接続自体を無効にするのを防ぎます[RFC4953]。データストリームメカニズムは、TCPセグメントの内容のみを保護し、接続が影響を受けると破壊される可能性があります。これらのデータ保護プロトコルの一部、特にTLSは、TCP-AOよりも豊富な主要な管理および認証メカニズムを提供するため、データストリームを異なる方法で保護します。TCP-AOは、これらのデータストリーム保護と一緒に使用して、互いの強みを補完することができます。
This document replaces TCP MD5 as follows [RFC2385]:
このドキュメントは、次のようにTCP MD5を置き換えます[RFC2385]：
o TCP-AO uses a separate option Kind (29).
o TCP-AOは、個別のオプションの種類を使用します（29）。
o TCP-AO allows TCP MD5 to continue to be used concurrently for legacy connections.
o TCP-AOにより、TCP MD5はレガシー接続に同時に使用され続けることができます。
o TCP-AO replaces TCP MD5's single MAC algorithm with MACs specified in a separate document and can be extended to include other MACs.
o TCP-AOは、TCP MD5の単一MACアルゴリズムを別のドキュメントで指定したMacに置き換え、他のMacを含むように拡張できます。
o TCP-AO allows rekeying during a TCP connection, assuming that an out-of-band protocol or manual mechanism provides the new keys. The option includes a 'key ID', which allows the efficient concurrent use of multiple keys, and a key coordination mechanism using a 'receive next key ID' manages the key change within a connection. Note that TCP MD5 does not preclude rekeying during a connection, but does not require its support either. Further, TCP-AO supports key changes with zero segment loss, whereas key changes in TCP MD5 can lose segments in transit during the changeover or require trying multiple keys on each received segment during key use overlap because it lacks an explicit key ID. Although TCP recovers lost segments through retransmission, loss can have a substantial impact on performance.
o TCP-AOは、帯域外のプロトコルまたは手動メカニズムが新しいキーを提供すると仮定して、TCP接続中に再キーイングを可能にします。オプションには「キーID」が含まれています。これにより、複数のキーの効率的な同時使用が可能になり、「次のキーIDの受信」を使用したキー調整メカニズムが接続内のキー変更を管理します。TCP MD5は、接続中の再キーを排除することはできませんが、そのサポートも必要としないことに注意してください。さらに、TCP-AOはセグメント損失がゼロでキー変更をサポートしますが、TCP MD5の主要な変更は、切り替え中に輸送中にセグメントを失うか、明示的なキーIDがないため、キー使用オーバーラップ中に各受信セグメントで複数のキーを試す必要があります。TCPは再送信を通じて失われたセグメントを回復しますが、損失はパフォーマンスに大きな影響を与える可能性があります。
o TCP-AO provides automatic replay protection for long-lived connections using sequence number extensions.
o TCP-AOは、シーケンス番号拡張機能を使用して、長寿命の接続に自動リプレイ保護を提供します。
o TCP-AO ensures per-connection traffic keys as unique as the TCP connection itself, using TCP's Initial Sequence Numbers (ISNs) for differentiation, even when static master key tuples are used across repeated instances of connections on a single socket pair.
o TCP-AOは、TCP接続自体と同じように一意の接続トラフィックキーを保証します。これは、Static Masterキータプルが単一のソケットペアの接続の繰り返しインスタンスで使用されている場合でも、分化にTCPの初期シーケンス番号（ISN）を使用します。
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は、最初に指定されたデフォルトのケース（96ビットMACを使用）で、TCP MD5（全体ではなく16バイト）よりも2バイト短いです。
TCP-AO differs from an IPsec/IKE solution as follows [RFC4301][RFC4306]:
TCP-AOは、次のようにIPSEC/IKEソリューションとは異なります[RFC4301] [RFC4306]：
o TCP-AO does not support dynamic parameter negotiation.
o TCP-AOは、動的なパラメーターネゴシエーションをサポートしていません。
o TCP-AO includes TCP's socket pair (source address, destination address, source port, destination port) as a security parameter index (together with the KeyID), rather than using a separate field as an index (IPsec's Security Parameter Index (SPI)).
o TCP-AOは、TCPのソケットペア（ソースアドレス、宛先アドレス、ソースポート、宛先ポート）をセキュリティパラメーターインデックス（KeyIDとともに）として含め、個別のフィールドをインデックス（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は、TCPソケットペア（IPアドレスとポート番号）を再利用する場合でも、接続が再起動するときに計算されたMacの変更を強制します[ED07]。
o TCP-AO does not support encryption.
o TCP-AOは暗号化をサポートしていません。
o TCP-AO does not authenticate ICMP messages (some ICMP messages may be authenticated when using IPsec, depending on the configuration).
o TCP-AOはICMPメッセージを認証しません（構成に応じて、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オプションの種類値29を使用します。次のセクションでは、TCP-AOについて説明し、比較のためにTCP MD5のレビューを提供します。
For review, the TCP MD5 option is shown in Figure 1.
レビューのために、TCP MD5オプションを図1に示します。
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| ...digest (con't)... |
+---------------------------------------+
| ... |
+---------------------------------------+
| ... |
+-------------------+-------------------+
| ...digest (con't) |
+-------------------+
Figure 1: The TCP MD5 Option [RFC2385]
図1：TCP MD5オプション[RFC2385]
In the TCP MD5 option, the length is fixed, and the MD5 digest occupies 16 bytes following the Kind and Length fields (each one byte), using the full MD5 digest of 128 bits [RFC1321].
TCP MD5オプションでは、長さが固定され、MD5ダイジェストは、128ビットの完全なMD5ダイジェスト[RFC1321]を使用して、種類と長さのフィールド（それぞれ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 Pseudoheader（IPソースおよび宛先アドレス、プロトコル番号、およびセグメントの長さ）。
2. The TCP header excluding options and checksum.
2. オプションとチェックサムを除くTCPヘッダー。
3. The TCP data payload.
3. TCPデータペイロード。
4. A key.
4. かぎ。
TCP-AO provides a superset of the capabilities of TCP MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field, and similar Length field to TCP MD5, a KeyID field, and a RNextKeyID field as shown in Figure 2.
TCP-AOは、TCP MD5の機能のスーパーセットを提供し、SP4 [SDNS88]の精神では最小限です。TCP-AOは、図2に示すように、新しい種類のフィールドと同様の長さフィールド、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以上でなければなりません。長さの値が4未満の場合、TCPはセグメントを破棄する必要があります。
>> The Length value MUST be consistent with the TCP header length. When the Length value is invalid, TCP MUST discard the segment.
>>長さの値は、TCPヘッダーの長さと一致する必要があります。長さの値が無効な場合、TCPはセグメントを破棄する必要があります。
This Length check implies that the sum of the sizes of all options, when added to the size of the base TCP header (5 words), matches the TCP Offset field exactly. This full verification can be computed because RFC 793 specifies the size of the required options, and RFC 1122 requires that all new options follow a common format with a fixed-length field location [RFC793][RFC1122]. A partial verification can be limited to check only TCP-AO, so that the TCP-AO length, when added to the TCP-AO offset from the start of the TCP header, does not exceed the TCP header size as indicated in the TCP header Offset field.
この長さのチェックは、すべてのオプションのサイズの合計が、ベースTCPヘッダー（5単語）のサイズに追加されると、TCPオフセットフィールドと正確に一致することを意味します。RFC 793が必要なオプションのサイズを指定しているため、この完全な検証を計算できます。RFC1122では、すべての新しいオプションが固定長のフィールドの位置[RFC793] [RFC1122]の共通形式に従うことが必要です。部分的な検証は、TCP-AOのみをチェックするために制限できます。これにより、TCP-AOの長さは、TCPヘッダーの開始からTCP-AOオフセットに追加されると、TCPヘッダーで示されているようにTCPヘッダーサイズを超えないようにします。オフセットフィールド。
Values of 4 and other small values larger than 4 (e.g., indicating MAC fields of very short length) are of dubious utility but are not specifically prohibited.
4および4を超える他の小値の値（たとえば、非常に短い長さのMacフィールドを示す）は疑わしいユーティリティですが、特に禁止されていません。
o KeyID: An unsigned 1-byte field indicating the Master Key Tuple (MKT, as defined in Section 3.1) used to generate the traffic keys that were used to generate the MAC that authenticates this segment.
o KeyID：マスターキータプル（セクション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でさらに議論します。KeyIDには暗号化特性がないことに注意してください。ランダムである必要はなく、予約された値もありません。
>> KeyID values MAY be the same in both directions of a connection, but do not have to be and there is no special meaning when they are.
>> keyID値は、接続の両方向で同じである場合がありますが、そうである必要はなく、特別な意味はありません。
This allows MKTs to be installed on a set of devices without coordinating the KeyIDs across that entire set in advance, and allows new devices to be added to that set using a group of MKTs later without requiring renumbering of KeyIDs. These two capabilities are particularly important when used with wildcards in the TCP socket pair of the MKT, i.e., when an MKT is used among a set of devices specified by a pattern (as noted in Section 3.1).
これにより、MKTは、そのセット全体にわたってKeyIDを調整せずにデバイスのセットにインストールすることができ、KeyIDの変更を必要とせずに、後でMKTSのグループを使用して新しいデバイスをそのセットに追加できるようにします。これらの2つの機能は、MKTのTCPソケットペアのワイルドカードとともに使用される場合、つまり、MKTがパターンで指定された一連のデバイスで使用される場合（セクション3.1に記載されているように）特に重要です。
o RNextKeyID: An unsigned 1-byte field indicating the MKT that is ready at the sender to be used to authenticate received segments, i.e., the desired 'receive next' key ID.
o RNEXTKEYID：送信者が受信セグメントを認証するために使用されるMKTを示す署名されていない1バイトフィールド、つまり目的の「Receive Next」キー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の必要なサポートは[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フィールドは、MACアルゴリズムを暗黙的に（TCP MD5のように）または明示的に示していません。使用される特定のアルゴリズムは、接続のセキュリティの構成状態の一部と見なされ、個別に管理されています（セクション3を参照）。
Please note that the use of TCP-AO does not affect TCP's advertised Maximum Segment Size (MSS), as is the case for all TCP options [Bo09].
TCP-AOの使用は、すべてのTCPオプション[BO09]の場合のように、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.
TCP-AOは、2つのセットのキーに依存して、受信と発信セグメントを認証するために、マスターキータプル（MKT）とトラフィックキーを認証します。MKTは、一意のトラフィックキーを導き出すために使用され、それらのトラフィックキーを生成するために使用されるキーイング素材を含め、トラフィックキーが使用される関連パラメーターを示します。このようなパラメーターには、TCPオプションが認証されているかどうか、およびトラフィックキーの派生とMAC計算に使用されるアルゴリズムの指標が含まれます。トラフィックキーは、個々のTCPセグメントのMACを計算するために使用されるキーイング素材です。
A Master Key Tuple (MKT) describes TCP-AO properties to be associated with one or more connections. It is composed of the following:
マスターキータプル（MKT）は、TCP-AOプロパティが1つ以上の接続に関連付けられていることを説明しています。次のことで構成されています。
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に含まれており、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 IDS。TCP-AOのkeyIDまたはrNextKeyIDで使用される値。同時使用（keyID）でMKTを区別するために使用されるだけでなく、MKTが反対方向（rnextKeyID）で使用できるタイミングを示すために使用されます。
Each MKT has two IDs - -- a SendID and a RecvID. The SendID is inserted as the KeyID of the TCP-AO option of outgoing segments, and the RecvID is matched against the TCP-AO KeyID of incoming segments. These and other uses of these two IDs are described further in Sections 7.4 and 7.5.
各MKTには2つのIDがあります-DendIDとRecvid。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 IDSは、0-255包括的任意の価値をサポートする必要があります。予約されたID値はありません。
ID values are assigned arbitrarily, i.e., the values are not monotonically increasing, have no reserved values, and are otherwise not meaningful. They can be assigned in sequence, or based on any method mutually agreed by the connection endpoints (e.g., using an external MKT management mechanism).
ID値は任意に割り当てられます。つまり、値は単調に増加しておらず、予約された値がなく、それ以外の場合は意味がありません。これらは、接続エンドポイントによって相互に合意された方法（例：外部MKT管理メカニズムを使用）に基づいて、順番に割り当てることができます。
>> IDs MUST NOT be assumed to be randomly assigned.
>> IDはランダムに割り当てられていると想定してはなりません。
o Master key. A byte sequence used for generating traffic keys, this may be derived from a separate shared key by an external protocol over a separate channel. This sequence is used in the traffic key generation algorithm described in Section 5.2.
o マスターキー。トラフィックキーの生成に使用されるバイトシーケンスは、別のチャネル上の外部プロトコルによって別の共有キーから導出される場合があります。このシーケンスは、セクション5.2で説明されているトラフィックキー生成アルゴリズムで使用されます。
Implementations are advised to keep master key values in a private, protected area of memory or other storage.
実装は、マスターキー値をプライベート、保護されたメモリまたはその他のストレージに維持することをお勧めします。
o Key Derivation Function (KDF). Indicates the key derivation function and its parameters, as used to generate traffic keys from master keys. It is explained further in Section 5.2 of this document and specified in detail in [RFC5926].
o キー導出関数（KDF）。マスターキーからトラフィックキーを生成するために使用されるように、キー派生関数とそのパラメーターを示します。このドキュメントのセクション5.2でさらに説明し、[RFC5926]で詳細に指定されています。
o Message Authentication Code (MAC) algorithm. Indicates the MAC algorithm and its parameters as used for this connection. It is explained further in Section 5.1 of this document and specified in detail in [RFC5926].
o メッセージ認証コード（MAC）アルゴリズム。この接続に使用されるMacアルゴリズムとそのパラメーターを示します。このドキュメントのセクション5.1でさらに説明し、[RFC5926]で詳細に指定されています。
>> Components of an MKT MUST NOT change during a connection.
>> MKTのコンポーネントは、接続中に変更してはなりません。
MKT component values cannot change during a connection because TCP state is coordinated during connection establishment. TCP lacks a handshake for modifying that state after a connection has been established.
MKTコンポーネント値は、接続の確立中にTCP状態が調整されるため、接続中に変更できません。TCPには、接続が確立された後にその状態を変更するための握手がありません。
>> The set of MKTs MAY change during a connection.
>> MKTSのセットは、接続中に変更される場合があります。
MKT parameters are not changed. Instead, new MKTs can be installed, and a connection can change which MKT it uses.
MKTパラメーターは変更されません。代わりに、新しいMKTをインストールすることができ、接続を使用するMKTを変更できます。
>> The IDs of MKTs MUST NOT overlap where their TCP connection identifiers overlap.
>> MKTSのIDは、TCP接続識別子が重複する場合に重複してはなりません。
This document does not address how MKTs are created by users or processes. It is presumed that an MKT affecting a particular connection cannot be destroyed during an active connection -- or, equivalently, that its parameters are copied to an area local to the connection (i.e., instantiated) and so changes would affect only new connections. The MKTs can be managed by a separate application protocol.
このドキュメントでは、MKTがユーザーまたはプロセスによってどのように作成されるかについては対処していません。特定の接続に影響を与えるMKTは、アクティブな接続中に破壊することはできません。または、同等に、そのパラメーターは接続にローカルな領域（つまり、インスタンス化された）にコピーされるため、変更は新しい接続のみに影響します。MKTSは、別のアプリケーションプロトコルによって管理できます。
A traffic key is a key derived from the MKT and the local and remote IP address pairs and TCP port numbers, and, for established connections, the TCP Initial Sequence Numbers (ISNs) in each direction. Segments exchanged before a connection is established use the same information, substituting zero for unknown values (e.g., ISNs not yet coordinated).
トラフィックキーは、MKTおよびローカルおよびリモートIPアドレスのペアとTCPポート番号から派生したキーであり、確立された接続の場合、各方向のTCP初期シーケンス番号（ISNS）です。接続が確立される前に交換されるセグメントは、同じ情報を使用して、不明な値（たとえば、まだ調整されていない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].
キーは一方向であることに注意してください。通常、特定の接続は、これらのキーのうち3つのみを使用します。これは、通常使用されるSynキーの1つだけが使用されるためです。4つすべてが、接続が「同時開く」[RFC793]を通過する場合にのみ使用されます。
The relationship between MKTs and traffic keys is shown in Figure 3. Traffic keys are indicated with a "*". Note that every MKT can be used to derive any of the four traffic keys, but only the keys actually needed to handle the segments of a connection need to be computed. Section 5.2 provides further details on how traffic keys are derived.
MKTとトラフィックキーの関係を図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：MKTとトラフィックキーの関係
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は使用されません。複数のMKTは、MKTが変更されている場合、単一の発信セグメントと一致する場合があります。これらのMKTは矛盾するIDを持つことはできません（他の場所で述べられているように）。一部のメカニズムは、与えられた各外出セグメントに使用するMKTを決定する必要があります。
>> An outgoing TCP segment MUST match at most one desired MKT, indicated by the segment's socket pair. The segment MAY match multiple MKTs, provided that exactly one MKT is indicated as desired. Other information in the segment MAY be used to determine the desired MKT when multiple MKTs match; such information MUST NOT include values in any TCP option fields.
>>発信TCPセグメントは、セグメントのソケットペアで示される最大1つの望ましいMKTに一致する必要があります。セグメントは、必要に応じて正確に1つのMKTが示されている場合、複数のMKTと一致する場合があります。セグメント内のその他の情報は、複数のMKTが一致するときに目的のMKTを決定するために使用できます。このような情報は、TCPオプションフィールドに値を含めてはなりません。
We recommend that the mechanism used to select from among multiple MKTs use only information that TCP-AO would authenticate. Because MKTs may indicate that options other than TCP-AO are ignored in the MAC calculation, we recommend that TCP options should not be used to determine MKTs.
複数のMKTの中から選択するために使用されるメカニズムは、TCP-AOが認証する情報のみを使用することをお勧めします。MKTは、MAC計算でTCP-AO以外のオプションが無視されていることを示している可能性があるため、MKTを決定するためにTCPオプションを使用しないことをお勧めします。
>> An incoming TCP segment including TCP-AO MUST match exactly one MKT, indicated solely by the segment's socket pair and its TCP-AO KeyID.
>> TCP-AOを含む着信TCPセグメントは、セグメントのソケットペアとそのTCP-AO KeyIDのみで示される1つのMKTを正確に一致させる必要があります。
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.
着信セグメントには、複数のマッチングMKT（KeyIDフィールド）から選択するTCP-AO内のインジケータが含まれています。TCP-AOでは、KeyIDのみを使用して複数の一致するMKTを区別することを要求しているため、TCP-AOキー変更調整メカニズムを使用してMKTの変更を調整できます。
>> When an outgoing TCP segment matches no MKTs, TCP-AO is not used.
>>発信TCPセグメントがMKTSを一致させない場合、TCP-AOは使用されません。
TCP-AO is always used when outgoing segments match an MKT, and is not used otherwise.
TCP-AOは、発信セグメントがMKTと一致する場合に常に使用され、それ以外の場合は使用されません。
TCP-AO uses a small number of parameters associated with each connection that uses TCP-AO, once instantiated. These values can be stored in the Transport Control Block (TCB) [RFC793]. These values are explained in subsequent sections of this document as noted; they include:
TCP-AOは、一度インスタンス化されると、TCP-AOを使用する各接続に関連付けられた少数のパラメーターを使用します。これらの値は、輸送制御ブロック（TCB）[RFC793]に保存できます。これらの値は、記載されているように、このドキュメントの以降のセクションで説明されています。それらは次のとおりです。
1. Current_key - the MKT currently used to authenticate outgoing segments, whose SendID is inserted in outgoing segments as KeyID (see Section 7.4, step 2.f). Incoming segments are authenticated using the MKT corresponding to the segment and its TCP-AO KeyID (see Section 7.5, step 2.c), as matched against the MKT TCP connection identifier and the MKT RecvID. There is only one current_key at any given time on a particular connection.
1. current_key -MKTは現在、発信セグメントを認証するために使用されています。受信セグメントは、MKT TCP接続識別子とMKT Recvidと一致するように、セグメントとそのTCP-AO KeyIDに対応するMKT（セクション7.5、ステップ2.Cを参照）を使用して認証されます。特定の接続には、いつでもcurrent_keyが1つしかありません。
>> 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が希望されています。
>> 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）。SNESは、セクション6.2で説明されているように、リプレイ攻撃を防ぐために使用されます。各SNEは、接続確立時にゼロに初期化されます。MACの計算での使用は、セクション5.1で説明されています。
4. One or more MKTs. These are the MKTs that match this connection's socket pair.
4. 1つ以上のMKTS。これらは、この接続のソケットペアに一致するMKTです。
MKTs are used, together with other parameters of a connection, to create traffic keys unique to each connection, as described in Section 5.2. These traffic keys can be cached after computation, and can be stored in the TCB with the corresponding MKT information. They can be considered part of the per-connection parameters.
MKTは、セクション5.2で説明されているように、各接続に固有のトラフィックキーを作成するために、接続の他のパラメーターとともに使用されます。これらのトラフィックキーは、計算後にキャッシュでき、対応する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は、暗号化アルゴリズムを使用して、接続全体で共有できるMKTを各接続の一意のトラフィックキーに変換します。これらはキー誘導関数（KDF）と呼ばれ、指定されています[RFC5926]。このセクションでは、これらのアルゴリズムがTCP-AOでどのように使用されるかについて説明します。
MAC algorithms take a variable-length input and a key and output a fixed-length number. This number is used to determine whether the input comes from a source with that same key, and whether the input has been tampered with in transit. MACs for TCP-AO have the following interface:
Macアルゴリズムは、可変長入力とキーを取り、固定長の数値を出力します。この数値は、入力が同じキーを持つソースから来るかどうか、および入力が輸送中に改ざんされているかどうかを判断するために使用されます。TCP-AOのMacには、次のインターフェイスがあります。
MAC = MAC_alg(traffic_key, message)
mac = mac_alg（traffic_key、message）
INPUT: MAC_alg, traffic_key, message
入力：mac_alg、traffic_key、メッセージ
OUTPUT: MAC
出力：Mac
where:
ただし：
o MAC_alg - the specific MAC algorithm used for this computation. The MAC algorithm specifies the output length, so no separate output length parameter is required. This is specified as described in [RFC5926].
o MAC_ALG -この計算に使用される特定のMACアルゴリズム。Macアルゴリズムは出力長を指定するため、個別の出力長パラメーターは必要ありません。これは、[RFC5926]で説明されているように指定されています。
o Traffic_key - traffic key used for this computation. This is computed from the connection's current MKT as described in Section 5.2.
o Traffic_key-この計算に使用されるトラフィックキー。これは、セクション5.2で説明されているように、接続の現在のMKTから計算されます。
o Message - input data over which the MAC is computed. In TCP-AO, this is the TCP segment prepended by the IP pseudoheader and TCP header options, as described in Section 5.1.
o メッセージ - Macが計算されるデータを入力します。TCP-AOでは、これはセクション5.1で説明されているように、IP擬似ヘッダーとTCPヘッダーオプションによって準備されたTCPセグメントです。
o MAC - the fixed-length output of the MAC algorithm, given the parameters provided.
o MAC-提供されたパラメーターが与えられたMACアルゴリズムの固定長い出力。
At the time of this writing, the algorithms' definitions for use in TCP-AO, as described in [RFC5926], are each truncated to 96 bits. Though the algorithms each output a larger MAC, 96 bits provides a reasonable trade-off between security and message size. However, this could change in the future, so TCP-AO size should not be assumed as fixed length.
この執筆時点で、[RFC5926]で説明されているように、TCP-AOで使用するアルゴリズムの定義は、それぞれ96ビットに切り捨てられます。アルゴリズムはそれぞれ大きなMACを出力しますが、96ビットはセキュリティとメッセージサイズの間に合理的なトレードオフを提供します。ただし、これは将来変化する可能性があるため、TCP-AOサイズを固定長と想定すべきではありません。
The MAC algorithm employed for the MAC computation on a connection is done so by definition in the MKT, per the definition in [RFC5926].
[RFC5926]の定義に従って、接続でMAC計算に使用されるMACアルゴリズムは、MKTで定義上、定義により行われます。
The mandatory-to-implement MAC algorithms for use with TCP-AO are described in a separate RFC [RFC5926]. This allows the TCP-AO specification to proceed along the IETF Standards Track even if changes are needed to its associated algorithms and their labels (as might be used in a user interface or automated MKT management protocol) as a result of the ever evolving world of cryptography.
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 PSEUDOHEADERは、IPv4またはIPv6 [RFC793] [RFC2460]のTCPチェックサムに使用されているとまったく同じです。
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Zero | Proto | TCP Length |
+--------+--------+--------+--------+
Figure 5: TCP IPv4 Pseudoheader [RFC793]
図5：TCP IPv4擬似ヘッダー[RFC 793]
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Upper-Layer Payload Length |
+--------+--------+--------+--------+
| Zero | Next Header |
+--------+--------+--------+--------+
Figure 6: TCP IPv6 Pseudoheader [RFC2460]
図6：TCP IPv6 Pseudoheader [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処理でゼロになっています。
4. The TCP data, i.e., the payload of the TCP segment.
4. TCPデータ、つまりTCPセグメントのペイロード。
Note that the traffic key is not included as part of the data; the MAC algorithm indicates how to use the traffic key, for example, as HMACs do [RFC2104][RFC2403]. The traffic key is derived from the current MKT as described in Section 5.2.
トラフィックキーはデータの一部として含まれていないことに注意してください。MACアルゴリズムは、たとえば、HMACSが行うようにトラフィックキーの使用方法を示しています[RFC2104] [RFC2403]。トラフィックキーは、セクション5.2で説明されているように、現在のMKTから派生しています。
TCP-AO's traffic keys are derived from the MKTs using Key Derivation Functions (KDFs). The KDFs used in TCP-AO have the following interface:
TCP-AOのトラフィックキーは、キー導入関数（KDF）を使用してMKTSから派生しています。TCP-AOで使用されるKDFSには、次のインターフェイスがあります。
traffic_key = KDF_alg(master_key, context, output_length)
traffic_key = kdf_alg（master_key、context、output_length）
INPUT: KDF_alg, master_key, context, output_length
入力：kdf_alg、master_key、context、output_length
OUTPUT: traffic_key
出力：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.
o MASTER_KEY -MASTER_KEY文字列は、関連するMKTに保存されます。
o Context - The context used as input in constructing the traffic_key, as specified in [RFC5926]. The specific way this context is used, in conjunction with other information, to create the raw input to the KDF is also explained further in [RFC5926].
o コンテキスト - [RFC5926]で指定されているように、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].
o output_length- KDFの目的の出力長、つまりKDFの出力が切り捨てられる長さ。これは、[RFC5926]で説明されているように指定されています。
o Traffic_key - The desired output of the KDF, of length output_length, to be used as input to the MAC algorithm, as described in Section 5.1.
o Traffic_key-セクション5.1で説明されているように、Macアルゴリズムへの入力として使用する長さの出力_LengthのKDFの目的の出力。
The context used as input to the KDF combines the TCP socket pair with the endpoint Initial Sequence Numbers (ISNs) of a connection. This data is unique to each TCP connection instance, which enables TCP-AO to generate unique traffic keys for that connection, even from an MKT used across many different connections or across repeated connections that share a socket pair. Unique traffic keys are generated without relying on external key management properties. The KDF context is defined in Figures 7 and 8.
KDFへの入力として使用されるコンテキストは、TCPソケットペアと接続のエンドポイント初期シーケンス番号（ISNS）を組み合わせます。このデータは、各TCP接続インスタンスに固有のものです。これにより、TCP-AOは、多くの異なる接続で使用されているMKTまたはソケットペアを共有する繰り返しの接続で使用されていても、その接続の一意のトラフィックキーを生成できます。一意のトラフィックキーは、外部のキー管理プロパティに依存せずに生成されます。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ペアが不明な場合、たとえば、再起動後にリセット（RST）を送信するとき、セグメントは認証なしで送信する必要があります。認証が必要な場合、セグメントはとにかく適切にマックされておらず、受領時にドロップされていたでしょう。
>> 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 set、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-発信synsの認証に使用されるトラフィックキー。ソース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 受信_syn_traffic_key-着信synを認証するために使用されるトラフィックキー。ソースISNは既知であり（TCP接続のリモートISN）、宛先（リモート）ISNは不明です（したがって、値0が使用されます）。
o Send_other_traffic_key - the traffic key used to authenticate all other outgoing TCP segments.
o send_other_traffic_key-他のすべての発信TCPセグメントを認証するために使用されるトラフィックキー。
o Receive_other_traffic_key - the traffic key used to authenticate all other incoming TCP segments.
o Receive_other_traffic_key-他のすべての着信TCPセグメントを認証するために使用されるトラフィックキー。
The following table describes how each of these traffic keys is computed, where the TCP-AO algorithms refer to source (S) and destination (D) values of the IP address, TCP port, and ISN, and each segment (incoming or outgoing) has a value that refers to the local side of the connection (l) and remote side (r):
次の表は、これらのトラフィックキーのそれぞれがどのように計算されるかを説明します。TCP-AOアルゴリズムは、IPアドレス、TCPポート、およびISN、および各セグメント（着信または発信）のソースと宛先（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]のように、ISNS擬似ランダムリーを選択する必要があります。
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ペアを使用して認証されます。宛先が不明であることは不明ですが、エンドポイントの再起動後、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アルゴリズム、長さ、または接続での使用）のメカニズムを提供しません。MKTの確立、パラメーター交渉、および再キーイングの帯域外メカニズムを想定しています。MKT使用とMKT管理のこの分離は、IPSECスイート[RFC4301] [RFC4306]の分離に似ています。
We encourage users of TCP-AO to apply known techniques for generating appropriate MKTs, including the use of reasonable master key lengths, limited traffic key sharing, and limiting the duration of MKT use [RFC3562]. This also includes the use of per-connection nonces, as suggested in Section 5.2.
TCP-AOのユーザーは、合理的なマスターキーの長さの使用、限られたトラフィックキー共有、MKT使用の期間の制限など、適切なMKTを生成するための既知の手法を適用することをお勧めします[RFC3562]。これには、セクション5.2で示唆されているように、接続ごとのノンセの使用も含まれます。
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は、プロトコルまたは手動手順[RFC4808]を介して、新しいMKTがバンドから交渉および調整されることの再キーリングをサポートしています。新しいMKT使用は、バンド外のメカニズムを使用して調整され、両方のTCPエンドポイントを更新します。一度に単一のMKTのみが使用される場合、無効なMKTの一時的な使用により、セグメントが削除される可能性があります。TCPはすでにそのようなドロップに対して堅牢ですが、TCP-AOはKeyIDフィールドを使用してそのような滴を回避します。特定の接続には、複数のマッチングMKTを持つことができます。キーイドフィールドは、セグメントに使用されるトラフィックキーに対応する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調整メカニズムを提供します。このようなメカニズムは、新しいMKTがインストールされている場合、またはMKTが変更された場合に役立ち、インストールされた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.
ユーザーは、TCP MD5 [RFC3562]を使用する際の主要な管理のためのアドバイスの精神に従ってMKTを管理し、特に適切なキー長（12-24バイト）を使用し、複数のBGPピアリングの配置でMKTを共有することを避けることをお勧めします。
MKTs can be reused across different socket pairs within a host, or across different instances of a socket pair within a host. In either case, replay protection is maintained.
MKTは、ホスト内のさまざまなソケットペア、またはホスト内のソケットペアのさまざまなインスタンスで再利用できます。どちらの場合でも、リプレイ保護が維持されます。
MKTs reused across different socket pairs cannot enable replay attacks because the TCP socket pair is included in the MAC, as well as in the generation of the traffic key. MKTs reused across repeated 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.
さまざまなソケットペアにわたって再利用されるMKTは、TCPソケットペアがMACに含まれており、トラフィックキーの生成に含まれているため、リプレイ攻撃を有効にできません。接続がトラフィックキー生成アルゴリズムに含まれており、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は、シーケンス番号拡張機能（SNE）を使用して、長寿命の接続内でのリプレイ攻撃を防ぎます。外部手段によって達成され、KeyIDフィールドを使用してインデックス化された明示的なMKTロールオーバーは、さまざまな理由（たとえば、人員の離職）でキーイングを変更するために使用できますが、長命の接続をサポートするためには必要ありません。
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は、特に手動キーのみが利用可能な環境で、効率的な使用をサポートするメカニズムを追加します。これらには、以前に説明されたメカニズムが、複数の同時MKTS（KeyIDフィールドを介して）をサポートし、一意の接続ごとのトラフィックキー（KDF経由）を生成するためのメカニズムが含まれます。このセクションでは、MKTの変更を調整し、トラフィックキーが長期間変更されない場合のリプレイ攻撃を防ぐための追加のメカニズムについて説明します。
At any given time, a single TCP connection may have multiple MKTs specified for each segment direction (incoming, outgoing). TCP-AO provides a mechanism to indicate when a new MKT is ready, which allows the sender to commence use of that new MKT. This mechanism allows new MKT use to be coordinated, to avoid unnecessary loss due to sender authentication using an MKT not yet ready at the receiver.
いつでも、単一のTCP接続には、各セグメント方向（着信、発信）に複数のMKTが指定されている場合があります。TCP-AOは、新しいMKTの準備が整うタイミングを示すメカニズムを提供します。これにより、送信者はその新しいMKTの使用を開始できます。このメカニズムにより、新しいMKTの使用を調整することができます。これは、受信機でまだ準備ができていないMKTを使用した送信者認証による不必要な損失を回避するためです。
Note that this is intended as an optimization. Deciding when to start using a key is a performance issue. Deciding when to remove an MKT is a security issue. Invalid MKTs are expected to be removed. TCP-AO provides no mechanism to coordinate their removal, as we consider this a key management operation.
これは最適化として意図されていることに注意してください。キーの使用をいつ開始するかを決定することは、パフォーマンスの問題です。MKTをいつ削除するかを決定することは、セキュリティの問題です。無効なMKTが削除されると予想されます。TCP-AOは、これを主要な管理操作と考えているため、除去を調整するメカニズムを提供しません。
New MKT use is coordinated through two ID fields in the header:
新しいMKT使用は、ヘッダー内の2つのIDフィールドを介して調整されます。
o KeyID
o keyid
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.
o rnextkeyid keyIDは、セグメント送信者がセグメントのMac（発信）を作成するために使用する発信MKT情報と、そのMacを検証するためにセグメントレシーバーが使用する対応する着信情報を表します。その方向にアクティブに使用するMKTのsendidが含まれています。
RNextKeyID represents the preferred MKT information to be used for subsequent received segments ('receive next'). That is, it is a way for the segment sender to indicate a ready incoming MKT for future segments it receives, so that the segment receiver can know when to switch MKTs (and thus their KeyIDs and associated traffic keys). It indicates the RecvID of the MKT desired for incoming segments.
rnextkeyidは、その後の受信セグメント（「次の受信」）に使用される優先されたMKT情報を表します。つまり、セグメント送信者が受信する将来のセグメントの準備が整ったMKTを示す方法であり、セグメントレシーバーがMKT（したがってKeyIDと関連するトラフィックキー）をいつ切り替えるかを知ることができます。これは、着信セグメントを望んでいるMKTのRecvidを示しています。
There are two pointers kept by each side of a connection, as noted in the per-connection information (see Section 4):
接続ごとの情報に記載されているように、接続の両側に保持されている2つのポインターがあります（セクション4を参照）。
o Currently active outgoing MKT (current_key)
o 現在アクティブな発信MKT（current_key）
o Current preference for incoming MKT (rnext_key)
o 着信MKT（RNEXT_KEY）の現在の好み
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).
RNEXT_KEYは、準備ができており、使用することを好む入っているMKTを指しています。接続確立時に、これは現在アクティブな着信MKTを指し示しています。新しいMKTがインストールされたときに変更できます（たとえば、自動MKT管理プロトコル操作またはユーザーマニュアル選択のいずれかによって）。
Rnext_key is changed only by manual user intervention or MKT management protocol operation. It is not manipulated by TCP-AO. Current_key is updated by TCP-AO when processing received TCP segments as discussed in the segment processing description in Section 7.5. Note that the algorithm allows the current_key to change to a new MKT, then change back to a previously used MKT (known as "backing up"). This can occur during an MKT change when segments are received out of order, and is considered a feature of TCP-AO, because reordering does not result in drops. The only way to avoid reuse of previously used MKTs is to remove the MKT when it is no longer considered permitted.
RNEXT_KEYは、手動ユーザー介入またはMKT管理プロトコル操作によってのみ変更されます。TCP-AOによって操作されていません。Current_Keyは、セクション7.5のセグメント処理説明で説明されているように、受信したTCPセグメントを処理するとTCP-AOによって更新されます。アルゴリズムにより、current_keyが新しいMKTに変更し、以前に使用されたMKT（「バックアップ」と呼ばれる）に戻ることができることに注意してください。これは、セグメントが故障していない場合にMKTの変更中に発生する可能性があり、並べ替えがドロップにつながらないため、TCP-AOの特徴と見なされます。以前に使用されていたMKTの再利用を避ける唯一の方法は、MKTが許可されなくなった場合にMKTを除去することです。
TCP uses a 32-bit sequence number, which may, for long-lived connections, roll over and repeat. This could result in TCP segments being intentionally and legitimately replayed within a connection. TCP-AO prevents replay attacks, and thus requires a way to 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の意図は、TCPの32ビットシーケンス番号とともに、64ビット全体のシーケンス番号スペースを提供することです。
For transmitted segments, SND.SNE can be implemented by extending TCP's sequence number to 64 bits; SND.SNE would be the top (high-order) 32 bits of that number. For received segments, TCP-AO needs to emulate the use of a 64-bit number space and correctly infer the appropriate high-order 32-bits of that number as RCV.SNE from the received 32-bit sequence number and the current connection context.
送信されたセグメントの場合、TCPのシーケンス番号を64ビットに拡張することにより、SND.SNEを実装できます。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.
SNESの実装はこのドキュメントでは指定されていませんが、RCV.SNE、SND.SNE、またはその両方に使用できる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つのSNEを使用した実装（SND.SNE、RCV。SNE）、および以下にリストされている追加の変数、すべて初期化されたゼロ、および現在のTCPセグメントフィールド（SEG.SEQ）：
o SND.PREV_SEQ, needed to detect rollover of SND.SEQ
o snd.prev_seq、snd.seqのロールオーバーを検出するために必要です
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o rcv.prev_seq、rcv.seqのロールオーバーを検出するために必要な
o SND.SNE_FLAG, which indicates when to increment the SND.SNE
o snd.sne_flag
o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE
o RCV.SNE_FLAG。これは、RCV.SNEをいつ増加させるかを示します
When a segment is received, the following algorithm (in C-like pseudocode) computes the SNE used in the MAC; this is the "RCV" side, and an equivalent algorithm can be applied to the "SND" side:
セグメントを受信すると、次のアルゴリズム（C様擬似コード）がMACで使用されるSNEを計算します。これは「RCV」側であり、同等のアルゴリズムを「SND」側に適用できます。
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1;
}
/* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value
} else {
SNE = RCV.SNE; # use the current value
}
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.SNE_FLAG = 0;
}
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;
In the above code, the first time the sequence number rolls over, i.e., when the new number is low (in the bottom half of the number space) and the old number is high (in the top half of the number space), the SNE is incremented and a flag is set.
上記のコードでは、シーケンス番号が初めてロールオーバーします。つまり、新しい数値が低い場合（数値の下半分）、古い数値が高い（数字の上半分）、SNEが増加し、フラグが設定されています。
If the flag is set and a high number is seen, it must be a reordered segment, so use the pre-increment SNE; otherwise, use the current SNE.
フラグが設定されていて、高い数が見られる場合は、再注文されたセグメントでなければならないため、事前に挿入されたSNEを使用してください。それ以外の場合は、現在のSNEを使用します。
The flag will be cleared by the time the number rolls all the way around.
フラグは、数がずっと回るまでにクリアされます。
The flag prevents the SNE from being incremented again until the flag is reset, which happens in the middle of the window (when the old number is in the bottom half and the new is in the top half). Because the receive window is never larger than half of the number space, it is impossible to both set and reset the flag at the same time -- outstanding segments, regardless of reordering, cannot straddle both regions simultaneously.
フラグは、フラグがリセットされるまでSNEが再びインクリメントされるのを防ぎます。これは窓の中央で発生します（古い数字が下半分に、新しい数が上半分にある場合）。受信ウィンドウは数値スペースの半分を超えることはないため、同時にフラグを設定してリセットすることは不可能です。並べ替えセグメントは、並べ替えに関係なく、両領域を同時に囲みません。
The following is a description of how TCP-AO affects various TCP states, segments, events, and interfaces. This description is intended to augment the description of TCP as provided in RFC 793, and its presentation mirrors that of RFC 793 as a result [RFC793].
以下は、TCP-AOがさまざまなTCP状態、セグメント、イベント、およびインターフェイスにどのように影響するかの説明です。この説明は、RFC 793で規定されているTCPの説明を強化することを目的としており、そのプレゼンテーションはRFC 793のプレゼンテーションを反映しています[RFC793]。
The TCP user interface supports active and passive OPEN, SEND, RECEIVE, CLOSE, STATUS, and ABORT commands. TCP-AO does not alter this interface as it applies to TCP, but some commands or command sequences of the interface need to be modified to support TCP-AO. TCP-AO does not specify the details of how this is achieved.
TCPユーザーインターフェイスは、アクティブおよびパッシブオープン、送信、受信、閉鎖、ステータス、および中止コマンドをサポートします。TCP-AOはTCPに適用されるため、このインターフェイスを変更しませんが、TCP-AOをサポートするためにインターフェイスのいくつかのコマンドまたはコマンドシーケンスを変更する必要があります。TCP-AOは、これがどのように達成されるかの詳細を指定していません。
TCP-AO requires that the TCP user interface be extended to allow the MKTs to be configured, as well as to allow an ongoing connection to manage which MKTs are active. The MKTs need to be configured prior to connection establishment, and the set of MKTs may change during a connection:
TCP-AOでは、TCPユーザーインターフェイスを拡張してMKTを構成し、継続的な接続がどのMKTがアクティブであるかを管理できるようにする必要があります。MKTは接続確立の前に構成する必要があり、MKTのセットは接続中に変更される場合があります。
>> TCP OPEN, or the sequence of commands that configure a connection to be in the active or passive OPEN state, MUST be augmented so that an MKT can be configured.
>> TCPオープン、またはアクティブまたはパッシブオープン状態に接続を構成するコマンドのシーケンスは、MKTを構成できるように補強する必要があります。
>> A TCP-AO implementation MUST allow the set of MKTs for ongoing TCP connections (i.e., not in the CLOSED state) to be modified.
>> TCP-AOの実装では、進行中のTCP接続（つまり、閉じた状態ではなく）のMKTのセットを変更する必要があります。
The MKTs associated with a connection need to be available for confirmation; this includes the ability to read the MKTs:
接続に関連付けられたMKTSは、確認のために利用できる必要があります。これには、MKTSを読む機能が含まれます。
>> TCP STATUS SHOULD be augmented to allow the MKTs of a current or pending connection to be read (for confirmation).
>> TCPステータスを補強して、電流または保留中の接続のMKTを読み取ることができます（確認用）。
Senders may need to be able to determine when the outgoing MKT changes (KeyID) or when a new preferred MKT (RNextKeyID) is indicated; these changes immediately affect all subsequent outgoing segments:
送信者は、発信MKTがいつ変更されるか（KeyID）、または新しい優先MKT（RNEXTKEYID）がいつ示されているかを判断できる必要がある場合があります。これらの変更は、その後のすべての発信セグメントにすぐに影響します。
>> TCP SEND, or a sequence of commands resulting in a SEND, MUST be augmented so that the preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection can be indicated.
>> TCP送信、または送信をもたらす一連のコマンドを増やす必要があります。これにより、優先されるMKT（current_key）および/または接続の優先受信MKT（RNEXT_KEY）が示されるようにします。
It may be useful to change the outgoing active MKT (current_key) even when no data is being sent, which can be achieved by sending a zero-length buffer or by using a non-send interface (e.g., socket options in Unix), depending on the implementation.
データが送信されていない場合でも、発信アクティブMKT（current_key）を変更すると便利かもしれません。これは、ゼロレングスのバッファーを送信するか、非センドインターフェイス（UNIXのソケットオプションなど）を使用することで達成できます。実装について。
It is also useful to indicate recent segment KeyID and RNextKeyID values received; although there could be a number of such values, they are not expected to change quickly, so any recent sample should be sufficient:
また、最近のセグメントKeyIDおよびRNextKeyID値を受け取った値を示すことも役立ちます。そのような値は多数ある可能性がありますが、それらは迅速に変更されるとは予想されていないため、最近のサンプルで十分なはずです。
>> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, MUST be augmented so that the KeyID and RNextKeyID of a recently received segment is available to the user out of band (e.g., as an additional parameter to RECEIVE or via a STATUS call).
>> TCP受信、または受信を生じるコマンドのシーケンスは、最近受信したセグメントのkeyIDとrNextKeyIDがバンド外のユーザーが利用できるように増強する必要があります（たとえば、受信またはステータスを介して追加のパラメーターとして電話）。
TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and CLOSED.
TCPには、リッスン、シンセント、シンロレット、確立、FIN-WAIT-1、FIN-WAIT-2、クローズウェイト、クロージング、ラストク、タイムウェイト、および閉鎖された州が含まれます。
>> 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 Flags Setの少なくとも1つ）とデータ（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と一致しません。この構成の最初のデフォルトは、そのような接続を静かに受け入れることです。これが望ましいケースではない場合、そのような接続に一致するために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.
>>サイレント廃棄イベントは警告としてユーザーに信号を送信する必要があり、警告としてサイレント受け入れイベントがユーザーに通知される場合があります。両方の警告は、利用可能な場合は、ステータスインターフェイスからアクセスできる必要があります。どちらの信号も非同期である可能性がありますが、もしそうなら、それらは料金制限されている必要があります。いずれかの信号が記録される場合があります。ロギングは、料金制限も可能にするはずです。
All TCP-AO processing occurs between the interface of TCP and IP; for incoming segments, this occurs after validation of the TCP checksum. For outgoing segments, this occurs before computation of the TCP checksum.
すべてのTCP-AO処理は、TCPとIPのインターフェイス間で発生します。着信セグメントの場合、これはTCPチェックサムの検証後に発生します。発信セグメントの場合、これはTCPチェックサムの計算前に発生します。
Note that use of TCP-AO on a connection is not negotiated within TCP. It is the responsibility of the receiver to determine when TCP-AO is required via other means (e.g., out of band, manually or with a key management protocol) and to enforce that requirement.
接続でのTCP-AOの使用は、TCP内で交渉されないことに注意してください。TCP-AOが他の手段（例えば、手動で、または主要な管理プロトコルを使用して）を介して必要な時期を決定し、その要件を実施することは、受信者の責任です。
The following procedure describes the modifications to TCP to support inserting TCP-AO when a segment departs.
次の手順では、セグメントが出発したときにTCP-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オプションでなければならないことに注意してください。
1. Find the per-connection parameters for the segment:
1. セグメントの接続ごとのパラメーターを見つけます。
a. If the segment is a SYN, then this is the first segment of a new connection. Find the matching MKT for this segment based on the segment's socket pair.
a. セグメントがsynの場合、これは新しい接続の最初のセグメントです。セグメントのソケットペアに基づいて、このセグメントの一致するMKTを見つけます。
i. If there is no matching MKT, omit TCP-AO. Proceed with transmitting the segment.
i. 一致するMKTがない場合は、TCP-AOを省略します。セグメントの送信を進めます。
ii. If there is a matching MKT, then set the per-connection parameters as needed (see Section 4). Proceed with the step 2.
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が接続に使用されているかどうかを判断し、接続ごとのパラメーター（セクション4を参照）のcurrent_key値で示されているようにMKTを使用し、ステップ2を進めます。
2. Using the per-connection parameters:
2. 接続ごとのパラメーターの使用：
a. Augment the TCP header with TCP-AO, inserting the appropriate Length and KeyID based on the MKT indicated by current_key (using the current_key MKT's SendID as the TCP-AO KeyID). Update the TCP header length accordingly.
a. TCPヘッダーをTCP-AOで拡張し、Current_Key（Current_Key MKTのsendIDをTCP-AO keyIDとして使用する）で示されたMKTに基づいて適切な長さとkeyIDを挿入します。それに応じてTCPヘッダーの長さを更新します。
b. Determine SND.SNE as described in Section 6.2.
b. セクション6.2で説明されているように、SND.SNEを決定します。
c. Determine the appropriate traffic key, i.e., as pointed to by the current_key (as noted in Section 6.1, and as probably cached in the TCB). That is, use the send_SYN_traffic_key for SYN segments and the send_other_traffic_key for other segments.
c. 適切なトラフィックキー、つまり、current_key（セクション6.1に記載されているとおり、おそらくTCBでキャッシュされているように）が指摘したように、適切なトラフィックキーを決定します。つまり、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. RNEXT_KEYポインターで示されているようにrNextKeyIDを決定し、TCP-AO RNEXTKEYIDフィールドに挿入します（RNEXT_KEY MKTのRecvidをTCP-AO KeyIDとして使用して）（セクション6.1に記載）。
e. Compute the MAC using the MKT (and cached traffic key) and data from the segment as specified in Section 5.1.
e. セクション5.1で指定されているように、MKT（およびキャッシュされたトラフィックキー）とセグメントからのデータを使用してMACを計算します。
f. Insert the MAC in the TCP-AO MAC field.
f. TCP-AO MACフィールドにMacを挿入します。
g. Proceed with transmitting the segment.
g. セグメントの送信を進めます。
The following procedure describes the modifications to TCP to support TCP-AO when a segment arrives.
次の手順では、セグメントが到着したときにTCP-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を欠くSynを受け入れないように、すべての着信Synsに対してTCP-AOチェックを実行する必要があることに注意してください。他のセグメントは、TCBでTCP-AOが必要かどうかをキャッシュできます。
1. Find the per-connection parameters for the segment:
1. セグメントの接続ごとのパラメーターを見つけます。
a. If the segment is a SYN, then this is the first segment of a new connection. Find the matching MKT for this segment, using the segment's socket pair and its TCP-AO KeyID, matched against the MKT's TCP connection identifier and the MKT's RecvID.
a. セグメントがsynの場合、これは新しい接続の最初のセグメントです。MKTのTCP接続識別子とMKTのRecvidと一致する、セグメントのソケットペアとそのTCP-AO KeyIDを使用して、このセグメントの一致するMKTを見つけます。
i. If there is no matching MKT, remove TCP-AO from the segment. Proceed with further TCP handling of the segment.
i. 一致するMKTがない場合は、セグメントからTCP-AOを削除します。セグメントのさらにTCP処理を続行します。
NOTE: this presumes that connections that do not match any MKT should be silently accepted, as noted in Section 7.3.
注：これは、セクション7.3に記載されているように、MKTと一致しない接続を静かに受け入れるべきであると推定しています。
ii. If there is a matching MKT, then set the per-connection parameters as needed (see Section 4). Proceed with step 2.
ii。一致するMKTがある場合は、必要に応じて接続ごとのパラメーターを設定します（セクション4を参照）。ステップ2を進みます。
2. Using the per-connection parameters:
2. 接続ごとのパラメーターの使用：
a. Check that the segment's TCP-AO Length matches the length indicated by the MKT.
a. セグメントのTCP-AOの長さがMKTで示されている長さと一致することを確認します。
i. If the lengths differ, silently discard the segment. Log and/or signal the event as indicated in Section 7.3.
i. 長さが異なる場合は、セグメントを静かに破棄します。セクション7.3に示されているように、イベントをログおよび/または信号します。
b. Determine the segment's RCV.SNE as described in Section 6.2.
b. セクション6.2で説明されているように、セグメントのRCV.SNEを決定します。
c. Determine the segment's traffic key from the MKT as described in Section 5.1 (and as likely cached in the TCB). That is, use the receive_SYN_traffic_key for SYN segments and the receive_other_traffic_key for other segments.
c. セクション5.1で説明されているように、MKTからセグメントのトラフィックキーを決定します（およびTCBでキャッシュされる可能性があります）。つまり、Syn SegmentsにはReceed_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.
i. 計算されたMACがTCP-AO MACフィールド値と異なる場合、セグメントを静かに破棄します。セクション7.3に示されているように、イベントをログおよび/または信号します。
e. Compare the received RNextKeyID value to the currently active outgoing KeyID value (current_key MKT's SendID).
e. 受信したrNextKeyID値を、現在アクティブに発信しているKeyID値（current_key mktのsendid）と比較してください。
i. If they match, no further action is required.
i. それらが一致する場合、それ以上のアクションは必要ありません。
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).
1. セグメントのソケットペアとrNextKeyIDに対応するMKTが利用できない場合、アクションは必要ありません（受信したセグメントのRNEXTKEYIDは、MKTのSendIDと一致する必要があります）。
2. If the matching MKT corresponding to the segment's socket pair and RNextKeyID is available:
2. セグメントのソケットペアとrnextKeyIDに対応する一致するMKTが利用可能な場合：
a. Set current_key to the RNextKeyID MKT.
a. current_keyをrnextkeyid mktに設定します。
f. Proceed with TCP processing of the segment.
f. セグメントのTCP処理を進めます。
It is suggested that TCP-AO implementations validate a segment's Length field before computing a MAC to reduce the overhead incurred by spoofed segments with invalid TCP-AO fields.
TCP-AOの実装は、MACを計算して、無効なTCP-AOフィールドを持つスプーフィングされたセグメントによって発生したオーバーヘッドを減らす前に、セグメントの長さフィールドを検証することをお勧めします。
Additional reductions in MAC validation overhead can be supported in the MAC algorithms, e.g., by using a computation algorithm that prepends a fixed value to the computed portion and a corresponding validation algorithm that verifies the fixed value before investing in the computed portion. Such optimizations would be contained in the MAC algorithm specification, and thus are not specified in TCP-AO explicitly. Note that the KeyID cannot be used for connection validation per se, because it is not assumed random.
MAC検証オーバーヘッドの追加の削減は、MACアルゴリズムでサポートできます。たとえば、計算された部分に固定値を準備する計算アルゴリズムと、計算された部分に投資する前に固定値を検証する対応する検証アルゴリズムを使用することにより。このような最適化は、MACアルゴリズムの仕様に含まれるため、TCP-AOで明示的に指定されていません。KeyIDは、ランダムと想定されていないため、接続検証自体に使用できないことに注意してください。
TCP-AO, using the initially required 96-bit MACs, uses a total of 16 bytes of TCP header space [RFC5926]. TCP-AO is thus 2 bytes smaller than the TCP MD5 option (18 bytes).
TCP-AOは、最初に必要な96ビットMacを使用して、合計16バイトのTCPヘッダースペース[RFC5926]を使用します。したがって、TCP-AOは、TCP MD5オプション（18バイト）よりも2バイトが小さくなります。
Note that the TCP option space is most critical in SYN segments, because flags in those segments could potentially increase the option space area in other segments. Because TCP ignores unknown segments, however, it is not possible to extend the option space of SYNs without breaking backward compatibility.
これらのセグメントのフラグが他のセグメントのオプションスペース領域を増加させる可能性があるため、TCPオプションスペースはSynセグメントで最も重要であることに注意してください。ただし、TCPは未知のセグメントを無視するため、逆方向の互換性を破ることなく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ビットワード）を終了する必要があります。これにより、オプションの40バイトが残り、そのうち15は現在の実装（以下にリスト）で予想され、他の用途には最大25が残ります。TCP-AOは16バイトを消費し、追加のSynオプションのために9バイトを残します（実装依存のアライメントパディングに応じて、最大でさらに2バイトを消費する可能性があります）。
o SACK permitted (2 bytes) [RFC2018][RFC3517]
o SACK PROTENED（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]（d-sackの場合18バイト[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 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.
TCP-AOは、非シンセグメントで16バイトを消費し続け、他のオプションに合計24バイトを残し、そのうちタイムスタンプが消費します。D-Sackを処理するなどの2つのサックブロックを使用すると、追加のサックブロックのスペースを確保するために、より小さなTCP-AO MACが必要になります（つまり、サックオプションのDサックバリアントに18バイトを残すため）[RFC2883]。TCP MD5のMacの長さが固定されており、十分なオプションスペースを残すには大きすぎるため、TCP MD5ではD-Sackがサポートできないことに注意してください。
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リセット（RSTS）を交換することができます。そのような状態が確立された後、1つのサイド再起動の場合、TCP-AOはTCPのRSTメカニズムが再起動しなかった側の古い状態をクリアすることを防ぎます。これは、再起動側が接続状態、したがってトラフィックキーを失ったために発生します。
It is important that implementations are capable of detecting excesses of TCP connections in such a configuration and can clear them out if needed to protect its memory usage [Ba10]. To protect against such state from accumulating and not being cleared out, a number of recommendations are made:
実装は、このような構成でTCP接続の過剰を検出できることが重要であり、メモリ使用量を保護するために必要に応じてそれらをクリアすることができます[BA10]。そのような状態を蓄積し、クリアされないように保護するために、多くの推奨事項が作成されます。
>> Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122].
>> TCP-AOを使用した接続は、TCP KeepAlives [RFC1122]も使用する必要があります。
The use of TCP keepalives ensures that connections whose keys are lost are terminated after a finite time; a similar effect can be achieved at the application layer, e.g., with BGP keepalives [RFC4271]. Either kind of keepalive helps ensure the TCP state is cleared out in such a case; the alternative, of allowing unauthenticated RSTs to be received, would allow one of the primary vulnerabilities that TCP-AO is intended to prevent.
TCP Keepalivesの使用により、キーが失われた接続が有限時間の後に終了することが保証されます。同様の効果は、たとえばBGP Keepalives [RFC4271]で、アプリケーション層で達成できます。どちらかの種類のキープライブは、そのようなケースでTCP状態を確実に解除するのに役立ちます。認定されていないRSTを受信できるようにする代替案により、TCP-AOが防止することを目的とした主要な脆弱性の1つが可能になります。
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:
Keepaliveは、再起動全体で接続がドロップされることを保証しますが、これは一部のプロトコルに有害な影響を与える可能性があります。具体的には、BGPのキープライブの使用が原因であっても、BGPはそのような接続ドロップとは不十分です。「Graceful Restart」がこの効果に対処するために導入され[RFC4724]、MPLS [RFC4781]でBGPをサポートするように拡張されました。結果として：
>> BGP connections SHOULD require support for graceful restart when using TCP-AO.
>> BGP接続には、TCP-AOを使用する際に優雅な再起動のサポートが必要です。
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（宛先の到達不能）、コード2-4（到達不能、到達不能、ポート、断片化が必要な断片化 - 「ハードエラー」）の受信ICMPV4メッセージを無視するためにデフォルトでなければなりません。到達不能）、同期された状態（確立、FIN-WAIT-1、FIN-WAIT-2、閉鎖、閉鎖、ラストクロウム、タイムウェイトを対象としたコード1（管理上禁止）およびコード4（到達不能））MKTSに一致します。
>> A TCP-AO implementation SHOULD allow whether such ICMPs are ignored to be configured on a per-connection basis.
>> TCP-AOの実装では、そのようなICMPが接続ごとに構成されているかどうかを無視するかどうかを許可する必要があります。
>> A TCP-AO implementation SHOULD implement measures to protect ICMP "packet too big" messages, some examples of which are discussed in [Go10].
>> TCP-AOの実装では、ICMP「パケットが大きすぎる」メッセージを保護するための措置を実装する必要があります。その例については[GO10]で説明します。
>> An implementation SHOULD allow ignored ICMPs to be logged.
>>実装を使用すると、無視されたICMPを記録できるようにする必要があります。
This control affects only ICMPs that currently require 'hard errors', which would abort the TCP connection [RFC1122]. This recommendation is intended to be similar to how IPsec would handle those messages, with an additional default assumed [RFC4301].
このコントロールは、現在「ハードエラー」を必要とするICMPのみに影響し、TCP接続[RFC1122]を中止します。この推奨事項は、IPSECがこれらのメッセージを処理する方法に似ていることを目的としており、追加のデフォルトが想定されています[RFC4301]。
TCP-AO obsoletes TCP MD5. As we have noted earlier:
TCP-AO OBESOLETES TCP MD5。先に述べたように：
>> TCP implementations that support TCP MD5 MUST support TCP-AO.
>> TCP MD5をサポートするTCP実装は、TCP-AOをサポートする必要があります。
Systems implementing TCP MD5 only are considered legacy, and ought to be upgraded when possible. In order to support interoperation with such legacy systems until upgrades are available:
TCP MD5を実装するシステムは、レガシーのみと見なされるため、可能な場合はアップグレードする必要があります。アップグレードが利用可能になるまで、そのようなレガシーシステムとの相互操作をサポートするために：
>> TCP MD5 SHOULD be supported where interactions with legacy systems are needed.
>> TCP MD5は、レガシーシステムとの相互作用が必要な場合にサポートする必要があります。
>> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for connections unless not supported by its peer, at which point it MAY use TCP MD5 instead.
>> TCP-AOとTCP MD5の両方をサポートするシステムは、ピアによってサポートされていない限り、接続にTCP-AOを使用する必要があります。その時点では、代わりにTCP MD5を使用できます。
>> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a particular TCP connection, but MAY support TCP-AO and TCP MD5 simultaneously for different connections (notably to support legacy use of TCP MD5).
>> TCP実装は、特定のTCP接続にTCP-AOとTCP MD5の両方を使用しないでください。さまざまな接続に対してTCP-AOとTCP MD5を同時にサポートする場合があります（特にTCP MD5のレガシー使用をサポートするため）。
The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used for a particular connection in TCP segments.
種類の値は、TCP-AOまたはTCP MD5がTCPセグメントの特定の接続に使用されるかどうかを明示的に示します。
It is possible that MKTs could be augmented to support TCP MD5, although use of MKTs is not described in RFC 2385.
MKTSの使用はRFC 2385では説明されていませんが、TCP MD5をサポートするためにMKTを増強する可能性があります。
It is possible to require TCP-AO for a connection or TCP MD5, but it is not possible to require 'either'. When an endpoint is configured to require TCP MD5 for a connection, it must be added to all outgoing segments and validated on all incoming segments [RFC2385]. TCP MD5's requirements prohibit the speculative use of both options for a given connection, e.g., to be decided by the other end of the connection.
接続またはTCP MD5にTCP-AOを要求することは可能ですが、「どちらも」を要求することはできません。エンドポイントが接続にTCP MD5を要求するように構成されている場合、すべての発信セグメントに追加され、すべての着信セグメント[RFC2385]で検証する必要があります。TCP MD5の要件は、特定の接続の両方のオプションの投機的使用を禁止しています。たとえば、接続のもう一方の端によって決定されます。
TCP-AO may interact with middleboxes, depending on their behavior [RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO) directly or alter the information TCP-AO includes in its MAC calculation. TCP-AO may interfere with these devices, exactly where the device modifies information TCP-AO is designed to protect.
TCP-AOは、動作に応じてミドルボックスと相互作用する場合があります[RFC3234]。一部のミドルボックスは、TCPオプション（TCP-AOなど）を直接変更するか、TCP-AOがMAC計算に含む情報を変更します。TCP-AOは、これらのデバイスを妨害する可能性があります。これは、デバイスが情報を修正する場所TCP-AOが保護するように設計されていることです。
TCP-AO supports middleboxes that do not change the IP addresses or ports of segments. Such middleboxes may modify some TCP options, in which case TCP-AO would need to be configured to ignore all options in the MAC calculation on connections traversing that element.
TCP-AOは、セグメントのIPアドレスやポートを変更しないミドルボックスをサポートしています。このようなミドルボックスは、いくつかのTCPオプションを変更する場合があります。この場合、TCP-AOを構成する必要があります。その要素を通過する接続のMAC計算のすべてのオプションを無視する必要があります。
Note that ignoring TCP options may provide less protection, i.e., TCP options could be modified in transit, and such modifications could be used by an attacker. Depending on the modifications, TCP could have compromised efficiency (e.g., timestamp changes), or could cease correct operation (e.g., window scale changes). These vulnerabilities affect only the TCP connections for which TCP-AO is configured to ignore TCP options.
TCPオプションを無視すると、保護が少なくなる可能性があります。つまり、TCPオプションは輸送中に変更される可能性があり、そのような変更は攻撃者が使用できることに注意してください。修正に応じて、TCPは効率を損なう可能性があり（例：タイムスタンプの変更）、または正しい操作（例：ウィンドウスケールの変更）を停止する可能性があります。これらの脆弱性は、TCP-AOがTCPオプションを無視するように構成されているTCP接続のみに影響します。
TCP-AO cannot interoperate natively across NAT/NAPT (Network Address Port Translation) devices, which modify the IP addresses and/or port numbers. We anticipate that traversing such devices may require variants of existing NAT/NAPT traversal mechanisms, e.g., encapsulation of the TCP-AO-protected segment in another transport segment (e.g., UDP), as is done in IPsec [RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO, or IPsec with NAT traversal can be used instead of TCP-AO in such cases [RFC3947].
TCP-AOは、IPアドレスおよび/またはポート番号を変更するNAT/NAPT（ネットワークアドレスポート変換）デバイス全体でネイティブに相互操作することはできません。このようなデバイスをトラバースすると、IPSEC [RFC2663] [RFC3947]で行われるように、別の輸送セグメント（例：UDP）におけるTCP-AO保護セグメントのカプセル化、既存のNAT/NAPTトラバーサルメカニズムのバリエーションが必要になる場合があります。このようなバリアントは、TCP-AOで使用するために適合させることができます。または、そのような場合にはTCP-AOの代わりにNATトラバーサルを使用して使用できます[RFC3947]。
An alternate proposal for accommodating NATs extends TCP-AO independently of this specification [To10].
NATを収容するための別の提案は、この仕様とは無関係にTCP-AOを拡張します[TO10]。
TCP-AO satisfies all the current requirements for a revision to TCP MD5, as summarized below [Ed07].
TCP-AOは、以下に要約されているように、TCP MD5の改訂の現在のすべての要件を満たしています。
1. Protected Elements
1. 保護された要素
A solution to revising TCP MD5 should protect (authenticate) the following elements.
TCP MD5を修正するためのソリューションは、次の要素を保護（認証）する必要があります。
This is supported -- see Section 5.1.
これがサポートされています - セクション5.1を参照してください。
a. IP pseudoheader, including IPv4 and IPv6 versions.
a. 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オプションを除外することを可能にし、オプションを変更するミドルボックスでの使用を可能にすることができることに注意してください（TCP-AO自体を変更する場合を除く）。セクション9を参照してください。
d. TCP payload data.
d. TCPペイロードデータ。
2. Option Structure Requirements
2. オプション構造要件
A solution to revising TCP MD5 should use an option with the following structural requirements.
TCP MD5を修正するためのソリューションは、次の構造要件を備えたオプションを使用する必要があります。
This is supported -- see Section 5.1.
これがサポートされています - セクション5.1を参照してください。
a. Privacy.
a. プライバシー。
The option should not unnecessarily expose information about the TCP-AO mechanism. The additional protection afforded by keeping this information private may be of little value, but also helps keep the option size small.
オプションは、TCP-AOメカニズムに関する情報を不必要に公開してはなりません。この情報をプライベートに保つことで得られる追加の保護は、ほとんど価値がないかもしれませんが、オプションサイズを小さく保つのにも役立ちます。
TCP-AO exposes only the MKT IDs, MAC, and overall option length on the wire. Note that short MACs could be obscured by using longer option lengths but specifying a short MAC length (this is equivalent to a different MAC algorithm, and is specified in the MKT). See Section 2.2.
TCP-AOは、ワイヤー上のMKT ID、Mac、および全体的なオプション長のみを公開します。短いオプションの長さを使用するが、短いMacの長さを指定することにより、短いMacは不明瞭になる可能性があることに注意してください（これは異なるMacアルゴリズムに相当し、MKTで指定されています）。セクション2.2を参照してください。
b. Allow optional per connection.
b. 接続ごとにオプションを許可します。
The option should not be required on every connection; it should be optional on a per-connection basis.
すべての接続でオプションを必要としないでください。接続ごとにオプションである必要があります。
This is supported because the set of MKTs can be installed to match some connections and not others. Connections not matching any MKT do not require TCP-AO. Further, incoming segments with TCP-AO are not discarded solely because they include the option, provided they do not match any MKT.
これは、MKTのセットをインストールして、他の接続ではなくいくつかの接続に合わせてインストールできるため、サポートされています。MKTと一致しない接続では、TCP-AOは必要ありません。さらに、TCP-AOを使用した入っているセグメントは、MKTと一致しない限り、オプションを含めるという理由だけで廃棄されません。
c. Require non-optional.
c. 非オプションが必要です。
The option should be able to be specified as required for a given connection.
オプションは、特定の接続に必要に応じて指定できる必要があります。
This is supported because the set of MKTs can be installed to match some connections and not others. Connections matching any MKT require TCP-AO.
これは、MKTのセットをインストールして、他の接続ではなくいくつかの接続に合わせてインストールできるため、サポートされています。MKTに一致する接続には、TCP-AOが必要です。
d. Standard parsing.
d. 標準解析。
The option should be easily parseable, i.e., without conditional parsing, and follow the standard RFC 793 option format.
オプションは簡単に解析可能である必要があります。つまり、条件付き解析なしで、標準のRFC 793オプション形式に従います。
This is supported -- see Section 2.2.
これがサポートされています - セクション2.2を参照してください。
e. Compatible with Large Windows and SACK.
e. 大きな窓と袋と互換性があります。
The option should be compatible with the use of the Large Windows and SACK options.
オプションは、大きなWindowsと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を参照してください。オプションのサイズは、大きな窓と袋で使用できるようにすることを目的としています。セクション1.3も参照してください。これは、96ビットMACを想定して、デフォルトのケースでTCP-AOがTCP MD5よりも2バイト短いことを示しています。
3. Cryptography requirements
3. 暗号化の要件
A solution to revising TCP MD5 should support modern cryptography capabilities.
TCP MD5を改訂するソリューションは、最新の暗号化機能をサポートする必要があります。
a. Baseline defaults.
a. ベースラインのデフォルト。
The option should have a default that is required in all implementations.
オプションには、すべての実装で必要なデフォルトが必要です。
TCP-AO uses a default required algorithm as specified in [RFC5926] and as noted in Section 5.1 of this document.
TCP-AOは、[RFC5926]で指定されており、このドキュメントのセクション5.1で述べたように、デフォルトの必要なアルゴリズムを使用します。
b. Good algorithms.
b. 良いアルゴリズム。
The option should use algorithms considered accepted by the security community, which are considered appropriately safe. The use of non-standard or unpublished algorithms should be avoided.
このオプションは、適切に安全であると見なされるセキュリティコミュニティによって受け入れられたと見なされるアルゴリズムを使用する必要があります。非標準または未発表のアルゴリズムの使用は避ける必要があります。
TCP-AO uses MACs as indicated in [RFC5926]. The KDF is also specified in [RFC5926]. The KDF input string follows the typical design (see [RFC5926]).
TCP-AOは[RFC5926]に示されているようにMacを使用します。KDFは[RFC5926]でも指定されています。KDF入力文字列は、典型的な設計に従います（[RFC5926]を参照）。
c. Algorithm agility.
c. アルゴリズムの俊敏性。
The option should support algorithms other than the default, to allow agility over time.
このオプションは、デフォルト以外のアルゴリズムをサポートし、時間の経過とともに敏ility性を可能にする必要があります。
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.
TCP-AOは、セクション2.2に記載されているように、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セグメントの処理を許可する必要があります。これにより、処理前に並べ替える必要がなくなり、オプションに対する誤った秩序化セグメントの影響が回避されます。
This is supported -- see Sections 7.3, 7.4, and 7.5. Note that pre-TCP processing is further required, because TCP segments cannot be discarded solely based on a combination of connection state and out-of-window checks; many such segments, although discarded, cause a host to respond with a replay of the last valid ACK, e.g., [RFC793]. See also the derivation of the SNE, which is reconstituted at the receiver using a demonstration algorithm that avoids the need for reordering (in Section 6.2).
これはサポートされています - セクション7.3、7.4、および7.5を参照してください。TCPセグメントは、接続状態とウィンドウ外のチェックの組み合わせのみに基づいて廃棄できないため、さらにTCP処理がさらに必要であることに注意してください。そのようなセグメントの多くは、廃棄されていますが、宿主は最後の有効なACKのリプレイで応答します[RFC793]。また、並べ替えの必要性を回避する実証アルゴリズムを使用して、レシーバーに再構成されたSNEの導出も参照してください（セクション6.2）。
e. Security parameter changes require key changes.
e. セキュリティパラメーターの変更には、重要な変更が必要です。
The option should require that the MKT change whenever the security parameters change. This avoids the need for coordinating option state during a connection, which is typical for TCP options. This also helps allow "bump in the stack" implementations that are not integrated with endpoint TCP implementations.
このオプションでは、セキュリティパラメーターが変更されるたびにMKTを変更する必要があります。これにより、TCPオプションに典型的な接続中にオプション状態を調整する必要がなくなります。これにより、エンドポイントTCP実装と統合されていない「スタックのバンプ」実装が可能になります。
Parameters change only when a new MKT is used. See Section 3.
パラメーターは、新しいMKTが使用される場合にのみ変更されます。セクション3を参照してください。
4. Keying requirements.
4. キーイング要件。
A solution to revising TCP MD5 should support manual keying, and should support the use of an external automated key management system (e.g., a protocol or other mechanism).
TCP MD5を修正するためのソリューションは、マニュアルキーイングをサポートする必要があり、外部自動化されたキー管理システム（たとえば、プロトコルやその他のメカニズム）の使用をサポートする必要があります。
Note that TCP-AO does not specify an MKT management system.
TCP-AOはMKT管理システムを指定していないことに注意してください。
a. Intraconnection rekeying.
a. 接続内の再キーイング。
The option should support rekeying during a connection, to avoid the impact of long-duration connections.
オプションは、長期的な接続の影響を回避するために、接続中の再キーイングをサポートする必要があります。
This is supported by the use of IDs and multiple MKTs; see Section 3.
これは、IDと複数のMKTの使用によってサポートされています。セクション3を参照してください。
b. Efficient rekeying.
b. 効率的な再キーイング。
The option should support rekeying during a connection without the need to expend undue computational resources. In particular, the options should avoid the need to try multiple keys on a given segment.
このオプションは、過度の計算リソースを消費する必要なく、接続中に再キーイングをサポートする必要があります。特に、オプションは、特定のセグメントで複数のキーを試す必要性を回避する必要があります。
This is supported by the use of the KeyID. See Section 6.1.
これは、KeyIDの使用によってサポートされています。セクション6.1を参照してください。
c. Automated and manual keying.
c. 自動化されたマニュアルキーイング。
The option should support both automated and manual keying.
オプションは、自動キーと手動のキーイングの両方をサポートする必要があります。
The use of MKTs allows external automated and manual keying. See Section 3. This capability is enhanced by the generation of unique per-connection keys, which enables use of manual MKTs with automatically generated traffic keys as noted in Section 5.2.
MKTを使用すると、外部の自動化と手動キーが可能になります。セクション3を参照してください。この機能は、セクション5.2に記載されているように、自動的に生成されたトラフィックキーを使用して、マニュアルMKTを使用できる一意の接続ごとのキーの生成によって強化されます。
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を参照してください。
5. Expected Constraints
5. 予想される制約
A solution to revising TCP MD5 should also abide by typical safe security practices.
TCP MD5を修正するためのソリューションは、典型的な安全なセキュリティ慣行も順守する必要があります。
a. Silent failure.
a. 静かな失敗。
Receipt of segments failing authentication must result in no visible external action and must not modify internal state, and those events should be logged.
認証に失敗したセグメントの受領は、目に見える外部アクションにつながる必要があり、内部状態を変更してはならず、それらのイベントを記録する必要があります。
This is supported - see Sections 7.3, 7.4, and 7.5.
これがサポートされています - セクション7.3、7.4、および7.5を参照してください。
b. At most one such option per segment.
b. せいぜいそのようなオプション自体セグメント。
Only one authentication option can be permitted per segment.
1つの認証オプションのみを許可できます。
This is supported by the protocol requirements - see Section 2.2.
これは、プロトコル要件によってサポートされています - セクション2.2を参照してください。
c. Outgoing all or none.
c. すべてまたはなし。
Segments out of a TCP connection are either all authenticated or all not authenticated.
TCP接続からのセグメントは、すべて認証されているか、すべて認証されていません。
This is supported - see Section 7.4.
これがサポートされています - セクション7.4を参照してください。
d. Incoming all checked.
d. すべてチェックします。
Segments into a TCP connection are always checked to determine whether their authentication should be present and valid.
TCP接続へのセグメントは常にチェックされ、認証が存在して有効かどうかを判断します。
This is supported - see Section 7.5.
これがサポートされています - セクション7.5を参照してください。
e. Non-interaction with TCP MD5.
e. TCP MD5との非操作。
The use of this option for a given connection should not preclude the use of TCP MD5, e.g., for legacy use, for other connections.
特定の接続にこのオプションを使用すると、他の接続に対するレガシーの使用など、TCP MD5の使用を排除するものではありません。
This is supported - see Section 8.
これがサポートされています - セクション8を参照してください。
f. "Hard" ICMP discard.
f. 「ハード」ICMP廃棄。
The option should allow certain ICMPs to be discarded, notably Type 3 (destination unreachable), Codes 2-4 (transport protocol unreachable, port unreachable, or fragmentation needed and IP DF field set), i.e., the ones indicating the failure of the endpoint to communicate.
オプションにより、特定のICMPを破棄する必要があります。特にタイプ3（宛先の到達不能）、コード2-4（輸送プロトコルが到達不能、ポートが到達できない、または断片化が必要です、IP DFフィールドセット）、つまりエンドポイントの障害を示すものを示す必要があります。コミュニケーションをとること。
This is supported - see Section 7.8.
これがサポートされています - セクション7.8を参照してください。
g. Maintain TCP connection semantics, in which the socket pair alone defines a TCP association and all its security parameters.
g. ソケットペアだけがTCP関連とそのすべてのセキュリティパラメーターを定義するTCP接続セマンティクスを維持します。
This is supported - see Sections 3 and 9.
これがサポートされています - セクション3および9を参照してください。
Use of TCP-AO, like the use of TCP MD5 or IPsec, will impact host performance. Connections that are known to use TCP-AO can be attacked by transmitting segments with invalid MACs. Attackers would need to know only the TCP connection ID and TCP-AO Length value to substantially impact the host's processing capacity. This is similar to the susceptibility of IPsec to on-path attacks, where the IP addresses and SPI would be visible. For IPsec, the entire SPI space (32 bits) is arbitrary, whereas for routing protocols typically only the source port (16 bits) is arbitrary (typically with less than 16 bits of randomness [La10]). As a result, it would be easier for an off-path attacker to spoof a TCP-AO segment that could cause receiver validation effort. However, we note that between Internet routers, both ports could be arbitrary (i.e., determined a priori out of band), which would constitute roughly the same off-path antispoofing protection of an arbitrary SPI.
TCP MD5やIPSECの使用など、TCP-AOの使用は、ホストのパフォーマンスに影響を与えます。TCP-AOを使用することが知られている接続は、無効なMACを使用してセグメントを送信することで攻撃できます。攻撃者は、ホストの処理能力に実質的に影響を与えるために、TCP接続IDとTCP-AOの長さの値のみを知る必要があります。これは、IPアドレスとSPIが表示されるパス攻撃に対するIPSECの感受性に似ています。IPSECの場合、SPIスペース全体（32ビット）は任意ですが、ルーティングプロトコルの場合は通常、ソースポート（16ビット）のみが任意です（通常、16ビット未満のランダム性[LA10]）。その結果、オフパスの攻撃者が受信機の検証努力を引き起こす可能性のある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.
TCP-AOには、予想されるTCP-AOなしでsyn-ackが受信され、接続が迅速にリセットまたは中止される速度の低下能力は含まれていません。通常のTCP操作は再試行とタイムアウトになります。これは、意図したレシーバーがとにかく必要とされるTCPバリアントが不可能である場合に予想されるべきことです。バックオフは、TCP-AOなしでスプーフィングされたsyn-ackを送信することにより、攻撃者が認証された接続試行を中止する機会を提供するため、最適化されていません。
TCP-AO is intended to provide similar protections to IPsec, but is not intended to replace the use of IPsec or IKE either for more robust security or more sophisticated security management. TCP-AO is intended to protect the TCP protocol itself from attacks that TLS, sBGP/soBGP, and other data stream protection mechanisms cannot. Like IPsec, TCP-AO does not address the overall issue of ICMP attacks on TCP, but does limit the impact of ICMPs, as noted in Section 7.8.
TCP-AOは、IPSECに同様の保護を提供することを目的としていますが、より堅牢なセキュリティまたはより洗練されたセキュリティ管理のために、IPSECまたはIKEの使用を置き換えることを意図していません。TCP-AOは、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（何らかの理由で）を使用して異なる同時接続を防ぎます（何らかの理由で）潜在的にトラフィックを巡る攻撃を可能にすることから、1つのソケットペアへのセグメントが異なるソケットペアを攻撃するように迂回します。複数の接続が同じMKTを使用している場合、1つのIDを意図したセグメントが輸送中に（悪意に違いないか、そうでないか）修正できず、他のIDに対して認証されることができないことを知ることが有用です。その要件は、エンドシステム内のMKTSに、および潜在的にエンドシステム全体に潜在的に一意性の負担をかけるでしょう。結果として生じる攻撃は低い確率ですが、受け取ったIDを含めることによって得られる保護はMACに含まれることを保証し、MAC計算またはMKT管理を過度に増やすことはありません。
The use of any security algorithm can present an opportunity for a CPU Denial-of-Service (DoS) attack, where the attacker sends false, random segments that the receiver under attack expends substantial CPU effort to reject. In IPsec, such attacks are reduced by the use of a large Security Parameter Index (SPI) and Sequence Number fields to partly validate segments before CPU cycles are invested validated the Integrity Check Value (ICV). In TCP-AO, the socket pair performs most of the function of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay attacks, isn't needed due to TCP's Sequence Number, which is used to reorder received segments (provided the sequence number doesn't wrap around, which is why TCP-AO adds the SNE in Section 6.2). TCP already protects itself from replays of authentic segment data as well as authentic explicit TCP control (e.g., SYN, FIN, ACK bits) but even authentic replays could affect TCP congestion control [Sa99]. TCP-AO does not protect TCP congestion control from this last form of attack due to the cumbersome nature of layering a windowed security sequence number within TCP in addition to TCP's own sequence number; when such protection is desired, users are encouraged to apply IPsec instead.
セキュリティアルゴリズムの使用は、CPUサービス拒否（DOS）攻撃の機会を提示することができます。ここでは、攻撃者が攻撃を受けている誤ったランダムセグメントを送信し、攻撃を受けているレシーバーが拒否するための実質的なCPUの努力を費やします。IPSECでは、CPUサイクルが投資される前にセグメントを部分的に検証するために、大規模なセキュリティパラメーターインデックス（SPI）とシーケンス番号フィールドを使用することにより、このような攻撃は、整合性チェック値（ICV）を検証する前にセグメントを部分的に検証することで削減されます。TCP-AOでは、ソケットペアはIPSECのSPIのほとんどの関数を実行し、再生攻撃を避けるために使用されるIPSECのシーケンス番号は、受信セグメントを再注文するために使用されるTCPのシーケンス番号のために必要ではありません（シーケンス番号を条件にしてください包み回さないため、TCP-AOがセクション6.2でSNEを追加します。TCPは、本物のセグメントデータと本物の明示的なTCPコントロール（Syn、Fin、ACKビットなど）のリプレイからすでに保護していますが、本物のリプレイでさえTCPの混雑制御に影響を与える可能性があります[SA99]。TCP-AOは、TCP独自のシーケンス番号に加えて、TCP内でウィンドウセキュリティシーケンス番号を階層化するという面倒な性質のために、この最後の形式の攻撃からTCPの混雑制御を保護しません。そのような保護が必要な場合、ユーザーは代わりにIPSECを適用することをお勧めします。
Further, it is not useful to validate TCP's Sequence Number before performing a TCP-AO authentication calculation, because out-of-window segments can still cause valid TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is similarly not useful to add a separate Sequence Number field to TCP-AO, because doing so could cause a change in TCP's behavior even when segments are valid.
さらに、TCP-AO認証計算を実行する前にTCPのシーケンス番号を検証することは有用ではありません。これは、ウィンドウ外セグメントが有効なTCPプロトコルアクション（ACK再送信など）を引き起こす可能性があるためです[RFC793]。同様に、TCP-AOに個別のシーケンス番号フィールドを追加することは役に立たない。
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] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的承認オプション」、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403] Madson、C。およびR. Glenn、「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] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「TCPの選択的承認（SACK）オプションの拡張」、RFC 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] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム」、RFC 3517、2003年4月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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] Sangli、S.、Chen、E.、Fernando、R.、Scudder、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.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 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. Aggarwal、「MPLSによるBGPの優雅な再起動メカニズム」、RFC 4781、2007年1月。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926] Lebovitz、G。およびE. Rescorla、「TCP認証オプションの暗号化アルゴリズム（TCP-AO）」、RFC 5926、2010年6月。
[Ba10] Bashyam, M., Jethanandani, M., and A. Ramaiah "Clarification of sender behaviour in persist condition", Work in Progress, January 2010.
[Ba10] Bashyam、M.、Jethanandani、M.、およびA. Ramaiah「持続状態での送信者行動の明確化」、2010年1月の作業。
[Bo07] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. Wheeler, "Authentication for TCP-based Routing and Management Protocols", Work in Progress, February 2007.
[Bo07] Bonica、R.、Weis、B.、Viswanathan、S.、Lange、A。、およびO. Wheeler、「TCPベースのルーティングおよび管理プロトコルの認証」、2007年2月の進行中。
[Bo09] Borman, D., "TCP Options and MSS", Work in Progress, July 2009.
[BO09]ボーマン、D。、「TCPオプションとMSS」、2009年7月、進行中の作業。
[Ed07] Eddy, W., Ed., Bellovin, S., Touch, J., and R. Bonica, "Problem Statement and Requirements for a TCP Authentication Option", Work in Progress, July 2007.
[ED07] Eddy、W.、ed。、Ed。、Bellovin、S.、Touch、J。、およびR. Bonica、「TCP認証オプションの問題声明と要件」、2007年7月の作業。
[Go10] Gont, F., "ICMP Attacks against TCP", Work in Progress, March 2010.
[Go10] Gont、F。、「TCPに対するICMP攻撃」、2010年3月、進行中の作業。
[La10] Larsen, M. and F. Gont, "Transport Protocol Port Randomization Recommendations", Work in Progress, April 2010.
[LA10] Larsen、M。およびF. Gont、「輸送プロトコルポートランダム化の推奨事項」、2010年4月の作業。
[Le09] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Work in Progress, October 2009.
[LE09] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、2009年10月の作業。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948] Bellovin、S。、「シーケンス番号攻撃に対する防御」、RFC 1948、1996年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、M。、「TCP MD5署名オプションの主要な管理上の考慮事項」、RFC 3562、2003年7月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 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] Touch、J。、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communications Review, V29, N5, pp71-78, October 1999.
[SA99] Savage、S.、N。Cardwell、D。Wetherall、T。Anderson、「不正行為レシーバーによる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）」、Specification SDN.401、Revision 1.2、1988年7月12日。
[To07] Touch, J. and A. Mankin, "The TCP Simple Authentication Option", Work in Progress, July 2007.
[TO07] Touch、J。およびA. Mankin、「TCP Simple認証オプション」、2007年7月の作業進行中。
[To10] Touch, J., "A TCP Authentication Option NAT Extension", Work in Progress, January 2010.
[TO10] Touch、J。、「TCP認証オプションNAT拡張機能」、2010年1月の作業。
[Wa05] Wang, X., H. Yu, "How to break MD5 and other hash functions", Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.
[Wa05] Wang、X.、H。Yu、「MD5およびその他のハッシュ関数を壊す方法」、Proc。IACR EuroCrypt 2005、デンマーク、pp.19-35。
[We05] Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, "TCP Message Authentication Code Option", Work in Progress, December 2005.
[We05] Weis、B.、Appanna、C.、McGrew、D。、およびA. Ramaiah、「TCPメッセージ認証コードオプション」、2005年12月、進行中の作業。
This document evolved as the result of collaboration of the TCP Authentication Design team (tcp-auth-dt), whose members were (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus Westerlund. The text of this document is derived from a proposal by Joe Touch and Allison Mankin [To07] (originally from June 2006), which was both inspired by and intended as a counterproposal to the revisions to TCP MD5 suggested in a document by Ron Bonica, Brian Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] (originally from September 2005) and in a document by Brian Weis [We05].
このドキュメントは、メンバーが（アルファベット順）であったTCP認証デザインチーム（TCP-Auth-DT）のコラボレーションの結果として進化しました。アリソン・マンキン、サンディ・マーフィー、ジョー・タッチ、スリラム・ヴィスワナサン、ブライアン・ワイス、マグナス・ウェスターランド。このドキュメントのテキストは、ジョー・タッチとアリソン・マンキン[TO07]（2006年6月からは元々）の提案から派生しています。これらは、Ron Bonicaの文書で提案されたTCP MD5への改訂に触発され、意図されていました。Brian Weis、Sriran Viswanathan、Andrew Lange、およびOwen Wheeler [BO07]（元々2005年9月から）、およびBrian Weis [WE05]による文書で。
Russ Housley suggested L4/application layer management of the master key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the use of TCP's Initial Sequence Numbers (ISNs) in the traffic key computation and SNEs to avoid replay attacks, and Brian Weis extended the computation to incorporate the entire connection ID and provided the details of the traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and Brian Weis developed the master key coordination mechanism.
Russ Housleyは、マスターキータプルのL4/アプリケーションレイヤー管理を提案しました。Steve BellovinはKeyIDフィールドを動機付けました。Eric Rescorlaは、トラフィックキー計算とSNESでTCPの初期シーケンス番号（ISNS）を使用してリプレイ攻撃を避けることを提案し、Brian Weisは計算を拡張して接続ID全体を組み込み、トラフィックキー計算の詳細を提供しました。マーク・オールマン、ウェス・エディ、ラース・エガート、テッド・フェイバー、ラス・ハウリー、グレゴリー・レボビッツ、ティム・ポーク、エリック・レスコルラ、ジョー・タッチ、ブライアン・ワイスはマスターキー調整メカニズムを開発しました。
Alfred Hoenes, Charlie Kaufman, Adam Langley, and numerous other members of the TCPM WG also provided substantial feedback on this document.
Alfred Hoenes、Charlie Kaufman、Adam Langley、およびTCPM WGの他の多くのメンバーも、このドキュメントに関する実質的なフィードバックを提供しました。
This document was originally prepared using 2-Word-v2.0.template.dot.
このドキュメントは、もともと2ワード-V2.0.template.dotを使用して準備されていました。
Authors' Addresses
著者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676 Admiralty Way Marina Del Rey、CA 90292-6695 U.S.A.
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Allison Mankin Johns Hopkins Univ. Baltimore, MD U.S.A.
アリソン・マンキン・ジョンズ・ホプキンス大学メリーランド州ボルチモアU.S.A.
Phone: 1 301 728 7199
EMail: mankin@psg.com
URL: http://www.psg.com/~mankin/
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 U.S.A.
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon、VA 20171 U.S.A.
EMail: rbonica@juniper.net