Hi Paul, >> 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.
OK, I understand that there are situations where it would be an advantage to only do optimized rekeyings for the Child SA created with IKE_AUTH (although in the IoT case I'd assume the proposals and TS are relatively small to begin with). And I think there are scenarios where we can do so (relatively) unambiguously. For instance, if no PFS is needed and the initiator omits the KE payload, that's quite clear for the responder. And if a KE payload is received, the responder could perhaps safely assume that that's the only and required key exchange (i.e. the initiator would not have NONE or any additional key exchanges in the proposal if it were to initiate a regular rekeying). So maybe we could define a set of conditions/requirements that allow initiators to use an optimized rekeying for the first rekeying of the initial Child SA (or that require a regular rekeying, whatever is shorter/easier). Of course, there could still be mismatches. PFS vs. no PFS results in a NO_PROPOSAL_CHOSEN error, like with a regular rekeying, so that's fine. But if the proposed KE method is unsuitable for the responder, it would either have to respond with NO_PROPOSAL_CHOSEN, too, or there need to be guidelines on what KE method to encode in an INVALID_KE_PAYLOAD notify, as we don't have a proposal from the initiator to select from (maybe NONE, which normally doesn't make sense, to trigger a regular rekeying?). And also what the initiator would do after receiving such an INVALID_KE_PAYLOAD error (always retry with a regular rekeying, or maybe with an optimized rekeying using the requested method if there is one and it's in its proposal). Regards, Tobias _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
