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

[Christian Hopps <[e-mail]>]

I think it's important for this discussion to recognize that we have 2 orthogonal issues.

1) How does IP-TFS work on the wire with IPsec/ESP - this is where we need to make sure we don't unnecessarily restrict uni-directional use.

2) What are the changes to IKEv2 to support IP-TFS - this is where we need to decided if we need the ability to negotiate uni-direction cases, we don't believe we need to do this. I think this is inline with what people are expecting here (i.e., a pair of SAs with IP-TFS enabled or not).

More inline..

> On Dec 1, 2019, at 2:41 AM, Paul Wouters <[e-mail]> wrote:
> 
> 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?

There is no traffic to protect in the reverse direction. Consider telemetry where one is simply sending un-acked UDP data using to monitors.

> 
> 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.

We are not looking to change the architecture, only to use the existing one (see orthogonal issues). The telemetry example is one case of uni-directional traffic; however, multicast is another area where you can get non-"TCP flow-like" unidirectional configurations.

> 
>> 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?

The standard case of using IKEv2 (i.e., what most users will use) assumes bi-directional use which seems appropriate. The draft also allows for not starting the IP-TFS constant send immediately. Finally, the draft does not restrict other less-traditional use cases which fall outside the scope of IKEv2 use.

For IKEv2 we believe bi-directional only is fine and that's what the draft has defined.

> 
>> 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.

Which users are we talking about here? We agree, for the vast majority of end-users the standard use case will be bi-directional, and the IKEv2 changes reflect this (see 2).

We're not making it *easy* to run uni-directional we're simply not outright prohibiting this use case for users who may have more complex requirements and/or know what they are doing. 

We've got the restriction in IKEv2, but what is the value in further restricting things at the IPsec/ESP level (1)? There is real value lost in making this restriction, so I think we need to justify it if we choose to do so.

Thanks,
Chris.

>> 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
>