On Fri, 29 Nov 2019, Christian Hopps wrote:
ESP SAs are always created in pairs. And whether IP-TFS is enabled or not is
common for both SAs.
Even if you use only one SA for IP-TFS traffic, the other will have IP-TFS
enabled too.
How are you going with your spec to create a pair of SAs where IP-TFS is
enabled in one direction and
disabled in the other? Am I missing something? Even if you are able to create
such a pair of SAs, is it justified?
Understood that SAs are created in pairs. The intent here (and throughout the
draft) is not to unnecessarily restrict possible uses. Having IP-TFS enabled on
only one of a pair of SAs can make sense when you're only trying to protect
traffic sent in one direction from traffic analysis (again e.g., telemetry).
The use of IP-TFS does involve the allocation of a fixed amount of bandwidth so
the justification for not enabling it in one direction is to save that
bandwidth.
It seems unwise to protect traffic one way but not the other way. Are
endusers really able to make the right decision based on their generated
traffic? If you are that hungry for resources, perhaps this isn't an
option for you to use?
Also, if an inbound or outbound SA is not using IP-TFS, couldn't the
memory be deallocated, or the memory allocation could be postponed
until the first IP-TFS type packet arrives?
The architecture is really symmetrical for in/out bound SA's, so I
would prefer we do not change that.
The spec is (trying to be) very careful in not restricting the unidirectional
TFS use case b/c there's no reason to do so, and so there should not be
anything in the document that restricts having only one of the SA pairs used by
IPsec/ESP running with IP-TFS.
The question is, does it need to be negotiated or not or can a well
implemented implementation postpone all memory requirements if this
feature is unused in one direction?
Setting up such an SA pair is orthogonal to being able to run with that
configuration. While the vast majority of IPsec utilizes IKEv2 for SA
creation/management, this is not a requirement of IPsec/ESP. The unidirectional
case can be covered with local configuration (along with IKEv2), or by using
another method entirely for the SA management.
Non-IKE can negotiate whatever it want and hack in custom IPsec SA's
that we would find completely illegal. That's out of scope of this WG,
but we should also not bring it into scope as "others might want that".
The intent in the end is to specify what we need to for IP-TFS operation, but
not too over-specify and unnecessarily restrict possible future (or outside)
uses. IOW, less is more.
But I am still not convinced endusers can make these decisions of
bidirectional vs unidirectional and whther or not their traffic
becomes more susceptible to traffic analyses attacks.
FWIW, I did explore adding machinery to IKEv2 to allow setting up/negotiating
unidirectional use cases, but it adds a lot of complexity, and so we decided
that while unidirectional TFS protection is useful it will still be a
relatively uncommon configuration and was best left for local configuration for
now. If in the future we see a large call for on-demand/negotiated (vs local
config) uni-directional TFS we can always come back and add it to IKEv2. What's
important in the context of the IKEv2 changes for now is that we don't do
anything to block doing this in the future.
I have not yet been convinced of this.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
