Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

Yoav Nir <ynir.ietf@gmail.com> Thu, 03 April 2014 06:41 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D6A1A00DA for <ipsec@ietfa.amsl.com>; Wed, 2 Apr 2014 23:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9N6IpxMo1xG for <ipsec@ietfa.amsl.com>; Wed, 2 Apr 2014 23:41:20 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DB7FB1A00E2 for <ipsec@ietf.org>; Wed, 2 Apr 2014 23:41:19 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w61so1320552wes.15 for <ipsec@ietf.org>; Wed, 02 Apr 2014 23:41:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6fWfu1Hlhpc4tnLGMGB+7zDdWZf68od+Ow2azeHJCkI=; b=OSK57wLso12w0LiP9NZigIPCZstmT7MJKHg+mqk5cScmivxyxd4Km/W1f8NU1bl/Np 6OZyQB9MHNHM03GS4YBER7PkLGeLMAc+LKgyEIBnwpXPxGJ/d4RDkiIGhgukc/GcO5RB Z8+fkLRcWv4hXvTKd9KUU0h6BCBj3swuBl5dT1II7OqS66i/yH6XXDGqgC7oHyH4KcTi HhMoiEiLW8lu74Gu82X+2iYyS34EZokqKOkfj/L3iYt5vf6and/cVvMShq50kBkXOz+r pPQnK8M8HnHPOSGJ+0SxDZ+bC2OOCOGrTnYB4VMTAt0I5udYxubqLMjuu8XVx4J9BzHU KYdQ==
X-Received: by 10.180.94.196 with SMTP id de4mr8228068wib.16.1396507275197; Wed, 02 Apr 2014 23:41:15 -0700 (PDT)
Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id 4sm9753199eeq.33.2014.04.02.23.41.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 23:41:14 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <alpine.LFD.2.10.1404021746580.26966@bofh.nohats.ca>
Date: Thu, 3 Apr 2014 09:41:05 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <41BF0C41-A0D9-4B8A-84EC-FB234E6015D8@gmail.com>
References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> <alpine.LFD.2.10.1404021746580.26966@bofh.nohats.ca>
To: Paul Wouters <paul@cypherpunks.ca>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/TcEgGmktqrVy78QVGTcGE_Yrrls
Cc: IPsec ME WG List <ipsec@ietf.org>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 03 Apr 2014 06:41:25 -0000

On Apr 3, 2014, at 1:13 AM, Paul Wouters <paul@cypherpunks.ca> wrote:

> On Wed, 2 Apr 2014, RJ Atkinson wrote:
> 
>>> The IPsec community generally prefers ESP with NULL encryption over AH.
>>> AH is still required in some protocols and operational environments
>>> when there are security-sensitive options in the IP header, such as
>>> source routing headers.
>> 
>> This does not make clear that ESP can't protect the IP options,
>> which is an important-to-document limitation of ESP.
> 
> In my 15 years of IPsec work, I've hardly seen requests for AH. When our
> KLIPS stack per default disabled AH support in the kernel module, no one
> complained.

FWIW nobody complained when we removed AH from our firewall in 2003, but our product uses IPsec only for VPN.

I’m also with Paul on this.

Yoav