Hi Valery,
Thank you for the detailed feedback.
I have been looking through the simultaneous-initiation case you describe,
where both peers have just completed an IKE SA rekey and therefore begin
with Message ID 0 on each side. One situation can be slightly problematic
when there delayed responses, however, I don't see any case where the
proposed ack would fail to advance the negotation.
Still to make it clear at the end I am proposing two direction specific
Notifiers instead of one.
Here is How I see the case you described. I am using
CREATE_CHILD_SA as example. The analysis would similar for other excahnge
too.
1. Simultaneous CREATE_CHILD_SA requests after rekey
In the simplest case:
---- IKE SA Rekeyed both ends Message ID 0
Request
Initiator Responder
MID(0) CREATE_CHILD_SA ----> <------ MID(0) CREATE_CHILD_SA
FACK(MID=0, respose flag=1) ---> <------ FACK(MID=0, respose flag=1)
Since each peer knows it has an outstanding request with MID=0,
the received FACK(MID=0,R=1) can be unambiguously associated with its own
outstanding request.
2. Case where one peer has advanced its CREATE_CHILD_SA exchange and the
response is lost
A more interesting scenario is when both peers send the CREATE_CHILD_SA
request, but one peer sends its response and then advances its internal
state, while the response is lost:
The actual CREATE_CHILD_SA response fragments are lost. And the initiator
responsd with FACK(MID=0, respose flag)
MID(0) CREATE_CHILD_SA ----> <------ MID(0) CREATE_CHILD_SA
FACK(MID=0, respose flag=1) ---> <------ Partial Retransmit (MID=0)
MID(0) CREATE_CHILD_SA respose flag=1 ---->
<------MID(0) CREATE_CHILD_SA respose
flag=1 ---->
<------ FACK(MID=0, respose flag=1)
Here, once the responders have advanced past CREATE_CHILD_SA, any FACK it
receives later clearly corresponds to the response it sent.
The initiator can correctly attribute that FACK to the outstanding response
it is waiting for.
3. Delayed or misordered FACK messages
I agree there are corner cases where a delayed FACK may arrive late and
overlap with another exchange with same MID, 0 in this case..
However, in these cases processing the FACK as a hint rather than a
state-advancing message does not break protocol correctness.
At worst, a late FACK would simply cause an extra re-transmit of fragments
that already arrived.
Addressing your core concern: distinguishing request-side vs response-side
acknowledgments
To address the case where a FACK for a request and a FACK for a response may
look identical (same MID, same exchange type, same R flag), I agree this
could lead to an un necessary ambiguity in simultaneous-initiation
scenarios.
To resolve this cleanly, I propose defining two separate Notify Status
Types:
FRAGMENT_ACK_REQ — acknowledgment of fragments belonging to a request
FRAGMENT_ACK_RES — acknowledgment of fragments belonging to a response
These two notifiers would make the semantic direction explicit, eliminating
any ambiguity you describe even in simultaneous exchanges with identical
Message IDs.
more responses bellow inline.
On Wed, Nov 26, 2025 at 03:24:15PM +0300, Valery Smyslov wrote:
> HI Antony,
>
> I doubt that this proposal is workable, at least in some situations.
> Consider the IKE SA was just rekeyed, so that each peer starts
> its first exchange with Message ID = 0. And consider they simultaneously
> initiate same exchange, say CREATE_CHILD_SA. And consider
> the response messages need fragmentation. Then the "response to response"
> messages will have the same Message ID (0) and the same exchange type
> and the same "response flag" as the regular response message for the
> other exchange. Moreover, they both can have the same content - FRAGMENT_ACK
> notify.
> It is impossible for the receiver to find the exchange this message belongs
> to.
> (OK, I can imagine a lot of possible approaches in this situation - e.g.,
> ignore
> such messages or process them for both exchanges since it is only a hint,
> but this decreases the value of this extension).
>
> In addition, you have to disable (or somehow tweak) a replay protection
> mechanism
> in IKEv2 since you should be able to process different messages with the same
> Message ID.
> And you already said that retransmission behavior of responders is also
> changed.
>
> Overall, the proposed solution looks like a protocol hack to me and I'm not
> sure it is
> so easy to implement (taking into considerations all possible cases).
>
> I think that depending on the nature of packet loss and the maximum size of
> the message,
> several approaches are possible.
>
> 1. If the message size is of few tens of Kbytes (so that the number of
> fragments is few tens),
> then the simplest solution would be either to randomize the order
> fragments are sent
> when retransmitted (or just shift them) and/or add some small delay
> (20-50 ms) between sending each
> fragment. This will cope with situation when network is quickly saturated
> or the receiver's buffers
> are too small and receivers performance is insufficient. In this case
> only the first few fragments are
> processed and the rest is dropped. Both solutions (changing the order of
> fragment and introducing
> delay) should help. They are both easy to implement and don't require
> protocol change.
This is a good idea. Thanks.
Also note RFC7383 state every retransmit must include the first segment. Our
proposal relaxes this requirement when responding to FRAGMENT_ACK_*, because
the first is received.
>
> 2. If the message size is of several hundreds of Kbytes (so that the number
> of fragments is few hundreds),
> then the above approach might not help. In this situation your proposal
> may not help too,
> because the size of FRAGMENT_ACK can grow so much, that the message
> containing it
> would be fragmented itself. In addition, if the reason of the packet loss
> is also network saturation
> or insufficient buffer size on receiver, then even with individual acks
> the process may still
> not converged (you still send a lot of extra data with each
> retransmission, that adds to the problem).
> In this situation the preferred solution would be to redefine IKE
> exchanges, perhaps splitting
> them into two sub-exchanges, where peer send a series of fragments one by
> one each
> individually acknowledged (and not all fragments at once).
>
> 3. If the message size is more than 1 Mbyte, then it is not possible to use
> UDP with IKE fragmentation
> in its current form regardless of how fragments are sent and
> acknowledged, because
> the number of fragments is limited to 2^16, thus TCP should be used.
Yes. This out of scope until number IKEv2 extend fragment numbers. Which at
this point I think is simple update RFC7383 to extend "Total Fragments" and
"Fragment Number" to 32 bit numbers from the current 16 bits. I tried to
write it down! The prposed Fragment Ack could support 32bit versions as well.
> And if network just randomly drops packets (I assume there is no congestion
> problems),
> then your proposal won't help much (in my opinion).
>
> I believe we are now at situation #1. Thus I think that simpler approaches
> should help.
> If we sometime reach situation #2 (e.g., if we use Classic McEliece with the
> smallest public keys),
> then proposals like yours can be considered (but I prefer less hacking
> approaches).
I am trying to be a bit less hack with two notifiers!
regards,
-antony
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
