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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
