Middlebox Communications (midcom) Protocol Requirements
RFC 3304
Document | Type | RFC - Informational (August 2002; Errata) | |
---|---|---|---|
Authors | Richard Swale , Melinda Shore , Scott Brim , Philip Mart , Paul Sijben | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3304 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Bradner | ||
IESG note | Responsible: RFC Editor | ||
Send notices to | (None) |
Network Working Group R. P. Swale Request for Comments: 3304 BTexact Technologies Category: Informational P. A. Mart Marconi Communications P. Sijben Lucent Technologies S. Brim M. Shore Cisco Systems August 2002 Middlebox Communications (midcom) Protocol Requirements 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. Abstract This document specifies the requirements that the Middlebox Communication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function. These requirements were developed with a specific focus on network address translation and firewall middleboxes. 1. Introduction This document is one of two developed by the Middlebox Communication (midcom) working group to address the requirements and framework for a protocol between middleboxes and "midcom agents." This document presents midcom requirements; [MCFW] presents the context and framework. [MCFW] also presents terminology and definitions and should be read in tandem with this one. These requirements were developed by examining the midcom framework and extracting requirements, both explicit and implicit, that appeared there. Swale, et al. Informational [Page 1] RFC 3304 Midcom Requirements August 2002 2. Requirements Each requirement is presented as a statement, followed by brief explanatory material as appropriate. Terminology is defined in [MCFW]. There may be overlap between requirements. 2.1. Protocol machinery 2.1.1. The Midcom protocol must enable a Midcom agent requiring the services of a middlebox to establish an authorized association between itself and the middlebox. This states that the protocol must allow the middlebox to identify an agent requesting services and make a determination as to whether or not the agent will be permitted to do so. 2.1.2. The Midcom protocol must allow a Midcom agent to communicate with more than one middlebox simultaneously. In any but the most simple network, an agent is likely to want to influence the behavior of more than one middlebox. The protocol design must not preclude the ability to do this. 2.1.3. The Midcom protocol must allow a middlebox to communicate with more than one Midcom agent simultaneously. There may be multiple instances of a single application or multiple applications desiring service from a single middlebox, and different agents may represent them. The protocol design must not preclude the ability to do so. 2.1.4. Where a multiplicity of Midcom Agents are interacting with a given middlebox, the Midcom protocol must provide mechanisms ensuring that the overall behavior is deterministic. This states that the protocol must include mechanisms for avoiding race conditions or other situations in which the requests of one agent may influence the results of the requests of other agents in an unpredictable manner. Swale, et al. Informational [Page 2] RFC 3304 Midcom Requirements August 2002 2.1.5. The Midcom protocol must enable the middlebox and any associated Midcom agents to establish a 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. This states that the protocol must provide clear identification for requests and results and that protocol operations must be atomic with respect to the midcom protocol. 2.1.6. The middlebox must be able to report its status to a Midcom agent with which it is associated. 2.1.7. The protocol must support unsolicited messages from middlebox to agent, for reporting conditions detected asynchronously at the middlebox. It may be the case that exceptional conditions or other events at the middlebox (resource shortages, intrusion mitigation) will cause the middlebox to close pinholes or release resources without consulting the associated Midcom agent. In that event, the protocol must allowShow full document text