Re: [IPsec] WESP - Roadmap Ahead

Jack Kohn <> Wed, 25 November 2009 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B915C28C1CA for <>; Tue, 24 Nov 2009 19:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P4isfndgmP1H for <>; Tue, 24 Nov 2009 19:35:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CE7F028C1C1 for <>; Tue, 24 Nov 2009 19:35:54 -0800 (PST)
Received: by gxk28 with SMTP id 28so6587695gxk.9 for <>; Tue, 24 Nov 2009 19:35:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id n37mr9501503agn.74.1259120146473; Tue, 24 Nov 2009 19:35:46 -0800 (PST)
In-Reply-To: <p0624080cc7309f6414a0@>
References: <> <> <> <p06240805c7272bb53718@> <> <p06240804c729109c4f93@> <> <p06240804c72ef7906c90@> <> <p0624080cc7309f6414a0@>
Date: Wed, 25 Nov 2009 09:05:46 +0530
Message-ID: <>
From: Jack Kohn <>
To: Stephen Kent <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [IPsec] WESP - Roadmap Ahead
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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.