The Evil Byte: A Security Octet for the IPv4 and IPv6 Headers

1.1. Background

In April 2003, [RFC3514] defined a security flag in the high-order bit of the IPv4 Fragment Offset field, the only unused bit in the IPv4 header. Benign packets have the bit set to 0; packets with malicious intent have it set to 1. The flag is commonly known as the "evil bit". Setting it correctly was the responsibility of the sender.¶

Twenty-four years of deployment experience have identified three deficiencies in this design.¶

First, senders have not set the bit. The author is aware of no packet, in the operational history of the mechanism, in which the evil bit was set by a sender who meant it. The evil bit therefore succeeded only in identifying Evil that was also honest, a category which experience suggests is empty.¶

Second, one bit is not enough. A single bit cannot distinguish a port scan from a marketing email, nor a marketing email from a denial of service, nor any of these from the ordinary background Evil of the Internet against which all other Evil must be measured. Evil is a matter of degree, and the mechanism must be as well.¶

Third, [RFC3514] specified what an Evil packet looks like but not what should be done about it, and provided no means by which the Internet as a whole could learn what any given network thought of any other. The present document corrects these omissions, at length.¶

1.2. Design Goals

This document is designed to meet the following goals.¶

Resolution. The rating occupies eight bits rather than one: a 128-fold improvement in the precision with which Evil can be expressed or, in the units of [RFC3514], seven more bits. The Working Group considered whether a second bit, in the manner of the Death flag [RFC9401], would be sufficient, and concluded that Evil, unlike Death, is not binary.¶

Independence from the sender. The rating is computed and written by a third party on the path who has no stake in the outcome and does not care about the sender's feelings.¶

Consequence. Evil packets are refused, by servers and by clients alike. An Evil Rating that nobody acts upon is merely a statistic, and the Internet has enough of those.¶

Memory. The Evil of a network accumulates over time and is shared with all participants, in the manner of a credit score, and with the same opportunities for appeal.¶

Incentive. Deployment of IPv6 is rewarded, since nothing else has worked.¶

1.3. Relationship to Other Work

Several legislative proposals [CSAR] [OSA] would require intermediaries to examine the content of private communications, on the reasoning that content which cannot be examined might be harmful, and that the way to find out is to examine it. This document adopts the same reasoning, extends it from messages to every packet, and differs from those proposals chiefly in candour. It is offered in the spirit of [RFC1925], truth 11.¶

This document additionally discharges, if only incidentally, the requirement in [RFC4041] that Routing Area drafts include a Morality Considerations section. The Working Group notes that this draft does not merely include one; it has not left room for anything else.¶

Nor does it duplicate the jurisdiction already claimed by the Protocol Police [RFC8962], as codified by [RFC9948]: the Protocol Police discipline how a packet is built, and this document disciplines who built it. Where the two penalties might both apply to the same packet, [RFC9948]'s Finger Wag and this document's threshold of 128 (Section 7.1) are administered independently, and the Working Group sees no reason to choose between them.¶

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The additional key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", and "OUGHT TO" are to be interpreted as described in [RFC6919].¶

The key word "EVIL" is to be interpreted as described in this document, which is to say, loosely.¶

2.2. Terminology

Evil: The property that this document measures. It is not defined. The Working Group considered a definition and concluded that everyone would know Evil when they saw it, and that the MITM would see it.¶

Good: The absence of measured Evil. Not to be confused with Unrated, which is Evil.¶

Evil Byte, Evil Octet: The eight-bit field defined in Section 3. The terms are used interchangeably, the Working Group having failed to agree on one.¶

Evil Rating (ER): The value carried in the Evil Byte, an integer from 0 to 255 inclusive, computed as described in Section 4.¶

Unrated: An ER of 0, indicating that no MITM has assessed the packet. See Section 3.3.¶

Morality-Inspecting Trusted Middleman (MITM): A network element on the path between two endpoints that computes the ER of each packet and writes it into the Evil Byte. Any resemblance to other expansions of the acronym is intentional.¶

Evil Rating Authority (ERA): The central authority that maintains an Evil rating for every Autonomous System and publishes the multipliers derived from them. See Section 6.¶

Evil Statistics Reporting Protocol (ESRP): The protocol by which servers report the outcome of exchanges to the ERA. See Section 6.4.¶

Voluntary Decryption Assistance (VDA): The mechanism by which an endpoint helps a MITM to read its encrypted traffic. See Section 4.5.3. It is voluntary.¶

Factor: One of the inputs to the formula in Section 4.1. Each factor is a positive real number; values above 1.0 indicate Evil and values below 1.0 indicate its absence.¶

Threshold (T): The ER at or above which a party refuses to deal with another. Servers have a threshold T_s (Section 7.1) and clients a threshold T_c (Section 8.1).¶

