[148071] in North American Network Operators' Group
Re: Does anybody out there use Authentication Header (AH)?
daemon@ATHENA.MIT.EDU (Jack Kohn)
Sun Jan 1 20:57:42 2012
In-Reply-To: <97DDC358-2C4A-4AAD-B176-72F2BC64A47B@cs.columbia.edu>
Date: Mon, 2 Jan 2012 07:26:51 +0530
From: Jack Kohn <kohn.jack@gmail.com>
To: Steven Bellovin <smb@cs.columbia.edu>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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 <smb@cs.columbia.edu> wrote=
:
>
> On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
>
>> John,
>>
>> Unlike AH, =A0ESP in transport mode does not provide integrity and authe=
ntication for the entire IP packet. However, =A0in Tunnel Mode, =A0where th=
e entire original IP packet is encapsulated with a new packet header added,=
=A0ESP protection is afforded to the whole inner IP packet (including the =
inner header) while the outer header (including any outer IPv4 options or I=
Pv6 extension headers) remains unprotected. =A0Thus, you need AH to authent=
icate the integrity of the outer header packet information.
>
>
> Not quite. =A0While the cryptographic integrity check does not cover the =
source and destination addresses -- the really interesting part of the oute=
r header -- they're bound to the security association, and hence checked se=
parately. =A0Below is a note I sent to the IPsec mailing list in 1999.
>
> That, however, is not the question that is being asked here. =A0The IPsec=
me working group has been over those issues repeatedly; your (non)-issue an=
d (slightly) more substantive issues about IPv6 have been rehashed ad nause=
um. =A0The questions on the table now are, first, are operators using AH, a=
nd if so is ESP with NULL encryption an option?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--Steve Bellovin, https://www.cs.columbia.=
edu/~smb
>
>
> =A0 =A0 =A0 =A0One of the biggest reasons we have AH is because there _ar=
e_
> =A0 =A0 =A0 =A0some things in the middle of the "IP header" that need to =
be
> =A0 =A0 =A0 =A0authenticated for them to be simultaneously safe and usefu=
l.
> =A0 =A0 =A0 =A0The 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. =A0You 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. =A0To the extent that we want to protect the addresses --
> a point that's very unclear to me -- they're bound to the security
> association. =A0The security label certainly should be. =A0If you're usin=
g
> 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.
>
> =A0 =A0 =A0 =A0I'll admit that I've never been in the operations business=
, but
> =A0 =A0 =A0 =A0I've been told that source routing is a very useful tool f=
or
> =A0 =A0 =A0 =A0diagnosing some classes of problems. =A0AH allows source r=
outing
> =A0 =A0 =A0 =A0to be useful again w/o opening the holes it opens.
>
> Well, yes, but not for the reason you specify. =A0The problem with source
> routing is that it makes address-spoofing trivial. =A0With 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. =A0The 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). =A0Its 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. =A0But I'm very far from convinced that these issues are
> important enough to justify AH.
>
> All that notwithstanding, this is not a new issue. =A0We've been over
> this ground before in the working group. =A0Several of us, myself
> included, suggested deleting AH. =A0We lost. =A0Fine; so be it. =A0Let's =
ship
> the documents and be done with it.
