Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Tracked by #878
nhorman opened this issue Nov 26, 2024 · 3 comments
Assignees
Milestone

Comments

@nhorman
Copy link
Contributor

nhorman commented Nov 26, 2024

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
Copy link

Sashan commented Dec 9, 2024

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
Copy link

Sashan commented Jan 17, 2025

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).

@t8m
Copy link
Member

t8m commented Jan 17, 2025

  • 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).

That's a good plan, IMO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: New
Status: Refining
Development

No branches or pull requests

4 participants