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

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Feb 24, 2023 at 10:45:13AM +0800, Jason Wang wrote:
> 
> 在 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

that isn't really achievable.

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