RFC 8546 - The Wire Image of a Network Protocol 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8546
タイトル : RFC 8546 - ネットワークプロトコルのワイヤーイメージ
翻訳編集 : 自動生成

[要約] RFC 8546は、ネットワークプロトコルのワイヤイメージに関する情報を提供するものであり、その目的はネットワークプロトコルの実装とデバッグを支援することです。

Internet Architecture Board (IAB)                            B. Trammell
Request for Comments: 8546                                 M. Kuehlewind
Category: Informational                                       April 2019
ISSN: 2070-1721

The Wire Image of a Network Protocol

ネットワークプロトコルのワイヤーイメージ

Abstract

概要

This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.

このドキュメントでは、ネットワーク上のプロトコルの参加者以外の人が利用できる情報の抽象化であるワイヤーイメージを定義しています。この抽象化は、暗号化の強化がワイヤーイメージを使用するネットワーク機能に与える影響を明らかにすることを目的としています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8546.

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

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  The Extent of the Wire Image  . . . . . . . . . . . . . .   4
     3.2.  Obscuring Timing and Sizing Information . . . . . . . . .   5
     3.3.  Integrity Protection of the Wire Image  . . . . . . . . .   5
   4.  Engineering the Wire Image  . . . . . . . . . . . . . . . . .   6
     4.1.  Declaring Protocol Invariants . . . . . . . . . . . . . .   7
     4.2.  Trustworthiness of Engineered Signals . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   IAB Members at the Time of Approval . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

1. はじめに

A protocol specification defines a set of behaviors for each participant in the protocol: which lower-layer protocols are used for which services, how messages are formatted and protected, which participant sends which message when, how each participant should respond to each message, and so on.

プロトコル仕様は、プロトコルの各参加者の一連の動作を定義します。どのサービスにどの下位層プロトコルが使用されるか、メッセージのフォーマットと保護の方法、どの参加者がいつメッセージを送信するか、各参加者が各メッセージに応答する方法、およびなど。

Implicit in a protocol specification is the information the protocol radiates toward nonparticipant observers of the messages sent among participants, often including participants in lower-layer protocols. Any information that has a clear definition in the protocol's message format(s), or is implied by that definition, and is not cryptographically confidentiality protected can be unambiguously interpreted by those observers. This information comprises the protocol's wire image, which we define and discuss in this document.

プロトコル仕様で暗黙的に示されるのは、参加者間で送信されるメッセージの非参加者オブザーバーに向けてプロトコルが放射する情報であり、多くの場合、下位層プロトコルの参加者も含まれます。プロトコルのメッセージ形式で明確な定義を持っているか、その定義によって暗示されていて、暗号で機密性が保護されていない情報は、それらのオブザーバーによって明確に解釈される可能性があります。この情報は、このドキュメントで定義および説明するプロトコルのワイヤーイメージで構成されています。

The wire image, not the protocol's specification, determines how third parties on the network paths among protocol participants will interact with that protocol.

プロトコルの仕様ではなく、ワイヤーイメージによって、プロトコル参加者間のネットワークパス上のサードパーティがそのプロトコルと対話する方法が決まります。

The increasing deployment of transport-layer security [RFC8446] to protect application-layer headers and payload, as well as the definition and deployment of transport protocols with encrypted control information such as QUIC [QUIC], brings new relevance to the question of how third parties on the network paths will interact with a protocol. QUIC is, in effect, the first IETF-defined transport protocol to take care of the minimization of its own wire image to prevent ossification and improve end-to-end privacy by reducing information radiation.

アプリケーション層のヘッダーとペイロードを保護するトランスポート層セキュリティ[RFC8446]の導入の増加、およびQUIC [QUIC]などの暗号化された制御情報を使用したトランスポートプロトコルの定義と導入は、3番目の方法の問題に新しい関連性をもたらします。ネットワークパス上のパーティはプロトコルと対話します。 QUICは、事実上、自身のワイヤーイメージの最小化を処理して、骨化を防ぎ、情報放射を減らすことでエンドツーエンドのプライバシーを改善する最初のIETF定義のトランスポートプロトコルです。

