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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