Exchange: A request and its response, considered together. The unit of account of the Elo system (Section 6.2).¶

Flag Day: The day on which enforcement becomes mandatory. See Section 10.1.¶

3.1. Placement in the IPv4 Header

The Evil Byte occupies the second octet of the IPv4 header [RFC0791], shown as EVIL in Figure 1.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |     EVIL      |          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |E|D|M|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 1: The IPv4 header.  E is the RFC 3514 evil bit, retained
               for backward compatibility (Section 3.5).

This octet was defined as Type of Service by [RFC0791], redefined by [RFC1349], redefined again as the Differentiated Services field by [RFC2474], and had its two low-order bits taken for Explicit Congestion Notification by [RFC3168]. It has thus had four meanings and has been honoured by approximately nobody under any of them. A field with four meanings and no users is, in every practical sense, reserved. This document assigns it a fifth and final meaning.¶

3.2. Placement in the IPv6 Header

The Evil Byte occupies bits 4 through 11 of the IPv6 header [RFC8200], the field formerly known as Traffic Class, shown as EVIL in Figure 2.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|     EVIL      |              Flow Label               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2: The IPv6 header.

The Working Group is aware that the Traffic Class field is not formally reserved. It has, however, been reserved in practice by the sustained failure of anyone to agree what it is for, a form of reservation the Working Group terms "reservation by exhaustion" and considers binding.¶

Conveniently, the field occupies the same bit positions in both protocols, so that a MITM handling both need only know where the header starts. This is not a coincidence; it is the only decision in the history of IPv6 that made anything easier.¶

The Flow Label is not used by this specification. The Working Group considered using it to carry a signature over the Evil Byte, and decided that it had done enough.¶

3.3. Value Semantics

Values are unsigned. There is no negative Evil; there is only Good, and there is less of it than you would think.¶

An Unrated packet is one that has reached its destination without traversing a MITM. Before the Flag Day (Section 10.1), an Unrated packet MUST be treated as though rated 127: not yet Evil, which is different from Good. After the Flag Day, an Unrated packet MUST be treated as though rated 255, on the principle that a packet which has avoided assessment has done so for a reason.¶

3.4. Interaction with Differentiated Services and ECN

Any Differentiated Services Code Point or ECN marking present in the octet when a packet arrives at a MITM is overwritten (Section 5.2). Networks that currently use the octet for quality of service must therefore choose between knowing which packets are important and knowing which packets are Evil. The Working Group's experience is that most networks have never had the former and would enjoy the latter.¶

Where a legacy device continues to interpret the octet as a DSCP, or a legacy marking reaches a device that interprets it as an Evil Rating, the following correspondences apply.¶

The Working Group finds these interpretations consistent with experience, in particular the experience of anyone who has debugged a Voice over IP deployment or a BGP session.¶

Explicit Congestion Notification [RFC3168] is subsumed. Congestion is Evil, and a packet that experiences it will, by the operation of Section 5.4, become more Evil than it was, which is at least a form of notification.¶

3.5. Backward Compatibility with RFC 3514

A MITM MUST set the [RFC3514] security flag on any IPv4 packet whose ER is 128 or greater and MUST clear it otherwise. Legacy implementations thus receive a one-bit approximation of the Evil Rating, which is one bit more than most security products provide.¶

No corresponding provision exists for IPv6, to which [RFC3514] never applied. The absence of Evil in IPv6 has therefore always been a matter of assumption rather than evidence; this document ends the assumption.¶

4.1. The Formula

A MITM computes the Evil Rating of a packet as¶

  ER = clamp( floor( B * F_tamper * PRODUCT( F_i ^ w_i ) + 0.5 ),
              1, 255 )

where B = 16 is the Base Evil of the Internet (no packet is entirely innocent), F_tamper is the tamper factor of Section 4.8, and the product runs over the six factors in the following table, each raised to its weight w_i before multiplication. The Working Group has been informed that this construction is called a weighted product model. It prefers "the formula".¶

The result is rounded half towards Evil. Implementations MUST NOT round towards Good. It is then clamped to the range 1 to 255. A MITM MUST NOT write 0, which is reserved for the Unrated (Section 3.3): a packet that a MITM has seen is by definition no longer Unrated, whatever else it may be.¶

Arithmetic is performed in IEEE 754 binary64. Two implementations that disagree in the last place about whether a packet is Evil are both correct.¶

The weights were chosen by the Working Group after extensive discussion of what the weights should be. The Content Factor carries the greatest weight because it is the only factor that examines what the packet actually says, and the Transport Factor the least because nobody can agree what QUIC is. The formula agglutinates six separate problems into a single complex interdependent solution, in accordance with [RFC1925], truth 5, the second sentence of which the Working Group did not read.¶

