RFC 3093 (rfc3093) - Page 2 of 11

Firewall Enhancement Protocol (FEP)

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
   Firewalls.

   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
   to develop a process by which TCP/IP itself is carried over HTTP.



Gaynor & Bradner             Informational