Does anybody out there use Authentication Header (AH)?

Steven Bellovin smb at cs.columbia.edu
Sun Jan 1 19:50:29 CST 2012


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.


More information about the NANOG mailing list