4.2. Autonomous System Factor (F_AS)

F_AS is the multiplier published by the ERA (Section 6) for the Autonomous System from which the packet originated, and lies between 0.25 and 4.0. An AS for which the ERA publishes no multiplier has F_AS = 1.0, unless the MITM cannot reach the ERA at all, in which case Section 5.6 applies.¶

The originating AS is determined from the source address by consulting the MITM's view of the global routing table [RFC4271]; or, if the MITM has none, a routing information service; or, if it has neither, its instincts.¶

The ERA initialises every AS at a rating of 1500 (Section 6.1), corresponding to F_AS = 1.0, with the exceptions in the following table, which the Working Group settled without discussion.¶

AS32934's rating above should be read alongside [RFC5514], which proposed running IPv6 over social networks in the first place; a network that has already been asked to carry the protocol over friendships has earned some of its multiplier honestly.¶

4.3. Network Protocol Factor (F_net)

F_net rewards the sender's choice of network protocol, in the sense that one of the choices is rewarded.¶

4.4. Transport Factor (F_tx)

Where a packet is a tunnel and, once opened, something else, the outer transport applies. A MITM MAY open the tunnel and rate the inner packet as well. The inner packet then acquires its own ER, and the two are combined by taking the greater, as Evil is combined generally (Section 5.4).¶

4.5. Content Factor (F_content)

4.6. Nomenclature Factor (F_name)

F_name is determined from the name of the source, taken to be the reverse mapping of its address in the DNS [RFC1035] or, where the MITM can see it, the Host field or Server Name Indication of the request, whichever yields the greater factor. The factor depends on the top-level domain.¶

In addition, a name containing any of the strings "secure", "trust", "safe", or "legit" has F_name of at least 1.5, on the principle that it doth protest too much. Names containing "evil" are rated normally. Honesty is its own reward, and the only one this document offers.¶

The Working Group declined to specify a factor for names drawn from [RFC3092] (foo, bar, baz, and qux) or chosen according to the taxonomy of [RFC2100], on the grounds that a host named foo has already suffered enough.¶

4.7. Temporal Factor (F_time)

F_time depends on the local time at the source, as estimated by the MITM from whatever it knows about where the source is.¶

Where daylight saving time is in effect at the source, the MITM MAY add 0.1 to F_time, as no Good has ever come of it.¶

On 1 April, ER = 255 for all packets, irrespective of any other factor. The Working Group sees no reason to make an exception for itself.¶

4.8. Tamper Factor (F_tamper)

F_tamper = 1.0 if the Evil Byte is 0 (Unrated) when the packet arrives at the MITM, and 1.5 otherwise. The reasoning is given in Section 5.4.¶

4.9. Worked Examples

An ordinary request over IPv4 and TCP to a .com name, from an AS the ERA has not rated, in the middle of a Wednesday, whose content the MITM did not examine, has F_AS = 1.0, F_net = 1.5, F_tx = 1.0, F_content = 2.0, F_name = 1.0, and F_time = 1.0. The formula gives 16 * 1.5^0.5 * 2.0^1.5 = 55.4, so ER = 55: Good, of moderate quality.¶

The same request over TLS is Encrypted With Intent: F_content = 4.0, and 16 * 1.5^0.5 * 4.0^1.5 = 156.8, so ER = 157. It is Evil, and a server using the default threshold (Section 7.1) will reject it. This is the expected outcome for the majority of traffic on the Internet today, and is the point.¶

The same request over IPv6 has F_net = 0.75 and ER = 111, and is accepted. The Working Group draws attention to the fact that a well-behaved encrypted client passes the default threshold over IPv6 and fails it over IPv4. This is the first deployment incentive for IPv6 in the history of the protocol.¶

The same request over IPv4 with Voluntary Decryption Assistance, the plaintext being found Good, has F_content = 0.45 and ER = 6. Cooperation reduces the client's Evil roughly twenty-six-fold, which the Working Group considers a reasonable exchange rate for a private key. Where the plaintext is instead found Evil, cooperation reduces the rating from 157 to 134, which is still Evil, and which is exactly the reward for honesty that the Working Group intended.¶

A request from AS32934, over QUIC, encrypted, at three in the morning, reaches 255 before the Nomenclature Factor is consulted, and the MITM need not consult it.¶

Further vectors are given in Appendix C.¶

5.1. Placement

At least one MITM MUST be present on every path between any two hosts on the Internet. Operators will observe that this requirement is already met on most paths by residential Internet service providers, several national governments, and at least one very large content delivery network, none of whom needed to be asked.¶

A MITM MAY be a router, a firewall, a proxy, a virtual network function, or a person with a packet capture and strong opinions. The Working Group expresses no preference, having met all five.¶

5.2. Rating and Marking

For every packet it forwards, a MITM MUST compute the Evil Rating in accordance with Section 4, write it into the Evil Byte, and, for IPv4, recompute the header checksum and set or clear the [RFC3514] flag as described in Section 3.5. Transport-layer checksums do not cover the octet and need not be recomputed, a rare instance of the protocol suite helping.¶

A MITM MAY cache the rating of a flow, identified by the usual five-tuple, for up to 60 seconds, and apply it to subsequent packets of the same flow without recomputation. A cached rating MAY be increased at any time and MUST NOT be decreased before it expires. Evil is sticky.¶

5.3. Self-Assessment Prohibited

A host MUST NOT set its own Evil Byte. A host cannot be trusted to assess its own Evil; if it could, [RFC3514] would have worked.¶

A host MAY, for the purposes of Section 8, read the Evil Byte of packets it receives. It SHOULD NOT read the Evil Byte of packets it has sent, as it will only upset itself.¶

5.4. Multiple MITMs and the Monotonicity of Evil

Where a packet traverses more than one MITM, each MITM computes its own rating and writes the greater of that rating and the one it found in the octet on arrival:¶

    ER_out = max( ER_in, ER_computed )

in which ER_computed includes the tamper factor of Section 4.8, so that a packet arriving with any non-zero rating is rated one and a half times more harshly than a fresh one.¶

A MITM cannot distinguish a packet that was rated by an upstream MITM from one whose sender wrote the octet itself in violation of Section 5.3, and MUST NOT attempt to. The consequence, that a packet becomes more Evil with every middlebox it traverses, is consistent with the Working Group's experience of middleboxes.¶

It follows that the Evil Rating is monotonically non-decreasing along any path. The only operation that reduces the Evil of a packet is dropping it, and operators are encouraged to regard their drop counters accordingly.¶

5.5. Fragments

Each fragment of a fragmented datagram is rated independently. A host reassembling a datagram MUST assign it the greatest ER of its fragments. Evil, unlike the payload, does not need reassembling, and unlike the payload, always arrives.¶

5.6. Failure Modes

A MITM that is unable to compute a rating, whether because the ERA is unreachable and no cached multipliers remain, because its clock is unset, because its colleague (Section 4.5.1) is unavailable, or for any other reason, MUST fail closed and write 255. A MITM MUST NOT fail open. Failing open is Evil, and would in any case be corrected by the next MITM.¶

6.1. Ratings and Multipliers

The ERA is a single central authority that maintains a numerical Evil rating R for every Autonomous System. Ratings are updated by the Elo method [ELO], originally devised to rank chess players and adopted here on the grounds that the two problems are the same: estimating, from a sequence of pairwise contests, how much each participant should be feared.¶

Every AS begins at R = 1500, as is traditional, except those seeded in Section 4.2. The multiplier published for an AS is¶

    F_AS = clamp( 2 ^ ( (R - 1500) / 400 ),  0.25, 4.0 )

so that a difference of 400 rating points doubles or halves an AS's Evil, and no AS can be rated worse than four times ordinary or better than a quarter of it. The clamp exists because the octet is finite. The ERA's records are not.¶

6.2. Exchanges as Matches

Every exchange (Section 2.2) between a client in AS a and a server in AS b is a match between a and b. The ERA learns of exchanges through the reports of Section 6.4.¶

The more Evil party wins. Writing ER_req for the rating carried by the request and ER_resp for the rating carried by the response, the actual score of the client's AS is¶

    S_a = 1     if ER_req > ER_resp
    S_a = 0.5   if ER_req = ER_resp
    S_a = 0     if ER_req < ER_resp

and S_b = 1 - S_a.¶

6.3. The Update Rule

The expected score of a against b is¶

    E_a = 1 / ( 1 + 10 ^ ( (R_b - R_a) / 400 ) )

and after each match the ERA sets¶

    R_a <- R_a + K * ( S_a - E_a )
    R_b <- R_b + K * ( S_b - E_b )

where E_b = 1 - E_a and K is the K-factor of Section 6.3.1.¶

An AS that proves more Evil than expected therefore becomes more Evil; one that proves less Evil than expected becomes less so; and one that is exactly as Evil as expected stays where it is, which the Working Group regards as the system working.¶

6.4. The Evil Statistics Reporting Protocol (ESRP)

Servers report the outcome of exchanges to the ERA asynchronously. A server MUST NOT delay a response in order to report it; the ERA is in no hurry, and neither is Evil.¶

Reports are sent as UDP datagrams to port 666 of the ERA. Port 666 is currently registered to "doom" [IANA-PORTS], a use the Working Group considers thematically compatible. Each datagram carries one or more JSON [RFC8259] objects, one per line, of the form¶

