Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

Daniel Franke <> Fri, 28 May 2021 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DEDD3A28D8 for <>; Fri, 28 May 2021 06:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 k9yRitlVjFkn for <>; Fri, 28 May 2021 06:26:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 185A33A28CD for <>; Fri, 28 May 2021 06:26:07 -0700 (PDT)
Received: by with SMTP id q25so3254013pfn.1 for <>; Fri, 28 May 2021 06:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yTJZcmaiH1BhSr0JfDgZCDlXm8XgmHlEAq8vvycyxyE=; b=SEfTdCAdB0qNvogTWIo9bquy9HQUBxizQUqrpugqgh5fLKf+VQ6vVsW1aEhvmAMR+R nwfoWxmvawR5OsfjmfFS78RfvntOyNPDZ6UHATCQZj3RF2AHsk60/GRhETvHkPK7zMWQ nSsXwQg7GAPpKXIwTIqFaSn6onGIrR9jQFADFQgtY9w9j4CrgDGCyn0x20VZWLN2GJyn bZc3NYqVh/F6yYVQERQvaDphevutrWV8M1UbwAOgHqHm07W3KrmTEXIiwmdWdjy/WMi4 ERiIFfMMwyX2zPm/2qu4ETR6uEPrxvlol7GXpHXkQz9sWBHQVLWHDs4H5q4VlV14UZdn AWGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yTJZcmaiH1BhSr0JfDgZCDlXm8XgmHlEAq8vvycyxyE=; b=F6uMUscjvUnaJs7/hmSP/LbSPpPFfffeCtMytPnTBxEDpd/npIE9Zv0AcOKwbmKu7Z JCIGsmomFtlwv9FqeCP+fPjcqf8eGSuJsObSIVbXz8vqDeyxvT3sb1LD59coDGEOOrBe eBrs0DEt5Qr9WFIHm+F11D8PNfJW0Qz2fL3CjmkPZKyb98cm8wkcsWPgxgTSzZb9BdsG g9CE4s3WAtGvr7pi69YNc5ADghx0HrPkkq/mV+O/uAhdn1AkiQ1clqDuk2WzySmAn8Kz 5uCSw1hckf2CWf5hvK/BnaLjW5Me5jq6k8oUakjXeN0lBLagGPe/Cx3R3rDxLnIAB346 k4aQ==
X-Gm-Message-State: AOAM532Cg9efEygj1pZxRwcqzo7LD5c35texfsflKlp1TAMfRE4SqLEP AKdNKAuq6k2s9z/xz1xoYE7bYugEQgX2HdcJWlwvac20eRI=
X-Google-Smtp-Source: ABdhPJyy3wmXHm1uZ5v2fpeT66LvOhKDn0MGHWKtHRM1oWksferSBAvB6INMf7Wb1hPlp5qEHAn4GsQFfJotaX3yBuk=
X-Received: by 2002:a63:bc19:: with SMTP id q25mr9053152pge.211.1622208366683; Fri, 28 May 2021 06:26:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Daniel Franke <>
Date: Fri, 28 May 2021 09:25:55 -0400
Message-ID: <>
To: Heiko Gerstung <>
Cc: "" <>, Doug Arnold <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 May 2021 13:26:13 -0000

On Fri, May 28, 2021 at 3:33 AM Heiko Gerstung
<> wrote:
> sorry for top-posting, I try to summarize your arguments in this discussion (and please correct me if I misunderstood something):
> You object adopting the draft that my colleagues and I submitted because:
> 1) you expect that working on this will require a lot of work for a lot of people
> 2) you think that using NTS4NTP in combination with Unicast PTP can provide a solution to the problems we want to solve with NTS4UPTP
> 3) you think that 2) is true because PTP could not guarantee a higher level of time accuracy in any network, mainly due to the fact that you consider RTT as the limiting factor and because there is no way to defend RTT against a MITM that is capable of delaying packets
> 4) you assume that because of 3) any user with a requirement that can only be fulfilled with PTP has to physically secure their network anyway to be protected against delay attacks and therefore there is no point in securing unicast PTP against any other security threats and types of attacks
> Is that correct? Did I miss something?

You have the gist of it, but there's a nit about (2) and an important
bit of nuance about (4).

On (2), the hybrid NTS4NTP/PTP solution isn't limited to unicast PTP.
It works just as well with broadcast/multicast. Of course the NTS4NTP
part still has to be unicast NTP.

On (4): "security threats and types of attacks" is kind of vague. I'd
rather think of this in terms of goals and adversary powers, and this
leads to two questions that I'm open to being persuaded on:

1. Are there goals beyond protecting the integrity of time
synchronization that NTS4UPTP can serve but hybrid NTS4NTP/PTP can't?

2. Are there any interesting classes of adversary weaker than the
standard MitM adversary, from whom NTP4UPTP can provide stronger
protection than hybrid NTS4NTP /PTP can?

Question 1 is what I already raised upthread when I mentioned
anti-amplification, protecting management functions, etc.

Question 2 is something I raised in the original thread about hybrid
NTS4NTP/PTP. Any attacker who is on-path or adjacent to one of the
endpoints can set itself up as a MitM and therefore conduct delay
attacks. Off-path attackers, on the other hand, can't read or modify
legitimate traffic but may be able to inject packets with spoofed
source addresses. With hybrid NTS4NTP/PTP, such an adversary can
potentially do just as much damage as a MitM can, injecting SYNC
messages that fall just inside the window of plausibility and inducing
a half-RTT error. With NTS4UPTP, such packets could be rejected
because the attacker wouldn't be able to forge the MAC tag; an
off-path attacker isn't capable of moving us from the "normal" case of
sub-microsecond precision to the "adversarial" case of half-RTT
precision. However, I don't find this argument compelling enough,
because in realistic PTP deployments. the problem of off-path
attackers should already be adequately mitigated by firewalls. Your
network is very broken if an outside attacker can spoof your PTP
server's network address and have that spoofed packet make it all the
way to clients rather than being dropped at your router. You couldn't
rely on firewalls this way if you were running PTP over the open
internet, but that's not how people use PTP.