Mr. Herbert, I am not sure why you are so excited to delete a feature that others are certainly using. Why use your valuable time to make trouble for others? Isn't standing on each others' shoulders better than standing on each others' toes?
"Deprecating" a protocol feature is more of a political statement than a technical statement. For example, I recall an Internet-Draft proposing to deprecate the entire IPv4 protocol suite: draft-howard-sunset4-v4historic-00. Its successor, draft-ietf-sunset4-ipv6-ietf-01, was approved by a small wg with three total votes, and actually made it to an IETF Last Call before saner heads prevailed, pointing out that the majority of traffic on the Internet was running over this "to-be-deprecated" protocol. The draft claims that there's no reason to run AH and "extrapolates" (sec. 3.3) that it is "not used anywhere". Clearly the author did not research the history of AH and ESP, the Crypto Wars, and the legal landmines that led to the development of authentication-only protocols. There have been, and are, many countries where encryption is illegal. You can't assume that full blown unbreakable encryption like IKE/ESP is available everywhere on the Internet, because it makes governments nervous when they can't wiretap their citizens. AH does not threaten them, which is why the IPSEC WG designed and deployed it. Distributing ESP in the United States was illegal until the year 2000 when EFF.org led a court case that overturned the multiple crypto export control laws that made it a felony. (It is still illegal to use ESP encryption, and TLS, over amateur radio links in the United States. And yes, IP runs over amateur radio links all over the world.) In 2026, the UK and EU are trying hard to outlaw encryption of messaging applications on the theory that bluenoses can't spy on who's trading dirty pictures -- and the US Congress was not far behind in trying to pass such a law last year. There are today major countries that entirely ban VPNs too -- China is an example. Tom Herbert <[email protected]> wrote: > To deprecate a protocol like this we can take a phased approach that > has been used for other features being deprecated. First, we'll > disable it to be compiled by default and give a nice warning that the > protocol is being deprecated. Once that's fully deployed and if no one > complains the feature is being deprecated then the code for the > protocol can safely be removed. First, most people don't compile their kernels. They run a popular Linux distribution that provides a small selection of kernels. If the mainline kernel config defaults the feature to "off" and the distros are not savvy enough to turn it back on for their customers, then anyone who was depending on the feature will suddenly discover that upgrading their OS to the latest version has broken whatever subsystem depended on the feature. This backward-incompatible breakage is the sort of thing that causes people to be very wary of upgrading to new OS releases. Their justified hesitancy, as another poster pointed out, is very bad for getting people to install the regular updates that close major security holes throughout the Internet. So breaking backward compatability is only justified in the most extreme cases. The "complaints" of end-users will mostly just turn the air blue around the user's or sysadmin's desk. Possibly they will be mad enough to send an email to their distro complaining that the feature went away for no obvious reason. Which will probably be filed in a bug-tracking system, and then later closed unfixed by someone or some daemon to make it look like they don't have any pending bugs. Essentially none of the users will send anything to the Linux-Kernel mailing list, or to you (the responsible party). So unless you make some particularly special arrangements to get feedback from ordinary users, there's no way for you to ever know that "no one complains". Second, the fix that you propose to require end-users and sysadmins to apply, after they discover that AH is broken, is to learn how to download, configure and build kernels from source code, and to then step through that process. But also to find and override the default that you created in the rat's nest of config options, the specific setting which makes AH not work. This is a relatively steep learning curve for most end users. You can probably do it in your sleep, but most people don't want to be kernel maintainers. And if end users do go through this step and make AH work again for them, they will likely not produce the "complaints" back to you that would prevent you from taking the second step and deleting the code entirely from some future mainline kernel release. Which would make an entirely greater burden on the end users once that kernel landed in their OS release. They'd have to resurrect the code from a prior kernel release, manually tease it out and integrate it and its config hooks into their modern kernel, and reconfigure and rebuild their kernel and reinstall it. That's an order of magnitude harder (e.g. they'd need to know C programming), and even more likely to produce unrelated errors or breakages. The easiest thing for users would be to not break AH at all. But it would certainly be easier for them if they could do a web search that led to: "Put this sysctl command in your /etc/rc.local and it will turn AH support back on every time you boot your machine." That's a much smaller lift than pointing them at a many-page document on how to configure kernels, rebuild them, reinstall them and test them. Maybe the suggested fix should also include: And put this command into your /etc/rc.local too: echo "Yes we still use AH don't delete it." | /bin/mail [email protected] As another poster suggested, it's likely that many end users would just downgrade their system to an OS release that still works for them. Which has all the security and compatability problems of running back-rev OS's. Why force them into making such a choice? In my own small home network I am facing a very similar issue due to the mainline kernel and distros removing support for SMB v1 (over security issues). The change was not backward compatible, and the result is that a piece of proprietary high-end audio gear that used to access my music library over SMB v1 can no longer reach my music collection. This left me with many possible paths to resolution, such as: * Junk my whole-house audio system * Try to get the supplier to provide an upgrade to SMB v2 or to NFS, for this product that they no longer produce * Try to manually patch the proprietary audio system (which runs an unfamiliar version of Linux under their proprietary code) to support SMB v2. * Find the old SMB v1 kernel code and manually merge it into a modern kernel in my file server * Downgrade my file server to run an old Ubuntu release with SMB v1 support Since I am my own sysadmin, and doing days of sysadmin is my least favorite activity, I have so far taken path #1 -- my music system is wrecked. In the SMB v1 case, I at least see why the kernel maintainers did what they did, despite the trouble that they caused me. In the case of AH support, I see zero reason to make it stop working, except misplaced zeal. John _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
