Reactions to RFC 3514

A few years ago, I wrote RFC 3514, an April 1 RFC.  I received lots of email, and even a few phone calls.  Here are some of the responses I got, unedited except for the senders' names. (You can read a press report of the reactions here.)

Most people enjoyed the joke:

Steven,
I take my hat off to you, absolutely terrific, haven't seen something this good since "TCP by pigeon"

Thanks

congratulations - well done!

One response was a bit worrisome...

Good day sir. Nice contribution for this April 1st.

But your jest, were there a reserved bit that actually could be used, could actually have merit to address a concern on the part of major content providers about internet redistribution of broadcasters' content.

So, you may see this again.... Happy April Fools Day.

One response was rather, umm, "interesting".  I never knew that RFCs could inspire this sort of thought.

I was reading your info about the proposed RFC and my mind and fingers strayed to check out my own evil bit...

I've just got my breath back. Shouldn't there be a health warning about playing with your own bits?

Some people implemented portions of it, or suggested extensions:

Not hard to implement the receiving end. The difficult part will be to make the API for the malicious content sufficiently easy that hackers will willingly, nay, joyfully implement it.

Here is the mailcap entry for 'mutt' to implement proper handling of the MIME type for both designated secure machines: 

# RFC-3514-compliant MIME attachment handling - secure version
application/msword; true; \
	print=true; \
	notes=Entered  01 April 2003
and completely insecure machines: 
# RFC-3514-compliant MIME attachment handling - insecure version
application/msword; %s; \
	print=%s; \
	notes=Entered  01 April 2003


mdodd       2003/04/01 00:21:44 PST

  FreeBSD src repository

  Modified files:
    sbin/ping            ping.8 ping.c 
    share/man/man4       inet.4 ip.4 
    sys/netinet          in.h in_pcb.h ip.h ip_input.c ip_output.c 
                         ip_var.h 
    usr.bin/netstat      inet.c 
  Log:
  Implement support for RFC 3514 (The Security Flag in the IPv4 Header).
  (See: ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt)
  
  This fulfills the host requirements for userland support by
  way of the setsockopt() IP_EVIL_INTENT message.
  
  There are three sysctl tunables provided to govern system behavior.
  
          net.inet.ip.rfc3514:
  
                  Enables support for rfc3514.  As this is an
                  Informational RFC and support is not yet widespread
                  this option is disabled by default.
  
          net.inet.ip.hear_no_evil
  
                   If set the host will discard all received evil packets.
  
          net.inet.ip.speak_no_evil
  
                  If set the host will discard all transmitted evil packets.
  
  The IP statistics counter 'ips_evil' (available via 'netstat') provides
  information on the number of 'evil' packets recieved.
  
  For reference, the '-E' option to 'ping' has been provided to demonstrate
  and test the implementation.
  
  Revision  Changes    Path
  1.47      +4 -2      src/sbin/ping/ping.8
http://cvsweb.FreeBSD.org/src/sbin/ping/ping.8.diff?r1=1.46&r2=1.47
  1.92      +13 -1     src/sbin/ping/ping.c
http://cvsweb.FreeBSD.org/src/sbin/ping/ping.c.diff?r1=1.91&r2=1.92
  1.21      +11 -0     src/share/man/man4/inet.4
http://cvsweb.FreeBSD.org/src/share/man/man4/inet.4.diff?r1=1.20&r2=1.21
  1.29      +9 -0      src/share/man/man4/ip.4
http://cvsweb.FreeBSD.org/src/share/man/man4/ip.4.diff?r1=1.28&r2=1.29
  1.75      +2 -0      src/sys/netinet/in.h
http://cvsweb.FreeBSD.org/src/sys/netinet/in.h.diff?r1=1.74&r2=1.75
  1.59      +1 -0      src/sys/netinet/in_pcb.h
http://cvsweb.FreeBSD.org/src/sys/netinet/in_pcb.h.diff?r1=1.58&r2=1.59
  1.22      +1 -0      src/sys/netinet/ip.h
http://cvsweb.FreeBSD.org/src/sys/netinet/ip.h.diff?r1=1.21&r2=1.22
  1.232     +14 -0     src/sys/netinet/ip_input.c
http://cvsweb.FreeBSD.org/src/sys/netinet/ip_input.c.diff?r1=1.231&r2=1.232
  1.181     +28 -1     src/sys/netinet/ip_output.c
http://cvsweb.FreeBSD.org/src/sys/netinet/ip_output.c.diff?r1=1.180&r2=1.181
  1.72      +1 -0      src/sys/netinet/ip_var.h
http://cvsweb.FreeBSD.org/src/sys/netinet/ip_var.h.diff?r1=1.71&r2=1.72
  1.57      +1 -0      src/usr.bin/netstat/inet.c
http://cvsweb.FreeBSD.org/src/usr.bin/netstat/inet.c.diff?r1=1.56&r2=1.57
There's a Linux implementation that always sets the bit.
Unfortunately, it turns out that there are sites that always block such packets. It's presumably a firewall that follows an adage from a Larry Niven story: "The moral of this story is, anything you don’t understand is dangerous until you do understand it." Bill Cheswick and I quoted that line in Chapter 1 of Firewalls and Internet Security: Repelling the Wily Hacker.
A correspondent suggested that the evil bit could be used as part of so-called Lawful Intercept mechanisms:

I've forwarded a link to your RFC to the ETSI TC LI group that is working on LI for IP. I've proposed that the ISP or LEA only intercept packets with the E-bit set to "0x1". Your proposal has done a great service to mankind to determine once and for all which packets should be intercepted.

;-)

We can even link this RFC to older RFCs of the same type:

Hi,

In RFC 3514 you don't appear to discuss the conditions that will cause the so called evil bit to be set.

This may be considered a serious deficiency in your proposal.

However, if we combine RFC 3514 with RFC 2549 (which updated RFC 1149), then a carrier with suitable conditioning can be made to detect evil intent and set the bit accordingly.

Another variation of 2549, using a K9 carrier can be made particularly effective by biting the attacker as well as setting the evil bit.

Juniper routers can almost do evil bit filtering:

Technically the CF does have the ability to see 'any bit in the first 21 bytes' of an IP packet... (I believe it's 21 bytes at least). The limitations on the software installed, however, keep you from doing the arbitrary bit field/offset business.

But some people didn't quite get it...

Is Request for Comments 3514 an April fool's joke? I'm trying to convince my colleague here that it is, and I thought I'd go straight to the source for the answer.

Thanks,

(deleted)
Senior Network Administrator

You've gotta be kidding me. I didn't think that there would ever be a false RFC....Well, that just proves what I said in the first place: I don't know enough about the internet.

Good Afternoon,

What or who determines the "evilness" or "goodness" of the packet? If a security admin or OS can determine or flag bits as good, what keeps the hacker from spoofing this process by setting the bit to "good"? Does the bit change based on behavior? Or maybe a database with signatures of "bad" bits?

(name deleted)
Microsoft Corporation