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.

Sign up for GitHub

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

Jump to bottom

allow dropping of Initial packets with invalid reserved bits #2053

Closed
wants to merge 1 commit into from
Closed

allow dropping of Initial packets with invalid reserved bits #2053

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3278,9 +3278,10 @@ Reserved Bits (R):

: The next two bits (those with a mask of 0x0c) of byte 0 are reserved. These
bits are protected using header protection (see Section 5.4 of {{QUIC-TLS}}).
The value included prior to protection MUST be set to 0. An endpoint MUST
treat receipt of a packet that has a non-zero value for these bits after
removing protection as a connection error of type PROTOCOL_VIOLATION.
The value included prior to protection MUST be set to 0. For Handshake and
0-RTT packets and endpoint MUST treat a non-zero value after removing
protection as a connection error of type PROTOCOL_VIOLATION. For Initial
packets, and endpoint MAY instead choose to drop the packet.
Copy link
Member

@kazuho kazuho Nov 30, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about stating that, for Initial packets:

  • an endpoint MUST ignore CRYPTO frames once it obtains Handshake keys
  • an endpoint MUST ignore CONNECTION_CLOSE frames once it receives a Handshake packet
  • an endpoint MUST ignore unexpected packet numbers found in an ACK frame

I think these three requirements are sufficient to address the attacks that happen after 1 RTT. And I think they are necessary for #2076 to work effectively.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the end, this might be simpler. You can ignore the content of Initial packets entirely, with the exception of ACK, which you only use to drive retransmission of your own Initial packets.


Packet Number Length (P):

Expand Down