RFC Prophecies

Contributed By: Mrs. Y

The other day a few of us at work were looking through the April Fool’s RFCs. If you haven’t seen them, they’re only for the most dedicated nerds. Almost every year, on April 1st, the IETF publishes facetious RFCs. It’s a tradition that started in 1973 with the Arpawocky RFC, which was a parody of Lewis Carroll’s Jabberwocky.

Beware the ARPANET, my son;

The bits that byte, the heads that scratch;

Beware the NCP, and shun the frumious system patch,

I’ve generally seen them referenced by subversive engineers in project or team meetings to make a point about the absurdity of an endeavor. It’s an inside joke and usually goes right over everyone’s head, except for the other engineers, of course. One of the most popular is the IP over Avian Carriers (IPoAC) RFC* and in 2001, the Bergen Linux User Group set up a proof-of-concept.

Avian carriers can provide high delay, low throughput, and low altitude service. The connection topology is limited to a single point-to-point path for each carrier, used with standard carriers, but many carriers can be used without significant interference with each other, outside of early spring. This is because of the 3D ether space available to the carriers, in contrast to the 1D ether used by IEEE802.3. The carriers have an intrinsic collision avoidance system, which increases availability. Unlike some network technologies, such as packet radio, communication is not limited to line-of-sight distance. Connection oriented service is available in some cities, usually based upon a central hub topology.

Now THAT’S a group of dedicated geeks!

Some of these joke RFCs are funnier than others, some are just weird, but I’ve also come across a few that are oddly ironic or prophetic, such as The Twelve Networking Truths:

Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.

or the one which gave me the shivers, The Firewall Enhancement Protocol (FEP), from 2001.

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.

Wait a second. Users actually DO this on networks with applications like BarbaTunnel and HTTPTunnel. In fact, people do all kinds of things to subvert firewall rules. The only funny part of that RFC is how ineffective firewalls have truly become.

*That’s a pigeon.

Cross-posted from PacketPushers.net


Today’s post pic is from Topsy.com. See ya!

4 comments for “RFC Prophecies

  1. May 9, 2012 at 4:02 pm

    BLOGGED: RFC Prophecies http://t.co/wYppFHzE

  2. May 9, 2012 at 11:00 pm

    BLOGGED: RFC Prophecies http://t.co/TFnF0w54 //In case you missed it.

  3. May 10, 2012 at 3:01 pm

    And from yesterday “RFC Prophecies” from @MrsYisWhy http://t.co/wYppFHzE

  4. May 10, 2012 at 3:01 pm

    And from yesterday “RFC Prophecies” from @MrsYisWhy http://t.co/TFnF0w54

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.