asciidoctor-rfc 0.1.0 → 0.2.0

data/spec/examples/rfc3514.md

@@ -0,0 +1,203 @@
+%%%
+
+    Title = "The Security Flag in the IPv4 Header"
+    abbrev = "The Security Flag in the IPv4 Header"
+    category = "info"
+    docName = "rfc-3514"
+    ipr= "trust200902"
+    area = "Internet"
+    workgroup = "Network Working Group"
+    keyword = [""]
+
+    date = 2003-04-01T00:00:00Z
+
+    [[author]]
+    initials="S."
+    surname="Bellovin"
+    fullname="Steven M. Bellovin"
+    #role="editor"
+    organization = "AT&T Labs Research"
+      [author.address]
+      email = "bellovin@acm.org"
+      phone = "+1 973-360-8656"
+      [author.address.postal]
+      street = "180 Park Avenue"
+      city = "Florham Park"
+      code = "NJ 07932"
+
+%%%
+
+.# 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.
+
+{mainmatter}
+
+# 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
+[@!RFC0791] header.  Benign packets have this bit set to 0; those that
+are used for an attack will have the bit set to 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].
+
+# 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:
+
+{align="left"}
+         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.
+
+# 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.  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.
+
+# 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 depends on the type of IDS.
+Thus, a signature-based IDS would have a low false positive value but
+a high false negative value.  A suitable administrative interface
+**MUST** be provided to permit operators to reset these values.
+
+Routers that are not intended as as security devices **SHOULD NOT**
+examine this bit. This will allow them to pass packets at higher
+speeds.
+
+As outlined earlier, host processing of evil packets is operating-
+system dependent; however, all hosts **MUST** react appropriately
+according to their nature.
+
+# Related Work
+
+Although this document only defines the IPv4 evil bit, there are
+complementary mechanisms for other forms of evil.  We sketch some of
+those here.
+
+For IPv6 [@!RFC2460], evilness is conveyed by two options.  The first,
+a hop-by-hop option, is used for packets that damage the network,
+such as DDoS packets.  The second, an end-to-end option, is for
+packets intended to damage destination hosts.  In either case, the
+option contains a 128-bit strength indicator, which says how evil the
+packet is, and a 128-bit type code that describes the particular type
+of attack intended.
+
+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.
+
+DDoS attack packets are denoted by a special diffserv code point.
+
+An application/evil MIME type is defined for Web- or email-carried
+mischief.  Other MIME types can be embedded inside of evil sections;
+this permit easy encoding of word processing documents with macro
+viruses, etc.
+
+# IANA Considerations
+
+This document defines the behavior of security elements for the 0x0
+and 0x1 values of this bit.  Behavior for other values of the bit may
+be defined only by IETF consensus [@!RFC2434].
+
+# Security Considerations
+
+Correct functioning of security mechanisms depend critically on the
+evil bit being set properly.  If faulty components do not set the
+evil bit to 1 when appropriate, firewalls will not be able to do
+their jobs properly.  Similarly, if the bit is set to 1 when it
+shouldn't be, a denial of service condition may occur.
+
+<reference anchor='CBR03' target=''>
+ <front>
+ <title>Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition</title>
+  <author initials='W.R.' surname='Cheswick' fullname='W.R. Cheswick'></author>
+  <author initials='S.M.' surname='Bellovin' fullname='S.M. Bellovin'></author>
+  <author initials='A.D.' surname='Rubin' fullname='A.D. Rubin'></author>
+  <date year='2003' />
+ </front>
+ <seriesInfo name="Addison-Wesley" value='' />
+ </reference>
+
+{backmatter}

data/spec/examples/rfc3514.md.2.xml

