> On Oct 13, 2020, at 9:16 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote: > > Hi Lou, > >> 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? > > I can't buy these arguments. Using IPTFS is negotiated in IKEv2 via > exchange of USE_IPTFS notify (BTW, note a typo in Section 5.1 title: USE_TFS > instead of USE_IPTFS). > So, unless you upgrade both ends and update configuration IPTFS won't be used > at all. > Once you upgrade one end you can add a configuration parameter to it to > propose using IPTFS while being initiator. Until the other end is upgraded > too, > it will ignore the USE_IPTFS notify and SA will be established in tunnel mode. > Once the other end is upgraded and its configuration is changed they > will start using 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. >> >> 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. > > Not true. If peers are misconfigured, then IPTFS won't be negotiated and SA > will be established in tunnel mode > (if using IPTFS is optional for both) or not established at all (if using PFS > is mandatory for the peer suggesting it). > On the contrary, if switching from tunnel to IPTFS on live SA is not > negotiated, and one of the peers doesn't > support it, then when the other peer switches from tunnel mode to IPTFS on > live IPsec SA and starts sending > IPTFS packets, then the first peer will most probably drop them. We'll get a > classical "black hole", and the worst > thing that it won't be detected by liveness checks, since IKE SA will be > perfectly workable. > >>> - 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? > > Right, but it complicates processing. Currently I uniformly process all the > packets within window. > Now I have to remember on which E(SN) the switching occured and process > previous > packets as tunnel (or start dropping them) and subsequent packets as IPTFS. > >>> 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.) > > Please, see above. Since using IPTFS is negotiated, I see no simplification > in configuring. You still need to upgrade and configure properly both ends > before you can use it.
IPTFS is not always negotiated, as IKE is not always used. Supporting zero-conf IPTFS receive is very useful for supporting these non-IKE use-cases. Thanks, Chris. > > If you badly need this feature, then please make it MAY and negotiable, > so that people can ignore it. SHOULD is too strong for it, > leaving it non-negotiable is just unacceptable, IMHO. > > Regards, > Valery. > >> 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 >>> 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
