[ntpwg] NTP WG Last Call:draft-ietf-ntp-dhcpv6-ntp-opt-02.txt
Benoit Lourdelet (blourdel)
blourdel at cisco.com
Thu Mar 5 14:49:41 UTC 2009
Richard and I reply online after BL>> and RG>> .
Based on the reply we expect to publish a revised version in the coming
My apologies for the delays in getting this out.
I have a number of issues with this draft.
The first paragraph of Section 2.1 (p3) discusses SNTP as if it is a
different protocol when in fact SNTP is just a simplifed implementation.
The protocol itself is still NTP. There is no SNTP protocol. It is not
possible to tell the difference between NTP and SNTP servers by the NTP
packets arriving on from those servers. It should not be treated outside
of NTP discussions as if they were different. RFC4075 misunderstands
this. Section 2.1 should not be discussing this and confusing matters
RG>> You are right that this paragraph is confusing, partly because of
use of the of the "SNTP protocol" wording. However, we have to
the existing SNTP option, and explain why we do not reuse it. So
reworked this paragraph in order to make it more explicit and less
The next two paragraphs of Section 2.1 then goes on to discuss security
concerns but those concerns should be moved to Section 6 rather than the
BL>> We have been asked over the course of the mailing list discussion
to put this discussion upfront.
The document only refers to IPv6 addresses for NTP servers and does not
mention IPv4. Currently there are very few IPv6 NTP servers available
and they almost all run IPv4 only. We would like to change this but this
document should not exclude IPv4 addresses. I assume that dhcpv6 is not
meant to ignore IPv4 but if it is then the document should explicitly
state this fact and give reasons for doing so. In fact I'd like to see
all IETF documents have a section which states whether or not it
addresses IPv4 and IPv6 is irrelevant and reasons for doing or not doing
RG>> You assumption is wrong regarding the fact that dhcpv6 would carry
IPv4 addresses. Dhcpv6 is not meant to carry configuration
for the IPv6 family of protocols. This is left to dhcpv4. The NTP
option for dhcpv4 is defined in RFC2132.
I'd like to see these options also optionally distribute keys needed to
authenticate the specified servers. NTP needs to do this in with an OOB
method since it has no authenticable way of doing this. This is
especially important for multicast addresses but is needed for all NTP
servers. Note that keys are on a per-server basis so each suboption
specified by the document would need to have that available. The key
part would need to specify the key type as specified by the autokey
draft as well as the length of the key and the actual key to be used to
BL>> in nature the draft is allowing for extension definition.
This key option will naturally fit in extention definition in a separate
Nits and other problems:
Section 3 (P5) states the following: "A client that receives this option
SHOULD use the specified NTP server to synchronize its clock."
I'm not clear why this is a SHOULD. It is entirely up to the client to
decide whether or not to use this option. The draft should be silent on
BL>> I think we agree to remove this sentence.
Section 3.3 (P7)
FQDN: Fully Qualidied Domain Name of the NTP server.
FQDN: Fully Qualified Domain Name of the NTP server.
Section 5 (P8-9)
The second paragraph states:
"The OPTION_NTP_SERVER option MUST NOT appear in messages other than the
following: Solicit, Advertise, Request, Renew, Rebind,
Information-Request, and Reply. If this option appears in messages
other than those specified above, the receiver SHOULD ignore it."
This doesn't make any sense. If The OPTION_NTP_SERVER option MUST NOT
appear in messages then surely the receiver MUST ignore it?
BL>> Ok to remove that sentence.
Section 6 Security Consideration
This needs to include those paragraphs currently in section 2.1 and make
it clear that these options can be used as an amplification attack on
NTP servers in a similar way that a number of router manufacturers
hard-coded NTP IP addresses and then sold them by the 10's of thousands
inflicting attacks on unsuspecting NTP servers.
BL>> I think the consensus was to address the amplification attack
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ntpwg