RE: [virtio-comment] [PATCH v8] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, February 13, 2023 3:44 PM

[..]
> 
> I didn't yes come up with anything convincing for improving security (dos/usage
> info leak due to queue collisions between tunnels).
> 
> I'd like to at least have a security considerations section documenting the issue
> with using RSS with tunneling.
This is good to add.

> In fact it's high time we started adding these sections all over the place.
> 
> I also found out at least mlx5 has these tunnel offloads, so I'd like to ask nvidia
> guys here on list
> - does this cover e.g. mlx5 functionality? e.g. is the tunnel list
>   sufficient?
Yes, it covers the functionality.
In most cases the sender is rate limited.
But for sure, RX can be under DOS.
Tunnel offloads are mostly used on the switching device than the guest VM NIC.

In such scenario of switching device, there are dedicated RQs per each port of the switch (multi-port NIC) with dedicated RQs.
So, there is no DOS attack per say on the RQ.
Tunnel offload is just to overcome the limitations of hashing done on the outer.

At virtio we are bit far away from such multi-port NIC. Tunnel offloads is step 1 in getting there.

> - does mlx5 cover queue collisions between tunnels and if yes how?
In scenario where there is collision, a receive policer is deployed to avoid the DOS.