Hi Valery, While updating the code logic to the latest version of the draft some questions came up to me:
1. Assume the initiator and responder both already support RFC 8784. If the initiator sends USE_PPK_ALT notify, and does not support IKE_INTERMEDIATE exchange, will the initiator and responder be able to use the alternative PPK rotation for rekeying the SA's and creating new PPK-protected SA's? That is, can this alternative approach be used independent of the IKE_INTERMEDIATE exchange support? A sentence in the draft "The initiator that supports both RFC8784 and this specification MAY include both the *USE_PPK_ALT (along with the INTERMEDIATE_EXCHANGE_SUPPORTED)* and the USE_PPK notifications if it is configured to use either specification." makes me think the alternative approach, thus also the PPK rotation and rekeying, must be used only if the INTERMEDIATE exchange occurs. 2. Similarly, assume neither the initiator nor the responder support RFC 8784 and INTERMEDIATE exchange. Can they implement the alternative approach and use it for, e.g. rekeying (and adding PPK protection to the original unprotected IKE SA) and creating new PPK-protected SA's? The two situations may look unrealistic, but clarity on the issues would be better for cleaner code logic. I suggest a sentence or two are added somewhere (with MUST, SHOULD, etc. wording) that would clarify how implementations should behave in the above two situations. In the case I missed something in the draft about this, I apologize. Thank you in advance! Regards, Vukašin
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