@@ -0,0 +1,238 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
+<rfc ipr="trust200902" category="info" docName="rfc-3514">
+<?rfc toc="yes"?>
+<?rfc symrefs="yes"?>
+<?rfc sortrefs="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc private=""?>
+<?rfc topblock="yes"?>
+<?rfc comments="no"?>
+<front>
+<title abbrev="The Security Flag in the IPv4 Header">The Security Flag in the IPv4 Header</title>
+
+<author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
+<organization>AT&amp;T Labs Research</organization>
+<address>
+<postal>
+<street>180 Park Avenue</street>
+<city>Florham Park</city>
+<code>NJ 07932</code>
+<country></country>
+<region></region>
+</postal>
+<phone>+1 973-360-8656</phone>
+<email>bellovin@acm.org</email>
+<uri></uri>
+</address>
+</author>
+<date year="2003" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+
+<abstract>
+<t>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.
+</t>
+</abstract>
+
+
+</front>
+
+<middle>
+
+<section anchor="introduction" title="Introduction">
+<t>Firewalls <xref target="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 &quot;evil&quot; bit, in the IPv4
+<xref target="RFC0791"/> header.  Benign packets have this bit set to 0; those that
+are used for an attack will have the bit set to 1.
+</t>
+
+<section anchor="terminology" title="Terminology">
+<t>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 <xref target="RFC2119"/>.
+</t>
+</section>
+</section>
+
+<section anchor="syntax" title="Syntax">
+<t>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.
+</t>
+<t>The bit field is laid out as follows:
+</t>
+
+<figure align="left"><artwork align="left">
+     0
+    +-+
+    |E|
+    +-+
+</artwork></figure>
+<t>Currently-assigned values are defined as follows:
+</t>
+<t>
+<list style="hanging">
+<t hangText="0x0:">
+<vspace />
+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.)</t>
+<t hangText="0x1:">
+<vspace />
+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.</t>
+</list>
+</t>
+</section>
+
+<section anchor="setting-the-evil-bit" title="Setting the Evil Bit">
+<t>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.
+</t>
+<t>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
+<spanx style="emph">MAY</spanx> provide an API to allow it to be cleared for non-malicious
+activity by users who normally engage in attack behavior.
+</t>
+<t>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.
+</t>
+<t>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.
+</t>
+<t>Some applications hand-craft their own packets.  If these packets are
+part of an attack, the application MUST set the evil bit by itself.
+</t>
+<t>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.
+</t>
+<t>Because NAT <xref target="RFC3022"/> boxes modify packets, they SHOULD set the evil
+bit on such packets.  &quot;Transparent&quot; http and email proxies SHOULD set
+the evil bit on their reply packets to the innocent client host.
+</t>
+<t>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.
+</t>
+</section>
+
+<section anchor="processing-of-the-evil-bit" title="Processing of the Evil Bit">
+<t>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.
+</t>
+<t>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
+<xref target="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.
+</t>
+<t>The default probabilities for these tests depends on the type of IDS.
+Thus, a signature-based IDS would have a low false positive value but
+a high false negative value.  A suitable administrative interface
+MUST be provided to permit operators to reset these values.
+</t>
+<t>Routers that are not intended as as security devices SHOULD NOT
+examine this bit. This will allow them to pass packets at higher
+speeds.
+</t>
+<t>As outlined earlier, host processing of evil packets is operating-
+system dependent; however, all hosts MUST react appropriately
+according to their nature.
+</t>
+</section>
+
+<section anchor="related-work" title="Related Work">
+<t>Although this document only defines the IPv4 evil bit, there are
+complementary mechanisms for other forms of evil.  We sketch some of
+those here.
+</t>
+<t>For IPv6 <xref target="RFC2460"/>, evilness is conveyed by two options.  The first,
+a hop-by-hop option, is used for packets that damage the network,
+such as DDoS packets.  The second, an end-to-end option, is for
+packets intended to damage destination hosts.  In either case, the
+option contains a 128-bit strength indicator, which says how evil the
+packet is, and a 128-bit type code that describes the particular type
+of attack intended.
+</t>
+<t>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.
+</t>
+<t>DDoS attack packets are denoted by a special diffserv code point.
+</t>
+<t>An application/evil MIME type is defined for Web- or email-carried
+mischief.  Other MIME types can be embedded inside of evil sections;
+this permit easy encoding of word processing documents with macro
+viruses, etc.
+</t>
+</section>
+
+<section anchor="iana-considerations" title="IANA Considerations">
+<t>This document defines the behavior of security elements for the 0x0
+and 0x1 values of this bit.  Behavior for other values of the bit may
+be defined only by IETF consensus <xref target="RFC2434"/>.
+</t>
+</section>
+
+<section anchor="security-considerations" title="Security Considerations">
+<t>Correct functioning of security mechanisms depend critically on the
+evil bit being set properly.  If faulty components do not set the
+evil bit to 1 when appropriate, firewalls will not be able to do
+their jobs properly.  Similarly, if the bit is set to 1 when it
+shouldn't be, a denial of service condition may occur.
+</t>
+</section>
+
+</middle>
+<back>
+<references title="Normative References">
+<reference anchor='CBR03' target=''>
+ <front>
+ <title>Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition</title>
+  <author initials='W.R.' surname='Cheswick' fullname='W.R. Cheswick'></author>
+  <author initials='S.M.' surname='Bellovin' fullname='S.M. Bellovin'></author>
+  <author initials='A.D.' surname='Rubin' fullname='A.D. Rubin'></author>
+  <date year='2003' />
+ </front>
+ <seriesInfo name="Addison-Wesley" value='' />
+ </reference>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1750.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2434.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"?>
+<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml"?>
+</references>
+
+</back>
+</rfc>

