[要約] RFC 7663は、IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)の報告書です。その目的は、ミドルボックスインターネットにおけるスタックの進化に関する議論をまとめ、将来のインターネットアーキテクチャの改善に役立てることです。
Internet Architecture Board (IAB) B. Trammell, Ed.
Request for Comments: 7663 M. Kuehlewind, Ed.
Category: Informational ETH Zurich
ISSN: 2070-1721 October 2015
Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)
ミドルボックスインターネット（SEMI）でのスタックの進化に関するIABワークショップからのレポート
Abstract
概要
The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
IPスタックエボリューションプログラム、インターネットソサエティ、スイス連邦工科大学（ETH）チューリッヒによるインターネットアーキテクチャボード（IAB）は、2015年1月26〜27日にチューリッヒでミドルボックスインターネット（SEMI）ワークショップのスタックエボリューションを主催しました。ミドルボックスおよびインターフェイス関連のスタックの骨化が存在する場合に、トランスポート層を進化させる機能を探索します。ワークショップの目的は、エンドポイント（新しいトランスポートレイヤーとアプリケーション）とミドルボックス（によって実行される）の両方に展開する明確なインセンティブを備えた段階的に展開可能なアプローチに焦点を当て、今後の作業でアーキテクチャのエンジニアリングガイダンスを作成して、停滞を打破することでした。ネットワーク事業者）。このドキュメントは、ワークショップへの貢献を要約し、ワークショップでの議論の概要、およびワークショップで特定された結果と次のステップを提供します。このレポートに記載されている見解と見解はワークショップ参加者のものであり、必ずしもIABの見解と見解を反映しているわけではありません。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7663.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7663で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Organization of This Report . . . . . . . . . . . . . . . 4
2. The Situation in Review . . . . . . . . . . . . . . . . . . . 4
3. Incentives for Stack Ossification and Evolution . . . . . . . 5
4. The Role and Rule of Middleboxes . . . . . . . . . . . . . . 6
5. Evolving the Transport Layer . . . . . . . . . . . . . . . . 6
6. Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Minimal Signaling for Encapsulated Transports . . . . . . 7
6.2. Middlebox Measurement . . . . . . . . . . . . . . . . . . 8
6.3. Guidelines for Middlebox Design and Deployment . . . . . 9
6.4. Architectural Guidelines for Transport Stack Evolution . 9
6.5. Additional Activities in the IETF and IAB . . . . . . . . 10
6.6. Additional Activities in Other Venues . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Attendees . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
The transport layer of the Internet has become ossified, squeezed between narrow interfaces (from BSD sockets to pseudo-transport over HTTPS) and increasing in-network modification of traffic by middleboxes that make assumptions about the protocols running through them. This ossification makes it difficult to innovate in the transport layer, through the deployment of new protocols or the extension of existing ones. At the same time, emerging applications require functionality that existing protocols can provide only inefficiently, if at all.
インターネットのトランスポート層は骨化し、狭いインターフェース（BSDソケットからHTTPS経由の疑似トランスポートまで）の間で圧迫され、それらを介して実行されるプロトコルについての仮定を行うミドルボックスによるトラフィックのネットワーク内変更が増加しています。この骨化により、新しいプロトコルの導入や既存のプロトコルの拡張により、トランスポート層の革新が困難になります。同時に、新興のアプリケーションは、既存のプロトコルが提供できるとしても、非効率的にしか提供できない機能を必要とします。
To begin to address this problem, the IAB, within the scope of its IP Stack Evolution Program, organized a workshop to discuss approaches to de-ossify transport, especially with respect to interactions with middleboxes and new methods for implementing transport protocols. Recognizing that the end-to-end principle has long been compromised, we start with the fundamental question of matching paths through the Internet with certain characteristics to application and transport requirements.
この問題に対処するために、IABはIPスタック進化プログラムの範囲内でワークショップを組織し、特にミドルボックスとの相互作用とトランスポートプロトコルを実装するための新しい方法に関して、トランスポートを骨化除去するアプローチについて議論しました。エンドツーエンドの原則が長い間妥協されてきたことを認識し、アプリケーションとトランスポートの要件に特定の特性を備えたインターネット経由のパスを一致させるという基本的な質問から始めます。
We posed the following questions in the call for papers: Which paths through the Internet are actually available to applications? Which transports can be used over these paths? How can applications cooperate with network elements to improve path establishment and discovery? Can common transport functionality and standardization help application developers to implement and deploy such approaches in today's Internet? Could cooperative approaches give us a way to rebalance the Internet back toward its end-to-end roots?
論文募集で次の質問をしました。実際にアプリケーションが利用できるインターネット経由のパスはどれですか。これらのパスで使用できるトランスポートはどれですか？アプリケーションはネットワーク要素とどのように連携してパスの確立と検出を改善できますか？共通のトランスポート機能と標準化は、アプリケーション開発者が今日のインターネットにそのようなアプローチを実装して展開するのに役立つでしょうか？協調的なアプローチは、インターネットをエンドツーエンドのルーツに向けて再バランスさせる方法を私たちに与えることができるでしょうか？
The call for papers encouraged a focus on approaches that are incrementally deployable within the present Internet. Identified topics included the following:
論文の募集により、現在のインターネット内で段階的に展開できるアプローチに焦点を当てることが奨励されました。識別されたトピックには以下が含まれます。
o Development and deployment of transport-like features in application-layer protocols
o アプリケーション層プロトコルでのトランスポートのような機能の開発と展開
o Methods for discovery of path characteristics and protocol availability along a path
o パスに沿ったパスの特性とプロトコルの可用性を検出する方法
o Methods for middlebox detection and characterization of middlebox behavior and functionality
o ミドルボックスの検出およびミドルボックスの動作と機能の特性評価の方法
o Methods for NAT and middlebox traversal in the establishment of end-to-end paths
o エンドツーエンドパスの確立におけるNATおよびミドルボックストラバーサルの方法
o Mechanisms for cooperative path-endpoint signaling, and lessons learned from existing approaches
o 協調パスエンドポイントシグナリングのメカニズム、および既存のアプローチから学んだ教訓
o Economic considerations and incentives for cooperation in middlebox deployment
o ミドルボックスの展開における協力のための経済的な考慮事項とインセンティブ
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計されたワークショップを時折開催します。 IABのこの長期計画機能は、インターネットエンジニアリングステアリンググループ（IESG）と地域のディレクターのリーダーシップの下で、インターネットエンジニアリングタスクフォース（IETF）のワーキンググループによって実行されているエンジニアリングの取り組みを補完します。
The SEMI workshop followed in part from the IAB's longer term interest in the evolution of the Internet and the adoption of Internet protocols, including the Internet Technology Adoption and Transition workshop [RFC7305], "What Makes for a Successful Protocol" [RFC5218], back to Deering's plenary talk [deering-plenary] at IETF 51 in 2001.
SEMIワークショップは、インターネットの進化とインターネットプロトコルの採用に対するIABの長期的な関心の一部であり、インターネットテクノロジーの採用と移行ワークショップ[RFC7305]、「成功するプロトコルを実現するもの」[RFC5218]を含みます。 2001年のIETF 51でのディアリングの本会議[deering-plenary]に出席。
This workshop report summarizes the contributions to, and discussions at the workshop, organized by topic. We started with a summary of the current situation with respect to stack ossification, and explored the incentives that have made it that way and the role of incentives in evolution. Many contributions were broadly split into two areas: middlebox measurement, classification, and approaches to defense against middlebox modification of packets; and approaches to support transport evolution. All accepted position papers and detailed transcripts of discussion are available at https://www.iab.org/activities/workshops/semi/.
このワークショップレポートは、ワークショップへの貢献とワークショップでの議論をトピック別にまとめたものです。スタックの骨化に関する現在の状況の概要から始め、そのようにしたインセンティブと、進化におけるインセンティブの役割を調査しました。多くの貢献は、大きく2つの領域に分かれました。ミドルボックスの測定、分類、およびパケットのミドルボックスの変更に対する防御のアプローチ。トランスポートの進化をサポートするアプローチ。承認されたすべてのポジションペーパーとディスカッションの詳細な筆記録は、https：//www.iab.org/activities/workshops/semi/で入手できます。
The outcomes of the workshop are discussed in Section 6, including progress after the workshop toward each of the identified work items as of the time of publication of this report.
ワークショップの結果については、このレポートの発行時点でのワークショップ後の特定された各作業項目に向けた進捗状況を含め、セクション6で説明します。
At the time of Deering's talk in 2001, network address translation (NAT) was identified as the key challenge to the Internet architecture. Since then, the NAT traversal problem has been largely solved, but the boxes in the middle are getting smarter and more varied.
2001年のDeeringの講演の時点で、ネットワークアドレス変換（NAT）は、インターネットアーキテクチャの主要な課題として特定されていました。それ以来、NATトラバーサルの問題は大幅に解決されましたが、中央のボックスはよりスマートで多様になっています。
SEMI, as the IP Stack Evolution program in general, is far from the first attempt to solve the problems caused by middlebox interference in the end-to-end model. Just within the IETF, the MIDCOM, NSIS, and BEHAVE efforts have addressed this problem, and the TRAM working group is updating the NAT traversal outcomes of MIDCOM to reflect current reality.
SEMIは、一般にIP Stack Evolutionプログラムとして、エンドツーエンドモデルのミドルボックス干渉によって引き起こされる問題を解決する最初の試みとはかけ離れています。 IETF内で、MIDCOM、NSIS、およびBEHAVEの取り組みがこの問題に対処しており、TRAMワーキンググループは、MIDCOMのNATトラバーサルの結果を更新して、現在の現実を反映しています。
We believe we have an opportunity to improve the situation in the present, however, due to a convergence of forces. While the tussle between security and middleboxes is not new, the accelerating deployment of cryptography for integrity and confidentiality makes many packet inspection and packet modification operations obsolete, creating pressure to improve the situation. There is also new energy in the IETF around work that requires transport-layer flexibility we're not sure we have (e.g., WebRTC) as well as flexibility at the transport interface (TAPS).
しかし、勢力の収束により、現在の状況を改善する機会があると信じています。セキュリティとミドルボックスの間の闘争は新しいものではありませんが、整合性と機密性のための暗号化の展開の加速により、多くのパケット検査とパケット変更操作が時代遅れになり、状況を改善する圧力が生じます。 IETFには、トランスポートインターフェース（TAPS）での柔軟性だけでなく、トランスポートレイヤーの柔軟性（WebRTCなど）が必要かどうかを確認する必要がある新しいエネルギーもあります。
The current situation is, of course, the result of a variety of processes, and the convergence of incentives for network operators, content providers, network equipment vendors, application developers, operating system developers, and end users. Moore's Law makes it easier to deploy more processing on-path, network operators need to find ways to add value, enterprises find it more scalable to deploy functionality in-network than on endpoints, and middleboxes are something vendors can vend. These trends increase ossification of the network stack.
もちろん、現在の状況はさまざまなプロセスの結果であり、ネットワークオペレーター、コンテンツプロバイダー、ネットワーク機器ベンダー、アプリケーション開発者、オペレーティングシステム開発者、およびエンドユーザーに対するインセンティブの収束です。ムーアの法則により、より多くの処理をパス上に展開しやすくなり、ネットワークオペレーターは付加価値を追加する方法を見つける必要があり、企業はエンドポイント上よりもネットワーク内に機能を展開する方がスケーラブルであることがわかります。これらの傾向は、ネットワークスタックの骨化を増加させます。
Any effort to reduce the resulting ossification in order to make it easier to evolve the transport stack, then, must consider the incentives to deployment of new approaches by each of these actors.
トランスポートスタックをより簡単に進化させるために、結果として生じる骨化を減らすためのあらゆる努力は、これらの各アクターによる新しいアプローチの展開へのインセンティブを考慮する必要があります。
As Christian Huitema [huitema-semi] pointed out, encryption provides a powerful incentive here: putting a transport protocol atop a cryptographic protocol atop UDP resets the transport versus middlebox tussle by making inspection and modification above the encryption and demux layer impossible. Any transport evolution strategy using this approach must also deliver better performance or functionality (e.g., setup latency) than existing approaches while being as deployable as these approaches, or moreso.
Christian Huitema [huitema-semi]が指摘したように、暗号化はここで強力なインセンティブを提供します。UDPの上にトランスポートプロトコルを暗号化プロトコルの上に置くと、暗号化とデマルチプレクサレイヤーの上で検査と変更を不可能にすることによって、トランスポートとミドルボックスの闘争をリセットします。このアプローチを使用するトランスポートの進化戦略は、これらのアプローチと同様に展開可能でありながら、既存のアプローチよりも優れたパフォーマンスまたは機能（セットアップのレイテンシなど）を提供する必要があります。
Indeed, significant positive net value at each organization where change is required -- operators, application developers, equipment vendors, enterprise and private users -- is best to drive deployment of a new protocol, said Dave Thaler, pointing to [RFC5218]. All tussles in networking stem from conflicting incentives unavoidable in a free market. For upper-layer protocols, incentives tend to favor protocols that work anywhere, use the most efficient mechanism that works, and are as simple as possible from an implementation, maintenance, and management standpoint. For lower-layer protocols, incentives tend toward ignoring and or disabling optional features, as there is a positive feedback cycle between being rarely used and rarely implemented.
実際、変更が必要な各組織（オペレーター、アプリケーション開発者、機器ベンダー、エンタープライズユーザー、プライベートユーザー）での有意な正の正味価値は、新しいプロトコルの導入を推進するのに最適であると、Dave Thalerは指摘している[RFC5218]。ネットワーキングにおけるすべての問題は、自由市場で避けられないインセンティブの相反から生じています。上位層プロトコルの場合、インセンティブはどこでも機能するプロトコルを優先する傾向があり、機能する最も効率的なメカニズムを使用し、実装、保守、および管理の観点からできるだけ単純です。下位層プロトコルの場合、インセンティブはオプション機能を無視または無効にする傾向があります。これは、ほとんど使用されず、ほとんど実装されない間に正のフィードバックサイクルがあるためです。
Middleboxes are commonplace in the Internet and constrain the ability to deploy new protocols and protocol extensions. Engineering around this problem requires a "bestiary" of middleboxes, a classification of which kinds of impairments middleboxes cause and how often, according to Benoit Donnet [edeline-semi].
ミドルボックスはインターネットでは一般的であり、新しいプロトコルとプロトコル拡張を展開する機能を制限します。 Benoit Donnet [edeline-semi]によると、この問題に関連するエンジニアリングには、ミドルボックスの「獣医」、つまりミドルボックスが引き起こす障害の種類と頻度の分類が必要です。
Even though the trend towards Network Function Visualization (NFV) allows for faster update-cycle of middleboxes and thereby more flexibility, the function provided by middleboxes will stay. In fact, service chaining may lead to more and more add-ons to address and manage problems in the network, in turn further increasing the complexity of network management. Ted Hardie [hardie-semi] warned that each instance may add a new queue and may increase the bufferbloat problem that is counterproductive for new emerging latency-sensitive applications. However, this new flexibility also provides a chance to move functionality back to the end host. Alternately, more appropriate in-network functionality could benefit from additional information in application and path characteristics, though this in turn implies a variety of complicated trust relationships among nodes in the network. In any case, an increasing trend of in-network functionality can be observed, especially in mobile networks.
ネットワーク機能の視覚化（NFV）の傾向により、ミドルボックスの更新サイクルが速くなり、柔軟性が向上しますが、ミドルボックスによって提供される機能は維持されます。実際、サービスチェーンにより、ネットワークの問題に対処および管理するためのアドオンが増加し、ネットワーク管理の複雑さがさらに増大する可能性があります。 Ted Hardie [hardie-semi]は、各インスタンスが新しいキューを追加し、新たに発生するレイテンシの影響を受けやすいアプリケーションにとって逆効果であるバッファブロートの問題を増大させる可能性があると警告しました。ただし、この新しい柔軟性により、機能をエンドホストに戻すことができます。あるいは、より適切なネットワーク内機能は、アプリケーションおよびパス特性の追加情報から利益を得ることができますが、これは、ネットワーク内のノード間のさまざまな複雑な信頼関係を意味します。いずれにせよ、特にモバイルネットワークでは、ネットワーク内機能の増加傾向が見られます。
Costin Raiciu [raiciu-semi] stated that middleboxes make the Internet unpredictable, leading to a trade-off between efficiency and reachability. While constructive cooperation with middleboxes to establish a clear contract between the network and the endpoint might be one approach to address this challenge, enforcement of contract in less cooperative environments might require extensive tunneling. Raiciu's contribution on "ninja tunneling" illustrates one such approach.
Costin Raiciu [raiciu-semi]は、ミドルボックスはインターネットを予測不可能にし、効率と到達可能性のトレードオフにつながると述べました。ネットワークとエンドポイント間の明確な契約を確立するためのミドルボックスとの建設的な協力は、この課題に対処するための1つのアプローチかもしれませんが、協調性の低い環境で契約を実施するには、広範なトンネリングが必要になる場合があります。 「忍者トンネリング」に関するライチウの貢献は、そのようなアプローチの1つを示しています。
For evolution in the transport layer itself, various proposals have been discussed, reaching from the development of new protocols (potentially as user-level stacks) encapsulated in UDP as a transport identification sub-header to the use of TCP as a substrate where the semantics of TCP are relaxed (e.g., regarding reliability, ordering, flow control, etc.) and a more flexible API is provided to the application.
トランスポート層自体の進化については、UDPにカプセル化された新しいプロトコル（潜在的にはユーザーレベルのスタック）の開発からトランスポート識別サブヘッダーとしてのTCPの使用に至るまで、さまざまな提案が議論されてきました。 TCPの信頼性が緩和され（信頼性、順序、フロー制御などに関して）、より柔軟なAPIがアプリケーションに提供されます。
Discussion on evolution during the workshop divided amicably along two lines: working to fix the deployability of TCP extensions (referred to in discussion as "the TCP Liberation Front") versus working to build new encapsulation-based mechanisms to allow wholly new protocols to be deployed (referred to in discussion as "the People's Front of UDP"). David Black [black-semi] pointed out that UDP encapsulation has to be adapted and separately discussed for every use case, which can be a long and painful process. UDP encapsulation can be an approach to develop more specialized protocols that helps to address special needs of certain applications. However, Stuart Cheshire [cheshire-semi] (as presented by Brian Trammell) pointed out that designing a new protocol instead of fixing/extending TCP might not always solve the problem.
ワークショップ中の進化についての議論は、2つの線に沿って友好的に分かれました。TCP拡張の展開可能性を修正する作業（「TCP解放戦線」と呼ばれます）と、完全に新しいプロトコルを展開できるようにする新しいカプセル化ベースのメカニズムを構築する作業（議論では「UDPの人民戦線」と呼ばれます）。 David Black [black-semi]は、UDPカプセル化を適応させ、すべてのユースケースについて個別に議論する必要があることを指摘しました。 UDPカプセル化は、特定のアプリケーションの特別なニーズに対処するのに役立つ、より専門的なプロトコルを開発するためのアプローチとなります。ただし、Stuart Cheshire [cheshire-semi]（Brian Trammellが発表）は、TCPを修正/拡張する代わりに新しいプロトコルを設計しても問題が解決しない場合があることを指摘しました。
To address the extensibility problem of TCP, Bob Briscoe proposed Inner Space [briscoe-semi]. Here, the general principle is to extend layer X's header within layer X+1; in the case of TCP, additional TCP header and option space is provided within the TCP payload, such that it cannot presently be inspected and modified by middleboxes.
TCPの拡張性の問題に対処するために、Bob BriscoeはInner Space [briscoe-semi]を提案しました。ここでは、一般的な原則は、レイヤーXのヘッダーをレイヤーX + 1内に拡張することです。 TCPの場合、追加のTCPヘッダーとオプションスペースがTCPペイロード内に提供されるため、現在ミドルボックスで検査および変更できません。
Further, instead of only focusing on those cases where new extensions and protocols are not deployable, Micheal Welzl [welzl-semi] points out that there are also a lot of paths in the network that are not ossified. To enable deployment on these paths, an end host would need to probe or use a happy-eyeball-like approach [RFC6555] and potentially fallback. The TAPS working group implements the first step to decouple applications from transport protocols allowing for the needed flexibility in the transport layer.
さらに、Micheal Welzl [welzl-semi]は、新しい拡張機能とプロトコルを展開できない場合のみに焦点を当てるのではなく、ネットワーク内に骨化されていない多くのパスがあることを指摘しています。これらのパスでの展開を可能にするには、エンドホストは幸福な目玉のようなアプローチ[RFC6555]を調査または使用する必要があり、フォールバックする可能性があります。 TAPSワーキンググループは、アプリケーションをトランスポートプロトコルから切り離すための最初のステップを実装して、トランスポート層で必要な柔軟性を可能にします。
The SEMI workshop identified several areas for further work, outlined below.
SEMIワークショップは、以下に概説する、さらなる作業のためのいくつかの領域を特定しました。
Assuming that a way forward for transport evolution in user space would involve encapsulation in UDP datagrams, the workshop identified that it may be useful to have a facility built atop UDP to provide minimal signaling of the semantics of a flow that would otherwise be available in TCP: at the very least, indications of first and last packets in a flow to assist firewalls and NATs in policy decision and state maintenance. This facility could also provide minimal application-to-path and path-to-application signaling, though there was less agreement on exactly what should or could be signaled here.
ユーザースペースでのトランスポートの進化の前進にはUDPデータグラムのカプセル化が含まれると想定し、ワークショップでは、UDPの上に機能を構築して、通常はTCPで利用できるフローのセマンティクスの最小限のシグナリングを提供することが有用である可能性があることを確認しました：少なくとも、フローの最初と最後のパケットの兆候は、ファイアウォールとNATがポリシーの決定と状態の維持に役立つようにします。この機能はまた、最小限のアプリケーションからパスへのパスおよびパスからアプリケーションへのシグナリングを提供できますが、ここで何をシグナリングする必要があるか、またはシグナリングできるかについてはあまり合意がありませんでした。
The workshop did note that, given the increasing deployment of encryption in the Internet, this facility should cooperate with Datagram Transport Layer Security (DTLS) [RFC6347] in order to selectively expose information about traffic flows where the transport headers and payload themselves are encrypted.
ワークショップでは、インターネットでの暗号化の導入が増加していることから、トランスポートヘッダーとペイロード自体が暗号化されているトラフィックフローに関する情報を選択的に公開するために、この機能はデータグラムトランスポート層セキュリティ（DTLS）[RFC6347]と連携する必要があることに注意しました。
To develop this concept further, it was decided to propose a BoF session that would not form a working group, SPUD (Substrate Protocol for User Datagrams), at the IETF 92 meeting in March in Dallas. A document on use cases [SPUD-USE], a prototype specification for a shim protocol over UDP [SPUD-PROTO], and a separate specification of the use of DTLS as a subtransport layer [TLS-DTLS] were prepared following discussions at SEMI and presented at the BoF.
この概念をさらに発展させるために、3月にダラスで開催されたIETF 92会議で、ワーキンググループSPUD（Substrate Protocol for User Datagrams）を形成しないBoFセッションを提案することが決定されました。ユースケースに関するドキュメント[SPUD-USE]、UDPを介したシムプロトコルのプロトタイプ仕様[SPUD-PROTO]、およびサブトランスポートレイヤーとしてのDTLSの使用に関する個別の仕様[TLS-DTLS]は、SEMIでの議論に従って準備されました。そしてBoFで発表されました。
Clear from discussion before and during the SPUD BoF, and drawing on experience with previous endpoint-to-middle and middle-to-endpoint signaling approaches, is that any selective exposure of traffic metadata outside a relatively restricted trust domain must be declarative as opposed to imperative, non-negotiated, and advisory. Each exposed parameter should also be independently verifiable, so that each entity can assign its own trust to other entities. Basic transport over the substrate must continue working even if signaling is ignored or stripped, to support incremental deployment. These restrictions on vocabulary are discussed further in [EXP-COOP].
SPUD BoFの前と最中の議論から明らかであり、以前のエンドポイントからミドルおよびミドルからエンドポイントへのシグナリングアプローチの経験を利用すると、比較的制限された信頼ドメインの外部でトラフィックメタデータを選択的に公開することは、義務付けられており、交渉されておらず、助言です。各公開されたパラメーターは、各エンティティが他のエンティティに独自の信頼を割り当てることができるように、独立して検証可能であるべきです。インクリメンタル展開をサポートするには、シグナリングが無視されたり取り除かれたりした場合でも、基板上での基本的な転送が継続して機能する必要があります。これらの語彙の制限については、[EXP-COOP]で詳しく説明されています。
There was much interest in the room in continuing work on an approach like the one under discussion. It was relatively clear that the state of the discussion and prototyping activity now is not yet mature enough for standardization within an IETF working group. An appropriate venue for continuing the work remains unclear.
議論中のアプローチのような作業を継続することについては、部屋に大きな関心がありました。 IETFワーキンググループ内での標準化に向けて、議論とプロトタイピング活動の状態がまだ十分に成熟していないことは比較的明らかでした。作業を継続するための適切な場所は不明なままです。
Discussion continues on the spud mailing list (spud@ietf.org). The UDP shim layer prototype is described by [SPUD-PROTO].
議論はspudメーリングリスト（spud@ietf.org）で続けられます。 UDPシム層プロトタイプは[SPUD-PROTO]で記述されています。
Discussion about the impairments caused by middleboxes quickly identified the need to get more and better data about how prevalent certain types of impairments are in the network. It doesn't make much sense, for instance, to engineer complex workarounds for certain types of impairments into transport protocols if those impairments are relatively rare. There are dedicated measurement studies for certain types of impairment, but the workshop noted that prevalence data might be available from error logs from TCP stacks and applications on both clients and servers: these entities are in a position to know when attempts to use particular transport features failed, providing an opportunity to measure the network as a side effect of using it. Many clients already have a feature for sending these bug reports back to their developers. These present opportunities to bring data to bear on discussion and decisions about protocol engineering in an Internet full of middleboxes.
ミドルボックスによって引き起こされる障害についての議論により、特定の種類の障害がネットワークにどの程度蔓延しているかについて、より多くのより良いデータを取得する必要性がすぐにわかりました。たとえば、特定の種類の障害が比較的まれである場合、それらの障害のトランスポートプロトコルに複雑な回避策を設計することはあまり意味がありません。特定の種類の障害に関する専用の測定調査がありますが、ワークショップでは、クライアントとサーバーの両方のTCPスタックとアプリケーションからのエラーログから有病率データが利用できる可能性があることに注意しました。これらのエンティティは、特定のトランスポート機能をいつ使用しようとするかを知ることができます失敗し、使用の副作用としてネットワークを測定する機会が提供されました。多くのクライアントには、これらのバグレポートを開発者に送信する機能がすでにあります。これらは、ミドルボックスでいっぱいのインターネットでのプロトコルエンジニアリングに関する議論と決定にデータを結び付ける機会を提供します。
The HOPS (How Ossified is the Protocol Stack) informal birds of a feather session ("Bar BoF") was held at the IETF 92 meeting in Dallas, to discuss approaches to get aggregated data from these logs about potential middlebox impairment, focusing on common data formats and issues of preserving end-user privacy. While some discussion focused on aggregating impairment observations at the network level, initial work will focus on making relative prevalence information available on an Internet-wide scope. The first activity identified has been to match the types of data required to answer questions relevant to protocol engineering to the data that currently is or can easily be collected.
HOPS（プロトコルスタックがどのように骨化されるか）の非公式の鳥の羽セッション（ "Bar BoF"）がダラスで開催されたIETF 92ミーティングで開催され、ミドルボックスの潜在的な障害に関するこれらのログから集計データを取得する方法について議論し、共通のデータ形式とエンドユーザーのプライバシー保護の問題。一部の議論は、ネットワークレベルでの減損観察の集約に焦点を当てていましたが、最初の作業は、インターネット全体の範囲で利用可能な相対的有病率情報を作成することに焦点を当てます。特定された最初のアクティビティは、プロトコルエンジニアリングに関連する質問に回答するために必要なデータのタイプを、現在収集されている、または簡単に収集できるデータに一致させることです。
A mailing list (hops@ietf.org) has been established to continue discussion.
議論を続けるためにメーリングリスト（hops@ietf.org）が設立されました。
The workshop identified the potential to update [RFC3234] to provide guidelines on middlebox design, implementation, and deployment in order to reduce inadvertent or accidental impact on stack ossification in existing and new middlebox designs. The IAB Stack Evolution Program will follow up on this with the participants in the now-closed BEHAVE working group, as it most closely follows the work of that group. It will draw in part on the work of the BEHAVE working group, and on experience with STUN, TURN, and ICE, all of which focus more specifically on network address translation.
ワークショップは、既存および新規のミドルボックス設計におけるスタックの骨化への不注意または偶発的な影響を減らすために、ミドルボックスの設計、実装、および導入に関するガイドラインを提供するために[RFC3234]を更新する可能性を特定しました。 IAB Stack Evolution Programは、現在終了しているBEHAVEワーキンググループの参加者をフォローします。BEHAVEワーキンググループは、そのグループの作業に最も密接に従うためです。 BEHAVEワーキンググループの作業、およびSTUN、TURN、ICEの経験を部分的に利用して、ネットワークアドレス変換に特に重点を置いています。
The workshop identified the need for architectural guidance in general for transport stack evolution: tradeoffs between user- and kernel-space implementations, tradeoffs in and considerations for encapsulations (especially UDP), tradeoffs in implicit versus explicit interaction with devices along the path, and so on. This document will be produced by the IAB IP Stack Evolution Program; the new transport encapsulations document [EXP-COOP] may evolve into the basis for this work.
ワークショップでは、トランスポートスタックの進化に関する一般的なアーキテクチャガイダンスの必要性を確認しました。ユーザー空間実装とカーネル空間実装のトレードオフ、カプセル化（特にUDP）のトレードオフと考慮事項、パスに沿ったデバイスとの暗黙的相互作用と明示的相互作用のトレードオフなどオン。このドキュメントは、IAB IP Stack Evolution Programによって作成されます。新しいトランスポートカプセル化ドキュメント[EXP-COOP]は、この作業の基礎に発展する可能性があります。
Further, due to the underlying discuss on trust and a needed "balance of power" between the end hosts and the network, the workshop participants concluded that it is necessary to define approaches based on the cryptographic protocol to enable transport protocol extensibility.
さらに、エンドホストとネットワーク間の信頼と必要な「パワーのバランス」に関する根本的な議論により、ワークショップの参加者は、トランスポートプロトコルの拡張性を可能にする暗号プロトコルに基づくアプローチを定義する必要があると結論付けました。
The workshop identified the need to socialize ideas connected to transport stack evolution within the IETF community, including presentations in the transport and applications open area meetings on protocol extensibility, UDP encapsulation considerations, and the application of TLS/DTLS in order to prevent middlebox meddling. Much of the energy coming out of the workshop went into the SPUD BoF (see Section 6.1), so these presentations will be given at future meetings.
ワークショップでは、ミドルボックスの干渉を防ぐために、プロトコルの拡張性、UDPカプセル化の考慮事項、およびTLS / DTLSの適用に関するトランスポートおよびアプリケーションオープンエリアミーティングでのプレゼンテーションを含む、IETFコミュニティ内のトランスポートスタックの進化に関連するアイデアを社会化する必要性を確認しました。ワークショップから出るエネルギーの多くはSPUD BoF（セクション6.1を参照）に費やされたため、これらのプレゼンテーションは今後の会議で行われます。
There are also clear interactions between the future work following the SEMI workshop and the IAB's Privacy and Security Program; Privacy and Security program members will be encouraged to follow developments in transport stack evolution to help especially with privacy implications of the outcomes of the workshop.
また、SEMIワークショップに続く将来の作業とIABのプライバシーおよびセキュリティプログラムの間には明確な相互作用があります。プライバシーおよびセキュリティプログラムのメンバーは、ワークショップの結果のプライバシーへの影響を特に支援するために、トランスポートスタックの進化の進展をフォローすることが推奨されます。
Bob Briscoe informally liaised the SEMI workshop discussions to the ETSI Network Function Virtualization (NFV) Industry Specification Group (ISG) following the workshop, focusing as well on the implications of end-to-end encryption on the present and future of in-network functionality. In the ISG's Security Working Group, he proposed text for best practices on middlebox access to data in the presence of end-to-end encryption.
Bob Briscoeは、SEMIワークショップの議論を非公式にETSIネットワーク機能仮想化（NFV）業界仕様グループ（ISG）に連絡し、ワークショップに続いて、ネットワーク内機能の現在と将来におけるエンドツーエンド暗号化の影響にも焦点を当てました。 ISGのセキュリティワーキンググループでは、エンドツーエンドの暗号化が存在する場合のデータへのミドルボックスアクセスに関するベストプラクティスのテキストを提案しました。
This document presents no security considerations.
このドキュメントでは、セキュリティに関する考慮事項はありません。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <http://www.rfc-editor.org/info/rfc3234>.
[RFC3234]カーペンター、B。およびS.ブリム、「ミドルボックス：分類と問題」、RFC 3234、DOI 10.17487 / RFC3234、2002年2月、<http://www.rfc-editor.org/info/rfc3234>。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <http://www.rfc-editor.org/info/rfc5218>.
[RFC5218] Thaler、D。、およびB. Aboba、「成功するプロトコルを作るもの」、RFC 5218、DOI 10.17487 / RFC5218、2008年7月、<http://www.rfc-editor.org/info/rfc5218> 。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555] Wing、D.、A。Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、DOI 10.17487 / RFC6555、2012年4月、<http://www.rfc-editor.org/info/ rfc6555>。
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, <http://www.rfc-editor.org/info/rfc7305>.
[RFC7305] Lear、E.、Ed。、「インターネットテクノロジーの採用と移行（ITAT）に関するIABワークショップからの報告」、RFC 7305、DOI 10.17487 / RFC7305、2014年7月、<http：//www.rfc-editor。 org / info / rfc7305>。
[SPUD-USE] Hardie, T., "Use Cases for SPUD", Work in Progress, draft-hardie-spud-use-cases-01, February 2015.
[SPUD-USE] Hardie、T。、「SPUDの使用例」、作業中、draft-hardie-spud-use-cases-01、2015年2月。
[SPUD-PROTO] Hildebrand, J. and B. Trammell, "Substrate Protocol for User Datagrams (SPUD) Prototype", Work in Progress, draft-hildebrand-spud-prototype-03, March 2015.
[SPUD-PROTO] Hildebrand、J。およびB. Trammell、「Substrate Protocol for User Datagrams（SPUD）Prototype」、Work in Progress、draft-hildebrand-spud-prototype-03、2015年3月。
[TLS-DTLS] Huitema, C., Rescorla, E., and J. Jana, "DTLS as Subtransport protocol", Work in Progress, draft-huitema-tls-dtls-as-subtransport-00, March 2015.
[TLS-DTLS] Huitema、C.、Rescorla、E.、J。Jana、「DTLS as Subtransport protocol」、Work in Progress、draft-huitema-tls-dtls-as-subtransport-00、2015年3月。
[EXP-COOP] Trammell, B., Ed., "Architectural Considerations for Transport Evolution with Explicit Path Cooperation", Work in Progress, draft-trammell-stackevo-explicit-coop-00, September 2015.
[EXP-COOP] Trammell、B。、編、「明示的なパス協調によるトランスポートの進化に関するアーキテクチャの考慮事項」、進行中の作業、draft-trammell-stackevo-explicit-coop-00、2015年9月。
[black-semi] Black, D., "UDP Encapsulation: Framework Considerations", January 2015, <https://www.iab.org/wp-content/ IAB-uploads/2014/12/semi2015_black.pdf>.
[black-semi] Black、D。、「UDPカプセル化：フレームワークの考慮事項」、2015年1月、<https://www.iab.org/wp-content/ IAB-uploads / 2014/12 / semi2015_black.pdf>。
[briscoe-semi] Briscoe, B., "Tunneling Through Inner Space", October 2014, <https://www.iab.org/wp-content/IAB-uploads/2014/12/ semi2015_briscoe.pdf>.
[briscoe-semi] Briscoe、B。、「Tunneling Through Inner Space」、2014年10月、<https://www.iab.org/wp-content/IAB-uploads/2014/12/ semi2015_briscoe.pdf>。
[cheshire-semi] Cheshire, S., "Restoring the Reputation of the Much-Maligned TCP", January 2015, <https://www.iab.org/ wp-content/IAB-uploads/2015/01/semi2015-cheshire.pdf>.
[cheshire-semi] Cheshire、S。、「Restoring the Reputation of the Reputation of the Much-Maligned TCP」、2015年1月、<https://www.iab.org/ wp-content / IAB-uploads / 2015/01 / semi2015- cheshire.pdf>。
[deering-plenary] Deering, S., "Watching the Waist of the Protocol Hourglass", August 2001, <https://www.ietf.org/proceedings/51/slides/plenary-1>.
[deering-plenary] Deering、S。、「Watching the Waist of the Protocol Hourglass」、2001年8月、<https://www.ietf.org/proceedings/51/slides/plenary-1>。
[edeline-semi] Edeline, K. and B. Donnet, "On a Middlebox Classification", January 2015, <https://www.iab.org/ wp-content/IAB-uploads/2014/12/semi2015_edeline.pdf>.
[edeline-semi] Edeline、K。およびB. Donnet、「On a Middlebox Classification」、2015年1月、<https://www.iab.org/ wp-content / IAB-uploads / 2014/12 / semi2015_edeline.pdf >。
[hardie-semi] Hardie, T., "Network Function Virtualization and Path Character", January 2015, <https://www.iab.org/wp-content/ IAB-uploads/2014/12/semi2015_hardie.pdf>.
[hardie-semi] Hardie、T。、「ネットワーク機能の仮想化とパス文字」、2015年1月、<https://www.iab.org/wp-content/ IAB-uploads / 2014/12 / semi2015_hardie.pdf>。
[huitema-semi] Huitema, C., "The Secure Transport Tussle", October 2014, <https://www.iab.org/wp-content/IAB-uploads/2014/12/ semi2015_huitema.pdf>.
[huitema-semi] Huitema、C。、「The Secure Transport Tussle」、2014年10月、<https://www.iab.org/wp-content/IAB-uploads/2014/12/ semi2015_huitema.pdf>。
[raiciu-semi] Raiciu, C., Olteanu, V., and , "Good Cop, Bad Cop: Forcing Middleboxes to Cooperate", January 2015, <https://www.iab.org/wp-content/IAB-uploads/2015/01/ ninja.pdf>.
[raiciu-semi] Raiciu、C.、Olteanu、V。、および「Good Cop、Bad Cop：Forced Middleboxes to Cooperate」、2015年1月、<https://www.iab.org/wp-content/IAB- uploads / 2015/01 / ninja.pdf>。
[welzl-semi] Welzl, M., Fairhurst, G., and D. Ros, "Ossification: a result of not even trying?", January 2015, <https://www.iab.org/wp-content/IAB-uploads/2014/12/ semi2015_welzl.pdf>.
[welzl-semi] Welzl、M.、Fairhurst、G。、およびD. Ros、「骨化：試みさえしなかった結果？」、2015年1月、<https://www.iab.org/wp-content/ IAB-uploads / 2014/12 / semi2015_welzl.pdf>。
The following people attended the SEMI workshop:
以下の人々がSEMIワークショップに参加しました：
Mary Barnes, Richard Barnes, David Black, Marc Blanchet, Bob Briscoe, Ken Calvert, Spencer Dawkins, Benoit Donnet, Lars Eggert, Gorry Fairhurst, Aaron Falk, Mat Ford, Ted Hardie, Joe Hildebrand, Russ Housley, Felipe Huici, Christian Huitema, Jana Iyengar, Mirja Kuehlewind, Eliot Lear, Barry Leiba, Xing Li, Szilveszter Nadas, Erik Nordmark, Colin Perkins, Bernhard Plattner, Miroslav Ponec, Costin Raiciu, Philipp Schmidt, Martin Stiemerling, Dave Thaler, Brian Trammell, Michael Welzl, Brandon Williams, Dan Wing, and Aaron Yi Ding.
メアリーバーンズ、リチャードバーンズ、デビッドブラック、マークブランシェ、ボブブリスコー、ケンカルバート、スペンサードーキンス、ブノワドネット、ラースエガート、ゴリーフェアハースト、アーロンフォーク、マットフォード、テッドハーディ、ジョーヒルデブランド、ラスハウズリー、フェリペヒューチ、クリスチャンウイテマ、Jana Iyengar、Mirja Kuehlewind、Eliot Lear、Barry Leiba、Xing Li、Silvezter Nadas、Erik Nordmark、Colin Perkins、Bernhard Plattner、Miroslav Ponec、Costin Raiciu、Philipp Schmidt、Martin Stiemerling、Dave Thaler、Brian Tram、Brian Trammウィリアムズ、ダンウィング、アーロンイーディン。
Additionally, Stuart Cheshire and Eric Rescorla contributed to the workshop but were unable to attend.
さらに、スチュアートチェシャーとエリックレスコーラはワークショップに参加しましたが、参加できませんでした。
Acknowledgments
謝辞
The IAB thanks the SEMI Program Committee: Brian Trammell, Mirja Kuehlewind, Joe Hildebrand, Eliot Lear, Mat Ford, Gorry Fairhurst, and Martin Stiemerling. We additionally thank Prof. Dr. Bernhard Plattner of the Communication Systems Group at ETH for hosting the workshop, and the Internet Society for its support. Thanks to Suzanne Woolf and Aaron Falk for the feedback and review.
IABは、SEMIプログラム委員会に感謝します。ブライアントラメル、ミルハキュールウィンド、ジョーヒルデブランド、エリオットリア、マットフォード、ゴーリーフェアハースト、マーティンスティーマーリング。さらに、ワークショップを主催していただいたETHの通信システムグループのBernhard Plattner博士、およびInternet Societyのサポートに感謝します。フィードバックとレビューを提供してくれたSuzanne WoolfとAaron Falkに感謝します。
Authors' Addresses
著者のアドレス
Brian Trammell (editor) ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメル（編集者）ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス
Email: ietf@trammell.ch
Mirja Kuehlewind (editor) ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
Mirja Kuehlewind（編集者）ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス
Email: mirja.kuehlewind@tik.ee.ethz.ch