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

Paul Wouters <paul@cypherpunks.ca> Mon, 03 March 2014 22:54 UTC

Return-Path: <paul@cypherpunks.ca>
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 F1AE01A02B8 for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 14:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IUuyCeuQZsEC for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 14:54:01 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 317AA1A01E8 for <ipsec@ietf.org>; Mon, 3 Mar 2014 14:54:01 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DBC86800AF; Mon, 3 Mar 2014 17:53:57 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s23MrvV9007085; Mon, 3 Mar 2014 17:53:57 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 3 Mar 2014 17:53:57 -0500 (EST)
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com>
Message-ID: <alpine.LFD.2.10.1403031743030.4233@bofh.nohats.ca>
References: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-SWyxIfqtWK_NrE5RdTmPqjyzYY
Cc: IPsec ME WG List <ipsec@ietf.org>
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 22:54:03 -0000

On Mon, 3 Mar 2014, RJ Atkinson wrote:

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

What meaning has "protecting" those bits? Endpoint A and B protect
something by cryptography, but any router in the middle can't trust
those signatures anyway. So I don't see how AH is different from
ESPinUDP where you set those options in the UDP header. These are
not "protected" but the router can't verify the crypto anyway.


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

So I don't buy that. The IP header is not protecting the packet from
a router, which cannot confirm the crypto of that protection. What this
is really about is exposing things like QoS bits, but those devices
acting on those are not verifying any "protection". They are blindly
using the exposed options.  So ESPinUDP works equally well here.

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

I'm not sure what you are referring to here. Not labeled IPsec I
take it? And again, how does this "protection" work? How do the
routers verify this "protection" when only the endpoints know
the crypto keys used to protect the header and payload?

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

Can you explain how this protection works? If an AH packet flies by,
and I change the QoS option from off to on to give my packet preference
in the network, how will the next router notice this and ignore
this QoS option?

> Some deployments definitely do care.  Other deployments do not.

By understanding was always that people didn't like options getting
"lost" or "hidde" within the ESP payload, and not getting set on
the outer packet. In fact, with KLIPS we had an option that could
copy some of the header bits into the outer IP header.

Paul