MIDCOM Working Group R P Swale Internet Draft BTexact Technologies Document: draft-ietf-midcom-requirements-02.txt P A Mart Expires: January 2002 Marconi Communications Category: draft P Sijben Lucent Technologies July 2001 Middlebox Control (MIDCOM) Protocol Architecture and Requirements < draft-ietf-MIDCOM-requirements-02.txt > 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 Networks connecting to and forming part of the Internet are increasingly deploying specialised network functions to address security, quality of service and other administrative policy requirements. These devices are a subset of what can be referred to as 'Middleboxes'. While certain applications may operate unaffected in this environment, other types of application - or certain operational scenarios of a given application - may either fail to work completely or malfunction in some way. These classes of session- oriented application are typified by the use of separated data transfer and control sessions. Existing solutions to these problems deploy application specific intelligence within individual Middleboxes. However this leads to many difficulties including poor scalability of the solution and problems in reusing generic Middlebox functionality. In addition, trusted third parties are also increasingly being asked to make such policy decisions on behalf of the various entities participating in an application's operation. A need has therefore emerged for session-orientated applications to be able to express their communications needs to the devices in the Swale et al Expires November 2001 1 MIDCOM Requirements July 2001 network that provide enforcement of transport policy. This document therefore focuses on the requirements for the protocol between the requesting device and the Middlebox and any associated policy entity. It is desirable that existing IETF protocols be used to implement these requirements where practical to do so. Table of Contents 1. Introduction.............................................3 1.1. Background...............................................3 1.2. Scope....................................................4 2. Terminology..............................................4 3. Definitions..............................................5 4. Specific functions assumed...............................5 4.1. Middlebox functions......................................5 4.2. MIDCOM Agent functions...................................6 4.3. Policy Server functions..................................6 4.4. Distribution of MIDCOM elements..........................6 5. Functional Requirements..................................7 5.1. Pin-Hole specification...................................7 5.1.1. Connectivity specification...............................7 5.1.2. Flow profile specification...............................7 5.2. Pin-Hole identification..................................8 5.3. Pin-Hole operations......................................8 5.3.1. Open Pin-Hole............................................8 5.3.2. Transfer Pin-Hole........................................8 5.3.3. Close Pin-Hole...........................................8 5.3.4. Pin-Hole Report..........................................9 5.3.5. Pin-Hole Refresh.........................................9 5.3.6. Error handling...........................................9 5.4. Asynchronous behaviour...................................9 6. Non-functional requirements..............................9 6.1. Extensibility............................................9 6.2. Reliability.............................................10 6.3. Resilience..............................................10 6.4. Scalability.............................................10 6.5. Performance.............................................10 6.6. Management..............................................11 6.6.1. Status reporting........................................11 6.6.2. Unsolicited messages....................................11 6.6.3. Protocol Failure........................................11 6.7. Security................................................11 6.7.1. Registration and Authorisation..........................11 6.7.1.1. Deregistration..........................................12 6.7.1.2. Error handling..........................................12 6.7.2. MIDCOM Authentication Requirements......................12 6.7.3. MIDCOM Protocol communications..........................12 6.7.4. MIDCOM Protocol transport...............................12 6.7.5. General Security considerations.........................13 Swale et al Expires November 2001 2 MIDCOM Requirements July 2001 7. Issues..................................................13 8. Copyright...............................................14 9. Intellectual Property...................................14 10. Acknowledgements........................................15 11. References..............................................15 12. Author's Addresses......................................15 1. Introduction A need has emerged for session-orientated applications to be able to express and communicate their needs for communications to devices in the network that provide, or represent, enforcement of transport policy. Examples of these devices include: - firewalls, - network address translators, - intrusion detection systems (e.g. signature management) These devices are a subset of what can be referred to as 'Middleboxes'. To enable the end-to-end operation of session- orientated applications in this environment, trusted third parties have become required to make policy decisions on behalf of the various entities participating in an application's operation. This document focuses on the requirements for the protocol between the requesting device and the Middlebox and any associated policy entity. It is desirable that existing IETF protocols be used to implement these requirements where practical to do so. 1.1. Background For a variety of reasons, Middlebox devices effectively delineate domains of administrative policy. Such policies may include translation of IP addresses (e.g. NAT) or admission control (e.g. firewalling). Examples of this are where a firewall may be used to delineate the security policy of an end user's LAN from a service provider's wide area network link to the Internet. While certain applications may operate unaffected in this environment, other types of application - or certain scenarios of a specific application - may either fail to work completely or malfunction in some way. Some of these examples are illustrated in [MIDBOXFRAME]. Session orientated applications represent an example of one class of application that encounters deployment difficulties in networks involving Middleboxes. This is because there are implicit relationships between individual packets that must be maintained between hosts across the network. One solution that has emerged to this problem has been to develop proprietary extensions (known as an Application Level Gateway) for a given Middlebox that enable it to handle a specific application. Unfortunately while this works for a small set of simple applications, it does not scale well. Neither can this approach easily handle increasingly complex scenarios such Swale et al Expires November 2001 3 MIDCOM Requirements July 2001 as those associated with multimedia applications. This is because these typically involve a multiplicity of media and control streams that originate from a single host but may have individual packet streams terminating on a diverse set of hosts. Trusted third parties are therefore increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation. Consequently a need has developed for applications to be able to express their needs to the devices in the network providing transport policy enforcement. Decomposing applications requiring policy decisions by removing application logic from the Middlebox and instead providing a generalized communications interface (by use of the "MIDCOM Protocol") provides a number of benefits, including:- - improved performance, - lower hardware and software development costs - lower maintenance costs, - improved ability to support traversal of packet filters by complex protocols, - easier deployment of new applications, and - the ability to consolidate management functions. For example, by moving stateful inspection of protocols such as H.323 and SIP out of firewalls, it is possible to improve performance and scalability while reducing development time and costs. 1.2. Scope This document presents a discussion of requirements for the MIDCOM Protocol. The network environment envisaged for MIDCOM includes one or more Middleboxes in the data path between communicating clients, servers or peers as described in [MIDBOXFRAME]. This document will only deal with needs arising from the use of firewalls and network address translation although the solution must enable extension to encompass other types of device in the future. This document may form the basis of subsequent protocol development or the development of profiles of existing protocols. The discovery of Middleboxes in the path of an application instance and communications between Middleboxes is outside the scope of the MIDCOM Protocol and consequently this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Swale et al Expires November 2001 4 MIDCOM Requirements July 2001 The terminology describing Middleboxes used in this document is introduced in [MIDBOXFRAME]. 3. Definitions Flow a sequence of IP packets communicated from one host and port to another host and port. Pin-Hole An association established across a Middlebox enabling a flow to be established that would otherwise have been prevented by normal or default behaviour of the Middlebox. 4. Specific functions assumed The MIDCOM environment [MIDBOXFRAME] involves three main entities; the Middlebox, the MIDCOM Agent and the Policy Server as shown in figure 1. The following functionality is assumed within these components from the view point of the MIDCOM Protocol. +-----------+ +---------------+ | MIDCOM | | Policy | | Agent | | Server | +-----------+ +---------------+ ^ ^ | MIDCOM | Policy protocol | Protocol | | | | | | | v v +----------+ +-----------------------------+ +---------+ | End | | Middlebox | | End | | Host |<------->| Device |<----->| Host | +----------+ +-----------------------------+ +---------+ Figure 1. The MIDCOM Protocol and Environment 4.1. Middlebox functions As described in [MIDBOXFRAME], a Middlebox may provide a number of processing functions for IP packets traversing it. Essentially, a Middlebox forwards packets from one of its physical interfaces to another. In doing so it may manipulate the headers of IP packets as requested by a MIDCOM Agent. However the Middlebox must not alter packet information unless it appears in the packet header. This is to ensure that there is an appropriate separation of concerns between the MIDCOM Agent and the Middlebox. It is assumed that the functions provided by a Middlebox are externalised from a control point of view to a MIDCOM Agent through the use of protocol(s) meeting the requirements of the MIDCOM Protocol. Swale et al Expires November 2001 5 MIDCOM Requirements July 2001 A Middlebox may establish whether the association with a specific MIDCOM Agent should be allowed via a Policy Server. The Middlebox may also communicate with a Policy Server to determine whether the actions requested by a specific MICOM Agent are permissible. 4.2. MIDCOM Agent functions A MIDCOM Agent, as described in [MIDBOXFRAME], embodies application specific intelligence external to a Middlebox. In conjunction with an associated Middlebox, a MIDCOM Agent enables specified end-to-end flows between application clients and/or servers in accordance with the needs of the application in question. Control information is passed between a MIDCOM Agent and associated Middlebox by the protocol(s) meeting the requirements of the MIDCOM Protocol. 4.3. Policy Server functions The MIDCOM environment allows for a Policy Server function to externalise policy decisions from a Middlebox. A Policy Server is a management entity interfacing with Middlebox functions to establish policies concerning authorization of MIDCOM Agents requesting access to the Middlebox and its resources. Its purpose may determine the flows supported across one or more Middleboxes. A MIDCOM Agent may have a pre-configured relationship with a given Middlebox as a trusted entity or the trust relationship may be established dynamically. In the case where a MIDCOM Agent is not pre-configured, the Middlebox will need to consult a Policy Server to validate requests from the agent. A policy server may add or remove the registration of individual MIDCOM Agents registered onto a Middlebox. The protocol facilitating the communication between a Middlebox and a Policy Server need not be part of the MIDCOM Protocol. 4.4. Distribution of MIDCOM elements To enable the solution to scale, it must be possible for the functional components within the MIDCOM framework to be distributed. The Middlebox therefore needs to support multiple simultaneous MIDCOM Agents. Each Agent may be acting on behalf of one or more applications. There is no implicit relationship between individual MIDCOM Agents and a specific Middlebox should not therefore assume any relationship between any given set of MIDCOM Agents. Swale et al Expires November 2001 6 MIDCOM Requirements July 2001 5. Functional Requirements The MIDCOM Protocol needs to enable a MIDCOM Agent requiring the services of a Middlebox to establish an association between itself and the Middlebox for the purposes of requesting Pin-Hole services from the Middlebox and obtaining statistics and other reporting information. The syntax and semantics of the MIDCOM Protocol shall be independent of the application(s)requesting Middlebox services. 5.1. Pin-Hole specification To enable a Middlebox to reliably establish a Pin-Hole at the request of a MIDCOM Agent, the MIDCOM Protocol must allow the MIDCOM Agent to express the nature of the Pin-Hole required to the Middlebox. The MIDCOM Protocol must therefore allow the MIDCOM Agent to describe the desired behaviour of the Middlebox for the purposes of requested flow(s). Two aspects of a flow have been identified as being necessary to specify the characteristics required; the addressing association required and the packet flow characteristics. 5.1.1. Connectivity specification The MIDCOM Protocol must allow a MIDCOM Agent to specify a Pin-Hole in terms of the address and port mappings required. The protocol shall permit the expression of direction to be associated with a Pin-Hole. The direction shall be specified in terms that apply to external view of the Middlebox. This directionality shall be expressed as "in", "out" or "Loopback" (meaning both "in" and "out" of the same side of the same Middlebox realm). 5.1.2. Flow profile specification To enable real-time streamed media to be supported, the MIDCOM Protocol must allow a MIDCOM Agent to specify a Pin-Hole in terms of the packet size and flow rate which is required. The requests communicated between a MIDCOM Agent and a Middlebox need to permit Pin-Holes to be specified in terms of packet size (maximum and minimum length, inter-packet arrival time and other parameters including: For IPv4: source and destination IP address or group of them determined by a netmask, protocol number, DSCP field For IPv6: source and destination IP address or group of them determined by a netmask, next header fields (Note: multiple fields may need to be Swale et al Expires November 2001 7 MIDCOM Requirements July 2001 traversed until a match is found) and traffic class field UDP: source and destination port numbers or group of them TCP: source and destination port numbers or group of them, "SYN packets" permission ICMP: type and code IGMP: type It shall be possible to indicate whether packets should be carried or discarded when a given flow specification is exceeded. 5.2. Pin-Hole identification The MIDCOM Protocol must enable a given MIDCOM Agent and Middlebox to identify and reference in a common manner any Pin-Holes for which they share a relationship. The MIDCOM Protocol must enable a Middlebox to be able to relate flows across it to requests for Pin-Holes from specific MIDCOM Agents. The MIDCOM Protocol should support the concept of an aggregated Pinhole-Descriptor comprising a multiple of individual flows allowing them to be treated as an aggregate. 5.3. Pin-Hole operations 5.3.1. Open Pin-Hole An operation is needed to enable a MIDCOM Agent to request a flow, with a given flow specification and address translation, across a given Middlebox. A MIDCOM Agent that requests a flow to be established maintains ownership of the request for the duration of the flow, or until such time as the MIDCOM Agent relinquishes or delegates ownership. 5.3.2. Transfer Pin-Hole The MIDCOM Protocol must allow the ownership of a requested flow to be transferred from one MIDCOM Agent to another. In doing so the Middlebox may need to act as a mediation point for affecting the transfer of ownership. This is necessary for a variety of reasons including scalability of the solution. 5.3.3. Close Pin-Hole An operation is needed to enable a MIDCOM Agent to request a flow be closed that it has either established or assumed a position of ownership over. Swale et al Expires November 2001 8 MIDCOM Requirements July 2001 Resources, such as a Pin-Hole Identifier, may be shared across MIDCOM Agents and a Middlebox. As Pin-Holes may be shared across Middlebox functions, a Pinhole-Descriptor may be created by one function, and terminated by a different one. A Pin-Hole may be closed such that ICMP reporting for subsequently discarded packets is either enabled or disabled. 5.3.4. Pin-Hole Report An operation is needed to enable a MIDCOM Agent to request a status report concerning a flow that it has either established or assumed a position of ownership over. The Middlebox may need to report information concerning the status and behaviour of a flow through an established Pin-Hole to the associated MIDCOM Agent that owns it. 5.3.5. Pin-Hole Refresh An operation is needed to enable a MIDCOM Agent to request that a Middlebox maintain an established Pin-Hole over which the Agent has ownership. 5.3.6. Error handling Where the communication relationship between a Middlebox and a MIDCOM Agent becomes invalid, all existing Pin-Holes owned by the MIDCOM Agent concerned must be closed. The MIDCOM Protocol must allow the MIDCOM Agent access to sufficient information as to enable it to notify the application when a Pin- Hole has become invalid. 5.4. Asynchronous behaviour Since Middleboxes and MIDCOM Agent(s) are likely to operate asynchronously, the protocol needs to permit the synchronisation of state machines between peer entities by adding state information to messages in normal operations or by the use of explicit query messages. Either the agent or the Middlebox can choose to initiate a connection prior to any data traffic. Alternately, either party (Middlebox or the MIDCOM Agent) may choose to initiate a connection only upon noticing application specific traffic. 6. Non-functional requirements 6.1. Extensibility Swale et al Expires November 2001 9 MIDCOM Requirements July 2001 The MIDCOM Protocol must be extensible to allow for both version upgrades to the protocol itself and the expansion of functionality available to MIDCOM Agents from Middleboxes. The syntax and semantics of the MIDCOM Protocol need to be extensible to allow the requirements of future applications to be adopted. The MIDCOM Protocol needs to contain version inter-working capabilities to enable subsequent extensions to support different types of Middlebox and future requirements of applications not considered at this stage. If a peer does not understand an option it must be clear whether the action required is to proceed without the unknown attribute being taken into account or the request is to be rejected. Where attributes may be ignored if not understood, a means may be provided to inform the client about what has been ignored. This may be provided as a version and capability exchange mechanism. 6.2. Reliability Where a multiplicity of MIDCOM Agents are interacting with a given Middlebox, the MIDCOM Protocol must provide mechanisms ensuring that the overall behaviour is deterministic. The MIDCOM Protocol must enable the Middlebox and any associated MIDCOM Agents to establish known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released. The protocol needs to provide per message acknowledgements, in order to achieve reliable communication. 6.3. Resilience The MIDCOM Protocol must be able to operate in an extended network environment between the MIDCOM Agent and the Middlebox that may be susceptible to the loss of packets. 6.4. Scalability The MIDCOM Protocol must scale to cope with the requirements of various sizes and types of Middlebox. From a physical point of view, these may range from single and dual port devices through to large- scale multi-port devices. The MIDCOM Protocol may allow a multiplicity of MIDCOM Agents to concurrently interact with a given Middlebox. 6.5. Performance Swale et al Expires November 2001 10 MIDCOM Requirements July 2001 The MIDCOM Protocol must not inhibit the deployment of real-time communication applications in a Middlebox environment. It therefore must exhibit low latency characteristics commensurate with the control of such applications. The MIDCOM Protocol should allow the aggregation of commands, requests and responses. The protocol needs to support time-constrained operation to enable scalability of the complete solution. This may include, amongst other things, the use of short messages and minimal messages per operation. The protocol must not assume 0 (zero) delay in communication paths to enable realistic deployment scenarios. The protocol must therefore be capable of being used over low speed links. 6.6. Management 6.6.1. Status reporting The MIDCOM Agent may report its status to a Middlebox with which it is associated. A Middlebox may report its status to a MIDCOM Agent with which it is associated. 6.6.2. Unsolicited messages The protocol needs to support unsolicited messages, for event reporting and propagation of alarms. 6.6.3. Protocol Failure To enable management systems to interact with the MIDCOM environment, the protocol needs to include failure reasons that allow the MIDCOM Agent behaviour to be modified as a result of the information contained in the reason. Failure reasons need to be chosen such that they do not make an attack on security easier. 6.7. Security 6.7.1. Registration and Authorisation The relationship between a MIDCOM Agent and a given Middlebox may be pre-configured through a manual configuration process or may be established dynamically through a registration process. In either case, depending upon the policy applied to the Middlebox, the Middlebox must appropriately authenticate the identity and credentials of the MIDCOM Agent seeking to make use of its services prior to servicing any other requests from the MIDCOM Agent. Swale et al Expires November 2001 11 MIDCOM Requirements July 2001 6.7.1.1. Deregistration The MIDCOM Protocol needs to allow either the MIDCOM Agent or the Middlebox to terminate the communications relationship between a MIDCOM Agent and a Middlebox. This allows either entity to close the session for maintenance, security or other reasons. Once the need for the relationship between a MIDCOM Agent and a Middlebox established during the registration process has lapsed, a deregistration process will be required. This will break the trust relationship between the specific Middlebox and MIDCOM Agent. Once this has been done, a Middlebox must not service any further requests from a given MIDCOM Agent without the MIDCOM Agent first re-establish the appropriate trust relationship with the Middlebox. MIDCOM session disconnection may be prompted by a successful de- registration request or a failure of some sort, such asa communications failure between the Middlebox and MIDCOM Agent. At the end of a MIDCOM session between a Middlebox and MIDCOM Agent, it should be possible for either the Middlebox or the MIDCOM Agent to initiate the disconnection of the relationship. As part of the de-registration process, any Pin-Holes or other Middlebox resources requested by the MIDCOM Agent must be immediately released by the Middlebox. 6.7.1.2. Error handling The MIDCOM Protocol must enable the Middlebox and/or MIDCOM Agent to determine when a registration session is no longer valid. This is to address cases such as when either a Middlebox or MIDCOM Agent re- starts. 6.7.2. MIDCOM Authentication Requirements The MIDCOM Protocol must allow communications between Middleboxes and MIDCOM Agents to be authenticated. Where possible, existing IETF protocols shall be used for authenticating MIDCOM entities such as Middleboxes and MIDCOM Agents. 6.7.3. MIDCOM Protocol communications To protect MIDCOM messages from being tampered with, individual message authentication should be used in addition to host authentication. Further message confidentiality may be administered by employing appropriate techniques to MIDCOM messages, when a higher level of security is required. Simple Source-address based security is the least form of security and should be permitted only to the most trusted hosts. 6.7.4. MIDCOM Protocol transport Swale et al Expires November 2001 12 MIDCOM Requirements July 2001 Communications between a MIDCOM Agent and a Middlebox constitute a flow of requests for services and associated responses. The transport of this information may present a security concern and should be appropriately protected. 6.7.5. General Security considerations Security mechanisms may be specified as provided in underlying transport mechanisms, such as IPSEC. The protocol, or such mechanisms, must: a. Allow for mutual authentication at the start of an MIDCOM Agent-Middlebox association b. Allow for preservation of the control messages once the association has been established. c. Allow for optional confidentiality protection of control messages. (If provided the mechanism should allow a choice in the algorithm to be used.) d. Operate across un-trusted domains between the MIDCOM Agent and Middlebox in a secure fashion. e. Support non-repudiation for a customer-located Middlebox communicating with a network operator's MIDCOM Agent. g. Define mechanisms to mitigate denial of service attacks. h. Define mechanisms to mitigate replay attacks on the control messages. Note: any associated protocol document will need to include an extended discussion of security requirements, offering more precision on each threat and giving a complete picture of the defence including non-protocol measures such as configuration. 7. Issues - Management: what should we say here? We need to balance management functionality with security concerns. - Middlebox resource discovery: how should a MIDCOM Agent be able to discover the resources available on a Middlebox? Related to this is the question of whether the MIDCOM Agent can automatically figure out what it has to do to get an application to work across a given Middlebox. - Do we want to have a Pin-Hole sharing operation which enables a MIDCOM Agent with ownership over a given flow to extend visibility of the Pin-Hole, for reporting or failure Swale et al Expires November 2001 13 MIDCOM Requirements July 2001 protection reasons, to another MIDCOM Agent which is authenticated with the same Middlebox? 8. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society March 23, 2001. 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 assignees. 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. 9. Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification Swale et al Expires November 2001 14 MIDCOM Requirements July 2001 can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Acknowledgements The authors would like to acknowledge the contributions from members of the MIDCOM working groups, specifically Jiri Kuthan, Jonathan Rosenberg, Andrew Molitor, Pyda Srisuresh and Melinda Shore. 11. References [MIDBOXFRAME] Middlebox Communication Architecture and Framework - work in progress. 12. Author's Addresses Richard Swale BTexact Technologies Callisto House Adastral Park Ipswich United Kingdom Email: richard.swale@bt.com Paul Sijben Lucent Technologies EMEA BV Huizen Netherlands Email: sijben@lucent.com Philip Mart Marconi Communications Ltd. Edge Lane Liverpool United Kingdom Email: philip.mart@marconi.com Swale et al Expires November 2001 15
Datatracker
Report a datatracker bug
draft-ietf-midcom-requirements-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3304.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |