Re: Does anybody out there use Authentication Header (AH)?

[Steven Bellovin <smb () cs columbia edu>]

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.