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

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Jan 2012 07:55:22 -0800

On Dec 31, 2011, at 5:29 PM, <[email-masked]> <[email-masked]> wrote:

> FWIW, the definition of "Historic" is in RFC 2026,

That is *a* definition of "Historic", but it has been modified informally since RFC 2026 has been written. The IESG is quite aware of this problem and has steadfastly refused to update 2026 to bring it up to the current understanding of "Historic". Doing so would open many large cans of worms.

Proposal: ignore the "historic" label altogether and simply go to "should not be used in new applications and protocols". That way, you can word it as strongly as you want. Such a document can be a BCP, which has the same effect as a standard.

--Paul Hoffman

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 1 Jan 2012 21:47:06 +0530

Hi Paul,

To get around this process problem do you suggest that I publish a new draft - "Avoiding Authentication Header (AH)" that's mostly a copy-paste of my current draft?

Cheers, Manav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Sunday, January 01, 2012 9:25 PM
To: <[email-masked]>
Cc: IPsecme WG
Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic

--Paul Hoffman

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Jan 2012 08:33:21 -0800

> To get around this process problem do you suggest that I publish a new draft - "Avoiding Authentication Header (AH)" that's mostly a copy-paste of my current draft?

Yep, that would work. It would also cut off the chin-scratching about "what does Historic really mean" and let us focus on what you actually want, which is people not using AH.

--Paul Hoffman

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 2 Jan 2012 05:21:04 +0530

Hi,

I have posted a new draft "Avoiding Authentication Header (AH)"

http://www.ietf.org/id/draft-bhatia-ipsecme-avoiding-ah-00.txt 

Hopefully this will help us focus on the technical, rather than the process related contents in the draft.

The message remains the same, which is that we should NOT use AH for any newer applications and protocols since ESP with NULL encryption algorithm is a better alternative.

Looking forward to hearing from the WG.

Cheers, Manav

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Sunday, January 01, 2012 10:03 PM
To: Bhatia, Manav (Manav)
Cc: <[email-masked]>; IPsecme WG
Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Jan 2012 19:11:14 -0500

>>>>> "Manav" == Manav Bhatia <Bhatia> writes:
    Manav> Hopefully this will help us focus on the technical, rather
    Manav> than the process related contents in the draft.

    Manav> The message remains the same, which is that we should NOT use
    Manav> AH for any newer applications and protocols since ESP with
    Manav> NULL encryption algorithm is a better alternative.

    Manav> Looking forward to hearing from the WG.

okay, I've read the draft, but your blanket statement that it is never
justified it wrong.   
Your draft might ring truer if you limited your analysis to IPv4 only.

I've maintained for a long time that we will need AH functionality in
the future, but we haven't gotten there yet.  SEND almost used it, and
the reason why we didn't, was because we had wrongly specified what to
do when we see an AH SPI# a host did not understand.  This was sad.

I do not agree that WESP provides the service desired. 
WESP requires cooperation (and therefore upgrade) of the end points.

What AH does that ESP NULL does not, is that it guarantees that the
things after the AH header are in fact in the clear.  One can in fact,
ignore the AH header completely (even on the receiving node!), and still
process the entire packet.  Not so with ESP!  

AH is just another extension header in IPv6. 

This property is simply undesireable for many security systems,
including all VPNs.   

Having said all of this,  I agree that for 99% of "Use IPsec"
statements, ESP-NULL is likely the correct choice.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 2 Jan 2012 07:14:58 +0530

Hi Michael,

> What AH does that ESP NULL does not, is that it guarantees that the things after the AH header are in fact in the clear.  One can in fact, ignore the AH > header completely (even on the receiving node!), and still process the entire packet.  Not so with ESP!  

You have this information with WESP as well. You definitely know that the packet is sent in clear with WESP. Just as you can use ESP with manual keying, you can use WESP too.

Obviously the end nodes need to implement WESP, but then they also need to implement AH if that's what they want to use.

Cheers, Manav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Jan 2012 09:31:02 +0200

> statements, ESP-NULL is likely the correct choice.

I don't think you actually meant to say that, right?

Most of the "Use IPsec" statements are followed by "and you'd better have 128 bits of security in the encryption".

Having said that, there was a thread some months ago about making a modified AH that does not MAC the stuff in previous headers - only its own fields and what follows. That would solve the "AH does not work through NAT" problem, but would make it even more indistinguishable from ESP-NULL. Except what you said about it being just another header.

Yoav