dnsproxy icon indicating copy to clipboard operation
dnsproxy copied to clipboard

Published 20 hours ago • verified publisher icon AdguardTeam

Padding of DoQ packets

Open phil-lipp opened this issue 3 years ago • 5 comments

While looking at DoQ traffic captured between the proxy and the AdGuard server, I noticed that the packets are not padded to the same lengths. This is curious, because when I asked the Support team I got an answer saying that padding was implemented and activated by default. Do I, contrary to the statement, have to set a flag in the dnsproxy command or is there something else wrong/padding missing?

my starting command for dnsproxy is: ./dnsproxy -l 127.0.0.1 --quic-port=8853 --tls-crt=example.crt --tls-key=example.key -u quic://dns-unfiltered.adguard.com –output=./log.txt

phil-lipp avatar Jun 24 '21 14:06 phil-lipp

  1. DoQ should rely on QUIC for adding padding: https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-07#section-5.5
  2. In our implementation we simply rely on quic-go library and I honestly don't know if they use PADDING frames or not. Therefore, I'll keep this issue open, until I have some time to look into it.
  3. In order to check that on your own you would probably need to decrypt QUIC packets which is not an easy task. You'll need to decrypt QUIC packets and look for padding frames there. I am not sure if Wireshark supports inspecting QUIC, but if it does, you'll need to patch dnsproxy to export SSH keys and use it to decrypt QUIC in Wireshark. Alternatively, debug dnsproxy and see for yourself if quic-go sends padding frames or not.

ameshkov avatar Jun 29 '21 12:06 ameshkov

Is there any news on that front?

peterthomassen avatar Dec 01 '22 14:12 peterthomassen

Well, quic-go implements padding as it's specified by the RFC9000. This RFC does not state that the packets should be padded to the same length though.

ameshkov avatar Dec 01 '22 16:12 ameshkov

I'm no go expert, so can't fully figure out the state of things. My understanding is that RFC 9000 requires padding only for Initial packets, which quic-go implements.

  • If that is sufficient (which I'm not sure about -- what about non-Initial packets?), can this issue be closed?
  • If that is not sufficient, what then?

peterthomassen avatar Dec 01 '22 17:12 peterthomassen

After reading it one more time I realized that the issue must still be open:

Instead, implementations SHOULD use QUIC PADDING frames to align the packet length to a small set of fixed sizes, aligned with the recommendations of [RFC8467].

quic-go does not allow us to use padding for that purpose so we'll probably need to stick to regular dns padding instead.

ameshkov avatar Dec 01 '22 17:12 ameshkov