Firewall Enhancement Protocol (FEP)
RFC 3093

Document Type RFC - Informational (April 2001; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 3093 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          M. Gaynor
Request for Comments: 3093                                    S. Bradner
Category: Informational                               Harvard University
                                                            1 April 2001

                  Firewall Enhancement Protocol (FEP)

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 (2001).  All Rights Reserved.


   Internet Transparency via the end-to-end architecture of the Internet
   has allowed vast innovation of new technologies and services [1].
   However, recent developments in Firewall technology have altered this
   model and have been shown to inhibit innovation.  We propose the
   Firewall Enhancement Protocol (FEP) to allow innovation, without
   violating the security model of a Firewall.  With no cooperation from
   a firewall operator, the FEP allows ANY application to traverse a
   Firewall.  Our methodology is to layer any application layer
   Transmission Control Protocol/User Datagram Protocol (TCP/UDP)
   packets over the HyperText Transfer Protocol (HTTP) protocol, since
   HTTP packets are typically able to transit Firewalls.  This scheme
   does not violate the actual security usefulness of a Firewall, since
   Firewalls are designed to thwart attacks from the outside and to
   ignore threats from within.  The use of FEP is compatible with the
   current Firewall security model because it requires cooperation from
   a host inside the Firewall.  FEP allows the best of both worlds: the
   security of a firewall, and transparent tunneling thought the

1.0 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

Gaynor & Bradner             Informational                      [Page 1]
RFC 3093             Firewall Enhancement Protocol          1 April 2001

2.0 Introduction

   The Internet has done well, considering that less than 10 years ago
   the telco's were claiming it could not ever work for the corporate
   environment.  There are many reasons for this; a particularly strong
   one is the end-to-end argument discussed by Reed, Seltzer, and Clark
   [2].  Innovation at the ends has proven to be a very powerful
   methodology creating more value than ever conceived of.  But, the
   world is changing as Clark notes in [6].  With the connection of the
   corporate world to the Internet, security concerns have become
   paramount, even at the expense of breaking the end-to-end paradigm.
   One example of this is the Firewall - a device to prevent outsiders
   from unauthorized access into a corporation.  Our new protocol, the
   Firewall Enhancement Protocol (FEP), is designed to restore the end-
   to-end model while maintaining the level of security created by

   To see how powerful the end-to-end model is consider the following
   example.  If Scott and Mark have a good idea and some implementation
   talent, they can create an artifact, use it, and send it to their
   friends.  If it turns out to be a good idea these friends can adopt
   it and maybe make it better.  Now enter the Firewall: if Mark happens
   to work at a company that installs a Firewall, he can't experiment
   with his friend Scott.  Innovation is more difficult, maybe
   impossible.  What business is it of an IT manager if Scott and Mark
   want to do some experiments to enable them to better serve their
   users?  This is how the web was created: one guy with talent, a few
   good ideas, and the ability to innovate.

   Firewalls are important, and we do respect the right of anybody to
   protecting themselves any way they want (as long as others are not
   inconvenienced).  Firewalls work, and have a place in the Internet.
   However, Firewalls are built to protect from external threats, not
   internal ones.  Our proposed protocol does not break the security
   model of the Firewall; it still protects against all external risks
   that a particular Firewall can protect against.  For our protocol to
   work someone inside the Firewall must run an application level
   protocol that can access TCP port 80.  Our concept allows a
   consistent level of security while bypassing the IT manager in charge
   of the Firewall.  We offer freedom to innovate without additionally
   compromising external security, and the best part, no need to waste
   time involving any managers for approval.

   We got this idea from the increasing number of applications that use
   HTTP specifically because it can bypass Firewall barriers.  This
   piecemeal deployment of specific applications is not an efficient way
   to meet the challenge to innovation created by Firewalls.  We decided
Show full document text