I may be the only evil bit user on the internet
21–30 of 39 posts
Re: I may be the only evil bit user on the internet
#22I 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.
> 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 :-)
Re: I may be the only evil bit user on the internet
#23I 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.
Re: I may be the only evil bit user on the internet
#24While 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!
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 impro…
Re: I may be the only evil bit user on the internet
#25Earlier quoted context omitted.
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 an…
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
Re: I may be the only evil bit user on the internet
#26What's going on here, exactly?
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.
Re: I may be the only evil bit user on the internet
#27Earlier quoted context omitted.
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 an…
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
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
Re: I may be the only evil bit user on the internet
#28Earlier quoted context omitted.
> 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 :-)
http://www.google.com/teapot :D