Most people enjoyed the joke:
I take my hat off to you, absolutely terrific, haven't seen something this good since "TCP by pigeon"
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=Enteredand completely insecure machines:
01 April 2003# 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
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.
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.
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.
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.
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.
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?