Re: [IPsec] WESP - Roadmap Ahead

Stephen Kent <kent@bbn.com> Mon, 30 November 2009 00:49 UTC

Return-Path: <kent@bbn.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910E63A6A08 for <ipsec@core3.amsl.com>; Sun, 29 Nov 2009 16:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOb+3s5nHTVH for <ipsec@core3.amsl.com>; Sun, 29 Nov 2009 16:49:11 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9FA463A6A07 for <ipsec@ietf.org>; Sun, 29 Nov 2009 16:49:11 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.236.246.158]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NEuRs-0005Kr-Ay; Sun, 29 Nov 2009 19:49:04 -0500
Mime-Version: 1.0
Message-Id: <p06240800c7384e723a12@[192.168.1.6]>
In-Reply-To: <dc8fd0140911251617h6f4aea76jae8b1c3ba4b9d8cf@mail.gmail.com>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com> <p06240805c7272bb53718@128.89.89.228> <f1548840911171103m4d39e544q236448d4b1c8eefe@mail.gmail.com> <p06240804c729109c4f93@10.1.231.26> <dc8fd0140911210939i4113200ckbfadb5e0a5ea9b50@mail.gmail.com> <p06240804c72ef7906c90@192.168.1.3> <dc8fd0140911221517j1ad39eeaje143b80c860b8681@mail.gmail.com> <p0624080cc7309f6414a0@128.89.89.105> <dc8fd0140911241935x26537efi5426ee0bec7ade2a@mail.gmail.com> <p06240808c732ed309450@192.168.1.5> <dc8fd0140911251617h6f4aea76jae8b1c3ba4b9d8cf@mail.gmail.com>
Date: Sun, 29 Nov 2009 19:48:43 -0500
To: Jack Kohn <kohn.jack@gmail.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] WESP - Roadmap Ahead
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 30 Nov 2009 00:49:12 -0000

Jack,

Thanks for describing the additional selection criteria that must be 
employed to avoid the problem I cited.

Given this more complete description of the selection criteria, I am 
not convinced that that is a significant benefit for using WESP in 
this context.

	- Whether using WESP or just ESP-NULL, the router needs to 
determine that the packet is addressed to it.  This means looking for 
either a unicast address (per interface?) or a multicast address. I 
thought that the traffic of interest would arrive on a multicast 
address. If so, then this is a very easy check.

	- Traffic other than OSPF can be addressed to the router, but 
I'm not sure what other traffic would be multicast. For unicast 
traffic addressed to the router, if some of that is protected using 
ESP with confidentiality, then the address check might have to be 
extended to include a source address as well.

	- There is an assumption that the OPSFv3 traffic is 
(ultimately)  protected using ESP-NULL. The next check that you 
described, i.e., looking for a few bits that indicate whether the 
payload is OSPF and appears to be a HELLO or ACK, is the real focus 
of this thread.  There appears to be a couple of cases:

	- If all multicast traffic directed to the router and 
protected using ESP is ESP-NULL, then WESP seems to help ONLY if 
there are algorithms being used for different SAs, AND if those 
algorithms result in different offsets for the start of the ESP-NULL 
payload. It's not clear that this is a realistic case. But, in this 
case, using WESP could avoid the need to check the SPI in the packet. 
What's not clear is whether checking for WESP and extracting the 
offset info is faster than matching against a set of SPIs.

	- if some multicast traffic directed to the router is 
protected with ESP with confidentiality, in addition to the ESP-NULL 
OSPF traffic, then one would need to check SPI values to 
differentiate between these two classes of traffic.

So, the question of whether we have one multicast SA for this 
traffic, or potentially a lot of these SAs is potentially relevant. 
As I mentioned in my previous message, this is not completely clear 
to me from 4552. You didn't respond to that part of my message, so I 
don't know if that means you find the RFC unclear on this point as 
well, or if you didn't think it mattered to this discussion. Well, if 
appears to matter, if one believes that the number is substantial.

So, the bottom line appears to be that WESP might be better than just 
using ESP-NULL, depending on the number of multicast SAs that 
terminate at the router, that make use of ESP, and maybe whether the 
ones that use ESP make use of different integrity algorithms that 
result in different offsets.  That is a lot of IFs for which we have 
yet to get an answer.

In any case, as I noted earlier, because of the use of manual keying 
in this context, selecting a subset of packets for out-of-order 
processing does not impose any burden on the IPsec for the remaining 
packets, so all of the comments about that issue were red herrings.

Steve