Network Working Group P. Srisuresh
Request for Comments: 3303 Kuokoa Networks
Category: Informational J. Kuthan
Fraunhofer Institute FOKUS
J. Rosenberg
dynamicsoft
A. Molitor
Aravox Technologies
A. Rayhan
Ryerson University
August 2002
Network Working Group P. Srisuresh
Request for Comments: 3303 Kuokoa Networks
Category: Informational J. Kuthan
Fraunhofer Institute FOKUS
J. Rosenberg
dynamicsoft
A. Molitor
Aravox Technologies
A. Rayhan
Ryerson University
August 2002
Middlebox communication architecture and framework
中间盒通信体系结构和框架
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group.
本文档的一个主要目标是描述middlebox communications（MIDCOM）的底层框架，以便使用可信的第三方无缝地通过middlebox实现复杂的应用程序。本文件和关于MIDCOM要求的配套文件（[REQMTS]）已作为重新编制MIDCOM工作组文件的前提而创建。
There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP and H.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic.
当今互联网上有各种各样的中间设备，它们的操作需要应用程序智能。与实时流应用程序（如SIP和H.323）以及对等应用程序（如Napster和NetMeeting）相关的数据报不能仅通过检查数据包头来识别。实现防火墙和网络地址转换器服务的中间盒通常在设备中嵌入应用程序智能，以进行操作。该文件规定了一种体系结构和框架，在这种体系结构和框架中，可委托受信任的第三方协助中间盒执行其操作，而无需借助嵌入应用程序智能。这样做将允许中间包继续提供服务，同时保持中间包应用程序的不可知性。
Intermediate devices requiring application intelligence are the subject of this document. These devices are referred to as middleboxes throughout the document. Many of these devices enforce application specific policy based functions such as packet filtering, VPN (Virtual Private Network) tunneling, Intrusion detection, security and so forth. Network Address Translator service, on the other hand, provides routing transparency across address realms (within IPv4 routing network or across V4 and V6 routing realms), independent of applications. Application Level Gateways (ALGs) are used in conjunction with NAT to examine and optionally modify application payload so the end-to-end application behavior remains unchanged for many of the applications traversing NAT middleboxes. There may be other types of services requiring embedding application intelligence in middleboxes for their operation. The discussion scope of this document is however limited to Firewall and NAT services. Nonetheless, the MIDCOM framework is designed to be extensible to support the deployment of new services.
需要应用智能的中间设备是本文件的主题。在整个文档中，这些设备称为中间箱。这些设备中的许多实施了基于应用程序特定策略的功能，如包过滤、VPN（虚拟专用网络）隧道、入侵检测、安全等。另一方面，网络地址转换器服务提供跨地址域的路由透明性（在IPv4路由网络内或跨V4和V6路由域），独立于应用程序。应用程序级网关（ALG）与NAT结合使用，以检查并可选地修改应用程序负载，因此对于许多通过NAT中间盒的应用程序，端到端应用程序行为保持不变。可能还有其他类型的服务需要在中间盒中嵌入应用程序智能以进行操作。然而，本文档的讨论范围仅限于防火墙和NAT服务。尽管如此，MIDCOM框架设计为可扩展，以支持新服务的部署。
Tight coupling of application intelligence with middleboxes makes maintenance of middleboxes hard with the advent of new applications. Built-in application awareness typically requires updates of operating systems with new applications or newer versions of existing applications. Operators requiring support for newer applications will not be able to use third party software/hardware specific to the application and are at the mercy of their middlebox vendor to make the necessary upgrade. Further, embedding intelligence for a large number of application protocols within the same middlebox increases complexity of the middlebox and is likely to be error prone and degrade in performance.
随着新应用程序的出现，应用程序智能与中间盒的紧密耦合使得中间盒的维护变得困难。内置应用程序感知通常需要使用新应用程序或现有应用程序的更新版本更新操作系统。需要支持较新应用程序的运营商将无法使用特定于该应用程序的第三方软件/硬件，并由其中间包供应商进行必要的升级。此外，将大量应用程序协议的智能嵌入到同一个中间盒中会增加中间盒的复杂性，并且可能容易出错并降低性能。
This document describes a framework in which application intelligence can be moved from middleboxes into external MIDCOM agents. The premise of the framework is to devise a MIDCOM protocol that is application independent, so the middleboxes can stay focused on services such as firewall and NAT. The framework document includes some explicit and implied requirements for the MIDCOM protocol. However, it must be noted that these requirements are only a subset. A separate requirements document lists the requirements in detail.
本文档描述了一个框架，在该框架中，应用程序智能可以从中间盒移动到外部MIDCOM代理。该框架的前提是设计一个独立于应用程序的MIDCOM协议，这样中间件就可以专注于防火墙和NAT等服务。该框架文件包括对MIDCOM协议的一些明确和隐含的要求。然而，必须注意的是，这些要求只是一个子集。单独的需求文件详细列出了需求。
MIDCOM agents with application intelligence can assist the middleboxes through the MIDCOM protocol in permitting applications such as FTP, SIP and H.323. The communication between a MIDCOM agent and a middlebox will not be noticeable to the end-hosts that take part in the application, unless one of the end-hosts assumes the role of a MIDCOM agent. Discovery of middleboxes or MIDCOM agents in the
具有应用程序智能的MIDCOM代理可以通过MIDCOM协议协助中间件允许FTP、SIP和H.323等应用程序。参与应用程序的终端主机不会注意到MIDCOM代理和中间盒之间的通信，除非其中一个终端主机承担MIDCOM代理的角色。在中发现中间包或MIDCOM代理
path of an application instance is outside the scope of this document. Further, any communication amongst middleboxes is also outside the scope of this document.
应用程序实例的路径超出了本文档的范围。此外，中间盒之间的任何通信也不在本文件范围内。
This document describes the framework in which middlebox communication takes place and the various elements that constitute the framework. Section 2 describes the terms used in the document. Section 3 defines the architectural framework of a middlebox for communication with MIDCOM agents. The remaining sections cover the components of the framework, illustration using sample flows, and operational considerations with the MIDCOM architecture. Section 4 describes the nature of MIDCOM protocol. Section 5 identifies entities that could potentially host the MIDCOM agent function. Section 6 considers the role of Policy server and its function with regard to communicating MIDCOM agent authorization policies. Section 7 is an illustration of SIP flows using a MIDCOM framework in which the MIDCOM agent is co-resident on a SIP proxy server. Section 8 addresses operational considerations in deploying a protocol adhering to the framework described here. Section 9 is an applicability statement, scoping the location of middleboxes. Section 11 outlines security considerations for the middlebox in view of the MIDCOM framework.
本文档描述了进行中间包通信的框架以及构成该框架的各种元素。第2节描述了文件中使用的术语。第3节定义了用于与MIDCOM代理通信的中间盒的体系结构框架。其余部分将介绍框架的组件、使用示例流的说明以及MIDCOM体系结构的操作注意事项。第4节描述了MIDCOM协议的性质。第5节确定了可能承载MIDCOM代理功能的实体。第6节讨论了策略服务器的角色及其在通信MIDCOM代理授权策略方面的功能。第7节说明了使用MIDCOM框架的SIP流，其中MIDCOM代理共同驻留在SIP代理服务器上。第8节讨论了部署遵循此处所述框架的协议时的操作注意事项。第9节是适用性声明，界定了中间盒的位置。第11节从MIDCOM框架的角度概述了中间件的安全注意事项。
Below are the definitions for the terms used throughout the document.
以下是本文件中使用的术语的定义。
A middlebox function or a middlebox service is an operation or method performed by a network intermediary that may require application specific intelligence for its operation. Policy based packet filtering (a.k.a. firewall), Network address translation (NAT), Intrusion detection, Load balancing, Policy based tunneling and IPsec security are all examples of a middlebox function (or service).
中间箱功能或中间箱服务是由网络中介执行的操作或方法，其操作可能需要特定于应用程序的智能。基于策略的数据包过滤（又称防火墙）、网络地址转换（NAT）、入侵检测、负载平衡、基于策略的隧道和IPsec安全都是中间件功能（或服务）的示例。
A Middlebox is a network intermediate device that implements one or more of the middlebox services. A NAT middlebox is a middlebox implementing NAT service. A firewall middlebox is a middlebox implementing firewall service.
中间箱是实现一个或多个中间箱服务的网络中间设备。NAT中间箱是实现NAT服务的中间箱。防火墙中间箱是实现防火墙服务的中间箱。
Traditional middleboxes embed application intelligence within the device to support specific application traversal. Middleboxes supporting the MIDCOM protocol will be able to externalize application intelligence into MIDCOM agents. In reality, some of the
传统的中间盒在设备中嵌入应用程序智能，以支持特定的应用程序遍历。支持MIDCOM协议的中间件将能够将应用程序智能外部化到MIDCOM代理中。事实上，一些
middleboxes may continue to embed application intelligence for certain applications and depend on MIDCOM protocol and MIDCOM agents for the support of remaining applications.
中间件可能会继续为某些应用程序嵌入应用程序智能，并依赖MIDCOM协议和MIDCOM代理来支持其余应用程序。
Firewall is a policy based packet filtering middlebox function, typically used for restricting access to/from specific devices and applications. The policies are often termed Access Control Lists (ACLs).
防火墙是一种基于策略的包过滤中间盒功能，通常用于限制对特定设备和应用程序的访问。这些策略通常称为访问控制列表（ACL）。
Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end-hosts. Transparent routing here refers to modifying end-node addresses en-route and maintaining state for these updates so that when a datagram leaves one realm and enters another, datagrams pertaining to a session are forwarded to the right end-host in either realm. Refer to [NAT-TERM] for the definition of Transparent routing, various NAT types, and the associated terms in use. Two types of NAT are most common. Basic-NAT, where only an IP address (and the related IP, TCP/UDP checksums) of packets is altered and NAPT (Network Address Port Translation), where both an IP address and a transport layer identifier, such as a TCP/UDP port (and the related IP, TCP/UDP checksums), are altered.
网络地址转换是一种将IP地址从一个地址域映射到另一个地址域的方法，提供到终端主机的透明路由。这里的透明路由指的是修改路由中的终端节点地址并维护这些更新的状态，以便当数据报离开一个域进入另一个域时，与会话相关的数据报被转发到任一域中的右端主机。有关透明路由的定义、各种NAT类型以及使用中的相关术语，请参阅[NAT-TERM]。两种NAT最常见。基本NAT，其中仅更改数据包的IP地址（以及相关IP、TCP/UDP校验和），NAPT（网络地址端口转换），其中更改IP地址和传输层标识符，例如TCP/UDP端口（以及相关IP、TCP/UDP校验和）。
The term NAT in this document is very similar to the IPv4 NAT described in [NAT-TERM], but is extended beyond IPv4 networks to include the IPv4-v6 NAT-PT described in [NAT-PT]. While the IPv4 NAT [NAT-TERM] translates one IPv4 address into another IPv4 address to provide routing between private V4 and external V4 address realms, IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address into an IPv6 address, and vice versa, to provide routing between a V6 address realm and an external V4 address realm.
本文档中的术语NAT与[NAT-term]中描述的IPv4 NAT非常相似，但扩展到IPv4网络之外，以包括[NAT-PT]中描述的IPv4-v6 NAT-PT。IPv4 NAT[NAT-TERM]将一个IPv4地址转换为另一个IPv4地址以提供专用V4和外部V4地址域之间的路由，而IPv4-v6 NAT-PT[NAT-PT]将IPv4地址转换为IPv6地址，反之亦然，以提供v6地址域和外部V4地址域之间的路由。
Unless specified otherwise, NAT in this document is a middlebox function referring to both IPv4 NAT, as well as IPv4-v6 NAT-PT.
除非另有规定，否则本文档中的NAT是一个指IPv4 NAT和IPv4-v6 NAT-PT的中间盒函数。
A proxy is an intermediate relay agent between clients and servers of an application, relaying application messages between the two. Proxies use special protocol mechanisms to communicate with proxy clients and relay client data to servers and vice versa. A Proxy terminates sessions with both the client and the server, acting as server to the end-host client and as client to the end-host server.
代理是应用程序的客户端和服务器之间的中间中继代理，在两者之间中继应用程序消息。代理使用特殊的协议机制与代理客户端通信，并将客户端数据中继到服务器，反之亦然。代理终止与客户端和服务器的会话，充当终端主机客户端的服务器和终端主机服务器的客户端。
Applications such as FTP, SIP, and RTSP use a control session to establish data sessions. These control and data sessions can take divergent paths. While a proxy can intercept both the control and data sessions, it might intercept only the control session. This is often the case with real-time streaming applications such as SIP and RTSP.
FTP、SIP和RTSP等应用程序使用控制会话来建立数据会话。这些控制和数据会话可以采用不同的路径。虽然代理可以拦截控制会话和数据会话，但它可能只拦截控制会话。实时流媒体应用程序（如SIP和RTSP）通常就是这种情况。
Application Level Gateways (ALGs) are entities that possess the application specific intelligence and knowledge of an associated middlebox function. An ALG examines application traffic in transit and assists the middlebox in carrying out its function.
应用程序级网关（ALG）是具有特定于应用程序的智能和相关中间盒功能知识的实体。ALG检查传输中的应用程序流量，并协助中间箱执行其功能。
An ALG may be a co-resident with a middlebox or reside externally, communicating through a middlebox communication protocol. It interacts with a middlebox to set up state, access control filters, use middlebox state information, modify application specific payload, or perform whatever else is necessary to enable the application to run through the middlebox.
ALG可以是与中间箱的共同驻留者，也可以驻留在外部，通过中间箱通信协议进行通信。它与中间盒交互，以设置状态、访问控制过滤器、使用中间盒状态信息、修改特定于应用程序的有效负载，或执行使应用程序能够在中间盒中运行所需的任何其他操作。
ALGs are different from proxies. ALGs are not visible to end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts. ALGs do not terminate sessions with either end-host. Instead, ALGs examine, and optionally modify, application payload content to facilitate the flow of application traffic through a middlebox. ALGs are middlebox centric, in that they assist the middleboxes in carrying out their function, whereas, the proxies act as a focal point for application servers, relaying traffic between application clients and servers.
ALG不同于代理。ALG对终端主机不可见，与代理不同，代理是中继代理，用于终止与两个终端主机的会话。ALG不会终止与任一终端主机的会话。相反，ALG检查并有选择地修改应用程序有效负载内容，以促进通过中间箱的应用程序流量。ALG是以中间箱为中心的，因为它们帮助中间箱执行其功能，而代理则充当应用程序服务器的焦点，在应用程序客户端和服务器之间传递流量。
ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers.
ALG与代理类似，因为ALG和代理都促进客户端和服务器之间特定于应用程序的通信。
End-hosts are entities that are party to a networked application instance. End-hosts referred to in this document, are specifically those terminating Real-time streaming Voice-over-IP applications, such as SIP and H.323, and peer-to-peer applications such as Napster and NetMeeting.
终端主机是网络应用程序实例的参与方实体。本文档中提到的终端主机，特别是那些终止实时流式IP语音应用程序（如SIP和H.323）和对等应用程序（如Napster和NetMeeting）的主机。
MIDCOM agents are entities performing ALG functions, logically external to a middlebox. MIDCOM agents possess a combination of application awareness and knowledge of the middlebox function. This
MIDCOM代理是执行ALG功能的实体，逻辑上位于中间盒外部。MIDCOM代理具有应用程序意识和对中间盒功能的了解。这
combination enables the agents to facilitate traversal of the middlebox by the application's packets. A MIDCOM agent may interact with one or more middleboxes.
组合使代理能够方便应用程序的数据包遍历中间包。MIDCOM代理可以与一个或多个中间盒交互。
Only "In-Path MIDCOM agents" are considered in this document. In-Path MIDCOM agents are agents which are within the path of those datagrams that the agent needs to examine and/or modify in fulfilling its role as a MIDCOM agent. "Within the path" here simply means that the packets in question flow through the node that hosts the agent. The packets may be addressed to the agent node at the IP layer. Alternatively they may not be addressed to the agent node, but may be constrained by other factors to flow through it. In fact, it is immaterial to the MIDCOM protocol which of these is the case. Some examples of In-Path MIDCOM agents are application proxies, gateways, or even end-hosts that are party to the application.
本文档仅考虑“路径中的MIDCOM代理”。路径中的MIDCOM代理是指代理在履行其作为MIDCOM代理的角色时需要检查和/或修改的数据报路径内的代理。这里的“在路径内”仅仅意味着有问题的数据包流经承载代理的节点。分组可以在IP层被寻址到代理节点。或者，它们可能不会被寻址到代理节点，但可能会受到其他因素的限制而流经代理节点。事实上，对于MIDCOM协议来说，哪种情况是这样是无关紧要的。路径内MIDCOM代理的一些示例包括应用程序代理、网关，甚至是作为应用程序一方的终端主机。
Agents not resident on nodes that are within the path of their relevant application flows are referred to as "Out-of-Path (OOP) MIDCOM agents" and are out of the scope of this document.
不驻留在其相关应用程序流路径内的节点上的代理称为“路径外（OOP）MIDCOM代理”，不在本文档的范围内。
MIDCOM Policy Decision Point (PDP) is primarily a Policy Decision Point(PDP), as defined in [POL-TERM]; and also acts as a policy repository, holding MIDCOM related policy profiles in order to make authorization decisions. [POL-TERM] defines a PDP as "a logical entity that makes policy decisions for itself or for other network elements that request such decisions"; and a policy repository as "a specific data store that holds policy rules, their conditions and actions, and related policy data".
MIDCOM政策决策点（PDP）主要是[POL-TERM]中定义的政策决策点（PDP）；还充当策略存储库，保存与MIDCOM相关的策略配置文件，以便做出授权决策。[POL-TERM]将PDP定义为“为其自身或为请求此类决策的其他网络元素做出决策的逻辑实体”；策略存储库是“保存策略规则、其条件和操作以及相关策略数据的特定数据存储”。
A middlebox and a MIDCOM PDP may communicate further if the MIDCOM PDP's policy changes or if a middlebox needs further information. The MIDCOM PDP may, at anytime, notify the middlebox to terminate authorization for an agent.
如果MIDCOM PDP的策略发生变化，或者如果MIDCOM PDP需要进一步的信息，则中间盒和MIDCOM PDP可以进一步通信。MIDCOM PDP可随时通知中间箱终止对代理的授权。
The protocol facilitating the communication between a middlebox and MIDCOM PDP need not be part of the MIDCOM protocol. Section 6 in the document addresses the MIDCOM PDP interface and protocol framework independent of the MIDCOM framework.
促进中间盒和MIDCOM PDP之间通信的协议不需要是MIDCOM协议的一部分。本文件第6节介绍了独立于MIDCOM框架的MIDCOM PDP接口和协议框架。
Application specific policy data and policy interface between an agent or application endpoint and a MIDCOM PDP is out of bounds for this document. The MIDCOM PDP issues addressed in the document are focused at an aggregate domain level as befitting the middlebox. For example, a SIP MIDCOM agent may choose to query a MIDCOM PDP for the administrative (or corporate) domain to find whether a certain user is allowed to make an outgoing call. This type of application
代理或应用程序终结点与MIDCOM PDP之间的特定于应用程序的策略数据和策略接口不适用于本文档。本文件中所述的MIDCOM PDP问题集中在聚合域级别，适合于中间包。例如，SIP MIDCOM代理可以选择查询管理（或公司）域的MIDCOM PDP，以查找是否允许某个用户进行传出呼叫。这种类型的应用程序
specific policy data, as befitting an end user, is out of bounds for the MIDCOM PDP considered in this document. It is within bounds, however, for the MIDCOM PDP to specify the specific end-user applications (or tuples) for which an agent is permitted to be an ALG.
适合最终用户的特定策略数据不适用于本文档中考虑的MIDCOM PDP。但是，MIDCOM PDP可以指定允许代理作为ALG的特定最终用户应用程序（或元组）。
The protocol between a MIDCOM agent and a middlebox allows the MIDCOM agent to invoke services of the middlebox and allow the middlebox to delegate application specific processing to the MIDCOM agent. The MIDCOM protocol allows the middlebox to perform its operation with the aid of MIDCOM agents, without resorting to embedding application intelligence. The principal motivation behind architecting this protocol is to enable complex applications through middleboxes, seamlessly using a trusted third party, i.e., a MIDCOM agent.
MIDCOM代理和中间箱之间的协议允许MIDCOM代理调用中间箱的服务，并允许中间箱将特定于应用程序的处理委托给MIDCOM代理。MIDCOM协议允许中间件在MIDCOM代理的帮助下执行其操作，而无需借助嵌入应用程序智能。构建此协议背后的主要动机是通过中间箱，无缝地使用可信的第三方，即MIDCOM代理，支持复杂的应用程序。
This is a protocol yet to be devised.
这是一个有待设计的协议。
A MIDCOM agent registration is defined as the process of provisioning agent profile information with the middlebox or a MIDCOM PDP. MIDCOM agent registration is often a manual operation performed by an operator rather than the agent itself.
MIDCOM代理注册定义为向Midbox或MIDCOM PDP提供代理配置文件信息的过程。MIDCOM代理注册通常是由操作员而不是代理本身执行的手动操作。
A MIDCOM agent profile may include agent authorization policy (i.e., session tuples for which the agent is authorized to act as ALG), agent-hosting-entity (e.g., Proxy, Gateway, or end-host which hosts the agent), agent accessibility profile (including any host level authentication information), and security profile (for the messages exchanged between the middlebox and the agent).
MIDCOM代理配置文件可以包括代理授权策略（即，代理被授权充当ALG的会话元组）、代理托管实体（例如，代理、网关或托管代理的终端主机）、代理可访问性配置文件（包括任何主机级认证信息）和安全配置文件（用于中间盒和代理之间交换的消息）。
A MIDCOM session is defined to be a lasting association between a MIDCOM agent and a middlebox. The MIDCOM session is not assumed to imply any specific transport layer protocol. Specifically, this should not be construed as referring to a connection-oriented TCP protocol.
MIDCOM会话定义为MIDCOM代理和中间盒之间的持久关联。假定MIDCOM会话并不意味着任何特定的传输层协议。具体而言，这不应解释为指面向连接的TCP协议。
A filter is packet matching information that identifies a set of packets to be treated a certain way by a middlebox. This definition is consistent with [POL-TERM], which defines a filter as "A set of
过滤器是一种数据包匹配信息，用于标识一组数据包，这些数据包将由中间盒以某种方式进行处理。该定义与[POL-TERM]一致，后者将过滤器定义为“一组
terms and/or criteria used for the purpose of separating or categorizing. This is accomplished via single- or multi-field matching of traffic header and/or payload data".
用于分离或分类的术语和/或标准。这是通过单字段或多字段匹配流量报头和/或有效负载数据来实现的”。
5-Tuple specification of packets in the case of a firewall and 5- tuple specification of a session in the case of a NAT middlebox function are examples of a filter.
防火墙情况下数据包的5元组规范和NAT中间盒功能情况下会话的5元组规范是过滤器的示例。
Policy action (or Action) is a description of the middlebox treatment/service to be applied to a set of packets. This definition is consistent with [POL-TERM], which defines a policy action as "Definition of what is to be done to enforce a policy rule, when the conditions of the rule are met. Policy actions may result in the execution of one or more operations to affect and/or configure network traffic and network resources".
策略操作（或操作）是对要应用于一组数据包的中间包处理/服务的描述。此定义与[POL-TERM]一致，后者将策略操作定义为“当满足规则的条件时，执行策略规则所需的定义。策略操作可能导致执行一个或多个操作，以影响和/或配置网络流量和网络资源”。
NAT Address-BIND (or Port-BIND in the case of NAPT) and firewall permit/deny action are examples of an Action.
NAT地址绑定（或NAPT情况下的端口绑定）和防火墙允许/拒绝操作是操作的示例。
The combination of one or more filters and one or more actions. Packets matching a filter are to be treated as specified by the associated action(s). The Policy rules may also contain auxiliary attributes such as individual rule type, timeout values, creating agent, etc.
一个或多个筛选器与一个或多个操作的组合。与筛选器匹配的数据包将被视为关联操作指定的数据包。策略规则还可以包含辅助属性，例如单个规则类型、超时值、创建代理等。
Policy rules are communicated through the MIDCOM protocol.
策略规则通过MIDCOM协议进行通信。
A middlebox may implement one or more of the middlebox functions selectively on multiple interfaces of the device. There can be a variety of MIDCOM agents interfacing with the middlebox to communicate with one or more of the middlebox functions on an interface. As such, the middlebox communication protocol must allow for selective communication between a specific MIDCOM agent and one or more middlebox functions on the interface. The following diagram identifies a possible layering of the service supported by a middlebox and a list of MIDCOM agents that might interact with it.
中间盒可以在设备的多个接口上选择性地实现一个或多个中间盒功能。可以有多种MIDCOM代理与中间箱接口，以便与接口上的一个或多个中间箱功能进行通信。因此，中间箱通信协议必须允许特定的MIDCOM代理和接口上的一个或多个中间箱功能之间的选择性通信。下图确定了一个中间盒支持的服务的可能分层，以及可能与其交互的MIDCOM代理列表。
+---------------+ +--------------+
| MIDCOM agent | | MIDCOM agent |
| co-resident on| | co-resident |
| Proxy Server | | on Appl. GW |
+---------------+ +--------------+
^ ^
| | +--------+
MIDCOM | | | MIDCOM |
Protocol | | +-| PDP |
| | / +--------+
+-------------+ | | /
| MIDCOM agent| | | /
| co-resident | | | /
| on End-hosts|<-+ | | /
+-------------+ | | | |
v v v v
+-------------------------------------------+
| Middlebox Communication |Policy |
| Protocol (MIDCOM) Interface |Interface |
+----------+--------+-----------+-----------+
Middlebox | | | | |
Functions | Firewall | NAT | VPN | Intrusion |
| | | tunneling | Detection |
+----------+--------+-----------+-----------+
Middlebox | Middlebox function specific policy rule(s)|
Managed | and other attributes |
Resources | |
+-------------------------------------------+
+---------------+ +--------------+
| MIDCOM agent | | MIDCOM agent |
| co-resident on| | co-resident |
| Proxy Server | | on Appl. GW |
+---------------+ +--------------+
^ ^
| | +--------+
MIDCOM | | | MIDCOM |
Protocol | | +-| PDP |
| | / +--------+
+-------------+ | | /
| MIDCOM agent| | | /
| co-resident | | | /
| on End-hosts|<-+ | | /
+-------------+ | | | |
v v v v
+-------------------------------------------+
| Middlebox Communication |Policy |
| Protocol (MIDCOM) Interface |Interface |
+----------+--------+-----------+-----------+
Middlebox | | | | |
Functions | Firewall | NAT | VPN | Intrusion |
| | | tunneling | Detection |
+----------+--------+-----------+-----------+
Middlebox | Middlebox function specific policy rule(s)|
Managed | and other attributes |
Resources | |
+-------------------------------------------+
Figure 1: MIDCOM agents interfacing with a middlebox
图1:MIDCOM代理与中间盒接口
Firewall ACLs, NAT-BINDs, NAT address-maps and Session-state are a few of the middlebox function specific policy rules. A session state may include middlebox function specific attributes, such as timeout values, NAT translation parameters (i.e., NAT-BINDS), and so forth. As Session-state may be shared across middlebox functions, a Session-state may be created by a function, and terminated by a different function. For example, a session-state may be created by the firewall function, but terminated by the NAT function, when a session timer expires.
防火墙ACL、NAT绑定、NAT地址映射和会话状态是一些特定于中间件功能的策略规则。会话状态可以包括特定于中间盒功能的属性，例如超时值、NAT转换参数（即NAT-BINDS）等。由于会话状态可以在中间盒函数之间共享，因此会话状态可以由函数创建，并由不同的函数终止。例如，会话状态可由防火墙功能创建，但在会话计时器过期时由NAT功能终止。
Application specific MIDCOM agents (co-resident on the middlebox or external to the middlebox) would examine the IP datagrams and help identify the application the datagram belongs to, and assist the middlebox in performing functions unique to the application and the middlebox service. For example, a MIDCOM agent, assisting a NAT middlebox, might perform payload translations, whereas a MIDCOM agent
特定于应用程序的MIDCOM代理（共同驻留在中间盒上或中间盒外部）将检查IP数据报，帮助识别数据报所属的应用程序，并帮助中间盒执行应用程序和中间盒服务特有的功能。例如，协助NAT中间箱的MIDCOM代理可以执行有效负载转换，而MIDCOM代理则可以执行有效负载转换
assisting a firewall middlebox might request the firewall to permit access to application specific, dynamically generated, session traffic.
协助防火墙中间包可能会请求防火墙允许访问特定于应用程序的、动态生成的会话流量。
The MIDCOM protocol between a MIDCOM agent and a middlebox allows the MIDCOM agent to invoke services of the middlebox and allow the middlebox to delegate application specific processing to the MIDCOM agent. The protocol will allow MIDCOM agents to signal the middleboxes, to let complex applications using dynamic port based sessions through them (i.e., middleboxes) seamlessly.
MIDCOM代理和中间箱之间的MIDCOM协议允许MIDCOM代理调用中间箱的服务，并允许中间箱将特定于应用程序的处理委托给MIDCOM代理。该协议将允许MIDCOM代理向中间盒发送信号，让使用基于端口的动态会话的复杂应用程序无缝地通过它们（即，中间盒）。
It is important to note that an agent and a middlebox can be on the same physical device. In such a case, they may communicate using a MIDCOM protocol message formats, but using a non-IP based transport, such as IPC messaging (or) they may communicate using well-defined API/DLL (or) the application intelligence is fully embedded into the middlebox service (as it is done today in many stateful inspection firewall devices and NAT devices).
请务必注意，代理和中间盒可以位于同一物理设备上。在这种情况下，它们可以使用MIDCOM协议消息格式进行通信，但可以使用非基于IP的传输，例如IPC消息（或）它们可以使用定义良好的API/DLL进行通信（或）应用程序智能完全嵌入到中间包服务中（就像今天在许多有状态检查防火墙设备和NAT设备中所做的那样）.
The MIDCOM protocol will consist of a session setup phase, run-time session phase, and a session termination phase.
MIDCOM协议将包括会话设置阶段、运行时会话阶段和会话终止阶段。
Session setup must be preceded by registration of the MIDCOM agent with either the middlebox or the MIDCOM PDP. The MIDCOM agent access and authorization profile may either be pre-configured on the middlebox (or) listed on a MIDCOM PDP; the middlebox is configured to consult. MIDCOM shall be a client-server protocol, initiated by the agent.
会话设置之前，必须先向Midbox或MIDCOM PDP注册MIDCOM代理。MIDCOM代理访问和授权配置文件可以在MIDCOM PDP上列出的中间盒（或）上预先配置；中间盒配置为咨询。MIDCOM应为客户端-服务器协议，由代理发起。
A MIDCOM session may be terminated by either of the parties. A MIDCOM session termination may also be triggered by (a) the middlebox or the agent going out of service and not being available for further MIDCOM operations, or (b) the MIDCOM PDP notifying the middlebox that a particular MIDCOM agent is no longer authorized.
任何一方均可终止MIDCOM会话。MIDCOM会话终止也可能由（A）中间箱或代理停止服务且不能用于进一步的MIDCOM操作，或（b）MIDCOM PDP通知中间箱特定的MIDCOM代理不再被授权而触发。
The MIDCOM protocol data exchanged during run-time is governed principally by the middlebox services the protocol supports. Firewall and NAT middlebox services are considered in this document. Nonetheless, the MIDCOM framework is designed to be extensible to support the deployment of other services as well.
在运行时交换的MIDCOM协议数据主要由协议支持的中间盒服务控制。本文档中考虑了防火墙和NAT中间包服务。尽管如此，MIDCOM框架设计为可扩展，以支持其他服务的部署。
MIDCOM agents are logical entities which may reside physically on nodes external to a middlebox, possessing a combination of application awareness and knowledge of middlebox function. A MIDCOM agent may communicate with one or more middleboxes. The issues of middleboxes discovering agents, or vice versa, are outside the scope of this document. The focus of the document is the framework in which a MIDCOM agent communicates with a middlebox using MIDCOM protocol, which is yet to be devised. Specifically, the focus is restricted to just the In-Path agents.
MIDCOM代理是逻辑实体，可以物理上驻留在中间盒外部的节点上，具有应用程序感知和中间盒功能知识的组合。MIDCOM代理可以与一个或多个中间盒通信。中间包发现代理的问题，或反之亦然，不在本文件的范围内。本文档的重点是一个框架，在该框架中，MIDCOM代理使用MIDCOM协议与中间盒进行通信，该协议尚待设计。具体来说，重点仅限于路径内代理。
In-Path MIDCOM agents are MIDCOM agents that are located naturally within the message path of the application(s) they are associated with. Bundled session applications, such as H.323, SIP, and RTSP which have separate control and data sessions, may have their sessions take divergent paths. In those scenarios, In-Path MIDCOM agents are those that find themselves in the control path. In a majority of cases, a middlebox will likely require the assistance of a single agent for an application in the control path alone. However, it is possible that a middlebox function, or a specific application traversing the middlebox might require the intervention of more than a single MIDCOM agent for the same application, one for each sub-session of the application.
路径内MIDCOM代理是自然位于与其关联的应用程序的消息路径内的MIDCOM代理。捆绑会话应用程序，例如具有单独控制和数据会话的H.323、SIP和RTSP，其会话可能采用不同的路径。在这些场景中，路径内MIDCOM代理是那些发现自己处于控制路径中的代理。在大多数情况下，对于控制路径中的应用程序，中间箱可能需要单个代理的协助。但是，一个中间箱功能或一个穿越中间箱的特定应用程序可能需要多个MIDCOM代理对同一应用程序进行干预，每个MIDCOM代理对应用程序的每个子会话进行干预。
Application Proxies and gateways are a good choice for In-Path MIDCOM agents, as these entities by definition, are in the path of an application between a client and server. In addition to hosting the MIDCOM agent function, these natively in-path application specific entities may also enforce application-specific choices locally, such as dropping messages infected with known viruses, or lacking user authentication. These entities can be interjecting both the control and data sessions. For example, FTP control and Data sessions are interjected by an FTP proxy server.
应用程序代理和网关是路径内MIDCOM代理的良好选择，因为根据定义，这些实体位于客户端和服务器之间的应用程序路径中。除了托管MIDCOM代理功能外，这些本机路径中的特定于应用程序的实体还可以在本地强制执行特定于应用程序的选择，例如丢弃感染已知病毒的消息，或者缺少用户身份验证。这些实体可以插入控制会话和数据会话。例如，FTP控制和数据会话由FTP代理服务器中断。
However, proxies may also be interjecting just the control session and not the data sessions, as is the case with real-time streaming applications, such as SIP and RTSP. Note, applications may not always traverse a proxy and some applications may not have a proxy server available.
然而，代理也可能只是插入控制会话而不是数据会话，就像实时流应用程序（如SIP和RTSP）的情况一样。请注意，应用程序可能并不总是遍历代理，某些应用程序可能没有可用的代理服务器。
SIP proxies and H.323 gatekeepers may be used to host MIDCOM agent functions to control middleboxes implementing firewall and NAT functions. The advantage of using in-path entities, as opposed to creating an entirely new agent, is that the in-path entities already possess application intelligence. You will need to merely enable the use of the MIDCOM protocol to be an effective MIDCOM agent. Figure 2 below illustrates a scenario where the in-path MIDCOM agents
SIP代理和H.323网关守卫可用于承载MIDCOM代理功能，以控制实现防火墙和NAT功能的中间盒。与创建全新代理不同，使用路径内实体的优势在于，路径内实体已经拥有应用程序智能。您只需使MIDCOM协议的使用成为有效的MIDCOM代理即可。下面的图2说明了一个场景，其中MIDCOM代理中的路径
interface with the middlebox. Let us say, the MIDCOM PDP has pre-configured the in-path proxies as trusted MIDCOM agents on the middlebox and the packet filter implements a 'default-deny' packet filtering policy. Proxies use their application-awareness knowledge to control the firewall function and selectively permit a certain number of voice stream sessions dynamically using MIDCOM protocol.
与中间盒的接口。比方说，MIDCOM PDP已将路径内代理预先配置为中间盒上的受信任MIDCOM代理，并且数据包过滤器实施“默认拒绝”数据包过滤策略。代理使用其应用程序感知知识来控制防火墙功能，并有选择地使用MIDCOM协议动态允许一定数量的语音流会话。
In the illustration below, the proxies and the MIDCOM PDP are shown inside a private domain. The intent however, is not to imply that they be inside the private boundary alone. The proxies may also reside external to the domain. The only requirement is that there be a trust relationship with the middlebox.
在下图中，代理和MIDCOM PDP显示在私有域内。然而，其目的并不是暗示它们仅在私人边界内。代理也可以位于域的外部。唯一的要求是与中间人建立信任关系。
+-----------+
| MIDCOM |
| PDP |~~~~~~~~~~~~~|
+-----------+ \
\
+--------+ \
| SIP |___ \
________| Proxy | \ Middlebox \
/ +--------+.. | +--------------------+
| : | MIDCOM | | |
| RTSP +---------+ :..|........| MIDCOM | POLICY |
SIP | ____| RTSP |.....|........| PROTOCOL | INTER- |
| / | Proxy |___ | | INTERFACE | FACE |
| | +---------+ \ \ |--------------------|
| | \ \______| |__SIP
| | \________| |__RTSP
| | ---| FIREWALL |--->--
+-----------+ /---| |---<--
+-----------+| Data streams // +--------------------+
+-----------+||---------->----// |
|end-hosts ||-----------<----- .
+-----------+ (RTP, RTSP data, etc.) |
. Outside the
Within a private domain | private domain
+-----------+
| MIDCOM |
| PDP |~~~~~~~~~~~~~|
+-----------+ \
\
+--------+ \
| SIP |___ \
________| Proxy | \ Middlebox \
/ +--------+.. | +--------------------+
| : | MIDCOM | | |
| RTSP +---------+ :..|........| MIDCOM | POLICY |
SIP | ____| RTSP |.....|........| PROTOCOL | INTER- |
| / | Proxy |___ | | INTERFACE | FACE |
| | +---------+ \ \ |--------------------|
| | \ \______| |__SIP
| | \________| |__RTSP
| | ---| FIREWALL |--->--
+-----------+ /---| |---<--
+-----------+| Data streams // +--------------------+
+-----------+||---------->----// |
|end-hosts ||-----------<----- .
+-----------+ (RTP, RTSP data, etc.) |
. Outside the
Within a private domain | private domain
Legend: ---- Application data path datagrams
____ Application control path datagrams
.... Middlebox Communication Protocol (MIDCOM)
~~~~ MIDCOM PDP Interface
|
. private domain Boundary
|
Legend: ---- Application data path datagrams
____ Application control path datagrams
.... Middlebox Communication Protocol (MIDCOM)
~~~~ MIDCOM PDP Interface
|
. private domain Boundary
|
Figure 2: In-Path MIDCOM Agents for middlebox Communication
图2：用于中间盒通信的路径内MIDCOM代理
End-hosts are another variation of In-Path MIDCOM agents. Unlike Proxies, End-hosts are a direct party to the application and possess all the end-to-end application intelligence there is to it. End-hosts presumably terminate both the control and data paths of an application. Unlike other entities hosting MIDCOM agents, end-host is able to process secure datagrams. However, the problem would be one of manageability - upgrading all the end-hosts running a specific application.
终端主机是Path MIDCOM代理的另一个变体。与代理不同，终端主机是应用程序的直接参与方，拥有应用程序的所有端到端智能。最终主机可能会终止应用程序的控制路径和数据路径。与托管MIDCOM代理的其他实体不同，终端主机能够处理安全数据报。然而，问题在于可管理性——升级运行特定应用程序的所有终端主机。
The functional decomposition of the MIDCOM architecture assumes the existence of a logical entity, known as MIDCOM PDP, responsible for performing authorization and related provisioning services for the middlebox as depicted in figure 1. The MIDCOM PDP is a logical entity which may reside physically on a middlebox or on a node external to the middlebox. The protocol employed for communication between the middlebox and the MIDCOM PDP is unrelated to the MIDCOM protocol.
MIDCOM体系结构的功能分解假设存在一个称为MIDCOM PDP的逻辑实体，该实体负责为中间件执行授权和相关的供应服务，如图1所示。MIDCOM PDP是一个逻辑实体，它可以物理上驻留在中间盒上或中间盒外部的节点上。用于中间盒和MIDCOM PDP之间通信的协议与MIDCOM协议无关。
Agents are registered with a MIDCOM PDP for authorization to invoke services of the middlebox. The MIDCOM PDP maintains a list of agents that are authorized to connect to each of the middleboxes the MIDCOM PDP supports. In the context of the MIDCOM Framework, the MIDCOM PDP does not assist a middlebox in the implementation of the services it provides.
代理向MIDCOM PDP注册，以获得调用middlebox服务的授权。MIDCOM PDP维护有权连接到MIDCOM PDP支持的每个中间盒的代理列表。在MIDCOM框架的上下文中，MIDCOM PDP不帮助中间盒实现其提供的服务。
The MIDCOM PDP acts in an advisory capacity to a middlebox, to authorize or terminate authorization for an agent attempting connectivity to the middlebox. The primary objective of a MIDCOM PDP is to communicate agent authorization information, so as to ensure that the security and integrity of a middlebox is not jeopardized. Specifically, the MIDCOM PDP should associate a trust level with each agent attempting to connect to a middlebox and provide a security profile. The MIDCOM PDP should be capable of addressing cases when end-hosts are agents to the middlebox.
MIDCOM PDP以向中间箱提供咨询的身份，授权或终止试图连接到中间箱的代理的授权。MIDCOM PDP的主要目标是传递代理授权信息，以确保不会危及中间盒的安全性和完整性。具体而言，MIDCOM PDP应将信任级别与尝试连接到中间盒的每个代理关联，并提供安全配置文件。MIDCOM PDP应能够解决终端主机是中间箱代理的情况。
Host authenticity and individual message security are two distinct types of security considerations. Host authentication refers to credentials required of a MIDCOM agent to authenticate itself to the middlebox and vice versa. When authentication fails, the middlebox must not process signaling requests received from the agent that failed authentication. Two-way authentication should be supported. In some cases, the 2-way authentication may be tightly linked to the
主机真实性和单个消息安全性是两种不同类型的安全注意事项。主机身份验证是指MIDCOM代理向中间盒进行自身身份验证所需的凭据，反之亦然。当身份验证失败时，中间盒不得处理从身份验证失败的代理收到的信令请求。应支持双向身份验证。在某些情况下，双向身份验证可能与
establishment of keys to protect subsequent traffic. Two-way authentication is often required to prevent various active attacks on the MIDCOM protocol and secure establishment of keying material.
建立密钥以保护后续通信。通常需要双向身份验证来防止对MIDCOM协议的各种主动攻击和密钥材料的安全建立。
Security services such as authentication, data integrity, confidentiality and replay protection may be adapted to secure MIDCOM messages in an untrusted domain. Message authentication is the same as data origin authentication and is an affirmation that the sender of the message is who it claims to be. Data integrity refers to the ability to ensure that a message has not been accidentally, maliciously or otherwise altered or destroyed. Confidentiality is the encryption of a message with a key, so that only those in possession of the key can decipher the message content. Lastly, replay protection is a form of sequence integrity, so when an intruder plays back a previously recorded sequence of messages, the receiver of the replay messages will simply drop the replay messages into bit-bucket. Certain applications of the MIDCOM protocol might require support for non-repudiation as an option of the data integrity service. Typically, support for non-repudiation is required for billing, service level agreements, payment orders, and receipts for delivery of service.
诸如身份验证、数据完整性、机密性和重播保护等安全服务可适用于在不受信任的域中保护MIDCOM消息。消息身份验证与数据源身份验证相同，它确认消息的发送者就是消息声称的发送者。数据完整性是指确保消息未被意外、恶意或以其他方式更改或破坏的能力。机密性是使用密钥对消息进行加密，以便只有拥有密钥的人才能解密消息内容。最后，重放保护是序列完整性的一种形式，因此，当入侵者回放先前记录的消息序列时，重放消息的接收者将简单地将重放消息放入位桶中。MIDCOM协议的某些应用程序可能需要支持作为数据完整性服务选项的不可否认性。通常，账单、服务级别协议、付款单和服务交付收据都需要对不可否认性的支持。
IPsec AH ([IPSEC-AH]) offers data-origin authentication, data integrity and protection from message replay. IPsec ESP ([IPSEC-ESP]) provides data-origin authentication to a lesser degree (same as IPsec AH if the MIDCOM transport protocol turns out to be TCP or UDP), message confidentiality, data integrity and protection from replay. Besides the IPsec based protocols, there are other security options as well. TLS based transport layer security is one option. There are also many application-layer security mechanisms available. Simple Source-address based security is a minimal form of security and should be relied on only in the most trusted environments, where those hosts will not be spoofed.
IPsec AH（[IPsec-AH]）提供数据源身份验证、数据完整性和防止消息重播的保护。IPsec ESP（[IPsec-ESP]）提供较小程度的数据源身份验证（如果MIDCOM传输协议是TCP或UDP，则与IPsec AH相同）、消息机密性、数据完整性和防止重播。除了基于IPsec的协议外，还有其他安全选项。基于TLS的传输层安全是一种选择。还有许多应用层安全机制可用。基于简单源地址的安全性是一种最低形式的安全性，应该仅在最受信任的环境中使用，这些环境中的主机不会被欺骗。
The MIDCOM message security shall use existing standards, whenever the existing standards satisfy the requirements. Security shall be specified to minimize the impact on sessions that do not use the security option. Security should be designed to avoid introducing and to minimize the impact of denial of service attacks. Some security mechanisms and algorithms require substantial processing or storage, in which case the security protocols should protect themselves as well as against possible flooding attacks that overwhelm the endpoint (i.e., the middlebox or the agent) with such processing. For connection oriented protocols (such as TCP) using security services, the security protocol should detect premature closure or truncation attacks.
只要现有标准满足要求，MIDCOM消息安全性应使用现有标准。应规定安全性，以尽量减少对不使用安全选项的会话的影响。安全设计应避免引入拒绝服务攻击，并将其影响降至最低。一些安全机制和算法需要大量的处理或存储，在这种情况下，安全协议应保护自身，并防止可能的洪水攻击，这些攻击会通过此类处理淹没端点（即，中间箱或代理）。对于使用安全服务的面向连接的协议（如TCP），安全协议应检测过早关闭或截断攻击。
Prior to allowing MIDCOM agents to invoke services of the middlebox, a registration process must take place. Registration is a different process than establishing a MIDCOM session. The former requires provisioning agent profile information with the middlebox or a MIDCOM PDP. Agent registration is often a manual operation performed by an operator rather than the agent itself. Setting up MIDCOM session refers to establishing a MIDCOM transport session and exchanging security credentials between an agent and a middlebox. The transport session uses the registered information for session establishment.
在允许MIDCOM代理调用middlebox的服务之前，必须进行注册过程。注册与建立MIDCOM会话是不同的过程。前者需要使用middlebox或MIDCOM PDP提供供应代理配置文件信息。代理注册通常是由操作员而不是代理本身执行的手动操作。设置MIDCOM会话指的是建立MIDCOM传输会话，并在代理和中间盒之间交换安全凭据。传输会话使用注册的信息建立会话。
Profile of a MIDCOM agent includes agent authorization policy (i.e., session tuples for which the agent is authorized to act as ALG), agent-hosting-entity (e.g., Proxy, Gateway or end-host which hosts the agent), agent accessibility profile (including any host level authentication information) and security profile (i.e., security requirements for messages exchanged between the middlebox and the agent).
MIDCOM代理的配置文件包括代理授权策略（即，授权代理充当ALG的会话元组）、代理托管实体（例如，代理、网关或托管代理的终端主机）、代理可访问性配置文件（包括任何主机级身份验证信息）和安全配置文件（即，中间盒和代理之间交换的消息的安全要求）。
MIDCOM agent profile may be pre-configured on a middlebox. Subsequent to that, the agent may choose to initiate a MIDCOM session prior to any data traffic. For example, MIDCOM agent authorization policy for a middlebox service may be preconfigured by specifying the agent in conjunction with a filter. In the case of a firewall, for example, the ACL tuple may be altered to reflect the optional Agent presence. The revised ACL may look something like the following.
MIDCOM代理配置文件可以在中间盒上预先配置。随后，代理可以选择在任何数据通信之前启动MIDCOM会话。例如，可以通过结合筛选器指定代理来预配置用于middlebox服务的MIDCOM代理授权策略。例如，在防火墙的情况下，可以修改ACL元组以反映可选代理的存在。修改后的ACL可能如下所示。
(<Session-Direction>, <Source-Address>, <Destination-Address>, <IP-
Protocol>, <Source-Port>, <Destination-Port>, <Agent>)
(<Session-Direction>, <Source-Address>, <Destination-Address>, <IP-
Protocol>, <Source-Port>, <Destination-Port>, <Agent>)
The reader should note that this is an illustrative example and not necessarily the actual definition of an ACL tuple. The formal description of the ACL is yet to be devised. Agent accessibility information should also be provisioned. For a MIDCOM agent, accessibility information includes the IP address, trust level, host authentication parameters and message authentication parameters. Once a session is established between a middlebox and a MIDCOM agent, that session should be usable with multiple instances of the application(s), as appropriate. Note, all of this could be captured in an agent profile for ease of management.
读者应该注意，这是一个说明性示例，不一定是ACL元组的实际定义。ACL的正式描述尚待设计。还应提供代理可访问性信息。对于MIDCOM代理，可访问性信息包括IP地址、信任级别、主机身份验证参数和消息身份验证参数。一旦在middlebox和MIDCOM代理之间建立了会话，该会话应可用于应用程序的多个实例（视情况而定）。注意，为了便于管理，所有这些都可以在代理概要文件中捕获。
The technique described above is necessary for the pre-registration of MIDCOM agents with the middlebox. The middlebox provisioning may remain unchanged, if the middlebox learns of the registered agents through a MIDCOM PDP. In either case, the MIDCOM agent should initiate the session prior to the start of the application. If the agent session is delayed until after the application has started, the
上述技术对于MIDCOM代理在middlebox中的预注册是必要的。如果中间盒通过MIDCOM PDP了解到已注册的代理，则中间盒设置可能保持不变。无论哪种情况，MIDCOM代理都应该在应用程序启动之前启动会话。如果代理会话延迟到应用程序启动之后，则
agent might be unable to process the control stream to permit the data sessions. When a middlebox notices an incoming MIDCOM session, and the middlebox has no prior profile of the MIDCOM agent, the middlebox will consult its MIDCOM PDP for authenticity, authorization, and trust guidelines for the session.
代理可能无法处理控制流以允许数据会话。当中间盒注意到传入的MIDCOM会话，并且该中间盒之前没有MIDCOM代理的配置文件时，该中间盒将咨询其MIDCOM PDP以了解会话的真实性、授权和信任准则。
In figure 3 below, we consider SIP applications (Refer [SIP]) to illustrate the operation of the MIDCOM protocol. Specifically, the application assumes that a caller, external to a private domain, initiates the call. The middlebox is assumed to be located at the edge of the private domain. A SIP phone (SIP User Agent Client/Server) inside the private domain is capable of receiving calls from external SIP phones. The caller uses a SIP Proxy, node located external to the private domain, as its outbound proxy. No interior proxy is assumed for the callee. Lastly, the external SIP proxy node is designated to host the MIDCOM agent function.
在下面的图3中，我们考虑SIP应用（参考[SIP]）来说明MIDCOM协议的操作。具体来说，应用程序假定私有域外部的调用方发起调用。假定中间盒位于私有域的边缘。私有域内的SIP电话（SIP用户代理客户端/服务器）能够接收来自外部SIP电话的呼叫。调用者使用SIP代理（位于私有域外部的节点）作为其出站代理。不为被调用方假定内部代理。最后，指定外部SIP代理节点承载MIDCOM代理功能。
Arrows 1 and 8 in the figure below refer to a SIP call setup exchange between the external SIP phone and the SIP proxy. Arrows 4 and 5 refer to a SIP call setup exchange between the SIP proxy and the interior SIP phone, and are assumed to be traversing the middlebox. Arrows 2, 3, 6 and 7 below, between the SIP proxy and the middlebox, refer to MIDCOM communication. Na and Nb represent RTP/RTCP media traffic (Refer [RTP]) path in the external network. Nc and Nd represent media traffic inside the private domain.
下图中的箭头1和8表示外部SIP电话和SIP代理之间的SIP呼叫设置交换。箭头4和5表示SIP代理和内部SIP电话之间的SIP呼叫设置交换，并假定正在穿越中间盒。下面的箭头2、3、6和7在SIP代理和中间盒之间表示MIDCOM通信。Na和Nb表示外部网络中的RTP/RTCP媒体流量（参考[RTP]）路径。Nc和Nd表示私有域内的媒体流量。
_________
--->| SIP |<-----\
/ | Proxy | \
| |_________| |
1| |^ ^| 4|
| || || |
|8 2||3 7||6 |5
______________ | || || | _____________
| |<-/ _v|____|v___ \->| |
| External | Na | | Nc | SIP Phone |
| SIP phone |>------->| Middlebox |>------>| within |
| |<-------<|___________|<------<| Pvt. domain|
|____________| Nb Nd |____________|
_________
--->| SIP |<-----\
/ | Proxy | \
| |_________| |
1| |^ ^| 4|
| || || |
|8 2||3 7||6 |5
______________ | || || | _____________
| |<-/ _v|____|v___ \->| |
| External | Na | | Nc | SIP Phone |
| SIP phone |>------->| Middlebox |>------>| within |
| |<-------<|___________|<------<| Pvt. domain|
|____________| Nb Nd |____________|
Figure 3: MIDCOM framework illustration with In-Path SIP Proxy
图3：带路径内SIP代理的MIDCOM框架说明
As for the SIP application, we make the assumption that the middlebox is pre-configured to accept SIP calls into the private SIP phone. Specifically, this would imply that the middlebox implementing firewall service is pre-configured to permit SIP calls (destination
对于SIP应用程序，我们假设中间盒预先配置为接受SIP呼叫到专用SIP电话。具体地说，这意味着实现防火墙服务的中间包被预先配置为允许SIP呼叫（目的地）
TCP or UDP port number set to 5060) into the private phone. Likewise, middlebox implementing NAPT service would have been pre-configured to provide a port binding, to permit incoming SIP calls to be redirected to the specific private SIP phone. I.e., the INVITE from the external caller is not made to the private IP address, but to the NAPT external address.
将TCP或UDP端口号设置为5060）插入专用电话。同样，实现NAPT服务的middlebox将被预先配置为提供端口绑定，以允许传入的SIP呼叫被重定向到特定的专用SIP电话。也就是说，来自外部调用方的邀请不是发送到私有IP地址，而是发送到NAPT外部地址。
The objective of the MIDCOM agent in the following illustration is to merely permit the RTP/RTCP media stream (Refer [RTP]) through the middlebox, when using the MIDCOM protocol architecture outlined in the document. A SIP session typically establishes two RTP/RTCP media streams - one from the callee to the caller and another from the caller to the callee. These media sessions are UDP based and will use dynamic ports. The dynamic ports used for the media stream are specified in the SDP section (Refer [SDP]) of the SIP payload message. The MIDCOM agent will parse the SDP section and use the MIDCOM protocol to (a) open pinholes (i.e., permit RTP/RTCP session tuples) in a middlebox implementing firewall service, or (b) create PORT bindings and appropriately modify the SDP content to permit the RTP/RTCP streams through a middlebox implementing NAT service. The MIDCOM protocol should be sufficiently rich and expressive to support the operations described under the timelines. The examples do not show the timers maintained by the agent to keep the middlebox policy rule(s) from timing out.
下图中的MIDCOM代理的目标是，在使用本文档中概述的MIDCOM协议体系结构时，仅允许RTP/RTCP媒体流（参考[RTP]）通过中间盒。SIP会话通常建立两个RTP/RTCP媒体流——一个从被叫方到被叫方，另一个从被叫方到被叫方。这些媒体会话基于UDP，将使用动态端口。用于媒体流的动态端口在SIP有效负载消息的SDP部分（参考[SDP]）中指定。MIDCOM代理将解析SDP部分并使用MIDCOM协议（a）在实现防火墙服务的中间盒中打开针孔（即，允许RTP/RTCP会话元组），或（b）创建端口绑定并适当修改SDP内容，以允许RTP/RTCP流通过实现NAT服务的中间盒。MIDCOM协议应足够丰富和富有表现力，以支持时间表中描述的操作。这些示例没有显示代理维护的计时器，以防止中间箱策略规则超时。
MIDCOM agent Registration and connectivity between the MIDCOM agent and the middlebox are not shown in the interest of restricting the focus of the MIDCOM transactions to enabling the middlebox to let the media stream through. MIDCOM PDP is also not shown in the diagram below or on the timelines for the same reason.
MIDCOM代理注册和MIDCOM代理与中间盒之间的连接未显示，其目的是将MIDCOM事务的焦点限制为使中间盒允许媒体流通过。出于同样的原因，MIDCOM PDP也未显示在下图或时间表上。
The following subsections illustrate a typical timeline sequence of operations that transpire with the various elements involved in a SIP telephony application path. Each subsection is devoted to a specific instantiation of a middlebox service - NAPT (refer [NAT-TERM], [NAT-TRAD]), firewall and a combination of both NAPT and firewall are considered.
以下小节说明了SIP电话应用程序路径中涉及的各种元素的典型时间线操作序列。每一小节都专门讨论一个特定的中间包服务实例——NAPT（参考[NAT-TERM]、[NAT-TRAD]）、防火墙以及NAPT和防火墙的组合。
In the following example, we will assume a middlebox implementing a firewall service. We further assume that the middlebox is pre-configured to permit SIP calls (destination TCP or UDP port number set to 5060) into the private phone. The following timeline illustrates the operations performed by the MIDCOM agent, to permit RTP/RTCP media stream through the middlebox.
在下面的示例中，我们将假设一个实现防火墙服务的中间盒。我们进一步假设，该中间盒已预配置为允许SIP呼叫（目标TCP或UDP端口号设置为5060）进入专用电话。以下时间线说明了MIDCOM代理为允许RTP/RTCP媒体流通过中间盒而执行的操作。
The INVITE from the caller (external) is assumed to include the SDP payload. You will note that the MIDCOM agent requests the middlebox to permit the Private-to-external RTP/RTCP flows before the INVITE is relayed to the callee. This is because, in SIP, the calling party must be ready to receive the media when it sends the INVITE with a session description. If the called party (private phone) assumes this and sends "early media" before sending the 200 OK response, the firewall will have blocked these packets without this initial MIDCOM signaling from the agent.
来自调用方（外部）的INVITE被假定为包括SDP负载。您会注意到，在将INVITE中继到被叫方之前，MIDCOM代理请求中间盒允许私有到外部RTP/RTCP流。这是因为，在SIP中，当主叫方发送带有会话描述的INVITE时，它必须准备好接收媒体。如果被叫方（私人电话）在发送200 OK响应之前假设这一点并发送“早期媒体”，则防火墙将在没有来自代理的初始MIDCOM信令的情况下阻止这些数据包。
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (FIREWALL (private)
| | Service) |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| Identify end-2-end | |
| parameters (from Caller's | |
| SDP) for the pri-to-Ext | |
| RTP & RTCP sessions. | |
| (RTP1, RTCP1) | |
| | | |
| |+Permit RTP1, RTCP1 +>| |
| |<+RTP1, RTCP1 OKed++++| |
| | | |
| |--------INVITE---------------------->|
| | | |
| |<-----180 Ringing--------------------|
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify end-2-end | |
| parameters (from callee's | |
| SDP) for the Ext-to-Pri | |
| RTP and RTCP sessions. | |
| (RTP2, RTCP2) | |
| | | |
| |+Permit RTP2, RTCP2 +>| |
| |<+RTP2, RTCP2 OKed++++| |
| | | |
|<---200 OK ------| | |
|-------ACK------>| | |
| |-----------ACK---------------------->|
| | | |
|<===================RTP/RTCP==========================>|
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (FIREWALL (private)
| | Service) |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| Identify end-2-end | |
| parameters (from Caller's | |
| SDP) for the pri-to-Ext | |
| RTP & RTCP sessions. | |
| (RTP1, RTCP1) | |
| | | |
| |+Permit RTP1, RTCP1 +>| |
| |<+RTP1, RTCP1 OKed++++| |
| | | |
| |--------INVITE---------------------->|
| | | |
| |<-----180 Ringing--------------------|
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify end-2-end | |
| parameters (from callee's | |
| SDP) for the Ext-to-Pri | |
| RTP and RTCP sessions. | |
| (RTP2, RTCP2) | |
| | | |
| |+Permit RTP2, RTCP2 +>| |
| |<+RTP2, RTCP2 OKed++++| |
| | | |
|<---200 OK ------| | |
|-------ACK------>| | |
| |-----------ACK---------------------->|
| | | |
|<===================RTP/RTCP==========================>|
| | | |
|-------BYE------>| | |
| |--------------------------BYE------->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |++Cancel permits to | |
| | RTP1, RTCP1, RTP2, | |
| | and RTCP2 +++++++++>| |
| |<+RTP1, RTP2, RTCP1 & | |
| | RTCP2 cancelled ++++| |
| | | |
|<---200 OK-------| | |
| | | |
| | | |
|-------BYE------>| | |
| |--------------------------BYE------->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |++Cancel permits to | |
| | RTP1, RTCP1, RTP2, | |
| | and RTCP2 +++++++++>| |
| |<+RTP1, RTP2, RTCP1 & | |
| | RTCP2 cancelled ++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
In the following example, we will assume a middlebox implementing NAPT service. We make the assumption that the middlebox is pre-configured to redirect SIP calls to the specific private SIP phone application. I.e., the INVITE from the external caller is not made to the private IP address, but to the NAPT external address. Let us say, the external phone's IP address is Ea, NAPT middlebox external Address is Ma, and the internal SIP phone's private address is Pa. SIP calls to the private SIP phone will arrive as TCP/UDP sessions, with the destination address and port set to Ma and 5060 respectively. The middlebox will redirect these datagrams to the internal SIP phone. The following timeline will illustrate the operations necessary to be performed by the MIDCOM agent to permit the RTP/RTCP media stream through the middlebox.
在下面的示例中，我们将假设一个实现NAPT服务的中间盒。我们假设中间盒已预配置为将SIP呼叫重定向到特定的专用SIP电话应用程序。也就是说，来自外部调用方的邀请不是发送到私有IP地址，而是发送到NAPT外部地址。比如说，外部电话的IP地址是Ea，NAPT middlebox外部地址是Ma，内部SIP电话的专用地址是Pa。对专用SIP电话的SIP呼叫将作为TCP/UDP会话到达，目标地址和端口分别设置为Ma和5060。中间盒将这些数据报重定向到内部SIP电话。以下时间线将说明MIDCOM代理为允许RTP/RTCP媒体流通过中间盒而必须执行的操作。
As with the previous example (section 7.1), the INVITE from the caller (external) is assumed to include the SDP payload. You will note that the MIDCOM agent requests the middlebox to create NAT session descriptors for the private-to-external RTP/RTCP flows before the INVITE is relayed to the private SIP phone (for the same reasons as described in section 7.1). If the called party (private phone) sends "early media" before sending the 200 OK response, the NAPT middlebox will have blocked these packets without the initial MIDCOM signaling from the agent. Also, note that after the 200 OK is received by the proxy from the private phone, the agent requests the middlebox to allocate NAT session descriptors for the external-to-private RTP2 and RTCP2 flows, such that the ports assigned on the Ma for RTP2 and RTCP2 are contiguous. The RTCP stream does not happen
与前面的示例（第7.1节）一样，假定来自调用方（外部）的INVITE包含SDP有效负载。您会注意到，在将INVITE中继到专用SIP电话之前，MIDCOM代理会请求中间件为专用到外部RTP/RTCP流创建NAT会话描述符（原因与第7.1节所述相同）。如果被叫方（私人电话）在发送200 OK响应之前发送“早期媒体”，NAPT中间盒将在没有来自代理的初始MIDCOM信令的情况下阻止这些数据包。另外，请注意，在代理从专用电话接收到200 OK之后，代理请求中间盒为外部到专用RTP2和RTCP2流分配NAT会话描述符，以便在Ma上为RTP2和RTCP2分配的端口是连续的。RTCP流不会发生
with a non-contiguous port. Lastly, you will note that even though each media stream (RTP1, RTCP1, RTP2 and RTCP2) is independent, they are all tied to the single SIP control session, while their NAT session descriptors were being created. Finally, when the agent issues a terminate session bundle command for the SIP session, the middlebox is assumed to delete all associated media stream sessions automagically.
使用非连续端口。最后，您将注意到，即使每个媒体流（RTP1、RTCP1、RTP2和RTCP2）都是独立的，但在创建NAT会话描述符时，它们都绑定到单个SIP控制会话。最后，当代理为SIP会话发出终止会话包命令时，假定中间盒自动删除所有关联的媒体流会话。
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT (Private)
IP Addr:Ea | Service) IP addr:Pa
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT (Private)
IP Addr:Ea | Service) IP addr:Pa
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for the RTP2 port on Ma. | |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | | |
| Modify IP addresses | |
| appropriately in the SIP | |
| header (e.g., To, from, | |
| Via, contact fields) | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for the RTP2 port on Ma. | |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | | |
| Modify IP addresses | |
| appropriately in the SIP | |
| header (e.g., To, from, | |
| Via, contact fields) | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
|<---200 OK-------| | |
| | | |
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
In the following example, we will assume a middlebox implementing a combination of a firewall and a stateful NAPT service. We make the assumption that the NAPT function is configured to translate the IP and TCP headers of the initial SIP session into the private SIP phone, and the firewall function is configured to permit the initial SIP session.
在下面的示例中，我们将假设一个中间件实现防火墙和有状态NAPT服务的组合。我们假设NAPT功能配置为将初始SIP会话的IP和TCP头转换为专用SIP电话，防火墙功能配置为允许初始SIP会话。
In the following time line, it may be noted that the firewall description is based on packet fields on the wire (ex: as seen on the external interface of the middlebox). In order to ensure correct behavior of the individual services, you will notice that NAT specific MIDCOM operations precede firewall specific operations on the MIDCOM agent. This is noticeable in the time line below when the MIDCOM agent processes the "200 OK" from the private SIP phone. The MIDCOM agent initially requests the NAT service on the middlebox to set up port-BIND and session-descriptors for the media stream in both directions. Subsequent to that, the MIDCOM agent determines the session parameters (i.e., the dynamic UDP ports) for the media stream, as viewed by the external interface and requests the firewall service on the middlebox to permit those sessions through.
在下面的时间线中，可能会注意到防火墙描述基于线路上的数据包字段（例如：在中间盒的外部接口上看到）。为了确保各个服务的正确行为，您将注意到特定于NAT的MIDCOM操作先于MIDCOM代理上特定于防火墙的操作。当MIDCOM代理处理来自专用SIP电话的“200OK”时，这在下面的时间线中很明显。MIDCOM代理最初请求中间盒上的NAT服务为两个方向的媒体流设置端口绑定和会话描述符。随后，MIDCOM代理确定媒体流的会话参数（即，动态UDP端口），由外部接口查看，并请求中间件上的防火墙服务允许这些会话通过。
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT & (Private)
IP Addr:Ea | firewall IP addr:Pa
| | Services) |
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT & (Private)
IP Addr:Ea | firewall IP addr:Pa
| | Services) |
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| |++Permit RTP1 & RTCP1 | |
| | sessions External to| |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions ++++++++++>| |
| |<+Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions OKed ++++++| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| |++Permit RTP1 & RTCP1 | |
| | sessions External to| |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions ++++++++++>| |
| |<+Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions OKed ++++++| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created | |
| | on Ma as (Mport2, | |
| | Mport2+1) ++++++++++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for RTP2 port on Ma. | |
| | | |
| |++Permit RTP2 & RTCP2 | |
| | sessions External | |
| | middlebox, namely | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2 | |
| | sessions OKed ++++++| |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created | |
| | on Ma as (Mport2, | |
| | Mport2+1) ++++++++++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for RTP2 port on Ma. | |
| | | |
| |++Permit RTP2 & RTCP2 | |
| | sessions External | |
| | middlebox, namely | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2 | |
| | sessions OKed ++++++| |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
| |++Cancel permits to | |
| | sessions External | |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Removed permits to | |
| | sessions listed ++++| |
| | | |
|<---200 OK-------| | |
| | | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
| |++Cancel permits to | |
| | sessions External | |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Removed permits to | |
| | sessions listed ++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
A middlebox cannot be assumed to be a simple device implementing just one middlebox function and no more than a couple of interfaces. Middleboxes often combine multiple intermediate functions into the same device and have the ability to provision individual interfaces of the same device with different sets of functions and varied provisioning for the same function across the interfaces.
不能假设一个中间盒是一个简单的设备，只实现一个中间盒功能，而不超过两个接口。中间盒通常将多个中间功能组合到同一设备中，并且能够为同一设备的各个接口提供不同的功能集，并跨接口为同一功能提供不同的配置。
As such, a MIDCOM agent ought to be able to have a single MIDCOM session with a middlebox and use the MIDCOM interface on the middlebox to interface with different services on the same middlebox.
因此，MIDCOM代理应该能够与中间箱进行单个MIDCOM会话，并使用中间箱上的MIDCOM接口与同一中间箱上的不同服务进行接口。
Asynchronous notification by the middlebox to a MIDCOM agent can be useful for events such as Session creation, Session termination, MIDCOM protocol failure, middlebox function failure or any other significant event. Independently, ICMP error codes can also be useful to notify transport layer failures to the agents.
middlebox向MIDCOM代理发送的异步通知对于诸如会话创建、会话终止、MIDCOM协议故障、middlebox功能故障或任何其他重要事件等事件非常有用。独立地，ICMP错误代码也可用于向代理通知传输层故障。
In addition, periodic notification of various forms of data, such as statistics update, would also be a useful function that would be beneficial to certain types of agents.
此外，定期通知各种形式的数据，如统计数据更新，也是一项有益的功能，对某些类型的代理人有利。
When supporting the MIDCOM protocol, the middlebox is required to allocate dynamic resources, as specified in policy rule(s), upon request from agents. Explicit release of dynamically allocated resources happens when the application session is ended or when a MIDCOM agent requests the middlebox to release the resource.
当支持MIDCOM协议时，需要按照策略规则中的规定，在代理请求时，中间件分配动态资源。当应用程序会话结束或MIDCOM代理请求中间件释放资源时，会显式释放动态分配的资源。
However, the middlebox should be able to recover the dynamically allocated resources, even as the agent that was responsible for the allocation is not alive. Associating a lifetime for these dynamic resources and using a timer to track the lifetime can be a good way to accomplish this.
但是，即使负责分配的代理不存在，中间件也应该能够恢复动态分配的资源。将这些动态资源的生存期关联起来并使用计时器跟踪生存期是实现这一点的好方法。
A middlebox could be implementing a variety of services (e.g. NAT and firewall) in the same box. Some of these services might have inter-dependency on shared resources and sequence of operation. Others may be independent of each other. Generally speaking, the sequence in which these function operations may be performed on datagrams is not within the scope of this document.
中间盒可以在同一个盒子中实现多种服务（例如NAT和防火墙）。其中一些服务可能对共享资源和操作顺序具有相互依赖性。其他人可能相互独立。一般来说，对数据报执行这些功能操作的顺序不在本文件的范围内。
In the case of a middlebox implementing NAT and firewall services, it is safe to state that the NAT operation on an interface will precede a firewall on the egress and will follow a firewall on the ingress. Further, firewall access control lists, used by a firewall, are assumed to be based on session parameters, as seen on the interface supporting firewall service.
在实施NAT和防火墙服务的中间箱的情况下，可以安全地声明，接口上的NAT操作将在出口上的防火墙之前，并在入口上的防火墙之后。此外，防火墙使用的防火墙访问控制列表假定基于会话参数，如支持防火墙服务的接口上所示。
The class of applications the MIDCOM architecture addresses focus around applications that have a combination of, one or more, signaling and data traffic sessions. The signaling may be done out-of-band, using a dedicated stand-alone session or may be done in-band, within a data session. Alternately, signaling may also be done as a combination of both stand-alone and in-band sessions.
MIDCOM体系结构所涉及的应用程序类别集中于具有一个或多个信令和数据通信会话组合的应用程序。信令可以使用专用的独立会话在带外完成，或者可以在数据会话内在带内完成。或者，信令也可以作为独立会话和带内会话的组合来完成。
SIP is an example of an application based on distinct signaling and data sessions. A SIP signaling session is used for call setup between a caller and a callee. A MIDCOM agent may be required to examine/modify SIP payload content to administer the middlebox so as to let the media streams (RTP/RTCP based) through. A MIDCOM agent is not required to intervene in the data traffic.
SIP是基于不同信令和数据会话的应用程序示例。SIP信令会话用于在呼叫者和被呼叫者之间建立呼叫。可能需要MIDCOM代理检查/修改SIP有效负载内容以管理中间盒，以便允许媒体流（基于RTP/RTCP）通过。MIDCOM代理不需要干预数据通信。
Signaling and context specific Header information is sent in-band, within the same data stream for applications such as HTTP embedded applications, sun-RPC (embedding a variety of NFS apps), Oracle transactions (embedding oracle SQL+, MS ODBC, Peoplesoft) etc.
信令和特定于上下文的报头信息在同一数据流中以频带发送，用于HTTP嵌入式应用程序、sun RPC（嵌入各种NFS应用程序）、Oracle事务（嵌入Oracle SQL+、MS ODBC、Peoplesoft）等应用程序。
H.323 is an example of an application that sends signaling in both dedicated stand-alone sessions, as well as in conjunction with data. H.225.0 call signaling traffic traverses middleboxes by virtue of static policy, no MIDCOM control needed. H.225.0 call signaling also negotiates ports for an H.245 TCP stream. A MIDCOM agent is required to examine/modify the contents of the H.245 so that H.245 can traverse it.
323是在专用独立会话中以及与数据一起发送信令的应用程序的示例。H.225.0呼叫信令流量通过静态策略穿越中间箱，无需MIDCOM控制。H.225.0呼叫信令还为H.245 TCP流协商端口。MIDCOM代理需要检查/修改H.245的内容，以便H.245能够遍历它。
H.245 traverses the middlebox and also carries Open Logical Channel information for media data. So, the MIDCOM agent is once again required to examine/modify the payload content needs to let the media traffic flow.
H.245遍历中间盒，还携带媒体数据的开放逻辑通道信息。因此，MIDCOM代理再次需要检查/修改有效负载内容，以允许媒体流量流动。
The MIDCOM architecture takes into consideration, supporting applications with independent signaling and data sessions as well as applications that have signaling and data communicated over the same session.
MIDCOM体系结构考虑支持具有独立信令和数据会话的应用程序，以及在同一会话中进行信令和数据通信的应用程序。
In the cases where signaling is done on a single stand-alone session, it is desirable to have a MIDCOM agent interpret the signaling stream and program the middlebox (that transits the data stream) so as to let the data traffic through uninterrupted.
在信令在单个独立会话上完成的情况下，希望让MIDCOM代理解释信令流并对中间盒（传输数据流）进行编程，以便让数据流量不间断地通过。
Middleboxes may be stationed in a number of topologies. However, the signaling framework outlined in this document may be limited to only those middleboxes that are located in a DMZ (De-Militarized Zone) at the edge of a private domain, connecting to the Internet. Specifically, the assumption is that you have a single middlebox (running NAT or firewall) along the application route. Discovery of a middlebox along an application route is outside the scope of this document. It is conceivable to have middleboxes located between departments within the same domain or inside the service provider's domain and so forth. However, care must be taken to review each individual scenario and determine the applicability on a case-by-case basis.
中间盒可以安装在许多拓扑中。然而，本文件中概述的信令框架可能仅限于位于私有域边缘的DMZ（非军事化区）中连接到互联网的那些中间盒。具体地说，假设您在应用程序路由上有一个中间包（运行NAT或防火墙）。在应用程序路径上发现中间盒不在本文档的范围之内。可以想象，在同一领域内的部门之间或在服务提供商的领域内等都有中间盒。但是，必须注意审查每个单独的场景，并根据具体情况确定适用性。
The applicability may also be illustrated as follows. Real-time and streaming applications, such as Voice-Over-IP, and peer-to-peer applications, such as Napster and Netmeeting, require administering firewalls and NAT middleboxes to let their media streams reach hosts inside a private domain. The requirements are in the form of
还可以如下说明适用性。实时和流式应用程序（如IP语音）以及对等应用程序（如Napster和Netmeeting）需要管理防火墙和NAT中间件，以使其媒体流到达私有域内的主机。要求的形式为
establishing a "pin-hole" to permit a TCP/UDP session (the port parameters of which are dynamically determined) through a firewall or retain an address/port bind in the NAT device to permit sessions to a port. These requirements are met by current generation middleboxes using adhoc methods, such as embedding application intelligence within a middlebox to identify the dynamic session parameters and administering the middlebox internally as appropriate. The objective of the MIDCOM architecture is to create a unified, standard way to exercise this functionality, currently existing in an ad-hoc fashion, in some of the middleboxes.
建立“针孔”以允许TCP/UDP会话（其端口参数是动态确定的）通过防火墙，或在NAT设备中保留地址/端口绑定以允许到端口的会话。这些要求由使用特殊方法的当前一代中间盒来满足，例如在中间盒中嵌入应用程序智能以识别动态会话参数，并在适当的情况下在内部管理中间盒。MIDCOM体系结构的目标是创建一种统一的、标准的方式来实现这些功能，目前这些功能以特别方式存在于一些中间件中。
By adopting MIDCOM architecture, middleboxes will be able to support newer applications they have not been able to support thus far. MIDCOM architecture does not, and must not in anyway, change the fundamental characteristic of the services supported on the middlebox.
通过采用MIDCOM体系结构，中间件将能够支持迄今为止无法支持的较新应用程序。MIDCOM体系结构不会，而且无论如何都不能改变middlebox上支持的服务的基本特性。
Typically, organizations shield a majority of their corporate resources (such as end-hosts) from visibility to the external network by the use of a De-Militarized Zone (DMZ) at the domain edge. Only a portion of these hosts are allowed to be accessed by the external world. The remaining hosts and their names are unique to the private domain. Hosts visible to the external world and the authoritative name server that maps their names to network addresses are often configured within a DMZ (De-Militarized Zone) in front of a firewall. Hosts and middleboxes within DMZ are referred to as DMZ nodes.
通常，组织通过在域边缘使用非军事化区域（DMZ），保护其大部分公司资源（如终端主机）不被外部网络看到。外部世界只允许访问这些主机的一部分。其余主机及其名称对于私有域是唯一的。外部世界可见的主机和将其名称映射到网络地址的权威名称服务器通常配置在防火墙前面的DMZ（非军事化区域）内。DMZ内的主机和中间盒称为DMZ节点。
Figure 4 below illustrates the configuration of a private domain with a DMZ at its edge. Actual configurations may vary. Internal hosts are accessed only by users inside the domain. Middleboxes, located in the DMZ may be accessed by agents inside or outside the domain.
下面的图4说明了在其边缘具有DMZ的私有域的配置。实际配置可能会有所不同。内部主机只能由域内的用户访问。位于DMZ的中间盒可由域内或域外的代理访问。
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
Stub A .........|\|....
|
+---------------+
| NAT middlebox |
+---------------+
|
| DMZ - Network
------------------------------------------------------------
| | | | |
+--+ +--+ +--+ +--+ +-----------+
|__| |__| |__| |__| | Firewall |
/____\ /____\ /____\ /____\ | middlebox |
DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+
Server Server etc. |
|
Internal Hosts (inside the private domain) |
------------------------------------------------------------
| | | |
+--+ +--+ +--+ +--+
|__| |__| |__| |__|
/____\ /____\ /____\ /____\
Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
Stub A .........|\|....
|
+---------------+
| NAT middlebox |
+---------------+
|
| DMZ - Network
------------------------------------------------------------
| | | | |
+--+ +--+ +--+ +--+ +-----------+
|__| |__| |__| |__| | Firewall |
/____\ /____\ /____\ /____\ | middlebox |
DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+
Server Server etc. |
|
Internal Hosts (inside the private domain) |
------------------------------------------------------------
| | | |
+--+ +--+ +--+ +--+
|__| |__| |__| |__|
/____\ /____\ /____\ /____\
Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server
Figure 4: DMZ network configuration of a private domain.
图4：专用域的DMZ网络配置。
The authors wish to thank Christian Huitema, Joon Maeng, Jon Peterson, Mike Fisk, Matt Holdrege, Melinda Shore, Paul Sijben, Philip Mart, Scott Brim and Richard Swale for their valuable critique, advice and input on an earlier rough version of this document. The authors owe special thanks to Eliot Lear for kick-starting the e-mail discussion on use-case scenarios with a SIP application flow diagram through a middlebox. Much thanks to Bob Penfield, Cedric Aoun, Christopher Martin, Eric Fleischman, George Michaelson, Wanqun Bao, and others in the MIDCOM work group for their very detailed feedback on a variety of topics and adding clarity to the discussion. Last, but not the least, the authors owe much thanks to Mark Duffy, Scott Brim, Melinda Shore and others for their help with terminology definition and discussing the embedded requirements within the framework document.
作者希望感谢Christian Huitema、Joon Maeng、Jon Peterson、Mike Fisk、Matt Holdrege、Melinda Shore、Paul Sijben、Philip Mart、Scott Brim和Richard Swale对本文件早期粗略版本的宝贵评论、建议和意见。作者特别感谢Eliot Lear，他通过一个中间箱，通过SIP应用程序流程图，启动了关于用例场景的电子邮件讨论。非常感谢MIDCOM工作组中的Bob Penfield、Cedric Aoun、Christopher Martin、Eric Fleischman、George Michaelson、Wanqun Bao和其他人就各种主题提供了非常详细的反馈，并为讨论增加了清晰度。最后，但并非最不重要的一点是，作者非常感谢Mark Duffy、Scott Brim、Melinda Shore和其他人在术语定义和讨论框架文档中的嵌入式需求方面提供的帮助。
Discussed below are security considerations in accessing a middlebox. Without MIDCOM protocol support, the premise of a middlebox operation fundamentally requires the data to be in the clear, as the middlebox needs the ability to inspect and/or modify packet headers and payload. This compromises the confidentiality requirement in some environments. Further, updating transport headers and rewriting application payload data, in some cases, by NAT prevents the use of integrity protection on some data streams traversing NAT middleboxes. Clearly, this can pose a significant security threat to the application in an untrusted transport domain.
Discussed below are security considerations in accessing a middlebox. Without MIDCOM protocol support, the premise of a middlebox operation fundamentally requires the data to be in the clear, as the middlebox needs the ability to inspect and/or modify packet headers and payload. This compromises the confidentiality requirement in some environments. Further, updating transport headers and rewriting application payload data, in some cases, by NAT prevents the use of integrity protection on some data streams traversing NAT middleboxes. Clearly, this can pose a significant security threat to the application in an untrusted transport domain.translate error, please retry
The MIDCOM protocol framework removes the need for a middlebox to inspect or manipulate transport payload. This allows applications to better protect themselves end-to-end with the aid of a trusted MIDCOM agent. This is especially the case when the agent is a resident on the end-host. When an agent has the same end-to-end ability as the end-host to interpret encrypted and integrity protected data, transiting a middlebox can be encrypted and integrity protected. The MIDCOM agent will still be able to interpret the data and simply notify the middlebox of open holes, install NAT table entries, etc. Note, however, the MIDCOM framework does not help with the problem of NAT breaking IPsec since in this case the middlebox still modifies IP and transport headers.
MIDCOM协议框架不再需要中间盒来检查或操作传输负载。这使得应用程序能够在可信的MIDCOM代理的帮助下更好地端到端保护自己。当代理是终端主机上的驻留主机时尤其如此。当代理具有与终端主机相同的端到端能力来解释加密和完整性保护的数据时，可以加密和完整性保护中转箱。MIDCOM代理仍然能够解释数据，并简单地通知中间箱打开的漏洞、安装NAT表条目等。但是，请注意，MIDCOM框架无助于解决NAT破坏IPsec的问题，因为在这种情况下，中间箱仍会修改IP和传输头。
Security between a MIDCOM agent and a middlebox has a number of components. Authorization, authentication, integrity and confidentiality. Authorization refers to whether a particular agent is authorized to signal a middlebox with requests for one or more applications, adhering to a certain policy profile. Failing the authorization process might indicate a resource theft attempt or failure due to administrative and/or credential deficiencies. In either case, the middlebox should take the proper measures to audit/log such attempts and consult its designated MIDCOM PDP for the required action if the middlebox is configured with one. Alternatively, the middlebox may resort to a default service deny policy when a MIDCOM agent fails to prompt the required credentials. Section 6 discusses the middlebox to MIDCOM PDP interactions in view of policy decisions.
MIDCOM代理和中间盒之间的安全性有许多组件。授权、认证、完整性和保密性。授权是指是否授权特定代理向中间箱发送一个或多个应用程序的请求，并遵守特定的策略配置文件。授权过程失败可能表示由于管理和/或凭据缺陷而导致资源盗窃企图或失败。在任何一种情况下，如果中间箱配置了一个，则中间箱应采取适当措施审计/记录此类尝试，并咨询其指定的MIDCOM PDP以了解所需的操作。或者，当MIDCOM代理无法提示所需的凭据时，middlebox可以求助于默认的服务拒绝策略。第6节从政策决策的角度讨论了从中间箱到MIDCOM PDP的交互。
Authentication refers to confirming the identity of an originator for all datagrams received from the originator. Lack of strong credentials for authentication of MIDCOM messages between an agent and a middlebox can seriously jeopardize the fundamental service rendered by the middlebox. A consequence of not authenticating an agent would be that an attacker could spoof the identity of a "legitimate" agent and open holes in the firewall. Another would be
认证是指确认从发端人接收的所有数据报的发端人身份。代理和中间箱之间缺少对MIDCOM消息进行身份验证的强凭据可能会严重危害中间箱提供的基本服务。未对代理进行身份验证的结果是，攻击者可以伪造“合法”代理的身份，并在防火墙中打开漏洞。另一个是
that it could otherwise manipulate the state on a middlebox, creating a denial-of-service attack by closing needed pinholes or filling up a NAT table. A consequence of not authenticating the middlebox to an agent is that an attacker could pose as a middlebox and respond to NAT requests in a manner that would divert data to the attacker. Failing to submit the required/valid credentials, once challenged, may indicate a replay attack, in which case a proper action is required by the middlebox such as auditing, logging, or consulting its designated MIDCOM PDP to reflect such failure. A consequence of not protecting the middlebox against replay attacks would be that a specific pinhole may be reopened or closed by an attacker at will, thereby bombarding end hosts with unwarranted data or causing denial of service.
否则，它可能会操纵中间盒上的状态，通过关闭所需的针孔或填充NAT表来创建拒绝服务攻击。未向代理验证中间箱的结果是，攻击者可能会冒充中间箱，以将数据转移给攻击者的方式响应NAT请求。如果未能提交所需/有效的凭据，一旦受到质疑，可能表明发生了重播攻击，在这种情况下，中间件需要采取适当的措施，如审计、记录或咨询其指定的MIDCOM PDP以反映此类失败。不保护中间盒免受重播攻击的后果是，攻击者可能会随意重新打开或关闭特定针孔，从而用不必要的数据轰炸终端主机或造成拒绝服务。
Integrity is required to ensure that a MIDCOM message has not been accidentally or maliciously altered or destroyed. The result of a lack of data integrity enforcement in an untrusted environment could be that an imposter will alter the messages sent by an agent and bring the middlebox to a halt or cause a denial of service for the application the agent is attempting to enable.
完整性是确保MIDCOM消息未被意外或恶意更改或破坏所必需的。在不受信任的环境中缺乏数据完整性强制执行的结果可能是，冒名顶替者将更改代理发送的消息，并使中间箱停止，或导致代理尝试启用的应用程序拒绝服务。
Confidentiality of MIDCOM messages ensure that the signaling data is accessible only to the authorized entities. When a middlebox agent is deployed in an untrusted environment, lack of confidentiality will allow an intruder to perform traffic flow analysis and snoop the middlebox. The intruder could cannibalize a lesser secure MIDCOM session and destroy or compromise the middlebox resources he uncovered on other sessions. Needless to say, the least secure MIDCOM session will become the achilles heel and make the middlebox vulnerable to security attacks.
MIDCOM消息的保密性确保信令数据仅可供授权实体访问。当在不受信任的环境中部署middlebox代理时，缺乏机密性将允许入侵者执行流量分析并窥探middlebox。入侵者可能会蚕食不太安全的MIDCOM会话，并破坏或破坏他在其他会话中发现的中间盒资源。不用说，最不安全的MIDCOM会话将成为致命弱点，使中间包容易受到安全攻击。
Lastly, there can be security vulnerability to the applications traversing a middlebox when a resource on a middlebox is controlled by multiple external agents. A middlebox service may be disrupted due to conflicting directives from multiple agents associated with different middlebox functions but applied to the same application session. Care must be taken in the protocol design to ensure that agents for one function do not abruptly step over resources impacting a different function. Alternately, the severity of such manifestations could be lessened when a single MIDCOM agent is responsible for supporting all the middlebox services for an application, due to the reduced complexity and synchronization effort in managing the middlebox resources.
最后，当中间盒上的资源由多个外部代理控制时，通过中间盒的应用程序可能存在安全漏洞。由于多个代理与不同的中间盒功能关联但应用于同一应用程序会话的指令冲突，中间盒服务可能会中断。协议设计中必须小心，以确保一个功能的代理不会突然跨过影响不同功能的资源。或者，当一个MIDCOM代理负责支持一个应用程序的所有中间包服务时，由于管理中间包资源的复杂性和同步工作降低，这种表现的严重性可以降低。
References
工具书类
[SIP] Rosenberg, J., Shulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]Rosenberg，J.，Shulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，Schooler，E.，“SIP：会话启动协议”，RFC 3261，2002年6月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[H.323] ITU-T Recommendation H.323. "Packet-based Multimedia Communications Systems," 1998.
[H.323]ITU-T建议H.323。“基于分组的多媒体通信系统”，1998年。
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RTP]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[RTSP] Schulzrinne, H., Rao, A. and R. Lanphier: "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RTSP]Schulzrinne，H.，Rao，A.和R.Lanphier：“实时流协议（RTSP）”，RFC 23261998年4月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，1985年10月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NAT-PT]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPsec AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[IPsec ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[POL-TERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[POL-TERM]Westerinen，A.，Schnizlein，J.，Strassner，J.，Scherling，M.，Quinn，B.，Herzog，S.，Huynh，A.，Carlson，M.，Perry，J.和S.Waldbusser，“基于政策的管理术语”，RFC 3198，2001年11月。
[REQMTS] Swale, R. P., Mart, P. A., Sijben, P., Brim, S. and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
[REQMTS]Swale，R.P.，Mart，P.A.，Sijben，P.，Brim，S.和M.Shore，“中间箱通信（midcom）协议要求”，RFC 33042002年8月。
Authors' Addresses
作者地址
Pyda Srisuresh Kuokoa Networks, Inc. 475 Potrero Ave. Sunnyvale, CA 94085 EMail: srisuresh@yahoo.com
Pyda Srisuresh Kuokoa Networks，Inc.加利福尼亚州桑尼维尔市Potrero大道475号94085电子邮件：srisuresh@yahoo.com
Jiri Kuthan Fraunhofer Institute FOKUS Kaiserin-Augusta-Allee 31 D-10589 Berlin, Germany EMail: kuthan@fokus.fhg.de
Jiri Kuthan Fraunhofer研究所FOKUS Kaiserin Augusta Allee 31 D-10589德国柏林电子邮件：kuthan@fokus.fhg.de
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 U.S.A. EMail: jdrosen@dynamicsoft.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue一楼东汉诺威，NJ 07936美国电子邮件：jdrosen@dynamicsoft.com
Andrew Molitor Aravox technologies 4201 Lexington Avenue North, Suite 1105 Arden Hills, MN 55126 U.S.A. voice: (651) 256-2700 EMail: amolitor@visi.com
Andrew Molitor Aravox technologies美国明尼苏达州亚顿山列克星敦大道北4201号1105室55126语音：（651）256-2700电子邮件：amolitor@visi.com
Abdallah Rayhan WINCORE Lab Electrical and Computer Engineering Ryerson University 350 Victoria Street Toronto, ON M5B 2K3 EMail: rayhan@ee.ryerson.ca, ar_rayhan@yahoo.ca
Abdallah Rayhan WINCORE实验室电气和计算机工程Ryerson大学多伦多维多利亚街350号，M5B 2K3电子邮件：rayhan@ee.ryerson.ca，ar_rayhan@yahoo.ca
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。