rfc3234.txt

RFC 的详细文档！

   functional, 6 processing, 7 hard, 8 restart}

2.23. Not included

   Some candidates suggested for the above list were excluded for the
   reasons given below.  In general, they do not fundamentally change
   the architectural model of packet delivery from source to
   destination.

   Bridges and switches that snoop ARP, IGMP etc.  These are below the
   IP layer, but use a layer violation to emulate network layer
   functions.  They do not change IP layer functions.

   Wiretaps and snoopers in general - if they are working correctly,
   they have no impact on traffic, so do not require analysis.

   Mobile IP home agents are intended to assist packet delivery to the
   originally desired destination, so they are excluded on the same
   grounds as standard routers.

   Relays in interplanetary networks - although these would certainly
   appear to be middleboxes, they are not currently deployed.

2.24. Summary of facets

   By tabulating the rough classifications above, we observe that of the
   22 classes of middlebox described:

   17 are application or multi-layer
   16 are implicit (and others are explicit OR implicit)
   17 are multi-hop
   21 are in-line; call-out is rare
   18 are functional; pure optimisation is rare
   Routing & processing are evenly split
   16 have hard state
   21 must restart session on failure





Carpenter & Brim             Informational                     [Page 17]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   We can deduce that current types of middlebox are predominantly
   application layer devices not designed as part of the relevant
   protocol, performing required functions, maintaining hard state, and
   aborting user sessions when they crash.  Indeed this represents a
   profound challenge to the end-to-end hourglass model.

3. Ongoing work in the IETF and elsewhere

   Apart from work cited in references above, current or planned work in
   the IETF includes:

   MIDCOM - a working group with focus on the architectural framework
   and the requirements for the protocol between a requesting device and
   a middlebox and the architectural framework for the interface between
   a middlebox and a policy entity [MIDFRAME, MIDARCH].  This may
   interact with session control issues [SIPFIRE].

   Work is also proceeding outside the MIDCOM group on middlebox
   discovery [MIDDISC].

   WEBI (Web Intermediaries) - a working group that addresses specific
   issues in the world wide web infrastructure (as identified by the
   WREC working group), by providing generic mechanisms which are useful
   in several application domains (e.g., proxies, content delivery
   surrogates).  Specific mechanisms will be Intermediary Discovery and
   Description and a Resource Update Protocol.

   Intermediaries are also an important focus in the development of XML
   Protocol by the World-Wide Web Consortium, who have published an
   interesting analysis [XMLPI].

   OPES (Open Pluggable Extension Services) - a proposed  working group
   whose output will enable construction of services executed on
   application data by participating transit intermediaries.  Caching is
   the most basic intermediary service, one that requires a basic
   understanding of application semantics by the cache server.

   CDI (Content Distribution Internetworking) is a potential working
   group for allowing cooperation between different Content Distribution
   Networks and cache clusters [CDNP].

   RSERPOOL (Reliable Server Pooling) is a working group that will
   define architecture and requirements for management and access to
   server pools, including requirements from a variety of applications,
   building blocks and interfaces, different styles of pooling, security
   requirements and performance requirements, such as failover times and
   coping with heterogeneous latencies.




Carpenter & Brim             Informational                     [Page 18]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


4. Comments and Issues

   A review of the list in Section 2 suggests that middleboxes fit into
   one or more of three broad categories:

   1) mechanisms to connect dissimilar networks to enable cross-protocol
      interoperability;

   2) mechanisms to separate similar networks into zones, especially
      security zones;

   3) performance enhancement.

   As observed in [RFC 2775], the rise of middleboxes puts into question
   the general applicability of the end-to-end principle [RFC 1958].
   Middleboxes introduce dependencies and hidden points of failure that
   violate the fate-sharing aspect of the end-to-end principle.  Can we
   define architectural principles that guarantee robustness in the
   presence of middleboxes?

4.1. The end to end principle under challenge

   Many forms of middlebox are explicitly addressed at the IP level, and
   terminate a transport connection (or act as a final destination for
   UDP packets) in a normal way.  Although they are potential single
   points of failure, they do not otherwise interfere with the end to
   end principle [RFC 1958].  (This statement does not apply to
   transport relays or TCP spoofers; they do not terminate a transport
   connection at the expected destination in the normal way.)

   However, there is a general feeling that middleboxes that divert an
   IP packet from its intended destination, or substantively modify its
   content on the fly, are fundamentally different from those that
   correctly terminate a transport connection and carry out their
   manipulations at applications level.  Such diversion or modification
   violates the basic architectural assumption that packets flow from
   source to destination essentially unchanged (except for time-to-live
   and QOS-related fields).  The effects of such changes on transport
   and applications is unpredictable in the general case.  Much of the
   analysis that applies to NAT [RFC 2993, RFC 3027] will also apply to
   RSIP, NAT-PT, DSTM, SOCKS, and involuntary packet redirectors.
   Interception proxies, anonymisers, and some types of load balancer
   can also have subtle effects on address-sensitive applications, when
   they cause packets to be delivered to or from a different address.
   Transport relays and TCP spoofers may deceive applications by
   delivering an unreliable service on a TCP socket.