The flip side of this trend is the impact of a less visible wire image on various functions driven by third-party observation of the wire image. In contrast to ongoing discussions about this tussle, this document treats the wire image as a pure abstraction, with the hope that it can shed some light on these discussions.

この傾向の反対側は、ワイヤ画像のサードパーティの観測によって駆動されるさまざまな機能に対する見えにくいワイヤ画像の影響です。この問題について進行中の議論とは対照的に、このドキュメントでは、ワイヤーイメージを純粋な抽象概念として扱い、これらの議論に光を当てることができると期待しています。

2. Definition

2. 定義

The wire image of the set of protocols in use for a given communication is the view of that set of protocols as observed by an entity not participating in the communication. It is the sequence of packets sent by each participant in the communication, including the content of those packets and metadata about the observation itself: the time at which each packet is observed and the vantage point of the observer.

特定の通信に使用されているプロトコルのセットのワイヤーイメージは、通信に参加していないエンティティによって観察されるプロトコルのセットのビューです。これは、通信の各参加者によって送信された一連のパケットであり、それらのパケットの内容と観測自体に関するメタデータ（各パケットが観測された時間と観測者の視点）を含みます。

3. Discussion

3. 討論

This definition illustrates some important properties of the wire image.

この定義は、ワイヤー画像のいくつかの重要な特性を示しています。

It is key that the wire image is not limited to merely "the unencrypted bits in the header". In particular, the metadata, such as sequences of interpacket timing and packet sizes, can be used to infer other parameters of the behavior of the protocols in use or to fingerprint protocols and/or specific implementations of those protocols; see Section 3.2.

ワイヤーイメージが単に「ヘッダー内の暗号化されていないビット」に限定されないことが重要です。特に、一連のパケット間タイミングやパケットサイズなどのメタデータを使用して、使用中のプロトコルの動作の他のパラメータを推測したり、プロトコルやそのプロトコルの特定の実装をフィンガープリントしたりできます。セクション3.2を参照してください。

An important implication of this property is that a protocol that uses confidentiality protection for the headers it needs to operate can be deliberately designed to have a specified wire image that is separate from that machinery; see Section 4. Note that this is a capability unique to encrypted protocols. Parts of a wire image may also be made visible to devices on path, but immutable through end-to-end integrity protection; see Section 3.3.

このプロパティの重要な意味は、操作に必要なヘッダーに機密保護を使用するプロトコルを、その機構とは別の指定されたワイヤーイメージを持つように意図的に設計できることです。セクション4を参照してください。これは暗号化プロトコルに固有の機能です。ワイヤーイメージの一部は、パス上のデバイスから見えるようにすることもできますが、エンドツーエンドの整合性保護により不変です。セクション3.3を参照してください。

Portions of the wire image of a protocol stack that are neither confidentiality protected nor integrity protected are writable by devices on the path(s) between the endpoints using the protocols. A protocol with a wire image that is largely writable operating over a path with devices that understand the semantics of the protocol's wire image can modify it in order to induce behaviors at the protocol's participants. TCP is one such protocol in the current Internet.

機密保護も完全性も保護されていないプロトコルスタックのワイヤーイメージの一部は、プロトコルを使用するエンドポイント間のパス上のデバイスによって書き込み可能です。プロトコルのワイヤイメージのセマンティクスを理解しているデバイスのあるパスを介して動作する、主に書き込み可能なワイヤイメージを持つプロトコルは、プロトコルの参加者に動作を誘発するためにそれを変更できます。 TCPは、現在のインターネットではそのようなプロトコルの1つです。

The term "wire image" can be applied in different scopes: the wire image of a single packet refers to the information derivable from observing that one packet in isolation, and the wire image of a single protocol refers to the information derivable from observing only the headers belonging to that protocol on a sequence of packets in isolation from other protocols in use for a communication. See Section 3.1 for more.

「ワイヤーイメージ」という用語は、さまざまな範囲で適用できます。単一パケットのワイヤーイメージは、1つのパケットを分離して観察することで得られる情報を指し、単一プロトコルのワイヤーイメージは、唯一のパケットを観察することで得られる情報を指します。通信に使用されている他のプロトコルから分離された一連のパケットのそのプロトコルに属するヘッダー。詳細については、セクション3.1を参照してください。

