Subject: [IPsec] Moving Authentication Header (AH) to Historic

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 30 Dec 2011 00:21:34 +0530

Hi,

We have had several discussions in the past about the utility of AH when ESP with NULL encryption offers everything that AH has to offer. I have written a very small draft that recommends moving AH to the Historic status. This document does NOT deprecate AH and it does NOT mean that people should stop using AH now. All it means is that other WGs should use ESP-NULL whenever defining integrity verification mechanisms and should only use AH when authentication cannot be achieved with ESP-NULL. I also discuss a few points that people usually put in favor of AH over ESP and why I think that those are not very relevant.

I would love to hear feedback from the WG.

The URL for the draft is:
http://www.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00.txt 

Happy New Year in advance!

Cheers, Manav

From: [email-masked] 
To: [email-masked] 
Reply-to: [email-masked] 
Subject: I-D Action: draft-bhatia-moving-ah-to-historic-00.txt 
X-RSN: 1/0/935/40711/44097 
 
A New Internet-Draft is available from the on-line Internet-Drafts directories. 
 
Title : Moving Authentication Header (AH) to Historic 
Author(s) : Manav Bhatia 
Filename : draft-bhatia-moving-ah-to-historic-00.txt 
Pages : 5 
Date : 2011-12-29 
 
This document recommends retiring Authentication Header (AH) and 
discusses the reasons for doing so. It recommends moving RFC 4302 to 
Historic status. 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00.txt 
 
Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/ 
 
This Internet-Draft can be retrieved at: 
ftp://ftp.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00.txt

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Dec 2011 10:25:09 -0900

It seems to me that the NAT problem is a *NAT* problem, not an AH
problem.  I'd want to hear from the wireless guys that they think
ESP NULL is a reasonable substitute for AH, too.

More generally the only reason I can see for moving something to
historic is if it's not implemented and the environment has changed
sufficiently so that it probably shouldn't be implemented.  Don't think
AH is there yet and I don't think it's a win to push more stuff into
the publication queue.  I'm not really against this but I'm definitely
not in support of it.

Melinda

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Dec 2011 23:37:49 +0200

On Dec 29, 2011, at 9:25 PM, Melinda Shore wrote:

> problem.

I disagree with this. Section 3.3.3.1.1.1 of RFC 4302 lists source IP address and destination IP address as immutable fields. This may be true in some idealized Internet where the end-to-end principle applies. It is definitely not true in our Internet, where NATs are everywhere.

>  I'd want to hear from the wireless guys that they think

I'd like to hear that as well. My company removed AH from our (non wireless) product in 2003. We have yet to hear a complaint about this.

> sufficiently so that it probably shouldn't be implemented.

The environment has changed since 1995. NATs are ubiquitous now. 

>  Don't think

I think it is a win to reduce the number of ways to accomplish the same goal. That is why I was opposed to the publication of RFC 6467. It encourages having multiple password methods. That is why the scep draft has an intended status of "historic", even though I would guess that SCEP is more widely implemented and deployed than both the standards-track protocols combined.

Moving AH to historic can point implementers and other working groups in a single direction.

Yoav

---

From: Jack Kohn <[email-masked]>
Date: Fri, 30 Dec 2011 07:18:40 +0530

> Moving AH to historic can point implementers and other working groups in a single direction.

It will also help ending repeated "ESP-NULL versus AH" discussions on
various mailing lists. I have not seen a single use case where
ESP-NULL cannnot be substituted for AH. Even if there are some
scenarios where ESP-NULL will not work, then those folks can continue
using AH and I dont see how marking AH as Historic would really affect
them.

I support this work and i think its time that IETF took a stand on AH
(which i personally find quite useless).

Ever since 4301 moved AH to a MAY, i know a few vendors that have
completely stopped supporting AH. Once again, if there are
environments where ESP-NULL will not work (and i guess it probably has
to do with the additional header that it inserts) then those
environments can continue using AH.

If folks dont want to move AH to historic then perhaps this document
could be modified to say something in the lines of - "AH should not be
preferred when designing new protocols and all attempts must be made
to use ESP-NULL"

Jack

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Dec 2011 20:57:36 -0900

On 12/29/11 4:48 PM, Jack Kohn wrote:
> various mailing lists.

That is, I think, the first truly compelling argument I've come
across.  This has been something of an energy sink.

