Slashdot Mirror
RFC 3514: New Bit Defined for IPv4 Headers
RFC 3514
was just released, with a new bit definition for use in the headers of IP packets. Because there are important security implications, anyone coding internet services (on either the client or server end) should probably take a look.
Finally, the scriptkiddie bit! Now we'll be able to drop all that pesky DDoS traffic with ease!
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
The bit set to 1 indicates a pr0n site, the bit set to 0 indicates a non-pr0n site.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
blah blah blah
That SQL Server worm I've been working on. What bit was that again?
This is such an amazingly important invention, but you are 2 hours early on the release. No one was supposed to know that.
Darn! You have already thwarted my evil plans yet again.
~ kjrose
APR1L F00Lz!!!
jumping the gun on April Fools Day a bit, aren't we?
Microsoft have released a beowulf distro.
Linus has joined redhat.
Slackware is closing down.
Linux now runs on single entangled electrons at MIT
etc etc etc
Official GOD FAQ.
Apparently it does nothing to prevent Slashdotting.
Yavolle heir commandant!
that's gotta be a record. I know subscribers get early access, but geez!
What a strange bird is the pelican, his beak can hold more than his belly can.
Hmm, a little bit of this and a little bit of that. Sounds like an old recipe from my grandma..
I love April fool's day.
Perl programmers may want to check out their beloved cpan.org site today, too. :-)
Mirror 1
Mirror 2
To lighten the load.
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
It'll be the Router Admin Full Employment Act of 2003!
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
Does the DMCA impose penalties for modifying the bit?
Since the "evil" bit *MUST* be set in attack programs, I guess that will thwart all hacker attacks!! This RFC must have been sponsored by Micro$oft... After all, Microsoft makes hackers obsolete...
So saddam is part of TCP ?
First post with the Evil flag set. If you are reading this comment, Slashdot is not RFC3514-compliant.
And not the last....
[In case you don't wanna bother or it's Slashdotted, it's about designating bits "evil" or not. Not that funny IMO, compared to some other good RFCs.]
Last 4/1 the editors posted about 15 of these in a row. Moderators got punchy and the whole place went to... well... be prepared.
I was reading the txt, thinking this is the stupidest thing ever, before i realized it was April Fool's.
ARggghhhhhh
This is a very elegant solution to most of the internets security problems. This could even prevent DDoS attacks! Does anyone know when the patched version of the SQL Slammer worm will be available, or should I just drop my firewall and let it install itself?
SPAM
Please, please, please take this wonderful advance in technology and extend it to email. Then Spam can have a new header called "Evil: Yes". Then we can leverage the same technology to do perfect Spam filtering.
- Persnickity
Hey: it's still before midnight where I am! I'll need to take this seriously for the next couple of hours...
Call me old fashioned, but I like a dump to be as memorable as it is devastating - Bender
Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1.
Note to self: Remember to set "evil" bit to 1 when launching world domination attempt.
134340: I am not a number. I am a free planet!
If your cursor finds a menu item followed by a dash, and the double-clicking icon puts your Window in the trash, and your data is corrupted 'cause the index doesn't hash, then your situation's hopeless and your system's gonna crash!!
If the label on the cable on the table at your house says the network is connected to the button on your mouse, but your packets want to tunnel to another protocol that's repeatedly rejected by the printer down the hall, and your screen is all distorted by the side effects of gauss, so your icons in the window are as wavy as a souse; then you may as well reboot and go out with a bang, 'cuz sure as I'm a poet, the sucker's gonna hang!
When the copy of your floppy's getting sloppy in the disk, and the macro code instructions cause unnecessary risk, then you'll have to flash the memory and you'll want to RAM your ROM. Quick, turn off the computer and be sure to tell your Mom!
Blatently pinched from - Twisted Monkey Entertainment
_________________
Cheap Web Site Hosting - recommended by some worker posting on slashdot!
There are a number of ways in which the evil bit may be set. Attack
applications may use a suitable API to request that it be set.
Systems that do not have other mechanisms MUST provide such an API;
attack programs MUST use it.
In other news, Tom Ridge is introducing a bill into congress that requires all sleeper cell terrorists duct tape to themselves a peice of orange plastic so they can be easily identified and arrested by Federal authorities.
More info is here
http://saveie6.com/
Unfortunately the RFC neglects to define what levels of evil the values of the 128-bit strength indicator maps to.
Therefore I, on behalf of the United Corp^H^H^H^H^H States government, submit that the top values should be reserved for the following:
2^127-n
4: Unpatriotic activity.
3: Terrorism. For up to date definition, see www.dhs.gov
2: Attempt to secure personal communication by encryption
1: Circumvention of copy protection mechanisms for purposes of piracy
0: Circumvention of copy protection mechanisms for purposes of "fair use"
Note that the last bit is reserved to indicate whether the packet originates from a foreign country.
My Sig: SEGV
Cached in my journal
It's April Fools time already! Even our favorite site is getting into the act.
Now we were really rolling on the floor laughing on that one. Is there a link explaining why they chose that theme?
The fine print: Aforementioned crimes are only illegal in Afghanistan and include, but are limited to, allowing women to walk around without being entirely concealed under a table cloth, teaching children how to read and write, and singing nursery rhymes.
East coast time, its not April 1st yet. Shouldn't you wait a couple more hours before posting these?
Here
Also note that it's actually based on the ideas initially developed by HTCPCP protocol, which just turned 5 years.
3.243F6A8885A308D313
An attacker can take advantage of the quantum nature of reality to set this bit to an indeterminate/combined value influenced by the nature of the observer of the packet. An observer who knows the evil nature of the sender of the packet will see the "evil" bit set to one, as it should be. However, unsuspecting observers, including firewalls and potential victims, will see the bit set to zero and be fooled.
The inherent subtlety of this attack is revealed by considering what happens when a security expert attempts to analyze the attack. As soon as he recognizes the evil nature of the attacker, the packets appear to have the 'evil' bit set, and his firewalls start dropping the packets, depriving him of further packets for analysis. The attack is thus even more precisely targeted towards the naive than an attack on Microsoft IIS.
Now when I write my viruses and attacking applications I'll set the evil bit to 0... I'M A GENIUS, NO ONE WILL KNOW IM EVIL!! MWUAHAHAHAA
Bellovin Informational [Page 1]
RFC 3514 The Security Flag in the IPv4 Header 1 April 2003
The bit field is laid out as follows:
0
+-+
|E|
+-+
Currently-assigned values are defined as follows:
0x0 If the bit is set to 0, the packet has no evil intent. Hosts,
network elements, etc., SHOULD assume that the packet is
harmless, and SHOULD NOT take any defensive measures. (We note
that this part of the spec is already implemented by many common
desktop operating systems.)
0x1 If the bit is set to 1, the packet has evil intent. Secure
systems SHOULD try to defend themselves against such packets.
Insecure systems MAY chose to crash, be penetrated, etc.
3. Setting the Evil Bit
There are a number of ways in which the evil bit may be set. Attack
applications may use a suitable API to request that it be set.
Systems that do not have other mechanisms MUST provide such an API;
attack programs MUST use it.
Multi-level insecure operating systems may have special levels for
attack programs; the evil bit MUST be set by default on packets
emanating from programs running at such levels. However, the system
MAY provide an API to allow it to be cleared for non-malicious
activity by users who normally engage in attack behavior.
Fragments that by themselves are dangerous MUST have the evil bit
set. If a packet with the evil bit set is fragmented by an
intermediate router and the fragments themselves are not dangerous,
the evil bit MUST be cleared in the fragments, and MUST be turned
back on in the reassembled packet.
Intermediate systems are sometimes used to launder attack
connections. Packets to such systems that are intended to be relayed
to a target SHOULD have the evil bit set.
Some applications hand-craft their own packets. If these packets are
part of an attack, the application MUST set the evil bit by itself.
In networks protected by firewalls, it is axiomatic that all
attackers are on the outside of the firewall. Therefore, hosts
inside the firewall MUST NOT set the evil bit on any packets.
Bellovin Informational [Page 2]
RFC 3514 The Security Flag in the IPv4 Header 1 April 2003
Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil
bit on such packets. "Transparent" http and email proxies SHOULD set
the evil bit on their reply packets to the innocent client host.
Some hosts scan other hosts in a fashion that can alert intrusion
detection systems. If the scanning is part of a benign research
project, the evil bit MUST NOT be set. If the scanning per se is
innocent, but the ultimate intent is evil and the destination site
has such an intrusion detection system, the evil bit SHOULD be set.
4. Processing of the Evil Bit
Devices such as firewalls MUST drop all inbound packets that have the
evil bit set. Packets with the evil bit off MUST NOT be dropped.
Dropped packets SHOULD be noted in the appropriate MIB variable.
Intrusion detection systems (IDSs) have a harder problem. Because of
their known propensity for false negatives and false positives, IDSs
MUST apply a probabilistic correction factor when evaluating the evil
bit. If the evil bit is set, a suitable random number generator
[RFC1750] must be consulted to determine if the attempt should be
logged. Similarly, if the bit is off, another random number
generator must be consulted to determine if it should be logged
despite the setting.
The default probabilities for these tests
Is it time to bring out the April Fools Day Tree yet?
Should I start opening the April Fools Day gifts?
Serious question: Will this bit work over Carrier Pigeon?
And one other thought, will Windows2003Server recognize it? Oh...they'll have to release the Service Pack because anything set to 0 won't get through because of a buffer overflow extension illegal operation segfault doo-hickey.
Any other cliches missed?
I liked this bit (emphasis mine):
NGWave - Fast Sound Editor for Windows
Comment removed based on user account deletion
I was actually wondering how this would help... Now I understand why.
;-)
Trust me, this program is not malicious.
LedgerSMB: Open source Accounting/ERP
From the SHOULD dept. Something like this should happen, though I think its one of those "shoulda-know-better" things your mother told you about.
Some dude was sending hidden messages in them.
I read that on Slashdot, so it may or may not be true.
If only it was that easy to detect evil intent in real life...
"Sally, cross your legs! His bit is set to 'evil'!"
On second thought...
"Watch your cornhole, bud."
and then, I thought, "this kind of obvious trolling only comes around April".
A little bit early jamie (all the pun intended).
~the keyboard is mightier than the pen.
I sent an email to my TCP/IP professor asking if he could explain this RFC to us in class because I couldn't understand it, and he wrote back saying I just earned an F. ^^;;
[o]_O
I don't think 256-bits of evilness strength and type code will be enough granularity for the amount of variety observed in the way certain popular operating systems crash in response to an attack.
Actually I think somebody famous* established long time ago that sex, as strange as some of its involved rituals may seem to many at times, are a better alternative to war.
.gov extension has the eBit** set.
I propose that instead anything coming from or going to a
*note: Larry Flint. Watch the movie.
**I hereforth trademark this name.
My life in the land of the rising sun.
geek humor is so the opposite of funny
Now, if Goldberg isnt really going to be at backlash, and that's an april fools joke, then THAT would sure suck.
I don't need no instructions to know how to rock!!!!
I think I will set it for the IIS servers anyway. I can remove it the day Microsoft stops adding sabotage code to their products.
Anyone care to place a bet? I need the URL of those 'Betting Pool' web sites. This one will need to run until at least the year 2050....
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
Note to self: Remember to set "evil" bit to 1 when launching world domination attempt.
Which makes me think: Will the cable company terminate my account if I forget to set the evil bit when I am DDoSing someone, as a TOS violation?
Tequila: It's not just for breakfast anymore!
You'll have to write a RFC, and until then, you'll have to use "X-Evil:" instead and hope it catches on.
"Don't worry, it's not loaded." --Terry Kath
First this and now I noticed the W3C added an addendum to HTTP 1.1:
10.5.4.1 503.1 Slashdotted
The server is currently unable to handle the request due to a fucking slashdotting of the server. Visit slashdot.org for potential mirrors.
There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.
Potentially devastating Y10k problem
Lifesaving method to temporarily reroute ip in cause of equipment failure
Protocol to guarantee software engineer productivity and efficiency
Addressing ipv6 with incredible bandwidth savings
Planning ahead to Star Trek technology with current protocols and infrastructure
I don't even know what this one is about...
And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...
"This is Zombo Com, and welcome to you who have come to Zombo Com" - www.zombo.com
The US Patent Office rejects "Evil Bit" patent...
Gentoo Weekly Newsletter contains the worst april fools' joke in existence
Does this mean I wont be able to run my Windows update through my firewall now?
Ahh.. I love the smell of an April Fool's Joke first thing in the morning ;) (Seriously people - an EVIL bit and you expect people to honour it? Heh.. I wish! ). While we are at it - can we have a PR0N, VIRUS and SPAM bit as well? I would make my job so much easier ;)
Snowy Angelique Maslov - http://www.snowy.org/
I think I better post a few mirrors:
Mirror #1
Mirror #2
Mirror #3
The last one is pretty fast. Try and use one of these instead of the main site!
there is just a bit of evil in everyone's head.
Our IT group must have contributed to this RFC! Now I know exactly what to think of it...
is competition good, or is duplication of effort bad?
Enough about the evil bit, where are the "naughty bits"?
I see even classic Slashdot is now pretty much unusable on dial up anymore.
The Evil Flag in the IP Header, LOL
Well at least I know to take nothing on Slashdot seriously for about 30 hours or so...
"Oh my God. This is terrible. This is the end of my Presidency. I'm fucked."; ~ Donald J. Trump
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
Date==1April2003
Had me going for a while there.
political_news.c: warning: comparison is always true due to limited range of data type
I bet we could get the US Congress to pass a law making it illegal to set this bit incorrectly.
Anyone know how the google news engine picks its headlines? This should go mainstream...
This isnt real??
Darn.
I am going to be distributing this at the office tomorrow and announcing that all of our hardware is going evil-bit-compliant. This is going to rock!
Ah yes, the annual "Slashdot is Even Less Readable than Usual Day." Seriously, why the fuck can't all the idiotic and 99% unfunny April Fool's "stories" be aggregated into one story so that other non-idiotic stuff can be posted?
OK, my question is which part of the joke did you not get? ;-)
LedgerSMB: Open source Accounting/ERP
Fooled you - with my stupid bit~!
have we forgotten that evil people often masquerade in sheep's clothing????
stupid!
joshua
3514 translated into l337 sp34k is ESIA... Doesn't ring a bell, but Egoistic Scriptkiddy Ignoring Annihilation seems to fit...
Please direct all bug reports to
Is this just me, or is this April's fool RFC kind of lame? I personally like the IP over Avian network. Anyone out there has a personal favorite?
I won't comment on the legitimatcy of the article due to the date (4/1) but, this RFC seems to be technically perfect, but flawed in every other way.
Attacking systems MUST set the "evil" bit. Secure systems MUST drop the packets, insecure systems MAY chose their action -- drop, crash, give in.
Basically, this system, you give implicit trust to the remote system on the end of the communications, and let that system determine the security your own network will take in response to the communications.
Let one malicious user not flag his attack packets as evil, and the remote network will let him right in.
Sounds like a plan!
...we don't celebrate April Fools.
...and with karma to burn... who said life isn't perfect?
Some link layers, notably those based on optical switching, may bypass routers (and hence firewalls) entirely. Accordingly, some link-layer scheme MUST be used to denote evil. This may involve evil lambdas, evil polarizations, etc.
The great advantage of having a reputation for being stupid: People are less suspicious of you.
At least wait the hour and a half until April 1st.
and responding accordingly you can prevent access of evil packets.
Sigs are bad for your health.
What a concept. Lets just force the hackers to mark their packets as EVIL.
:)
Funny, reminds me of the Arian Carrier RFC
Jamey Kirby
Back to the RFCs: the list above doesn't seem exhaustive. I found some more: 12 networking truths RFC, telnet randomly lose option and Hyper Text Coffee Pot Control Protocol
i got to:
" There are a number of ways in which the evil bit may be set. Attack
applications may use a suitable API to request that it be set.
Systems that do not have other mechanisms MUST provide such an API;
attack programs MUST use it."
Funny.
The 1st of appril is here =)
:)
Damn. I took is seriously for the first 5 lines
Bot Assisted Blogging
To solve this problem, we define a security flag, known as the "evil" bit, in the IPv4 [RFC791] header. Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1.
Oh great! So now my firewall can at least tell me whether it likes a packet or not!
$DEITY bless $NATION
somebody set this thing to "Evil."
Thank you.
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
In my timezone, it is currently 10:30 of March 31st. Shouldn't the Internet community wait until it is April 1st everywhere before trying to implement this suggestion?
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
Is anyone else sick to death of all this april the first BS?
It's just not funny any more.
Next year I'm not even opening a web browser.
I want to call your attention to the fact that
:) (In case you took one word of the above seriously...Happy April Fools Day from Kentucky! )
the Winsock32 stack in Windows 98 build 950B
is sensitive to setting this high-order bit. I can
appreciate the humor of the RFC, BUT DO NOT SET THIS
BIT on packets inbound to legacy hosts running this
operating system!
This is related to the infamous TCPNODELAY stack
exploit in the same OS. Patched systems should be okay.
I would document this vulnerability in my own RFC,
but unfortunately the textarea is too small to contain it without comment overflow.
Gates' Law: Every 18 months, the speed of software halves.
Fellow /.ers may recollect the
"cool scientific paper" where the authors bomb DRAM chips with Xrays or more simply with 50-watt spotlight bulb to exploit Java and .NET virtual machines. That attack is very relevant to this new scheme proposed in this RFC.
What if the new security bit flips? Wow! I just improved my result from 70% to 100% !!! I should waste no time in typing my latest paper.
--Sudhakar.
It seems to me that by setting the EVIL bit, a packet thereby becomes less evil, in fact not evil at all, and thus should set the bit to 0, but of course then it would be truly evil, and back at square one are we.
My head spins along with this bit. Can someone please clear this up? Is it a bit intended only for quantum computers?
Infuriate left and right
Oh sure, turn their servers into slag!
One line blog. I hear that they're called Twitters now.
http://www.theage.com.au/articles/2003/03/31/10489 62694949.html
The Singularity is closer than you think
Quant
your friendly NRA
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.
I haven't read the second edition but the first I read shortly after setting up my first Linux server and reading O'reiliey's TCP/IP book. I read it cover to cover (no, really) and thoroughly enjoyed it. It is a great book for those that are interested in network security; it has well told stories and good examples of best practices. I especially liked the way they described their logging machine: A server connected via a cat five wires that had seven of the eight pairs cut! The only pair left was the receive pair. Bad for TCP / good for UDP.
Happy 4/1 (or 1/4 in Europe)
Restore America: Dr. Ron Paul for President!
You bastards!
I don't want knowledge. I want certainty. - Law, David Bowie
Enjoy! :-)
I had got quite far into this before I realised you were taking the piss. Then finally the incredulity reached the tipping poinbt and my synapses connected the date with the ludicrous nature of the RFC. But, I admit it, you had me going for quite a bit...
There now exists a patch for nmap which sets the evil bit on by default, available here
also, more discussion on when the evil bit should be set.
HA HA...
If anyone actually believed this... then I have a bridge for sale in SF.
If you dont like what I am saying, well then why dont you +++ATH0
ho ho.
Can we call the evil bit the "ming" bit instead?
It's not you: I'm just this horrifically socially awkward with everybody.
Network Working Group S. Bellovin
.
Request for Comments: 3514 AT&T Labs Research
Category: Informational 1 April 2003
The Security Flag in the IPv4 Header
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 (2003). All Rights Reserved.
Abstract
Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases.
1. Introduction
Firewalls CBR03 , packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. The problem is that making such determinations is hard. To solve this problem, we define a security flag, known as the "evil" bit, in the IPv4 RFC791 header. Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1.
1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119
2. Syntax
The high-order bit of the IP fragment offset field is the only unused bit in the IP header. Accordingly, the selection of the bit position is not left to IANA.
The bit field is laid out as follows:
0
+-+
|E|
+-+
Currently-assigned values are defined as follows:
0x0 If the bit is set to 0, the packet has no evil intent. Hosts, network elements, etc., SHOULD assume that the packet is harmless, and SHOULD NOT take any defensive measures. (We note
that this part of the spec is already implemented by many common desktop operating systems.)
0x1 If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc.
3. Setting the Evil Bit
There are a number of ways in which the evil bit may be set. Attack applications may use a suitable API to request that it be set. Systems that do not have other mechanisms MUST provide such an API; attack programs MUST use it.
Multi-level insecure operating systems may have special levels for attack programs; the evil bit MUST be set by default on packets emanating from programs running at such levels. However, the system MAY provide an API to allow it to be cleared for non-malicious activity by users who normally engage in attack behavior.
Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an intermediate router and the fragments themselves are not dangerous, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet.
Intermediate systems are sometimes used to launder attack connections. Packets to such systems that are intended to be relayed to a target SHOULD have the evil bit set.
Some applications hand-craft their own packets. If these packets are part of an attack, the application MUST set the evil bit by itself.
In networks protected by firewalls, it is axiomatic that all attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets.
Because NAT RFC3022 boxes modify packets, they SHOULD set the evil bit on such packets. "Transparent" http and email proxies SHOULD set the evil bit on their reply packets to the innocent client host.
Some hosts scan other hosts in a fashion that can alert intrusion detection systems. If the scanning is part of a be
748, 1097, 1149, 1313, 1437, 2549.
This isn't exhaustive, the coffee-brewing protocol is missing &c.
I like 2549 with the ascii-art pigeon.
Damn this globalisation
Art is the mathematics of emotion
So damn uncreative - not the RFC, which was quite good, but the /. crew.
/. crowd - fake a new release of Geeks In Space, consisting of nothing but low-level ambient noise for 20 minutes followed by a loud "April Fool!" at the end.
I'd emailed Rob with the perfect April Fool's joke to play on the
You all see the (absence of) result.
www.eFax.com are spammers
That was one of the rare things I run across on the internet that literally have me rolling on the floor laughing...Everyone in the library was staring at me. :) Ack...The librarian's coming in this direction...but it's the EVIL BIT! THE EVIL BIT!
There used to be a "security" bit you could use to mark you packets as especially interesting (the do-not-route-thru-Iraq-bit) [rfc 791]. Is that feature obsoleted by this evil?
If people don't protect their systems by checking this bit, and malicious packets ARE sent with this bit set, does this mean that they are partially responsible for any damage caused by the malicious packet? Are software vendors responsible for handling these packets properly? I can see the headlines now. Longhorn machine compromised by "evil" packets, Microsoft sued. From what I understand, even if MS is found 1% responsible and the attacker 99% responsible, MS would have to pay the majority of a large judgement since MS would almost certainly have more money than the attacker.
The router that implements this evil bit could send the packets to Write-Only-Memory.
"In 1972 Signetics recognized April Fools day by printing a full color datasheet for a Write-Only Memory. This is a chip which accepts data but never reads it back. Suggested uses include a data logger for bombs. Graphs show "number of pins left versus number of insertions" and other useful data. A couple of pins are dedicated to 6.3 volt AC input... for the filaments, of course! A scanned version is here (page 1) and here (page 2) (these are 150k .JPGs)."
It wasn't april 1st yet when you posted this. C'mon, if you are going to go with slashdot tradition, at least be a bit clueful. And yeah, I know it's not entirely the poster's fault, the RFC was released to soon too, but it just shows that, as usual, most /. posters can't spot a real april fools day joke if it ran up and smacked them right in the head.
Oh yeah, and, by by karma. Whatever.
Not to be outdone, Steve Balmer of Microsoft has announced the development of the "ActiveEvil" standard, which is claimed to be compatible with RFC3514 but offers several advantages. A new version of Windows XP incorporating this standard is due to be released in March 2003.
Critics of the new MS standard claim that it will not be entirely compatible with RFC3514. Apparently, while ActiveEvil generates the "evil bit" correctly, it adds a "lawful bit". Servers using ActivEvil will not respect the evil bit from clients unless the lawful bit is also set correctly.
There is also speculation that MS may be secretly developing a new application suite called "/evil" to take advantage of this standard. Applications in this suite would include a bulk mailer, a web server, a Quake 1 client, and an IRC client. These applications would be available remotely to annonymous users, and would all communicate in "evil mode".
I boycott Dr. Seuss Enterprises because it submitted an amicus brief supporting the Bono Act. A K5 user once pretended to channel Dr. Seuss:
Nothing is offtopic on April Trolls Day!
Will I retire or break 10K?
enough, this have been posted FOUR separate times so far:
h tm l
t ml
h tm l
h tm l
http://slashdot.org/articles/03/04/01/0218226.s
http://slashdot.org/articles/03/04/01/133217.sh
http://slashdot.org/articles/03/04/01/1434209.s
http://slashdot.org/articles/03/04/01/1440230.s
....what about pen tests.... they may be doing evil but have no evil intent... we need a pseudo-evil bit too!
I bet we can this one trhough the U.S. patent office :)
If the IP headers were jumping, couln't we set the Evil Knievel bit?
This is wierd. So now the hacker will set his evil bit to 1 because he is evil? and who will make sure he dont send it as 0. The only use I see of this is to distinguish to a server in a autonomous system that the packet originated internally or its an external packet. So the server can make distinction based on the bit to its behaviour. Is that what this bit is intended for??