For a given packet observed at a given point in the network, the wire image contains information from the entire stack of protocols in use at that observation point. This implies that the wire image depends on the observer as well: each observer may see a slightly different image of the same communication.

ネットワークの特定のポイントで監視される特定のパケットの場合、ワイヤーイメージには、その監視ポイントで使用されているプロトコルのスタック全体からの情報が含まれます。これは、ワイヤー画像が観察者にも依存することを意味します。各観察者は同じコミュニケーションのわずかに異なる画像を見る可能性があります。

In this document, we assume that only information at the transport layer and above is delivered end-to-end, and we focus on the "Internet" wire image: that portion of the wire image at the network layer and above. While confidentiality and integrity protection may be added at multiple layers in the stack, protection below the network layer does not prevent modification either by the devices terminating those security associations or by devices on different segments of the path.

このドキュメントでは、トランスポート層以上の情報のみがエンドツーエンドで配信されると想定し、「インターネット」のワイヤー画像、つまりネットワーク層以上のワイヤー画像の部分に焦点を当てます。スタック内の複数の層に機密性と整合性の保護を追加できますが、ネットワーク層の下の保護は、これらのセキュリティアソシエーションを終了するデバイスまたはパスの異なるセグメント上のデバイスによる変更を妨げません。

3.1. The Extent of the Wire Image

3.1. ワイヤー画像の範囲

While we begin this definition as the properties of a sequence of packets in isolation, this is not how wire images are typically used by passive observers. A passive observer will generally consider the union of all the information in the wire image in all the packets generated by a given conversation.

この定義は、一連のパケットのプロパティとして分離して開始しますが、パッシブオブザーバーがワイヤイメージを通常使用する方法ではありません。パッシブオブザーバーは一般的に、特定の会話によって生成されたすべてのパケットのワイヤーイメージ内のすべての情報の結合を考慮します。

Similarly, the wire image of a single protocol is rarely seen in isolation. The dynamics of the application and network stacks on each endpoint use multiple protocols for any higher-level task. Most protocols involving user content, for example, are often seen on the wire together with DNS traffic; the information from the wire image from each protocol in use for a given communication can be correlated to infer information about the dynamics of the overlying application.

同様に、単一のプロトコルのワイヤーイメージが単独で表示されることはほとんどありません。各エンドポイントのアプリケーションとネットワークスタックのダイナミクスは、上位レベルのタスクに複数のプロトコルを使用します。たとえば、ユーザーコンテンツを含むほとんどのプロトコルは、DNSトラフィックと一緒にネットワーク上でよく見られます。特定の通信に使用されている各プロトコルのワイヤーイメージからの情報を相関させて、上にあるアプリケーションのダイナミクスに関する情報を推測できます。

Information from protocol wire images is also not generally used on its own but is rather additionally correlated with other context information available to the observer, e.g., information about other communications engaged in by each endpoint, information about the implementations of the protocols at each endpoint, information about the network and internetwork topology near those endpoints, and so on. This context can be used together with information from the wire image to reach more detailed inferences about endpoint and end-user behavior.

プロトコルワイヤーイメージからの情報も、通常、それ自体では使用されませんが、オブザーバーが利用できる他のコンテキスト情報、たとえば、各エンドポイントが関与する他の通信に関する情報、各エンドポイントでのプロトコルの実装に関する情報、とさらに関連付けられます。これらのエンドポイント付近のネットワークおよびインターネットワークトポロジに関する情報など。このコンテキストをワイヤーイメージからの情報と一緒に使用して、エンドポイントとエンドユーザーの動作に関するより詳細な推論に到達できます。

Note also that the wire image is multidimensional. This implies that the name "image" is not merely metaphorical and that general image recognition techniques may be applicable to extracting patterns and information from it.

また、ワイヤー画像は多次元であることに注意してください。これは、「画像」という名前が単なる比喩的なものではなく、一般的な画像認識手法がパターンと情報の抽出に適用できることを意味します。

3.2. Obscuring Timing and Sizing Information

3.2. タイミングとサイジング情報を不明瞭にする

