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