rfc3303
rfc3234
draft-kuthan-fcp-02
draft-martin-midcom-sip-natfw-callflows-00
draft-stiemerling-midcom-simco
draft-ietf-midcom-semantics
draft-stiemerling-midcom-semantics
rfc3303
rfc3234
draft-kuthan-fcp-02
draft-martin-midcom-sip-natfw-callflows-00
draft-stiemerling-midcom-simco
draft-ietf-midcom-semantics
draft-stiemerling-midcom-semantics
rfc3303.txt  | Middlebox communication architecture and framework |
| Author(s) | P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan |
| Organization | ietf |
| State | informational |
| Size | 91209 bytes |
| 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. 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. |
| rfc3234.txt | Middleboxes: Taxonomy and Issues |
| Author(s) | B. Carpenter, S. Brim |
| Organization | ietf |
| State | informational |
| Size | 62329 bytes |
| Abstract | This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. |
draft-kuthan-fcp-02.txt  | Firewall Control Protocol Framework and Requirements |
| Author(s) | J Rosenberg, J Kuthan |
| Organization | ietf |
| State | unknown |
| Date | 2000-11-29 |
| Size | 58635 bytes |
| Abstract | The purpose of this document is to develop framework and requirements for a protocol that will allow for communicating control data associated with IP/transport-layer data flows or aggregates of them between intermediate packet processing devices and external controllers. The protocol will be extensible in order to allow for communicating arbitrary control data associated with packet flows and defining packet flow processing. It will include provisions for verifying the integrity of each message as well as ensuring authentication of all parties involved in the transactions. A major application of this protocol will be the control of packet processing policies in decomposed firewalls/NATs/NAT-PTs by externalized Application Level Gateways. This particular use will relieve firewalls/NATs from application-layer processing to improve their maintainability and performance. Examples of other possible applications include but are not limited to buffer management and load balancing. |
| draft-martin-midcom-sip-natfw-callflows-00.txt | SIP Through NAT Enabled Firewall Call Flows |
| Author(s) | Alan Johnston, Chris Martin |
| Organization | ietf |
| State | unknown |
| Date | 2001-02-23 |
| Size | 62865 bytes |
| Abstract | This informational draft outlines the operation of a transparent SIP NAT/firewall proxy which makes modifications to SIP (Session Initiation Protocol)[2] headers and SDP (Session Description Protocol)[3] fields. Both inbound and outbound detailed call flows are included. Table of Contents Introduction......................................................2 Overview of NAT...................................................2 Assumptions.......................................................3 Security Considerations and Implications..........................4 Transparency vs. SIP Proxy Functionality..........................4 High Level Tasks..................................................4 LEGEND 5 Outbound SIP Through NAT Call Flow Scenario.......................6 Inbound SIP Through NAT Call Flows...............................19 References.......................................................30 Authors' Addresses...............................................31 |
| draft-stiemerling-midcom-simco-03.txt
|
"Simple Middlebox Configuration (SIMCO) Protocol Version 2.0", Juergen
Quittek, Martin Stiemerling, 04-MAR-03,
This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used. The protocol meets all requirements defined by the MIDCOM working group (see [4]) and it implements the MIDCOM semantics [3]. |
| draft-ietf-midcom-semantics-02.txt
|
"MIDCOM Protocol Semantics", Martin Stiemerling, 15-May-03,
This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- |
| draft-stiemerling-midcom-semantics-03.txt
|