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."  In the discussion of that requirement, hberaud provided the following view.  This ticket is to request the development of the faculty Herve outlines.

From an oslo perspective it would be surely possible to add an extra option to allow optional message size limitations. Services would configure this option at their convenience. By default message size won't been limited, hence, designate won't be impacted, but services who are eagers to use it could activate this option by setting the limitation size and so implement their own DoS protection. I would suggest a default value of `-1` which would mean no limitation.

Here are a couple of questions that should be answered first to define how we want to implement it:

Do we have a stallion measure? By example is the option should be set in bytes, kilo, mega, etc...

I believe that Kilobytes would be a user-friendly measurement to use.

If this option is set, do we have a threshold that must not be exceeded?

No, there is no hard limitation - allowing the tunable is the main goal.  Clouds could then incorporate use of this message size tunable to provide additional robustness to their cloud.

What do we want to do if the message exceed the size? Reject, fail, warn...

We should reject the request with an appropriate error message.

What if some services discussing together by using messaging are not using the same limitation size? Limit configuration is only for senders and the size of the received messages doesn't matter?

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.