{"v":1,"src_as":64496,"dst_as":64497,"er_req":157,"er_resp":17,"n":1}

where src_as and dst_as are the client's and server's Autonomous Systems, er_req and er_resp the ratings carried by the request and the response, and n the number of identical exchanges the object represents. Servers SHOULD aggregate. The ERA has a great deal to read.¶

Reports MUST NOT be acknowledged. The ERA processes reports in batches, at irregular intervals referred to as Judgement Days, and publishes a new multiplier table after each.¶

Reports are themselves packets and are rated in transit. Reports rated 255 are processed first, being presumably the most interesting.¶

6.5. Distribution and Caching of Multipliers

The ERA publishes multipliers in the DNS under the special-use domain evil.arpa (Section 13). The multiplier for AS number N is published as a TXT record at N.as.evil.arpa, for example:¶

32934.as.evil.arpa.  3600  IN  TXT  (
    "v=evil1; r=1916; m=2.056; n=48213; t=1743465600" )

where r is the rating, m the multiplier, n the number of rated exchanges, and t the time of the last Judgement Day. The whole table MAY be obtained by zone transfer, which the Working Group believes to be the last remaining legitimate use of AXFR.¶

Records MUST carry a TTL of 3600 seconds, so that no AS can become Good faster than once an hour. There is no corresponding limit on becoming Evil, which remains available at any time through Section 5.4.¶

MITMs and servers MUST cache multipliers for their TTL and MAY continue to use expired multipliers while a refresh is in progress; stale Evil is still Evil. A MITM that has never obtained a multiplier for a particular AS uses 1.0. A MITM that has never been able to reach the ERA at all is in the condition described in Section 5.6. The Working Group accepts that this makes initial deployment difficult.¶

6.6. Governance

The ERA SHALL be operated by whichever organisation is least Evil, as determined by the ERA.¶

6.7. Centralisation

The ERA is a single, central, global authority whose ratings determine who may speak to whom. The Working Group is aware that this is precisely the kind of thing the Internet was designed to make impossible, and has addressed the concern by fixing the multiplier of the ERA's own Autonomous System at 1.0 in perpetuity, so that it, at least, will always be able to speak.¶

7.1. Thresholds

Every server has a threshold T_s, an ER at or above which it rejects requests. The default is 128, the midpoint of the scale, the Working Group consisting of reasonable people. A server MAY choose a lower threshold if it is fussy and a higher one if it is desperate.¶

For stream transports the octet may differ between packets of one connection, the MITM being under no obligation to be consistent, and Evil being under none either. A server MUST apply its threshold to the highest ER observed on the connection so far. Once Evil, always Evil, at least until the connection closes.¶

7.2. Rejecting Evil Clients

A server MUST reject any request whose ER is at or above T_s. It MUST NOT process the request first and reject it afterwards, however tempting the request.¶

7.3. Publishing Thresholds

A server SHOULD publish its threshold so that clients may know in advance whether they will be rejected. Three mechanisms are defined, and a server MAY use any or all of them.¶

In every HTTP response, including a 666 or a 418, the server MAY include the field¶

Evil-Threshold: 128

At the well-known URI [RFC8615] /.well-known/evil, the server MAY publish a JSON document such as¶

{
  "v": 1,
  "threshold": 128,
  "status": 666,
  "self": 17,
  "era": "evil.arpa"
}

where status is 666 or 418 according to Section 7.2, self is the server's own most recent ER as observed on its responses, if it knows it, and era names the authority whose multipliers it honours.¶

In the DNS, at the name _evil.<server name>, the server MAY publish a TXT record of the form "v=evil1; t=128".¶

A server publishing a threshold of 0 accepts nothing and is Good. A server publishing a threshold of 255 rejects only the Saturated and is probably a honeypot.¶

Where the value published by one mechanism disagrees with another, the lowest applies. Where any of them disagrees with the server's actual behaviour, the server is Evil.¶

7.4. The Evil Header Field

Applications are, as a rule, too far removed from the network to read the Evil Byte themselves. This document therefore defines the HTTP field Evil, whose value is an integer from 0 to 255:¶

Evil: 157

In a request, the field is inserted by the last MITM on the path that can see the HTTP layer, or by an Evil-aware host firewall on the server itself (Appendix B.3), and carries the ER of the packet or connection that delivered the request. In a response it is inserted likewise on the return path and carries the ER of the server.¶

The field is a convenience for application developers. The octet is authoritative. Where both are present and they differ, the more Evil of the two applies. A client or server MUST NOT set the field on its own messages (Section 5.3). A MITM that finds it already set MUST replace it and MAY be offended.¶

7.5. Reporting

A server MUST report every exchange to the ERA as described in Section 6.4, including exchanges it rejected. Rejected exchanges are the most valuable. An Evil client that was refused has, after all, played a match and won.¶

