Subject: [IPsec] Next IPTFS doc update question

From: Christian Hopps <[email-masked]>
Date: Mon, 14 Sep 2020 14:06:00 -0400

Hi Folks,

I'll be posting a new version of https://www.ietf.org/archive/id/draft-ietf-ipsecme-iptfs-01.txt in the next couple days, and have one edit to ask about.

Early in the document development process there was a request by Valery (perhaps supported by Paul W?) to remove the late-enabling of IP-TFS on an SA. The expressed feeling was this was too much complexity to add for not enough value.

2.4.  Initiating IP-TFS Operation On The SA.

   While a user will normally configure their IPsec tunnel (SA) to
   operate using IP-TFS to start, we also allow IP-TFS operation to be
   enabled post-SA creation and use.  This late-enabling may be useful
   for debugging or other purposes.  To support this late-enabled
   operation the receiver switches to IP-TFS operation on receipt of the
   first ESP payload with the IPTFS_PROTOCOL indicated as the payload
   type which also contains a data block (i.e., a non-empty IP-TFS
   payload).  The the receipt of an empty IPTFS_PROTOCOL payload (i.e.,
   one without any data blocks) is used to communicate congestion
   control information from the receiver back to the sender on a non-IP-
   TFS enabled SA, and MUST NOT cause IP-TFS to be enabled on that SA.

I'm wondering if anyone else has any comments (for or against) on keeping this functionality?

Thanks,
Chris.