
I may be the only evil bit user on the internet - benjojo12
https://blog.benjojo.co.uk/post/evil-bit-RFC3514-real-world-usage
======
geofft
The "security by obscurity" bit is interesting. I'm now imagining a server
where it checks that the initial sequence number of the SYN packet ends with
your current OATH two-factor authentication code, or something, and it drops
the packet if you have the wrong code. (Which elevates it quite a bit past
simply "obscurity.") The traffic is indistinguishable from normal SSH traffic,
and there's very little code that has to process anything from untrusted
sources.

~~~
rando289
See fwknop and the history of port knocking.

~~~
michaelrash
Some information on this is located in the fwknop tutorial:

[http://www.cipherdyne.org/fwknop/docs/fwknop-
tutorial.html](http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html)

------
xorcist
While a very good story, I suspect the offending firewalls might drop traffic
with _any_ of the reserved bits set, not just the "evil" bit. Very fun
exercise though!

~~~
nly
This seems like a really bad thing to do. If any of those reserved bits get
used for a legitimate purpose in the future then none of these networks will
be accessible. Reserved should mean "set to 0 when you send, ignore on when
you receive". It's not like these bits actually cost any additional
processing. There's literally no benefit to dropping these packets, and it's
shenanigans like this that mean we can't improve protocols easily in the
future.

I wonder how many routers are filtering IPv4 packets with fragment offsets of
8190 and 8191?

~~~
fulafel
Firewalls and other middleboxes are notorious about doing very bad things like
this to the detriment of the internet as a whole. See PMTU discovery, why it
was impossible to deploy TCP RED or SCTP, etc.

~~~
technion
"Windows DNS is broken" was a meme for about five years due to Cisco ASA's
blocking EDNS traffic.

------
rmc
In 1990 Bergen LUG implemented TCP over Avian Carriers.
[http://www.blug.linux.no/rfc1149/](http://www.blug.linux.no/rfc1149/) The
ping over that link was not good
[http://www.blug.linux.no/rfc1149/pinglogg/](http://www.blug.linux.no/rfc1149/pinglogg/)

~~~
werid
The RFC is from 1990, the implementation from 2001.

------
barosl
> Is it that someone didn’t see the date of the RFC, maybe sarcasm doesn’t
> translate very well, possibly someone in the real world actually sent the
> evil bit when doing evil things, and cause some products to target it?

I think it was done just for fun. It is slightly concerning that a live
equipment has such a joke enabled, but I'd say its fun-to-price ratio is
relatively high.

~~~
RobIII
I'm not intimately familiar with the RFC's but you could argue that since that
bit is technically `reserved` when it's set the packet is 'invalid' and thus
should be dropped (by some manufacturers reasoning maybe, not mine
specifically)?

Also: IIRC IP packets contain CRC's/checksums of some sort. I'm not sure if
the poster corrected for that or maybe the other side does(n't) and somewhere
the CRC doesn't check out and _thus_ the packet is dropped/invalid (or maybe
even somewhere along the way by at a hop that chokes on such bit)?

~~~
barosl
Reading RFC 791 again, it is said that the reserved bit "must be zero".[1] I'm
not sure if it is reasonable to force a "reserved" flag to be a certain value,
but I guess if one is following the RFC rigorously, dropping packets with the
reserved bit enabled is the correct behavior?

[1] [https://tools.ietf.org/html/rfc791](https://tools.ietf.org/html/rfc791)

~~~
LukaAl
No. Imagine tomorrow a new RFC suggest to use the reserved bit for something
meaningful. Any implementation that check that bit and drop the packet if the
bit is 1 is broken immediately, even if it is not impacted.

True story, some years ago I had to design a protocol for remote configuration
using text messages. We used a char to send the status in a compact format but
in the first version we used only the first 3 bit and we specified that all
the other bit should be zero (we have done so in order to have a predictable
default in the future and also to increase the readability of the logs). After
few months in the field we noticed that using an additional bit would be
useful. Don't want to go into many details, not a problem if the bit is
ignored but nice to have to simplify the operations. We updated the protocol,
issued the new specs, the vendors develop the new version, we test the new
version and surprise: the IOT between the new server and the old client was
broken. Why? Because the designer the implementer of the client was to strict
on the must be zero clause and decided that a packet with a one was a corrupt
packet and should be dropped.

The result was a slow campaign of firmware upgrade and a 1 year delay of
introduction of the new protocol. And it was a closed system where we had full
control of clients and servers. Imagine what happens with open systems.

By the way, it is an application of this principle:
[https://en.wikipedia.org/wiki/Robustness_principle](https://en.wikipedia.org/wiki/Robustness_principle)

------
eponeponepon
I yearn for a world in which that RFC were viable.

I love that anyone's implemented it at all though, and I really hope it's
deliberate on the part of the people who drop the packet.

~~~
RobIII
> I love that anyone's implemented it at all though

Similarly I have had a page online for years (may still be, can't remember the
exact url... so I'd have to dig a little) that was served with HTTP status

    
    
      418 I'm a teapot
    

See
[https://tools.ietf.org/html/rfc2324#section-2.3.2](https://tools.ietf.org/html/rfc2324#section-2.3.2)
:-)

~~~
iMerNibor
[http://www.google.com/teapot](http://www.google.com/teapot) :D

~~~
nkrisc
Visit that link on your phone and tilt it.

~~~
anonymfus
You can just click/tap the pot instead.

------
daveguy
One of the domains that identifies and drops evil bit packets -- Kaspersky.com
... Smart, Kaspersky, smart.

------
frik
Some of the websites used probably Kaspersky software (anti virus, etc. from
Eastern Europe)

------
hdmoore
Funny enough, we found a practical application for this during my time at
BreakingPoint. The BPS-1000 appliance would mix a huge number of concurrent
streams through a device under test; we added a feature to flag the exploit
traffic as evil by setting the RFC 3514 bit:
[https://strikecenter.ixiacom.com/articles/permalink?month=06...](https://strikecenter.ixiacom.com/articles/permalink?month=06&year=2007&title=rfc3514-setting-
the-evil-bit&day=20)

This made it easier for manufacturers of IDS/IPS/UTM/NGFW equipment to quickly
isolate false negatives during fully loaded tests.

------
tomrod
What's going on here, exactly?

~~~
JosephRedfern
Author modified his OS kernel to set the "Evil Bit" (as proposed in RFC3514)
on every TCP Packet Header. Having scanned the Alexa 100K, the author found
that some servers actually followed RFC3514 and dropped traffic with the Evil
bit set.

~~~
akshatpradhan
excellent ELI5!

------
yanazendo
The evil bit is valuable; but with byzantine attacks who knows what to
believe.

