RFC 3093
Firewall Enhancement Protocol (FEP)
RFC 3093: Firewall Enhancement Protocol (FEP) 🦋
Okay bestie, let's start with the basics. This is RFC 3093, written by M. Gaynor and S. Bradner from Harvard University, and it's dated 1 April 2001 (April Fools' Day, just saying 👀). It's part of the Network Working Group series and it's marked as Informational, which means it shares information but doesn't set an Internet standard. It doesn't list anything it obsoletes or updates, so it's all its own thing 💅
Status of This Memo ✨
This memo gives information to the Internet community. It is not an Internet standard of any kind 🌸 You can distribute it as much as you want, no restrictions.
Copyright Notice 💜
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 🔥
Okay so the whole reason the Internet is so iconic is Internet Transparency, which comes from the end-to-end architecture. That's what let so many new technologies and services get built [1]. But recent Firewall tech has messed with that model and it's been shown to block innovation 😭 So the authors propose the Firewall Enhancement Protocol (FEP), which lets innovation happen without breaking the security model of a Firewall.
Here's the wild part: with zero cooperation from the firewall operator, FEP lets ANY application get through a Firewall 🧚 The method is to wrap any application layer Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets inside HyperText Transfer Protocol (HTTP), because HTTP packets usually get through Firewalls just fine. This doesn't actually weaken what a Firewall is good for, since Firewalls are built to stop attacks from outside and aren't really meant to catch threats from inside 🙈 FEP works with the current Firewall security model because it needs a host inside the Firewall to cooperate. The authors say it gives you the best of both worlds: the security of a firewall, plus transparent tunneling through 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 💅
2.0 Introduction 🌈
The Internet has honestly done amazing, especially considering that less than 10 years before this, the telco's were saying it could never work for the corporate environment 💀 A big reason it worked is the end-to-end argument discussed by Reed, Seltzer, and Clark [2]. Innovation at the ends has been super powerful and has created more value than anyone imagined 🔥 But the world is changing, as Clark notes in [6]. Now that corporations are connected to the Internet, security concerns have become top priority, even if that means breaking the end-to-end paradigm 😭 One example is the Firewall, which is a device that stops outsiders from getting unauthorized access into a corporation. The new protocol, the Firewall Enhancement Protocol (FEP), is designed to bring back the end-to-end model while keeping the level of security that Firewalls provide 🫶
Let me show you why the end-to-end model is so powerful. Say Scott and Mark have a good idea and some implementation talent. They can build an artifact, use it, and send it to their friends. If it turns out to be a good idea, those friends can adopt it and maybe make it even better ✨ Now enter the Firewall: if Mark happens to work at a company that installs one, he can't experiment with his friend Scott anymore 😭 Innovation becomes harder, maybe impossible. What business is it of an IT manager if Scott and Mark want to run some experiments so they can serve their users better? This is literally how the web was created: one person with talent, a few good ideas, and the ability to innovate 🦋
Firewalls are important, and the authors respect anybody's right to protect themselves however they want (as long as they don't inconvenience others) 🌸 Firewalls work and they have a place on the Internet. Still, Firewalls are built to protect against external threats, not internal ones. The proposed protocol doesn't break the security model of the Firewall. It still protects against every external risk that a particular Firewall can protect against 🛡️ For the protocol to work, someone inside the Firewall has to run an application level protocol that can access TCP port 80. The concept keeps a consistent level of security while getting around the IT manager in charge of the Firewall 👑 The big win is freedom to innovate without making external security worse, plus no need to waste time getting managers to approve anything 🙌
The authors got this idea from the growing number of applications that use HTTP specifically because it can get past Firewall barriers 👀 Deploying applications one at a time like this isn't an efficient way to deal with the innovation problem that Firewalls create. So they decided to develop a process where TCP/IP itself is carried over HTTP 🧚
With this, anyone can use any new TCP/IP application right away, without going through the painful process of getting Firewall access for each particular application 🎀 A bonus side effect is that existing TCP/IP applications can also be supported, to serve users better. With FEP, users get to decide which applications they can run 💖
The protocol is simple and partly based on the Eastlake [3] proposal for MIME encoding of IP packets. It uses the ubiquitous HTTP protocol format. The IP datagram goes in the message body of the HTTP message, and the TCP packet header information gets encoded into HTTP headers. This ASCII encoding of the header fields has lots of perks: it's human readable, it makes new applications easier to debug, and it makes logging packet information easy 🍓 The authors even say that if this gets widely adopted, tools like tcpdump will become obsolete 😭🔥
3.0 FEP Protocol 💅
Figure 1 gives a high level view of the protocol 🦋 The application (1) on host A (outside the Firewall) sends a TCP/IP datagram to host B (inside the firewall). A tunnel interface routes the TCP/IP datagram to the FEP software (2), which encodes the datagram inside an HTTP message. That message gets sent through an HTTP/TCP/IP tunnel (3) to host B on the normal HTTP port (4). When it arrives at host B, the packet gets routed through the tunnel to the FEP software (5), which decodes it and creates a TCP/IP datagram to insert into host B's protocol stack (6). The packet then gets routed to the application on host B (7), as if the Firewall (8) never existed 🌈
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 13.1 HTTP Method 🌸
FEP lets either side act like a client or a server. Each TCP/IP packet gets sent as either an HTTP GET request or a response to a GET request. This flexibility works well with firewalls that try to verify valid HTTP commands crossing the Firewall, which helps stop the unwanted interception of FEP packets 🫶
3.2 TCP Header Encapsulation: 💖
The TCP/IP packet gets 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 header, and optionally the IP header, is strictly for human readability, since the entire IP datagram is already encoded in the body part of the HTTP command 🧚
This proposal defines the following new HTTP headers for representing TCP header information. Let's go through them one by one, bestie 🎀
TCP_value_opt is an ASCII string that represents the encoding type for the TCP fields where a mandatory encoding type isn't specified. The legitimate values are:
TCP_binary💜 is the ASCII representation of the binary representation of the value of the field.TCP_hexed🌷 is the ASCII representation of the hex representation of the value of the field.
TCP_Sport 🦋 is the 16-bit TCP Source Port number, encoded as an ASCII string that represents the value of the port number.
TCP_Dport 🌈 is the 16-bit TCP Destination Port number, encoded as an ASCII string that represents the value of the port number.
TCP_SeqNum 🔥 is the 32-bit Sequence Number, encoded as an ASCII string that represents the hex value of the Sequence number. This field MUST be sent as lower case because it is not urgent 💀
TCP_Ackl ✨ is the 32-bit Acknowledgement Number, encoded as an ASCII string that represents the value of the Acknowledgement number.
TCP_DODO 🍓 is the 4-bit Data Offset value, encoded as an ASCII string that represents the base 32 value of the actual length of the TCP header in bits. (Normally this is the Data value times 32.)
TCP_6Os 🙈 is 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 that these characters MUST all be sent as "off" and MUST be ignored on receipt.) 🫶
TCP_FlgBts 👑 is the TCP Flags, encoded as a set of 5 comma-separated ASCII strings: [{URG|urg}, {ACK|ack}, {PSH|psh}, {RST|rst}, {SYN|syn}, {FIN|fin}]. Capital letters mean the flag is set, and lowercase means the flag is not set 🌸
TCP_Windex 🎀 is the 16-bit TCP Window Size, encoded as an ASCII string that represents the value of the number of bytes in the window.
TCP_Checkit 💅 is the 16-bit TCP Checksum field, encoded as an ASCII string that represents the decimal value of the ones-complement of the checksum field.
TCP_UP 🔥 is 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 😭
TCP_Opp_Lst 🌈 is a comma-separated list of any TCP options that may be present. Each option is encoded as an ASCII string that represents the name of the option, followed by option-specific information enclosed in square brackets. Here are some representative options and how they get encoded. Other IP options follow the same form 🧚
- End of Options option:
["End of Options"] - Window scale option:
["Window scale", shift_count], whereshift_countis the window scaling factor, represented as the ASCII string in decimal 🦋
3.2 IPv4 Header Encapsulation 🌐
okay so this part is where we get into the IPv4 header, and it's giving full detail mode 💅 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. 🎀
IP_value_opt: this ASCII string represents the encoding type for the following fields where a mandatory encoding type is not specified. The legitimate values are the same as forTCP_value_opt.IP_Ver: the IP Version number, encoded as a UTF-8 string. The legitimate values for the string are"four","five", and"six."The encapsulation of the fields in the IP header is defined in this section if the value is"four", and in section 3.3 if the value is"six". Encapsulations for headers withIP_Vervalue of"five"will be developed if the right orders are received. Encapsulations for headers with theIP_Vervalue of"eight"are empty. Implementations MUST be able to support arbitrary native languages for these strings. 🌸IP4_Hlen: the IP Internet Header Length field. It is encoded in the same way asTCP_DODO.IP4_Type_of_Service(this name is case sensitive): this is an obsolete name for a field in the IPv4 header, which has been replaced withIP_$$andIP_CU. 🥀IP_$$: the 6-bit Differentiated Services field, encapsulated as a UTF-8 string representing the name of the DS codepoint in the field. 💜IP_CU: the 2-bit field that was the two low-order bits of the TOS field. Since this field is currently being used for experiments, it has to be coded in the most general way possible. Thus it is encoded as two ASCII strings of the form"bit0=X"and"bit1=X,"where"X"is"on"or"off."Note that bit 0 is the MSB. 🔬IP4_Total: the 16-bit Total Length field, encoded as an ASCII string representing the value of the field. 📏IP4_SSN: the IP Identification field, encoded as an ASCII string representing the value of the field. 🪪IP4_Flags: the IP Flags, encoded as the set of 3 comma-separated ASCII strings:[{"Must Be Zero"}, {"May Fragment"|"Don't Fragment"}, {"Last Fragment"|"More Fragments"}]🚩IP4_Frager: the 13-bit Fragment Offset field, encoded as an ASCII string representing the value of the field. ✂️IP4_TTL: the 8-bit Time-to-Live field, encoded as a UTF-8 string of the form"X hops to destruction."Where"X"is the decimal value -1 of the field. Implementations MUST be able to support arbitrary languages for this string. 💀IP4_Proto: the 8-bit Protocol field, encoded as a UTF-8 string representing the common name for the protocol whose header follows the IP header. 🧩IP4_Checkit: the 16-bit Checksum field, encoded in the same way asTCP_Checkit. ✅IP4_Apparent_Source: the 32-bit Source Address field. For user friendliness, this is encoded as a UTF-8 string representing the domain name of the apparent sender of the packet. An alternate form, to be used when the domain name itself might be blocked by a firewall programmed to protect the innocence of the corporate users, is an ASCII string representing the dotted quad form of the IPv4 address. 🏢IP4_Dest_Addr: the 32-bit Destination Address field, encoded in the same way asIP4_Apparent_Source. 🎯IP4_Opp_Lst: a comma-separated list of all IPv4 options that are 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"] - Loose Source Routing option:
["Loose Source Routing", length, pointer, IP4_addr1, IP4_addr2, ...], wherelengthandpointerare ASCII strings representing the value of those fields. 🧭
- End of Options option:
3.3 IPv6 Header Encapsulation 🦋
okay the IPv6 era is here bestie 😭 This proposal defines the following new HTTP headers for representing IPv6 header information:
These optional headers encode the IPv6 [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. At this time only the base IPv6 header is supported. If there is sufficient interest, support will be developed for IPv6 extension headers. 🧚
IP_$$: the 6-bit Differentiated Services field. See above.IP_CU: the 2-bit unused field. See above.IP6_Go_with_the_Flow: the 20-bit Flow Label field. Since this field is not currently in use, it should be encoded as the UTF-8 string"do not care". 🫶IP6_PayLd: the 16-bit Payload Length field, encoded as an ASCII string representing the value of the field. The use of FEP with IPv6 jumbograms is not recommended. 🐘IP6_NxtHdr: the 8-bit Next Header field, encoded in the same way asIP4_Proto. 🔗IP6_Hopping: the 8-bit Hop Limit field, encoded in the same way asIP4_TTL. 🦘IP6_Apparent_Source: the 128-bit Source Address field. For user friendliness, this is encoded as a UTF-8 string representing the domain name of the apparent sender of the packet. An alternate form, to be used when the domain name itself might be blocked by a Firewall programmed to protect the innocence of the corporate users, is an ASCII string representing any one of the legitimate forms of representing an IPv6 address. 🏰IP6_Dest_Addr: the 128-bit Destination Address field, encoded the same way asIP6_Apparent_Source. 🎀
3.4 TCP Header Compression 🗑️
compressing TCP headers in the face of a protocol like this one that explodes the size of packets is silly, so we just ignore it 💅
4.0 Security Considerations 💀
okay this section is short but iconic 🙈 Since this protocol deals with Firewalls, there are no real security considerations.
⚠️ bestie, read that one again. The author is saying this whole protocol is built around Firewalls, and the document states there are no real security considerations. Please do not take this as permission to skip your own security review. 😭
5.0 Acknowledgements 🌈
we need to thank the many Firewall vendors who have supported this work to re-enable the innovation that made the Internet great, without giving up the cellophane fig leaf of security that a Firewall provides. 🫠 Truly a love letter.
6.0 Authors' Addresses 🖊️
Mark Gaynor Harvard University Cambridge MA 02138
EMail gaynor@eecs.harvard.edu
Scott Bradner Harvard University Cambridge MA 02138
Phone +1 617 495 3864 EMail sob@harvard.edu
References 📚
[1] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[2] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design". 2nd International Conference on Distributed Systems, Paris, France, April 1981.
[3] Eastlake, D., "IP over MIME", Work in Progress.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Clark, D. and M. Blumenthal, "Rethinking the Design of the Internet: The end-to-end argument vs. the brave new world". 2000.
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2001). 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 RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3093 2001-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms