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
- [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Scott C Moonen
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Merike Kaeo
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Daniel Migault
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Steven Bellovin
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Richard Graveman
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Venkatesh Sriram
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Steven Bellovin
- [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Dan McDonald
- Re: [IPsec] WESP - Roadmap Ahead Gregory Lebovitz
- Re: [IPsec] WESP - Roadmap Ahead Gregory Lebovitz
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Daniel Migault
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent