Re: [IPsec] Avoiding Authentication Header (AH)

"Dan Harkins" <dharkins@lounge.org> Mon, 02 January 2012 21:53 UTC

Return-Path: <dharkins@lounge.org>
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 B85411F0C4F for <ipsec@ietfa.amsl.com>; Mon, 2 Jan 2012 13:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.389
X-Spam-Level:
X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, 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 QTLJeGk0oACO for <ipsec@ietfa.amsl.com>; Mon, 2 Jan 2012 13:53:36 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 32D6E1F0C35 for <ipsec@ietf.org>; Mon, 2 Jan 2012 13:53:36 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C46B6A88810C; Mon, 2 Jan 2012 13:53:35 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 2 Jan 2012 13:53:35 -0800 (PST)
Message-ID: <df23d350136320c159f180b988c0c4d1.squirrel@www.trepanning.net>
In-Reply-To: <CAObD46vF0Wc0oCEhrxGTd0wpzvmuhr4ma_qt=uTWDEb2BT18dA@mail.gmail.com>
References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <CAObD46vF0Wc0oCEhrxGTd0wpzvmuhr4ma_qt=uTWDEb2BT18dA@mail.gmail.com>
Date: Mon, 02 Jan 2012 13:53:35 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Venkatesh Sriram <vnktshsriram@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IPsec ME WG List <ipsec@ietf.org>, RJ Atkinson <rja.lists@gmail.com>
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 21:53:37 -0000

  Hello,

On Mon, January 2, 2012 7:43 am, Venkatesh Sriram wrote:
> 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

  If much of the above is not duplicative then you have bigger problems
that AH.

> 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.

  Ran has provided a good list of things that AH can do that ESP-NULL
cannot.

> 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?

  If it's a MAY then don't spend any cycles on it. Implementations that
support it MUST be prepared to interoperate with implementations that
do not.

> 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.

  If you want to direct WGs to be circumspect when specifying AH then
why don't you go sit in those WGs and instruct them in what they should
be doing? Or at the very least comment during LC. Honestly, if a WG is
not paying attention to RFC 4301 then what makes you think they're gonna
pay attention to a random individual submission?

  I don't have any particular love for AH but this effort is really
lacking in one thing: a problem to solve. On the one hand, we're being
told that the effort is necessary because WGs developing a "standard for
protocol fool" need to be instructed on how to obtain integrity protection
but we're also being told that discouraging AH is OK because no one (in
NANOG) is using it and it's a MAY anyway. These seem to be somewhat
contradictory to me-- either no one's using it and we have a solution
in search of a problem; or, someone's using it and it would probably be
a problem to restrict its use in the future.

  I detect the strong arm of a weak product management department at
work here. If the engineers are complaining about implementing a protocol
that isn't being used then grow a backbone and tell your customers that
they're not gonna get support for a protocol they don't use.

  regards,

  Dan.