Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex

Watson Ladd <watsonbladd@gmail.com> Sat, 25 September 2021 16:22 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C3A3A18D0 for <ntp@ietfa.amsl.com>; Sat, 25 Sep 2021 09:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fb6zEXFPOxBp for <ntp@ietfa.amsl.com>; Sat, 25 Sep 2021 09:22:13 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 0B08A3A18CB for <ntp@ietf.org>; Sat, 25 Sep 2021 09:22:13 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id eg28so49197113edb.1 for <ntp@ietf.org>; Sat, 25 Sep 2021 09:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rhrK13T+r/TI4fEm/3oVlqd30go5pcZhnwFK2xY3xfU=; b=LxRwXqnTaIqMqDywLrfSxfuCOdFgl8QYylGDG+fy9IujHuquRwVfe9BoVwJY8HVRet ug6527RMMy3/jrEE5Xj6x7xVm8EAHRTrmUx7T8aLlXu6/qmMhWqhJt6otsDhZ9YRcDSy 4G8OkByKJDMbjy8OCGCrAPLhzNO4QKTi5ktT6bPaHILubymOMaSrkHGYQ+olB7cjDU9+ AfMfJCvSbUTDvvNfqXxZEYHKLR3dxm8X7Cn7MfFDHd0hzpCjUv2JpUXvOThW9tgC6kBj uTmXXUVjVB0bEH8rIN6XEd/y2rhgHY7tR6Fn/CUYEh2qWQOGi9odoIApTV/rekRYfRlC 2dTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rhrK13T+r/TI4fEm/3oVlqd30go5pcZhnwFK2xY3xfU=; b=xDMXTIDtlIgWeXWBjS9TVxO0QoJEanmN/5lI8NZOID0YQ/cb6VwBkEEEkDQ/vynNjP NwH1PsaxXAgDL4M5roKN8rwlJGpjAfqKwRbYDHLfnAL2Fd5vHVdHGRcZky3cnyWde427 yRTP6aC8xMjKoSN3cJAeKZm/xyM6KnAiDSBkVzQKFMeYCTNP+MKG0B0P2pxb2wcCn5yu raska7Pr5c3H2TGW5QtX+O52P8eAn8Bdy9HYJ9NkDbjiLk94aJs5DbYWBN7vMLIi8UAW DpFbqz0QJLbjX4KT0FI8p24fx2zJnrutTzW4fUl4nE5o/DjmtLRchtHFEgYsyYN1Q/GG AKfw==
X-Gm-Message-State: AOAM532zU/REChYos+pxvuTJGuU4qBIIttvpy/baizI58HaD7/hPap/T zQ1h+5rM8nUXmeYqhla3dLm1kgS9OZTiTNWdTN4=
X-Google-Smtp-Source: ABdhPJzTvidnsYK3jGMmyCtcnPnPrK3vOZ3RpkrSrXhnDtsh6QQu1md2OrJlcsEik2CgI1GD/Iq1/ZWntGTwAYi66tg=
X-Received: by 2002:a50:9dcf:: with SMTP id l15mr11812632edk.137.1632586931130; Sat, 25 Sep 2021 09:22:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAGZkp1-ZCuSvMyQyWCnE511O8-WL=OXfsTdraKsByMmWC3spVA@mail.gmail.com> <CACsn0ckZmR=k2NAmdyhVOA=V_XQ18AnBUBSTOu+bDXS1YsPpUg@mail.gmail.com> <CAGZkp18eASaF7qvubYpDgzvg643ZXuPwDs9qsiC1P_AVLcywLA@mail.gmail.com> <CACsn0cnjHFwxHT13nMavRFzRteWJ=SORY8v4RCZjdjYP0H3oaw@mail.gmail.com> <7dde7eb3-4dc7-94d3-e63a-6d5d0736b1c2@pdmconsulting.net> <54baf1fa-b138-4eb8-6f4e-99168cf2db7b@dansarie.se> <0a95d35f-f708-4a3c-4ecf-77597c42a7a4@pdmconsulting.net>
In-Reply-To: <0a95d35f-f708-4a3c-4ecf-77597c42a7a4@pdmconsulting.net>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 25 Sep 2021 09:21:59 -0700
Message-ID: <CACsn0c=gdQWDumfzeHYYWzXPV4sz4J9mTUtYW+4=KueaHHbGdQ@mail.gmail.com>
To: Danny Mayer <mayer@pdmconsulting.net>
Cc: Marcus Dansarie <marcus@dansarie.se>, NTP WG <ntp@ietf.org>, JP Sugarbroad <taralx@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/PK8ZqRO6qQsDtW6B75oxCxcX-BE>
Subject: Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Sep 2021 16:22:19 -0000

On Wed, Sep 22, 2021, 8:00 AM Danny Mayer <mayer@pdmconsulting.net> wrote:
>
>
> On 9/21/21 3:24 PM, Marcus Dansarie wrote:
> > I'll hijack this thread in an attempt to answer a number of related
> > Roughtime questions in the same place. Apologies in advance for that.
> >
> > On 2021-09-21 16:27, Danny Mayer wrote:
> >> It would be helpful if you explained why you changed it in the first
> >> place. I assume you had a good reason to do so.
> > I was the one to initially suggest terminating the PAD tag with zeros
> > instead of ones (0xff) back in 2019:
> >
> >> The PAD tag key is encoded as PAD\xff, while the SIG tag key is
> >> encoded as SIG\x00. For consistency, this should be changed so that
> >> both are terminated with \x00. Additionally, terminating the tag keys
> >> with the NULL character will make displaying them easier on many
> >> platforms.
> > In short, terminating all "ASCII-style" tags shorter than four
> > characters with zeros allows for unambiguous translation into 32-bit
> > integer tags. The entire message is archived at:
> > https://mailarchive.ietf.org/arch/msg/ntp/BSYmaFGoEYHNECg2Mc2qgjzQZh4/
>
> It would make more sense to make all of the tags 4 ascii characters and
> be done with it. I also don't understand the need for PAD and that the
> message has to be at least 1024 bytes in length. The length of the
> message is included in the packet so such a requirement is unnecessary.

NUL is an ASCII character :-P.

Padding is necessary to ensure that servers never send back replies
bigger than responses. The minimum length is to ensure that most
responses will fit. Why we do it in the message and not the packet is
partially historical: Marcus and I will at some point revisit this
along with some other choices.

Sincerely,
Watson