Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Dieter Sibold <> Mon, 08 March 2021 12:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 624AA3A0D03 for <>; Mon, 8 Mar 2021 04:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uM3zQqwrCPMQ for <>; Mon, 8 Mar 2021 04:13:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D60813A0D01 for <>; Mon, 8 Mar 2021 04:13:01 -0800 (PST)
Received: by with SMTP id mm21so19817454ejb.12 for <>; Mon, 08 Mar 2021 04:13:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=yeiDhR8HQbKt2i71cPMGDGenkbHJn+1J+teDgcXkkL4=; b=DtCBD/aKC5zVY80jfwE+PyeJd/sypeEovZhq1HwOSLDegnVHUBbYLi5IValmu8hioA Sj5AIZM5rLBA0jq5vabkSc6iN7RGfz7a4OIeE2txF7RjxrtjSdO4CziTcKIzDpxjrZ2a PkmoGGBUm/kBN6QNSIV5AQnEHb2TFou3Y2BD333P79jUQgNc87h4rRfbtJDD38xfbnRs OH7cULGBlaH1F71dqolsz5QB1Hk6WG2hwbUyN4BuiAryejPeo9Uhwfkhc+9H1PHHnwgZ knoVhzvqI1rHdod4RcDFfyUJKntp//k4Jl8b29K105AnA3pUkJHqHlqRTEVZ7bHtO5q0 1rvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=yeiDhR8HQbKt2i71cPMGDGenkbHJn+1J+teDgcXkkL4=; b=Se3OHNmXk9hvRAafgnaSTQPlAPZugTPIuENPSboYOiodd0KHZFl1C8gzVga33/wt2w zDehTbgp47b9D3Zs4cxpj6s+uy8rHdIL24bJCbaTzAjWLD0LXy+SRk6yu7lk6YBW2fYZ EkWYwyM3l6asIAjub60KBT2l6rHemLHRYI2Gqx3QitHg0vFbtYu09MmQhsO9MzjNpESa hlSekEfWbGMFtDwjz6es2oCiEdYJ9ls5O4VlVy/sZ1Hp67+n/iG40ZkjYyMTnK8kCu20 t1HWCPagkAS8kb7O7W7VOJpqv0OrnjQUOJKLnSG2/dvwyvgI7IJ0TviddU5bEjjvMm2L G6uQ==
X-Gm-Message-State: AOAM533yrTEYR7zmkqCPr335Jo2wIgFa3JUSOIYRnln7K/WeSQlTphDg GEGvAxObeVEZJfIyMZWDfq0=
X-Google-Smtp-Source: ABdhPJxz30LI+4D4uIyrsUwLHiLtmXhrI6N+kX6OK5vxyBSlIOZ6o0JTbmapc+x4PBE0ICs08PlOdg==
X-Received: by 2002:a17:906:f0c8:: with SMTP id dk8mr12401394ejb.300.1615205578364; Mon, 08 Mar 2021 04:12:58 -0800 (PST)
Received: from [] ( [2003:d1:7f0a:df00:bc89:c181:8531:bef9]) by with ESMTPSA id da17sm6932023edb.83.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 04:12:57 -0800 (PST)
From: Dieter Sibold <>
To: Miroslav Lichvar <>
Cc: Heiko Gerstung <>, Watson Ladd <>, NTP WG <>, "Langer, Martin" <>
Date: Mon, 08 Mar 2021 13:12:56 +0100
X-Mailer: MailMate (1.14r5757)
Message-ID: <>
In-Reply-To: <YEYHHhIrYv4ZhTkl@localhost>
References: <> <> <> <YEYHHhIrYv4ZhTkl@localhost>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Mar 2021 12:13:03 -0000

On 8 Mar 2021, at 12:14, Miroslav Lichvar wrote:

> On Mon, Mar 08, 2021 at 11:43:29AM +0100, Heiko Gerstung wrote:
>> As far as I can see, up until this point the mechanism can be very 
>> similar to NTS4NTP. We most probably need a different cookie format, 
>> but the rest should be OK. Once we did 1 + 2, the unicast master will 
>> start the PTP packet transmission to the authenticated (via the 
>> cookie) PTP client. The client will also start sending Delay Req 
>> packets and requires the GM to respond with unicast delay responses.
>> During this packet transmission phase I propose to use the S2C to 
>> secure the packets from the GM to the client (ANNOUNCE, SYNC, 
>> DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP 
>> client to the GM (i.e. DELAY_REQ).
> I don't think it makes sense to use NTS cookies in PTP, even if you
> limit the NTS support to the unicast mode. The main point of the
> cookies is to avoid having client-specific state on the server. That's
> not possible in PTP as announce and sync messages are not responses to
> requests. They are sent at their own interval, which can be different
> from the delay request interval.
> In PTP there has to be some client-specific state and the clients need
> to be authenticated. Very different from NTS-for-NTP.

I agree with Miroslav. There is already state information defined in the 
IEEE 1588-2019 version in the context of the Authentication TLV. It 
should be possible to use them also for this purpose. This would make 
things easier compared to offload state information via cookies to the 
slaves and would minimize computational for the master.

> -- 
> Miroslav Lichvar
> _______________________________________________
> ntp mailing list