Re: [Ntp] [Last-Call] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standard

Danny Mayer <> Fri, 19 February 2021 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DCEA3A0D6A; Fri, 19 Feb 2021 06:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u95ZEpoNUn52; Fri, 19 Feb 2021 06:16:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 176263A0D6D; Fri, 19 Feb 2021 06:16:04 -0800 (PST)
Received: from L34097OUS.fios-router.home ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4DhtsY6rDnzMNRH; Fri, 19 Feb 2021 14:16:01 +0000 (UTC)
To: tom petch <>, Dhruv Dhody <>
Cc: NTP WG <>, Ankit Kumar Sinha <>,,,, Dieter Sibold <>,
References: <> <> <> <> <> <> <>
From: Danny Mayer <>
Message-ID: <>
Date: Fri, 19 Feb 2021 09:16:00 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ntp] [Last-Call] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standard
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, 19 Feb 2021 14:16:22 -0000

Maybe I can help clarify the issue with MD5 hashing of an IPv6 address. 
The usage is for the Reference ID in the packet and the Reference ID is 
designed to prevent timing loops. For non-stratum-1 server references 
this was the IPv4 address of the chosen parent clock as chosen by the 
receiving client. IPv6 addresses don't fit into a 32-bit field so this 
hashing scheme was invented. (See section 7.3 of RFC5905). Unfortunately 
this has been totally misunderstood and does not deal with outgoing 
packets from the same server using different IP addresses. There is no 
proper way to fix this in the Ntpv4 packets, it will need to wait for a 
V5 version of the protocol. V5 would need to have each ntp server 
generate a random number that will then be including in all outgoing 
packets regardless of interfaces and IP addresses that the receiving 
server can use for it's referenceID in its own outgoing packets.

None of this is related to the security issues of MD5 hashes.

I hope this helps,


On 2/19/21 5:30 AM, tom petch wrote:
> -13 looks better
> Perhaps a comment for the AD.  You have added a reference for MD5 
> which I think necessary but as Informative which I find debatable 
> given its use to generate a 32-bit identifier from a IPv6 address, ie 
> its use is going to go up and up, not fade away.  I am aware that the 
> RFC is Informational not Standards Track so a Normative Reference 
> would be a downref which needs calling out in a Last Call which means 
> a new Last Call.  (Given the number of changes made since -10, perhaps 
> that is not such a left field idea:-)  The reference in RFC5905 is 
> Normative.  Like I say, one for the AD.
> Hash algorilthms - a minefield.  You have lots of choice but that 
> increases the probability of incompatability between client and 
> server.  One is good, obsolescent and now recommended is good, but a 
> choice of eight without even including SHA3?  I note too that the 
> Netconf WG regard SHA1 as obsolete.
> Access mode I think deserves more text, a sub-section in s.5, not just 
> a mention.  Authors vary as to how much text there is in a YANG I-D 
> but I think that the better ones have more rather than less, bridging 
> the gap from protocol specification to YANG module, and, as you have 
> seen, I went looking in the RFC for an explanation, which was a waste 
> of time:-)  And I really do not understand the text.
> 'can be performed on the local NTP service'
> I find ambiguous.  Does it mean that the entity in which this YANG 
> module is will send such requests? Or does it mean that the entity 
> will respond to such requests?  And how does that vary with server, 
> client, peer?  I cannot tell from the I-D.
> identity broadcast-client could do with mode 6 to bring it in line 
> with other identity
> s.8.5
> You slip in a version 3 which I guarantee will attract the attention 
> of an AD!.  You mentioned earlier that you intended the module to work 
> with V3 which I did not pick up from reading the I-D.  If that is your 
> intention, then I think that this needs calling out, perhaps in the 
> Introduction as well as the text preceding s.8.5
> Tom Petch