RFC 6978 - A TCP Authentication Option Extension for NAT Traversal 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6978
タイトル : RFC 6978 - NATトラバーサル用のTCP認証オプション拡張
翻訳編集 : 自動生成

[要約] RFC 6978は、NATトラバーサルのためのTCP認証オプション拡張に関する規格です。その目的は、TCP接続のセキュリティを向上させ、NAT環境での通信の信頼性を確保することです。

Independent Submission                                          J. Touch
Request for Comments: 6978                                       USC/ISI
Category: Experimental                                         July 2013
ISSN: 2070-1721

A TCP Authentication Option Extension for NAT Traversal

NATトラバーサル用のTCP認証オプション拡張

Abstract

概要

This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.

このドキュメントでは、ネットワークアドレストランスレータやネットワークアドレスとポートトランスレータ（NAT / NAPT）を通過する接続での使用をサポートするためのTCP認証オプション（TCP-AO）の拡張について説明します。この拡張機能は、トラフィックキーの計算に使用されるデータを変更しますが、TCP-AOのパケット処理またはキー生成アルゴリズムを変更しません。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントでは、インターネットコミュニティの試験運用プロトコルを定義しています。これは、他のRFCストリームとは関係なく、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6978.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6978で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................2
   3. Background ......................................................3
   4. Extension to Allow NAT Traversal ................................3
   5. Intended Use ....................................................4
   6. Security Considerations .........................................5
   7. References ......................................................5
      7.1. Normative References .......................................5
      7.2. Informative References .....................................5
   8. Acknowledgments .................................................6

1. Introduction

1. はじめに

This document describes an extension to the TCP Authentication Option (TCP-AO) [RFC5925] called TCP-AO-NAT to support its use in the presence of Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs) [RFC2663]. These devices translate the source address and/or the source port number of a TCP connection. TCP-AO without TCP-AO-NAT extensions would be sensitive to these modifications and would discard authenticated segments.

このドキュメントでは、TCP-AO-NATと呼ばれるTCP認証オプション（TCP-AO）[RFC5925]の拡張機能について説明し、ネットワークアドレストランスレータやネットワークアドレスおよびポートトランスレータ（NAT / NAPT）が存在する場合の使用をサポートします[RFC2663 ]。これらのデバイスは、TCP接続の送信元アドレスまたは送信元ポート番号、あるいはその両方を変換します。 TCP-AO-NAT拡張のないTCP-AOはこれらの変更の影響を受けやすく、認証されたセグメントを破棄します。

At least one potential application of TCP-AO-NAT is to support the experimental multipath TCP protocol [RFC6824], which uses multiple IP addresses to support a single TCP transfer.

TCP-AO-NATの少なくとも1つの潜在的なアプリケーションは、複数のIPアドレスを使用して単一のTCP転送をサポートする実験的なマルチパスTCPプロトコル[RFC6824]をサポートすることです。

This document assumes detailed familiarity with TCP-AO [RFC5925]. As a preview, this document focuses on how TCP-AO generates traffic keys, and it does not otherwise alter the TCP-AO mechanism or that of its key generation [RFC5926].

このドキュメントは、TCP-AO [RFC5925]に精通していることを前提としています。プレビューとして、このドキュメントはTCP-AOがトラフィックキーを生成する方法に焦点を当てており、TCP-AOメカニズムまたはそのキー生成[RFC5926]のメカニズムは変更していません。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

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]. When used in lower case, these words have their conventional meaning and do not convey the interpretations in RFC 2119.

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。小文字で使用される場合、これらの単語は従来の意味を持ち、RFC 2119の解釈を伝えません。

3. Background

3. バックグラウンド

TCP-AO generates traffic keys that are specific to a socket pair [RFC5925]. The following information is used to create a connection's traffic keys. (Note that 'local' and 'remote' are interpreted as in TCP-AO [RFC5925].)

TCP-AOは、ソケットペア[RFC5925]に固有のトラフィックキーを生成します。次の情報は、接続のトラフィックキーを作成するために使用されます。（ 'local'と 'remote'はTCP-AO [RFC5925]のように解釈されることに注意してください。）

o IP local address

o IPローカルアドレス

o IP remote address

o IPリモートアドレス

o TCP local port

o TCPローカルポート

o TCP remote port

o TCPリモートポート

o TCP local Initial Sequence Number (ISN)

o TCPローカル初期シーケンス番号（ISN）

o TCP remote Initial Sequence Number (ISN)

o TCPリモート初期シーケンス番号（ISN）

Of these fields, the remote ISN is not known for SYN segments and is excluded from the traffic key used to authenticate them. Otherwise, all fields are used in the traffic keys of all other segments.

