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
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
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and
L. Jones, "SOCKS Protocol Version 5", March 1996.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC1958, June 1996.
[RFC2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
version 2", RFC2186, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Service", RFC2475, December 1998.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC2543,
March 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC2616, June 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
(HTCP/0.0)", RFC2756, January 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC2766,
February 2000.
[RFC2775] Carpenter, B., "Internet Transparency", RFC2775, February
2000.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC2979, October 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC2993,
November 2000.
[RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.
and J. Segers, "Megaco Protocol 1.0", RFC3015, November
2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC3022, January
2001.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC3027, 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.
[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,
RFC3205, 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", RFC3135, June 2001.
[RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
"Realm Specific IP: Framework", RFC3102, 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.
[SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
RFC3089, 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", RFC3040, 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
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 RFCEditor function is currently provided by the
Internet Society.