Does anybody out there use Authentication Header (AH)?

Mon Jan 2 01:56:51 UTC 2012

The __exact__ same discussion happening on IPsecME WG right now.

http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html

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

Jack

On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
>
> On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
>
>> John,
>>
>> 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.
>
>
> 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.
>
> 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?
>
>                --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>        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.
>
> 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'.
>
> 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.
>
>        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.
>
> 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.
>
> 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.
>
> 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.