Re: [IPsec] Avoiding Authentication Header (AH)

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 04 January 2012 06:08 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8CB21F85C2 for <ipsec@ietfa.amsl.com>; Tue, 3 Jan 2012 22:08:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level:
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnrMWRIJIzsH for <ipsec@ietfa.amsl.com>; Tue, 3 Jan 2012 22:08:13 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2558021F85C1 for <ipsec@ietf.org>; Tue, 3 Jan 2012 22:08:12 -0800 (PST)
Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q04685L0013857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 00:08:10 -0600 (CST)
Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q04684sP028998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jan 2012 11:38:05 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 4 Jan 2012 11:38:04 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Nico Williams <nico@cryptonector.com>
Date: Wed, 04 Jan 2012 11:35:52 +0530
Thread-Topic: [IPsec] Avoiding Authentication Header (AH)
Thread-Index: AczKpJrI51v2UZYuTIuT8OUzW12u1gAABK9Q
Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com>
In-Reply-To: <CAK3OfOg0Gsxxf8T66XNVLHtR1Tk9yHFDGw96tr0UkEh6x5uYpQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Avoiding Authentication Header (AH)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2012 06:08:13 -0000

Hi Nico,
 
> Advising (and updating said advice as circumstances change) 
> use-IPsec protocol designers as to when to use ESP and/or AH 
> is something we should do.  Deprecating AH seems like a nice 
> idea, but if there's good reasons to still use it, then maybe not.

We're not talking about deprecating or killing AH. I concede that I did allude to it in my first draft, but then changed the tone based on the WG feedback, to say that we should "avoid" AH wherever possible.

What we're trying to say is this:

1. If folks have a reason to use AH then they're most welcome to use it. 

2. If there are topologies where it makes only sense to use AH then do that. Ran pointed out to some very specific cases where it apparently makes sense to use AH and I have no problems with people using AH there. In the view of most people there isn't a need for AH in the service provider network and I am fine with a few people disagreeing with me. 

3. If there are newer protocols that cant use ESP-NULL for some reason and need to extend AH, then they should do that. All we're saying is that those folks should not arbitrarily extend AH. They should have a good reason for doing so.

In short, if ESP-NULL can do the job, then DON'T mandate AH - no point having multiple protocols doing the same stuff. If it cant, then either (i) fix ESP or (ii) go ahead and use AH. Pick up whichever is more elegant and preferred by the community.

I think that's all that we're trying to say here.

Cheers, Manav