Re: Unrecoverable loss pattern

Marten Seemann <martenseemann@gmail.com> Mon, 26 February 2018 00:58 UTC

Return-Path: <martenseemann@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D17127337 for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 16:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlLjmLsM2OsG for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 16:58:57 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8AC127275 for <quic@ietf.org>; Sun, 25 Feb 2018 16:58:57 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id n48so9437761uae.13 for <quic@ietf.org>; Sun, 25 Feb 2018 16:58:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hVv/jm7o0BTqQhQdDiQ/INVhUyFsv8m5m9nkAckF8sU=; b=bHohZH2AfFSJUqQNhcR6Ecsb8EhWJ2h3dQOJ0wj9QFCsk9/wPIR1AKZ+lb4bvb1Asi MTxLCyIY2ItJt7EW9gHpEBTF0Tuz6cFVv+DYv40lAHhv87n5xjyNtfchwTXE2V+PPyge X5Aq4E5t5miWGKk6Vc7r3ctVsH+xTkx5K3lop3j+AuPiQCsXypwM0aoXnTJbsQreDerl Avn94EchcMaMOSqBKo0+QS0xQgv8qxZedxlOpnDNBByfzwLr4hfZ2OhfwQTmSOYK1pIJ 0u4oBvIqblhVr4ktV1zo9O3rYDnz0iV/6EVLv0+H7udbMjyo60POfIZsZDw52vLBWcFj qLDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hVv/jm7o0BTqQhQdDiQ/INVhUyFsv8m5m9nkAckF8sU=; b=aWgRU1UMxOd40L6pyGbGSPtr0S60ZoDyq7E/YhooCAOftUo+xJDZ2w9CTCYTiAkReg jV2zNlTUXipIvAzzcIcHwRPklNY43Pfs4pqDYp25b/NeKygxMMXdK/OfxMILrByXQxIQ Cm1LA1kWuLLBDj0Hbc6vAYtQbpqRPORJqKV1nO54tu01Du3th2F2JQ8RX8+AQkpRmNQd gFaD28wSxnLRYhQC2DLkkLK1E9HCCVc0mqkQmt81L6oKCCKRF9Rpen7yUT0yaezsVwmT kMoiYqvvXFNVvAV8D9hxfglQt0scnhhAgazdLrfxh1r33Ydn1f/Me0AH23nyvabMFhbU itdg==
X-Gm-Message-State: APf1xPAmoDEVGHOFE/BfIIMaFOaz42O7/RNj1InnZYPFhVc4oSHKBXiz igV6tgP3q7SIJpBmm/IAdODqvoRD3BAmPUoBd04=
X-Google-Smtp-Source: AG47ELsyrG8nzXO7pj3Rco7SfaGO85S6rJ7wCc4gqNI3s+ia/u3WDT3MQSFOOw1mT6LFs4dqGedjfu8Wfqmv31y2+KE=
X-Received: by 10.176.23.238 with SMTP id p46mr7027434uaf.134.1519606735832; Sun, 25 Feb 2018 16:58:55 -0800 (PST)
MIME-Version: 1.0
References: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com> <CABkgnnWuXJb2_BcfU4N=ODwy5JDZKBBd6TyhFmXLbPgVrvCoEA@mail.gmail.com>
In-Reply-To: <CABkgnnWuXJb2_BcfU4N=ODwy5JDZKBBd6TyhFmXLbPgVrvCoEA@mail.gmail.com>
From: Marten Seemann <martenseemann@gmail.com>
Date: Mon, 26 Feb 2018 00:58:45 +0000
Message-ID: <CAOYVs2q0q6YrFfipd7UEENoz2ht2Mr0fPqnvy5pJRz-bPxCJpw@mail.gmail.com>
Subject: Re: Unrecoverable loss pattern
To: Martin Thomson <martin.thomson@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f403043c6cb8b00ce205661303cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8cUO5Q6N7LfhhHtogg51Drhp1YM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2018 00:58:59 -0000

@Nick: The server did get all handshake packets, please see 1. in my
description. It's the server's ACK for the FINISHED message that is lost,
not the FINISHED message itself.
@Martin: Yes, it is, but I don't think there's anything problematic about
the language in this paragraph. Since the server received ACKs for all the
handshake messages it sent, it makes sense to not open unencrypted packets
any more.

On Mon, Feb 26, 2018 at 6:47 AM Martin Thomson <martin.thomson@gmail.com>;
wrote:

> I assume that this is the language you refer to:
>
>    A server MUST process ACK frames in unprotected packets
>    until the TLS handshake is reported as complete, or it receives an
>    ACK frame in a protected packet that acknowledges all of its
>    handshake messages.
>
> That talks about ACK frames, not Finished.
>
> On Mon, Feb 26, 2018 at 1:25 AM, Marten Seemann <martenseemann@gmail.com>;
> wrote:
> > I’ve been playing around with QUIC loss recovery and in my tests I’m
> > encountering one specific loss pattern which it seems impossible to
> recover
> > from. It's pretty rare, because there are a couple of conditions that
> must
> > be fulfilled for it to occur:
> >
> > 1. Client and server perform the handshake, no packets are lost so far.
> > Client and server both arrive at the CONNECTED state, and the server
> > receives all ACKs for handshake packets it sent. The client receives ACKs
> > for all handshake packets except for the one containing the FINISHED
> message
> > is lost (the packet containing the ACK for the FINISHED is lost).
> > 2. The client starts using 1-RTT keys, and it sends two packets: First, a
> > packet only containing an ACK, and then a packet containing stream data
> > (e.g. a request). The request packet is then lost.
> > 3. The server receives the ACK in the 1-RTT packet, and it stops
> accepting
> > unencrypted packets according to 6.1.2 of the TLS draft. It doesn’t
> generate
> > an ACK in response, since the packet only contained an ACK.
> > 4. The client is now missing acknowledgements for two packets: the
> > (unencrypted) packet containing the FINISHED message, and the (1-RTT)
> packet
> > containing the request. It runs its loss recovery algorithm
> > (OnLossDetectionAlarm), and since there is one outstanding handshake
> packet,
> > it retransmit all outstanding handshake packets.
> >
> > Now we’ve run into a situation we can’t recover from: The server won’t
> even
> > open packet sent as a retransmission (since these packets are
> unencrypted,
> > and arrive after it already received a 1-RTT packet), and the client will
> > never retransmit the request packet. Furthermore, the server won't send
> any
> > other packets, since it's just waiting for a request from the client.
> >
> > I think the solution for this is to also retransmit 1-RTT packets in a
> case
> > like this. Can we just apply the normal retransmission rules in
> > OnLossDetectionAlarm, even if there are still handshake packets
> outstanding?
> >
> >
>