Rate Limiting and Request Throttling

[bburda]

Summary

Implement configurable rate limiting to protect the gateway from abuse, denial-of-service attacks, and resource exhaustion.

---

Background

Without rate limiting, malicious or misconfigured clients can:

• Overwhelm the gateway with requests
• Cause resource exhaustion on the ROS 2 system
• Trigger excessive topic sampling or service calls
• Impact legitimate users' access

---

Proposed Solution

1. Rate Limiting Configuration

ros2_medkit_gateway:
  ros__parameters:
    rate_limiting:
      enabled: true

      # Global limits (requests per window)
      global:
        requests_per_minute: 1000
        requests_per_second: 100

      # Per-client limits (by IP or authenticated user)
      per_client:
        requests_per_minute: 100
        requests_per_second: 10

      # Endpoint-specific limits
      endpoints:
        # Heavy operations have stricter limits
        "/*/operations/*":
          requests_per_minute: 30
        "/*/data":
          requests_per_minute: 60

2. Response Headers

Include rate limit information in responses:

• X-RateLimit-Limit: Maximum requests allowed
• X-RateLimit-Remaining: Requests remaining in window
• X-RateLimit-Reset: Timestamp when limit resets

3. Implementation

• Token bucket or sliding window algorithm
• In-memory storage
• Return 429 Too Many Requests when limit exceeded

---

Implementation Tasks

• Design rate limiting data structures
• Implement token bucket algorithm
• Add rate limit middleware to REST server
• Add configuration parameters
• Add rate limit response headers
• Unit tests for rate limiting logic
• Integration tests for 429 responses
• Documentation update

---

Acceptance Criteria

• Requests exceeding limit return 429 with Retry-After header
• Rate limit headers included in all responses
• Different limits configurable per endpoint
• Disabled by default for backward compatibility