[148072] in North American Network Operators' Group
Re: Does anybody out there use Authentication Header (AH)?
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Sun Jan 1 21:04:00 2012
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <CAA1nO72uavpLO+4O-+JqdBW+gnvzC405yc-cH6FxJtdwT6bmQA@mail.gmail.com>
Date: Sun, 1 Jan 2012 21:03:02 -0500
To: Jack Kohn <kohn.jack@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Yes, I know; I'm on that list. John Smith decided to see if=20
reality matched theory -- always a good thing to do -- and asked
here.
Btw, it's not just "this time there is some support for it"; AH
was downgraded to "MAY" in RFC 4301 in 2005.
On Jan 1, 2012, at 8:56 PM, Jack Kohn wrote:
> The __exact__ same discussion happening on IPsecME WG right now.
>=20
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html
>=20
> It seems there is yet another effort being made to "retire" AH so that
> we have less # of options to deal with. This time there is some
> support for it ..
>=20
> Jack
>=20
> On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin <smb@cs.columbia.edu> =
wrote:
>>=20
>> On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
>>=20
>>> John,
>>>=20
>>> Unlike AH, ESP in transport mode does not provide integrity and =
authentication for the entire IP packet. However, in Tunnel Mode, =
where the entire original IP packet is encapsulated with a new packet =
header added, ESP protection is afforded to the whole inner IP packet =
(including the inner header) while the outer header (including any outer =
IPv4 options or IPv6 extension headers) remains unprotected. Thus, you =
need AH to authenticate the integrity of the outer header packet =
information.
>>=20
>>=20
>> Not quite. While the cryptographic integrity check does not cover =
the source and destination addresses -- the really interesting part of =
the outer header -- they're bound to the security association, and hence =
checked separately. Below is a note I sent to the IPsec mailing list in =
1999.
>>=20
>> That, however, is not the question that is being asked here. The =
IPsecme working group has been over those issues repeatedly; your =
(non)-issue and (slightly) more substantive issues about IPv6 have been =
rehashed ad nauseum. The questions on the table now are, first, are =
operators using AH, and if so is ESP with NULL encryption an option?
>>=20
>> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>>=20
>>=20
>> One of the biggest reasons we have AH is because there _are_
>> some things in the middle of the "IP header" that need to be
>> authenticated for them to be simultaneously safe and useful.
>> The biggest example of this is source routing.
>>=20
>> In my opinion -- and I've posted this before -- there's nothing in =
the
>> IP header that's both interesting and protected. You can't protect =
the
>> source routing option, since the next-hop pointer changes en route.
>> Appendix A of the AH draft recognizes that, and lists it as 'mutable =
--
>> zeroed'.
>>=20
>> When you look over the list of IP header fields and options that are
>> either immutable or predictable, you find that the only things that =
are
>> really of interest are the source and destination addresses and the
>> security label. To the extent that we want to protect the addresses =
--
>> a point that's very unclear to me -- they're bound to the security
>> association. The security label certainly should be. If you're =
using
>> security labels (almost no one does) and you don't have the =
facilities
>> to bind it at key management time, use tunnel mode and be done with =
it.
>>=20
>> I'll admit that I've never been in the operations business, =
but
>> I've been told that source routing is a very useful tool for
>> diagnosing some classes of problems. AH allows source routing
>> to be useful again w/o opening the holes it opens.
>>=20
>> Well, yes, but not for the reason you specify. The problem with =
source
>> routing is that it makes address-spoofing trivial. With AH, people
>> will either verify certificate names -- the right way to do things --
>> or they'll bind a certificate to the source address, and use AH to
>> verify the legitimacy of it. The route specified has nothing to do
>> with it, and ESP with null encryption does the same thing.
>>=20
>> I don't like AH, either in concept or design (and in particular I =
don't
>> like the way it commits layer violations). Its only real use, as I =
see
>> it, is to answer Greg Minshall's objections -- it leaves the port
>> numbers in the clear, and visible in a context-independent fashion.
>> With null encryption, the monitoring station has to know that that =
was
>> selected. But I'm very far from convinced that these issues are
>> important enough to justify AH.
>>=20
>> All that notwithstanding, this is not a new issue. We've been over
>> this ground before in the working group. Several of us, myself
>> included, suggested deleting AH. We lost. Fine; so be it. Let's =
ship
>> the documents and be done with it.
>=20
--Steve Bellovin, https://www.cs.columbia.edu/~smb
