Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

Ted Lemon <mellon@fugue.com> Wed, 01 August 2018 03:22 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF9130E23 for <dnsop@ietfa.amsl.com>; Tue, 31 Jul 2018 20:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level:
X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 w3sP9b7D_jHd for <dnsop@ietfa.amsl.com>; Tue, 31 Jul 2018 20:22:26 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 ACA56130E0A for <dnsop@ietf.org>; Tue, 31 Jul 2018 20:22:23 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id k16-v6so14878845iom.12 for <dnsop@ietf.org>; Tue, 31 Jul 2018 20:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O1K1TUqSxNs7DuY37+Cm04iDjttB00ryJ6MwU20Nslg=; b=zI8AYyQ1V3bcRVc7difKZDhjnPritKkgb7oh6/cN76Rp8EWrDSQEPccnR7XIa5rYo3 l/+wVTWwKvWYaSs/Pk9WcNQ94Kn8DhzU6/Nfokh8HLvBg+LAYn5CNUj60iHv1Od93b8l uODQHeU/D9Eqhl6xJXob5+7E5S87srQVdu/rNLIKbAeZZCNuZD3qFAJ0zbAKrJbKQ42Z 7rDOhIWc0t1FmN7wTCFDQVVTeBaR4tvF/hR2mgDPhGPzppa3hf2O/EFWB25lpY0ytzxh msK4kHbSW7lwQTaPomnLGqRe2c07EgQyOdGjMoAohK9DQlvwA2VNLQlesrzp9T3QjycA A6Iw==
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=O1K1TUqSxNs7DuY37+Cm04iDjttB00ryJ6MwU20Nslg=; b=Q0QIoJJ2PqF1XRpvVdLYPHPeq7MgynWJrvZc3yr8Q9XlIYLpJe0FaC8Ag6q3RcvpdT dwbY1DAPlxxxEHsfqw3qPbHba0Xaiiz6sqiZaCeQ7f5pVaFxKUv/GxcAJa9+UgNbkGfq v4jT/wA3Vbb6EWUsnAmGCO+HEJuFpBUFacD4HUffMnyUGTqNn7G9nair0TEjiOew4uqQ rDgRC0JSSRzqOBrhh9iN5WGXZmezsCwczQr/rVUFKNfY/HpBztXQPIBEJol3Tp7qHPXa pLxpCjaJ5YPE5qehEGLHvHi0bTvMULrQRCYB/srFyho09SWk1xXQhcvnP8RIR7f94y+I JAAA==
X-Gm-Message-State: AOUpUlE/yvkyfD0UGqq/LDp2DlOHN2qzzu0p34Eax2CtTUH8qPB7EKai YL0uDq5ahLLDdWfiqwyEPGrL8JzTWUc/VLJDVjPQVw==
X-Google-Smtp-Source: AAOMgpeynyVnM5NSvH2hmaJZ5FM3KxemL14AtTb8riyCyO/DqdJboO0HAKGR5k/JyNAdNxT1KbF35idmmb2XuRA8+T4=
X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr1872651ioc.45.1533093743000; Tue, 31 Jul 2018 20:22:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 20:21:42 -0700 (PDT)
In-Reply-To: <CABcZeBO+5Nxv88HW6xVkDtru5DUnCHxeytX1gdRAc4Z3S7K+Jg@mail.gmail.com>
References: <153307610896.3243.16744625445592133652.idtracker@ietfa.amsl.com> <CAPt1N1m_LP2ZcG9yR1DggwRg7KOeuRwTzrsX67iBxkpXekjxUw@mail.gmail.com> <CABcZeBO+5Nxv88HW6xVkDtru5DUnCHxeytX1gdRAc4Z3S7K+Jg@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 31 Jul 2018 23:21:42 -0400
Message-ID: <CAPt1N1=z7bjXT9+xAwupr+gttY-L6d4UnP_01iJeawKAUJGOgg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop WG <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, draft-ietf-dnsop-session-signal@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f58f7905725733ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xPX0uvFP1r59LJAYCs0h3pwT038>
Subject: Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2018 03:22:28 -0000

On Tue, Jul 31, 2018 at 10:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> Yeah, this seems fine. Didn't mean to make you do a lot of work here, just
> noticed as I was reading.
>

No problem, I think your comments on this and some other points that you
probably thought of as asides resulted in significant improvements. :)


> You're doing more than I asked for here (thanks!). I just found myself
> wondering at this point in the spec how this worked and so was looking for
> an overview. But this text is very helpful, so I think it's good to add.
>

I agree.   I think not having this text here would likely result in some
head scratching or unexpected behavior, so it's better to make it explicit.

 S 3.

> >
>>> >      DNS Stateful Operations uses three kinds of message: "DSO request
>>> >      messages", "DSO response messages", and "DSO unacknowledged
>>> >      messages".  A DSO request message elicits a DSO response message.
>>> >      DSO unacknowledged messages are unidirectional messages and do not
>>> >      generate any response.
>>>
>>> This would be useful further up.
>>>
>>
>> Do you mean in the introduction?
>>
>
> Yes.
>

I think this is a tossup, because more text makes the document longer, and
I don't think this adds much value for someone who's actually going to
implement the document.


> We don't expect this to work with DNS-over-QUIC without some restriction
>> like this, hence the text in paragraph 3 of section 5.1.
>>
>
> Sure. I just wanted to point out that that was a consequence of this design
>

OK!

Sorry, has this been changed in a new version?
>

The text you commented on is the new version, with some additional text to
address a point raised in the gen-art review.   We gamed this out pretty
thoroughly—I don't think there's an actual problem here, although I
understand why it looks that way.   The worst case scenario here is that a
middlebox breaks the session signaling, which just looks like "the server
doesn't support session signaling," which is fine.


>
>> S 5.4.
>>> >         generate a response, the application-layer software informs the
>>> >         TCP implementation that it should go ahead and send the TCP ACK
>>> >         and window update immediately, without waiting for the Delayed
>>> ACK
>>> >         timer.  Unfortunately it is not known at this time which (if
>>> any)
>>> >         of the widely-available networking APIs currently include this
>>> >         capability.
>>>
>>> Are you going to make a recommendation here?
>>>
>>
>> Out of scope for DNSOP to update TCP stack APIs.
>>
>
> Sorry, it wasn't clear from context what I was referring to here. You
> discuss a number
> of strategies and then say they are all bad. Do you had a recommendation
> for what
> people ought to do?
>

We don't.   This is text that was heavily touched by Mirja's DISCUSS, so I
suspect that by the time Stuart is done addressing her DISCUSS, this will
have been fixed.   However, I will try to remember to check just to be
sure. :)


> S 6.6.1.2.
>>> >      client a Retry Delay message, or by forcibly aborting the
>>> underlying
>>> >      transport connection) the client SHOULD try to reconnect, to that
>>> >      service instance, or to another suitable service instance, if more
>>> >      than one is available.  If reconnecting to the same service
>>> instance,
>>> >      the client MUST respect the indicated delay, if available, before
>>> >      attempting to reconnect.
>>>
>>> Do you want to recommend some sort of randomness around this value to
>>> avoid avalanche?
>>>
>>
>> The server is specifying the retry delay, so if the client adds
>> randomness, that could result in more collisions rather than fewer.
>>
>
> Sure, if the server actually randomizes it itself. Perhaps that's worth
> recommending?
>

Yeah, I was dragging my feet on this, but inclined the same way.

diff --git a/draft-ietf-dnsop-session-signal.md
b/draft-ietf-dnsop-session-signal.md
index a9037e0..85bc28d 100644
--- a/draft-ietf-dnsop-session-signal.md
+++ b/draft-ietf-dnsop-session-signal.md
@@ -1463,6 +1463,12 @@ are described in {{delay}}.
 After sending a Retry Delay message,
 the server MUST NOT send any further messages on that DSO Session.

+The server MAY randomize retry delays in situations where many retry
delays are sent
+in quick succession, so as to avoid all the clients attempting to
reconnect at once.
+In general, implementations should avoid using the Retry Delay message in
a way that
+would result in many clients reconnecting at the same time, if every
client attempts
+to reconnect at the exact time specified.
+
 Upon receipt of a Retry Delay message from the server,
 the client MUST make note of the reconnect delay for this server,
 and then immediately close the connection gracefully.
@@ -1520,7 +1526,9 @@ or by forcibly aborting the underlying transport
connection)
 the client SHOULD try to reconnect,
 to that service instance, or to another suitable service instance, if more
than one is available.
 If reconnecting to the same service instance, the client MUST respect the
indicated delay,
-if available, before attempting to reconnect.
+if available, before attempting to reconnect.   Clients should not attempt
to randomize the delay;
+the server will randomly jitter the retry delay values it sends to client
if this behavior is
+desired.

 If the service instance will only be out of service for a short
maintenance period,
 it should use a value a little longer that the expected maintenance window.


> Mostly I just missed this. With that said, generally we are discouraging
> compression in cryptographic protocols.
> OTOH, I'm not that worried about the covert-channel either, so it's kind
> of a tossup
>

OK.   I'm going to call it done then, at least until we hear back from
Stuart and Mirja.