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. 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. 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 >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
