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

RJ Atkinson <rja.lists@gmail.com> Wed, 02 April 2014 20:35 UTC

Return-Path: <rja.lists@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 EF9A01A03D6 for <ipsec@ietfa.amsl.com>; Wed, 2 Apr 2014 13:35:01 -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 1rZH42-MirEE for <ipsec@ietfa.amsl.com>; Wed, 2 Apr 2014 13:34:56 -0700 (PDT)
Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB8E1A03D2 for <ipsec@ietf.org>; Wed, 2 Apr 2014 13:34:56 -0700 (PDT)
Received: by mail-qa0-f49.google.com with SMTP id j7so706660qaq.8 for <ipsec@ietf.org>; Wed, 02 Apr 2014 13:34:52 -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 :content-transfer-encoding:message-id:references:to; bh=5crLsyBBOkuYrP3L6B0mvIsgSb04FTUPYSh6uB0lHaE=; b=WTJtn9BBlKp9Gga26IqlE04yHkOgFu7z/Q20+DXML/DtAz1gAv32wiSF6dW7wWM6Kk l/TR5h668zo6gmieMpwElZzjOLOW2dHXUz1t1q+AlRCy7uvCp1ZYQx298htPfXBT1QvS YDztw07xJCcMhaYQTkkzwfFIE8hEhRv1xKplkJxzFt5EFAve1itFqdXLRurL/CMO8mV/ ThxLDq5SVqHDSk45T8kTy6TF4KlpkRfS2TRxjMAcT4CX85Twk4vNcSVcoDD20dYnrfZx XaYgGQha438ZDkkdfOivvA88r+DLhmO/SGme90F/KZaVrSDysyCh8pbcgFX4fG+d9xz3 wYmA==
X-Received: by 10.229.179.65 with SMTP id bp1mr3172609qcb.11.1396470892562; Wed, 02 Apr 2014 13:34:52 -0700 (PDT)
Received: from [10.30.20.15] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id x8sm5814082qam.20.2014.04.02.13.34.52 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 13:34:52 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
From: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <0B1B3C1C-1EC6-4B22-98FA-E05E3506D3E3@vpnc.org>
Date: Wed, 2 Apr 2014 16:34:52 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <D11E3740-F7CA-48A9-8183-E10C824F7D54@gmail.com>
References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> <0B1B3C1C-1EC6-4B22-98FA-E05E3506D3E3@vpnc.org>
To: IPsec ME WG List <ipsec@ietf.org>
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Z4p0lmk8li28saB7g4SGIjIuItg
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: Wed, 02 Apr 2014 20:35:02 -0000

On 02  Apr 2014, at 16:17 , Paul Hoffman wrote:
> Actually, yes. Looking in the archives,
> I see you stating it in a few different threads.

Again, that's not what I said, but instead 
what you have mis-read.

>> A general IPsec Requirements document ought to be addressing
>> all deployed use cases, and ought not be limited to VPN uses.
> 
> If that's what the WG wants, great. In me reading the
> list as a document author, I don't see people agreeing with that.

If this I-D is NOT addressing all IPsec use cases, then why isn't
this I-D titled the "IPsec VPN Requirements" document ?

> Good catch. Proposed improvement:
> 
>   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; ESP inherently cannot those IP options.

I assume you meant to write:  s/cannot those/cannot protect those/

If I understand the intended text, that is an important and very helpful 
improvement, and I very much appreciate it being added.

>> It also should mention IP sensitivity label options, such as RFC-1108 
>> and RFC-5570 as a use case for AH, in addition to source-routing headers.
> 
> Having this document listing all of the IP options from Informational RFCs
> would undermine the value of this document.

  Adding s/source routing headers;/source routing headers or sensitivity
label options;/  plus adding those 2 RFC citations to your "proposed 
improvement" text above could not possibly "undermine the value of this 
document", particularly since both RFCs are examples of currently
deployed use cases.

  Please re-consider applying the brief text edits I've provided just above 
and the corresponding citations to those 2 RFCs.

Yours,

Ran