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

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Apr 2012 11:53:02 +0100

I'd like to add a voice of support to this draft.  AH adds little except
complication to ipsec implementations and confusion to end users.

Regarding ipv4 NATs, they are ubiquitous and will become more so once ipv4
scarcity is realised worldwide (particularly in asia, which is currently
the fastest growing global region, and has already reached RIR exhaustion).

There was a previous comment about this draft about the NAT/AH issue being
a NAT problem rather than an AH problem.  Well, yeah, in the purest sense
this is true, but we live in the real world and need to work within its
limitations.  You can apply fixups and ALGs to lots of protocols which are
NAT sensitive, but AH is cryptographically incompatible with NAT and this
cannot be fixed.

I see little value in the IETF formally supporting a protocol which simply
cannot work for most end-users on the basis of the access addressing
provided.  Formal deprecation / designation to historic status is
appropriate in this case.

Also +1 to the following arguments:

- ESP + NULL == substantially equivalent
- less mailing list chatter

Nick

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Apr 2012 14:25:51 +0300

> complication to ipsec implementations and confusion to end users.

It only adds confusion and complication in the sense that telnet adds them (ESP is SSH in this analogy). If you don't implement it you and your users don't get confused. 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.

> the fastest growing global region, and has already reached RIR exhaustion).

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.

> NAT sensitive, but AH is cryptographically incompatible with NAT and this

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

> appropriate in this case.

Formal deprecation is pretty much meaningless. Consider this example:
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.

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.

> - less mailing list chatter

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. I think moving it to historic creates a lot more mailing list chatter than ignoring it.

Yoav

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Apr 2012 18:22:31 +0200

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