Hi, > Hi all, > > Following the last IETF meeting, we would like to take the following > direction for our draft: > > 1. Negotiation: use KE payload as described in > draft-tjhai-ipsecme-hybrid-qske-ikev2-01. The main reason is backward > compatibility. Not all IKEv2 implementations out there are > RFC7296-compliant, while it is theoretically possible to upgrade them, > but we cannot guarantee that all of them would be upgraded. With the > approach described in draft-tjhai-ipsecme-hybrid-qske-ikev2-01, there > won't be any issues with backward compatibility.
Well, this was discussed on the list and it is my impression, that those who expressed their opinion (Tero [1], PaulW [2], myself [3]) prefer to re-use existing mechanism. I cannot recall that anybody on the list or in London argued for using KE payload for negotiation. Have I missed something? I understand your concern about existence of non-compliant implementations, but in my opinion adding QSKE into IKEv2 is not an immediate task, so there must be plenty of time for vendors to fix their implementations. I don't want to introduce new negotiation mechanism when we already have one that was specially designed for this purpose. > 2. There appeared to be a consensus in using an intermediary stage, > i.e. IKE_AUX, to transport the post-quantum key exchange payload. Agree. > 3. There was also a suggestion in using a new payload type, e.g. PQKE > or QSKE, to carry the post-quantum key exchange payload. I believe there will be no need for new payload if existing negotiation mechanism is re-used. What is the reason for introduction of new payload? > What do people of think of this approach? > > Thanks, > CJ Regards, Valery. [1] https://mailarchive.ietf.org/arch/msg/ipsec/lW4cFBLagNMdAx2VOSrz1z8VJF0 [2] https://mailarchive.ietf.org/arch/msg/ipsec/XqhkCN4u5vpRugE_Bg_TkP-hDGs [3] https://mailarchive.ietf.org/arch/msg/ipsec/jahWqh_dvPkqAXnA4-C9LndtWWk _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
