Re: ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]

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