[ntpwg] NTP WG Last Call:draft-ietf-ntp-dhcpv6-ntp-opt-02.txt

[Danny Mayer]

My apologies for the delays in getting this out.

I have a number of issues with this draft.

Substantive issues:

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
even more.

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
introduction.

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 so.

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
authenticate.

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
this.

Section 3.3 (P7)

FQDN: Fully Qualidied Domain Name of the NTP server.

should be:
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?

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.

I hope this clarifies matters.

Danny