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
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
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
Smelly? There is nothing nicer than to smell a twostroke. Compare with desil or petrol engines!
Besides all this talk of us running out of oil is poppycock! If it looks like we're running out - the USA and UK will just invade another middle eastern country! - oh wait...
So hands up how many people will pay £400 and up for a new phone ?
Phone contracts subsidises the cost of a new phone, admittedly in the uk and my provider I can choose from a large range of phones, some "Free" (end of line, or stupidly basic, or just crap)
I'm seriously looking about getting one of the newer Nokias or Sony T800 symbian thingies.
Why? Well, I've been a Palm OS fan for ages, and have been waiting for a while to get a decent PDA and phone combo together.
At least now the phone PDA thing is starting to take off, the ability of my phone/PDA being able to run programs *I* want without stupid signing of apps any, being able to run java, ssh etc is very neat.
Just waiting for early adopters to tell me about battery life, and what it's like for data entry etc.
We, my friend, had to input our code using dip switches, 1 byte at a time. And heaven forbid that you make a mistake near the end of the program, 'cause then we had to start all over.
You had dip switches, when I was a lad, we had to code using plugboards!
No doubt if aliens find it and come to earth, Bush will demand they disarm all their weapons of mass destruction. Not to mention that he would align them with the axis of evil, and then the media will show them eating children and small pets.
Could they not, in fact write a small game and have it embed grub/lilo so it could boot off a HD partition/file instead ? I'm sure you could work around such things easily enough.
But M$ Bought interix, because they were the only company that cared enough to provide a better posix subsystem than M$ did.
[semitroll] God knows why cygwin insists on that crappy dll still, when by rights it should install a proper posix subsystem:-) [/semitroll]
Having interix on your NT-class machine is very odd, being about to export proper X11 apps to a real xterm is quite fun, and apparently you can telnet/ssh into an interix enabled system too.
Slashdot Mirror
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
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
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
Uh..Oh.. I hope we don't get those funky blipverts. ...Mind you it'll reduce unemployment!
Smelly? There is nothing nicer than to smell a twostroke. Compare with desil or petrol engines!
Besides all this talk of us running out of oil is poppycock! If it looks like we're running out - the USA and UK will just invade another middle eastern country! - oh wait...
Now where do I post the cheque?
So hands up how many people will pay £400 and up for a new phone ?
Phone contracts subsidises the cost of a new phone, admittedly in the uk and my provider I can choose from a large range of phones, some "Free" (end of line, or stupidly basic, or just crap)
I'm seriously looking about getting one of the newer Nokias or Sony T800 symbian thingies.
Why? Well, I've been a Palm OS fan for ages, and have been waiting for a while to get a decent PDA and phone combo together.
At least now the phone PDA thing is starting to take off, the ability of my phone/PDA being able to run programs *I* want without stupid signing of apps any, being able to run java, ssh etc is very neat.
Just waiting for early adopters to tell me about battery life, and what it's like for data entry etc.
You can with the symbian-based ones :-)
/me suggests Latex support.
And there is nothing wrong with spandex either!
mods on crack again... how is this "offtopic" ?
Anyone read this as:
Peace Corps Wire Segal ?
All these worlds are yours except Europa ... attempt no landings there
... for the dup in a few hours.
You had punch cards? Talk about spoiled.
We, my friend, had to input our code using dip switches, 1 byte at a time. And heaven forbid that you make a mistake near the end of the program, 'cause then we had to start all over.
You had dip switches, when I was a lad, we had to code using plugboards!
No doubt if aliens find it and come to earth, Bush will demand they disarm all their weapons of mass destruction. Not to mention that he would align them with the axis of evil, and then the media will show them eating children and small pets.
You use the right tool for the job. Period. End of discussion.
Third, right after YOUR MUMs email address.
It's not your language, ENGLISH is "owned" by the ENGLISH.
:-)
YOUR language is full of misspellings already.
All they have to do is sign grub/lilo etc?
Could they not, in fact write a small game and have it embed grub/lilo so it could boot off a HD partition/file instead ? I'm sure you could work around such things easily enough.
But M$ Bought interix, because they were the only company that cared enough to provide a better posix subsystem than M$ did.
:-)
[semitroll]
God knows why cygwin insists on that crappy dll still, when by rights it should install a proper posix subsystem
[/semitroll]
Having interix on your NT-class machine is very odd, being about to export proper X11 apps to a real xterm is quite fun, and apparently you can telnet/ssh into an interix enabled system too.
ah well...
1) Start geek website
/.
2) Post dupes
3) ????
4) Profit!!
In Soviet Russia the dupes post YOU!
Someone is obviously smoking crack at
PS. Shift ZZ
That'll be going back to the bad old days of DOS. :(
Okay, so use oil then... ...NASA Should have all it needs when bush invades iraq
... and the book was Much better than the film.