[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [virtio-dev] Re: [PATCH v9] virtio-net: support inner header hash
å 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 theWhat 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.
ThanksThanks.It seems out of the scope of the spec (unless we want to let driver manageable QOS).ThanksThanks.+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 encapsulation2) whether or not it's the implementation details that the spec doesn't need to care (or how it is solved in real NIC)ThanksAt this point with no ways to mitigate, I don't feel this is somethinge.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.orgThis 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.pdfList Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-listsCommittee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]