Re: Unrecoverable loss pattern
Martin Thomson <martin.thomson@gmail.com> Mon, 26 February 2018 02:07 UTC
Return-Path: <martin.thomson@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 96017127342 for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 18:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 al0BoSjzirAA for <quic@ietfa.amsl.com>; Sun, 25 Feb 2018 18:07:47 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 AE96A127275 for <quic@ietf.org>; Sun, 25 Feb 2018 18:07:47 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id m22so2766373otf.10 for <quic@ietf.org>; Sun, 25 Feb 2018 18:07:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lAm0oN6JolVpyeXe0AIugoleDFFzBolSgW9Oj+2/ELQ=; b=r6D4al14YTkgcsE9ns21/zqR/eLJ2Z1tOt5zPPQy2z7Kfx0bytVoyMPqORdPW2IPOE 45dXzkSftCqxVCs5V4c1xGDOf47QAbKyZ/trsxPxSb+F2Zkz+zYRiRilFNRwg9A9Stm9 BgCD0EsLkaEANxwPP6Xu62VjGicpqoNlisW9ALJRU4HFolsYOTSNE4bvD89uGunGkmYC 5eb1q55evt5bNdT2GFJff8ZKen1DclUX6ym8VWDQb+bpFoWIsWLFhBI9SO3EXHpEZuE5 cBugf7lqgx/cBM7DCpSG2i65sib3wECAbqZufNSiJcBda8qED9sthxhPQ6iVCMPgz3QW wbPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lAm0oN6JolVpyeXe0AIugoleDFFzBolSgW9Oj+2/ELQ=; b=QTBdimNosiWzm5Lk9ALaLQpp393jSMyHGmXaL7SjjMU/JWscUF9kmvsZ54ixCmPTLi bWYX2iZ9vnZmmoOiRR5slf+mG1/72wo6leNcJbfE8H/O+xbvXvU9BuOdIV53V2U8JUSS VcJv1FWy0J29LIQbnzDMPidpqWVLAy6NO9HjLAM5BDA9ClLDVSdKphJWGMP+v8s3RHiP uSDLEmJRX+YdEsrY3rykBurvHmneGebqd3ejZkK+Cpc3FTAnISrr+SltLesJg+065Ruv 4yjUgdWvv55v1+VN3SpLaOoM/PyUt7oziS+iL5knkZh3kOtSZEFJrDrMTNb2arWrr7Dj tCXg==
X-Gm-Message-State: APf1xPCGthMGwdAxDb1BMDU0wb5w0tiJP7F0V916ew2m/RS4gjWcXQPn C87iN0HdjBnwbFvMpt40NgmlZhTI4jVn4NUWjKQ=
X-Google-Smtp-Source: AH8x226SfO78dTaEGrIqvC/cvQB/CoH9VMyOIvc0Ms3vwcFygLWdOe3GbBJiBZcrYRTfUno4xL/sh7/44gZfxNS/Hvw=
X-Received: by 10.157.53.10 with SMTP id o10mr6260609otc.283.1519610866777; Sun, 25 Feb 2018 18:07:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Sun, 25 Feb 2018 18:07:46 -0800 (PST)
In-Reply-To: <CAOYVs2ogy77tjE+e9_mj6YNYcsDP0iduUKsE-_JnMrOeo4jVbQ@mail.gmail.com>
References: <CAOYVs2q1QSpvZjPRfbJmKhhQ6eApwLSSFSbbOBt2J-PAeqVELQ@mail.gmail.com> <CABkgnnWuXJb2_BcfU4N=ODwy5JDZKBBd6TyhFmXLbPgVrvCoEA@mail.gmail.com> <CAOYVs2q0q6YrFfipd7UEENoz2ht2Mr0fPqnvy5pJRz-bPxCJpw@mail.gmail.com> <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> <CAOYVs2ogy77tjE+e9_mj6YNYcsDP0iduUKsE-_JnMrOeo4jVbQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 26 Feb 2018 13:07:46 +1100
Message-ID: <CABkgnnVLdKiaEDdGKjLXB9wNZ8vxvV_ZyJQnLAR4VxsjUDvjyg@mail.gmail.com>
Subject: Re: Unrecoverable loss pattern
To: Marten Seemann <martenseemann@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6jsINyyqONC9UfgTtnKuLG9ZTnQ>
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 02:07:49 -0000
Yes, this is a real issue. It arises because the packet that would normally trigger loss detection for the request packet (the ACK for the Finished) never gets sent because the server believes the client to be quiescent. The server believes that because it discards the cleartext packets that it receives. Client sends ...., Finished, ACK, Y. Then Y is lost. Server acknowledges up to Finished, but this acknowledgment is lost. Client detects loss of the Finished. It does this on a timer, because if the server was sending data, the client would receive the ACK for the Finished and things would work out. If the handshake wasn't special, the client would send Finished again using the 1-RTT keys, and this wouldn't be a problem. But in this case it resends Finished in a new packet and the server throws that away. The client never does TLP or RTO for Y. See <https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.html#rfc.section.3.4.7.4> for that algorithm. The general case is a little worrying: as long as the Finished is outstanding, the client will not repair loss from other packets (see <https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.html#rfc.section.3.4.8>). You might consider this failing to be a result of trying to compose the various timers into a single alarm. This wouldn't be a problem if the RTO and TLP for ordinary packets proceeded as normal. One extra timer during the handshake isn't that much additional burden. But maybe there is a more elegant solution. On Mon, Feb 26, 2018 at 12:30 PM, Marten Seemann <martenseemann@gmail.com> wrote: > The problem is that the server will not open the unencrypted packet > containing the retransmission of the FINISHED, since it already completed > the handshake AND received ACKs for all its handshake packets. We *could* > fix this problem by making the server accept unencrypted packets > indefinitely, but this comes with a whole range of problems of > man-on-the-side attacks. > > On Mon, Feb 26, 2018 at 9:20 AM Christian Huitema <huitema@huitema.net> > wrote: >> >> On 2/25/2018 4:58 PM, Marten Seemann wrote: >> >> @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. >> >> >> See https://github.com/quicwg/base-drafts/issues/829 and >> https://github.com/quicwg/base-drafts/issues/1018 for discussion of related >> issues. >> >> Picoquic manages these issues by handling "ACK of ACK". Normally, it will >> send ACK frames that acknowledge all packets received so far, potentially >> with a long list of ACK ranges. So if an ACK is lost, the next ACK will >> repeat the information that it carried. The list is only pruned when an "ACK >> of ACK" is received. >> >> In your example, if the FINISHED message is not acknowledged, the client >> will retransmit the stream zero data containing the FINISHED message in a >> new Handshake packet. The server will have to send an ACK of that packet, >> and the ACK range will also cover the previous packet. There is no problem >> for sending that ACK. You cannot acknowledge a protected packet in a clear >> text message, but nothing prevents you from acknowledging clear text packets >> in protected messages. >> >> >> -- Christian Huitema
- Unrecoverable loss pattern Marten Seemann
- RE: Unrecoverable loss pattern Nick Banks
- Re: Unrecoverable loss pattern Marten Seemann
- RE: Unrecoverable loss pattern Nick Banks
- Re: Unrecoverable loss pattern Martin Thomson
- Re: Unrecoverable loss pattern Marten Seemann
- Re: Unrecoverable loss pattern Christian Huitema
- Re: Unrecoverable loss pattern Marten Seemann
- Re: Unrecoverable loss pattern Martin Thomson
- Re: Unrecoverable loss pattern Christian Huitema
- Re: Unrecoverable loss pattern Mikkel Fahnøe Jørgensen
- Re: Unrecoverable loss pattern Mikkel Fahnøe Jørgensen
- Re: Unrecoverable loss pattern Martin Thomson
- Re: Unrecoverable loss pattern Christian Huitema
- Re: Unrecoverable loss pattern Ian Swett
- Re: Unrecoverable loss pattern Mikkel Fahnøe Jørgensen
- Re: Unrecoverable loss pattern Martin Thomson
- Re: Unrecoverable loss pattern Martin Thomson
- Re: Unrecoverable loss pattern Ian Swett
- Re: Unrecoverable loss pattern Martin Thomson
- Re: Unrecoverable loss pattern Christian Huitema
- Re: Unrecoverable loss pattern Christian Huitema
- Re: Unrecoverable loss pattern Mikkel Fahnøe Jørgensen
- Re: Unrecoverable loss pattern Ian Swett
- Re: Unrecoverable loss pattern Mikkel Fahnøe Jørgensen