Live data from Hacker News

I may be the only evil bit user on the internet

blog.benjojo.co.uk

21–30 of 39 posts

Re: I may be the only evil bit user on the internet

#22
post #15

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.

> 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

Re: I may be the only evil bit user on the internet

#23

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.

Unfortunately it isn't clear what might be considered "evil" or an "attack". Probably section 1.1 should be extended accordingly.

Re: I may be the only evil bit user on the internet

#24
post #9
post #8

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!

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…

This may be better than allowing the bit to desynchronise your firewall's state machine. However, if you want to be nazi like that you may actually prefer not to route your network to the Internet at the IP layer but rather provide application-level proxies (IIRC Check Point products can be configured like this).

Re: I may be the only evil bit user on the internet

#25
post #16
post #14

Earlier 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

If you don't force it to be a certain value, its hardly reserved. Then it's just a free bit that anybody can use for anything. Reserved means it has to be able to be used for something else in the future, and for that to be possible it has to have a known default value.

Re: I may be the only evil bit user on the internet

#26
post #5

What'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.

excellent ELI5!

Re: I may be the only evil bit user on the internet

#27
post #16
post #14

Earlier 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

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

Re: I may be the only evil bit user on the internet

#28
post #15

Earlier 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

Visit that link on your phone and tilt it.
Post reply on HN