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

Thu Mar 5 14:49:41 UTC 2009

Hello,

Richard and I reply online after BL>> and RG>> . 

Based on the reply we expect to publish a revised version in the coming
days.

Regards

Benoit

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.

RG>> You are right that this paragraph is confusing, partly because of 

RG>> the

     use of the of the "SNTP protocol" wording. However,  we have to
mention 

     the existing SNTP option, and explain why we do not reuse it.  So
we

     reworked this paragraph in order to make it more explicit and less

     confusing.

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.

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

RG>> You assumption is wrong regarding the fact that dhcpv6 would carry

     IPv4 addresses. Dhcpv6 is not meant to carry configuration
information

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

BL>> in nature the draft is allowing for extension definition. 

This key option will naturally fit in extention definition in a separate
document.

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.

BL>> I think we agree to remove this sentence.

Section 3.3 (P7)

FQDN: Fully Qualidied Domain Name of the NTP server.

should be:

FQDN: Fully Qualified Domain Name of the NTP server.

BL>> agreed

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.org/pipermail/ntpwg/attachments/20090305/3d72783d/attachment.html 