Cryptography can protect the confidentiality of a protocol's headers to the extent that forwarding devices do not need the confidentiality-protected information for basic forwarding operations. Ciphersuites and other transmission techniques designed to prevent timing analysis can also be applied at the sender to reduce the information content of the metadata portion of the wire image. However, there are limits to these techniques. Packets cannot be made smaller than their information content, be sent faster than processing time requirements at the sender allow, or be transmitted through the network faster than the speed of light. Since these techniques operate at the expense of bandwidth efficiency and latency, they are also limited to the application's tolerance for latency and bandwidth inefficiency.

暗号化は、転送デバイスが基本的な転送操作のために機密保護された情報を必要としない範囲で、プロトコルのヘッダーの機密を保護できます。タイミング分析を防止するように設計された暗号スイートやその他の伝送技術を送信者に適用して、ワイヤー画像のメタデータ部分の情報コンテンツを削減することもできます。ただし、これらの手法には限界があります。パケットは、情報コンテンツよりも小さくすること、送信者が許可する処理時間要件よりも速く送信すること、または光速より速くネットワークを介して送信することはできません。これらの手法は帯域幅の効率とレイテンシを犠牲にして動作するため、レイテンシと帯域幅の非効率性に対するアプリケーションの許容範囲にも制限されます。

3.3. Integrity Protection of the Wire Image

3.3. ワイヤーイメージの完全性保護

Adding end-to-end integrity protection to portions of the wire image makes it impossible for on-path devices to modify them without detection by the endpoints, which can then take action in response to those modifications, making these portions of the wire image effectively immutable. However, they can still be observed by devices on path. This allows the creation of signals intended by the endpoints solely for the consumption of these on-path devices.

ワイヤーイメージの一部にエンドツーエンドの整合性保護を追加すると、パス上のデバイスがエンドポイントによる検出なしにデバイスを変更できなくなり、エンドポイントはそれらの変更に応答してアクションを実行し、ワイヤーイメージのこれらの部分を効果的に作成できます。不変。ただし、パス上のデバイスからは引き続き監視できます。これにより、エンドポイントがこれらのパス上のデバイスの消費のみを目的とした信号を作成できます。

Integrity protection can only practically be applied to the sequence of bits in each packet, which implies that a protocol's visible wire image cannot be made completely immutable in a packet-switched network. Interarrival timings, for instance, cannot be easily protected, as the observable delay sequence is modified as packets move through the network and experience different delays on different links. Message sequences are also not practically protectable, because packets may be dropped or reordered at any point in the network as a consequence of the network's operation. Intermediate systems with knowledge of the protocol semantics in the readable portion of the wire image can also purposely delay or drop packets in order to affect the protocol's operation.

完全性保護は実際には各パケットのビットシーケンスにのみ適用できます。これは、プロトコルの可視ワイヤイメージをパケット交換ネットワークで完全に不変にすることはできないことを意味します。たとえば、パケットがネットワークを移動し、さまざまなリンクでさまざまな遅延が発生すると、観測可能な遅延シーケンスが変更されるため、到着間タイミングを簡単に保護することはできません。ネットワークの操作の結果として、パケットがネットワーク内の任意のポイントで破棄または並べ替えられる可能性があるため、メッセージシーケンスも実際には保護できません。ワイヤイメージの読み取り可能な部分にプロトコルセマンティクスの知識がある中間システムは、プロトコルの動作に影響を与えるために、パケットを意図的に遅延またはドロップすることもできます。

4. Engineering the Wire Image

4. ワイヤーイメージのエンジニアリング

Understanding the nature of a protocol's wire image allows it to be engineered. The general principle at work here, observed through experience with deployability and non-deployability of protocols at the network and transport layers in the Internet, is that all observable parts of a protocol's wire image will eventually be used by devices on path. Consequently, changes or future extensions that affect the observable part of the wire image become difficult or impossible to deploy.

プロトコルのワイヤーイメージの性質を理解することで、プロトコルを設計できます。ここでの一般的な原則は、インターネットのネットワーク層とトランスポート層でのプロトコルの展開可能性と非展開可能性の経験を通じて観察されたものであり、プロトコルのワイヤーイメージのすべての監視可能な部分は、最終的にはパス上のデバイスによって使用されるということです。その結果、ワイヤーイメージの監視可能な部分に影響を与える変更または将来の拡張は、展開が困難または不可能になります。

