Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

RJ Atkinson <rja.lists@gmail.com> Mon, 03 March 2014 15:04 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 4AF931A0145 for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 07:04:48 -0800 (PST)
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 PHkN0DddtLWA for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 07:04:47 -0800 (PST)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD8671A0133 for <ipsec@ietf.org>; Mon, 3 Mar 2014 07:04:46 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id x48so3264333wes.21 for <ipsec@ietf.org>; Mon, 03 Mar 2014 07:04:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=EZjtrcBnQ1467YWqIueUSkHXQjRJhLc6pNbQd/pU3x0=; b=zf45zLluEj32TlrXY070Z9r/LBHmSuZiCT/0SUgZr62GPY8yNimqfvo6lJ7jfKZk3c VQnIMPwgtmHyS6pjU+B0zV89pKZm+OUn2Cr6V2MRzuzxj2lASfaqOjY6eaQiJ7Ls6Cc7 uPKfPf8+XYkVgyQmeO/BtfdzOwvQ1dIRtPHBWiNJrw9oo3DOEiZM0o2z9wpGLiCjGxAL xOk8u90PHK+YE3Sye2ly31aVlCPTbZHZURCAPzSRHxYNMlM4u2sYfU9ZP7uKDjAHFGSS V5cr67I4T088uc7G/DvKqaaOpIXl0xaW1WyR7fxD+xVZquKoZXsbP4p/anE8degNhzYJ oj0A==
X-Received: by 10.194.84.144 with SMTP id z16mr18730387wjy.23.1393859083364; Mon, 03 Mar 2014 07:04:43 -0800 (PST)
Received: from dhcp-b378.meeting.ietf.org (dhcp-b378.meeting.ietf.org. [31.133.179.120]) by mx.google.com with ESMTPSA id f7sm36526312wjb.7.2014.03.03.07.04.41 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 07:04:42 -0800 (PST)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 03 Mar 2014 10:04:40 -0500
Message-Id: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com>
To: IPsec ME WG List <ipsec@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/akfMloaTqRFnjPr3WenJn_WXVyc
Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
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: Mon, 03 Mar 2014 15:04:48 -0000

> Perhaps some text along the line of:
> 
> 	ESP-NULL offers the same protection as AH, ...

  This sentence above is not true.  ESP-NULL and AH provide 
different security properties to the IP-layer.

  AH protects all IP options, whereas ESP cannot protect any 
IP options that appear prior to the ESP header -- the location
in the packet where those IP options are seen *and acted upon* 
by routers/firewalls/etc.

  Similarly, AH protects many IP header fields from in-transit
modification, whereas ESP encapsulation provides no protection
for the 1st (outer) IP header (i.e., that appears before the ESP header).

  As a prior discussion has noted, AH can and is used to provide
cryptographic protection to some security-critical IP options
(e.g. sensitivity labels).  ESP-NULL is not capable of protecting
those options.  

  The reason AH is MAY is that not all deployments care about
protecting the (outer) IP header and (visible to the forwarding
plane) IP options.  Some deployments definitely do care.  Other
deployments do not.

Yours,

Ran