[ntp:hackers] Clarifications sought on v4 extensions

Danny Mayer mayer at ntp.org
Thu May 6 17:03:18 UTC 2010

You should repost this in the NTP WG mailing list rather than here since
this deals with questions on the protocol rather than the
implementations themselves.

The draft is now in the RFC Editor's hands so if there are any errors it
would need to be added as errata. If it's clarifications that would need
to go into a -bis version of the RFC.

Nelson B Bolyard wrote:
> After reading the recently expired draft-ietf-ntp-ntpv4-proto-13 and
> contrasting it with the current ntpd source code available from ntp.org,
> I'd like to request/suggest a number of clarifications to section 7.5
> "NTP Extension Field Format" on page 27 of that draft.
> I believe it was the intent of the draft that the 16-bit length field
> in the first word of an extension would contain the number of octets in
> the extension following that first word, so that the total length of the
> extension would be the number specified in that field, plus 4.
> Can someone confirm that?  It would be good for the RFC to make that clear.
> Also, as presently specified, the length count in the header includes the
> number of pad bytes, so that the least significant two bits of the length
> field will always be zero.  This in turn means that they do not tell the
> recipient how many pad bytes were included.  Perhaps it would be better if
> the length field did NOT include the number of pad bytes (but the number of
> pad bytes was nonetheless sufficient to bring the total extension size to
> a multiple of 4 octets and no less than the minimum number, which I discuss
> below), so that the recipient could inexpensively tell if there were any
> pad bytes to be dropped from the extension.
> The draft seems to acknowledge only MD5 and not SHA1 or any other hash,
> but the ntpd sources clearly implement both MD5 and SHA1 hashes, when
> built with the OpenSSL libcrypto library.
> The draft says "the minimum field length containing required fields is 4
> words (16 octets)" but does not explain the basis for that minimum
> requirement.  A comment in the ntpd source code strongly suggests that
> the intent was that the minimum extension length (including the 1 word
> extension header) would be equal to the maximum length MAC (including
> the one-word key identifier that acts as the MAC header).  Put another way,
> the minimum extension contents (excluding the 1 word extension header)
> must be no shorter than the maximum MAC hash size.  The comment says
> that if the length of the packet exceeds the length of the minimum NTP
> packet (12 words) by more than the maximum MAC size (including key
> identifier) this indicates that extensions are present.
> Assuming that the only MAC hash is MD5, whose hash size is 16 bytes, then
> that design goal is met by requiring extension contents to be at least 4
> words, but if SHA1 hashes are also allowed, then the minimum extension
> contents (without header) must be 5 words, and with header must be 6.  This
> is consistent with the comment in the present ntpd implementation, which
> states that the test for the presence of extensions is that the packet size
> exceeds the minimum by MORE than 6 words.
> So I ask that the next draft of the RFC be clarified about these things:
> - whether the extension's length field includes the 4 octets in the first
> word of the extension, or only the octets in words following the first.
> - whether the extension's length field really should include the number of
> pad bytes, or not.
> - whether other hashes besides MD5 are allowed.
> - the minimum number of words required in each extension (inclusive of
> the header word).
> Regards,
> /Nelson Bolyard
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> http://lists.ntp.org/listinfo/hackers

More information about the hackers mailing list