Re: [IPsec] WESP - Roadmap Ahead

Jack Kohn <kohn.jack@gmail.com> Wed, 25 November 2009 03:35 UTC

Return-Path: <kohn.jack@gmail.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 B915C28C1CA for <ipsec@core3.amsl.com>; Tue, 24 Nov 2009 19:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 P4isfndgmP1H for <ipsec@core3.amsl.com>; Tue, 24 Nov 2009 19:35:55 -0800 (PST)
Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id CE7F028C1C1 for <ipsec@ietf.org>; Tue, 24 Nov 2009 19:35:54 -0800 (PST)
Received: by gxk28 with SMTP id 28so6587695gxk.9 for <ipsec@ietf.org>; Tue, 24 Nov 2009 19:35:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rvHztCl6pxLKGWyROnw33kkXArd6O+hQomZ9cJs0dBg=; b=qGGWPSASkFzlmHmeYjmemZqtn9gA7wZV2ChFteY4ANsHKPQyGwUx2D4dUmXPA4/bnZ pqvLARdQJrzjhu+l1ENssE8YpX99/aAJ4H1YMcI/eSzNmaBYYOz8qBogiRB7gNBU7OE5 VrAao91HjUKYv8obOvxHcqc+aZ9bTUfof16R0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cDBFB6H8H62JvwVyeS4RovofpxZBgAOHyScC3GrsMVDV1hLAzF0OKgtT6q51ZTJlMe vffdtjPWYmf7q5xIZvi4yEufrw9p/2sPu07eBXGnDDUE4Q38hGm3Du/qukXCgqf8Qgul yid9qlLRcrx+ckuUkWESffSgvUmJQjREraQcw=
MIME-Version: 1.0
Received: by 10.90.40.37 with SMTP id n37mr9501503agn.74.1259120146473; Tue, 24 Nov 2009 19:35:46 -0800 (PST)
In-Reply-To: <p0624080cc7309f6414a0@128.89.89.105>
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>
Date: Wed, 25 Nov 2009 09:05:46 +0530
Message-ID: <dc8fd0140911241935x26537efi5426ee0bec7ade2a@mail.gmail.com>
From: Jack Kohn <kohn.jack@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1
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 03:35:55 -0000

>
>        - the principle example offered is OSPFv3 use of IPsec
>        - OSPFv3 relies on both unicast and multicast SAs
>        - in either case, a router receiving IPsec-protected OSPFv3 traffic
>          will have an SAD entry for the traffic, which means that the
>          router will know that the traffic will be protected via AH
>          or ESP. if ESP is employed, a router receiving traffic will know
>          ESP-NULL is used.
>        - RFC 4552 mandates support for using different SAs for DSCP-marked
>          traffic
>        - RFC 4552 calls for manual keying for both unicast and multicast
> SAs,
>          and states that a receiver is not checking sequence numbers.
>
> In a given OSPF context (e.g., an AS), all the routers are operated by the
> same administrative entity (based on the definition of an AS). If the AS in
> which OSPF is being employed chooses to use ESP-NULL, all the routers can be
> configured to require this, as part of local SPD management.
>
> Why do we need to use WESP in this context? The current argument you
> provided was that this was an issue for a router receiving OSPF traffic, not
> a middlebox issue. But the router knows that the traffic will be ESP-NULL,
> and knows the algorithm employed, so it should be able to examine this
> traffic easily. If the router wants to process traffic out-of-order, after
> examination, that too is easy, since there is no receiver sequence number
> checking, so processing the rest of the traffic (potentially with gaps) will
> not be a problem from an IPsec perspective.

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

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.

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.

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

This becomes a huge advantage when we start scaling up the OSPF adjacencies.

Jack.