Melinda

---

From: Venkatesh Sriram <[email-masked]>
Date: Fri, 30 Dec 2011 22:17:02 +0530

AH and ESP can theoretically be applied in combination with each other
to exploit the strengths of both protocols but, in most real-world
scenarios, ESP alone is enough.

When used together, AH authentication and ESP encryption results in a
higher percentage increase in network load for small files when
compared to ESP encryption and authentication. If the percentage of
small files sent over a network is significant and the network has
limited bandwidth (wireless?), then its always better to use ESP
instead of AH to provide authentication.

I am yet to come across a really compelling argument in favor of AH.

A small nit - You should also mention RFC 5879 - "Heuristics for
Detecting ESP-NULL Packets" along side RFC 5840 - WESP when you
discuss deep inspecting ESP-NULL packets.

Sriram
On Fri, Dec 30, 2011 at 12:21 AM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Sat, 31 Dec 2011 03:58:45 +0000

>> preferred when designing new protocols and all attempts must be made
[Dacheng Zhang] 
Really like this suggestion. +1

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 31 Dec 2011 21:25:41 +0200

I agree that people should prefer ESP-null for all new uses.

I spent a few minutes trying to look up the precise definition of 
"Historic Documents" in the IETF standards process. Since the definition 
appears to be extremely vague and may not clearly apply in this case, I 
strongly suggest that we avoid this rathole (and move to the next one), 
by adopting the proposed wording below. Manav's I-D is an Independent 
document and so its content is completely up to its author; OTOH, I'd 
rather not waste the group's energy on not-very-important process 
matters. What does matter is that implementers and standards bodies 
understand the strengths and weaknesses of our protocols.

Wishing us all a Happy New Year 2012!

     Yaron

---

From: <[email-masked]>
Date: Sat, 31 Dec 2011 20:29:06 -0500

> appears to be extremely vague and may not clearly apply in this case,

FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron that
it's not exactly precise:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.  (Purists have suggested that the
   word should be "Historical"; however, at this point the use of
   "Historic" is historical.)

There is a subtle distinction between Obsolete and Historic - an Historic RFC
is always Obsolete, but an Obsolete RFC may not be Historic.  Before going any
further,  let me say that I strongly agree with Yaron on priorities:

> I strongly suggest that we avoid this rathole (and move to the next one),

In order to obsolete AH, the draft header needs to say "Obsoletes: 4302", in
addition to its discussion of making RFC 4302 Historic.  Both of the foregoing
require that the draft not be Informational; I'd go further and suggest that with
suitable editing and review, this could be a Best Current Practice (BCP) RFC,
as the primary goal is to document the following as current design practice:

> > "AH should not be

I believe that a BCP can be used to cause a standards track RFC to become
obsolete.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
> Sent: Saturday, December 31, 2011 2:26 PM
> To: Dacheng Zhang(Dacheng)
> Cc: [email-masked]; Melinda Shore; Yoav Nir; Jack Kohn
> Subject: Re: [IPsec] 答复: Moving Authentication Header (AH) to Historic
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 1 Jan 2012 07:23:11 +0530

Hi David and Yaron,

I think its possible to edit the draft headers and the text so that we basically say that AH should NOT be used for newer proposals unless there is a burning reason to do so. And if someone wants to use AH, then they should have a pretty good reason for doing that. In my draft I clearly say that AH does a good job with whats its supposed to do - integrity verification. However, ESP-NULL does that equally good and there is no good reason to use AH any more. I wrote this draft because I was having a private discussion on PIM security with a few folks and the discussion started veering towards "Hey lets use AH since we want to snoop certain PIM packets and ESP-NULL wouldn’t let us do that". 

So, while people working on security understand that AH should not be used for newer protocols, there are lots of others who don’t.

I just wanted that to be pointed out explicitly. 

I don’t really care whether its through an informational RFC, BCP, standards track or some other type as long as the message is out loud and clear. However, before spending any more cycles on it I would first like to gauge the interest level in the WG to see if people think it’s an idea worth spending time on. And if not, then why.

Cheers, Manav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, January 01, 2012 6:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic

> "Historic Documents" in the IETF standards process. Since the 
> definition appears to be extremely vague and may not clearly apply in 
> this case,

FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron that it's not exactly precise:

