Refactor port_default_packet_handler to allow for AEAD validation before we have a channel

[nhorman]

Current, we do some amount of header parsing in port_default_packet_handler, for things like version negotiation and server address validation. But these checks occur before we have done AEAD validation on a packet, meaning we are somewhat susceptible to corruption of the header data, and may accept invalid values from a peer. Currently we are mitigating this through various checks and indpependent validations (i.e. checking the token-encoded dcid against the header dcid).

A better solution would be to refactor when we do AEAD validation to ensure that the packet has some level of integrity. This is a significant work effort however, and so should be undertaken post 3.5

I believe @Sashan has some ideas on how to accomplish this

[Sashan]

I think we need to go for it. We need to verify integrity of QUIC header before the packet is passed to channel. The integrity check must happen in port.

[Sashan]

My branch here provides a summary of my effort and investigation done so far. My idea was to move OSSL_QRX object from channel to port/demix (QUIC_PORT/QUIC_DEMUX) so we could parse QUIC header earlier (before packet reaches the channel). I failed to figure out a convenient way how to deal with packets that are on encryption levels other than initial.

My fallback plan is to change logic in port_default_packet_handler() to something like this:

• parse UDP datagram enough so we can determine encryption level
• for initial encryption level verify integrity of packet, drop packet if it can not be verified
• if packet is in other than encryption level find a channel for it, drop packet if no channel is found
• now we are in situation where we
  • either have a packet which we have a channel for, then just inject the packet to channel
  • or it is initial packet which pass integrity check, so we can continue with business as usual (send retry or create a channel for it and pass the packet to newly created channel).