Thanks to Valery for writing this draft, apologies for the delay. I was hoping to beat the I-D submission cutoff, but I didn't make it.
I did spend some time mapping out the differences in how the key development works in all three versions: RFC 7296, RFC8784 and this draft. They are related, but different in all three places. I think I see why it is done the way it is, including a way to rekey the SA without tearing down the whole connection. [I'm happy take comments from those whose crypt background is less rusty than my own.] Specific comments: We might need to work on these a bit. Most are readability comments. Abstract, para 2: Remove the word 'Besides,'. Last sentence, change to, 'This specification defines a way to use PPKs in active IVKv2 SAs for creating additional IPsec SAs and rekey operations. (I'm not sure how much this helps, it is pretty awkward.) Introduction, para 1, sentence 2, 4, last phrase: add/change some text to make it flow better, 'An extension...', 'post-quantum security is defined', 'IPsec traffic that mostly needs protecting, (albeit it wouldn't provide protection of the identity of the peers). Introduction, para 3, QKD sentence: 'for example via the use of Quantum Key Distribution (QKD). Section 3.1.1, para 2, first sentence: I don't understand this sentence, 'computed differently compared to use PPKs'... maybe 'computed differently to how PPKs are used in IKE_AUTH', but I'm not sure. Section 3.2, para 1: 'peers MAY use this PPK' to 'peers MAY use this fresh PPK'. Section 3.2, Figure 2: What is 'Nir'? Maybe a typo for 'Nr'? Or something else. Appendix A, last paragraph: 'PPK stuff', maybe 'PPK messages'? General: There are a handful of pointers back to the g-ikev2 draft. Just be sure that the naming that was changed late in the process has made it into this draft. For example, GSA_AUTH - I don't remember if that was new, old, or unchanged. Deb
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
