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

[Heng Qi <hengqi@linux.alibaba.com>]

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.

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