Does anybody out there use Authentication Header (AH)?


I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL.

Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them?


AH provides for connectionless integrity and data origin authentication and provides protection against replay attacks. Many US Gov departments that have to follow NIST and do not understand what this means require it between internal point-to-point routers between one portion of their organization and another adding more expense for no increase in operational security.

If you are following NIST or DCID-63, this is required to meet certain integrity requirements

ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. EG AH portion provides for the integrity requirement and the ESP encryption provides for the confidentiality requirement of NIST.

Think of AH that it is like just signing a PGPMail and ESP as signing and encrypting a PGPMail.

There are reasons for both.


(Sigh) Here we go again.

AH is a liability and a baggage that we're carrying over our weary
shoulders. IMO we should have gotten rid of it long time back. There
have been enough emails on multiple forums over this and google is
probably your friend here. The only reason(s) we have AH is because
(i) circa early 1990s, US had export restrictions on encryption keys >
40 bits and ESP thus had restrictions on how it could be used. AH
otoh, only did authentication, for which the rules were much more
relaxed AND (ii) people earlier naively believed that AH protected the
IP header and ESP couldnt.

AH is a mess if you have NATs deployed, as AH breaks NAT. IPv6
proponents thus saw AH as a tool to push IPv6, since they hated NATs
(till someone discovered IPv6 NAT-PT, but thats a different story).

Most people think ESP as "encryption" - they forget that it can be
used for data integrity verification without encryption as well.


Hi Tom,

Thanks for the reply.

Why cant we use ESP/NULL for meeting the NIST requirement? Is there something extra that AH offers here?



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.

Again, just like PGPMail as I explained before,


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,

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

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.

The __exact__ same discussion happening on IPsecME WG right now.

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


Yes, I know; I'm on that list. John Smith decided to see if
reality matched theory -- always a good thing to do -- and asked

Btw, it's not just "this time there is some support for it"; AH
was downgraded to "MAY" in RFC 4301 in 2005.

As far as real world examples, I know of none that use AH only. All the operational uses I have seen in use are tunnels.

I would guess that if there are any it would be because some minimally technical COI rep thought that by using it it would provide some minimalist support of their interpretation of FISMA.



It seems NIST recommends ESP over AH.

You can look at the following 2 emails from Manav and Sriram on the IPsecME WG: