Title:
Router fuzzing proposal

Background:
I’m working with @asraa on a router fuzzer. The fuzzer will be modelled around replicating and catching interesting scenarios that caused availability issues and zero-days for Envoy in the past. Currently, no fuzzer executes these codepaths. A vm-exploitable query-of-death (#7154) was caused due to an issue in the router where an upstream request was not reset if the router had already seen headers. This caused a null dereference crash when the body and trailers of the response were attempted to be decoded by the router. Another crash (#6348) occurred when Envoy attempted to refresh a cached route on an early response path.

Description:
Currently the design for the fuzzer incorporates retries and timeouts, with the plan of eventually adding watermarking events and logging.

The proposed input is as follows:

message DirectionalAction {
  oneof response_action_selector {
    test.fuzz.Headers headers = 1;
    uint32 data = 2;
    test.fuzz.Headers trailers = 3;
  }
  bool end_stream = 4;
}

message StreamAction {
  oneof stream_action_selector {
    DirectionalAction request = 1;
    DirectionalAction response = 2;
  }
}

message Action {
  oneof action_selector {
    StreamAction stream_action = 1;
    google.protobuf.Empty advance_time = 2; // to test timeouts
    google.protobuf.Empty upstream_503 = 3; // to test retries
  }
}

message RouterTestCase {
  repeated Action actions = 1;
}

Design Issues:
We’re thinking about using the framework from the router test but it uses mostly mocks so we’re not sure if it’s possible. We are considering using something similar to this but plugging in real encoders/decoders and maybe a real upstream.

We are also considering using the integration test framework, but in order to do this we would have to remove some components to increase the speed of the fuzzer. @asraa looked into this so maybe she can update on whether this is possible.