A network function that serves a purpose useful to its deployer will use the information it needs from the wire image and will tend to get that information from the wire image in the simplest way possible.

デプロイヤーにとって有用な目的を果たすネットワーク機能は、ワイヤー・イメージから必要な情報を使用し、ワイヤー・イメージからその情報を可能な限り単純な方法で取得する傾向があります。

For example, consider the case of the ubiquitous TCP [RFC793] transport protocol. As described in [RFC8558], several key in-network functions have evolved to take advantage of implicit signals in TCP's wire image, which, as TCP provides neither integrity or confidentiality protection for its headers, is inseparable from its internal operation. Some of these include:

たとえば、ユビキタスTCP [RFC793]トランスポートプロトコルの場合を考えてみます。 [RFC8558]で説明されているように、いくつかの主要なネットワーク内機能が進化し、TCPのワイヤーイメージの暗黙的な信号を利用しています。TCPはヘッダーの整合性または機密性保護を提供しないため、内部操作と切り離せません。これらのいくつかは次のとおりです。

o Determining return routability and consent: For example, TCP's wire image contains both an implicit indication that the sender of a packet is at least on the path toward its source address (in the acknowledgement number during the handshake), as well as an implicit indication that a receiving device consents to continue communication. These are used by stateful network firewalls.

o リターンルーティング可能性と同意の決定：たとえば、TCPのワイヤーイメージには、パケットの送信者が少なくともその送信元アドレスへのパス上にあるという暗黙の指示（ハンドシェイク中の確認応答番号で）と、受信デバイスは通信を継続することに同意します。これらは、ステートフルネットワークファイアウォールで使用されます。

o Measuring loss and latency: For example, examining the sequence of TCP's sequence and acknowledgement numbers, as well as the ECN [RFC3168] control bits, allows the inference of congestion, loss, and retransmission along the path. The sequence and acknowledgement numbers together with the timestamp option [RFC7323] allow the measurement of application-experienced latency.

o 損失とレイテンシの測定：たとえば、TCPのシーケンスと確認番号のシーケンス、およびECN [RFC3168]制御ビットを調べることで、パスに沿った輻輳、損失、および再送信を推測できます。シーケンス番号と確認応答番号とタイムスタンプオプション[RFC7323]を併用すると、アプリケーションで発生したレイテンシを測定できます。

During the design of a protocol, the utility of features like these should be considered. The protocol's wire image can be designed to explicitly expose information to those network functions deemed important by the designers. The wire image should expose as little other information as possible.

プロトコルの設計時には、これらのような機能の有用性を考慮する必要があります。プロトコルのワイヤーイメージは、設計者が重要と見なしたネットワーク機能に情報を明示的に公開するように設計できます。ワイヤーイメージは、他の情報をできるだけ少なく公開する必要があります。

However, even when information is explicitly provided to the network, any information that is exposed by the wire image, even information not intended to be consumed by an observer, must be designed carefully, as deployed network functions using that information may render it immutable for future versions of the protocol. For example, information needed to support decryption by the receiving endpoint (cryptographic handshakes, sequence numbers, and so on) may be used by devices along the path for their own purposes.

ただし、情報がネットワークに明示的に提供されている場合でも、ワイヤーイメージによって公開される情報は、オブザーバーが使用することを意図していない情報であっても、慎重に設計する必要があります。プロトコルの将来のバージョン。たとえば、受信エンドポイントによる復号化をサポートするために必要な情報（暗号化ハンドシェイク、シーケンス番号など）は、パスに沿ったデバイスが独自の目的で使用する場合があります。

4.1. Declaring Protocol Invariants

4.1. プロトコル不変条件の宣言

One potential approach to reduce the extent of the wire image that will be used by devices on the path is to define a set of invariants for a protocol during its development. Declaring a protocol's invariants represents a promise made by the protocol's developers that certain bits in the wire image, and behaviors observable in the wire image, will be preserved through the specification of all future versions of the protocol. QUIC's invariants [QUIC-INVARIANTS] are an initial attempt to apply this approach to QUIC.

