Re: [IPsec] WESP - Roadmap Ahead

Stephen Kent <kent@bbn.com> Wed, 25 November 2009 14:32 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 999CE3A690C for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:32:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level:
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 fhbpyuePTyEP for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:32:03 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AB6AC3A6AB1 for <ipsec@ietf.org>; Wed, 25 Nov 2009 06:32:03 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NDIuU-0007qu-Ap; Wed, 25 Nov 2009 09:31:58 -0500
Mime-Version: 1.0
Message-Id: <p06240808c732ed309450@[192.168.1.5]>
In-Reply-To: <dc8fd0140911241935x26537efi5426ee0bec7ade2a@mail.gmail.com>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com> <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> <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>
Date: Wed, 25 Nov 2009 09:31:52 -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: Wed, 25 Nov 2009 14:32:04 -0000

At 9:05 AM +0530 11/25/09, Jack Kohn wrote:
>  >
>  >...
>
>Assume we dont have WESP.
>
>The end router having scores of OSPF adjacencies will have following
>rules in its database for *each* adjacency:
>
>Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF
>HELLO, put it in Ospfv3HighPrioQueue.
>Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF
>ACK, put it in Ospfv3HighPrioQueue.
>
>This is assuming that SPI X corresponds to ESP-NULL and one can
>disambiguate OSPF Hellos/ACKs from other OSPF packets by looking at
>the nth bit and the mth bit (Please note that n could also be equal to
>m).

These packets are arriving on a multicast SA, so the preferred way to 
do the lookup, to make certain that the packet is from a relevant 
router is to perform
the lookup as described in section 4.1 (pages 12+13) of RFC 4301. 
That means that these SAs generally are uniquely identified based on 
both the SPI value and the source and/or destination addresses.  So, 
you would need to refine the matching algorithm described above based 
on the rules from 4301.

>Now, if this router has N adjacencies then the # of rules required = 
>2 x N = 2N
>
>Thus the # of filter entries scales up linearly with the # of adjacencies.

I've always found the 4552 discussion of SA use a bit confusing, but 
my recollection is that it called for reusing SAs in a way to avoid 
this problem (see Figure 3, section 7, page 7). But I am not 
completely confident about this, based on the wording in that RFC.

>Now, assume that we were using WESP.
>
>You would need just two rules in your filter database saying the following:
>
>Incoming Pkt is WESP integrity Protected, then look at the nth bit and
>if its a OSPF HELLO, put it in Ospfv3HighPrioQueue.
>Incoming Pkt is WESP integrity Protected, then look at the mth bit and
>if its a OSPF ACK, put it in Ospfv3HighPrioQueue.

This is much simpler, but also potentially inaccurate. Specifically, 
because it pays no attention to the SAD info, it would grab ANY 
packet that passes through the router, uses WESP, and that matches 
the bits that one uses to decide of a packet is an OSPF HELLO or ACK.

>Thus one now needs only 2 rules in the HW to prioritize packets for
>*all* OSPF adjacencies.

Unless you used some other rules to narrow down the set of packets 
subject to these quick checks, other packets may be grabbed.

Steve