From ea331de08754682d835b2245920f647a81a0be67 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 18:18:05 -0400 Subject: [PATCH] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 360325e28c..c67c51e67c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -882,11 +882,11 @@ a NEW_TOKEN frame) or by processing any message from the client encrypted using the Handshake keys. This limit exists to mitigate amplification attacks. In order to prevent this limit causing a handshake deadlock, the client SHOULD -send a packet as large as the Initial containing only PADDING if it has no -other data to send and does not yet have the Handshake keys. If the client -has no data to send and the Handshake keys are available, it SHOULD send a -packet with a single byte of padding. Details on when to send these PADDING -packets are in {{QUIC-RECOVERY}}. +always send a packet upon a handshake timeout, as described in +{{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have +Handshake keys, it should send a packet as large as the Initial containing +only PADDING. If the client has Handshake keys, it SHOULD send a packet +containing only PADDING. The payload of this packet contains CRYPTO frames and could contain PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE