Re: [IPsec] Avoiding Authentication Header (AH)

Venkatesh Sriram <vnktshsriram@gmail.com> Mon, 02 January 2012 15:43 UTC

Return-Path: <vnktshsriram@gmail.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 C426921F891D for <ipsec@ietfa.amsl.com>; Mon, 2 Jan 2012 07:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 pzuJMt2TL3As for <ipsec@ietfa.amsl.com>; Mon, 2 Jan 2012 07:43:43 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9BF21F87C9 for <ipsec@ietf.org>; Mon, 2 Jan 2012 07:43:43 -0800 (PST)
Received: by yhjj72 with SMTP id j72so10367282yhj.31 for <ipsec@ietf.org>; Mon, 02 Jan 2012 07:43:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=enKXgsPUXYKpnLI4F0lnKclXHdlBohIYyFfkC3w0oqk=; b=oRJK7dBqGgC/3X6vC+PP82MQAQHbu3Ma5uQxVm5W9oOPR8YKbVYGnNOj5ucxeONuPJ Ts5JVH/i1wLbrM8aO+2F8vBZYHjywwhxnAW/dq69emyQOUJZTFEDzEzYKvMB74SdXPRp w8Jiedpy8yvegChj6c5RQmBcoiRchfL/q9dAg=
MIME-Version: 1.0
Received: by 10.236.175.72 with SMTP id y48mr63988268yhl.17.1325519017003; Mon, 02 Jan 2012 07:43:37 -0800 (PST)
Received: by 10.236.183.228 with HTTP; Mon, 2 Jan 2012 07:43:36 -0800 (PST)
In-Reply-To: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com>
References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com>
Date: Mon, 02 Jan 2012 21:13:36 +0530
Message-ID: <CAObD46vF0Wc0oCEhrxGTd0wpzvmuhr4ma_qt=uTWDEb2BT18dA@mail.gmail.com>
From: Venkatesh Sriram <vnktshsriram@gmail.com>
To: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IPsec ME WG List <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: Mon, 02 Jan 2012 15:43:43 -0000

If ESP and AH continue to co-exist then I see the following happening:
(i) standard for feature foo1 using ESP-NULL + SW effort + QA effort +
interop effort(ii) standard for feature foo1 using AH + SW effort + QA
effort + interop effort(iii) standard for feature foo2 using ESP-NULL
+ SW effort + QA effort + interop effort(iv) standard for feature foo2
using AH + SW effort + QA effort + interop effort..(iii) standard for
feature foo'n' using ESP-NULL + SW effort + QA effort + interop
effort(iv) standard for feature foo'n' using AH + SW effort + QA
effort + interop effort
Now, i am willing to live with this if the security offered by AH and
ESP-NULL is significantly different. I dont see why we should have
this complication if ESP-NULL can do everything that AH has to offer.
Why should the operators learn managing ESP and AH when both do the
same?
RFC 4301, by declaring ESP as a MUST and AH as a MAY has already set
the context. I dont see why vendors and everybody else in the food
chain should spend cycles on AH, if its not bringing anything
substantial on the table?
I dont think the draft in question says that AH is bad and should be
deprecated. It merely says that WGs should be circumspect when
mandating AH since its likely that most people are using ESP-NULL and
you dont want to unnecessarily add complexity in people's lives for no
good reason.
Sriram