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 Rerved. Abstract
Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and rvices [1].
However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propo the
Firewall Enhancement Protocol (FEP) to allow innovation, without
violating the curity model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traver a
Firewall. Our methodology is to layer any application layer
Transmission Control Protocol/Ur Datagram Protocol (TCP/UDP)
alevin
packets over the HyperText Transfer Protocol (HTTP) protocol, since
HTTP packets are typically able to transit Firewalls. This scheme
does not violate the actual curity ufulness of a Firewall, since Firewalls are designed to thwart attacks from the outside and to
ignore threats from within. The u of FEP is compatible with the
current Firewall curity model becau it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the curity 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]
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 discusd 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, curity concerns have become
paramount, even at the expen 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 curity created by
Firewalls.
To e 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, u it, and nd it to their
friends. If it turns out to be a good idea the 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 rve their
urs? 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 themlves 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 propod protocol does not break the curity
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 curity while bypassing the IT manager in charge of the Firewall. We offer freedom to innovate without additionally
compromising external curity, and the best part, no need to waste
herpes btime involving any managers for approval.
We got this idea from the increasing number of applications that u HTTP specifically becau it can bypass Firewall barriers. This
piecemeal deployment of specific applications is not an efficient way to meet the challenge to inno
vation created by Firewalls. We decided to develop a process by which TCP/IP itlf is carried over HTTP. Gaynor & Bradner Informational [Page 2]
With this innovation anyone can u 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 rve the urs. With
FEP, the urs can decide what applications they can run.
Our protocol is simple and is partly bad on the Eastlake [3]
proposal for MIME encoding of IP packets. We u 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) nds 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 nt 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 inrt 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]
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 rver. Each TCP/IP packet is nt as either a HTTP GET request or a respon 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:
smn是什么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 pard and encoded into new HTTP headers. Finally, as an option, the IP header can also be encoded into ne
w 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 reprenting TCP header information.
TCP_value_opt - This ASCII string reprents the encoding type for
the TCP fields where a mandatory encoding type is not specified.
The legitimate values are:
Gaynor & Bradner Informational [Page 4]
TCP_binary - ASCII reprentation of the binary reprentation of the value of the field.上海文来中学
TCP_hexed - ASCII reprentation of the hex reprentation of the
value of the field.
TCP_Sport - The 16-bit TCP Source Port number, encoded as an ASCII
string reprenting the value of port number.
TCP_Dport - The 16-bit TCP Destination Port number, encoded as an
ASCII string reprenting the value of the port number.
TCP_SeqNum - The 32-bit Sequence Number, encoded as an ASCII string
reprenting the hex value of the Sequence number. This field
MUST be nt as lower ca becau it is not urgent.
TCP_Ackl - The 32-bit Acknowledgement Number, encoded as ASCII string reprenting the value of the Acknowledgement number.
TCP_DODO - The 4-bit Data Offt value, encoded as an ASCII string
reprenting the ba 32 value of the actual length of TCP header in bits. (Normally this is the Data value times 32.)
TCP_6Os - The 6 rerved bits, encoded as a string of 6 ASCII
characters. A "O" ("Oh") reprents an "Off" bit and "O" ("Oh")
reprents an "On" bit. (Note the characters MUST all be nt
as "off" and MUST be ignored on receipt.)
TCP_FlgBts - The TCP Flags, encoded as the t of 5 comma-parated
在线阅读网站ASCII strings: [{URG|urg}, {ACK|ack}, {PSH|psh}, {RST|rst},
{SYN|syn}, {FIN|fin}]. Capital letters imply the flag is t,
lowerca means the flag is not t.
nbsiTCP_Windex - The 16-bit TCP Window Size, encoded as an ASCII string
reprenting the value of the number of bytes in the window.
TCP_Checkit - The 16-bit TCP Checksum field, encoded as an ASCII
string reprenting the decimal value of the ones-complement of
the checksum field.
TCP_UP - The 16-bit TCP Urgent Pointer, encoded as the hex
reprentation of the value of the field. The hex string MUST be capitalized since it is urgent.
Gaynor & Bradner Informational [Page 5]
TCP_Opp_Lst - A comma-parated list of any TCP options that may be
prent. Each option is encoded as an ASCII string reprenting
the name of the option followed by option-specific information
enclod in square brackets. Reprentative 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 reprented as the
ASCII string in decimal.
3.2 IPv4 Header Encapsulation:
This proposal defines the following new HTTP headers for reprenting IPv4 header information:
The optional headers are ud to encode the IPv4 [5] header for
better readability. The fields are encoded in a manner similar to the above TCP header fields.
Since the ba IP packet is already prent in an HTTP header, the
following headers are optional. None, some or all of them may be
ud depending on the whim of the programmer.
adonis
IP_value_opt - This ASCII string reprents the encoding type for the following fields where a mandatory encoding type is not
specified. The legitimate values are the same as for
TCP_value_opt.
IP_Ver - The IP Version number, encoded as an UTF-8 string. The
legitimate values for the string are "four", "five", and "six."
The encapsulation of the fields in the IP header are defined in
this ction if the value is "four", and in ction 3.3 if the
value is "six". Encapsulations for headers with IP_Ver value of
"five" will be developed if the right orders are received.
Encapsulations for headers with the IP_Ver value of "eight" are
empty. Implementations MUST be able to support arbitrary native
languages for the strings.
IP4_Hlen - The IP Internet Header Length field, it is encoded in the same way as TCP_DODO.
IP4_Type_of_Service (this name is ca nsitive) - This is an
obsolete name for a field in the IPv4 header, which has been
replaced with IP_$$ and IP_CU.
Gaynor & Bradner Informational [Page 6]
