Hi Chris, > Transforms aren't just about the encryption algorithm though (e.g., the > extended sequence number > transform).
Whether you want to use ESN or not can depend on selected cryptographic algorithms (there is no point to use ESN unless algorithm allows to encrypt a large amount of data with a single key). > In the IP-TFS case it's not about whether one would enable TFS with a given > encryption algorithm. Exactly. That's why I think it's better to decouple the negotiation of IP-TFS from the negotiation of cryptographic algorithms. In your current proposal they are coupled, and this will lead to some problems. For example, if using IP-TFS congestion control is optional for the initiator, then it must include two IP-TFS transforms in every proposal. If using IP-TFS itself is optional, then all the proposals must be duplicated (with and w/o IP-TFS transforms), because legacy implementations will ignore the whole proposal when they see an unknown transform type in it. This will lead to SA payload explosion. And things will get worse with QSKE, since additional key exchanges must be negotiated using new transforms (they are crypto-related). > 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. :) 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. > 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
