Ask people not to drop new versions?

[martinduke]

The VN section suggests that observers not use the version number to detect QUIC.

Would it be futile to ask them to admit QUIC versions they don't recognize rather than drop them?

[martinthomson]

Probably.

[mirjak]

Not sure. Depends on the function you implement. I guess there could be security functions that decide to only allow certain versions... not sure if that is justified but I don't think we can stop it.

[mirjak]

Any further opinions here?

[martinduke]

We can stop it with greasing, I guess. IMO the draft should specify best practices that don't break extensibility and if people don't follow it it's on them. That's the approach I took in QUIC-LB.

[mirjak]

The best practice is to not block any unknown traffic as blocking hinders evolution. However, I guess there might be security reasons why some will not do that. I guess allowing for certain versions of QUIC is better than blocking UDP entirely...?

[britram]

+1... I don't think that putting text in this document saying "don't wholesale block versions of QUIC you don't understand" will actually change the behavior of the boxes that will ship this behavior, since drop-unknown is taken as a security best practice. But I still think it's worth putting that advice in the document nonetheless, if only to have "I told you so" in an RFC.

(I do still tend to think that we'll see only two behaviors emerge in the wild: (1) permit anything with a QUIC wire image since there's not much to grab on to there (and rely on the LB implementation to eat DoS hiding behind that wire image) and (2) block anything that smells like QUIC (because it is easy to implement in the default case and it forces fallback to TCP, which already has lots of running security monitoring code).)

[britram]

will work up a PR for us to discuss