On Tue, 11 Jan 2022, Valery Smyslov wrote:
This sort of construction invites ambiguity if there is ever some other future exchange that wants to go between IKE_SA_INIT and IKE_AUTH. This seems like a strong argument in support of the approach this draft takes, i.e., make IKE_INTERMEDIATE fully generic, so as to minimize the chance of needing such an additional future exchange. That said, it might be possible to slightly improve the future-proofing if we included an indicator of what the "next content" after MACedIDFor[IR] is, such as the one-octet encoding of the exchange type. (I think it would have to be part of IntAuth_N, not IntAuth itself.) I don't have a great sense for whether the value this adds would be worth the disruption to existing implementations, though.
I think this makes sense, and I would be okay with such a change.
If the WG thinks that it's worth to do this modification, then we may also consider addressing the following issue, raised past WGLC by Tobias Brunner: https://mailarchive.ietf.org/arch/msg/ipsec/8kM6GoPeJwjuoxSH4CL4B75ZJMk/
The WG reaction at that time was that the issue is minor and no modification is needed, but _if_ we decide to incorporate Ben's modification, then we can address this issue too.
I'm not sure this is needed. Implementations will anyway limit the number of IKE_INTERMEDIATE exchanges they are willing to accept to some reasonably very low number. Although if others want this, I won't object.
And even if we decide to leave it out, some words should be added to Security Considerations section anyway, I'll do it.
That makes sense. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
