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

[Christian Hopps <[e-mail]>]

> On Oct 13, 2020, at 9:16 AM, Valery Smyslov <[e-mail]> 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, [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