> On Dec 1, 2019, at 9:28 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
>
> On Sun, Dec 01, 2019 at 03:52:30AM -0500, Christian Hopps wrote:
>> 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 <p...@nohats.ca> wrote:
>>>
>>> On Fri, 29 Nov 2019, Christian Hopps wrote:
>>>
>>> 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.
>
> I feel like I must be missing something; if there's no traffic in the
> reverse direction why does it matter if we assign semantics to the reverse
> SA or not?
B/c an IP-TFS enabled SA is sending a constant stream of packets either filled
with the actual traffic or pad if no data is available.
Thanks,
Chris.
>
> -Ben
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
