[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Death to AH (was Re: SA identification)

Pekka,

Here is my response to your question:

1. Almost no one but a very tiny minority of IPsec users employ AH, at least
among our customer base. But AH doubles the testing cost of IPsec per se (as
distinct from key management). Testing dominates the cost of developing and
deploying IPsec, so AH seems like a non-trivial tax to impose on everyone
who otherwise might want to use IPsec. This does not seem like a reasonable
engineering tradeoff if an alternative exists.

2. The added complexity of AH bloats the IPsec drivers and silicon and makes
it much harder to determine when they have been designed and implemented
correctly. As an industry it's hard to understand how anyone can think we
know whether we are really contributing to anyone's security, because
correctly analyzing the security properties of implementations that do all
the AH/ESP/IPPCP/Tunnel/Transport combinations with 5 different ciphers (and
Null encryption, too), 3 MACs, and 2 compression protocols is something we
have repeatedly proved human beings can't reliably do with much facility or
grace. Eliminating rarely used options leads to simpler implementations that
are easier to understand and therefore to an improved likelihood the device
will operate correctly, given the same level of due diligence on our part as
implementors.

3. Most users of IPsec technology can't figure out when to use AH and when
to use ESP with data authentication. Any protocol that tries like IPsec to
market itself as everyone's answer to wire security had better be correctly
configured by any second grader, and IPsec can't exactly claim this at the
moment. Getting rid of options, especially infrequently sued options, would
certainly contribute toward this so far ignored requirement.

There were about 6 of us (out of 2 or 3 hundred) who voted to abolish AH at
the LA IETF meeting, and the subject keeps coming up with regularity every 9
months or so, but AH stays in the spec as mandatory to implement. What
reason can anyone give to hope that anything has changed? This discussion
has identified one AH application, and because of this it will be very hard
to root it out, no matter what the relative merits of casting it out versus
retaining it as mandatory to implement.

-- Jesse Walker

-----Original Message-----
From: Pekka Nikander [mailto:Pekka.Nikander@nomadiclab.com]
Sent: Friday, March 23, 2001 7:55 AM
To: IP Security List
Subject: Re: Death to AH (was Re: SA identification)


Based on discussion with some people, I'd like to ask a simple
question.  I know, most of this has been discussed to death before,
but for me the exact reason for killing AH seems unclear.  If you
don't want to clutter the list, feel free to send your reply to me
and I'll try to summarize whatever I receive.

Thus, which do you consider a bigger problem in AH,
 
 a) the fact that AH protects the IP addresses, which make it impossible
    to change the addresses on the fly, or

 b) the fact that AH attempts to protect all of "immutable" fields in
    the IP address, and actually deciding which fields are immutable
    and which are not is not that easy, or

 c) doing AH right is just hard because all that hassle with mutable
    vs. immutable fields in the header?

That is, is it that wrt NAT the IP address fields are not immutable 
anymore, and therefore protecting them with AH seems not that productive.
Or is it that there are also other fields that are considered immutable
by the AH spec but are not.  Or is it that doing AH right is just 
so complex because you have to parse the header and zero some fields etc?

(I don't see any reason for protecting the addresses since if you are 
doing end-to-end ipsec, protecting the addresses is (almost) pointless,
and if you are not doing end-to-end and want to rely on addresses,
you most probably want to do tunneling anyway).  

Or am I missing something, and the problem with AH is something
completely different?

--Pekka