Internet Architecture Board (IAB)                       B. Trammell, Ed.
Request for Comments: 7663                            M. Kuehlewind, Ed.
Category: Informational                                       ETH Zurich
ISSN: 2070-1721                                             October 2015
        
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)

来自IAB关于中间盒互联网(SEMI)中堆栈演化研讨会的报告

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.

互联网体系结构委员会(IAB)通过其IP堆栈演进计划、互联网协会和苏黎世瑞士联邦理工学院(ETH)在中间盒互联网(SEMI)中主持了堆栈演进2015年1月26日至27日在苏黎世举办的研讨会,旨在探索在存在与中间盒和界面相关的堆栈骨化的情况下发展传输层的能力。研讨会的目标是为打破僵局的未来工作提供架构和工程指导,重点关注增量部署方法,明确鼓励在端点(在新的传输层和应用程序中)以及中间盒(由网络运营商运行)上部署。本文件总结了对研讨会的贡献,概述了研讨会上的讨论,以及研讨会确定的成果和下一步行动。本报告中记录的观点和立场是研讨会参与者的观点和立场,不一定反映IAB的观点和立场。

Status of This Memo

关于下段备忘

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

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

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.

版权所有(c)2015 IETF信托基金和确定为文件作者的人员。版权所有。

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
        
   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
        
1. Introduction
1. 介绍

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的这一长期规划职能是对互联网工程任务组(IETF)工作组在互联网工程指导小组(IESG)和地区理事会领导下进行的工程工作的补充。

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.

半研讨会部分源于IAB对互联网发展和互联网协议采用的长期兴趣,包括互联网技术采用和过渡研讨会[RFC7305],“协议成功的原因”[RFC5218],以及2001年在IETF 51上迪林的全体会议[Deering Conference]。

1.1. Organization of This Report
1.1. 本报告的组织

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/.

本研讨会报告按主题总结了研讨会的贡献和讨论。我们首先总结了关于堆栈骨化的现状,并探讨了促使堆栈骨化的激励因素以及激励因素在进化中的作用。许多贡献大致分为两个领域:中间箱测量、分类和防止数据包中间箱修改的方法;以及支持运输发展的方法。所有接受的立场文件和详细的讨论记录可在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节讨论了研讨会的成果,包括截至本报告发布之时,研讨会后针对每个已确定的工作项目所取得的进展。

2. The Situation in Review
2. 检讨中的情况

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

SEMI作为IP协议栈演进的一般方案,远不是第一次尝试解决端到端模型中由于中间盒干扰而引起的问题。就在IETF、MIDCOM、NSIS和

BEHAVE efforts have addressed this problem, and the TRAM working group is updating the NAT traversal outcomes of MIDCOM to reflect current reality.

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中也有新的能量,需要传输层的灵活性(我们不确定是否有)(例如WebRTC)以及传输接口的灵活性(TAPS)。

3. Incentives for Stack Ossification and Evolution
3. 堆栈骨化和进化的诱因

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,

Dave Thaler指出,[RFC5218]事实上,运营商、应用程序开发人员、设备供应商、企业和私人用户等需要变革的每个组织的显著正净值最有利于推动新协议的部署。网络上的所有争斗都源于在自由市场中不可避免的相互冲突的激励。对于上层协议,激励措施倾向于支持在任何地方工作的协议,使用最有效的工作机制,并且从实现、维护和管理的角度来看尽可能简单。对于低层协议,

incentives tend toward ignoring and or disabling optional features, as there is a positive feedback cycle between being rarely used and rarely implemented.

激励倾向于忽略或禁用可选功能,因为在很少使用和很少实现之间存在一个积极的反馈周期。

4. The Role and Rule of Middleboxes
4. 中间商的作用和规则

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].

中间包在Internet中很常见,限制了部署新协议和协议扩展的能力。根据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]表示,中间包让互联网变得不可预测,导致效率和可达性之间的权衡。虽然与中间商进行建设性合作以在网络和端点之间建立明确的契约可能是解决这一挑战的一种方法,但在合作较少的环境中执行契约可能需要大量的隧道。Raiciu对“忍者隧道”的贡献说明了这样一种方法。

