Re: [IPsec] draft-bhatia-moving-ah-to-historic

[Nick Hilliard <[e-mail]>]

On 16/04/2012 12:25, Yoav Nir wrote:
> It only adds confusion and complication in the sense that telnet adds
> them (ESP is SSH in this analogy).

To be fair, it adds a lot more confusion than telnet vs ssh.  With my
!inex.ie hats on, I see smart but untrained ops people attempting to
configure up their firewall / vpn systems and not realise that AH is
actually a separate protocol, but actually requires end-to-end support for
protocol 51.  Then they stumble on the fact that it doesn't work with NAT
and further anxiety ensues.

Debugging firewall problems is at least a level 2 support issue, and often
requires escalation to level 3.  This sort of support burden is expensive.

> If you don't implement it you and your users don't get confused.

It's not me using it -  it's my clients' customers.  The end-users are one
level further removed from that.

> Besides, the end users of IPsec who actually have to know what ESP is vs
> what AH is are very sophisticated. They're not the people who simply
> press "Connect" on their L2TP or VPN clients.

Indeed, and I'm talking about operators who configure these services, not
end users who click connect.

> Maybe, maybe not. As ISPs move large blocks of users to a combination of
> IPv6 and CGN, blocks of IPv4 address space may be freed up. But
> regardless, NAT *is* going to be with us for a while, even in IPv6.

I question whether we will ever transition to ipv6.  I hope we will, but
rate it somewhat unlikely at this stage of the Internet's evolution.  This
is a separate discussion though.

IPv4 NAT will be around for the forseeable future - e.g. many decades at
the very least.

> Nothing's stopping you from proposing 4302bis, which will be compatible
> with NATs. There just isn't much demand for changing AH like that.

That particular wheel has already been invented many times at many layers
(esp, ssl/tls, etc).

> Suppose the TICTOC working group decide that they need packet
> authentication for time signals, but not encryption. (makes sense, as
> they only deliver the time of day). They can go with either AH or
> ESP-Null. They also don't care about NAT, because NATs introduce so much
> jitter, that they'll ruin the accuracy of PTP, so PTP does not go
> through NAT anyway. They also first construct the IPsec packet, then
> paste the timestamp where it's needed, and quickly calculate the hash.
> If they can do this with less jitter with AH than with ESP, do you think
> they'll actually care whether they're using a "current" or "historic"
> standard?  They'll just use whatever gets the job done better.

This is an edge case.  It's possible to create edge cases for anything.

> Even "historic" does not mean everyone has to stop using it, even in new
> standards. It just means that you have to have a really good
> justification why you need that rather than ESP. That's the situation
> already. Declaring it so doesn't help.

The IETF is very self-deprecating about historic status.  There's nothing
wrong with a document saying:

--
operators: this protocol has serious problems in practice.  therefore we
suggest you use $otherprotocol which has none of these problems and is
better in almost every other respect.

developers: don't bother. no point.
--

Call it good housekeeping.  Call it operational guidance that access
providers can show to their customers about why AH is not a good idea.
Whatever it's called, historic status is a good place for moribund
protocols to be placed, lovingly or otherwise.

> Well, this draft generated a 77-post thread. Then the mailing list got
> quiet about it, and we had three months without any mention of AH.

Sounds pretty typical for most mailing lists...?

> I think moving it to historic creates a lot more mailing list chatter
> than ignoring it.

Right now yes.  But this argument will go round in circles for the next 50
years until people finally accept that AH is generally not useful.  During
that time, there will be much mailing list chatter about it, on this and
other lists.  Best consign it to history and close that particular door.
It was good while it was relevant, but those times are gone.

Nick