Middlebox communication architecture and framework
RFC 3303

Document Type RFC - Informational (August 2002; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3303 (Informational)
Telechat date
Responsible AD Scott Bradner
IESG note Responsible: RFC Editor
Send notices to (None)
Network Working Group                                       P. Srisuresh
Request for Comments: 3303                               Kuokoa Networks
Category: Informational                                        J. Kuthan
                                              Fraunhofer Institute FOKUS
                                                            J. Rosenberg
                                                              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.


   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.

Srisuresh, et al.            Informational                      [Page 1]
RFC 3303           MIDCOM Architecture and Framework         August 2002

1. Introduction

   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.

   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.
Show full document text