Hi. So following Daniel’s message in the room, here’s how I think we can make this work.
The IKE header has a “Message ID” field that is a counter. It’s tempting to use this as a counter, same as we use the replay counter in IPsec. However, as Tero pointed out on Jabber, each such message ID can be used several times: All responses have the same Message ID as the requests. The Message ID is one sided. The n-th request from the original Responder has the same Message ID as the n-th request from the original Initiator. When a message is fragmented as in RFC 7383, all fragments that are part of the same message are transmitted (and encrypted) with the same Message ID. Re-using the Message ID makes us re-use the AEAD nonce. Not good. Fortunately, all the algorithms that the IIV draft mentions require an 8-octet IV while the Message ID is 4-octet. We can use the 32 “spare” bits to differentiate these messages. I have two proposals for constructing the 8-octet IV: Proposal #1: ========== | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| And use IIV only for regular Encrypted Payload, not for Encrypted Fragment. The reasoning is that if you use fragmentation you’ve already solved the message-too-big issue. The Flags octet includes the I(nitiator) and R(esponse) bits, which differentiate the cases that are not related to fragmentation. Proposal #2: ========== | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits)| The Fragment Counter is the same as in the RFC 7383 fragment payload, or zero if we are using the regular encrypted payload. The Flags octet includes the I(nitiator) and R(esponse) bits, which differentiate the cases that are not related to fragmentation. The Fragment Counter differentiates between different part of the same message. The Next Payload differentiates between sending a message fragmented and sending it unfragmented. So in summary, I think it’s doable and can be added to the draft if we have consensus. Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
