rfc3093.txt

RFC 的详细文档！

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.

Abstract

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

1.0 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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
   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                      [Page 2]

RFC 3093             Firewall Enhancement Protocol          1 April 2001


   With this innovation anyone can use any new TCP/IP application
   immediately without having to go through the laborious process of
   dealing with Firewall access for the particular application.  An
   unintended byproduct of this proposal is that existing TCP/IP
   applications can also be supported to better serve the users.  With
   FEP, the users can decide what applications they can run.

   Our protocol is simple and is partly based on the Eastlake [3]
   proposal for MIME encoding of IP packets.  We use the ubiquitous HTTP
   protocol format.  The IP datagram is carried in the message body of
   the HTTP message and the TCP packet header information is encoded
   into HTTP headers of the message.  This ASCII encoding of the header
   fields has many advantages, including human readability, increasing
   the debuggability of new applications, and easy logging of packet
   information.  If this becomes widely adopted, tools like tcpdump will
   become obsolete.

3.0 FEP Protocol

   Figure 1 shows a high level view of our protocol.  The application
   (1) in host A (outside the Firewall) sends a TCP/IP datagram to host
   B (within the firewall).  Using a tunnel interface the TCP/IP
   datagram is routed to our FEP software (2), which encodes the
   datagram within a HTTP message.  Then this message is sent via a
   HTTP/TCP/IP tunnel (3) to host B on the normal HTTP port (4).  When
   it arrives at host B, this packet is routed via the tunnel to the FEP
   software (5), which decodes the packet and creates a TCP/IP datagram
   to insert into host's B protocol stack (6).  This packet is routed to
   the application on host B (7), as if the Firewall (8) never existed.






















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


            host A                                       host B
          ----------                                   ----------
         |    App   | (1)                             |    App   | (7)
         |----------|                                 |----------|
         |    TCP   |                                 |    TCP   |
         |----------|                                 |----------|
         |     IP   |                                 |    IP    | (6)
         |----------|                                 |----------|
         | FEP dvr  | (2)                             |  FEP dvr | (5)
         |----------|                                 |----------|
         |    TCP   |                                 |    TCP   |
         |----------|                                 |----------|
         |    IP    |         Firewall (8)            |    IP    |
          ----------              ---                  -----------
                |       (3)       | |                       ^ (4)
                +---------------->| |-----------------------+
                                  | |
                                  | |
                                  ---
                                Figure 1

3.1 HTTP Method

   FEP allows either side to look like a client or server.  Each TCP/IP
   packet is sent as either a HTTP GET request or a response to a GET
   request.  This flexibility work well with firewalls that try to
   verify valid HTTP commands crossing the Firewall stopping the
   unwanted intercepting of FEP packets.

3.2 TCP Header Encapsulation:

   The TCP/IP packet is encoded into the HTTP command in two (or
   optionally three) steps.  First, the IP packet is encoded  as the
   message body in MIME format, as specified in [3].  Next, the TCP [4]
   packet header is parsed and encoded into new HTTP headers.  Finally,
   as an option, the IP header can also be encoded into new optional
   HTTP headers.  Encoding the TCP and optionally the IP header is
   strictly for human readability, since the entire IP datagram is
   encoded in the body part of the HTTP command.

   This proposal defines the following new HTTP headers for representing
   TCP header information.

   TCP_value_opt - This ASCII string represents the encoding type for
      the TCP fields where a mandatory encoding type is not specified.
      The legitimate values are:





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


   TCP_binary - ASCII representation of the binary representation of the
      value of the field.

   TCP_hexed - ASCII representation of the hex representation of the
      value of the field.

   TCP_Sport - The 16-bit TCP Source Port number, encoded as an ASCII
      string representing the value of port number.

   TCP_Dport - The 16-bit TCP Destination Port number, encoded as an
      ASCII string representing the value of the port number.

   TCP_SeqNum - The 32-bit Sequence Number, encoded as an ASCII string
      representing the hex value of the Sequence number.  This field
      MUST be sent as lower case because it is not urgent.

   TCP_Ackl - The 32-bit Acknowledgement Number, encoded as ASCII string
      representing the value of the Acknowledgement number.

   TCP_DODO - The 4-bit Data Offset value, encoded as an ASCII string
      representing  the base 32 value of the actual length of TCP header
      in bits.  (Normally this is the Data value times 32.)

   TCP_6Os - The 6 reserved bits, encoded as a string of 6 ASCII
      characters.  A "O" ("Oh") represents an "Off" bit and "O" ("Oh")
      represents an "On" bit.  (Note these characters MUST all be sent
      as "off" and MUST be ignored on receipt.)

   TCP_FlgBts - The TCP Flags, encoded as the set of 5 comma-separated
      ASCII strings: [{URG|urg}, {ACK|ack}, {PSH|psh}, {RST|rst},
      {SYN|syn}, {FIN|fin}].  Capital letters imply the flag is set,
      lowercase means the flag is not set.

   TCP_Windex - The 16-bit TCP Window Size, encoded as an ASCII string
      representing the value of the number of bytes in the window.

   TCP_Checkit - The 16-bit TCP Checksum field, encoded as an ASCII
      string representing the decimal value of the ones-complement of
      the checksum field.

   TCP_UP - The 16-bit TCP Urgent Pointer, encoded as the hex
      representation of the value of the field.  The hex string MUST be
      capitalized since it is urgent.








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


   TCP_Opp_Lst - A comma-separated list of any TCP options that may be
      present.  Each option is encoded as an ASCII string representing
      the name of the option followed by option-specific information
      enclosed in square brackets.  Representative options and their
      encoding follow, other IP options follow the same form:

      End of Options option: ["End of Options"]

      Window scale option: ["Window scale", shift_count], where
         shift_count is the window scaling factor represented as the
         ASCII string in decimal.

3.2 IPv4 Header Encapsulation:

   This proposal defines the following new HTTP headers for representing
   IPv4 header information:

   These optional headers are used to encode the IPv4 [5] header for
   better readability.  These fields are encoded in a manner similar to
   the above TCP header fields.

   Since the base IP packet is already present in an HTTP header, the
   following headers are optional.  None, some or all of them may be
   used depending on the whim of the programmer.