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.
