Re: [IPsec] WESP - Roadmap Ahead

Tero Kivinen <> Wed, 25 November 2009 13:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 882CC3A69C3 for <>; Wed, 25 Nov 2009 05:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GLxxhRJtji7I for <>; Wed, 25 Nov 2009 05:44:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6D6D73A67A8 for <>; Wed, 25 Nov 2009 05:44:56 -0800 (PST)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id nAPDictw016250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:44:38 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.3/8.12.11) id nAPDib0d014155; Wed, 25 Nov 2009 15:44:37 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Wed, 25 Nov 2009 15:44:37 +0200
From: Tero Kivinen <>
To: Jack Kohn <>
In-Reply-To: <>
References: <> <> <> <p06240805c7272bb53718@> <> <p06240804c729109c4f93@> <> <p06240804c72ef7906c90@> <> <p0624080cc7309f6414a0@> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 11 min
Cc: "" <>, Stephen Kent <>
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 13:44:57 -0000

Jack Kohn writes:
> Assume we dont have WESP.

I would like to, but unfortunately I lost :-)

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

As all of those IPsec connections is created by node, it actually
knows which algorithms are allowed, so it can very quickly do simple
run partial heuristics on the packet to know it is ESP-NULL.

Or actually it can also make so that if SPI number bit x is set then
the IPsec SA is using ESP-NULL for ospf, otherwise it is normal
encrypted traffic or something else. As SPI allocation is local
matter for this node, it can do this kind of things.

Middle boxes (where wesp and heuristics are really intended for)
cannot do this kind of things, but end-boxes can.

So for end boxes there is even more efficient methods than using WESP
to do the same thing. Splitting SPI range to indicate algorithms is
more efficient than WESP, as then you do waste extra bytes for extra

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

If you start using IPsec protected OSPF then you most likely will
require hardware support for IPsec also, and SPI lookup to find out
the algorithms etc is very fast first step done in there. After that
you know the parameters for the SA and you can then do this kind of
prioritizing before forwarding packet to the actual crypto engines. On
the other hand it might be better to just put few extra dollars for
the hardware and get fast enough crypto chips so you can do this
prioritizing using AUTHENTICATED data from the packet, i.e. after
IPsec processing as that will protect against attackers flooding the
Ospfv3HighPrioQueue by sending packets matching your bits.