Slashdot Mirror
IPv4 Headers Investigated
An anonymous reader writes "New security measures are being suggested (see RFC 3514) for the IPv4 header. The measures include a bit that can be set and unset according to whether the packet is secure or not. Due to the important security implications, anyone coding client/server internet applications might want to take a look."
April Fool's or not, this may be a record for a duplicate... the previous story was a whole THREE entries below this one on the homepage...
There! I claim it in the name of the third dupe! So we've already had a dupe and a tripe, perhaps we call this...hmm, what's a good name for a fourth dupe?
This sig no verb.
Why am I always the last to know about these things. I try and keep up to date about technology matters, but I've missed out on this. I wish that I could have seen this one coming.
OK...
I can do this. I am, after all,
a superhero!
Seems clear that this is going to be a running gag throughout the day. Any bets on how many total we'll have?
It's April 1st. I wonder if Taco's gonna do anything out of the ordinary today for April Fool's Day?
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
For more information, click here.
I read somewhere today that there's a new RFC out regarding IP header bits--you can set and unset a particular bit to determine the packet's overall security. I haven't seen it linked anywhere yet, and I'm considering sending it in to the editors, but I can't find their address.
This is something I think they'd be very interested in.
We need a new flag implemented into the Slashdot system that will indicate whether or not the story is a dupe. It can be preset to DUPE=1 to save everyone trouble.
Might as well take advantage of Taco's amnesia... I've now submitted the story again, and expect my version of it to be the 6th or 7th posting. Maybe I'll finally break the karma barrier this way!
Is that there's a bunch of duplicate stories, and people can't tell if it's April Fools, or just business as usual...
Taco Trolls the main slashdot site.
"This is the fourth time I have seen this story.
It is getting less and less funny."
Perhaps if y'all didn't act like Slashdot commited a mortal sin whenever the occasional dupe occured, Taco wouldn't have found this joke so amusing. Mmmm?
Frankly I think it's hilarious. I hope you all have learned a lesson now. Stop bitching about story dupes or this joke'll be around next year too.
You don't see the pattern here?
Story
Story
Dup Evil bit
Story
Story
Dup Evil bit
It'll be pretty much like this all day, today. And people were annoyed with the plethora of Apr. 1 gags last year. The Peter Jackson/King Kong is real, afaik, as it's been in the news the prior couple days. (How did that one slip through?)
In other news:
A feeling of having made the same mistake before: Deja Foobar
And i have proof!
hehe
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
Next Year? Ha!
I'm betting on tomorrow.
Any sufficiently well-organized Government is indistinguishable from bullshit.
At long last, we know for certain that Taco does hear our plea: "Stop with the duplicate stories already!"
:)
He just doesn't care.
Now THAT is comedy.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
"This is the post that doesn't end,
yes it goes on and on my friends.
Ol' Taco started posting it, not knowing what it was,
And he'll continue posting it forever just because,
This is the post that doesn't end,
yes it goes on and on my friends..."
Tripes and quadrupes are new though.
I don't know about quadrupes, but they do post tripe rather frequently.
I take drugs seriously.
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 benign research project, the evil bit MUST NOT be set
I kinda like The Matrix Lower Upper Decomposition, and the electro-political thriller Gaussian Elimination.
[
Is everybody ready for the internet cleaning day?
C'mon, though really...it was funny the first time. Humorous the second, but come ON....Are you going for a record or something?
Actually, hell...it's probably a reference to something mentioned in the RFC(j)...I just haven't taken the time to read it yet.
There is a reason for everything. Sometimes that reason just sucks.
You forgot The Matrix: Spectral Decomposition.
There is a secure option that can be used in the IP header.
t .h tml#secure
http://www.ee.siue.edu/~rwalden/networking/ipop
00000000 00000000 - Unclassified
11110001 00110101 - Confidential
01111000 10011010 - EFTO
10111100 01001101 - MMMM
01011110 00100110 - PROG
10101111 00010011 - Restricted
11010111 10001000 - Secret
01101011 11000101 - Top Secret
00110101 11100010 - (Reserved for future use)
10011010 11110001 - (Reserved for future use)
01001101 01111000 - (Reserved for future use)
00100100 10111101 - (Reserved for future use)
00010011 01011110 - (Reserved for future use)
10001001 10101111 - (Reserved for future use)
11000100 11010110 - (Reserved for future use)
11100010 01101011 - (Reserved for future use)
Ride that dead horse! Ride 'im, boy!
I'm employing a Full Software Development Life Cycle Methodology (FSDLCM) with Extreme Programming to modify my TCP stack for an Evil Bit Payload Control System(EBPCS). Using the latest Rational Tools I've already made several lengthy iterations on a UML modeling with advanced design patterns including the Inactive Observer and Simpleton Factory. The enabling features of Rational Rose groupware has empowered everyone from marketing to sales and janitorial staff to participate and pool their synergism in the IT architectural process. ~
Then again....
Restore America: Dr. Ron Paul for President!