💾 Archived View for thrig.me › blog › 2023 › 03 › 13 › going-postel.gmi captured on 2023-05-24 at 18:21:11. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
Maintaining Robust Protocols February 2023
A short summary of the above is to "reduce ambiguity over time and create a healthy ecosystem". Nuance has been gained; various downsides of "being liberal in what you accept" have been noted. Old implementations were expected to be conservative in what they sent, and to silently discard unexpected inputs unless the specification required an error message. The draft instead recommends "active maintenance" instead of an accumulation of tolerances for whatever wacky things the other end might do.
If we look at the last version of ISC DHCP (4.4.3-P1, released October 2022) there are references to "picky DHCP clients (e.g., Windows 95)" with broadcast address changes not being "a problem on Linux 2.2 and later kernels". Support for Windows 95 ended around the year 2000; Linux 2.2 was released in 1999, and yet there's still documentation for this two decades later. This documentation is of historic interest, but left unchecked it's noise to wade through for someone looking for current issues with current systems.
What if we have a malicious or buggy client?
The DHCPDECLINE message is used by DHCP clients to indicate that the lease the server has offered is not valid. When the server receives a DHCPDECLINE for a particular address, it normally abandons that address, assuming that some unauthorized system is using it. Unfortunately, a malicious or buggy client can, using DHCPDECLINE messages, completely exhaust the DHCP server's allocation pool. The server will eventually reclaim these leases, but not while the client is running through the pool. This may cause serious thrashing in the DNS, and it will also cause the DHCP server to forget old DHCP client address allocations.
Or a vague protocol specification?
/* If the client is RENEWING, unicast to the client using the
regular IP stack. Some clients, particularly those that
follow RFC1541, are buggy, and send both ciaddr and server
identifier. We deal with this situation by assuming that
if we got both dhcp-server-identifier and ciaddr, and
giaddr was not set, then the client is on the local
network, and we can therefore unicast or broadcast to it
successfully. A client in REQUESTING state on another
network that's making this mistake will have set giaddr,
and will therefore get a relayed response from the above
code. */
RFC2132 [RFC2132] defines the initial set of DHCP Options and provides a great deal of guidance on how to go about formatting and processing options. The document unfortunately waffles to a great extent about the NULL termination of DHCP Options, and some DHCP Clients (Windows 95) have been implemented that rely upon DHCP Options containing text strings to be NULL-terminated (or else they crash).
Some might argue that DHCP is too complicated a protocol (ISC DHCP has about 100,000 lines of C) but good luck getting agreement on anything simpler. BOOTP is probably too simple, and then you're back to the "I only need 5% of X" problem where different people need different five percents. Active maintenance here would be to clarify the waffles and get most of the clients and servers in line with that.
Not crashing due to unexpected inputs might also be good.
Latin is pretty dead, dead by the criterion of dead languages as used by linguists. I suspect that computers have a ways to go before the hardware and software could stabilize around any sort of unchanging specification that lasts for so brief a period as a millennium (assuming civilization keeps working for that long, etc). It might also take a change of culture.
Inactive maintenance would require that the protocol has been out there for a while, beaten into some sort of shape over years of misuse. Once dead, it would not need extensibility; the dead protocol would do what it was designed to do. But humans do like to fiddle around with things.
Encryption protocols are likely to change, other protocols maybe not so much or maybe not so quickly as in the past. But I guess there's always room for new ways to move bytes around. Especially if they simplify.
The document does talk about taking long term fixes over short term workarounds...on the other hand, computing is hilariously new in the grand scheme of things.
https://www.youtube.com/watch?v=D2JaaolRcHw
tags #protocol #dhcp