> On Mar 14, 2019, at 10:37, Christian Hopps <[email protected]> wrote: > > > Valery Smyslov <[email protected]> writes: > >>> 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. >> >> Yes, don't break IKE core things. > > I was hoping there would be an openness to possible improvements, and wasn't > looking to just break well established protocols. An earlier mail from Paul > made it sound like other use-cases have wanted for expanded functionality as > well.
Just to clarify. It is not that people are not open minded, but that the suggested change technically cannot work due to the base model of how IKEv2 works. The way msgid handling is specified in the core spec cannot support uni-directional behaviour even if we all wanted to add it. And even the current handling has some issues we must clarify in future drafts without the addition of uni-directionality. It is too complicated already. Supporting uni-directionality would mean creating IKEv2.1 or IKEv3, which would be years of efforts. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
