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
Roman Danyliw's Transport Comment 3 #4566
Comments
It might not be entirely realistic, in that the person deploying a server might not be aware of unsecure endpoints around them, but it's better to have the caution present than say nothing. |
I think that it is moderately realistic for most deployments. There aren't so many UDP-based protocols out there in common usage. Besides, conducting an audit, if you did not already know, would be healthy. From another angle, a reason to include this is that if you have a firewall, deploy a QUIC server behind that firewall, and don't know what else is behind that firewall, then us writing this text makes it clear where fault lies if something bad happens. |
This is not an editorial issue. I think that it is an excellent question, and definitely the sort of question I would expect the IESG to press on. FWIW, I think that this response would be totally unreasonable if this were TCP instead of UDP, which implies that there is a degree of subjectivity involved in the decision. The working group position suggests no action, but I want to confirm that @rdanyliw is satisfied with that response. As this was only a comment, not DISCUSS, I'm going to assume that this is OK unless I'm told otherwise. |
Would it help to more tightly scope the definition of "networks"? One absurd reading is that QUIC should not be deployed on Internet facing networks because there is not a 0% chance of some unsecured UDP listening host somewhere. |
I think we might be able to say "networks without ingress filtering [BCP38]". Servers are only vulnerable to these attacks if they (or their network) permit source address spoofing. |
WfMq |
This is already something we recommend separately, but this is a SHOULD and the extra is useful. Closes #4566.
I think the addition of BCP 38 makes it much more pointed and realistic. Overall, this is an important cautionary note. We decided that instead of trying to fix this in the protocol, it made sense to force those deploying QUIC to consider the implications of the environment in which they are doing it. |
@rdanyliw could you comment on the proposed resolution? |
Thanks for the refined text. The reference to ingress filtering makes it clearer. Consider this COMMENT resolved. |
Roman Danyliw said:
The text was updated successfully, but these errors were encountered: