Middleboxes: Taxonomy and Issues
RFC 3234

gt; 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:

   1. The interference with end-to-end packet transmission by many types
      of middlebox is a crippling impediment to generalised use of IPSEC
      in its present form, and also invalidates transport layer security
      in many scenarios.

   2. Middleboxes require us to move definitively from a two-way to an
      N-way approach to trust relationships and key sharing.

   3. The management and configuration mechanisms of middleboxes are a
      tempting point of attack, and must be strongly defended.

   These points suggest that we need a whole new approach to security
   solutions as the middlebox paradigm ends up being deployed in lots of
   different technologies, if only to avoid each new technology

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

   designing a end-to-end security solution appropriate to its
   particular impact on the data stream.

   Additionally, content caches and content distribution mechanisms
   raise the issue of access control for content that is subject to
   copyright or other rights.  Distributed authentication, authorisation
   and accounting are required.

6. Acknowledgements

   Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom,
   Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on
   early versions of this document.  Rob Austein and Allison Mankin
   drafted the text on transport relays and TCP spoofers, and Rob
   Austein made other substantial contributions.  Participants in the
   MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including
   Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker,
   Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen,
   Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave
   invaluable input.  Mark Nottingham brought the W3C work to our
   attention.  Melinda Shore suggested using a facet-based
   categorization.  Patrik Faltstrom inspired section 4.3.

7. References

   [RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

   [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and
              L. Jones, "SOCKS Protocol Version 5", March 1996.

   [RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
              version 2", RFC 2186, September 1997.

   [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
              and W. Weiss, "An Architecture for Differentiated
              Service", RFC 2475, December 1998.

   [RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              March 1999.

   [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

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

   [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

   [RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
              (HTCP/0.0)", RFC 2756, January 2000.

   [RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February
              2000.

   [RFC 2979] Freed, N., "Behavior of and Requirements for Internet
              Firewalls", RFC 2979, October 2000.

   [RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

   [RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.
              and J. Segers, "Megaco Protocol 1.0", RFC 3015, November
              2000.

   [RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022, January
              2001.

   [RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027, January
              2001.

   [CHU]      Y. Chu, S. Rao, and H. Zhang, A Case for End System
              Multicast, SIGMETRICS, June 2000.
              http://citeseer.nj.nec.com/chu00case.html

   [CLARK88]  The Design Philosophy of the DARPA Internet Protocols,
              D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4,
              August 1988, pages 106-114 (reprinted in ACM CCR Vol 25,
              Number 1, January 1995, pages 102-111).

   [CLARK95]  "Adding Service Discrimination to the Internet", D.D.
              Clark, Proceedings of the 23rd Annual Telecommunications
              Policy Research Conference (TPRC), Solomons, MD, October
              1995.

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

   [CDNP]     M. Day, et al., "A Model for Content Internetworking
              (CDI)", Work in Progress.

   [DSTM]     J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A.
              Durand, "Dual Stack Transition Mechanism (DSTM)", Work in
              Progress.

   [H323]     ITU-T Recommendation H.323: "Packet Based Multimedia
              Communication Systems".

   [HOURG]    "Realizing the Information Future: The Internet and
              Beyond", Computer Science and Telecommunications Board,
              National Research Council, Washington, D.C., National
              Academy Press, 1994. However, the "hourglass" metaphor was
              first used by John Aschenbrenner in 1979, with reference
              to the ISO Open Systems Interconnection model.

   [HTTPSUB]  Moore, K., "On the use of HTTP as a Substrate", BCP 56,
              RFC 3205, February 2002.

   [MIDARCH]  E. Lear, "A Middlebox Architectural Framework", Work in
              Progress.

   [MIDDISC]  E. Lear, "Requirements for Discovering Middleboxes", Work
              in Progress.

   [MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A.
              Rayhan, "Middlebox Communication: Framework and
              Requirements", Work in Progress.

   [PILCPEP]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135, June 2001.

   [RSIP]     Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
              "Realm Specific IP: Framework", RFC 3102, October 2001.

   [SALTZER]  End-To-End Arguments in System Design, J.H. Saltzer,
              D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November
              1984, pp 277-288.

   [SIPFIRE]  S. Moyer, D. Marples, S. Tsang, J. Katz, P. Gurung, T.
              Cheng, A. Dutta, H. Schulzrinne, A. Roychowdhury,
              "Framework Draft for Networked Appliances Using the
              Session Initiation Protocol", Work in Progress.

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

   [SOCKS6]   Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
              RFC 3089, April 2001.

   [TRANS64]  "Overview of Transition Techniques for IPv6-only to Talk
              to IPv4-only Communication", Work in Progress.

   [WREC]     Cooper, I, Melve, I. and G. Tomlinson, "Internet Web
              Replication and Caching Taxonomy", RFC 3040, January 2001.

   [XMLPI]    Intermediaries and XML Protocol, Mark Nottingham, Work in
              Progress at http://lists.w3.org/Archives/Public/xml-dist-
              app/2001Mar/0045.html

Authors' Addresses

   Brian E. Carpenter
   IBM Zurich Research Laboratory
   Saeumerstrasse 4 / Postfach
   8803 Rueschlikon
   Switzerland

   EMail: brian@hursley.ibm.com

   Scott W. Brim
   146 Honness Lane
   Ithaca, NY 14850
   USA

   EMail: sbrim@cisco.com

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

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Carpenter & Brim             Informational                     [Page 27]