Add oslo option to implement message size limitations.

[Daniel Bengtsson]

Requirement T536 from the Threat Modelling initiative specifies, "Limit the size of input messages that services accept to protect them against Denial of Service (DoS) attacks." I think OpenStack services need to trust that other OpenStack services have already sanitized their incoming requests to make them proof against such concerns. As such I believe this is specific to API requests and not to requests that come across the RabbitMQ bus.

[Takashi Kajinami (kajinamit)]

In OpenStack we do not expose messaging queues directly to users to allow them to send messages, and we expect a service is in front of messaging queues sending messages. So the limit may need to be implemented in the service layer, not at the library layer. Services should have appropriate user input (and rejection response such as 401).

If we aim to add limit to protect messaging queue from bad design or bug in services, but even in such case we can first try to use an existing mechanism in messaging queue. For example RabbitMQ has max_message_size option. Setting limit at message queue is more robust way instead of implementing it at library layer.

What we can try for a short term is to check the current behavior against the limit within MQ so that we handle the error properly (though this may not be very needed).

As long term we may want to check how user input is injected into message queues by every service but this may be beyond scope of the oslo project, because it requires investigation in individual components.

[Daniel Bengtsson (damani42)]

Hi,

Actually after a bit of research we found an option in rabbitmq max_message_size. From the rabbitmq documentation:

    max_message_size The largest allowed message payload size in bytes. Messages of larger size will be rejected with a suitable channel exception.
    Default: 134217728
    Max value: 536870912

So we already have that default limit. The limit may need to be configured within rabbitmq.

[Daniel Bengtsson (damani42)]

I totally agree with Takashi, it's not the library so must implement that option but the services.