Hi Chris, > Hi ipsecme and chairs, > > This is a small update to the IPTFS draft which incorporates the last 2 > changes that had been requested over > the last year or so. > > 1. As requested last year, it dispenses with the late-enabled functionality, > replacing it with a SHOULD clause > supporting receiving IPTFS encapsulated ESP payloads w/o extra configuration.
I prefer this functionality to be removed. Either you are doing classical tunnel/transport in the SA or you are doing IPTFS. >From my understanding it's just another encapsulation mode. Otherwise we have >the following problems: - Since this functionality is optional its capability must be negotiated (or indicated by the peers) in IKEv2. And negotiation of IPTFS features is already complex enough. - It complicates processing in the kernel. E.g, it's not clear for me what "on receipt of the first IP-TFS payload" means. If packets are reordered in the network and the first received IPTFS packet is not the first sent IPTFS packet? What to do with the non-IPTFS packets sent before first IPTFS packet but received after it? And so on. IPTFS processing in the kernel is already quite complex, let's not introduce additional complexity. - I see no value in this functionality apart from the debugging and I don't want debugging capability to be present in the RFC, so that people, who really don't need it, implement it in their products introducing new bugs. You may argue, that you made it optional, but SHOULD is very close to MUST and in addition making it optional only complicates negotiation of IPTFS. So, please, remove it. > 2. It highlights that one must send payloads that carry inner packet > fragments using consecutive ESP > sequence numbered packets (with a caveat for all pad payload insertion). That's useful clarification, thanks. Regards, Valery. > We feel the document is quite stable at this point and would thus like to ask > for moving to WG Last Call. > > Thanks, > Chris. > > > On Sep 30, 2020, at 12:25 PM, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IP Security Maintenance and Extensions WG > > of the IETF. > > > > Title : IP Traffic Flow Security > > Author : Christian Hopps > > Filename : draft-ietf-ipsecme-iptfs-02.txt > > Pages : 26 > > Date : 2020-09-30 > > > > Abstract: > > This document describes a mechanism to enhance IPsec traffic flow > > security by adding traffic flow confidentiality to encrypted IP > > encapsulated traffic. Traffic flow confidentiality is provided by > > obscuring the size and frequency of IP traffic using a fixed-sized, > > constant-send-rate IPsec tunnel. The solution allows for congestion > > control as well. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-02 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > 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