data/spec/examples/rfc3514.md.3.xml

@@ -0,0 +1,258 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info" docName="rfc-3514">
+<front>
+<title abbrev="The Security Flag in the IPv4 Header">The Security Flag in the IPv4 Header</title>
+
+<author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
+<organization>AT&amp;T Labs Research</organization>
+<address>
+<postal>
+<street>180 Park Avenue</street>
+<city>Florham Park</city>
+<code>NJ 07932</code>
+<country></country>
+<region></region>
+</postal>
+<phone>+1 973-360-8656</phone>
+<email>bellovin@acm.org</email>
+<uri></uri>
+</address>
+</author>
+<date year="2003" month="April" day="1"/>
+
+<area>Internet</area>
+<workgroup>Network Working Group</workgroup>
+<keyword></keyword>
+
+
+<abstract>
+<t>
+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.
+</t>
+</abstract>
+
+</front>
+
+<middle>
+
+<section anchor="introduction">
+<name>Introduction</name>
+<t>
+Firewalls <xref target="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 &quot;evil&quot; bit, in the IPv4
+<xref target="RFC0791"/> header.  Benign packets have this bit set to 0; those that
+are used for an attack will have the bit set to 1.
+</t>
+
+<section anchor="terminology">
+<name>Terminology</name>
+<t>
+The keywords <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</bcp14>, <bcp14>SHALL</bcp14>, <bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>,
+<bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14>, when they appear in this
+document, are to be interpreted as described in <xref target="RFC2119"/>.
+</t>
+</section>
+</section>
+
+<section anchor="syntax">
+<name>Syntax</name>
+<t>
+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.
+</t>
+<t>
+The bit field is laid out as follows:
+</t>
+<artwork align="left">
+     0
+    +-+
+    |E|
+    +-+
+</artwork>
+<t>
+Currently-assigned values are defined as follows:
+</t>
+<dl>
+<dt>0x0:</dt>
+<dd>If the bit is set to 0, the packet has no evil intent.  Hosts,
+network elements, etc., <bcp14>SHOULD</bcp14> assume that the packet is
+harmless, and <bcp14>SHOULD NOT</bcp14> take any defensive measures.  (We note
+that this part of the spec is already implemented by many common
+desktop operating systems.)</dd>
+<dt>0x1:</dt>
+<dd>If the bit is set to 1, the packet has evil intent.  Secure
+systems <bcp14>SHOULD</bcp14> try to defend themselves against such packets.
+Insecure systems <bcp14>MAY</bcp14> chose to crash, be penetrated, etc.</dd>
+</dl>
+</section>
+
+<section anchor="setting-the-evil-bit">
+<name>Setting the Evil Bit</name>
+<t>
+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 <bcp14>MUST</bcp14> provide such an API;
+attack programs <bcp14>MUST</bcp14> use it.
+</t>
+<t>
+Multi-level insecure operating systems may have special levels for
+attack programs; the evil bit <bcp14>MUST</bcp14> be set by default on packets
+emanating from programs running at such levels.  However, the system
+<em>MAY</em> provide an API to allow it to be cleared for non-malicious
+activity by users who normally engage in attack behavior.
+</t>
+<t>
+Fragments that by themselves are dangerous <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be cleared in the fragments, and <bcp14>MUST</bcp14> be turned
+back on in the reassembled packet.
+</t>
+<t>
+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.
+</t>
+<t>
+Some applications hand-craft their own packets.  If these packets are
+part of an attack, the application <bcp14>MUST</bcp14> set the evil bit by itself.
+</t>
+<t>
+In networks protected by firewalls, it is axiomatic that all
+attackers are on the outside of the firewall.  Therefore, hosts
+inside the firewall <bcp14>MUST NOT</bcp14> set the evil bit on any packets.
+</t>
+<t>
+Because NAT <xref target="RFC3022"/> boxes modify packets, they <bcp14>SHOULD</bcp14> set the evil
+bit on such packets.  &quot;Transparent&quot; http and email proxies <bcp14>SHOULD</bcp14> set
+the evil bit on their reply packets to the innocent client host.
+</t>
+<t>
+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 <bcp14>MUST NOT</bcp14> 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 <bcp14>SHOULD</bcp14> be set.
+</t>
+</section>
+
+<section anchor="processing-of-the-evil-bit">
+<name>Processing of the Evil Bit</name>
+<t>
+Devices such as firewalls <bcp14>MUST</bcp14> drop all inbound packets that have the
+evil bit set.  Packets with the evil bit off <bcp14>MUST NOT</bcp14> be dropped.
+Dropped packets <bcp14>SHOULD</bcp14> be noted in the appropriate MIB variable.
+</t>
+<t>
+Intrusion detection systems (IDSs) have a harder problem.  Because of
+their known propensity for false negatives and false positives, IDSs
+<bcp14>MUST</bcp14> apply a probabilistic correction factor when evaluating the evil
+bit.  If the evil bit is set, a suitable random number generator
+<xref target="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.
+</t>
+<t>
+The default probabilities for these tests depends on the type of IDS.
+Thus, a signature-based IDS would have a low false positive value but
+a high false negative value.  A suitable administrative interface
+<bcp14>MUST</bcp14> be provided to permit operators to reset these values.
+</t>
+<t>
+Routers that are not intended as as security devices <bcp14>SHOULD NOT</bcp14>
+examine this bit. This will allow them to pass packets at higher
+speeds.
+</t>
+<t>
+As outlined earlier, host processing of evil packets is operating-
+system dependent; however, all hosts <bcp14>MUST</bcp14> react appropriately
+according to their nature.
+</t>
+</section>
+
+<section anchor="related-work">
+<name>Related Work</name>
+<t>
+Although this document only defines the IPv4 evil bit, there are
+complementary mechanisms for other forms of evil.  We sketch some of
+those here.
+</t>
+<t>
+For IPv6 <xref target="RFC2460"/>, evilness is conveyed by two options.  The first,
+a hop-by-hop option, is used for packets that damage the network,
+such as DDoS packets.  The second, an end-to-end option, is for
+packets intended to damage destination hosts.  In either case, the
+option contains a 128-bit strength indicator, which says how evil the
+packet is, and a 128-bit type code that describes the particular type
+of attack intended.
+</t>
+<t>
+Some link layers, notably those based on optical switching, may
+bypass routers (and hence firewalls) entirely.  Accordingly, some
+link-layer scheme <bcp14>MUST</bcp14> be used to denote evil.  This may involve evil
+lambdas, evil polarizations, etc.
+</t>
+<t>
+DDoS attack packets are denoted by a special diffserv code point.
+</t>
+<t>
+An application/evil MIME type is defined for Web- or email-carried
+mischief.  Other MIME types can be embedded inside of evil sections;
+this permit easy encoding of word processing documents with macro
+viruses, etc.
+</t>
+</section>
+
+<section anchor="iana-considerations">
+<name>IANA Considerations</name>
+<t>
+This document defines the behavior of security elements for the 0x0
+and 0x1 values of this bit.  Behavior for other values of the bit may
+be defined only by IETF consensus <xref target="RFC2434"/>.
+</t>
+</section>
+
+<section anchor="security-considerations">
+<name>Security Considerations</name>
+<t>
+Correct functioning of security mechanisms depend critically on the
+evil bit being set properly.  If faulty components do not set the
+evil bit to 1 when appropriate, firewalls will not be able to do
+their jobs properly.  Similarly, if the bit is set to 1 when it
+shouldn't be, a denial of service condition may occur.
+</t>
+</section>
+
+</middle>
+<back>
+<references>
+<name>Normative References</name>
+<reference anchor='CBR03' target=''>
+ <front>
+ <title>Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition</title>
+  <author initials='W.R.' surname='Cheswick' fullname='W.R. Cheswick'></author>
+  <author initials='S.M.' surname='Bellovin' fullname='S.M. Bellovin'></author>
+  <author initials='A.D.' surname='Rubin' fullname='A.D. Rubin'></author>
+  <date year='2003' />
+ </front>
+ <seriesInfo name="Addison-Wesley" value='' />
+ </reference>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1750.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2434.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/>
+<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml"/>
+</references>
+
+</back>
+</rfc>