Subject: Re: [secdir] secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Fri, 18 Sep 2009 11:27:09 +0200

Hello,

The comments that require discussion are signaled by BL>>

The rest of the comments are taken into account.

Benoit

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 4:31 AM
To: [email-masked]; [email-masked]; Benoit Lourdelet (blourdel);
[email-masked]; 'Brian Haberman'; 'Karen O'Donoghue'
Subject: secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

EDITORIAL

Global: s/an NTP/a NTP/
        s/an FQDN/a FQDN/

In section 2., the acronym "DHCPv6" should be expanded on first usage.

The first paragraph of section 2.1 says:

   When using DHCPv6 to offer NTP Server location, and if
   there is a need to distribute a device with a hardcoded
   configuration, this configuration MUST NOT include server location
   that is not part of the organization that distribute this device.

s/distribute/distributes in the last line.
I don't understand what device is under discussion.  Is it a DHCP
server?  A
DHCP client?  Also,

   Typical usage of this option is to specify an NTP Server that is part
   of the organization that operates the DHCPv6 server.

This seems less clear than it should be to me; suggest rephrasing,
perhaps
as 

  This option will typically be used by the organization operating the
DHCPv6 
  server to provide data regarding the location of its own NTP server.
BL>> that is the point. The  suggested usage is to have the DHCPv6
server and the NTP server pointed to in the same organization.
This to prevent overloading public servers.

The second paragraph of section 2.1 says:

   DNS can be used to redirect misconfigured clients
   to an unexisting IPv6 address instead of having to change the address
   of the NTP server itself.

I don't know exactly what an "unexisting IPv6 address" is, nor why it
would
be a good thing to redirect misconfigured clients to one.  Also, the
acronym
"FQDN" should be expanded on first usage.
BL>> The idea is to blackhole malicious traffic.

The third paragraph of section 2.1 says: "The DHCPv6 option for NTP is
then
restricted to server location."  This construction is a little bit
clumsy, I
think; suggest changing to "The DHCPv6 option for NTP is therefore
restricted to server location."

In the first paragraph of section 3.0, the acronym "SNTP" should be
expanded
upon first usage; suggest changing "This option serves as a container
for
all the information related to one NTP server or SNTP server." to "This
option serves as a container for all the information related to one NTP
or
Simple Network Time Protocol (SNTP) [RFC4335] server."  This will also
take
care of one of the unused references mentioned below.

BL>> RFC4330 instead.

The second paragraph of section 3.0 says:

   While the FQDN option offers the most deployment
   flexibility, resiliency as well as security, the IP address options
   are defined to cover cases where a dependancy to DNS is not
   desirable.

I think that the readability of this sentence could be improved; suggest
changing to 

   While the FQDN option offers the most deployment Flexibility and 
   resiliency as well as security, the IP address options are defined 
   to cover cases where a DNS dependency is not desirable.

The last paragraph of section 3.0 says:

   This document does not define any priority between the client's
   embedded configuration and the NTP servers or SNTP servers discovered
   via this option.  

Suggest changing to 

   This document does not define any priority relationship between the
client's
   embedded configuration (if any) and the NTP or SNTP servers
discovered
   via this option.  

In the heading of section 4, capitalize "use" or just change the heading
from "Examples of use" to "Examples".

Section 4 seems somewhat less than useful to me, especially since the
examples are inconsistent: the FQDN example uses the exact encoding of
the
FQDN, but the unicast and multicast address examples do not.  I suggest
either making the examples consistent by putting the actual address
encoding
of the addresses in the address examples or just getting rid of section
4
altogether.

BL>> If that works for everybody I remove the example section for now.

The references to RFC 4075 and RFC 4330 are defined but never used.

BL>> RFC4330 is no in use. RFC4075 is in use in the new version of the
ID that explain its relation to RFC4075.

Hope this helps.

~gwz