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?
>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
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
