Hi Valery, Thanks for taking the time to present your draft at tomorrow's session. I quickly went through your slides — appreciate you including a comparison with our draft. I am sorry for my delayed response! I updated our draft back in January, and didn't get around to responding it.
Thnaks for the numbers in your slides. That give better picture. On Thu, Dec 11, 2025 at 03:19:18PM +0300, Valery Smyslov wrote: > 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). Once this draft is standardized, any such future (imaginary) extension would need to accommodate the existing mechanism regardless. More importantly, your proposal has the same property: the Receipt Status Message is sent with the same Message ID as the original exchange, so you also have two messages sharing a Message ID — the receipt status and the actual IKE response. The concern applies equally to both drafts. As for the Message ID as AEAD counter: yes, implementations need to handle this carefully, but less of a protocol correctness issue. Implementations can track the context create a monotonus counter as IV. > > > 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). The ICV trick interestg. It is smart, and I wonder wouldn't it be an interop risk: a non-supporting peer sees an ICV failure and must decide whether to re-check. No negotiation means no clean capability signaling. Using notifier is my preference. I vote to negotiate. Most of the other points are, in my opinion, a matter of design preference, and I have mine. One concrete reason I strongly prefer ranges over a bitmap: ranges are far easier to inspect in practice — both in Wireshark dissectors and in plain log output — which matters for diagnostics and interop testing. A bitmap requires bit-level decoding; a (start, count) pair is immediately human-readable. The remaining concerns you raised are addressed in v3 of our draft: I am also open to merging the two approaches: keep Valery's ICV trick to avoid negotiation, but use Notify payloads with ranges instead of a bitmap. This would combine the cleaner diagnostics and human-readable encoding of ranges with the no-negotiation property of Valery's design. Would others in the WG like to weigh in? Looking forward to tomorrow's presentation, and hoping we have time during the session to discuss both drafts. regards, -antony _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
