Comments:
* I have issues with the draft's emphasis on fixed SPI values. One reason for the SPI value is to handle key updates cleanly; during the transition, the SPI can be used to indicate whether the packet was encrypted with the previous set of key or the new ones. As we really don't want to discourage rekeying I would suggest that, instead of talking so much about fixed SPIs, you instead address how to do nonrandom SPIs (for example, by having the top 3 bytes of the inbound SPI being the SAD entry, and the lower byte being the rekey index). * "Values 0-255 SHOULD NOT be used."; shouldn't that be MUST NOT? Can you think of an advantage a device might have for using a SPI in that region? The use of fix SPI MUST NOT be considered as a way to avoid strong random generators. Such generator will be required in order to provide strong cryptographic protection"; actually, if the IPsec implementation doesn't actually generate its own keys (that is, it relies on an external service to provide them), and the transform itself doesn't require random data (CBC can be implemented securely without one), then the IPsec implementation doesn't actually need an CSPRNG. * SN based on clocks; one issue that is not addressed is that standard receivers are tuned for an increment of one-per-packet; if the sender uses increments significantly larger than that, and packets are reordered, the receiver is more likely to reject valid packets because they fell outside the window. * One issue you do not address (but I believe you should) is the fact that some cryptographical transforms are more resilient for key reuse (e.g. because you use a fixed key, and don't change it after a reboot) than others. In particular, both GCM and ChaCha20-Poly1305 have real problems when that happens, and should be avoided. Typos: * a random SPI may consume to much -> too much * fix SPI -> fixed SPI * can be alleviate -> can be alleviated * algorythm -> algorithm *
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
