> On Nov 29, 2019, at 11:14 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote:
>
>>> I envision a lively discussion with INT folks if we ask them for a "fake"
>>> protocol number :-)
>>
>> I would not choose to refer to it as a fake protocol. The field is defined
>> as an IPv4 or IPv6 protocol value to
>> identify the ESP payload. IPsec/ESP is *the* standard for encrypting IP
>> traffic so this field has a valid claim to
>> make on that number space. Just b/c it may not (but see next point) be used
>> outside of IPsec/ESP doesn't
>> mean that IPsec should not be able to allocate a number from it.
>
> I meant that this IP protocol number will never be seen (and used) outside
> ESP.
> So, it's an ESP-only protocol number, thus for INT folks it's a "fake" one.
What I'm saying is that IPsec/ESP is *the* standard for encrypted IP even in
the context of INT, so the next header field in the ESP payload is a valid IP
protocol payload in that context, it's not fake in the INT context just b/c it
might not be used outside of encrypted IP packets.
[...]
>>>> The next-header value is not always redundant, the use case where IP-TFS
>>>> is enabled in only one direction
>>>> with congestion control enabled requires being able to differentiate
>>>> IPv[46] packets from IP-TFS CC
>>>> information which is now sent in-band in the return direction. The CC
>>>> information was moved in-band out
>> of
>>>> IKEv2 from the original -00 document based on comments from the WG (and I
>>>> agree is a much better
>> solution
>>>> :)
>>>
>>> It's a strange use case. Both peers must support IP-TFS, but it is used
>>> only in one direction, so its usefulness
>>> is limited (you can gain quite a lot information from timing of return
>>> packets). Do we really need to
>> complicate
>>> things to allow such asymmetric use case? BTW, you cannot negotiate it with
>>> your current spec :-)
>>
>> I do not think this is strange, consider uni-directional data streams, e.g.,
>> telemetry.
>
> 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.
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.
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.
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.
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.
Thanks,
Chris.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
