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 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. > > 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 <s...@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. > --Steve Bellovin, https://www.cs.columbia.edu/~smb
