On Sat, Jan 3, 2026 at 1:47 PM Brian E Carpenter <[email protected]> wrote: > > On 04-Jan-26 09:31, Tom Herbert wrote: > > 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. > > Yes. That's exactly what I meant. That could be suggested in the draft.
Hi Brain, Good idea! > > > > > 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. > > I agree. But we can assume that certain large vendors will move more > slowly on this than even the IETF :-(. It isn't only Linux. We're always just one well publicized security breach from vendors moving quickly ;-) Tom > > Brian > > > > > 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]
