[IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
Dear ipsec WG, When working on a VPN implementation we found that it's very difficult to rely on IPv6 ESP packets because many networks drop them, so even if IKE negotiation succeeds, the data plane might be broken. Worse, this can happen on migrate, blackholing an existing session until the problem is detected and fixed with another migration. In many cases, I think a simple "pre-flight check" to see if ESP is supported on a given network path could solve this problem. So after a few conversations with folks here I put together this draft. It provides the equivalent of an ESP ping packet. Comments and feedback appreciated. Cheers, Lorenzo -- Forwarded message - From: Date: Tue, Jul 25, 2023 at 7:01 PM Subject: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt To: Lorenzo Colitti A new version of I-D, draft-colitti-ipsecme-esp-ping-00.txt has been successfully submitted by Lorenzo Colitti and posted to the IETF repository. Name: draft-colitti-ipsecme-esp-ping Revision: 00 Title: ESP Echo Protocol Document date: 2023-07-25 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-00.txt Status: https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ Html: https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping Abstract: This document defines an ESP echo function which can be used to detect whether a given network path supports IPv6 ESP packets. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update
On Jul 25, 2023, at 00:19, Tobias Brunner wrote: > > > > That's exactly what I'm proposing. Make it *mandatory* that the first > rekeying of the Child SA that's created with IKE_AUTH is a regular one. > Because if that's not the case, it might be impossible for a responder > to deduce what the initiator's proposal is. All further rekeyings of > that Child SA can be optimized afterwards. I do not want to make it mandatory because for IoT devices with provisioning, this is not needed and the whole point is saving energy by not sending unnecessary bytes and a regular rekey is a LOT of bytes. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update
Hi Tero, >> It already states in section 3: "Non-optimized, regular rekey requests >> MUST always be accepted." > ... >> So you're saying some configs, that are valid for regular IKEv2, will >> just not work with this extension? And we'll only know once there is > > Combining those two, I think this is fine. I.e., this is optimization > and it does NOT NEED to optimize every single possible configuration. > We can clearly state that if you are using certain configurations you > can't use this optimization, and have to fall back to normal rekey. > > For example we could say that if you are negotiating multiple > protocols (AH + ESP or ESP + IPCOMP), or if you are using anything > else than one single KE algorithm for create child sa, you need to use > regular rekey. While there might be configurations that prevent this extension from working at all (but I think e.g. with IPComp sending the CPI with the regular IPCOMP_SUPPORTED notify in the optimized rekeying exchange should be fine), I think, with regards to key exchanges, a regular rekeying is really only necessary the first time the initial Child SA is rekeyed. For all other Child SAs it's perfectly fine to use optimized rekeyings because their proposals were negotiated with a regular CREATE_CHILD_SA exchange. >> The only way to avoid that would be the extension either making >> childless IKE SAs mandatory, or strictly prohibiting inconsistent KE >> configs between IKE and Child SAs, taking away quite a bit of >> flexibility IKEv2 offers. > > You do not need to make childless IKE SA mandatory, you simply need to > do first rekey after initial sa creation using normal rekey, and if > that normal rekey has SA/KE payloads that are acceptable for the > optimized rekey in the future, then you can use optimized rekeys in > the future. That's exactly what I'm proposing. Make it *mandatory* that the first rekeying of the Child SA that's created with IKE_AUTH is a regular one. Because if that's not the case, it might be impossible for a responder to deduce what the initiator's proposal is. All further rekeyings of that Child SA can be optimized afterwards. Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
