UDP proxy fuzzing

[asraa]

UDP proxy fuzzing:
The goal of this fuzzer is to test Envoy’s UDP proxy listener filter. Currently, UDP proxy is intended to be robust against untrusted downstream traffic and assumes that the upstream is trusted. However, including fuzzing of upstream data is trivial to add, so the scope of this project will fuzz both upstream and downstream datagrams.

Description:
UDP support in Envoy is used in QUIC, edge routing, and proxying within a cluster (UDP to UDP). Envoy indexes client sessions by the 4-tuple consisting of the source and destination IP/port that the datagram is received on and lasts until the idle timeout is reached. The UDP proxy filter emits statistics on the number of datagrams and errors received and transmitted.

The bytes ingested by the UDP proxy are structured UDP datagrams that originate from a raw socket. Datagrams can be sent with a system call sendmsg. Kernels can do path MTU (Maximum Transmission Unit) discovery to a specific target IP address or also use the interface MTU to fragment outgoing UDP packets on the wire. Receive operations occur through recvmsg.

Goals
The target inputs should contain a UDP proxy configuration (or a subset) and a sequence of UDP datagram reads.

The goal is to ensure that the code in UdpListenerImpl::handleReadCallback is robust against errors that may be received by potential datagrams, and cover the possible error conditions and conditional flags detected on the received message (truncated, out-of-band, etc).

Questions
Ideally, the fuzzer should model/generate real datagram packets through a recvmsg system call. However, real system calls can be a potential slow-down in fuzzers, and may require permissions outside of OSS-Fuzz's environment.

Modeling UDP datagrams and covering all possible error conditions, control-related messages, and ancillary data may be hard. Are there smarter tools that can be used to model UDP (and if so, can they also be used beyond a UDP proxy fuzzer)

Links
#14113
#14122

[asraa]

@DavidKorczynski