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.
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.
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]
