On Fri, Jan 2, 2026 at 8:33 AM Robinson, Herbie <[email protected]> wrote: > > This might be an unusual case, because IKE can negotiate around it, but in > general, assuming you can remove a feature you’re your because the IETF has > deprecated it will get you into trouble with your customers/clients or > whatever. The practical meaning of deprecated means you don’t have to > support it in new implementations and should try to stop fixing bugs in it. > In the case of AH, deprecation means that we don’t have to figure out what to > do about every new case where it’s incompatible with some new Internet > protocol (or the existing places where it doesn’t work).
Herbie, If a protocol is deprecated that should mean that no one is using it or the code that implements it. In that case, we want to remove unused code from implementations because maintaining the it is not without cost and unused/untested code becomes a liability and a risk when someone tries to use it. 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. Tom > > > > From: Tom Herbert <[email protected]> > Sent: Thursday, January 1, 2026 9:29 PM > To: Fernando Gont <[email protected]> > Cc: int-area <[email protected]>; 6MAN <[email protected]> > Subject: [Int-area] Re: [IPv6]Re: Fwd: New Version Notification for > draft-herbert-deprecate-auth-header-00.txt > > > > Penguin Solutions Security Checkpoint: External email. Please make sure you > trust this source before clicking links or opening attachments. > > > > On Thu, Jan 1, 2026, 5:59 PM Fernando Gont <[email protected]> wrote: > > > > On 31/12/2025 18:16, Tom Herbert wrote: > > On Wed, Dec 31, 2025 at 1:12 PM Brian E Carpenter > > <[email protected]> wrote: > >> > >> Hi, > >> > >> I'm no expert, but I think the Security Area might have an opinion on this. > >> > >> Note that according to RFC 8221: > >> > >> "The last method that can be used is ESP+AH. This method is NOT > >> RECOMMENDED." > >> > >> "ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to > >> enable the use of ESP with only authentication, which is preferred > >> over AH due to NAT traversal." > >> > >> "As mentioned by [RFC7321], it is NOT > >> RECOMMENDED to use ESP with NULL authentication (with non- > >> authenticated encryption) in conjunction with AH; some configurations > >> of this combination of services have been shown to be insecure > >> [PD10]." > >> > >> That seems pretty close to deprecation already. > > > > HI Brian, > > > > Indeed. I'm looking forward to completing the formal deprecation and > > removing the code from the OS (linux at least) :-). > > FWIW, if you're into that, you may start by disabling the feature by > default and/or implementing a sysctl to do so. > > > > Hi Fernando > > > > The first step would be to turn off compiling AH by default in Kconfig with a > warning that it's deprecated. After that the code would be removed. > > > > Tom > > > Thanks, > -- > Fernando Gont > e-mail: [email protected] > PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01 _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
