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

RJ Atkinson <rja.lists@gmail.com> Wed, 02 April 2014 19:33 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 74DEF1A03A2 for <ipsec@ietfa.amsl.com>; Wed, 2 Apr 2014 12:33:48 -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 2OOFOJ6frmzf for <ipsec@ietfa.amsl.com>; Wed, 2 Apr 2014 12:33:43 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEDF1A03A8 for <ipsec@ietf.org>; Wed, 2 Apr 2014 12:33:43 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so23998qgf.21 for <ipsec@ietf.org>; Wed, 02 Apr 2014 12:33:39 -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=4BINTfgYFHiOR8mamO1/62vwxeujIParIImoiBATLK4=; b=t+dGALrQ5bbx2pm3ANi+FYgbusJXNcgGiXa3GOZsjbYZYxVAXUDhotjTZ0OhOJ19tL dsZ9HAvCbsBhfNrz57KLlpMLN69b2nvNxc55j23eDal3YVWweH8/PVHmRmDEUC2vvD5M 6hFH01Ym8tXcqF8UvCyycOp1mbKC63chZglh1bgdN55PxB8vWKhYQ1Naj61WbTHMTz1U INI7Jcmy11pw6nF2ZzCeEYhfRzRPF9Bn24m6trAdFSdONVeszSZMsSj6Csthvm4v1vFp ZL0bzIBhHg1TGLVioYF/C6mD9CqNkjK5k2K7qKdRzI+bXpGlh9Uaawvxsz22kKLL1+o+ TuJA==
X-Received: by 10.224.5.136 with SMTP id 8mr2890713qav.42.1396467219010; Wed, 02 Apr 2014 12:33:39 -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 r5sm5531549qaj.24.2014.04.02.12.33.38 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 12:33:38 -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: <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org>
Date: Wed, 02 Apr 2014 15:33:39 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com>
References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@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/JaMrYzgxc2Bm_toBrzNP8CSqxPk
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 19:33:48 -0000

On 02  Apr 2014, at 13:25 , Paul Hoffman wrote:
> That was certainly not the intention.

OK.

>> [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers
>> with forwarding silicon that could parse AH and any other IPv4/IPv6
>> options - at wire-speed for 10 Gbps interfaces - 10 years ago.  I am
>> aware of 2 other very widely deployed implementations with the same
>> ability to parse past AH to read TCP/UDP ports and apply ACLs at
>> wire-speed.  So this is a widely deployed capability, rather than
>> theory. :-]
> 
> That's not an important note for this discussion, ...

Ah, but it is important, because it talks about deployed reality,
and many many users and implementers DO care about the ability 
to apply ACLs.

> which is about what the IPsec community
> has expressed as a general preference.

You are mis-characterising the "VPN community" (e.g. VPNC)
as being the whole "IPsec community".  This I-D supposedly
is NOT a VPN-focused draft, but instead claims to address 
the whole audience of IPsec implementers, users, and usages.

> You feel that preference is wrong, and you have stated
> that in earlier WG discussions.

No.  That is not what I believe or feel, NOR is the quote 
a correct summary what I have expressed in past discussions.
Instead, that is a mis-apprehension of what I have said.

In fact, I don't think that the preference for ESP with an integrated
transform is wrong or bad - for VPN uses.  Indeed, there are 
well-understood and broadly agreed reasons why - for VPNs -
ESP with an integrated transform is preferable.  Further, we all 
agree and understand that VPN is the most widely deployed use case.  
However, it is not the only deployed IPsec use case.  

A general IPsec Requirements document ought to be addressing
all deployed use cases, and ought not be limited to VPN uses.

>> We owe it to readers to be crisp, clear, complete, and accurate 
>> with the text in this draft.
> 
> Yes, but:
> 
>> Candidate new text:
>> 
>>    "When no IPv4 options or IPv6 optional headers are present, and 
>>    in environments without concerns about attacks based on option
>>    insertion (e.g. inserting a source routing header to facilitate
>>    pervasive eavesdropping), the IPsec community generally prefers
>>    ESP with NULL encryption over AH.  However, some protocols
>>    require AH.  Also, AH always protects all IPv4 options and IPv6
>>    optional headers, while ESP NULL is unable to protect any IPv4
>>    options or to protect IPv6 options that are seen & processed by
>>    intermediate systems (e.g. routers, security gateways, other
>>    middle-boxes).  Some IP-layer options, for example IPSO [RFC-1108]
>>    and CALIPSO [RFC-5570], today are deployed in some environments 
>>    while using AH to provide both integrity protection & authentication.
>> 
>>    Further, deployed routers from multiple vendors are able to parse
>>    past an AH header in order to read upper-layer protocol
>>    (e.g. TCP) header information (e.g. to apply port-based router
>>    ACLs) at wire-speed.  By contrast, there is no 100% reliable way
>>    to parse past an ESP header, although some ESP header parsing
>>    heuristics have been documented [RFC-5879] that work in some cases.
> 
> That is neither crisp nor clear; it is more complete;

> it is inaccurate about the parameters that the IPsec community cares about.

Precisely HOW is it inaccurate ?

I believe that everything in my text is accurate.
If there is something inaccurate, please do say precisely what.

> The proposed text comes off as an advertisement for AH, but that's exactly
> the opposite direction that the WG has been leaning for this document.

I'm open to having you or others propose some alternative text, provided
that text makes clear that ESP can't protect IP options in transit, 
while AH can.  This difference in the provided security properties is
entirely factual.  For VPN deployments, this might not matter, but
for other existing IPsec deployments it is known to matter.  Again,
this document is not about a VPN profile of IPsec, it is about the
entirety of IPsec.

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

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.

Yours,

Ran