[quicwg/base-drafts] Handshake Flow Control can result in hung connections (#1764)

martinduke <notifications@github.com> Tue, 18 September 2018 15:10 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9916812D7F8 for <quic-issues@ietfa.amsl.com>; Tue, 18 Sep 2018 08:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Xcfr_-qxkWbY for <quic-issues@ietfa.amsl.com>; Tue, 18 Sep 2018 08:10:18 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54B5130E4D for <quic-issues@ietf.org>; Tue, 18 Sep 2018 08:10:17 -0700 (PDT)
Date: Tue, 18 Sep 2018 08:10:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1537283416; bh=lcs2H6tSdrgt1SgDIdL3eUiZuEW0FOMoT8HV39lXEbQ=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=X+jEfFDF2Gl2um9H4t8pWMtezDqJCwDpzxVntPxiAs9DCzt2FeZsdJ5DIGoDV1LPb f7SKEwGg/fCPvlqJmoXWm1/ZHAs43Jo5QRX1BB9HJhVZRQnpMzd2dBLepuDOmLeS4q RuIA4y4lF2XBNCznYDC0EY3/at16wGv8hjvCOAnM=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab16207c2055a572de71c3cd63cfec79ac1be1974892cf0000000117b8d75892a169ce1589cd31@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1764@github.com>
Subject: [quicwg/base-drafts] Handshake Flow Control can result in hung connections (#1764)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ba11558b6db3_587e3fc8574d45b8166954"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/cIxVM4za-Lc_UYeWE4lzZy9mIew>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 15:10:21 -0000

Section 4.7 of the handshake draft states:

>    Servers MUST NOT send more than three datagrams including Initial and
>    Handshake packets without receiving a packet from a verified source
>    address.  Source addresses can be verified through an address
>    validation token (delivered via a Retry packet or a NEW_TOKEN frame)
>    or by receiving any message from the client encrypted using the
>    Handshake keys.

As written, there are two scenarios where no one can transmit. If the client successfully sends the initial ACK to the server, and *either* the server's handshake flight or the client's handshake acks are lost, then (1) the client has nothing to do, and (2) the server does not have the flow control credit to retransmit the lost packets.

It would be nice to minimize the resource and amplification implications for the server. Ekr proposed the following conditions that apply when the path has not been verified:
1) The client initial must be padded to 1200 bytes, as today.
2) The client must retransmit its initial until it has a Handshake Crypto frame to send (i.e. it has received the entire server's first flight.)
3) Until the server gets an hs pkt (the path has been verified), it only retransmits in response to the Client Initial; this response is all server packets that have not been acked. With no retransmissions, the server will need to have some kind of timer to clean up the state if the connection is dead.

There are many other ways to solve this problem; this is an example.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: