Re: [IPsec] WESP - Roadmap Ahead

[Jack Kohn <[e-mail]>]

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