5. Evolving the Transport Layer
5. 发展传输层

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.

研讨会期间关于演进的讨论大致分为两部分:一是致力于修复TCP扩展的可部署性(在讨论中称为“TCP解放阵线”),二是致力于构建新的基于封装的机制,以允许部署全新的协议(在讨论中称为“UDP人民阵线”). DavidBlack[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提出了内部空间[Briscoe semi]。这里,一般的原则是在X+1层内扩展X层的头;在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工作组实现了将应用程序与传输协议分离的第一步,从而在传输层实现了所需的灵活性。

6. Outcomes
6. 结果

The SEMI workshop identified several areas for further work, outlined below.

半研讨会确定了以下几个需要进一步开展工作的领域。

6.1. Minimal Signaling for Encapsulated Transports
6.1. 封装传输的最小信号

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会议上提出一个BoF会议,该会议将不成立一个工作组SPUD(用户数据报基板协议)。关于用例[SPUD-use]的文件、UDP上shim协议的原型规范[SPUD-PROTO]以及将DTL用作子传输层[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]描述。

6.2. Middlebox Measurement
6.2. 中间箱测量

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

关于中间包造成的损害的讨论很快发现,需要获得更多更好的数据,了解某些类型的损害在网络中的流行程度。例如,如果某些类型的损伤相对较少,那么将这些损伤的复杂解决方案设计成传输协议就没有多大意义。对于某些类型的损害有专门的测量研究,但研讨会指出,流行率数据可能来自客户端和服务器上TCP堆栈和应用程序的错误日志:这些实体能够知道使用特定传输功能的尝试何时失败,提供一个测量网络的机会,作为使用网络的副作用。许多客户端已经有了发送数据的功能

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.

这些bug会向开发人员报告。在一个充斥着中间包的互联网上,这些都提供了将数据用于协议工程讨论和决策的机会。

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.

在达拉斯举行的IETF 92会议上,举行了HOPS(协议栈有多僵化)非正式的羽毛鸟会议(“Bar BoF”),以讨论从这些日志中获取有关潜在中间箱损害的聚合数据的方法,重点是常见数据格式和保护最终用户隐私的问题。虽然一些讨论侧重于在网络层面汇总损伤观察结果,但初步工作将侧重于在互联网范围内提供相对患病率信息。确定的第一项活动是将回答协议工程相关问题所需的数据类型与当前正在收集或可以轻松收集的数据相匹配。

A mailing list (hops@ietf.org) has been established to continue discussion.

邮寄名单(hops@ietf.org)已建立以继续讨论。

6.3. Guidelines for Middlebox Design and Deployment
6.3. 中间盒设计和部署指南

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计划将与现已关闭的BEHAVE工作组的参与者一起跟进这一点,因为它最密切地关注该工作组的工作。它将部分借鉴BEHAVE工作组的工作,以及STUN、TURN和ICE的经验,所有这些都更具体地关注网络地址转换。

6.4. Architectural Guidelines for Transport Stack Evolution
6.4. 传输堆栈演进的体系结构指南

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堆栈演进计划编制;新的运输封装文件[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.

此外,由于对信任的基本讨论以及终端主机和网络之间所需的“权力平衡”,研讨会参与者得出结论,有必要定义基于加密协议的方法,以实现传输协议的可扩展性。

6.5. Additional Activities in the IETF and IAB
6.5. IETF和IAB中的其他活动

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.

研讨会确定了在IETF社区内将与传输堆栈演进相关的想法社会化的必要性,包括在传输和应用开放区域会议上就协议扩展性、UDP封装注意事项和TLS/DTL的应用进行演讲,以防止中间箱干预。研讨会产生的大部分能量用于SPUD转炉(见第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.

半研讨会后的未来工作与IAB的隐私和安全计划之间也存在明确的互动关系;隐私和安全计划成员将被鼓励关注传输堆栈演变的发展,特别是研讨会成果对隐私的影响。

6.6. Additional Activities in Other Venues
6.6. 其他场地的额外活动

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与ETSI网络功能虚拟化(NFV)行业规范小组(ISG)非正式地联系了半研讨会讨论,重点讨论了端到端加密对当前和未来网络功能的影响。在ISG的安全工作组中,他提出了在端到端加密的情况下对数据进行中间盒访问的最佳实践文本。

7. Security Considerations
7. 安全考虑

This document presents no security considerations.

本文件未提出任何安全注意事项。

8. Informative References
8. 资料性引用

[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]Carpenter,B.和S.Brim,“中间盒:分类和问题”,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,“数据报传输层安全版本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,“快乐眼球:双堆栈主机的成功”,RFC 6555,DOI 10.17487/RFC65552012年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]李尔,E.,编辑,“IAB互联网技术采用和转型研讨会(ITAT)的报告”,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的用例”,正在进行的工作,草稿-Hardie-SPUD-USE-Cases-012015年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,“用户数据报的基板协议(SPUD)原型”,正在进行的工作,草稿-Hildebrand-SPUD-Prototype-032015年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作为子传输协议”,正在进行的工作,草稿-Huitema-TLS-DTLS-as-Subtransport-0015年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.,Ed.,“具有明确路径合作的交通发展的建筑考虑”,正在进行的工作,草稿-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上传/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.,“穿越内部空间的隧道”,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.,“恢复备受诟病的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全体会议]deering,S.,“观察议定书沙漏的腰部”,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,“关于中间箱分类”,2015年1月<https://www.iab.org/ wp content/IAB uploads/2014/12/semi2015\u 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上传/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.,“安全运输之争”,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.,和“好警察,坏警察:迫使中间商合作”,2015年1月<https://www.iab.org/wp-content/IAB-uploads/2015/01/ 忍者.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\u welzl.pdf>。

Appendix A. Attendees
附录A.与会者

The following people attended the SEMI workshop:

以下人员参加了半研讨会:

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.

玛丽·巴恩斯、理查德·巴恩斯、大卫·布莱克、马克·布兰切特、鲍勃·布里斯科、肯·卡尔弗特、斯宾塞·道金斯、贝诺特·唐奈、拉尔斯·艾格特、戈里·费尔赫斯特、亚伦·福克、马特·福特、特德·哈迪、乔·希尔德布兰德、罗斯·霍斯利、费利佩·惠西、克里斯蒂安·惠特马、雅娜·艾扬格、米莉亚·库勒温德、艾略特·李尔、巴里·莱巴、邢莉、斯维斯特·纳达斯、埃里克·诺德马克、,科林·帕金斯、伯恩哈德·普拉特纳、米罗斯拉夫·波内克、科斯汀·雷丘、菲利普·施密特、马丁·斯蒂梅林、戴夫·泰勒、布赖恩·特拉梅尔、迈克尔·韦尔兹尔、布兰登·威廉姆斯、丹·荣和亚伦·伊丁。

Additionally, Stuart Cheshire and Eric Rescorla contributed to the workshop but were unable to attend.

此外,Stuart Cheshire和Eric Rescorla为研讨会做出了贡献,但未能出席。

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感谢半项目委员会:Brian Trammell、Mirja Kuehlewind、Joe Hildebrand、Eliot Lear、Mat Ford、Gorry Fairhurst和Martin Stiemerling。我们还感谢ETH通信系统组的Bernhard Plattner教授主持研讨会,并感谢互联网协会的支持。感谢Suzanne Woolf和Aaron Falk的反馈和评论。

Authors' Addresses

作者地址

Brian Trammell (editor) ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland

布莱恩·特拉梅尔(编辑)ETH苏黎世Gloriastrasse 35 8092苏黎世瑞士

   Email: ietf@trammell.ch
        
   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
        
   Email: mirja.kuehlewind@tik.ee.ethz.ch