There is a subtle distinction between Obsolete and Historic - an Historic RFC is always Obsolete, but an Obsolete RFC may not be Historic.  Before going any further,  let me say that I strongly agree with Yaron on priorities:

> I strongly suggest that we avoid this rathole (and move to the next 
> one), by adopting the proposed wording below. Manav's I-D is an 
> Independent document and so its content is completely up to its 
> author; OTOH, I'd rather not waste the group's energy on 
> not-very-important process matters. What does matter is that 
> implementers and standards bodies understand the strengths and weaknesses of our protocols.

> > preferred when designing new protocols and all attempts must be made 

I believe that a BCP can be used to cause a standards track RFC to become obsolete.

Thanks,
--David

> "Historic Documents" in the IETF standards process. Since the 
> definition appears to be extremely vague and may not clearly apply in 
> this case, I strongly suggest that we avoid this rathole (and move to 
> the next one), by adopting the proposed wording below. Manav's I-D is 
> an Independent document and so its content is completely up to its 
> author; OTOH, I'd rather not waste the group's energy on 
> not-very-important process matters. What does matter is that 
> implementers and standards bodies understand the strengths and weaknesses of our protocols.
> 
> >>> If folks dont want to move AH to historic then perhaps this 
> >>> document could be modified to say something in the lines of - "AH 
> >>> should not be preferred when designing new protocols and all 
> >>> attempts must be made to use ESP-NULL"
> > [Dacheng Zhang]

---

From: Nico Williams <[email-masked]>
Date: Sat, 31 Dec 2011 20:01:37 -0600

>   "Historic" is historical.)

The question, for me, is: do "Historic", "retired", and "obsolete"
refer strictly to the ability of new standards to depend on the old
ones, or does it go further to requiring implementors to also obsolete
(i.e., declare intention to remove) the feature from their products?

Section 6.4 is a bit more specific:

   As the technology changes and matures, it is possible for a new
   Standard specification to be so clearly superior technically that one
   or more existing standards track specifications for the same function
   should be retired.  In this case, or when it is felt for some other
   reason that an existing standards track specification should be
   retired, the IESG shall approve a change of status of the old
   specification(s) to Historic.  [...]

Elsewhere we have a requirement that normative references of
standards-track documents not be to non-stantards-track documents.

That helps me interpret RFC2026 as limiting the effect of "Historic"
to forbidding the dependence of new standards on old ones.

Do we have any reason to imagine that AH will ever be sufficiently
more appropriate than ESP for any protocol that we are not yet ready
to retire AH?  I don't, but maybe I'm not imaginative enough.

For the record, and with the above understanding of the meaning of
"Historic", I'm firmly in support of the proposal that we move AH to
Historic.

Nico
--

---

From: <[email-masked]>
Date: Sat, 31 Dec 2011 22:06:10 -0500

Hi Manav,

I think it's more important to clearly state what we want protocol designers to do/not do and why (ditto for IPsec implementers).  We can figure out the process stuff later.  I definitely think that it's worth spending time on drafting guidance about when (if ever) use of AH in new protocols is appropriate.

Thanks, --David +++ Sent from BlackBerry +++

----- Original Message -----
From: Bhatia, Manav (Manav) [mailto:[email-masked]]
Sent: Saturday, December 31, 2011 08:53 PM
To: Black, David; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: Moving Authentication Header (AH) to Historic

Hi David and Yaron,

Cheers, Manav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, January 01, 2012 6:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic

Thanks,
--David

---

From: Venkatesh Sriram <[email-masked]>
Date: Sun, 1 Jan 2012 09:11:29 +0530

I think this draft pretty much does the same.

It says why AH should not be used. For most cases, this should work.
However, if there are protocols that for some reason need AH then they
should justify its use.

I think the intent is captured here in this paragraph:

   Moving AH to historic doesn't mean that people have to stop using AH
   right now.  It only means that in the opinion of the community there
   are now better alternatives.  Moving AH to historic will discourage
   new protocols to mandate the use of AH.  It however, does not
   preclude the possibility of new work to IETF that will require or
   enhance AH.  It just means that the authors will have to explain why
   that solution is really needed and why ESP-NULL cant be used instead.

I strongly agree with David, Manav and Nico that we must not worry
about the process stuff here. Once we have an understanding of how
this needs to be done, taking care of the process stuff should be
easy.

Sriram