Re: [virtio-dev] Re: [PATCH v9] virtio-net: support inner header hash

[Jason Wang <jasowang@redhat.com>]

在 2023/2/23 12:41, Heng Qi 写道:
>
>
> 在 2023/2/23 上午10:50, Jason Wang 写道:
>> Hi:
>>
>> 在 2023/2/22 14:46, Heng Qi 写道:
>>> Hi, Jason. Long time no see. :)
>>>
>>> 在 2023/2/22 上午11:22, Jason Wang 写道:
>>>>
>>>> 在 2023/2/22 01:50, Michael S. Tsirkin 写道:
>>>>> On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
>>>>>> +\subparagraph{Security risks between encapsulated packets and RSS}
>>>>>> +There may be potential security risks when encapsulated packets 
>>>>>> using RSS to
>>>>>> +select queues for placement. When a user inside a tunnel tries 
>>>>>> to control the
>>>>
>>>>
>>>> What do you mean by "user" here? Is it a remote or local one?
>>>>
>>>
>>> I mean a remote attacker who is not under the control of the tunnel 
>>> owner.
>>
>>
>> Anything may the tunnel different? I think this can happen even 
>> without tunnel (and even with single queue).
>
> I agree.
>
>>
>> How to mitigate those attackers seems more like a implementation 
>> details where might require fair queuing or other QOS technology 
>> which has been well studied.
>
> I am also not sure whether this point needs to be focused on in the 
> spec, and I see that the protection against tunnel DoS is more 
> protected outside the device,
> but it seems to be okay to give some attack reminders.


Maybe it's sufficient to say the device should make sure the fairness 
among different flows when queuing packets?

Thanks


>
> Thanks.
>
>>
>> It seems out of the scope of the spec (unless we want to let driver 
>> manageable QOS).
>>
>> Thanks
>>
>>
>>>
>>> Thanks.
>>>
>>>>
>>>>>> +enqueuing of encapsulated packets, then the user can flood the 
>>>>>> device with invaild
>>>>>> +packets, and the flooded packets may be hashed into the same 
>>>>>> queue as packets in
>>>>>> +other normal tunnels, which causing the queue to overflow.
>>>>>> +
>>>>>> +This can pose several security risks:
>>>>>> +\begin{itemize}
>>>>>> +\item  Encapsulated packets in the normal tunnels cannot be 
>>>>>> enqueued due to queue
>>>>>> +       overflow, resulting in a large amount of packet loss.
>>>>>> +\item  The delay and retransmission of packets in the normal 
>>>>>> tunnels are extremely increased.
>>>>>> +\item  The user can observe the traffic information and enqueue 
>>>>>> information of other normal
>>>>>> +       tunnels, and conduct targeted DoS attacks.
>>>>>> +\end{\itemize}
>>>>>> +
>>>>> Hmm with this all written out it sounds pretty severe.
>>>>
>>>>
>>>> I think we need first understand whether or not it's a problem that 
>>>> we need to solve at spec level:
>>>>
>>>> 1) anything make encapsulated packets different or why we can't hit 
>>>> this problem without encapsulation
>>>>
>>>> 2) whether or not it's the implementation details that the spec 
>>>> doesn't need to care (or how it is solved in real NIC)
>>>>
>>>> Thanks
>>>>
>>>>
>>>>> At this point with no ways to mitigate, I don't feel this is 
>>>>> something
>>>>> e.g. Linux can enable.  I am not going to nack the spec patch if
>>>>> others  find this somehow useful e.g. for dpdk.
>>>>> How about CC e.g. dpdk devs or whoever else is going to use this
>>>>> and asking them for the opinion?
>>>>>
>>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org