On Sat, Jan 3, 2026 at 12:03 PM Brian E Carpenter <[email protected]> wrote: > > Tom, > > Documenting why AH is a Bad Thing and shouldn't be used unless there is > operationally no alternative is something the IETF can do. As I said already, > that is exactly what SHOULD NOT means in IETF-speak. > > I've done such things myself [RFC3879][RFC6343][RFC6563][RFC7526] and I think > the IETF should do more of it. > > But that's very different from the "strip it all out" approach, which simply > isn't OK on a running system. Somebody somewhere is using it for production, > whatever it is. Configuring it off by default is fine. Zapping it completely > isn't.
Brian, It's a two stage process. First the feature is disabled by default, and then after nobody complains that it's being deprecated then it can be safely removed. If IETF recommends that a protocol SHOULD NOT be used isn't that sort of a hint that the protocol really *shouldn't* be used? It seems like it's the prerogative of implementations to take the necessary steps to promote a SHOULD NOT. Also, indefinitely maintaining an implementation for a security protocol that IETF doesn't recommend to be used seems inherently risky to me. Tom > > Regards/Ngā mihi > Brian > On 04-Jan-26 08:31, Tom Herbert wrote: > > On Sat, Jan 3, 2026 at 9:45 AM Acee Lindem <[email protected]> wrote: > >> > >> I don't see a compelling argument to deprecate AH and doubt this draft > >> will gain traction. If anything, you could write a draft documenting the > >> problem with NAT compatibility. > > > > Hi Acee, > > > > The problem is continuing to support AH in implementation when it's > > not used and not even usable for the vast majority of host is a > > liability and is risk if someone tries to use it (i.e. if the code is > > not being routinely exercised then there is a greater chance of bugs). > > Unless there's a compelling reason otherwise put forward, my intent is > > to remove AH support from Linux at least. I would prefer that IETF > > would formally deprecate the protocol for that, but it's not > > necessary-- frankly, it wouldn't be the first time that > > implementations taken action when IETF fails to keep protocol > > specifications in line with realities of the real world. > > > > As for documenting the problems with NAT compatibility, that seems > > like a pretty pointless exercise since this has been a known problem > > for at least twenty. Documenting that NAT breaks AH changes nothing. > > > > Tom > > > > > > > >> > >> Thanks, > >> Acee > >> > >>> On Jan 2, 2026, at 9:18 PM, Brian E Carpenter > >>> <[email protected]> wrote: > >>> > >>>> I was looking for a way to see which RFCs cite RFC-4302 (and RFC-2402). > >>>> Is there one? Google wasn't any help; although, the AI's response to > >>>> "What cites rfc-4302?" is a great imitation of Humphrey Appleby in "Yes > >>>> Minister". > >>> > >>> https://datatracker.ietf.org/doc/rfc4302/referencedby/ > >>> https://datatracker.ietf.org/doc/rfc2402/referencedby/ > >>> > >>> Regards/Ngā mihi > >>> Brian Carpenter > >>> > >>> On 03-Jan-26 12:40, Robinson, Herbie wrote: > >>>> From: Eliot Lear <[email protected]> > >>>>> On 02.01.2026 13:24, Tom Herbert wrote: > >>>>>> We cannot prove no one is using it, however given the fact NAT breaks > >>>>>> AH and AH would break checksum offload (at least in LInux) the vast > >>>>>> majority of billions of computers couldn't use AH even if they wanted > >>>>>> to. > >>>>> Just an FYI- there are implementations that DO use AH that would not > >>>>> generally > >>>>> be impacted by NAT. These would be used in site-to-site VPNs and with > >>>>> OSPFv3. > >>>>> AH is recommended by at least two vendors for use with OSPFv3 > >>>>> (specifically with IPv6)[1,2] > >>>>> to match the advice given in RFC 5340 [3] that neither been updated nor > >>>>> obsoleted. > >>>>> There are probably other RFCs hiding out there that use IPSEC as a > >>>>> crutch, > >>>>> given that was common practice in the 1990s and early 2000s. If you're > >>>>> going to deprecate AH, > >>>>> you should probably do a little digging to see what we're in for. > >>>>> Finally, I would advise against policy changes based on extrapolations. > >>>>> Eliot > >>>> o The Cisco doc says you can use either AH or ESP. I didn't see > >>>> anywhere where they specifically recommend AH (but I was reading > >>>> quickly). > >>>> o The Juniper doc linked to gives examples for setting up AH and doesn't > >>>> mention ESP. The page linked to at the bottom implies they also support > >>>> ESP, but it's not real clear. > >>>> Practically every hash and authentication algorithm listed in the vendor > >>>> examples is considered insecure. That doesn't necessarily mean > >>>> anything, it could just be out-of-date documentation. Up-to-date > >>>> recommendations would probably be to use GCM (which has to be ESP and is > >>>> probably faster than any secure hash used alone with the AH protocol). > >>>> The only thing relevant I see there is that configuration changes would > >>>> be necessary if AH actually got removed. > >>>> RFC-5340 refers to RFC-4552 -- The bulk of the IPSec discussion appears > >>>> there. The key phrase I see is "In order to provide authentication to > >>>> OSPFv3, implementations MUST support ESP and MAY support AH." It would > >>>> appears that movement to deprecate AH was already afoot. > >>>> In terms of Tom's document, I think maybe there should be a quick > >>>> reference to RFC-4552. > >>>> I was looking for a way to see which RFCs cite RFC-4302 (and RFC-2402). > >>>> Is there one? Google wasn't any help; although, the AI's response to > >>>> "What cites rfc-4302?" is a great imitation of Humphrey Appleby in "Yes > >>>> Minister". > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> [email protected] > >>>> List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ > >>>> -------------------------------------------------------------------- > >> _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
