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

Watson Ladd <> Tue, 21 September 2021 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7DF33A20DE for <>; Mon, 20 Sep 2021 21:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X2mRcj2lODpF for <>; Mon, 20 Sep 2021 21:45:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D1943A20DD for <>; Mon, 20 Sep 2021 21:45:56 -0700 (PDT)
Received: by with SMTP id v24so69505846eda.3 for <>; Mon, 20 Sep 2021 21:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KMM2avfpA33aP36mj7SSxbDTPhQjj/PcS9OHbAZkbOA=; b=VtEnNzsANOp14KFLkITrdVRddddlDzaHmIyyr4K0o8wEAVydgiqHDtw9uiXkG9n1nP e8kPyVWwRPhKF0oHQpRfEApYe90+6f+BvHCHgzMmNctkQcVzhHP1WkKv6Ru2nEFMbvTI 2m+Y2wAj0dSYNk25C4CSIZmZroujCtJ/t0I0V2Pmvl+s7ooFfrx0Q9xnKyNCbLLVNYG5 yyK139RXLeuK10ah1zRiDz4dPZE5E4OZDKOTzbw1tGjkH2kV/SE2w6NZnZbvLm8xOe63 qBMzDFgLRNyCjKOh1saWedMJmALsFIOmp1NXlGSACaGSfs6kzkC2FbwhebkrGqwG26RA 8WBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KMM2avfpA33aP36mj7SSxbDTPhQjj/PcS9OHbAZkbOA=; b=YPLjRBM8LpMMUPs8VsX8BdIyy2j19TPvZ+M4fdmzABu8CBcV5GSNjdA0F6XSyg8JPF ++fAXLXDXsmABI0soXDZr7wII3jij8xxWHYy3y4FKPoK/7FrpZZoa60CRWu/cXOp1clH 8TeYjTf3qGRVmIGDP5n1OtNadIkCRVELnKognOIQuMHkufQDO9x6F+AM7RII++d7DzG5 OrHgCS1xklFjwKa58KhgFVmV/bJxqoDGDckUiwPQnRTXcpQPeK63ZGzdilEHq0KeYDYc 622BsoAxJUFYvHyVEx9mEfx1OGDoU2x7xpHug9/XnI2T4wQ5qCeJzkv0fVxat/Z58tvy T01g==
X-Gm-Message-State: AOAM530rXqFopWtE7WfOQ2imFc0FrXei4EoBgDW9bHlY/HzDjdh5WJMl gbRPAPbDDC5BVbgODWKhLylNTN4hlesM0Q4KFZ4=
X-Google-Smtp-Source: ABdhPJzfNEgdFIY0Z33l1k+jeWfGA6M3n5cbaHOXFq4WOV+fgEdd6GRxUnf+6xvhRKk3fSuQsEyYg+mkXmWTvwLosbE=
X-Received: by 2002:a17:906:f906:: with SMTP id lc6mr31743334ejb.487.1632199554544; Mon, 20 Sep 2021 21:45:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Mon, 20 Sep 2021 21:45:43 -0700
Message-ID: <>
To: JP Sugarbroad <>
Cc: NTP WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Sep 2021 04:46:00 -0000

On Mon, Sep 20, 2021 at 9:07 PM JP Sugarbroad <> wrote:
> On Mon, Sep 20, 2021, 20:43 Watson Ladd <> wrote:
> Could you perhaps say more about why this is a barrier to your
> implementation? It's easy enough for my coauthor and I to change them
> back, but we'd like to know why.
> I hear you on the other short tags, so I guess my request is to allow the padding tag to be last. (FWIW the way the tags sort feels weird.)
> The shape of a packet before was:
> 2, 32, "NONC", "PAD\xFF", random, padding
> Notably, the size of the padding doesn't have to be calculated and is at the end. So one can allocate a zeroed buffer, write mostly fixed data to the start of it, and then send.
> In the new version:
> "ROUGHTIM", len, 3, padlen, padlen+4, "PAD\0", "VER\0", "NONC", padding, x80000005, random
> This version has padding in the middle, and the lengths are all dependent on the length of the packet.
> If padding were at the end:
> "ROUGHTIM", len, 3, 4, 36, "VER\0", "NONC", "PAD\xFF", x80000005, random, padding
> Back to mostly static values. It's a small thing, but I'm on an embedded platform and these things can matter...

You can still do the construction in a mostly static way. You know the
total length of the buffer ahead of time: that's what's the padding
for. So fill up the buffer with all the other data. Then you know the
padding length, and can copy that segment of the buffer backwards to
make room for the padding.


> - JP

Astra mortemque praestare gradatim