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

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

在 2023/2/24 上午10:45, Jason Wang 写道:
>
> 在 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?

Yes, maybe the device does not guarantee QoS or needs to guarantee 
enqueue fairness between flows.

Thanks.

>
> 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
>>
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: 
> https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/