Re: [IPsec] WESP - Roadmap Ahead

[Tero Kivinen <[e-mail]>]

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

> 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.
-- 
[e-mail]