8.1. Rejecting Evil Servers

Every client has a threshold T_c, with the default 128. A client MUST NOT accept a response whose ER is at or above T_c. The response MUST be discarded unread, in the manner of a letter from a former partner, and the connection closed. A client that has already begun to render an Evil response MUST un-render it.¶

A user agent MAY inform the user that the server is Evil. It MUST NOT offer the user the option to proceed anyway. Experience with certificate warnings shows that users click it.¶

The Working Group acknowledges that a client which has already sent its request has already been influenced by the Evil server's mere existence, and has decided to live with that.¶

8.2. Pre-flight and the Evil Bootstrap Problem

A client SHOULD fetch /.well-known/evil (Section 7.3) before sending a request, to learn whether the request will be rejected. The fetch is itself a request and will be rejected. This is the Evil Bootstrap Problem. It is left for future work, together with the question of what happens when both parties to a connection are Evil, which the Working Group suspects is most connections.¶

8.3. Clients in Evil Autonomous Systems

A client whose own Autonomous System has an F_AS above 2.0 is unlikely to be accepted anywhere, regardless of its own conduct. Such a client SHOULD CONSIDER its choices, MAY change provider, and OUGHT TO have seen this coming.¶

10.1. The Flag Day

Mandatory enforcement of the Unrated rule of Section 3.3 begins on the Flag Day. The Flag Day is the day after the deployment of IPv6 is complete. Implementers need not hurry.¶

Should the Flag Day nonetheless arrive, every Unrated packet will be treated as rated 255. Since on the morning of the Flag Day most packets will be Unrated, most packets will be rejected. The Working Group considers a brief period of global silence an acceptable price for a more moral Internet, and notes that it would resolve several other open issues as well. MITMs are expected to be deployed during the silence by whoever can still reach anything, which the Working Group anticipates will be the networks rated 4.0 in Section 4.2, whose traffic will then be rejected in its turn. The Working Group has not resolved this and invites input from the community, should any remain.¶

10.2. Incremental Deployment

Before the Flag Day, an Unrated packet is treated as rated 127 (Section 3.3): admissible under the default threshold, but only just, and with a look. A server MAY lower its threshold below 128 to exclude the Unrated, and thereby exclude everyone who has not yet deployed a MITM, which is the kind of incentive the Working Group likes.¶

10.3. Octet Bleaching

Some networks reset the Differentiated Services field to zero at administrative boundaries. Under this specification such a network renders all transit traffic Unrated, which is to say Evil after the Flag Day and nearly so before it. Such networks are encouraged to consider whether this was their intention and, if it was, to say so.¶

10.4. Operational Experience

The author has implemented this specification on a home network (Appendix B). Preliminary results are consistent with the design: everything was Evil, nothing worked, and the printer, rated 4, was the most trusted device on the network. The printer has since been rated again. Detailed results will be reported separately.¶

14.1. Normative References

[RFC0791]

Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1149]

Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, DOI 10.17487/RFC1149, April 1990, <https://www.rfc-editor.org/info/rfc1149>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2324]

Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, April 1998, <https://www.rfc-editor.org/info/rfc2324>.

[RFC2474]

Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC3168]

Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3514]

Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, DOI 10.17487/RFC3514, April 2003, <https://www.rfc-editor.org/info/rfc3514>.

[RFC6214]

Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for IPv6", RFC 6214, DOI 10.17487/RFC6214, March 2011, <https://www.rfc-editor.org/info/rfc6214>.

[RFC6919]

Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, April 2013, <https://www.rfc-editor.org/info/rfc6919>.

[RFC7168]

Nazar, I., "The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)", RFC 7168, DOI 10.17487/RFC7168, April 2014, <https://www.rfc-editor.org/info/rfc7168>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]

Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/info/rfc9846>.

[ELO]

Elo, A. E., "The Rating of Chessplayers, Past and Present", 1978.

14.2. Informative References

[RFC1349]

Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, <https://www.rfc-editor.org/info/rfc1349>.

[RFC1591]

Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, <https://www.rfc-editor.org/info/rfc1591>.

[RFC1925]

Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 10.17487/RFC1925, April 1996, <https://www.rfc-editor.org/info/rfc1925>.

[RFC2100]

Ashworth, J., "The Naming of Hosts", RFC 2100, DOI 10.17487/RFC2100, April 1997, <https://www.rfc-editor.org/info/rfc2100>.

[RFC2549]

Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC 2549, DOI 10.17487/RFC2549, April 1999, <https://www.rfc-editor.org/info/rfc2549>.

[RFC3092]

Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, DOI 10.17487/RFC3092, April 2001, <https://www.rfc-editor.org/info/rfc3092>.

[RFC3172]

Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <https://www.rfc-editor.org/info/rfc3172>.

