> On Oct 13, 2020, at 7:27 AM, Lou Berger <lber...@labn.net> wrote: > > Valery, > > Please see below. > > On 10/13/2020 3:22 AM, Valery Smyslov wrote: >> 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. > > I agree that there is added code complexity, but have you considered the > operational benefit of having this? Specifically (a) adding yet another > required configuration parameter that must match at both ends to get an ipsec > tunnels up and (b) what it takes to go from an operational non-TFS > configuration to a TFS configuration in one or both directions?
FWIW, there really was no complexity to support this. If one chooses to support it (it is a SHOULD not a MUST after all), you initialize a small amount of receive side IPTFS state for INBOUND SAs. The change to add this functionality to our implementation required: Code: add global always rx tfs ability 3 files changed, 38 insertions(+), 6 deletions(-) ... Less than 50 lines of (init/config) code were modified, quite minimal actually. Perhaps most importantly to your concern, nothing in the data-path (fast-path) actually needs to change. It simplifies configurations for people that are using systems other than IKE for IPsec configuration, it's easy to add to the code, and it's not required (SHOULD not MUST). So I think it's good support this. Thanks, Chris. > >> >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. > > I'm not sure what needs to be negotiated here -- without negotiation the > behavior is the same as would be seen with a miss-configured endpoint or > mismatch in TFS config that will occur without the option. > >> - 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. > > This is an implementation choice, right? Why not just drop it or process it > as the implementation sees fit? > >> 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. > > My view is that the main benefit is simpler configuration and removing a > requirement for timing manual configuration changes at each end of a tunnel. > Configuring IPsec is complex enough, from the operational perspective, I'd > prefer to see this as a MUST, but can live with SHOULD. (IMO - Getting the > code right once per implementation is greatly outweighed by the returns in > not having to impose more configuration and configuration timing burdens.) > > Thanks, > > Lou > >> 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 <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
