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

[Yoav Nir <[e-mail]>]

On Apr 16, 2012, at 1:53 PM, Nick Hilliard wrote:

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

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.

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

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.

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

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

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

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.

> Also +1 to the following arguments:
> 
> - ESP + NULL == substantially equivalent
> - 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