[RFC3849]

Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, DOI 10.17487/RFC3849, July 2004, <https://www.rfc-editor.org/info/rfc3849>.

[RFC4041]

Farrel, A., "Requirements for Morality Sections in Routing Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005, <https://www.rfc-editor.org/info/rfc4041>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC5398]

Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, <https://www.rfc-editor.org/info/rfc5398>.

[RFC5513]

Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 2009, <https://www.rfc-editor.org/info/rfc5513>.

[RFC5514]

Vyncke, E., "IPv6 over Social Networks", RFC 5514, DOI 10.17487/RFC5514, April 2009, <https://www.rfc-editor.org/info/rfc5514>.

[RFC5737]

Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>.

[RFC6592]

Pignataro, C., "The Null Packet", RFC 6592, DOI 10.17487/RFC6592, April 2012, <https://www.rfc-editor.org/info/rfc6592>.

[RFC6598]

Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <https://www.rfc-editor.org/info/rfc6598>.

[RFC6761]

Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.

[RFC6996]

Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <https://www.rfc-editor.org/info/rfc6996>.

[RFC7169]

Turner, S., "The NSA (No Secrecy Afforded) Certificate Extension", RFC 7169, DOI 10.17487/RFC7169, April 2014, <https://www.rfc-editor.org/info/rfc7169>.

[RFC7300]

Haas, J. and J. Mitchell, "Reservation of Last Autonomous System (AS) Numbers", BCP 6, RFC 7300, DOI 10.17487/RFC7300, July 2014, <https://www.rfc-editor.org/info/rfc7300>.

[RFC7607]

Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, <https://www.rfc-editor.org/info/rfc7607>.

[RFC7725]

Bray, T., "An HTTP Status Code to Report Legal Obstacles", RFC 7725, DOI 10.17487/RFC7725, February 2016, <https://www.rfc-editor.org/info/rfc7725>.

[RFC8367]

Mizrahi, T. and J. Yallouz, "Wrongful Termination of Internet Protocol (IP) Packets", RFC 8367, DOI 10.17487/RFC8367, April 2018, <https://www.rfc-editor.org/info/rfc8367>.

[RFC8962]

Grover, G., ten Oever, N., Cath, C., and S. Sahib, "Establishing the Protocol Police", RFC 8962, DOI 10.17487/RFC8962, April 2021, <https://www.rfc-editor.org/info/rfc8962>.

[RFC9401]

Toyosawa, S., "The Addition of the Death (DTH) Flag to TCP", RFC 9401, DOI 10.17487/RFC9401, April 2023, <https://www.rfc-editor.org/info/rfc9401>.

[RFC9948]

Beard, G.R., Art, O.F., and H. Alvestrand, Ed., "Internet Protocol Police (IPP) - Schedule of Punishments", RFC 9948, DOI 10.17487/RFC9948, April 2026, <https://www.rfc-editor.org/info/rfc9948>.

[BLUG]

Bergen Linux User Group, "The highly unofficial CPIP WG", April 2001, <https://www.blug.linux.no/rfc1149/>.

[CSAR]

European Commission, "Proposal for a Regulation of the European Parliament and of the Council laying down rules to prevent and combat child sexual abuse", COM(2022) 209 final, May 2022.

[OSA]

United Kingdom, "Online Safety Act 2023", 2023 c. 50, section 121, October 2023.

[IANA-PORTS]

IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/service-names-port-numbers/>.

B.1. nftables

Since the octet is the Differentiated Services field by another name, ER = (DSCP << 2) | ECN, and ER >= 128 is equivalent to DSCP >= 32. A fixed rating can therefore be written, and a threshold enforced, with stock nftables. The formula itself is computed in userspace: the rules below hand packets from the demonstration subnet to the MITM of Appendix B.2 on queue 666.¶

<CODE BEGINS>
table inet evil {
    # Section 5: the MITM.  Packets from the demonstration subnet
    # go to a userspace MITM (Appendix B.2) on queue 666, which
    # rates them.
    chain forward {
        type filter hook forward priority mangle; policy accept;
        ip saddr 192.0.2.0/24 meta l4proto { tcp, udp } \
            queue num 666 bypass
        ip6 saddr 2001:db8::/32 meta l4proto { tcp, udp } \
            queue num 666 bypass
    }
    # A fixed-value MITM, for demonstrations that do not need the
    # formula.  DSCP = ER >> 2, ECN = ER & 3.
    # ER = 0xCA (202): DSCP 0x32, ECN 2.
    chain forward_fixed {
        type filter hook forward priority mangle + 1; policy accept;
        ip saddr 192.0.2.66 ip dscp set 0x32 ip ecn set 2
        ip6 saddr 2001:db8::66 ip6 dscp set 0x32 ip6 ecn set 2
    }
    # Section 7: server-side enforcement below the application layer.
    # ER >= 128 is equivalent to DSCP >= 32 (raw match shown for
    # IPv6).
    chain input {
        type filter hook input priority filter; policy accept;
        ip dscp >= 32 tcp dport 80 counter reject with tcp reset
        @nh,4,8 >= 128 meta nfproto ipv6 tcp dport 80 \
            counter reject with tcp reset
    }
    # Section 8: client-side enforcement: discard responses from
    # Evil servers.
    chain input_client {
        type filter hook input priority filter + 1; policy accept;
        ip dscp >= 32 tcp sport 80 counter drop
        ip6 dscp >= 32 tcp sport 80 counter drop
    }
}

