Re: [DNSOP] Genart last call review of draft-ietf-dnsop-serve-stale-07

Puneet Sood <puneets@google.com> Wed, 18 September 2019 16:20 UTC

Return-Path: <puneets@google.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 A0356120AD7 for <dnsop@ietfa.amsl.com>; Wed, 18 Sep 2019 09:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 NWP1Si2Inu4m for <dnsop@ietfa.amsl.com>; Wed, 18 Sep 2019 09:20:28 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 D673B120B0B for <dnsop@ietf.org>; Wed, 18 Sep 2019 09:20:25 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id p13so238380vso.0 for <dnsop@ietf.org>; Wed, 18 Sep 2019 09:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s2mmRsr3GXW9HRdo8ZLAP15lpKAm9vA5270QoiQUmoo=; b=ksFduIrfhIueRwnrLOFu0F5s+yiaO0fYynJc1MG3PLKcporuEKHmpj8S9pn9/6glI3 CSaS+JvowDIYJAgXzy6COodp37rHxxz5eMXgF85urxOORF9i+tMu3DlqXPqVct1nCEpY bgVXi7RzcSW5YizXNkt2VKVE2cBt1LHOKLXAL84RKcvW8VOaeE7SUEn3c29U+slGiDZM 2v7vS8hYhxBd/2p+g6a8ErOy+N7LZtnM3gyU8jnTOFjOYb10JBGn77Az4MzP7vl4aNqB 6cEy6AYJbxJf47Zh+qJkzrXIzXV8hoY0kGiWTl1YoZV/r1MQht9yy/IRxn6oXarXpwwO BCHg==
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=s2mmRsr3GXW9HRdo8ZLAP15lpKAm9vA5270QoiQUmoo=; b=Z9CcyGCFJv0LwRr4Fpn8yyl1yYvplbZUOaJL9FbVy40h/V7d7stxXbEZaDokIO8Tcw OLSytUTo2hYFlqZqwcxGcpqP8O+La4F1RE/hZ7AE9XSB7jo/qPWoA4xPzS+uXcNDZ2vw 4dCM+iKQ7Qs0KA4r1ca+1SlPCHbxrv0mF5CxZxHbuja2lF7RvYOZipdoQcYqdSJMAbqD Me+/p1oJyIunc0g+XW/5HtkCiv/xOGm0cVOS7poT/fHfrFvG3jV0Y3bowldUBfR3RLs2 jG00NC7kJ7ca7WFK96rkWzMiaSLIsJTg/tqgYu8FmWdLKBnuUOl43DiWJ6IdmJIVGW6g nOUw==
X-Gm-Message-State: APjAAAXtUfHwAPRJgyc48flxfT+wElIF/0NQvZA1yrlFtVZflhjxw28Y p3b0LpxNaEPU2ijYBrGQuS3SoM9jwujQyqVAUrgYzg==
X-Google-Smtp-Source: APXvYqxRhsn4l3BFApQ0vWtVaX5LoHAromfjufba1n+hw6EO/su3jRFBHCKfYATSWuK9vCzlg8Y298Kf+wz6Nfe9Dzk=
X-Received: by 2002:a67:1043:: with SMTP id 64mr2744983vsq.114.1568823624509; Wed, 18 Sep 2019 09:20:24 -0700 (PDT)
MIME-Version: 1.0
References: <156868709386.28247.6521607966073267680@ietfa.amsl.com>
In-Reply-To: <156868709386.28247.6521607966073267680@ietfa.amsl.com>
From: Puneet Sood <puneets@google.com>
Date: Wed, 18 Sep 2019 12:20:12 -0400
Message-ID: <CA+9_gVvG-5Y5eqnx=yKULr_gCXXzsdgZb4pHvuba5GYtae-ZXQ@mail.gmail.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>
Cc: gen-art@ietf.org, IETF DNSOP WG <dnsop@ietf.org>, draft-ietf-dnsop-serve-stale.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hJe_wMcG52WG9AplfzXw8tkTUF4>
Subject: Re: [DNSOP] Genart last call review of draft-ietf-dnsop-serve-stale-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Sep 2019 16:20:38 -0000

NOTE: Responding to the TTL concerns raised in multiple threads
(thanks Viktor Dukhovni, Tony Finch) here since it seems to cover all
the lists.


On Mon, Sep 16, 2019 at 10:24 PM Brian Carpenter via Datatracker
<noreply@ietf.org>; wrote:
>
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
>
> Gen-ART Last Call review of draft-ietf-dnsop-serve-stale-07
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.
>
> Document: draft-ietf-dnsop-serve-stale-07.txt
> Reviewer: Brian Carpenter
> Review Date: 2019-09-17
> IETF LC End Date: 2019-09-25
> IESG Telechat date:
>
> Summary: Ready with issue
> --------
>
> Major issues:
> -------------
>
> "(It [RFC2181] also has the curious suggestion that a value in the
> range 2147483648 to 4294967295 should be treated as zero.)"
>
> I don't see why that is "curious". That is the range of unsigned
> 32-bit integers that would be negative if treated as signed 32-bit
> integers. And in any case, the statement seems unfair to the authors
> of RFC2181, which actually says this:
>
> "It is
> hereby specified that a TTL value is an unsigned number, with a
> minimum value of 0, and a maximum value of 2147483647... this value
> shall be encoded in the less significant 31 bits..."
>
> It's not a "suggestion"; since the RFC does not use RFC2119 keywords,
> it's a requirement. It's unambiguous, and obviously motivated by
> resilience to coding errors around signed vs unsigned integers. That
> was a legitimate concern in 1997. As best as I can tell, in 1997
> standard C did not include uint32; you needed to use unsigned long int
> and hope it was mapped to 32 bits.
>
> So the current draft overrides this choice made in RFC2181. Since that
> choice had an obvious (but unstated) motivation, how do we know that
> allowing TTLs above 2147483647 will not trigger long-standing coding
> bugs?
>
> There's an alarm bell later in the draft:
>
> "Regarding the TTL to set on stale records in the response,
> historically TTLs of zero seconds have been problematic for some
> implementations, and negative values can't effectively be
> communicated to existing software."
>
> You bet. If the TTL is specified as an unsigned 32 bit integer, and
> stored in a uint32, negative values are impossible. But if the coding
> is sloppy and used long int, "if ttl > 0" could go horribly wrong.
>
> Maybe it's all OK and there is no old resolver code out there with coding
> errors for values above 2147483647. Did the WG discuss this? I think the
> "curious suggestion" text above should be replaced by a brief discussion
> of why RFC2181 made the change that it did, and why it's now safe to
> reverse it.
>
>

The primary concern is around treating TTL values with the high bit
set as positive numbers resulting in really long TTL value either
intentionally (someone added that to a zone configuration) or
unintentionally (e.g. software incorrectly decrementing a zero value
or small positive value). The responses from Tony and Brian clarify
why the wording in RFC 2181 is written the way it is. My co-authors
have more context on the changes for TTL interpretation. I will follow
up and we will come back with a response.

I will also address the editorial comments around the TTL text with tat.

Thanks,
Puneet