パス上のデバイスによって使用されるワイヤーイメージの範囲を削減するための1つの潜在的なアプローチは、その開発中にプロトコルの不変条件のセットを定義することです。プロトコルの不変条件の宣言は、プロトコルの開発者によって、ワイヤーイメージの特定のビット、およびワイヤーイメージで観察可能な動作が、プロトコルのすべての将来のバージョンの仕様を通じて保持されるという約束を表します。 QUICの不変式[QUIC-INVARIANTS]は、このアプローチをQUICに適用する最初の試みです。

While static aspects of the wire image (bits with simple semantics at fixed positions in protocol headers) can easily be made invariant, different aspects of the wire image may be more or less appropriate to define as invariants. For a protocol with a version and/or extension negotiation mechanism, the bits in the header and the behaviors tied to those bits, which implement version negotiation, should be made invariant. More fluid aspects of the wire image and behaviors that are not necessary for interoperability are not appropriate as invariants.

ワイヤーイメージの静的な側面（プロトコルヘッダーの固定位置に単純なセマンティクスを持つビット）は簡単に不変にすることができますが、ワイヤーイメージのさまざまな側面が不変として定義するのに多少適している場合があります。バージョンや拡張のネゴシエーションメカニズムを備えたプロトコルの場合、ヘッダーのビットと、バージョンネゴシエーションを実装するこれらのビットに結び付けられた動作は、不変にする必要があります。ワイヤーイメージのより流動的な側面と相互運用性に必要のない動作は、不変条件として適切ではありません。

Parts of a protocol's wire image not declared invariant but intended to be visible to devices on path should be protected against "accidental invariance": the deployment of on-path devices over time that make simplifying assumptions about the behavior of those parts of the wire image, making new behaviors not meeting those assumptions difficult to deploy. Integrity protection of the wire image may itself help protect against accidental invariance, because read-only wire images invite less meddling than path-writable wire images. The techniques discussed in [USE-IT] may also be useful in further preventing accidental invariance and ossification.

不変として宣言されていないがパス上のデバイスから見えるようにすることを意図したプロトコルのワイヤーイメージの部分は、「偶発的な不変性」から保護する必要があります。ワイヤーイメージのそれらの部分の動作についての仮定を単純化する、長期にわたるパス上のデバイスの展開、それらの想定を満たさない新しい動作を展開することを困難にします。読み取り専用のワイヤーイメージはパス書き込み可能なワイヤーイメージよりも干渉が少ないため、ワイヤーイメージの整合性保護自体が偶発的な不変性からの保護に役立つ場合があります。 [USE-IT]で説明されている手法は、偶発的な不変性や骨化をさらに防ぐのにも役立つ場合があります。

Likewise, parts of a protocol's wire image not declared invariant and not intended to be visible to the path should be encrypted to protect their confidentiality. When confidentiality protection is either not possible or not practical, then, as above, the approaches discussed in [USE-IT] may be useful in ossification prevention.

同様に、不変であると宣言されておらず、パスから見えるように意図されていないプロトコルのワイヤーイメージの部分は、それらの機密性を保護するために暗号化されるべきです。機密保護が不可能または実用的でない場合、上記のように、[USE-IT]で説明されているアプローチは、骨化の予防に役立つ可能性があります。

4.2. Trustworthiness of Engineered Signals

4.2. 設計された信号の信頼性

Since signals in the wire image that are engineered to be exposed are separate from the signals that drive an encrypted protocol's mechanisms, the accuracy of these signals intended for consumption by the path may not be verifiable by on-path devices; see [RFC8558].

公開されるように設計されたワイヤーイメージ内の信号は、暗号化されたプロトコルのメカニズムを駆動する信号とは異なるため、パスによる消費を目的としたこれらの信号の精度は、パス上のデバイスでは検証できない場合があります。 [RFC8558]を参照してください。

Indeed, any two endpoints with a secret channel between them (in this case, the encrypted protocol itself) may collude to change the semantics and information content of these signals. This is an unavoidable consequence of the separation of the wire image from the protocol's operation afforded by confidentiality protection of the protocol's headers.

実際、間に2つのエンドポイント（この場合、暗号化されたプロトコル自体）の間に秘密チャネルがある2つのエンドポイントは、これらの信号のセマンティクスと情報コンテンツを変更するために共謀する可能性があります。これは、プロトコルのヘッダーの機密保護により、ワイヤーイメージがプロトコルの動作から分離されることによる避けられない結果です。

