4 ms·

Since address validation is about blocking senders which forge their IP address, I think the number of connection attempts which where the client doesn't eventu

Since address validation is about blocking senders which forge their IP address, I think the number of connection attempts which where the client doesn't eventually validate its address should factor into the decision to enable this feature. This should rarely happen for legitimate clients (e.g. connection loss/cancellation during the first roundtrip) but always happen for IP address forgers. Or perhaps simply use the number of half-open/embryonic connections as the metric.

mholt 4y ago
Good point. Our current metric (number of active requests) is a bit naive, but mostly does the job essentially for free. If your proposed metric doesn't cost too much in memory, it might be a good fit.
- CodesInChaos 4y ago
  How does such an attacker influence your active requests metric? Is it incremented when the initial UDP packet arrives (even though the http request itself hasn't arrived yet) and decremented when it times out?
  - mholt 4y ago
    No, currently we increment it when the HTTP request is parsed. (It counts HTTP requests, not packets/connections.) This was a quick and easy way to count; but I am very open to improving this! Feel free to submit a proposal or a PR. Ref: https://github.com/caddyserver/caddy/blob/50748e19c34fc90882bbb268c95a2a0acb051752/modules/caddyhttp/server.go#L185-L186 https://github.com/caddyserver/caddy/blob/50748e19c34fc90882...
    - CodesInChaos 4y ago
      In that case, I don't think your metric works at all, since legitimate users will increase it, but attackers won't. During an attack it will either remain the same, or even go down as fewer legitimate users manage to connect. This attack is the QUIC equivalent of a SYN flood, which results in half-open connections, because the attacker is unable to complete the connection by responding to message the server sends. RequireAddressValidation corresponds enabling syn cookies. Unfortunately I don't use caddy myself, and don't have time to get involved deeper in improving this.
      - mholt 4y ago
        I opened an issue with quic-go to get ideas for a better metric: https://github.com/lucas-clemente/quic-go/issues/3549 https://github.com/lucas-clemente/quic-go/issues/3549

mholt 4y ago

Good point. Our current metric (number of active requests) is a bit naive, but mostly does the job essentially for free. If your proposed metric doesn't cost too much in memory, it might be a good fit.

CodesInChaos 4y ago
How does such an attacker influence your active requests metric? Is it incremented when the initial UDP packet arrives (even though the http request itself hasn't arrived yet) and decremented when it times out?
- mholt 4y ago
  No, currently we increment it when the HTTP request is parsed. (It counts HTTP requests, not packets/connections.) This was a quick and easy way to count; but I am very open to improving this! Feel free to submit a proposal or a PR. Ref: https://github.com/caddyserver/caddy/blob/50748e19c34fc90882bbb268c95a2a0acb051752/modules/caddyhttp/server.go#L185-L186 https://github.com/caddyserver/caddy/blob/50748e19c34fc90882...
  - CodesInChaos 4y ago
    In that case, I don't think your metric works at all, since legitimate users will increase it, but attackers won't. During an attack it will either remain the same, or even go down as fewer legitimate users manage to connect. This attack is the QUIC equivalent of a SYN flood, which results in half-open connections, because the attacker is unable to complete the connection by responding to message the server sends. RequireAddressValidation corresponds enabling syn cookies. Unfortunately I don't use caddy myself, and don't have time to get involved deeper in improving this.
    - mholt 4y ago
      I opened an issue with quic-go to get ideas for a better metric: https://github.com/lucas-clemente/quic-go/issues/3549 https://github.com/lucas-clemente/quic-go/issues/3549