Hi Antony,
please, see inline.
> 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.
This would help. However, it won't work if some future (imaginary) IKE extension
makes each exchange to use different key (e.g., as KDF(SK_ex, MSG-ID).
> 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.
Yes.
> 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.
I meant the case:
MID(0) CREATE_CHILD_SA ----> <------ MID(0) CREATE_CHILD_SA
FACK(MID=0, response flag=1) ---> (1) (delayed)
<---- MID(0)
CREATE_CHILD_SA response flag=1
FACK(MID=0, response flag=1) ---> (2)
(1 received)
Message (1) is the FACK response to the responder's request while
message (2) is the FACK response to responder's response to initiator's request.
The responder cannot distinguish these two messages.
I agree that making the content different would help (but see above),
but in general this is a headache to implement (since it violates the steps
the incoming message is processed - it is processed in a context of a particular
exchange that is determined before the message is parsed).
> 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.
This is incorrect, RFC 7383 does not contain this requirement.
RFC 7383 says (or tries to say) that when responder has already sent the
(possibly fragmented) response
and it receives some (retransmitted or delayed) fragments of the request (which
the responder has already processed),
then the responder must only re-send its response if the received fragment
number is 1 (the first fragment).
Thus, the first fragment has a special meaning for the responder when it
decides whether to re-send the response, but
the initiator is free to send any subset of fragments at any time (as well as
the responder).
> > 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.
I don't think that extending fragments number to 2^32 has practical sense.
With 2^16 and the size of fragment around 500 bytes it is enough to transfer
32 Mbytes of data. I'm very skeptical that even with the help of acks
but w/o any congestion control transferring that much data will go smoothly.
> > 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!
Thinking more about this I come up to an alternative proposal:
https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-fragm-large-msg/
Comparing to yours it has (as I believe) the following advantages:
- request/response semantics is preserved - no "response to response"
- retransmission logic is preserved - initiator is always an active side
- IKE replay protection is not affected
- no layer violation - the extension can be entirely implemented in the IKE
fragmentation code,
upper layers (e.g., message parsing and forming) are not affected
- RFC 7383 PMTU discovery is supported
- traffic overhead is smaller in most cases (but I agree that not in all)
- receipt status messages are protected against replays
- no negotiation is needed (not a real advantage, just a feature that can be
changed in future)
My proposal also has one small hack (or a trick), but it is not immanent
to the proposal, there are several ways how to avoid it (and perhaps it is not
needed at all,
this is just in case).
Regards,
Valery.
> regards,
> -antony
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