5. IANA Considerations

5. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

6. Security Considerations

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

This document explores the information exposed by the wire image that may be relevant to end-to-end communication privacy and security. When designing the wire image of a network protocol, care must be taken to expose only that information to the network deemed necessary in the protocol's design, and careful design is necessary to reduce the risk that information not explicitly included in the wire image is derivable from its observation.

このドキュメントでは、エンドツーエンドの通信のプライバシーとセキュリティに関連する可能性のある、ワイヤー画像によって公開される情報について説明します。ネットワークプロトコルのワイヤーイメージを設計するときは、プロトコルの設計に必要であると見なされるネットワークにその情報のみを公開するように注意する必要があり、ワイヤーイメージに明示的に含まれていない情報が派生するリスクを減らすために注意深い設計が必要ですその観察。

7. Informative References

7. 参考引用

[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, draft-ietf-quic-transport-19, March 2019.

[QUIC] Iyengar、J。およびM. Thomson、「QUIC：A UDPベースの多重化された安全なトランスポート」、作業中、draft-ietf-quic-transport-19、2019年3月。

[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", Work in Progress, draft-ietf-quic-invariants-04, April 2019.

[QUIC-INVARIANTS] Thomson、M。、「バージョンに依存しないQUICのプロパティ」、Work in Progress、draft-ietf-quic-invariants-04、2019年4月。

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[RFC7323] Borman、D.、Braden、B.、Jacobson、V。、およびR. Scheffenegger、編、「高性能のTCP拡張機能」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：// www.rfc-editor.org/info/rfc7323>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.

[RFC8558] Hardie、T。、編、「Transport Protocol Path Signals」、RFC 8558、DOI 10.17487 / RFC8558、2019年4月、<https://www.rfc-editor.org/info/rfc8558>。

[USE-IT] Thomson, M., "Long-term Viability of Protocol Extension Mechanisms", Work in Progress, draft-thomson-use-it-or-lose-it-03, January 2019.

[USE-IT] Thomson、M.、「プロトコル拡張メカニズムの長期的な実行可能性」、Work in Progress、draft-thomson-use-it-or-lose-it-03、2019年1月。

IAB Members at the Time of Approval

承認時のIABメンバー

Jari Arkko Alissa Cooper Ted Hardie Christian Huitema Gabriel Montenegro Erik Nordmark Mark Nottingham Melinda Shore Robert Sparks Jeff Tantsura Martin Thomson Brian Trammell Suzanne Woolf

ジャリアルコアリッサクーパーテッドハーディクリスチャンウイテマガブリエルモンテネグロエリックノードマークマークノッティンガムメリンダショアロバートスパークスジェフタンツラマーティントムソンブライアントラメルスザンヌウルフ

Acknowledgments

謝辞

Thanks to Martin Thomson, Stephen Farrell, Thomas Fossati, Ted Hardie, Mark Nottingham, Tommy Pauly, and the membership of the IAB Stack Evolution Program for text, feedback, and discussions that have improved this document.

Martin Thomson、Stephen Farrell、Thomas Fossati、Ted Hardie、Mark Nottingham、Tommy Pauly、およびこのドキュメントを改善したテキスト、フィードバック、ディスカッションのためのIAB Stack Evolution Programのメンバーに感謝します。

This work is partially supported by the European Commission under Horizon 2020 grant agreement No. 688421, Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract No. 15.0268. This support does not imply endorsement.

この作業は、Horizon 2020助成金契約No. 688421、Middleboxed Internet（MAMI）のMeasurement and Architectureに基づく欧州委員会、および契約番号15.0268に基づくスイス教育研究革新局により、部分的にサポートされています。このサポートは保証を意味するものではありません。

Authors' Addresses

著者のアドレス

Brian Trammell ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland

ブライアントラメルETHチューリッヒGloriastrasse 35 8092チューリッヒスイス

   Email: ietf@trammell.ch

Mirja Kuehlewind ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland

Mirja Kuehlewind ETH Zurich Gloriastrasse 35 8092チューリッヒスイス

   Email: ietf@kuehlewind.net