Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

[Valery Smyslov <[e-mail]>]

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.

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, [e-mail] 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ipsec
> >>>
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >