[IPsec] DELETE_REASON notify (draft-pwouters-ipsecme-delete-info)

At IETF-118 I presented the issue on reason of deletion. From the Introduction: The IKEv2 [RFC7296] protocol supports sending a Delete Notify message, but this message cannot convey the reason why a particular Child SA or IKE SA is being deleted. It can be useful

[IPsec] draft-pwouters-ipsecme-child-pfs-info

I agreed to write up a draft to discuss the issue regarding rekeying the initial Child SA and KE/PFS settings. Previous discussion/presentation at IETF118: https://datatracker.ietf.org/meeting/118/materials/slides-118-ipsecme-ikev2-dhke-interop-issues-00 Initial proposed draft: https://data

Re: [IPsec] Review of draft-kampanakis-ml-kem-ikev2-02

I agree that it sounds like a good time to start work on postquantum IKEv2 authentication. In addition to the lamps draft you cite, my list of items that need to be done (or at least considered) include: * Specifying the code points in the auth payload to mean “dilithium signature” (and I

[IPsec] Review of draft-kampanakis-ml-kem-ikev2-02

Review of draft-kampanakis-ml-kem-ikev2-02 Hi, I think IPSECME should adopt this draft asap. This should definitely be a standards track RFC. I really like that IKEv2 register KEMs as separate code points and not hybrid code points like in TLS 1.3. I think the hybrid code points in TLS 1.3 migh