> On Nov 29, 2019, at 7:09 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote:
>
> 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.
>
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.
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