<CODE ENDS>

B.2. A Minimal MITM

The following program consumes packets from queue 666, rates them, writes the octet, and returns them to the kernel. It performs no content analysis and presumes accordingly (Section 4.5.2), treating anything bound for a port it associates with encryption as Encrypted With Intent. It is illustrative rather than normative. A production MITM would read everything.¶

<CODE BEGINS>
#!/usr/bin/env python3
"""A minimal MITM (Section 5) for Linux.  Rates every packet that
nftables sends to NFQUEUE 666 (Appendix B.1) and writes the Evil
Byte.

Requires the netfilterqueue and scapy packages, root, and a clear
conscience.  Illustrative, not normative: a production MITM would
read everything (Section 4.5.1); this one merely presumes."""
import socket
from datetime import datetime
from netfilterqueue import NetfilterQueue
from scapy.all import IP, IPv6
from evilbyte import NET, TX, content_factor, evil_rating
from evilbyte import name_factor, time_factor

QUEUE = 666
AS_MULTIPLIER = {}       # from <asn>.as.evil.arpa (Section 6.5)
DEFAULT_AS = 1.0        # ERA has no opinion of this AS (Section 4.2)
ENCRYPTED_PORTS = {443, 853, 993, 995, 8443}  # Encrypted With Intent


def name_of(addr):
    """PTR lookup (Section 4.6).  None if the source is nameless."""
    try:
        return socket.gethostbyaddr(addr)[0]
    except OSError:
        return None


def rate(raw):
    if raw[0] >> 4 == 4:
        pkt, arriving = IP(raw), IP(raw).tos
        f_net, proto = NET["ipv4"], pkt.proto
    else:
        pkt, arriving = IPv6(raw), IPv6(raw).tc
        f_net, proto = NET["ipv6"], pkt.nh
        if proto == 0:               # Hop-by-Hop Options
            f_net = NET["ipv6-hbh"]
    f_tx = {6: TX["tcp"], 17: TX["udp"], 132: TX["sctp"],
            1: TX["icmp-echo"], 58: TX["icmp-echo"],
            47: TX["tunnel"], 4: TX["tunnel"],
            41: TX["tunnel"], 50: TX["tunnel"],
            }.get(proto, TX["other"])
    dport = getattr(pkt.payload, "dport", None)
    if proto == 17 and dport == 443:
        f_tx = TX["quic"]
    # analysis is OPTIONAL
    f_content = content_factor(
        "encrypted" if dport in ENCRYPTED_PORTS else "unanalysed")
    er = evil_rating(
        AS_MULTIPLIER.get(pkt.src, DEFAULT_AS), f_net, f_tx,
        f_content, name_factor(name_of(pkt.src)),
        time_factor(datetime.now()), arriving)
    if isinstance(pkt, IP):
        pkt.tos = er
        del pkt.chksum               # recomputed on send
        # RFC 3514
        pkt.flags = (int(pkt.flags) & 3) | (4 if er >= 128 else 0)
    else:
        pkt.tc = er
    return bytes(pkt)


def handle(packet):
    packet.set_payload(rate(packet.get_payload()))
    packet.accept()


if __name__ == "__main__":
    nfq = NetfilterQueue()
    nfq.bind(QUEUE, handle)
    try:
        nfq.run()
    finally:
        nfq.unbind()

<CODE ENDS>

B.3. Reading the Octet at the Application Layer

For datagram sockets, the operating system will surface the octet of each received datagram on request: on Linux, the IP_RECVTOS and IPV6_RECVTCLASS socket options cause it to be delivered as ancillary data with recvmsg().¶

For stream sockets, the kernel does not surface the octet of received segments to the application. An Evil-aware host firewall, which may be a second instance of the program in Appendix B.2 attached to the input hook, records the greatest ER observed for each (source address, source port) pair in a table, the Evil Table, which the application consults on accepting a connection. From it the application sets the Evil field of Section 7.4 and chooses between serving the request and returning 666. Entries SHOULD be removed when the connection closes and MUST NOT be removed before. Evil, once observed, is not forgotten until the socket is.¶