[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v9] virtio-net: support inner header hash
On Wed, Feb 22, 2023 at 02:46:51PM +0800, Heng Qi wrote: > 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. OK let's just say "remote attacker" then. > > > > > > +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? > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]