> On Mar 12, 2019, at 10:34, Valery Smyslov <[email protected]> wrote: > > Hi Chris, > >> Sure, I'm definitely open to changes, and in particular with the congestion >> info report. This is just the first >> draft. :) >> >> So my reading of IKEv2 indicated that one way notifications were supported, >> not that they were *only* to be >> used for unprotected error notification though. Yes, they are currently only >> used for errors, but again I didn't >> read they were restricted to that use alone. > > No, unidirectional notifications cannot be used in regular IKE SAs. The > reason is that both peers must have common view > on the next Message ID to be used in each direction. If unidirectional > message with Message ID N is lost, its sender will never know > that > and think he can safely use Message ID N+1 for the next exchange, while the > receiver will discard N+1, since > N is not received yet (I assume for simplicity that IKE window size is 1). > This simply won't work. > > In current IKEv2 unidirectional messages are exceptions and can only be sent > unencrypted outside > any existing IKE SA.
Ok. Perhaps we could look into extending their usefulness? >> The reason I did not want to make the report sending reliable is that they >> are continuously sent on an >> relatively short interval. It didn't make a lot of sense to be re-sending a >> possibly growing queue of reports >> repeatedly, when the latest one would do. > > Then send them over IPsec. Unfortunately this would require bi-directional tunnels, which we don’t want to require. More in the reply to the other email... Thanks, Chris. > > Regards, > Valery. > >> Thanks, >> Chris. >> >> >> >>> On Mar 11, 2019, at 11:43 AM, Valery Smyslov <[email protected]> wrote: >>> >>> Hi, >>> >>>> We utilize a send only (i.e., no response expected) IKEv2 >>>> INFORMATIONAL exchange (37) to transmit the congestion information >>>> using a notification payload of type TFS_CONGEST_INFO (TBD). The The >>>> Response bit should be set to 0. As no response is expected the only >>>> payload should be the congestion information in the notification >>>> payload. >>>> >>>> This very much violates the state machine model of IKEv2, and I would >>>> not be in favour of this without strong arguments of why requiring a >>>> response (even if empty) is harmful. >>> >>> Strongly agree. Actually, one-way notifications are only defined >>> in IKEv2 for unprotected error notifications when no IKE SA exists >>> (like INVALID_IKE_SPI notifications). They simply don't work >>> for regular IKEv2 traffic. >>> >>> Regards, >>> Valery. >>> >>>> Paul >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> _______________________________________________ >>> IPsec mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ipsec >>> > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
