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

Roman Danyliw's Transport Comment 3 #4566

Closed
LPardue opened this issue Jan 6, 2021 · 9 comments · Fixed by #4733
Closed

Roman Danyliw's Transport Comment 3 #4566

LPardue opened this issue Jan 6, 2021 · 9 comments · Fixed by #4733
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus. iesg An issue raised during IESG review.

Comments

@LPardue
Copy link
Member

LPardue commented Jan 6, 2021

Roman Danyliw said:

** Section 21.5. Per “QUIC servers SHOULD NOT be deployed in networks that
also have inadequately secured UDP endpoints”, I was wondering if this caution
is a realistic.

@LPardue LPardue added -transport iesg An issue raised during IESG review. labels Jan 6, 2021
@LPardue LPardue added this to the transport-iesg milestone Jan 6, 2021
@MikeBishop
Copy link
Contributor

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.

@martinthomson
Copy link
Member

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.

@larseggert larseggert added this to Triage in Late Stage Processing via automation Jan 11, 2021
@martinthomson
Copy link
Member

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.

@LPardue
Copy link
Member Author

LPardue commented Jan 12, 2021

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.

@martinthomson
Copy link
Member

martinthomson commented Jan 12, 2021

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.

@LPardue
Copy link
Member Author

LPardue commented Jan 12, 2021

WfMq

martinthomson added a commit that referenced this issue Jan 12, 2021
This is already something we recommend separately, but this is a SHOULD
and the extra is useful.

Closes #4566.
@janaiyengar
Copy link
Contributor

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.

@larseggert
Copy link
Member

@rdanyliw could you comment on the proposed resolution?

@larseggert larseggert added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Jan 12, 2021
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Jan 12, 2021
@rdanyliw
Copy link

Thanks for the refined text. The reference to ingress filtering makes it clearer. Consider this COMMENT resolved.

Late Stage Processing automation moved this from Editorial Issues to Issue Handled Jan 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus. iesg An issue raised during IESG review.
Projects
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

6 participants