Comment 34 for bug 1227575

@malini-k-bhandaru
> I read the bug report and it mentions noVNC and SPICE, so I incorporated both in the messaging.

Good call. I've adjusted some wording slightly, but the additions you made look good overall.

> Which is the entity that becomes unresponsive?
> 1) The noVNC Proxy host? (the middle wheel in bottom that hosts the Nova console auth)
> Or
> 2) The compute node, top right?

The responsiveness of the nova-novncproxy service is what we are most concerned about. It is true that a host running nova-compute compute node has to deal with the incoming VNC connections as well, but there are usually many compute nodes and instances are balanced across them. If the nova-novncproxy service is the bottleneck, then the compute node itself won't become non-responsive.

> What is meant by "no amplification" ?

As I understand it, it's a when the volume of traffic in an attack is amplified. This typically involves getting many other services to reflect traffic at the target. For a real world example, lookup "smurf attack".

> That means damage is limited right, then answer should be (2) above.

It's not limited (which is the main issue here). It just means it's not amplified. That is, the attacker needs to be able to open enough connections themself to overcome the resources of the system running nova-novncproxy.

> But if it is two, each compute node would need to be listed and rate limited?

As I mentioned above, the nova-novncproxy service is the main concern. It wouldn't hurt to mention that a compute node could be affected too. I've just added this to the note draft on the wiki.