> On Mar 12, 2019, at 10:39, Valery Smyslov <[email protected]> wrote: > > Hi Chris, > >> There are other ways to skin this cat though. :) >> >> One option is that instead of sending a new CC info report on the interval >> timer expiry if we haven't received a >> response "ack" yet, we simply update the data (last seq num seen, drop count >> and timestamp) we sent >> previously to be current, keep the message ID the same and resend the >> message. Would changing the data in >> the message prior to resending be preferable? > > No, all retransmissions of IKE message with the same Message ID must be > binary identical.
Perhaps we could relax this requirement for this particular message though. This seems like a simple tightly-focused semantic change which gets us past the roadblock. FWIW, regarding retransmission and message IDs, one thing I considered was not even using the message ID at all (e.g., let it be 0) but this seemed too radical as a first approach. :) If there really is no way to work around this, I suppose we just require retransmissions of CC info reports until they are ACKd or things are torn down b/c of drops (i.e., normal INFO exchange). It does feel like we are adding fragility here that isn’t really needed though. It makes the functioning of the unidirectional tunnel depend more heavily on the reverse direction traffic working when that isn’t actually needed for the tunnel to operate. Thanks, Chris. > > Regards, > Valery. > >> Thanks, >> Chris. > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