Carpenter & Brim             Informational                     [Page 19]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   We conclude that:

      Although the rise of middleboxes has negative impact on the end to
      end principle at the packet level, it does not nullify it as a
      useful or desirable principle of applications protocol design.
      However, future application protocols should be designed in
      recognition of the likely presence of network address translation,
      packet diversion, and packet level firewalls, along the data path.

4.2. Failure handling

   If a middlebox fails, it is desirable that the effect on sessions
   currently in progress should be inconvenient rather than
   catastrophic.  There appear to be three approaches to achieve this:

      Soft state mechanisms.  The session continues in the absence of
      the box, probably with reduced performance, until the necessary
      session state is recreated automatically in an alternative box (or
      the original one, restarted).  In other words the state
      information optimises the user session but is not essential.  An
      example might be a true caching mechanism, whose temporary failure
      only reduces performance.

      Rapid failover mechanisms.  The session is promptly redirected to
      a hot spare box, which already has a copy of the necessary session
      state.

      Rapid restart mechanisms.  The two ends of the session promptly
      detect the failure and themselves restart the session via a spare
      box, without being externally redirected.  Enough session state is
      kept at each end to recover from the glitch.

   It appears likely that "optimising" middleboxes are suitable
   candidates for the soft state approach and for non-real-time data
   streams, since the consequence of failure of the box is not
   catastrophic for the user.  (Configured HTTP proxies used as caches
   are an awkward case, as their failure causes client failure.)  On the
   other hand, "functional" middleboxes must be present for the session
   to continue, so they are candidates for rapid failover or rapid
   restart mechanisms.  We conclude that:

      Middlebox design should include a clear mechanism for dealing with
      failure.








Carpenter & Brim             Informational                     [Page 20]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


4.3. Failures at multiple layers

   Difficulties occur when middlebox functions occur at different
   layers, for example the following situation, where B and C are not in
   the same physical box:

      Apps layer:     A ------------------------> C ------> D

      Lower layer:    A -----> B -------------------------> D

   When all is well, i.e., there is an IP path from A to B to C to D and
   both B and C are working, this may appear quite workable.  But the
   failure modes are very challenging.  For example, if there is a
   network failure between C and D, how is B instructed to divert the
   session to a backup box for C?.  Since C and B function at different
   protocol layers, there is no expectation that they will have
   coordinated failure recovery mechanisms.  Unless this is remedied in
   some general way, we conclude that

      Middlebox failure recovery mechanisms cannot currently assume they
      will get any help from other layers, and must have their own means
      of dealing with failures in other layers.

      In the long term future, we should be able to state clearly for
      each middlebox function what it expects from its environment, and
      make recommendations about which middlebox functions should be
      bound together if deployed.

4.4. Multihop application protocols

   We can also observe that protocols such as SMTP, UUCP, and NNTP have
   always worked hop-by-hop, i.e., via multiple middleboxes.  Nobody
   considers this to be an issue or a problem.  Difficulties arise when
   inserting a middlebox in an application protocol stream that was not
   designed for it.  We conclude that:

      New application protocol designs should include explicit
      mechanisms for the insertion of middleboxes, and should consider
      the facets identified in Section 2 above as part of the design.

   A specific challenge is how to make interactive or real-time
   applications ride smoothly over middleboxes.  This will put
   particular stress on the failure handling aspects.








Carpenter & Brim             Informational                     [Page 21]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


4.5. Common features

   Given that the IP layer - the neck of the hourglass - is no longer
   alone in its role supporting end-to-end connectivity, it would be
   desirable to define requirements and features that are common to
   middlebox intermediaries.  It would then be possible to implement
   middleboxes, and in particular the protocols that communicate with
   them, fully from the stance of supporting the end-to-end principle.
   Conceptually, this would extend the neck of the hourglass upwards to
   include a set of common features available to all (or many)
   applications.  In the context of middleboxes and multihop protocols,
   this would require common features addressing at least:

      Middlebox discovery and monitoring
      Middlebox configuration and control
      Call-out
      Routing preferences
      Failover and restart handling
      Security, including mutual authentication

   As far as possible, the solutions in these areas being developed in
   the IETF and W3C should be sufficiently general to cover all types of
   middlebox; if not, the work will be done several times.

5. Security Considerations

   Security risks are specific to each type of middlebox, so little can
   be said in general.  Of course, adding extra boxes in the
   communication path creates extra points of attack, reduces or
   eliminates the ability to perform end to end encryption, and
   complicates trust models and key distribution models.  Thus, every
   middlebox design requires particular attention to security analysis.
   A few general points can be made: