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

What does "MUST reduce" mean? #3845

Closed
ekr opened this issue Jul 8, 2020 · 5 comments · Fixed by #3864
Closed

What does "MUST reduce" mean? #3845

ekr opened this issue Jul 8, 2020 · 5 comments · Fixed by #3864
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@ekr
Copy link
Collaborator

ekr commented Jul 8, 2020

An endpoint is allowed to drop the packet protection keys when entering the
closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in
response to any UDP datagram that is received. However, an endpoint without the
packet protection keys cannot identify and discard invalid packets. To avoid
creating an unwitting amplification attack, such endpoints MUST reduce the
frequency with which it sends packets containing a CONNECTION_CLOSE frame. To

This seems like a pretty vague requirement for a 2119 MUST. Like, I could only send it 9999/10000 packets and that would be compliant.

martinthomson added a commit that referenced this issue Jul 8, 2020
We weren't very concrete in saying how endpoints generate packets with
CONNECTION_CLOSE, particularly those that throw away keys.  We have
a rather vague requirement.

In short, follow the same rules we established for the handshake.
Wording this as an aggregate number allows for stochastic reactions and
larger CONNECTION_CLOSE frames.  This way, if you get a 25-byte packet
and respond with a 200-byte packet, you can do that, but you have to
respond to 3 in 8 or fewer in that way.

Note that this limit only applies if the endpoint throws away decryption
keys.  Endpoints with keys aren't blind amplifiers.

Closes #3845.
@martinthomson
Copy link
Member

I think that it would be good to follow the 3x rule here also, but that's a non-editorial change.

@larseggert larseggert added this to Triage in Late Stage Processing via automation Jul 8, 2020
@larseggert larseggert added the design An issue that affects the design of the protocol; resolution requires consensus. label Jul 20, 2020
@project-bot project-bot bot moved this from Triage to Design Issues in Late Stage Processing Jul 20, 2020
@larseggert
Copy link
Member

Do folks agree the PR resolves this?

@ianswett
Copy link
Contributor

I think the PR resolves this and is a sensible choice.

@janaiyengar
Copy link
Contributor

Yup, the PR resolves this.

@larseggert larseggert added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Jul 21, 2020
@project-bot project-bot bot moved this from Design Issues to Consensus Emerging in Late Stage Processing Jul 21, 2020
@larseggert
Copy link
Member

OK, labelling as such.

@larseggert larseggert moved this from Consensus Emerging to Consensus Call issued in Late Stage Processing Jul 22, 2020
@LPardue LPardue added call-issued An issue that the Chairs have issued a Consensus call for. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. design An issue that affects the design of the protocol; resolution requires consensus. labels Jul 24, 2020
@project-bot project-bot bot moved this from Consensus Call issued to Consensus Declared in Late Stage Processing Jul 29, 2020
@LPardue LPardue added design An issue that affects the design of the protocol; resolution requires consensus. and removed call-issued An issue that the Chairs have issued a Consensus call for. labels Jul 29, 2020
@project-bot project-bot bot moved this from Consensus Declared to Design Issues in Late Stage Processing Jul 29, 2020
@LPardue LPardue moved this from Design Issues to Consensus Declared in Late Stage Processing Jul 29, 2020
Late Stage Processing automation moved this from Consensus Declared to Issue Handled Jul 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

6 participants