On Wed, 20 Feb 2019, Sandeep Kampati wrote:
Htmlized: https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00
I read the draft and I think it has some good ideas, and a few things I don't like as much :) The idea of not including the SA when rekeying for the identical IPsec or IKE SA looks good to me. Omitting the TS payload in ESP transport mode for rekeying seems okay as well, but does seem to be a bit of a corner case to optimize for. But I can't come up with a strong reason not to do it. There is an issue when there are multiple IPsec SA's - you need the TS to see which one is being rekeyed. So when omitted, you need to send the old SPI? Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in IKE_INIT, it should be send in IKE_AUTH because we can fragment in IKE_AUTH and not in IKE_INIT. It also reduces what a passive attacker can see and fingerprint users/implementations on. I'd also prefer a shorter name than IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED, perhaps call it MINIMAL_REKEY_SUPPORTED ? (we don't prefix with IKEV2 in https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16 Section 3.1 should clarify the payload length is 0? It should clarify the setting of the Critical flag (off) Some clarification should be needed on whether sending the notify means the rekeys MAY or MUST use this new feature. The NEW_SPI should probably have the critical flag set? The example talks about there being a KEi payload, but if there is no PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only covers ike rekey, so then this is right. maybe clarify :) the text states "initiator will send initiator IKE SPI" but that is only true for IKE rekey, not IPsec rekey where it needs to send the IPsec SPI. If there is more than one IPsec SA, then omiting the TS would lead to the responder no longer knowing which IPsec SA is being rekeyed. So perhaps sending the old SPI would be needed. Or if we decide this is too much of a corner case, perhaps we should not allow omittig the TS? I think 3.2.1 should named better, eg "IKE SA rekey without SA" and 3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 is a bit odd. (i misread 3.2.1 making assumptions about child sa) I think a more clear split between ike/child rekey is needed. Currently 3.2.1 is about IKE, 3.2.2. about both? 3.3 again ensure to tell critical flag must be set. I think an OLD_SPI() payload is needed here too. Section 4 needs work :) But in a way it is more secure agains accidental downgrade of cryptographic strength. But also it prevents upgrade of cryptographic strength. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
