I glanced the proposal, and I have doubts as to how well it works, and in particular, how well it would work in parallelized decryption. As I understand it, the antireplay window the decryptor checks against is specified in the 'Sender ID/Window ID' field. If the decryptor can handle only one packet for a specific antireplay window, then the level of parallelism that the decryptor can use is entirely up to the encryptor, which might not take the decryptor's needs into consideration. For example, if the encryptor decides to send every packet with the same Sender ID/Window ID, then the decryptor would be forced to use a single thread, which eliminates most of the advantage this proposal claimed to offer.
So, does this proposal include any way for the decryptor to suggest (either at SA negotiation time or dynamically) the behavior the encryptor is supposed to follow? And, if the decryptor can handle a single antireplay window with multiple threads, then most of the parallelizability benefits aren't there (and parallelizing in the encrypt direction is fairly straight-forward; the only non-parallelizable step is assigning the sequence number to each packet, and that's comparatively straight-forward). In addition, during the WG meeting, I groused in the chat about requiring the receiver to track a large (and not tightly bounded) number of independent sequence windows; I believe that is an issue as well. On the IPsec dataplanes I've worked on, we tried to keep the data structures simple (and we could not dynamically allocate memory if we saw a sender id/window id that we hadn't seen before). Now, it has since occurred to me that the data plane could have a number of antireplay windows, and if it saw a sender id/window id that it hadn't seen before, then (after validating the packet), it could send a message to the control plane (which would allocate/refresh the antireplay window, and possible retire a not-recently-used one). However, that strikes me as adding significant complexity. I believe that this was asked on the mailing list already, but I will repeat it: what advantage does this approach have over the 'having independent SAs with separate SPIs' approach? As for the idea of moving the integrity check value before the encapsulated packet, well, that idea might help on your platform; however it strikes me that the advantage would likely be fairly platform dependent. However, if you are getting rid of the trailer, how would this idea extend to transport mode? Where would you place the NH field (this is a question, not a criticism; moving the NH field up front is likely to be a benefit).
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
