rfc3303.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,285 行 · 第 1/5 页

Network Working Group                                       P. Srisuresh
Request for Comments: 3303                               Kuokoa Networks
Category: Informational                                        J. Kuthan
                                              Fraunhofer Institute FOKUS
                                                            J. Rosenberg
                                                             dynamicsoft
                                                              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.

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.




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.
   A separate requirements document lists the requirements in detail.

   MIDCOM agents with application intelligence can assist the
   middleboxes through the MIDCOM protocol in permitting applications
   such as FTP, SIP and H.323.  The communication between a MIDCOM agent
   and a middlebox will not be noticeable to the end-hosts that take
   part in the application, unless one of the end-hosts assumes the role
   of a MIDCOM agent.  Discovery of middleboxes or MIDCOM agents in the




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


   path of an application instance is outside the scope of this
   document.  Further, any communication amongst middleboxes is also
   outside the scope of this document.

   This document describes the framework in which middlebox
   communication takes place and the various elements that constitute
   the framework.  Section 2 describes the terms used in the document.
   Section 3 defines the architectural framework of a middlebox for
   communication with MIDCOM agents.  The remaining sections cover the
   components of the framework, illustration using sample flows, and
   operational considerations with the MIDCOM architecture.  Section 4
   describes the nature of MIDCOM protocol.  Section 5 identifies
   entities that could potentially host the MIDCOM agent function.
   Section 6 considers the role of Policy server and its function with
   regard to communicating MIDCOM agent authorization policies.  Section
   7 is an illustration of SIP flows using a MIDCOM framework in which
   the MIDCOM agent is co-resident on a SIP proxy server.  Section 8
   addresses operational considerations in deploying a protocol adhering
   to the framework described here.  Section 9 is an applicability
   statement, scoping the location of middleboxes.  Section 11 outlines
   security considerations for the middlebox in view of the MIDCOM
   framework.

2. Terminology

   Below are the definitions for the terms used throughout the document.

2.1. Middlebox function/service

   A middlebox function or a middlebox service is an operation or method
   performed by a network intermediary that may require application
   specific intelligence for its operation.  Policy based packet
   filtering (a.k.a. firewall), Network address translation (NAT),
   Intrusion detection, Load balancing, Policy based tunneling and IPsec
   security are all examples of a middlebox function (or service).

2.2. Middlebox

   A Middlebox is a network intermediate device that implements one or
   more of the middlebox services.  A NAT middlebox is a middlebox
   implementing NAT service.  A firewall middlebox is a middlebox
   implementing firewall service.

   Traditional middleboxes embed application intelligence within the
   device to support specific application traversal.  Middleboxes
   supporting the MIDCOM protocol will be able to externalize
   application intelligence into MIDCOM agents.  In reality, some of the




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


   middleboxes may continue to embed application intelligence for
   certain applications and depend on MIDCOM protocol and MIDCOM agents
   for the support of remaining applications.

2.3. Firewall

   Firewall is a policy based packet filtering middlebox function,
   typically used for restricting access to/from specific devices and
   applications.  The policies are often termed Access Control Lists
   (ACLs).

2.4. NAT

   Network Address Translation is a method by which IP addresses are
   mapped from one address realm to another, providing transparent
   routing to end-hosts.  Transparent routing here refers to modifying
   end-node addresses en-route and maintaining state for these updates
   so that when a datagram leaves one realm and enters another,
   datagrams pertaining to a session are forwarded to the right end-host
   in either realm.  Refer to [NAT-TERM] for the definition of
   Transparent routing, various NAT types, and the associated terms in
   use.  Two types of NAT are most common.  Basic-NAT, where only an IP
   address (and the related IP, TCP/UDP checksums) of packets is altered
   and NAPT (Network Address Port Translation), where both an IP address
   and a transport layer identifier, such as a TCP/UDP port (and the
   related IP, TCP/UDP checksums), are altered.

   The term NAT in this document is very similar to the IPv4 NAT
   described in [NAT-TERM], but is extended beyond IPv4 networks to
   include the IPv4-v6 NAT-PT described in [NAT-PT].  While the IPv4 NAT
   [NAT-TERM] translates one IPv4 address into another IPv4 address to
   provide routing between private V4 and external V4 address realms,
   IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address into an IPv6
   address, and vice versa, to provide routing between a V6 address
   realm and an external V4 address realm.

   Unless specified otherwise, NAT in this document is a middlebox
   function referring to both IPv4 NAT, as well as IPv4-v6 NAT-PT.

2.5. Proxy

   A proxy is an intermediate relay agent between clients and servers of
   an application, relaying application messages between the two.
   Proxies use special protocol mechanisms to communicate with proxy
   clients and relay client data to servers and vice versa.  A Proxy
   terminates sessions with both the client and the server, acting as
   server to the end-host client and as client to the end-host server.




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


   Applications such as FTP, SIP, and RTSP use a control session to
   establish data sessions.  These control and data sessions can take
   divergent paths.  While a proxy can intercept both the control and
   data sessions, it might intercept only the control session.  This is
   often the case with real-time streaming applications such as SIP and
   RTSP.

2.6. ALG

   Application Level Gateways (ALGs) are entities that possess the
   application specific intelligence and knowledge of an associated
   middlebox function.  An ALG examines application traffic in transit
   and assists the middlebox in carrying out its function.

   An ALG may be a co-resident with a middlebox or reside externally,
   communicating through a middlebox communication protocol.  It
   interacts with a middlebox to set up state, access control filters,
   use middlebox state information, modify application specific payload,
   or perform whatever else is necessary to enable the application to
   run through the middlebox.

   ALGs are different from proxies.  ALGs are not visible to end-hosts,
   unlike the proxies which are relay agents terminating sessions with
   both end-hosts.  ALGs do not terminate sessions with either end-host.
   Instead, ALGs examine, and optionally modify, application payload
   content to facilitate the flow of application traffic through a
   middlebox.  ALGs are middlebox centric, in that they assist the