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. > 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. 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
