[要約] RFC 7974は、ホスト識別のための実験的なTCPオプションに関するものであり、ホストの識別と認証を改善することを目的としています。
Independent Submission B. Williams
Request for Comments: 7974 Akamai, Inc.
Category: Informational M. Boucadair
ISSN: 2070-1721 Orange
D. Wing
October 2016
An Experimental TCP Option for Host Identification
ホスト識別のための実験的なTCPオプション
Abstract
概要
Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed. This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.
最近のRFCは、アドレス/プレフィックス共有デバイスやアプリケーション層プロキシなどのIPアドレス共有システムでのホスト識別に関する問題について議論しています。共有アドレス展開でホスト識別子を明らかにするための潜在的なソリューションについても説明しました。このメモは、TCPオプションを使用してホスト識別子を送信する、今日のインターネットでの運用でのそのようなソリューションの設計、展開、およびプライバシーの考慮事項について説明します。
Independent Submissions Editor Note
Independent Submissions Editor Note
This Informational document specifies an experimental TCP HOST_ID option that is already fairly widely deployed. It discusses that option's privacy considerations in considerable detail and highlights the care providers need to exercise in any actual deployment. The Independent Submissions Editor has chosen to publish this document in the Independent Stream so that potential deployers and implementors can understand all its details, so as to produce implementations that will interwork properly with other (existing) deployments.
この情報ドキュメントは、すでにかなり広く展開されている実験的なTCP HOST_IDオプションを指定しています。オプションのプライバシーに関する考慮事項についてかなり詳細に説明し、実際の展開でケアプロバイダーが行使する必要があることを強調します。 Independent Submissions Editorは、潜在的なデプロイヤとインプリメンタが詳細をすべて理解できるように、このドキュメントをIndependent Streamで公開することを選択しました。これにより、他の（既存の）デプロイメントと適切に相互作用する実装を作成できます。
IESG Note
IESG Note
This proposal was previously proposed for adoption by the TCPM working group and rejected as being an undesirable technical design for both transport and privacy reasons. This document specifies a new TCP option that uses the shared experimental options format. The use of experimental TCP options is specified in [RFC6994] for TCP options "that are not yet eligible for assigned codepoints". As this proposal has been rejected by the IETF community, it is not eligible for the registration of a TCP option codepoint. It should be further noted that for experimental TCP options, it "is only appropriate to use these values in explicitly-configured experiments; they MUST NOT be shipped as defaults in implementations" [RFC4727]. The IESG also carried out a review as described in [RFC5742] and concluded that this proposal violates IETF principles expressed in [RFC7258] about pervasive monitoring as an attack and should therefore not be published without IETF review and IESG approval. (The process described in [RFC5742] nonetheless allows the Independent Submissions Editor to publish, as has been chosen in this case.) Deployments of this proprietary TCP option may be widely viewed as undermining privacy and are likely to encounter issues with reliability of transport.
この提案は、以前はTCPMワーキンググループによる採用が提案されており、トランスポートとプライバシーの両方の理由から望ましくない技術設計であるとして拒否されました。このドキュメントでは、共有実験オプション形式を使用する新しいTCPオプションを指定します。実験的なTCPオプションの使用は、[RFC6994]で、「割り当てられたコードポイントにまだ適格でない」TCPオプションについて指定されています。この提案はIETFコミュニティによって拒否されているため、TCPオプションコードポイントの登録には適していません。さらに、実験的なTCPオプションの場合、「明示的に構成された実験でこれらの値を使用することのみが適切です。これらは実装のデフォルトとして出荷してはなりません」[RFC4727]。 IESGは、[RFC5742]で説明されているレビューも実施し、この提案は[RFC7258]で表明されているIETFの原則に違反しており、攻撃としての広汎な監視について違反しているため、IETFレビューとIESGの承認なしに公開するべきではありません。 （[RFC5742]で説明されているプロセスでは、この場合も選択されているように、独立した送信エディターが公開できます。）この独自のTCPオプションの展開は、プライバシーを損なうと広く見なされ、トランスポートの信頼性に関する問題が発生する可能性があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション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/rfc7974.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7974で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Important Use Cases ........................................4
1.2. Document Goals .............................................6
2. Terminology .....................................................6
3. Option Format ...................................................7
4. Option Use ......................................................7
4.1. Option Values ..............................................7
4.2. Sending Host Requirements ..................................9
4.2.1. Alternative SYN Cookie Support ......................9
4.2.2. Persistent TCP Connections ..........................9
4.2.3. Packet Fragmentation ...............................10
4.3. Multiple In-Path HOST_ID Senders ..........................10
5. Option Interpretation ..........................................11
6. Interaction with Other TCP Options .............................12
6.1. Multipath TCP (MPTCP) .....................................12
6.2. Authentication Option (TCP-AO) ............................12
6.3. TCP Fast Open (TFO) .......................................13
7. Security Considerations ........................................13
8. Privacy Considerations .........................................14
9. Pervasive Monitoring (PM) Considerations .......................15
10. IANA Considerations ...........................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Acknowledgements ..................................................20
Authors' Addresses ................................................20
A broad range of issues associated with address sharing have been documented in [RFC6269] and [RFC7620]. In addition, [RFC6967] provides an analysis of various solutions to the problem of revealing the sending host's identifier (HOST_ID) information to the receiver, indicating that a solution using a TCP [RFC793] option for this purpose is among the possible approaches that could be applied with limited performance impact and a high success ratio. The purpose of this memo is to describe a TCP HOST_ID option that is currently deployed on the public Internet using the TCP experimental option codepoint, including discussion of related design, deployment, and privacy considerations.
アドレス共有に関連する広範囲の問題が[RFC6269]と[RFC7620]に文書化されています。さらに、[RFC6967]は、送信ホストの識別子（HOST_ID）情報をレシーバーに明らかにする問題に対するさまざまなソリューションの分析を提供します。これは、この目的のためにTCP [RFC793]オプションを使用するソリューションが可能なアプローチの1つであることを示します限られたパフォーマンスへの影響と高い成功率で適用されます。このメモの目的は、TCP実験オプションコードポイントを使用して、現在パブリックインターネットに展開されているTCP HOST_IDオプションを説明することです。これには、関連する設計、展開、およびプライバシーの考慮事項の説明が含まれます。
Multiple documents have defined TCP options for the purpose of host identification: [REVEAL], [HOSTID], and [OVERLAYPATH]. Specification of multiple option formats to serve the purpose of host identification increases the burden for potential implementers and presents interoperability challenges as well, so the authors of those documents have worked together to define a common TCP option that supersedes the formats from those three documents. This memo describes a version of that common TCP option format that is currently in use on the public Internet.
複数のドキュメントで、ホストの識別を目的としたTCPオプションが定義されています：[REVEAL]、[HOSTID]、および[OVERLAYPATH]。ホスト識別の目的に役立つ複数のオプション形式を指定すると、潜在的な実装者の負担が増大し、相互運用性の課題も生じるため、これらのドキュメントの作成者は共同で、これら3つのドキュメントの形式に取って代わる共通のTCPオプションを定義しました。このメモは、一般のインターネットで現在使用されている一般的なTCPオプション形式のバージョンについて説明しています。
The option defined in this memo uses the TCP experimental option codepoint sharing mechanism defined in [RFC6994]. One of the earlier specifications, [OVERLAYPATH], is associated with unauthorized use of a TCP option kind number, and moving to the TCP experimental option codepoint has allowed the authors of that document to correct their error.
このメモで定義されたオプションは、[RFC6994]で定義されたTCP実験的オプションコードポイント共有メカニズムを使用します。以前の仕様の1つである[OVERLAYPATH]は、TCPオプションの種類番号の不正使用に関連付けられており、TCP試験運用オプションコードポイントに移行することで、そのドキュメントの作成者はエラーを修正できました。
The authors' implementations have primarily focused on the following address-sharing use cases in which currently deployed systems insert the HOST_ID option:
著者の実装は、主に、現在デプロイされているシステムがHOST_IDオプションを挿入する次のアドレス共有の使用例に焦点を当てています。
Carrier-Grade NAT (CGN): As defined in [RFC6888], [RFC6333], and other sources, a CGN allows multiple hosts connected to the public Internet to share a single Internet routable IPv4 address. One important characteristic of the CGN use case is that it modifies IP packets in-path, but does not serve as the endpoint for the associated TCP connections.
キャリアグレードNAT（CGN）：[RFC6888]、[RFC6333]、およびその他のソースで定義されているように、CGNを使用すると、パブリックインターネットに接続された複数のホストが1つのインターネットルーティング可能なIPv4アドレスを共有できます。 CGNの使用例の1つの重要な特性は、パス内のIPパケットを変更しますが、関連するTCP接続のエンドポイントとして機能しないことです。
Application Proxy: As defined in [RFC1919], an application proxy splits a TCP connection into two segments, serving as an endpoint for each of the connections and relaying data flows between the connections.
アプリケーションプロキシ：[RFC1919]で定義されているように、アプリケーションプロキシはTCP接続を2つのセグメントに分割し、各接続のエンドポイントとして機能し、接続間のデータフローを中継します。
Overlay Network: An overlay network is an Internet-based system providing security, optimization, or other services for data flows that transit the system. A network-layer overlay will sometimes act much like a CGN, in that packets transit the system with NAT being applied at the edge of the overlay. A transport-layer or application-layer overlay [RFC3135] will typically act much like an application proxy, in that the TCP connection will be segmented with the overlay network serving as an endpoint for each of the TCP connections.
オーバーレイネットワーク：オーバーレイネットワークは、システムを通過するデータフローにセキュリティ、最適化、またはその他のサービスを提供するインターネットベースのシステムです。ネットワーク層オーバーレイは、CGNのように機能することがあります。その場合、パケットはオーバーレイのエッジでNATが適用されてシステムを通過します。トランスポート層またはアプリケーション層のオーバーレイ[RFC3135]は、通常、TCP接続が各TCP接続のエンドポイントとして機能するオーバーレイネットワークでセグメント化されるという点で、アプリケーションプロキシのように機能します。
In this set of sender use cases, the TCP option is applied to an individual TCP packet either at the connection endpoint (e.g., an application proxy or a transport-layer overlay network) or at an address-sharing middlebox (e.g., a CGN or a network-layer overlay network). See Section 4 for additional details about the types of devices that add the option to a TCP packet, as well as existing limitations on use of the option when it is inserted by an address-sharing middlebox, including issues related to packet fragmentation.
この一連の送信側の使用例では、TCPオプションは、接続エンドポイント（たとえば、アプリケーションプロキシまたはトランスポート層オーバーレイネットワーク）またはアドレス共有ミドルボックス（たとえば、CGNまたはネットワーク層オーバーレイネットワーク）。 TCPパケットにオプションを追加するデバイスのタイプの詳細、およびパケット共有に関連する問題を含む、アドレス共有ミドルボックスによってオプションが挿入されるときのオプションの使用に関する既存の制限については、セクション4を参照してください。
The existing receiver use cases considered by this memo include the following:
このメモで検討されている既存のレシーバーの使用例には、次のものがあります。
o Differentiating between attack and non-attack traffic when the source of the attack is sharing an address with non-attack traffic.
o 攻撃の送信元が非攻撃トラフィックとアドレスを共有している場合の攻撃トラフィックと非攻撃トラフィックの区別。
o Application of per-subscriber policies for resource utilization, etc., when multiple subscribers are sharing a common address.
o 複数のサブスクライバーが共通のアドレスを共有している場合の、リソース使用率などのサブスクライバーごとのポリシーの適用。
o Improving server-side load-balancing decisions by allowing the load for multiple clients behind a shared address to be assigned to different servers, even when session affinity is required at the application layer.
o アプリケーション層でセッションアフィニティが必要な場合でも、共有アドレスの背後にある複数のクライアントの負荷を異なるサーバーに割り当てることができるようにすることで、サーバー側の負荷分散の決定を改善します。
In all of the above cases, differentiation between address-sharing clients is performed by a network function that does not process the application-layer protocol (e.g., HTTP) or the security protocol (e.g., TLS), because the action needs to be performed prior to decryption or parsing the application layer. Due to this, a solution implemented within the application layer or security protocol was considered unable to fully meet the receiver-side requirements. At the same time, as noted in [RFC6967], use of an IP option for this purpose has a low success rate. For these reasons, using a TCP option to deliver the host identifier was deemed by the authors to be an effective way to satisfy these specific use cases. See Section 5 for details about receiver-side interpretation of the option.
上記のすべてのケースで、アクションを実行する必要があるため、アドレス共有クライアント間の区別は、アプリケーション層プロトコル（HTTPなど）またはセキュリティプロトコル（TLSなど）を処理しないネットワーク機能によって実行されます。アプリケーション層を復号化または解析する前。このため、アプリケーション層またはセキュリティプロトコル内に実装されたソリューションは、レシーバー側の要件を完全に満たすことができないと見なされていました。同時に、[RFC6967]に記載されているように、この目的でIPオプションを使用すると成功率が低くなります。これらの理由により、TCPオプションを使用してホスト識別子を配信することは、これらの特定の使用例を満たすための効果的な方法であると著者は考えました。オプションの受信側の解釈の詳細については、セクション5を参照してください。
Publication of this memo is intended to serve multiple purposes.
このメモの発行は、複数の目的を果たすことを目的としています。
First and foremost, this document intends to inform readers about a mechanism that is in broad use on the public Internet. The authors are each affiliated with companies that have implemented, tested, and/or deployed systems that use the HOST_ID option on the public Internet. Other systems might encounter packets that contain this TCP option, and this document is intended to help others understand the nature of the TCP option when it is encountered so they can make informed decisions about how to handle it.
何よりもまず、このドキュメントは、パブリックインターネットで広く使用されているメカニズムについて読者に情報を提供することを目的としています。著者はそれぞれ、公衆インターネット上でHOST_IDオプションを使用するシステムを実装、テスト、または配備した企業と提携しています。他のシステムでは、このTCPオプションを含むパケットが発生する可能性があります。このドキュメントは、TCPオプションが検出されたときに、そのオプションの性質を理解して、処理方法について十分な情報を得られるようにすることを目的としています。
The testing effort documented in [HOSTID] indicated that a TCP option could be used for host identification purposes without significant disruption of TCP connectivity to legacy servers and networks that do not support the option. It also showed how mechanisms available in existing TCP implementations could make use of such a TCP option for diagnostics and/or packet filtering. The authors' use of the TCP option on the public Internet has confirmed that it can be used effectively for our use cases, but it has also uncovered some interoperability issues associated with the option's use on the public Internet, especially regarding interactions with other TCP options that support new transport capability being specified within the IETF. Section 6 discusses those interactions and limitations and explains how our systems handle associated issues.
[HOSTID]に記載されているテストの取り組みにより、TCPオプションは、ホスト識別の目的で、オプションをサポートしないレガシーサーバーおよびネットワークへのTCP接続を大幅に中断することなく使用できることが示されました。また、既存のTCP実装で利用可能なメカニズムが、そのようなTCPオプションを診断やパケットフィルタリングに利用する方法も示しました。著者によるパブリックインターネットでのTCPオプションの使用は、それが私たちのユースケースで効果的に使用できることを確認しましたが、パブリックインターネットでのオプションの使用に関連するいくつかの相互運用性の問題、特に他のTCPオプションとの相互作用についても発見しましたIETF内で指定されている新しいトランスポート機能をサポートします。セクション6では、これらの相互作用と制限について説明し、システムが関連する問題をどのように処理するかについて説明します。
Discussions within the IETF have raised privacy concerns about the option's use, especially in regard to pervasive monitoring risks. Existing uses of the option limit the nature of the HOST_ID values that are used and the systems that insert them in order to mitigate pervasive monitoring risks. Sections 8 and 9 discuss the authors' assessments of the privacy and monitoring impact of this TCP option in its current uses and suggest behavior for some external systems when the option is encountered. Continued discussion following publication of this memo is expected to allow further refinement of requirements related to the values used to populate the option and how those values can be interpreted by the receiver. There is a trade-off between providing the expected functionality to the receiver and protecting the privacy of the sender, and continued assessment will be necessary in order to find the right balance.
IETF内での議論により、特に広範囲にわたる監視リスクに関して、オプションの使用に関するプライバシーの懸念が生じています。このオプションの既存の使用は、広範囲にわたる監視リスクを軽減するために、使用されるHOST_ID値とそれらを挿入するシステムの性質を制限します。セクション8と9は、現在の使用におけるこのTCPオプションのプライバシーと監視の影響に関する著者の評価について説明し、オプションが検出されたときの一部の外部システムの動作を提案します。このメモの公開後の継続的な議論により、オプションの設定に使用される値に関連する要件と、それらの値がレシーバーによってどのように解釈されるかに関する要件をさらに改善できることが期待されます。期待される機能を受信者に提供することと送信者のプライバシーを保護することの間にはトレードオフがあり、適切なバランスを見つけるためには継続的な評価が必要になります。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
When used for host identification, the TCP experimental option uses the experiment identification mechanism described in [RFC6994] and has the following format and content.
ホストの識別に使用される場合、TCP実験オプションは[RFC6994]で説明されている実験識別メカニズムを使用し、次の形式と内容を持ちます。
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| HOST_ID ...
+--------+---
Kind: The option kind value is 253.
種類：オプションの種類の値は253です。
Length: The length of the option is variable, based on the required size of the host identifier (e.g., a 2-octet HOST_ID will require a length of 6, while a 4-octet HOST_ID will require a length of 8).
長さ：オプションの長さは、ホスト識別子の必要なサイズに基づいて可変です（たとえば、2オクテットのHOST_IDには長さ6、4オクテットのHOST_IDには長さ8が必要です）。
ExID: The experiment ID value is 0x0348 (840).
ExID：実験IDの値は0x0348（840）です。
HOST_ID: The host identifier is a value that can be used to differentiate among the various hosts sharing a common public IP address. See below for further discussion of this value.
HOST_ID：ホスト識別子は、共通のパブリックIPアドレスを共有するさまざまなホストを区別するために使用できる値です。この値の詳細については、以下を参照してください。
This section describes requirements associated with the use of the option, including expected option values, which hosts are allowed to include the option, and segments that include the option.
このセクションでは、予想されるオプション値、オプションを含めることができるホスト、オプションを含むセグメントなど、オプションの使用に関連する要件について説明します。
The information conveyed in the HOST_ID option is intended to uniquely identify the sending host to the best capability of the machine that adds the option to the segment, while at the same time avoiding inclusion of information that does not assist this purpose. In addition, the option is not intended to be used to expose information about the sending host that could not be discovered by observing segments in transit on some portion of the Internet path between the sender and the receiver. Existing use cases have different requirements for receiver-side functionality, so this document attempts to provide a high degree of flexibility for the machine that adds the option to TCP segments.
HOST_IDオプションで伝達される情報は、セグメントにオプションを追加するマシンの最高の能力で送信側ホストを一意に識別すると同時に、この目的に役立たない情報が含まれないようにすることを目的としています。さらに、このオプションを使用して、送信側と受信側の間のインターネットパスの一部で転送中のセグメントを監視しても発見できなかった送信側ホストに関する情報を公開することは意図されていません。既存のユースケースでは、レシーバー側の機能に対する要件が異なるため、このドキュメントでは、TCPセグメントにオプションを追加するマシンに高度な柔軟性を提供することを試みています。
The HOST_ID option value MUST correlate to IP addresses and/or TCP port numbers that were changed by the inserting host/device (i.e., some of the IP address and/or port number bits are used to generate the HOST_ID). Example values that satisfy this requirement include the following:
HOST_IDオプションの値は、ホスト/デバイスの挿入によって変更されたIPアドレスやTCPポート番号と関連付ける必要があります（つまり、一部のIPアドレスやポート番号のビットがHOST_IDの生成に使用されます）。この要件を満たす値の例は次のとおりです。
Unique ID: An inserting host/device could maintain a pool of locally unique ID values that are dynamically mapped to the unique source IP address values in use behind the host/device as a result of address sharing. This ID value would be meaningful only within the context of a specific shared IP address due to the local uniqueness characteristic. Such an ID value could be smaller than an IP address (e.g., 16 bits) in order to conserve TCP option space. This option is preferred because it does not increase IP address visibility on the forward side of the address-sharing system, and it SHOULD be used in cases where receiver-side requirements can be met without direct inclusion of the original IP address (e.g., some load-balancing uses).
一意のID：挿入するホスト/デバイスは、アドレス共有の結果としてホスト/デバイスの背後で使用されている一意の送信元IPアドレス値に動的にマップされるローカルで一意のID値のプールを維持できます。このID値は、ローカルの一意性の特性により、特定の共有IPアドレスのコンテキスト内でのみ意味があります。このようなID値は、TCPオプションスペースを節約するために、IPアドレス（16ビットなど）よりも小さい場合があります。このオプションは、アドレス共有システムのフォワード側でIPアドレスの可視性を向上させないため、推奨されます。また、元のIPアドレスを直接含めることなくレシーバー側の要件を満たすことができる場合に使用する必要があります（たとえば、ロードバランシングの用途）。
IP Address/Subnet: An inserting host/device could simply populate the option value with the IP address value in use behind the host/ device. In the case of IPv6 addresses, it could be difficult to include the full address due to TCP option space constraints, so the value would likely need to provide only a portion of the address (e.g., the first 64 bits).
IPアドレス/サブネット：挿入するホスト/デバイスは、ホスト/デバイスの背後で使用されているIPアドレス値をオプションの値に設定するだけです。 IPv6アドレスの場合、TCPオプションのスペースの制約により、完全なアドレスを含めることが難しい場合があるため、値はアドレスの一部（たとえば、最初の64ビット）のみを提供する必要がある可能性があります。
IP Address and TCP Port: Some networks share public IP addresses among multiple subscribers with a portion of the TCP port number space being assigned to each subscriber [RFC6346]. When such a system is behind an address-sharing host/device, inclusion of both the IP address and the TCP port number will more uniquely identify the sending host than just the IP address on its own.
IPアドレスとTCPポート：一部のネットワークは、複数のサブスクライバー間でパブリックIPアドレスを共有し、TCPポート番号スペースの一部が各サブスクライバーに割り当てられています[RFC6346]。このようなシステムがアドレス共有ホスト/デバイスの背後にある場合、IPアドレスとTCPポート番号の両方を含めると、IPアドレスだけではなく、送信ホストを一意に識別できます。
When multiple host identifiers are necessary (e.g., an IP address and a port number), the HOST_ID option is included multiple times within the packet, once for each identifier. While this approach significantly increases option space utilization when multiple identifiers are included, cases where only a single identifier is included are expected to be more common; thus, it is beneficial to optimize for those cases. Note that some middleboxes might reorder TCP options, so this method could be problematic if such a middlebox is in-path between the address-sharing system and the receiver. This has not proven to be a problem for existing use cases.
複数のホスト識別子（IPアドレスとポート番号など）が必要な場合、HOST_IDオプションは、識別子ごとに1つずつ、パケット内に複数回含まれます。このアプローチでは、複数の識別子が含まれる場合にオプションスペースの使用率が大幅に増加しますが、単一の識別子のみが含まれる場合のほうが一般的であると予想されます。したがって、これらのケースに対して最適化することは有益です。一部のミドルボックスはTCPオプションを並べ替える場合があるため、このようなミドルボックスがアドレス共有システムとレシーバーの間のパスにある場合、この方法は問題になる可能性があることに注意してください。これは、既存のユースケースで問題になることは証明されていません。
See Section 8 for discussion of privacy considerations related to selection of HOST_ID values.
HOST_ID値の選択に関連するプライバシーの考慮事項については、セクション8を参照してください。
The HOST_ID option MUST only be added by the sending host or any device involved in the forwarding path that changes IP addresses and/ or TCP port numbers (e.g., NAT44 [RFC3022], L2-Aware NAT, DS-Lite Address Family Transition Router (AFTR) [RFC6333], IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296], NAT64 [RFC6146], Dual-Stack Extra Lite [RFC6619], TCP Proxy, etc.). The HOST_ID option MUST NOT be added or modified en route by any device that does not modify IP addresses and/or TCP port numbers.
HOST_IDオプションは、IPアドレスやTCPポート番号を変更する転送パスに関与する送信ホストまたはデバイス（たとえば、NAT44 [RFC3022]、L2-Aware NAT、DS-Liteアドレスファミリー遷移ルーター（ AFTR）[RFC6333]、IPv6-to-IPv6ネットワークプレフィックス変換（NPTv6）[RFC6296]、NAT64 [RFC6146]、Dual-Stack Extra Lite [RFC6619]、TCPプロキシなど）。 HOST_IDオプションは、IPアドレスやTCPポート番号を変更しないデバイスによって途中で追加または変更してはなりません（MUST NOT）。
The sending host or intermediary device cannot determine whether the option value is used in a stateful manner by the receiver, nor can it determine whether SYN cookies are in use by the receiver. For this reason, the option MUST be included in all segments, both SYN and non-SYN segments, until return segments from the receiver positively indicate that the TCP connection is fully established on the receiver (e.g., the return segment either includes or acknowledges data).
送信ホストまたは中間デバイスは、オプション値が受信者によってステートフルな方法で使用されているかどうかを判断できず、SYN Cookieが受信者によって使用されているかどうかも判断できません。このため、受信側からの戻りセグメントが受信側でTCP接続が完全に確立されていることを明確に示すまで（たとえば、戻りセグメントがデータを含むか、または確認応答するまで）、オプションはすべてのセグメント（SYNセグメントと非SYNセグメントの両方）に含める必要があります）。
The authors have also considered an alternative approach to SYN cookie support in which the receiving host (i.e., the host that accepts the TCP connection) echoes the option back to the sender in the SYN/ACK segment when a SYN cookie is being sent. This would allow the host sending HOST_ID to determine whether further inclusion of the option is necessary. This approach would have the benefit of not requiring inclusion of the option in non-SYN segments if SYN cookies had not been used. Unfortunately, this approach fails if the responding host itself does not support the option, since an intermediate node would have no way to determine that SYN cookies had been used.
著者はまた、SYN Cookieが送信されるときに、受信ホスト（つまり、TCP接続を受け入れるホスト）がSYN / ACKセグメントで送信者にオプションをエコーバックする、SYN Cookieサポートの代替アプローチを検討しました。これにより、HOST_IDを送信するホストは、オプションをさらに含める必要があるかどうかを判断できます。このアプローチには、SYN Cookieが使用されていない場合に非SYNセグメントにオプションを含める必要がないという利点があります。残念ながら、中間ノードにはSYN Cookieが使用されたことを確認する方法がないため、応答するホスト自体がオプションをサポートしていない場合、このアプローチは失敗します。
Some types of middleboxes (e.g., application proxy) open and maintain persistent TCP connections to regularly visited destinations in order to minimize the burden of connection establishment. Such middleboxes might use a single persistent TCP connection for multiple different client hosts over the life of the persistent connection.
一部のタイプのミドルボックス（アプリケーションプロキシなど）は、接続確立の負担を最小限に抑えるために、定期的に訪問する宛先への永続的なTCP接続を開いて維持します。このようなミドルボックスは、永続的な接続の存続期間中、複数の異なるクライアントホストに対して単一の永続的なTCP接続を使用する場合があります。
This specification does not attempt to support the use of persistent TCP connections for multiple client hosts due to the perceived complexity of providing such support. Instead, the HOST_ID option is only allowed to be used at connection initiation. An inserting host/ device that supports both the HOST_ID option and multi-client persistent TCP connections MUST NOT apply the HOST_ID option to TCP connections that could be used for multiple clients over the life of the connection. If the HOST_ID option was sent during connection initiation, the inserting host/device MUST NOT reuse the connection for data flows originating from a client that would require a different HOST_ID value.
この仕様は、複数のクライアントホストに対する永続的なTCP接続の使用をサポートしようとはしていません。これは、そのようなサポートを提供することの複雑さが認識されているためです。代わりに、HOST_IDオプションは、接続の開始時にのみ使用できます。 HOST_IDオプションとマルチクライアント永続的TCP接続の両方をサポートする挿入ホスト/デバイスは、接続の存続期間にわたって複数のクライアントに使用できるTCP接続にHOST_IDオプションを適用してはなりません（MUST NOT）。接続の開始時にHOST_IDオプションが送信された場合、挿入するホスト/デバイスは、別のHOST_ID値を必要とするクライアントから発信されたデータフローに対して接続を再利用してはなりません（MUST NOT）。
In order to avoid the overhead associated with in-path IP fragmentation, it is desirable for the inserting host/device to avoid including the HOST_ID option when IP fragmentation might be required. This is not a firm requirement though, because the HOST_ID option is only included in the first few packets of a TCP connection; thus, associated IP fragmentation will generally have minimal impact. The option SHOULD NOT be included in packets if the resulting packet would require local fragmentation.
パス内IPフラグメンテーションに関連するオーバーヘッドを回避するために、IPフラグメンテーションが必要になる可能性がある場合は、ホスト/デバイスの挿入でHOST_IDオプションが含まれないようにすることが望ましいです。ただし、HOST_IDオプションはTCP接続の最初の数パケットにのみ含まれるため、これは確実な要件ではありません。したがって、関連するIPフラグメンテーションの影響は通常最小限です。結果のパケットがローカルフラグメンテーションを必要とする場合、オプションにパケットを含めないでください。
It can be difficult to determine whether local fragmentation would be required. For example, in cases where multiple interfaces with different MTUs are in use, a local routing decision has to be made before the MTU can be determined, and in some systems, this decision could be made after TCP option handling is complete. Additionally, it could be true that inclusion of the option causes the packet to violate the path's MTU but the path's MTU has not been learned yet on the sending host/device.
ローカルフラグメンテーションが必要かどうかを判断するのは難しい場合があります。たとえば、MTUが異なる複数のインターフェイスが使用されている場合、MTUを決定する前にローカルルーティングを決定する必要があり、システムによっては、TCPオプションの処理が完了した後でこの決定を行うことができます。さらに、オプションを含めるとパケットがパスのMTUに違反するが、パスのMTUが送信側ホスト/デバイスでまだ学習されていないことは事実です。
In existing deployed systems, the impact of IP fragmentation that results from use of the option has been minimal.
既存の展開済みシステムでは、オプションの使用によるIPフラグメンテーションの影響は最小限に抑えられています。
The possibility exists that there could be multiple in-path hosts/ devices configured to insert the HOST_ID option. For example, the client's TCP packets might first traverse a CGN device on their way to the edge of a public Internet overlay network. In order for the HOST_ID value to most uniquely identify the sender, it needs to represent both the identity observed by the CGN device (the subscriber's internal IP address, e.g., Shared Address Space [RFC6598]) and the identity observed by the overlay network (the shared address of the CGN device). The mechanism for handling the received HOST_ID value could vary depending upon the nature of the new HOST_ID value to be inserted, as described below.
HOST_IDオプションを挿入するように設定された複数のパス内ホスト/デバイスが存在する可能性があります。たとえば、クライアントのTCPパケットは、まず公衆インターネットオーバーレイネットワークのエッジに向かう途中でCGNデバイスを通過する可能性があります。 HOST_ID値が送信者を最も一意に識別するには、CGNデバイスによって監視されるID（サブスクライバーの内部IPアドレス、たとえば共有アドレススペース[RFC6598]）とオーバーレイネットワークによって監視されるID（RFC6598）の両方を表す必要があります。 CGNデバイスの共有アドレス）。受信したHOST_ID値を処理するメカニズムは、以下で説明するように、挿入される新しいHOST_ID値の性質によって異なります。
The problem of multiple in-path HOST_ID senders has not been observed in existing deployed systems. For this reason, existing implementations do not consistently support this scenario. Some systems do not propagate forward the received HOST_ID option value in any way, while other systems follow the guidance described below.
パス内の複数のHOST_ID送信者の問題は、既存の展開済みシステムでは確認されていません。このため、既存の実装はこのシナリオを一貫してサポートしていません。一部のシステムは受信したHOST_IDオプション値を転送しませんが、他のシステムは以下に説明するガイダンスに従います。
An inserting host/device that uses the received packet's source IP address as the HOST_ID value (possibly along with the port) MUST propagate forward the HOST_ID value(s) from the received packet, since the source IP address and port only represent the previous in-path address-sharing device and do not represent the original sender. In the CGN-plus-overlay example, this means that the overlay will include both the CGN's HOST_ID value(s) and a HOST_ID with the source IP address received by the overlay.
受信したパケットの送信元IPアドレスをHOST_ID値として（場合によってはポートとともに）使用する挿入ホスト/デバイスは、受信したパケットからHOST_ID値を転送する必要があります。送信元IPアドレスとポートは、 -pathアドレス共有デバイスで、元の送信者を表すものではありません。 CGN-plus-overlayの例では、これは、オーバーレイがCGNのHOST_ID値と、オーバーレイによって受信されたソースIPアドレスを持つHOST_IDの両方を含むことを意味します。
An inserting host/device that sends a unique ID (as described in Section 4.1) has two options for how to handle the HOST_ID value(s) from the received packet:
一意のIDを送信する挿入ホスト/デバイス（セクション4.1で説明）には、受信パケットからのHOST_ID値を処理する方法に関する2つのオプションがあります。
1. A host/device that sends a unique ID MAY strip the received HOST_ID option and insert its own option, provided that it uses the received HOST_ID value as a differentiator for selecting the unique ID. What this means in the CGN-plus-overlay example above is that the overlay is allowed to drop the HOST_ID value inserted by the CGN provided that the HOST_ID value selected by the overlay represents both the CGN itself and the HOST_ID value inserted by the CGN.
1. 一意のIDを送信するホスト/デバイスは、一意のIDを選択するための差別化要因として受信したHOST_ID値を使用する場合、受信したHOST_IDオプションを取り除き、独自のオプションを挿入できます。上記のCGN-plus-overlayの例でこれが意味することは、オーバーレイによって選択されたHOST_ID値がCGN自体とCGNによって挿入されたHOST_ID値の両方を表す場合、CGNによって挿入されたHOST_ID値をオーバーレイがドロップできることです。
2. A host/device that sends a unique ID MAY instead select a unique ID that represents only the previous in-path address-sharing host/device and propagate forward the HOST_ID value inserted by the previous host/device. In the CGN-plus-overlay example, this means that the overlay would include both the CGN's HOST_ID value and a HOST_ID with a unique ID of its own that was selected to represent the CGN's shared address.
2. 一意のIDを送信するホスト/デバイスは、代わりに、以前のパス内アドレス共有ホスト/デバイスのみを表す一意のIDを選択し、以前のホスト/デバイスによって挿入されたHOST_ID値を転送する場合があります。 CGN-plus-overlayの例では、これは、オーバーレイにCGNのHOST_ID値と、CGNの共有アドレスを表すために選択された固有のIDを持つHOST_IDの両方が含まれることを意味します。
An inserting host/device that sends a unique ID MUST use one of the above two mechanisms.
一意のIDを送信する挿入ホスト/デバイスは、上記の2つのメカニズムのいずれかを使用する必要があります。
Due to the variable nature of the option value, it is not possible for the receiving machine to reliably determine the value type from the option itself. For this reason, a receiving host/device SHOULD interpret the option value as an opaque identifier.
オプション値の性質が可変であるため、受信側のマシンがオプション自体から値タイプを確実に決定することはできません。このため、受信ホスト/デバイスはオプション値を不透明な識別子として解釈する必要があります（SHOULD）。
This specification allows the inserting host/device to provide multiple HOST_ID options. The order of appearance of TCP options could be modified by some middleboxes, so receivers SHOULD NOT rely on option order to provide additional meaning to the individual options. Instead, when multiple HOST_ID options are present, their values SHOULD be concatenated together in the order in which they appear in the packet and treated as a single large identifier.
この指定により、挿入するホスト/デバイスが複数のHOST_IDオプションを提供できるようになります。 TCPオプションの出現順序は、一部のミドルボックスによって変更される可能性があるため、受信者は、個々のオプションに追加の意味を提供するためにオプションの順序に依存するべきではありません。代わりに、複数のHOST_IDオプションが存在する場合、それらの値は、パケットに出現する順序で連結され、単一の大きな識別子として扱われる必要があります（SHOULD）。
For both of the receiver requirements discussed above, this specification uses SHOULD rather than MUST because reliable interpretation and ordering of options could be possible if the inserting host and the interpreting host are under common administrative control and integrity-protect communication between the inserting host and the interpreting host. Mechanisms for signaling the value type(s) and integrity protection are not provided by this specification, and in their absence, the receiving host/ device MUST interpret the option value(s) as a single opaque identifier.
上記の両方のレシーバー要件について、この仕様では、MUSTではなくSHOULDを使用する必要があります。挿入ホストと解釈ホストが共通の管理制御下にあり、挿入ホストと整合性保護通信が行われている場合、オプションの信頼できる解釈と順序付けが可能になるためです。通訳ホスト。値のタイプと完全性保護を通知するメカニズムはこの仕様では提供されていません。それらがない場合、受信ホスト/デバイスはオプション値を単一の不透明な識別子として解釈する必要があります。
This section details how the HOST_ID option functions in conjunction with other TCP options.
このセクションでは、HOST_IDオプションが他のTCPオプションとともにどのように機能するかについて詳しく説明します。
TCP provides for a maximum of 40 octets for TCP options. As discussed in Appendix A of MPTCP [RFC6824], a typical SYN from modern, popular operating systems contains several TCP options (MSS (Maximum Segment Size), window scale, SACK (selective acknowledgment) permitted, and timestamp), which consume 19-24 octets depending on word alignment of the options. The initial SYN from a multipath TCP client would consume an additional 16 octets.
TCPは、TCPオプションに最大40オクテットを提供します。 MPTCP [RFC6824]の付録Aで説明されているように、最新の人気のあるオペレーティングシステムの典型的なSYNには、19-を消費するいくつかのTCPオプション（MSS（最大セグメントサイズ）、ウィンドウスケール、SACK（選択的確認応答）、およびタイムスタンプ）が含まれています。オプションの単語の配置に応じて24オクテット。マルチパスTCPクライアントからの最初のSYNは、追加の16オクテットを消費します。
HOST_ID needs at least 6 octets to be useful, so 9-21 octets are sufficient for many scenarios that benefit from HOST_ID. However, 4 octets are not enough space for the HOST_ID option. Thus, a TCP SYN containing all the typical TCP options (MSS, window scale, SACK permitted, and timestamp) and also containing multipath capable or multipath join as well as being word-aligned has insufficient space to accommodate HOST_ID. This means something has to give. The choices are either to avoid word alignment in that case (freeing 5 octets) or avoid adding the HOST_ID option. Each of these approaches is used in existing implementations and has been deemed acceptable for the associated use case.
HOST_IDを使用するには、少なくとも6オクテットが必要なので、HOST_IDを利用する多くのシナリオでは9〜21オクテットで十分です。ただし、4オクテットはHOST_IDオプションに十分なスペースではありません。したがって、すべての一般的なTCPオプション（MSS、ウィンドウスケール、許可されたSACK、タイムスタンプ）を含み、マルチパス対応またはマルチパス結合を含み、ワードアラインされているTCP SYNには、HOST_IDを収容するための十分なスペースがありません。これは、何かを与える必要があることを意味します。その場合は、ワードアラインメントを回避する（5オクテットを解放する）か、HOST_IDオプションを追加しないようにします。これらのアプローチのそれぞれは、既存の実装で使用されており、関連するユースケースでは許容できると見なされています。
The TCP Authentication Option (TCP-AO) [RFC5925] is incompatible with address sharing due to the fact that it provides integrity protection of the source IP address. For this reason, the only use cases where it makes sense to combine TCP-AO and HOST_ID are those where the TCP-AO-NAT extension [RFC6978] is in use. Injecting a HOST_ID TCP option does not interfere with the use of TCP-AO-NAT because the TCP options are not included in the Message Authentication Code (MAC) calculation.
TCP認証オプション（TCP-AO）[RFC5925]は、送信元IPアドレスの整合性保護を提供するため、アドレス共有と互換性がありません。このため、TCP-AOとHOST_IDを組み合わせることが意味があるのは、TCP-AO-NAT拡張[RFC6978]が使用されている場合のみです。 HOST_ID TCPオプションを挿入しても、TCPオプションはメッセージ認証コード（MAC）の計算に含まれないため、TCP-AO-NATの使用を妨げることはありません。
The TFO option [RFC7413] uses a zero-length cookie (total option length is 2 bytes) to request a TFO cookie for use on future connections. The server-generated TFO cookie is required to be at least 4 bytes long and allowed to be as long as 16 bytes (total option length is 6 to 18 bytes). The cookie request form of the option leaves enough room available in a SYN packet with the most commonly used options to accommodate the HOST_ID option, but a valid TFO cookie length longer than 13 bytes would prevent even the minimal 6-byte HOST_ID option from being included in the header.
TFOオプション[RFC7413]は、長さがゼロのCookie（オプションの長さの合計は2バイト）を使用して、将来の接続で使用するTFO Cookieを要求します。サーバーで生成されたTFO Cookieは、少なくとも4バイトの長さが必要で、16バイトの長さまで許可されています（オプションの合計長は6〜18バイトです）。オプションのcookieリクエストフォームは、SYNパケットで利用可能な十分なスペースを残し、HOST_IDオプションに対応するために最も一般的に使用されるオプションを備えていますが、13バイトを超える有効なTFO cookie長は、最小の6バイトのHOST_IDオプションも含まれないようにしますヘッダー内。
There are multiple possibilities for allowing TFO and HOST_ID to be supported for the same connection, including:
TFOとHOST_IDが同じ接続でサポートされるようにするには、次のような複数の方法があります。
o If the TFO implementation allows the cookie size to be configurable, the configured cookie size can be specifically selected to leave enough option space available in a typical TFO SYN packet to allow inclusion of the HOST_ID option.
o TFO実装でCookieサイズを構成できるようにする場合、構成されたCookieサイズを具体的に選択して、HOST_IDオプションを含めることができるように、通常のTFO SYNパケットで十分なオプションスペースを残すことができます。
o If the TFO implementation provides explicit support for the HOST_ID option, it can be designed to use a shorter cookie length when the HOST_ID option is present in the TFO cookie request SYN.
o TFO実装がHOST_IDオプションを明示的にサポートしている場合、TFO CookieリクエストSYNにHOST_IDオプションが存在する場合は、より短いCookie長を使用するように設計できます。
Reducing the TFO cookie size in order to include the HOST_ID option could have unacceptable security implications, so existing deployed systems that use the HOST_ID option consider TFO and HOST_ID to be mutually exclusive and do not support the use of both options on the same TCP connection.
HOST_IDオプションを含めるためにTFO Cookieのサイズを小さくすると、セキュリティに許容できない影響が生じる可能性があるため、HOST_IDオプションを使用する既存のデプロイ済みシステムは、TFOとHOST_IDを相互に排他的であると見なし、同じTCP接続で両方のオプションの使用をサポートしません。
It should also be noted that the presence of data in a TFO SYN increases the likelihood that there will be no space available in the SYN packet to support inclusion of the HOST_ID option without IP fragmentation, even if there is enough room in the TCP option space. This is an additional reason that the existing system considers TFO and HOST_ID to be mutually exclusive.
また、TFO SYNにデータが存在すると、TCPオプションスペースに十分なスペースがあっても、SYNパケットにIPフラグメンテーションなしでHOST_IDオプションを含めることができるスペースがない可能性が高まることにも注意してください。 。これは、既存のシステムがTFOとHOST_IDを相互に排他的であると見なすもう1つの理由です。
Security (including privacy) considerations common to all HOST_ID solutions are discussed in [RFC6967].
すべてのHOST_IDソリューションに共通するセキュリティ（プライバシーを含む）の考慮事項は、[RFC6967]で説明されています。
The content of the HOST_ID option SHOULD NOT be used for purposes that require a trust relationship between the sender and the receiver (e.g., billing and/or subscriber policy enforcement). This requirement uses SHOULD rather than MUST because reliable interpretation of options could be possible if the inserting host and the interpreting host are under common administrative control and integrity-protect communication between the inserting host and the interpreting host. Mechanisms for signaling the value type(s) and integrity protection are not provided by this specification, and in their absence, the receiving host/device MUST NOT use the HOST_ID value for purposes that require a trust relationship.
HOST_IDオプションの内容は、送信者と受信者の間の信頼関係を必要とする目的で使用してはなりません（SHOULD NOT）（たとえば、請求および/または加入者ポリシーの施行）。挿入ホストと解釈ホストが共通の管理制御下にあり、挿入ホストと解釈ホストの間の完全性保護通信である場合、オプションの信頼できる解釈が可能になるため、この要件は必須ではなくSHOULDを使用します。値のタイプと完全性保護を通知するメカニズムはこの仕様では提供されていません。そのため、受信側のホスト/デバイスは、信頼関係を必要とする目的でHOST_ID値を使用してはなりません。
Note that the above trust requirement applies equally to HOST_ID option values propagated forward from a previous in-path host as described in Section 4.3. In other words, if the trust mechanism does not apply to all option values in the packet, then none of the HOST_ID values can be considered trusted, and the receiving host/ device MUST NOT use any of the HOST_ID values for purposes that require a trust relationship. An inserting host/device that has such a trust relationship MUST NOT propagate forward an untrusted HOST_ID in such a way as to allow it to be considered trusted.
上記の信頼要件は、セクション4.3で説明されているように、以前のパス内ホストから前方に伝播されたHOST_IDオプション値にも同様に適用されます。言い換えると、信頼メカニズムがパケット内のすべてのオプション値に適用されない場合、HOST_ID値はどれも信頼できると見なすことができず、受信ホスト/デバイスは信頼を必要とする目的でHOST_ID値を使用してはなりません（MUST NOT）。関係。そのような信頼関係を持つ挿入ホスト/デバイスは、信頼されていると見なされるように、信頼されていないHOST_IDを転送してはなりません（MUST NOT）。
When the receiving network uses the values provided by the option in a way that does not require trust (e.g., maintaining session affinity in a load-balancing system), then use of a mechanism to enforce the trust relationship is OPTIONAL.
受信側ネットワークが、オプションを提供する値を信頼を必要としない方法で使用する場合（たとえば、負荷分散システムでセッションアフィニティを維持する場合）、信頼関係を強制するメカニズムの使用はオプションです。
Sending a TCP SYN across the public Internet necessarily discloses the public IP address of the sending host. When an intermediate address-sharing device is deployed on the public Internet, anonymity of the hosts using the device will be increased, with hosts represented by multiple source IP addresses on the ingress side of the device using a single source IP address on the egress side. The HOST_ID TCP option removes that increased anonymity, taking information that was already visible in TCP packets on the public Internet on the ingress side of the address-sharing device and making it available on the egress side of the device as well. In some cases, an explicit purpose of the address-sharing device is anonymity, in which case use of the HOST_ID TCP option would be incompatible with the purpose of the device.
パブリックインターネット経由でTCP SYNを送信すると、送信ホストのパブリックIPアドレスが明らかになります。中間アドレス共有デバイスがパブリックインターネットに展開されると、デバイスを使用するホストの匿名性が高まり、ホストは、出力側の単一のソースIPアドレスを使用するデバイスの入力側の複数のソースIPアドレスで表されます。 。 HOST_ID TCPオプションは匿名性を向上させ、アドレス共有デバイスの入力側のパブリックインターネット上のTCPパケットにすでに表示されていた情報を取得し、デバイスの出力側でも利用できるようにします。場合によっては、アドレス共有デバイスの明示的な目的は匿名性です。その場合、HOST_ID TCPオプションの使用はデバイスの目的と互換性がありません。
A NAT device used to provide interoperability between a local area network (LAN) using private [RFC1918] IP addresses and the public Internet is sometimes specifically intended to provide anonymity for the LAN clients as described in the above paragraph. For this reason, address-sharing devices at the border between a private LAN and the public Internet MUST NOT insert the HOST_ID option.
プライベート[RFC1918] IPアドレスを使用するローカルエリアネットワーク（LAN）とパブリックインターネット間の相互運用性を提供するために使用されるNATデバイスは、上記の段落で説明したように、LANクライアントに匿名性を提供することを特に意図している場合があります。このため、プライベートLANとパブリックインターネットの境界にあるアドレス共有デバイスは、HOST_IDオプションを挿入してはなりません（MUST NOT）。
The HOST_ID option MUST NOT be used to provide client geographic or network location information that was not publicly visible in IP packets for the TCP flows processed by the inserting host. For example, the client's IP address MAY be used as the HOST_ID option value, but any geographic or network location information derived from the client's IP address MUST NOT be used as the HOST_ID value.
HOST_IDオプションは、挿入するホストによって処理されるTCPフローのIPパケットで公開されていないクライアントの地理情報またはネットワークロケーション情報を提供するために使用してはなりません（MUST NOT）。たとえば、クライアントのIPアドレスはHOST_IDオプションの値として使用できますが、クライアントのIPアドレスから派生した地理情報やネットワークロケーション情報はHOST_IDの値として使用してはなりません（MUST NOT）。
The HOST_ID option MAY provide differentiating information that is locally unique such that individual TCP flows processed by the inserting host can be reliably identified. The HOST_ID option MUST NOT provide client identification information that was not publicly visible in IP packets for the TCP flows processed by the inserting host, such as subscriber information linked to the IP address.
HOST_IDオプションは、挿入するホストによって処理される個々のTCPフローを確実に識別できるように、ローカルで一意の識別情報を提供する場合があります。 HOST_IDオプションは、IPアドレスにリンクされたサブスクライバー情報など、挿入するホストによって処理されるTCPフローのIPパケットで公開されていないクライアント識別情報を提供してはなりません（MUST NOT）。
The HOST_ID value MUST be changed whenever the subscriber IP address changes. This requirement ensures that the HOST_ID option does not introduce a new globally unique identifier that persists across subscriber IP address changes.
HOST_ID値は、サブスクライバーIPアドレスが変更されるたびに変更する必要があります。この要件により、HOST_IDオプションが、サブスクライバーIPアドレスの変更全体にわたって持続する新しいグローバル一意識別子を導入しないことが保証されます。
The HOST_ID option MUST be stripped from IP packets traversing middleboxes that provide network-based anonymity services.
HOST_IDオプションは、ネットワークベースの匿名サービスを提供するミドルボックスを通過するIPパケットから削除する必要があります。
[RFC7258] provides the following guidance: "Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions." Legitimate concerns about host identification have been raised within the IETF. The authors of this memo have attempted to address those concerns by providing details about the nature of the HOST_ID values and the types of middleboxes that should and should not include the HOST_ID option in TCP headers, which describes limitations already imposed by existing deployed systems. This section is intended to highlight some particularly important aspects of this design and the related guidance/limitations that are relevant to the pervasive monitoring discussion.
[RFC7258]は次のガイダンスを提供します：「開発中のIETF仕様は、PMをどのように考慮したかを記述でき、攻撃が公開される作業に関連している場合、関連する設計決定を正当化できる必要があります。」ホストの識別に関する正当な懸念がIETF内で提起されました。このメモの作成者は、HOST_ID値の性質、およびTCPヘッダーにHOST_IDオプションを含める必要がある、または含めないミドルボックスのタイプに関する詳細を提供することにより、これらの懸念に対処しようとしました。このセクションは、この設計のいくつかの特に重要な側面と、広範にわたる監視の議論に関連する関連するガイダンス/制限を強調することを目的としています。
When a generated identifier is used, this document prohibits the address-sharing device from using globally unique or permanent identifiers. Only locally unique identifiers are allowed. As with persistent IP addresses, persistent HOST_ID values could facilitate user tracking and are therefore prohibited. The specific requirements for permissible HOST_ID values are discussed in Sections 8 and 4.1.
生成された識別子を使用する場合、このドキュメントでは、アドレス共有デバイスがグローバルに一意または永続的な識別子を使用することを禁止しています。ローカルで一意の識別子のみが許可されます。永続的なIPアドレスと同様に、永続的なHOST_ID値はユーザーの追跡を容易にするため、禁止されています。許容されるHOST_ID値の具体的な要件については、セクション8および4.1で説明します。
This specification does not target exposing a host beyond what the original packet, issued from that host, would have already exposed on the public Internet without introduction of the option. The option is intended only to carry forward information that was conveyed to the address-sharing device in the original packet, and HOST_ID option values that do not match this description are prohibited by requirements discussed in Section 8. This design does not allow the HOST_ID option to carry personally identifiable information, geographic location identifiers, or any other information that is not available in the wire format of the associated TCP/IP headers.
この仕様は、そのホストから発行された元のパケットが、オプションを導入せずにパブリックインターネットですでに公開されていたであろう範囲を超えてホストを公開することを対象としていません。このオプションは、元のパケットでアドレス共有デバイスに伝えられた情報を引き継ぐことのみを目的としており、この説明に一致しないHOST_IDオプション値は、セクション8で説明されている要件によって禁止されています。この設計では、HOST_IDオプションは許可されません個人を特定できる情報、地理的位置識別子、または関連するTCP / IPヘッダーのワイヤー形式では利用できないその他の情報を運ぶため。
This document's guidance on option values is followed in the existing deployed system. Thus, the volatility of the information conveyed in a HOST_ID option is similar to that of the public, subscriber IP address. A distinct HOST_ID is used by the address-sharing function when the host reboots or gets a new public IP address from the subscriber network.
オプション値に関するこのドキュメントのガイダンスは、既存の展開されたシステムに従っています。したがって、HOST_IDオプションで伝達される情報の変動性は、パブリックなサブスクライバーIPアドレスの変動性に似ています。ホストがリブートしたとき、またはサブスクライバーネットワークから新しいパブリックIPアドレスを取得したときに、アドレス共有機能によって別個のHOST_IDが使用されます。
The described TCP option allows network identification to a similar level as the first 64 bits of an IPv6 address. That is, the server can use the bits of the TCP option to help identify a host behind an address-sharing device, in much the same way the server would use the host's IPv6 network address if the client and server were using IPv6 end to end.
説明されているTCPオプションを使用すると、IPv6アドレスの最初の64ビットと同じレベルのネットワーク識別が可能になります。つまり、サーバーはTCPオプションのビットを使用して、アドレス共有デバイスの背後にあるホストを識別するのに役立ちます。クライアントとサーバーがIPv6エンドツーエンドを使用している場合にサーバーがホストのIPv6ネットワークアドレスを使用するのとほぼ同じ方法で。
Some address-sharing middleboxes on the public Internet have the express intention of providing originator anonymity. Publication of this document can help such middleboxes recognize the associated risk and take action to mitigate it (e.g., by stripping or modifying the option value).
パブリックインターネット上のいくつかのアドレス共有ミドルボックスは、発信者に匿名性を提供するという明確な意図があります。このドキュメントの公開は、そのようなミドルボックスが関連するリスクを認識し、それを軽減するためのアクションを実行するのに役立ちます（たとえば、オプション値を削除または変更することによって）。
This document specifies a new TCP option (HOST_ID) that uses the shared experimental options format [RFC6994], with ExID in network-standard byte order. IANA has registered HOST_ID (0x0348) in the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry.
このドキュメントでは、Excをネットワーク標準のバイトオーダーで使用して、共有実験オプション形式[RFC6994]を使用する新しいTCPオプション（HOST_ID）を指定します。 IANAは、「TCP実験オプション実験識別子（TCP ExID）」レジストリにHOST_ID（0x0348）を登録しました。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <http://www.rfc-editor.org/info/rfc4727>.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC 4727、DOI 10.17487 / RFC4727、2006年11月、<http://www.rfc-editor.org / info / rfc4727>。
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <http://www.rfc-editor.org/info/rfc5742>.
[RFC5742] Alvestrand、H。およびR. Housley、「独立およびIRTFストリーム送信を処理するためのIESG手順」、BCP 92、RFC 5742、DOI 10.17487 / RFC5742、2009年12月、<http：//www.rfc-editor。 org / info / rfc5742>。
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>.
[RFC6994] Touch、J。、「実験的TCPオプションの共有使用」、RFC 6994、DOI 10.17487 / RFC6994、2013年8月、<http://www.rfc-editor.org/info/rfc6994>。
[HOSTID] Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP Options: Implementation & Preliminary Test Results", Work in Progress, draft-abdo-hostid-tcpopt-implementation-03, July 2012.
[HOSTID] Abdo、E.、Boucadair、M.、J。Queiroz、「HOST_ID TCP Options：Implementation＆Preliminary Test Results」、Work in Progress、draft-abdo-hostid-tcpopt-implementation-03、2012年7月。
[OVERLAYPATH] Williams, B., "Overlay Path Option for IP and TCP", Work in Progress, draft-williams-overlaypath-ip-tcp-rfc-04, June 2013.
[OVERLAYPATH]ウィリアムズ、B。、「IPおよびTCPのオーバーレイパスオプション」、作業中、draft-williams-overlaypath-ip-tcp-rfc-04、2013年6月。
[REVEAL] Yourtchenko, A. and D. Wing, "Revealing hosts sharing an IP address using TCP option", Work in Progress, draft-wing-nat-reveal-option-03, December 2011.
[公開] Yourtchenko、A。およびD. Wing、「TCPオプションを使用してIPアドレスを共有するホストを公開する」、作業中、draft-wing-nat-reveal-option-03、2011年12月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, DOI 10.17487/RFC1919, March 1996, <http://www.rfc-editor.org/info/rfc1919>.
[RFC1919] Chatel、M。、「クラシックIPプロキシと透過IPプロキシ」、RFC 1919、DOI 10.17487 / RFC1919、1996年3月、<http://www.rfc-editor.org/info/rfc1919>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<http://www.rfc-editor.org/info/ rfc3022>。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/info/rfc3135>.
[RFC3135] Border、J.、Kojo、M.、Griner、J。、モンテネグロ、G。、およびZ. Shelby、「リンク関連の劣化を緩和するためのパフォーマンス強化プロキシ」、RFC 3135、DOI 10.17487 / RFC3135、6月2001、<http://www.rfc-editor.org/info/rfc3135>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<http://www.rfc-editor.org/info / rfc5925>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<http： //www.rfc-editor.org/info/rfc6146>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269]フォード、M。、エド、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、 <http://www.rfc-editor.org/info/rfc6269>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<http://www.rfc-editor.org/info/rfc6296 >。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<http：/ /www.rfc-editor.org/info/rfc6333>。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.
[RFC6346] Bush、R.、Ed。、「IPv4アドレス不足に対するアドレスとポート（A + P）のアプローチ」、RFC 6346、DOI 10.17487 / RFC6346、2011年8月、<http：//www.rfc-editor .org / info / rfc6346>。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <http://www.rfc-editor.org/info/rfc6598>.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、DOI 10.17487 / RFC6598 、2012年4月、<http://www.rfc-editor.org/info/rfc6598>。
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012, <http://www.rfc-editor.org/info/rfc6619>.
[RFC6619] Arkko、J.、Eggert、L。、およびM. Townsley、「インターフェイスごとのバインディングを使用したアドレストランスレータのスケーラブルな操作」、RFC 6619、DOI 10.17487 / RFC6619、2012年6月、<http：//www.rfc -editor.org/info/rfc6619>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<http：// www.rfc-editor.org/info/rfc6824>。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common Requirements for Carrier-Grade NATs（CGNs）"、BCP 127、RFC 6888、 DOI 10.17487 / RFC6888、2013年4月、<http://www.rfc-editor.org/info/rfc6888>。
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, DOI 10.17487/RFC6967, June 2013, <http://www.rfc-editor.org/info/rfc6967>.
[RFC6967] Boucadair、M.、Touch、J.、Levis、P。、およびR. Penno、「共有アドレス配置におけるホスト識別子（HOST_ID）を明らかにするための潜在的なソリューションの分析」、RFC 6967、DOI 10.17487 / RFC6967、 2013年6月、<http://www.rfc-editor.org/info/rfc6967>。
[RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013, <http://www.rfc-editor.org/info/rfc6978>.
[RFC6978] Touch、J。、「NAT TraversalのTCP認証オプション拡張」、RFC 6978、DOI 10.17487 / RFC6978、2013年7月、<http://www.rfc-editor.org/info/rfc6978>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<http：//www.rfc-editor .org / info / rfc7413>。
[RFC7620] Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B., and B. Sarikaya, "Scenarios with Host Identification Complications", RFC 7620, DOI 10.17487/RFC7620, August 2015, <http://www.rfc-editor.org/info/rfc7620>.
[RFC7620] Boucadair、M.、Ed。、Chatras、B.、Reddy、T.、Williams、B.、and B. Sarikaya、 "Scenarios with Host Identification Complications"、RFC 7620、DOI 10.17487 / RFC7620、August 2015、 <http://www.rfc-editor.org/info/rfc7620>。
Acknowledgements
謝辞
Many thanks to W. Eddy, Y. Nishida, T. Reddy, M. Scharf, J. Touch, A. Zimmermann, and A. Falk for their comments.
コメントを寄せてくれたW. Eddy、Y。Nishida、T。Reddy、M。Scharf、J。Touch、A。Zimmermann、A。Falkに感謝します。
Authors' Addresses
著者のアドレス
Brandon Williams Akamai, Inc. 8 Cambridge Center Cambridge, MA 02142 United States of America
Brandon Williams Akamai、Inc. 8 Cambridge Center Cambridge、MA 02142アメリカ合衆国
Email: brandon.williams@akamai.com
Mohamed Boucadair Orange
ムハンマドバスジルオレンジ
Email: mohamed.boucadair@orange.com
Dan Wing
ダンウイング|
Email: dwing-ietf@fuggles.com