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 <[e-mail]>]

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,

Danny

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
>