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

Specify behavior for post-handshake CRYPTO messages #2524

Merged
merged 3 commits into from Apr 23, 2019
Merged

Specify behavior for post-handshake CRYPTO messages #2524

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1638503
Specify behavior for post-handshake CRYPTO messages
nharper Mar 15, 2019
a026012
Change some things to MUST
martinthomson Mar 18, 2019
4645b94
Take suggestion from Jana, improve language for ACKing dropped CRYPTO…
nharper Apr 16, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
30 changes: 30 additions & 0 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1448,6 +1448,32 @@ New transport parameters can be registered according to the rules in
{{iana-transport-parameters}}.


## Cryptographic Message Buffering

Implementations need to maintain a buffer of CRYPTO data received out of order.
Because there is no flow control of CRYPTO frames, an endpoint could
potentially force its peer to buffer an unbounded amount of data.

Implementations MUST support buffering at least 4096 bytes of data received in
CRYPTO frames out of order. Endpoints MAY choose to allow more data to be
buffered during the handshake. A larger limit during the handshake could allow
for larger keys or credentials to be exchanged. An endpoint's buffer size does
not need to remain constant during the life of the connection.

Being unable to buffer CRYPTO frames during the handshake can lead to a
connection failure. If an endpoint's buffer is exceeded during the handshake, it
can expand its buffer temporarily to complete the handshake. If an endpoint
does not expand its buffer, it MUST close the connection with a
CRYPTO_BUFFER_EXCEEDED error code.

Once the handshake completes, if an endpoint is unable to buffer all data in a
CRYPTO frame, it MAY discard that CRYPTO frame and all CRYPTO frames received in
the future, or it MAY close the connection with an CRYPTO_BUFFER_EXCEEDED error
code. Packets containing discarded CRYPTO frames MUST be acknowledged because
the packet has been received and processed by the transport even though the
CRYPTO frame was discarded.


# Address Validation

Address validation is used by QUIC to avoid being used for a traffic
Expand Down Expand Up @@ -5183,6 +5209,10 @@ INVALID_MIGRATION (0xC):
: A peer has migrated to a different network when the endpoint had disabled
migration.

CRYPTO_BUFFER_EXCEEDED (0xD):

: An endpoint has received more data in CRYPTO frames than it can buffer.

CRYPTO_ERROR (0x1XX):

: The cryptographic handshake failed. A range of 256 values is reserved for
Expand Down