Tests for API flood resilience

[Leo-Besancon]

Using the massa-test-framework, we can write functional tests that ensures:

• [ ] Exposed Public APIs servers are resilient to Denial of Service attacks (if one attacker tries to flood it with requests, the server can still handle some of the normal API load)

• [ ] A flood on the API does not impact negatively other modules (the server should still finalize blocks, allow bootstrap, etc.)

• [ ] No memory leaks on the long run for API servers. See how we could do it easily (maybe with the

• Related to the check of the limit: https://github.com/massalabs/massa/issues/4475

Limits should be tested on a referance machine (e.g. k8s cluster).

[aoudiamoncef]

• [x] api local load tests

• launch a node locally with sandbox mode with staking enabled

• launch a python script to spam operations

• see if the api is still responsive

• [ ] api remote load testing

• 3 nodes

• load tests should be run from the launcher of the tests

• 1 specific node installed in the Kubernetes cluster for gRPC or JsonRPC loadtests.

• [ ] protocol load testing

• 3 nodes

• 1 node launched with op_spammer feature enbled

[aoudiamoncef]

@Leo-Besancon

Rethinking Massa Public API Load Testing Strategy

Introduction: The Massa Public API serves as a critical component in our system architecture, connecting various services and enabling seamless communication. Load testing plays a vital role in ensuring the API's robustness, scalability, and reliability. However, a recent evaluation prompts us to reconsider our approach to load testing, specifically focusing on the absence of rate limiting and the necessity of exposing the API to the internet via a reverse proxy.

1. Absence of Rate Limiting: One of the key aspects of load testing is understanding how the system performs under different levels of demand. Rate limiting, the ability to restrict the number of requests a client can make within a specific timeframe, is a fundamental mechanism to prevent abuse, manage server resources, and maintain a consistent quality of service. The Massa Public API currently lacks rate limiting, which raises questions about the accuracy and relevance of our load tests. Without this essential feature, load testing may not accurately simulate real-world scenarios where API usage needs to be controlled and managed.

2. Exposure via Reverse Proxy: Security is paramount when it comes to exposing APIs to the internet. Utilizing a reverse proxy adds an additional layer of security, protecting the API from direct exposure and potential security threats. It acts as a shield, filtering and processing requests before they reach the API server. Without a reverse proxy, the API is vulnerable to various attacks, potentially impacting its performance and stability. However, when load testing, the absence of this security layer might lead to skewed results, as the API is directly exposed, bypassing the protective measures a reverse proxy provides.

3. Reevaluating Load Testing Priorities: Given the absence of rate limiting and the need for a reverse proxy, it's crucial to reconsider our load testing priorities. While load testing remains essential, the focus should shift towards addressing these fundamental concerns first. Implementing rate limiting within the API ensures that load tests simulate realistic usage patterns. Additionally, deploying a reverse proxy enhances security, safeguarding the API from potential threats during testing and real-world usage.

Conclusion: In summary, the Massa Public API load testing strategy requires a revision. Addressing the absence of rate limiting and ensuring the API is exposed via a reverse proxy are fundamental steps before conducting meaningful load tests. By prioritizing these aspects, we not only enhance the accuracy of our tests but also fortify the API against potential security vulnerabilities, ensuring a robust and reliable system for our users.