Re: Deadlocking in the transport

Martin Thomson <martin.thomson@gmail.com> Thu, 18 January 2018 23:11 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 5BC95129C6E for <quic@ietfa.amsl.com>; Thu, 18 Jan 2018 15:11:04 -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 UAm1PY020v_Y for <quic@ietfa.amsl.com>; Thu, 18 Jan 2018 15:11:02 -0800 (PST)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 C43E0126C3D for <quic@ietf.org>; Thu, 18 Jan 2018 15:11:01 -0800 (PST)
Received: by mail-ot0-x233.google.com with SMTP id t35so14960783otd.13 for <quic@ietf.org>; Thu, 18 Jan 2018 15:11:01 -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:content-transfer-encoding; bh=TxmbbEMTlcqFScZ5J+Nlp5Zj02IbT1nKoCbakfhZdzQ=; b=ktyObuqpldAHpdK5GTjx34zD6lk/+ij7oe1laSsW7gKA+s/PuW807sM96XeM7NIpXE 7N5gArp/fvWqgTwjZsg26Zm+SOiEhZI1ThLazOgEaSgYLZ1OHR9ocyO2lkk75cd33V35 xadu9CuWtvtji0CaoFxTUJ7e7XJUXfXUN7Vsn9HsLP4W9LY6S3oiBbuyeabqAaR2drq1 YIu9ErTYR4kSOQTubfsDr672jIhI4A3z7UcgCWYy/p03ucHhbh9b9EsBRUm9S95UQwe1 FWnG+45HC2A/miB/RKyyCSK0YSVfirwSDNSiTlehsJaIOI2TPv/dZq9Bo1zwKygbXhIi hr7g==
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:content-transfer-encoding; bh=TxmbbEMTlcqFScZ5J+Nlp5Zj02IbT1nKoCbakfhZdzQ=; b=Z6a0JZUqzdDeyfIkTAS4/J2eaEr9S0cPPdqqPavHGtFV6YhCOiwzqJLRFWWFtg9+Yz syq1Xl33L2AvARvyiRg8XUF0qbyw1GckGROmUCUaQ8gqh89JyIEBHYnKr4cMJHKsNXoi NnIqRVouypJSaUMtlnf4waWKtNCSTXXIY0v8za17TduhkSvSQ+YlBtDPNlbNxkTTdHBS SNIBAdFJJtnxWC6AEZY+u9jBYdJ1vLLsfAR9KL0ebZBNqsMZR4m70uAQlPM6IHRAtOVi VV99Qn81q1/beasSNbIZPoeplb44Z9IFK/y4iYLZJUTVIlPWw8j2l1aRd7BimAk61oEa npwA==
X-Gm-Message-State: AKwxytcx+rTu7EEoYBETgTO+nbP0+zLEWDJB1ymMZMXlN90diP0Uk2Iz p+9liSjXl9LFuvnadELhP6njAEpADJGOhGtM3ys=
X-Google-Smtp-Source: ACJfBouCnzpNXE456TljIG5fB9/HHDMsw4rXrFVpgin/InrIzdCSuG7uTeJ4n6bj+rxACV76W8+kIPRDAx9xR/BVm/s=
X-Received: by 10.157.68.154 with SMTP id v26mr4546151ote.308.1516317060609; Thu, 18 Jan 2018 15:11:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.39.16 with HTTP; Thu, 18 Jan 2018 15:10:59 -0800 (PST)
In-Reply-To: <96c30da5-d7ab-d7cf-32c6-262183232a24@tik.ee.ethz.ch>
References: <CABkgnnUSMYRvYNUwzuJk4TQ28qb-sEHmgXhxpjKOBON43_rWCg@mail.gmail.com> <20180110194716.GA30573@ubuntu-dmitri> <CAGD1bZYiDOakLYNppMBr=99JreX3Xr2zkS7O2DRNfvr_o0NUbg@mail.gmail.com> <20180110200646.GB30573@ubuntu-dmitri> <CAGD1bZa-ZOw5J6oSWBYdk3uYHOpGvak+vwGp0XsZB44zbLvRrw@mail.gmail.com> <20180110202357.GC30573@ubuntu-dmitri> <CAGD1bZbPM3wnatLLN5938wGPo3e1qmxnGzobSTym6XX3W8FNJQ@mail.gmail.com> <CABkgnnU3CQkvd7m+G80sCOPJfzb_=HonbRDSQJC8wqD_uWoj0w@mail.gmail.com> <CAGD1bZbrtMEJE-OOXqG02yWmHy_2baEvaZu=rFCBTtcq94JrOg@mail.gmail.com> <CABkgnnWtmprf291pBgTOrfi6yU9tXSfKi5J5uQpm7Z4JHuiGWg@mail.gmail.com> <EDF23BB9-DA04-44A5-8682-3D22C1DD7380@tik.ee.ethz.ch> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> <CABkgnnU+9u3pqzN7QbowAktxwFwj2XqJDhVyB5h5XOszF1CuXg@mail.gmail.com> <CAGD1bZa7L2OzDjf_FUTsQuxpfkRTjs97tCjZkBg9xVcAKqNfhw@mail.gmail.com> <CAKcm_gN2s2c9Uw86Ppb0yGLHXnahSfLBaWG7VoX31Nvut_hBAA@mail.gmail.com> <CABkgnnW=75JxULpKgjO3K8Ry1E2umDq4icYJS3SqetRSMjamAw@mail.gmail.com> <96c30da5-d7ab-d7cf-32c6-262183232a24@tik.ee.ethz.ch>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 19 Jan 2018 10:10:59 +1100
Message-ID: <CABkgnnUUQTc2nhYo5mHLakq_92F-guPLy8tfE5XKypFvGPg+VA@mail.gmail.com>
Subject: Re: Deadlocking in the transport
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Cc: Ian Swett <ianswett@google.com>, Jana Iyengar <jri@google.com>, QUIC WG <quic@ietf.org>, Roberto Peon <fenix@fb.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zbCIdB2zsRAMR5St_uAWAxJXK8k>
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: Thu, 18 Jan 2018 23:11:04 -0000

