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