Network Working Group R. Penno INTERNET-DRAFT Nortelnetworks Expires: January, 2002 A. Rayhan Consultant M. Duffy QuarryTech Out-Of-Path (OOP) Agents and MIDCOM Framework Integration Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft extends the MIDCOM framework described in [midcom] to support Out-Of-Path (OOP) agents. Penno et al. [Page 1] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 1. Introduction Middleboxes have been introduced in [MIDCOM] as a network intermediate devices that implement one or more of the middlebox services. These services cover a number of applications such as firewall filtering, NATing, VPN tunneling, etc. Rather than limiting application intelligence physically to the middlebox, the MIDCOM architecture proposes a different alternative based on external agents. The agents, also known as MIDCOM agents, possessing application awareness relieving the middleboxes from implementing ALGs or integrating them into their implementation. The MIDCOM Framework limits its discussion to one type of agents known as In- Path agents. They refer to those agents that are natively in the transport path of the application. This documents extends the framework in [MIDCOM] to address agents that fall within a different category known as Out-Of-Path (OOP) agents. OOP agents in a nutshell are those agents that are not natively in the transport path of the application. When ALGs are used in conjunction with another MIDCOM service, such as NAT, they examine and optionally modify application payload so the end-to-end application behavior can remain unchanged. Thus allowing many applications to traverse the middlebox. The MIDCOM architecture rather than embedding such intelligence in middleboxes, it relies upon the agents to perform such tasks. The integration of MIDCOM agents into the MIDCOM framework depends on the following: - Type of agent, - Type of the application supported by the middlebox, and - Agent deployment requirements. In-path agents are the only type of agents considered in the MIDCOM Framework [MIDCOM]. In-Path agents play native role in the path of the application traversal. For example, 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 agents are those that find themselves in the control path. An alternative to In-Path agents is Out-of-Path (OOP) agents in which they are not natively in the transport path of an application. In other words, they are not necessarily resident (or co-resident) on entities that are natively in the path of application flows. OOP agents have a few benefits. OOP agents can be implemented in a system, independent of any pre-existing application-aware entity. Unlike In-path agents, there are no topological restrictions as to where the agents can be located. Further, multiple application specific agents can be grouped together on the same node. Penno et al. [Page 2] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 The MIDCOM Framework [MIDCOM] discusses packet filtering and NAT services. These services address deployment and functional requirements of applications such as H.323, SIP and RTSP. Other types of applications have different deployment and functional requirements. For example, content inspection requires inspecting the application payload and modifying it as deemed necessary. The agent supporting such as application needs to be L4 aware or act as a proxy for the end-host. Intrusion detection is another type of application that requires passive access to the end-user application payload for the purpose of inspection without modifying the content. Other type of applications may exist for various customer requirements. The previous type of applications can be more efficiently realized in OOP agents' scenarios. The realization scenarios may dictate different deployment situations in which OOP agents become more attractive choice than In-Path agents. For example, in mobile IP [MOBIP], NOTE: "discuss how mobile IP can be served with OOP agents from deployment perspective." This document extends the MIDCOM framework [MIDCOM] to support OOP agents. NOTE: " Present the Outline of this document". 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Below are the definitions for the terms used throughout the document. 3. Definitions This document assumes the definitions presented in [MIDCOM]. In addition to that it introduces and redefines the following. 3.1. MIDCOM Agents MIDCOM agents are entities performing ALG function, logically external to a middlebox. MIDCOM agents possess a combination of application awareness and knowledge of the middlebox function. A MIDCOM agent may communicate with one or more middleboxes. MIDCOM agents may be located either In-Path or Out-of-path of an application instance. In-Path MIDCOM agents are those in which the MIDCOM agent function is co-resident on devices that are naturally within the message path of the application they are associated with. This may be an application proxy, gateway, or in the extreme case, one of the end-hosts, that is party to the application. Out-of-Path (OOP) MIDCOM agents are those that are not necessarily resident (or co-resident) on entities that are natively in the path of application flows. Penno et al. [Page 3] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 4. OOP Agents and MIDCOM Architecture 4.1 In-Path Agents in the MIDCOM Framework The MIDCOM framework assumes that one or more services can be supported on a middlebox on multiple interfaces of the device. A variety of agents can communicate with the middlebox using the MIDCOM protocol interface and interact with one or more of the middlebox functions. This requires selective communication support on part of the middlebox platform for the implemented services. 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 agent | | MIDCOM agent | | Stand-alone | | co-resident on| | co-resident | | MIDCOM agent| | Proxy Server | | on Appl. GW | | (OOP Agent) | +---------------+ +--------------+ +-------------+ ^ ^ ^ | | | +--------+ | | MIDCOM | | Policy | | | Protocol | +-| Server | | | | / +--------+ +-------------+ | | | / | MIDCOM agent| | | | / | co-resident | | | | / | on End-hosts|<-+ | | | / +-------------+ | | | | | v v v v v +-------------------------------------------+ | Middlebox Communication |Policy | | Protocol (MIDCOM) Interface |Interface | +----------+--------+-----------+-----------+ Middlebox | | | | | Functions | Firewall | NAT | DiffServ- | Intrusion | | | | QOS | Detection | +----------+--------+-----------+-----------+ Middlebox | Firewall ACLs, Session-descriptors, | Managed | NAT-BINDs, NAT Address-Maps and other | Resources | Middlebox function specific attributes | +-------------------------------------------+ Figure 1: MIDCOM agents interfacing with a middlebox When In-Path agents are assumed, they intercept the signaling streams in applications where separate control and data sessions exist such as H.323, SIP and RTSP. This allows agents to play a native role in the path of the application traversal. Penno et al. [Page 4] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 When the middlebox requires the assistance for a particular application, it is possible that one or more agents will be required to intervene in coordination with the services offered by the middlebox. When In-Path agents are used they can be application proxies or ALGs. Such a decision depends on the type of application as well the type of service supported by the middlebox. For example, SIP proxies and H.323 gatekeepers may be used to host MIDCOM agent function to control middleboxes implementing firewall and NAT functions. Figure 2 below illustrates a scenario where the in-path MIDCOM agents interface with the middlebox. 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. +-----------+ | Middlebox | | Policy | | Server |~~~~~~~~~~~~~| +-----------+ \ \ +--------+ \ | SIP |___ \ ________| Proxy | \ Middlebox \ / +--------+.. | +--------------------+ | : | MIDCOM | | | | RSTP +---------+ :..|........| MIDCOM | POLICY | SIP | ____| RSTP |.....|........| PROTOCOL | INTER- | | / | Proxy |___ | | INTERFACE | FACE | | | +---------+ \ \ |--------------------| | | \ \-----| | | | \-------| | | | ---| FIREWALL |-->-- +-----------+ /---| |--<-- +-----------+| Data streams // +--------------------+ +-----------+||---------->----// | |end-hosts ||-----------<----- . +-----------+ (RTP, RSTP data, etc.) | . Outside the Within a private domain | private domain Legend: ---- Application data path datagrams ____ Application control path datagrams .... Middlebox Communication Protocol (MIDCOM) ~~~~ MIDCOM Policy Server Interface | . private domain Boundary | Penno et al. [Page 5] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 Figure 2: In-Path MIDCOM Agents for Middlebox Communication 4.2. Out-of-Path MIDCOM agents Extension to the MIDCOM Framework OOP agents are entities that are not natively in the transport path of an application. OOP Agents have a role in the application traversal, only by virtue of their MIDCOM function. No native role otherwise. There is a significant difference between in-path agents and OOP agents in the way the middlebox directs application specific traffic for processing by the agents. During connection establishment, an agent would identify itself as either In-Path, Out-Of-Path or both to the middlebox. Consequently, the middlebox should identify what type of agent it can support. This may require exchange of profile information during the registration process. When an agent is naturally in the transport path of the application (as is the case with an In-Path MIDCOM agent), there is no additional effort required of the middlebox in redirecting the application traffic. The middlebox cannot assume the same with an OOP agent and hence will need to explicitly redirect datagrams to the agent. The OOP agent should in turn be capable of returning the processed traffic to the middlebox point of origin or forwarding to the destination. It is possible that the application implemented by the OOP agent does not require the traffic to be returned to the middlebox. In the case the agent is both In-Path and OOP capable, it could use a mix of diversion requests and native processing to manipulate the packets it needs. In essence, a middlebox provides to an OOP agent the ability to transparently examine and modify selected traffic. It is reasonable to further classify OOP agents into those which modify control traffic, and those which do not. For example, if an OOP agent is used simply to manage firewall policy for SIP-based telephony, it is enough to forward SIP messages to the agent for examination. On the other hand, if the agent must also manage NAT bindings, the agent needs to modify the SIP messages, and re-inject them into the control path. Figure 3 below illustrates a scenario where the OOP agents interface with the middlebox. Penno et al. [Page 6] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 +-----------+ | Middlebox | | Policy | | Server |~~~~~~~~~~~~~| +-----------+ \ \ \ \ Middlebox \ +--------------------+ MIDCOM | | | +---------+...............| MIDCOM | POLICY | ___|MiddleBox|==>===\ | PROTOCOL | INTER- | / | Agent |=<== \ | INTERFACE | FACE | | +---------+ \ \ |--------------------| | \ \==>==| | | | \Diverted| Diversion | | | \Traffic| Function | | | \===<==| | | | |-----------| | | ---| Firewall | |-->-- +-----------+ Signalling and /---| | |--<-- +-----------+| Data streams // +--------------------+ +-----------+||---------->----// | |end-hosts ||-----------<----- . +-----------+ (SIP, 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 Policy Server Interface ==== Diverted Traffic | . private domain Boundary | Figure 3: Out-Of-Path MIDCOM Agents in the MIDCOM Framework Optionally the middlebox can make a copy of the datagrams it will redirect to the OOP agent and not expect the OOP agent to return the traffic. Such scenarios are useful for intrusion detection type of applications or middleboxes with wiretapping features. 4.2 OOP Applications What are these applications? Penno et al. [Page 7] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 4.3 MIDCOM Signaling What role does MIDCOM signaling play in the OOP operations? 4.4 Traffic Diversion In order to support OOP agents, the middlebox will require an additional "Datagram Divergence (DataDiv)" functional component. This function is strictly to support the Out-of-path MIDCOM agents and is independent of any middlebox service or application. Such a DataDiv function is also independent of the MIDCOM protocol, per se. However, the intrinsic details of its operation may be controlled by the MIDCOM protocol. The DataDiv function on the middlebox would be required to subject the traffic to the following processing. 1. When a datagram is received by the middlebox, the middlebox will subject the datagram to the standard middlebox services as appropriate. However, if the datagram is designated for diversion (i.e., the application specific MIDCOM agent is registered as OOP), the middlebox will redirect the datagram to the diversion target. Consequently, once the datagram has been directed to a particular agent, it gets processed accordingly. As such, this may be accomplished using some type of tunneling mechanism, API framework, or some other proprietary mechanism. Optionally the middlebox can make a copy of the datagram before it is redirected to the OOP agent. The middlebox might not require the return of the datagrams depending on the type of the application. 2. The recipient of the diverted datagram (i.e., the OOP agent) will examine and optionally modify the payload (as appropriate to the middlebox service) and does one of the following. (a) Send the processed datagram right back to the middlebox using the same diversion approach the middlebox used. (b) Forward the datagram to the appropriate destination (i.e., one of the end-hosts that is party to the application). This assumes that the OOP agent has routing/forwarding capability. (c) Through some sort of API or protocol signaling indicates which changes are needed in the packet. The middlebox then make the necessary changes on its copy of the datagram and forwards the packet to the appropriate destination Note : "I don't know how useful this approach is?" Penno et al. [Page 8] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 (d) Apply specific function on the diverted traffic which does not include (a), (b) or (c). The middlebox might not need to wait on the traffic return in order to forward the datagrams to their destination in this case. 3. When the middlebox receives a diverted (i.e., co-processed) datagram from the OOP agent, the middlebox will simply forward the processed datagram to the appropriate destination (i.e., one of the end-hosts that is party to the application. Figure 4 below is an illustration of a scenario where OOP agents interface with the middlebox. The middlebox is assumed to implement firewall service. The OOP agents are presumably pre-configured as trusted MIDCOM agents on the middlebox and the packet filtering implements 'default-deny' packet filtering policy. The OOP agents register themselves as the divereted traffic targets for the applications they support. They examine the payload of the diverted traffic and use application-awareness knowledge to control the firewall function and selectively permit a certain number application sessions dynamically using the MIDCOM protocol. Penno et al. [Page 9] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 +---------+ Examined ftp-control traffic | FTP OOP |============>=============================\ | Agent |++++++++++++<++++++++++++++++++++++++++++ || | | Diverted ftp-control traffic + || +---------+ + || : + || : +----------+ Examined SIP traffic + || : | SIP OOP |=========>===============\ + || : | Agent |+++++++++<++++++++++++++ || + || : | | Diverted SIP traffic + || + || : +----------+ + || + || : : + || + || : : +-----------+ + || + || : : | Middlebox | + || + || : : | Policy |~~~~~| + || + || : : | Server | \ + || + || : : +-----------+ \ + || + || : : \ + || + || : :.............. \ + || + || : MIDCOM : \ + || + || :................. : \ + || + || : : \ + || + || +-----------+-----------+-----------+ | | | | | MIDCOM | POLICY | DATAGRAM | | PROTOCOL | INTERFACE | DIVERSION | | INTERFACE | | INTERFACE | +------------+ +-----------+-----------+-----------+ +------------+|------>----| FIREWALL |->- +------------+||------<----| |-<- |end-hosts || Ctrl +Data +-----------------------------------+ +------------+ (SIP, RTP, FTP-CTRL, | FTP-Data, etc.) . | Within a private domain . Outside the | private domain Legend: ---- Application data & control path datagrams .... Middlebox Communication Protocol (MIDCOM) ~~~~ MIDCOM Policy Server Interface ++++ Control traffic diverted To a MIDCOM agent ==== Examined and optionally modified application specific control traffic returning FROM the Out-of- Path agent | . private domain Boundary | Figure 4: Illustrations for OOP agents Penno et al. [Page 10] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 4.5 MIDCOM framework illustration with an OOP FTP Agent In Figure 5, an FTP client inside a private domain connects via a middlebox to an external FTP server. The middlebox is assumed to implement NAPT and firewall functions. The FTP traffic is addressed directly to the external FTP server. The Arrow labeled 1 indicates a registration via the MIDCOM protocol in which the OOP FTP agent indicates that it would like to receive TCP traffic directed to or from port 21 (FTP control). The OOP agent may be located either inside the private domain or external to the domain. The FTP control traffic traversing the middlebox is diverted by the middlebox to the OOP FTP agent for FTP control payload processing. Diverted control traffic is indicated by Arrow 2. The OOP agent parses the FTP control commands and responses and possibly modifies, as appropriate and forwards the traffic over to the server and/or the client. Neither of the end-hosts is aware of the OOP Agent or the middlebox in transit. At some point, the Client sends a PORT command to the Server, indicating that the Server should create a TCP connection from the Server to the Client. This port command specifies an IP address and port number to which the Server should connect. The IP address may be a private IP address, if the client is located in a privately addressed domain. The OOP agent parses the PORT command, and carries out appropriate MIDCOM transactions (Arrow 4) to discover any changes to the IP address required, to request a new NAPT port binding if necessary, and to open a suitable pinhole allowing the connection from the Server to the dynamically allocated port number on the Client to succeed. The (perhaps modified) PORT command is then sent on to the Server, which responds by connecting to the indicated IP address and port, which will now flow through the middlebox to the Client. The example does not show the timers maintained by the agent to keep the firewall pinholes and NAT session descriptors and BINDs from timing out. Readers are urged to refer [NAT-FRAMEWORK] for a detailed illustration of how an OOP agent could interface with the NAT-only middlebox. Penno et al. [Page 11] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 +-----------+ | OOP FTP | | Agent | +-----------+ | ^ | | | | | | |1 |2 |3 |4 +------------+ | | | | +------------+ | | _v__|__v__v_ | | | FTP client | Ctrl | | Ctrl | External | | within the |<------->| MiddleBox |<------>| FTP Server | | Pvt. domain|<------->|___________|<------>| | |____________| Data Data |____________| Ctrl - indicates the FTP control traffic, which is transparently diverted to the OOP agent (2 and 3) Data - indicates the FTP data traffic, which flows directly through the middlebox between the FTP end hosts (i.e., FTP client and Server) Figure 5: MIDCOM framework illustration Out-of-Path FTP agent 4.6 Timeline flows for OOP Agents This section discuses the timeline for a SIP flow in a middlebox implementing 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. The INVITE from the caller (external) is assumed to include the SDP payload. You will note that the OOP 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. Penno et al. [Page 12] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 SIP Phone Middlebox SIP Proxy SIP Phone (External) (FIREWALL (OOP MIDCOM (private) Service) agent) | | | | | |----INVITE------>| | | | | | | | |~~~Diverts Traffic~~~>| | | | | | | | | | | | Identify end-2-end | | | parameters (from Caller's | | | SDP) for the pri-to-Ext | | | RTP & RTCP sessions. | | | (RTP1, RTCP1) | | | | | | |<+Permit RTP1, RTCP1+ | | | | | | |<---100Trying---------------------------| | | | | | | |<----------------180 Ringing---------| | | | | | |~~~Diverts Traffic~~~>| | | | | | |<--180Ringing---------------------------| | | | | | | |<----------------200 OK--------------| | | | | | |~~~Diverts Traffic~~~>| | | | | | | | Identify end-2-end | | | parameters (from callee's | | | SDP) for the Ext-to-Pri | | | RTP and RTCP sessions. | | | (RTP2, RTCP2) | | | | | | |<+Permit RTP2, RTCP2+ | | | | | | |<---------200 OK -----------------------| | | | | | |-------ACK------>| | | | | | | | |~~~Diverts Traffic~~~>| | | | | | | | |-----ACK----->| | | | | |<===================RTP/RTCP==========================>| | | | | |-------BYE------>| | | | | | | | |~~~Diverts Traffic~~~>| | Penno et al. [Page 13] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 | | | | | | |---BYE------->| | | | | | |<----------200 OK--------------------| | | | | | |~~~Diverts Traffic~~~>| | | | | | | |<+++Cancel permits to | | | | RTP1, RTCP1, RTP2, | | | | and RTCP2 <+++++++++| | | | | | |<---200 OK-------| | | | | | | Legend: ++++ MIDCOM control traffic ---- SIP control traffic ==== RTP/RTCP media traffic ~~~~ Diverted Traffic 4.7 Timeline Flow - Middlebox implementing NAPT and Firewall In the following figure, an end-host inside the private network at address(pa) 10.0.0.4 wishes to communicate with an external FTP server with an IP address Ea. The Middlebox provides public IP address(Ma) 209.46.41.66 for external communication by private hosts. The middlebox diverts the FTP control traffic to the OOP agent. The OOP agent, in turn, reviews the datagrams and optionally modify as appropriate and redirects the datagrams right back to the middlebox. The OOP agent may need to update even the TCP SYNs and ACKs (i.e., datagrams with no application specific payload) in the event the agent had to rewrite the address content in the payload and the payload length changed as a result. FTP-client OOP FTP Middlebox (NAPT & FTP Server (Private) Agent Firewall Services) (External) IP addr(Pa): | IP addr(Ma): IP addr: Ea 10.0.0.4 | 209.46.41.66 | | | | | | | | | | |++Attach as FTP ALG+++>| | | | | | | |<+++++ OK +++++++++++++| | | | | | | The OOP FTP Agent attaches with middlebox & | | is authorized to process FTP control | | traffic from private hosts (or any set | | of hosts adhering to a certain policy) | | | | | Penno et al. [Page 14] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 | | | | The FTP client connects to the external FTP server. The middlebox would have created a NAT Port-BIND and an FTP control session resource with the appropriate translation parameters. | | | | | PORT 10,0,0,4,4,9 | | |--------------------------------------| | | | | | | |<## Ctrl-Pkt diverted #| | | | | | | |++Query NAT Session | | | | Descriptor for | | | | Pa-to-Ea FTP flow+++>| | | | | | | |<+Pa-to-Ea FTP flow | | | | Session Descriptor+++| | | | | | | |++Create NAT port-BIND | | | | for (Pa, 1033) +++++>| | | | | | | |<+Port BINDs created | | | | with (Ma, 15324)+++++| | | | | | | |++Create NAT Session | | | | descriptor for the | | | | Data session from Ea | | | | to (Ma, 15324);Set | | | | Parent session to | | | | FTP-Ctrl session +++>| | | | | | | |<+FTP-Data session | | | | descriptor created+++| | | | | | | |++Permit FTP data | | | | session from Ea to | | | | (Ma, 15324)+++++++++>| | | | | | | |<+Data session OKed++++| | | | | | | |### Modified Control | | | | Pkt forwarded #######################>| | | | | |<===FTP Data traffic between Pa & Ea==|=================>| | | | | | | | | Legend: ++++ MIDCOM control traffic ##### Diverted datagrams ---- FTP control traffic ==== FTP data traffic Penno et al. [Page 15] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 The above flow does not indicate all packets as diverted, only the important ones (e.g. the datagram with the PORT command in the payload). It is safe to assume that all control packets are diverted from the middlebox to the OOP Agent via the datagram diversion component of the middlebox. Note that the FTP data traffic is not diverted to the OOP Agent. This is because the OOP agent does not assign a diversion function associated with the data session while at the instance creating the FTP-Data session. This is an essential feature, since we allow the middlebox to move the data about, while the Agent intervention is limited just to the control session. 5. OOP Protocol Interfaces 5.1 Protocol candidate solutions 5.2 API Alternative 6. Policy Server Issues Authentication and confidentiality issues. Registration and De-Registration OOP-Application profiles 7. OOP Agents Interface Functional Requirements This section covers extensions to the functions of the midcom protocol itself, the diversion protocol/mechanism, and other functions the agent and middlebox must perform to support OOP agents. 7.1 MIDCOM OOP Functional Requirements A minor extension is required to the midcom protocol itself to support OOP agents. Specifically, the OOP agent must be able to request diversion to itself of certain packets. The midcom protocol is extended to allow the agent to request an additional type of action for packets matching a particular session-descriptor. That action is: divert to me, tagged with agent handle A corresponding extension is required to the midcom authorization policy model, to support specification of what packet diversions a given agent is authorized to request. Penno et al. [Page 16] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 In the middlebox, packets matching a session-descriptor that requests a diversion action will be diverted to the agent along with context-identifying handles assigned by both the agent and the middlebox. If the middlebox requires that the packet be returned to it for reintroduction, it may so indicate. The middlebox encapsulates the selected packets in the diversion protocol and sends them to the agent. In the agent, diverted packets are decapsulated and delivered to the appropriate ALG function of the agent. The agent may use the middlebox IP address and/or the agent-assigned handle for context in determining how to process each packet. Packets to be returned to the middlebox after processing by the agent are re-encapsulated in the diversion protocol and sent back to the middlebox with the middlebox-assigned handle. In the middlebox, the reintroduced packets are decapsulated from the diversion protocol. The middlebox may use the agent IP address and/or the middlebox-assigned handle to recover relevant context for processing the packet. The middlebox may apply additional services to the packets, which are then forwarded towards their destinations. The TTL field of each diverted packet must be decremented by the device that ultimately forwards it -- the agent when it forwards the packet directly, or the middlebox when packets are returned to it for forwarding. 7.2 Traffic Diversion Protocol Functional Requirements The traffic diversion protocol must be able to carry packets from the middlebox to a requesting OOP agent and back. It must satisfy the following requirements: a) Must support locating agents more than one IP hop away from the middlebox b) Must be able to handle packets with non-unique (private) addressing c) Must allow the receiver to unambiguously determine that the packets are midcom OOP diversion/reintroduction packets and not normal received IP packets d) Must provide for carrying additional information, besides the diverted IP packet itself e) Must be readily able to be implemented within a wide variety of agent and middlebox architectures Penno et al. [Page 17] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 The following are specifically not requirements for the diversion protocol. These non-requirements are motivated by the observation that there is no need for packets on the diversion loop to enjoy a level of service or security superior to that they are being given by the network as a whole. a) In-order or reliable packet delivery b) Flow control c) Confidentiality or data integrity Along with each diverted packet the following additional information needs to be carried: a) An indication of whether the agent may forward the packet directly towards the destination, or whether it must return it to the middlebox for reintroduction. b) A handle assigned by the OOP agent at the time it requests diversion of packets matching a particular session-descriptor. This handle is opaque to the middlebox and must be delivered unmodified to the agent with each packet diverted under the associated session-descriptor. It may identify the context for the agent's processing of the packet. c) A handle assigned by the middlebox. This handle is opaque to the agent and must be returned unmodified to the middlebox if the packet is reintroduced through the middlebox. It may identify any middlebox context associated with the particular packet. The selected diversion protocol that meets the above requirements is UDP [RFC768]. A midcom diversion header is prepended to each packet, and the result is then encapsulated in a UDP/IP datagram. This approach is simple, efficient, and meets the requirements stated above. The source and destination IP addresses used by the middlebox and the midcom agent for the diversion tunnel MUST be the same addresses each party uses on their associated midcom protocol session (the session via which the diversion was requested by the agent). The Registered port number SHOULD be used as the UDP destination port for both to-OOP-agent diverted packets and to-middlebox returned packets. The source port is not important and SHOULD be set to 0. The sender SHOULD compute and set the UDP Checksum. The receiver SHOULD verify the UDP Checksum if it is nonzero. The midcom diversion header consists of 12 octets formatted as follows Penno et al. [Page 18] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|D| Reserved | Ver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Middlebox Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Return To Middlebox (R) bit when set by the middlebox indicates that the packet MUST be returned to the middlebox for reintroduction (or the agent MAY drop it). It MUST be set to 0 for messages sent from agent to middlebox. The Direction (D) bit is set to 1 for messages from middlebox to agent and set to 0 for messages from agent to middlebox. The Reserved field MUST be set to 0 by the sender and ignored by the receiver. The Version (Ver) field MUST be set to 1 indicating the version of the diversion header described by this document. The Agent Handle is a 32 bit identifier assigned by the agent at the time it requests diversion of certain packets. The contents of this field are undefined in messages sent from the agent to the middlebox. The Middlebox Handle is a 32 bit identifier assigned by the middlebox at the time it diverts the packet. The value sent to the agent with a particular packet MUST be returned unmodified by the agent when/if the agent returns the packet to the middlebox. Diverted packets may require IP fragmentation. If fragmented, they are necessarily reassembled by the receiving agent or middlebox. The addition of the diversion encapsulation may tend to push datagrams past common MTU values. However, typically it will be control packets that will be diverted and these should generally tend to be substantially smaller than popular MTU sizes. The DF (Do not Fragment) bit SHOULD NOT be set in the outer IP header carrying the diverted header, as doing so could systematically drop diverted packets with no feedback to the sender. 8. Operational Consderations During connection establishment between an agent and a middlebox, the agent identifies itself as in-path (or) Out-of-Path. Penno et al. [Page 19] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 The middlebox takes no additional action to redirect a packet, if the agent is in-path. If the agent is Out-of-Path, the middlebox will be required to have a datagram diverter function that diverts datagrams to the out-of-path agent. The datagram diverter function on a middlebox, however, is not a requirement when the middlebox chooses not to support OOP agents. The OOP agent should be capable of returning processed datagrams to the middlebox point of origin or forward to the destination. The middlebox should in turn forward the processed datagrams without subjecting to any middlebox services the second time around. I.e., A datagram should not be diverted back to the OOP agent the second time around. Failing this, the datagram could simply recycle between the two entities. The datagram diverter function is an internal implementation issue for the middlebox and is unrelated to the MIDCOM protocol. One approach to datagram diversion might be to encapsulate datagrams (both diverted and processed) in a tunnel during traversal between the agent and the middlebox. Another approach might be to dedicate an interface on the middlebox for the purpose. There may be other proprietary approaches. 9. Security Considerations [TBD] 10. References [MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "Middlebox Communication Architecture and framework", draft-ietf-midcom-framework-03.txt, work in progress. [MIDREQ] P Swale, P A Mart, P Sijben, "Middlebox Control (MIDCOM) Protocol Architecture and Requirements" draft-ietf-midcom- requirements-01.txt, work in pogress. [IETF-STD] Bradner, S., " The Internet Standards Process -- Revision 3", RFC 1602, IETF, October 1996. [SIP] Handley, M., H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF, March 1999. [SDP] Handley, M., and Jacobson, V., "SDP: session description protocol", RFC 2327, IETF, April 1998. [H.323] ITU-T Recommendation H.323. "Packet-based Multimedia Communications Systems," 1998. Penno et al. [Page 20] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 [RTP] Schulzrinne, H., S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, IETF, January 1996. [RTSP] Schulzrinne, H., A. Rao, R. Lanphier: "Real Time Streaming Protocol", RFC 2326, IETF, April 1998. [FTP] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", RFC 959 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [NAT-TRAD] Srisuresh, P. and Egevang, K., "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [NAT-COMP] Holdrege, M. and Srisuresh, P., "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [NAT-PT] Tsirtsis, G. and Srisuresh, P., "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, [APPL-ID] Bernet, Y. and Pabbati, R., "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000. [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 [IPsec-AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [IPsec-ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January 1999. Author's Addresses Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com Penno et al. [Page 21] Internet-Draft draft-ietf-midcom-oop-00.txt August 2001 Mark Duffy Quarry Technologies 8 New England Executive Park Burlington, MA 01803 mduffy@quarrytech.com Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. 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.