> > - 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. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
