[ntp:hackers] Clarifications sought on v4 extensions
Nelson B Bolyard
nelson at bolyard.me
Thu May 6 05:33:43 UTC 2010
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).
More information about the hackers