これらのフィールドのうち、リモートISNはSYNセグメントで認識されておらず、それらの認証に使用されるトラフィックキーから除外されています。それ以外の場合、他のすべてのセグメントのトラフィックキーですべてのフィールドが使用されます。

NATs and NAPTs (both referred to herein as "NATs", even if port translation is included) would interfere with these uses, because they alter the IP address and TCP port of the endpoint behind the NAT [RFC2663].

NATおよびNAPT（ポート変換が含まれている場合でも、ここでは「NAT」と呼ばれます）は、NAT [RFC2663]の背後にあるエンドポイントのIPアドレスとTCPポートを変更するため、これらの使用を妨害します。

4. Extension to Allow NAT Traversal

4. NATトラバーサルを許可する拡張

The premise of TCP-AO-NAT is that it might be useful to allow TCP-AO use in the presence of NATs, e.g., to protect client/server communication where clients are behind NATs.

TCP-AO-NATの前提は、NATの存在下でTCP-AOを使用できるようにすること（たとえば、クライアントがNATの背後にあるクライアント/サーバー通信を保護すること）が役立つ場合があることです。

This document describes TCP-AO-NAT, an extension to TCP-AO that enables its use in the presence of NATs. This extension requires no modification to the TCP-AO header or packet processing, and it requires no modification to the algorithms used to generate traffic keys [RFC5926]. The change is limited to the data used to generate traffic keys only.

このドキュメントでは、NATの存在下での使用を可能にするTCP-AOの拡張であるTCP-AO-NATについて説明します。この拡張機能は、TCP-AOヘッダーやパケット処理を変更する必要がなく、トラフィックキーの生成に使用されるアルゴリズムを変更する必要もありません[RFC5926]。変更は、トラフィックキーの生成に使用されるデータに限定されます。

In TCP-AO, "a Master Key Tuple (MKT) describes the TCP-AO properties to be associated with one or more connections" [RFC5925]. This includes the TCP connection identifier, the TCP option flag (indicating whether TCP options other than TCP-AO are included in the Message Authentication Code (MAC) calculation), keying information, and other parameters. TCP-AO-NAT augments the MKT with two additional flags:

TCP-AOでは、「マスターキータプル（MKT）は、1つ以上の接続に関連付けられるTCP-AOプロパティを記述します」[RFC5925]。これには、TCP接続識別子、TCPオプションフラグ（TCP-AO以外のTCPオプションがメッセージ認証コード（MAC）の計算に含まれるかどうかを示す）、キーイング情報、およびその他のパラメーターが含まれます。 TCP-AO-NATは、2つの追加フラグでMKTを拡張します。

o localNAT

o 地元

o remoteNAT

TCP-AO implementations supporting TCP-AO-NAT MUST support both localNAT and remoteNAT flags.

TCP-AO-NATをサポートするTCP-AO実装は、localNATフラグとremoteNATフラグの両方をサポートする必要があります。

These flags indicate whether a segment's local or remote (respectively) IP address and TCP port are zeroed before MAC calculation, either for creating the MAC to insert (for outgoing segments) or for calculating a MAC to validate against the value in the option. These flags modify TCP-AO processing rules as follows:

これらのフラグは、MACを作成して（送信セグメントの場合）、またはMACを計算してオプションの値に対して検証するために、MAC計算の前にセグメントのローカルまたはリモート（それぞれ）IPアドレスとTCPポートがゼロにされるかどうかを示します。これらのフラグは、TCP-AO処理ルールを次のように変更します。

o In TCP-AO-NAT, traffic keys are computed by zeroing the local/remote IP address and TCP port as indicated by the localNAT or remoteNAT flags.

o TCP-AO-NATでは、トラフィックキーは、localNATまたはremoteNATフラグで示されるように、ローカル/リモートIPアドレスとTCPポートをゼロにすることによって計算されます。

o In TCP-AO-NAT, MAC values are computed by zeroing the local/remote IP address and TCP port as indicated by the localNAT or remoteNAT flags.

o TCP-AO-NATでは、MAC値は、localNATまたはremoteNATフラグで示されるように、ローカル/リモートIPアドレスとTCPポートをゼロにすることによって計算されます。

The use of these flags needs to match on both ends of the connection, just as with all other MKT parameters.

これらのフラグの使用は、他のすべてのMKTパラメータと同様に、接続の両端で一致する必要があります。

5. Intended Use

5. 使用目的

A host MAY use TCP-AO-NAT when it is behind a NAT, as determined using NAT discovery techniques, or when TCP-AO protection is desired but conventional TCP-AO fails to establish connections.

ホストは、NAT検出技術を使用して決定されるように、NATの背後にある場合、またはTCP-AO保護が必要であるが従来のTCP-AOが接続の確立に失敗した場合に、TCP-AO-NATを使用できます。

