> > It can easily be done with a single notification containing the proposed > > features. > > The responder would send back the notification indicating the features it > > agrees to use. > > > > I have some doubts about calling this "easy". This sounds a lot like the > already existing transform mechanism. > Are there other deployed examples of negotiating the required features of an > SA using notifications in parallel > with the transforms? It seems to me there's a lot of standard text, > experience, and deployed code written > getting the transform negotiation mechanism working correctly. Duplicating > this rather than re-using it > worries me.
A lot of things in IKEv2 is negotiated by using notifications. With regard to child SA they are - using transport mode, using IPcomp, using WESP, using ROHC. IP-TFC looks to me like a natural continuation of this line. Regards, Valery. > Thanks, > Chris. > > >> After coding this I will say using transforms feels like a very natural > >> fit. > > > > And notifications is even more natural fit :-) > > > > > > Regards, > > Valery. > > > >> Thanks, > >> Chris. > >> > >>> On Nov 28, 2019, at 8:49 AM, Valery Smyslov <smyslov.i...@gmail.com> > >>> wrote: > >>> > >>> 3. I think that using new Transform Type for IP-TFS negotiation is a bad > >>> idea. > >>> Transforms are best thing when combination of them matters. I don't think > >>> that it is the case - negotiation of using IP-TFS is orthogonal to > >>> negotiation > >>> of algorithms to use. I cannot imagine that one wants to use IPTFS with > >>> say AES-GCM and doesn't want to do it with say Chacha+Poly. > >>> So I believe it is better to negotiate IPTFS by means of notifications, > >>> as it is done > >>> with transport mode or WESP. So, a new notification (let call it > >>> USE_IPTFS) should be > >>> introduced, which will contain data regarding whether congestion control > >>> is needed and whether fragmentation is allowed. If the responder > >>> supports > >>> IPTFS it will return back this notification with the data reflecting > >>> its choice > >>> of IPTFS features. In this case IPTFS_REQUIREMENTS notification is not > >>> needed. > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
