Transforms aren't just about the encryption algorithm though (e.g., the extended sequence number transform). In the IP-TFS case it's not about whether one would enable TFS with a given encryption algorithm. Consider supporting and/or selecting from the set of IP-TFS with congestion control, IP-TFS without congestion control, no-IP-TFS, or even another future-defined TFS algorithm. Being able to easy negotiate these different selections was what drove me to the current design. :)
After coding this I will say using transforms feels like a very natural fit. 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