Let's be really crisp about what we mean here.

I think that we have used "middlebox" to refer to those things that
are on path, but do not hold keys.

In contrast, this is an issue that affects intermediation by entities
that terminate the security association.  These entities hold keys.
Specifically, this is an issue when those intermediaries only
understand QUIC-the-transport-protocol, and not the thing that is
running atop it.

I separately have a little trouble with the assertion that you might
want to terminate transport on path.  Managing trust there is
basically intractable (ask around for the history of "trusted proxy"
discussions in HTTP if you don't believe me).  Also, that sort of
termination is a large part of why QUIC encrypts.


On Thu, Jan 18, 2018 at 8:29 PM, Mirja Kühlewind
<mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> Hi all,
>
> while I agree that we need to decide which middlebox behavior we want to
> support, I don't really think this is a middlebox issue. If the transport
> you are using is offering you an interface where you can send data over
> independent streams (which was the goal to avoid HOL blocking) but the
> application sends not-independent data over the streams, it is an
> application-layer issue to handle that.
>
> Regarding middlebox behavior, I think we should support transport level
> proxies because especially in mobile networks where the link characteristics
> are quite different from the rest of the network this seems still to be the
> appropriate solution. However, I would wish that we could separate transport
> state from end-to-end payload encryption and would not need to terminate
> both...
>
> Mirja
>
>
>
>
> On 18.01.2018 08:21, Martin Thomson wrote:
>>
>> Yes, what Ian said (and more to what Jana said).  I think that we've
>> some proportion of the working group who are operating on one set of
>> assumptions and another on a different set of assumptions on this
>> subject.  Until now, that didn't bother me much.  After all, that's
>> normal for a whole range of issues.
>>
>> Now there's a concrete problem, so let's dig into this properly.
>>
>> FWIW, I don't think that we'll resolve this particular issue in
>> Melbourne, but I hope that we can at least start that process.  This
>> promises to be interesting.
>>
>> On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett <ianswett@google.com> wrote:
>>>
>>> +1 million
>>>
>>> On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar <jri@google.com> wrote:
>>>>
>>>>
>>>> We will discuss this at the interim, but one comment, inline.
>>>>
>>>>>
>>>>> In part, it's the ignorance of the intermediary that causes this
>>>>> particular problem.  If the intermediary was aware of the protocol
>>>>> details then it might be able to recognize and avoid these situations,
>>>>> but that seems a little too much to expect of intermediaries. Ruling
>>>>> out the entire class of intermediary that operates purely at the
>>>>> transport layer is extremely harsh.
>>>>>
>>>>> What is more likely here is that we describe this situation, explain
>>>>> that it is impossible to prevent in the presence of intermediation,
>>>>> and explain how to kill the right streams in order to ensure forward
>>>>> progress doesn't stall indefinitely.
>>>>
>>>>
>>>>
>>>> Exactly because intermediaries make things difficult, it's important to
>>>> be
>>>> certain that the intermediary behavior we are discussing is one that
>>>> there's
>>>> a strong argument for supporting. We have spent countless cycles on
>>>> designing around uncertain and unknown intermediary behaviors in various
>>>> parts of the IETF, and I don't want us to recreate these boogeymen. I
>>>> think
>>>> it's reasonable to rule out classes of middleboxes if we don't have
>>>> strong
>>>> arguments for supporting them.
>>>>
>>>
>>>
>>
>