A client behind a NAT MAY set localNAT=TRUE for MKTs supporting TCP-AO-NAT for outgoing connections. A server MAY set remoteNAT=TRUE for MKTs supporting TCP-AO-NAT for incoming connections. Peer-to-peer applications with dual NAT support, e.g., those traversing so-called 'symmetric NATs' [RFC5389], MAY set both localNAT=TRUE and remoteNAT=TRUE for MKTs supporting TCP-AO-NAT bidirectionally. Once these flags are set in an MKT, they affect all connections that match that MKT.

NATの背後にあるクライアントは、発信接続のTCP-AO-NATをサポートするMKTに対してlocalNAT = TRUEを設定する場合があります。サーバーは、着信接続のTCP-AO-NATをサポートするMKTにremoteNAT = TRUEを設定できます（MAY）。いわゆる「対称NAT」[RFC5389]を通過するデュアルNATサポートを備えたピアツーピアアプリケーションは、TCP-AO-NATを双方向でサポートするMKTに対してlocalNAT = TRUEとremoteNAT = TRUEの両方を設定できます。これらのフラグがMKTで設定されると、そのMKTに一致するすべての接続に影響します。

TCP-AO-NAT is intended for use only where coordinated between endpoints for connections that match the shared MKT parameters, as with all other MKT parameters.

TCP-AO-NATは、他のすべてのMKTパラメータと同様に、共有MKTパラメータと一致する接続のエンドポイント間で調整される場合にのみ使用することを目的としています。

Note that TCP-AO-NAT is not intended for use with services transiting Application Layer Gateways (ALGs), i.e., NATs that also translate in-band addresses, such as used in FTP or SIP. TCP-AO-NAT protects the contents of the TCP segments from modification and would (correctly) interpret such alterations as an attack on those contents.

TCP-AO-NATは、アプリケーションレイヤーゲートウェイ（ALG）を通過するサービス、つまり、FTPやSIPで使用されているような、帯域内アドレスも変換するNATでの使用を目的としていないことに注意してください。 TCP-AO-NATはTCPセグメントの内容を変更から保護し、そのような変更をそれらの内容への攻撃として（正しく）解釈します。

6. Security Considerations

6. セキュリティに関する考慮事項

TCP-AO-NAT does not affect the security of connections that do not set either the localNAT or remoteNAT flags. Such connections are not affected themselves and are not affected by segments in other connections that set those flags.

TCP-AO-NATは、localNATフラグまたはremoteNATフラグを設定しない接続のセキュリティには影響しません。そのような接続自体は影響を受けず、これらのフラグを設定する他の接続のセグメントの影響も受けません。

Setting either the localNAT or remoteNAT flags reduces the randomness of the input to the Key Derivation Function (KDF) used to generate the traffic keys. The largest impact occurs when using IPv4, which reduces the randomness from 2 IPv4 addresses, 2 ISNs, and both ports down to just the two ISNs when both flags are set. The amount of randomness in the IPv4 addresses and service port is likely to be small, and the randomness of the dynamic port is under debate and should not be considered substantial [RFC6056]. The KDF input randomness is thus expected to be dominated by that of the ISNs, so reducing it by either or both of the IPv4 addresses and ports is not expected to have a significant impact.

localNATフラグまたはremoteNATフラグのいずれかを設定すると、トラフィックキーの生成に使用されるキー導出関数（KDF）への入力のランダムさが低減されます。最大の影響は、IPv4を使用するときに発生します。これにより、2つのIPv4アドレス、2つのISN、および両方のポートから、両方のフラグが設定されている場合の2つのISNまでのランダム性が減少します。 IPv4アドレスとサービスポートのランダム性の量は少なくなる可能性が高く、動的ポートのランダム性については議論の余地があり、実質的なものと見なすべきではありません[RFC6056]。したがって、KDF入力ランダム性はISNのそれによって支配されると予想されるため、IPv4アドレスとポートのいずれかまたは両方によってそれを減らすことは大きな影響を与えるとは予想されません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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月。

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.

[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。

7.2. Informative References

7.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月。

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.

[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。

[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 Authentication Option（TCP-AO）の暗号化アルゴリズム」、RFC 5926、2010年6月。

[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.

[RFC6056] Larsen、M。、およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、2011年1月。

[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013.

[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、2013年1月。

8. Acknowledgments

8. 謝辞

This extension was inspired by discussions with Dan Wing.

この拡張機能はDan Wingとの議論に触発されました。

This document was initially prepared using 2-Word-v2.0.template.dot.

このドキュメントは、最初は2-Word-v2.0.template.dotを使用して作成されました。

Author's Address

著者のアドレス

Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292 USA

ジョータッチUSC / ISI 4676アドミラルティウェイマリナデルレイ、カリフォルニア州90292アメリカ

   Phone: +1 (310) 448-9151
   EMail: touch@isi.edu