Re: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt

Hi Margaret,

Thanks for your thorough review. I am sorry for replying bit late. See
my reply inline....

~ Vijay

> 
> General question on this document:  We recently deprecated
> the option code allocation for the IPv4 version of this 
> option.  Why do we think that there is a greater need for 
> this in IPv4 than in IPv6?  Has anyone implemented these options?  

NTP version 4.0 available in www.ntp.org supports IPv6. Most of the
vendors provide this version and support NTP on IPv6. So, it is really
needed.

> 
> >Abstract
> >
> >   This document describes the options for Time related configuration
> >   information in DHCPv6: NTP Servers and Timezone specifier.
> 
> This is a very weak abstract.

I will elaborate it bit more.

> 
> >3. Terminology
> >
> >   This document uses terminology specific to IPv6 and DHCPv6 as
> defined
> >   in section "Terminology" of the DHCP specification.
> 
> s/section "Terminology"/"Terminology" section
> 
> ...and/or include a section number.

Fine.. I will change it.

> 
> >4. Network Time Protocol (NTP) Servers option
> >
> >[...]
> >
> >   NTP server:    IP address of NTP server
> 
> Is it expected that this option will only contain the
> addresses of IPv6 NTP servers? If so, you  should make that 
> clear.  If not, how 
> would an IPv4 address be indicated?

Yes. This option is for IPv6 addresses only. I will make it clear.

> 
> It is also my understand that we haven't (yet) specified how
> NTP would run over IPv6, so this option may be premature.

Since, there is actually no protocol changes are needed in existing RFC
for NTP, there is no specification for NTP on IPv6. Its just like
another application migration to IPv6. But, IPv6 version of NTP are
available in various platforms. I don't think this option is a premature
one.

> 
> >5. Timezone option
> >
> >   The Timezone option is used by the server to convey client's
> timezone
> >   information to the client.
> 
> Is it assumed that the server will always be in the same
> timezone as all of its clients?  Or is there some other way 
> that the server will determine what timezone information to 
> send to each client (config'ed on a per-prefix basis, perhaps?).

Server is not needed to be in the same timezone. Basically, the timezone
is allocated based on the prefix. The assumption is, the nodes in the
same network will be in the same timezone.

> 
> >   time-zone:   Time zone of the client in the format as explained
> below.
> >   
> >      Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]]
> >
> >   where '[' and ']' enclose optional fields, '|' indicates choice
> >   of exactly one of the alternatives, ',' and '/' represent literal
> >   characters present in the string.
> >
> >   If "Offset" is specified, then the time-zone is represented in the
> >   IEEE 1003.1 POSIX timezone format [3].
> 
> What is the reason for specifying a timezone format in this
> document, instead of relying completely on another establish 
> standard for 
> timezone representation? 

This flexibility is provided to help the vendors to use some other
vendor specific database for timezone information. This is needed, if
they feel that their databases can convey more information than POSIX
time string.

> 
> >    iii) Representing ii) in the non POSIX standard way is:
> >
> >       America/New-York
> >
> >     It says that the locale belongs to New-York timezone in America,
> which
> >     will be used as the index in to a timezone database to get more 
> >     information of the timezone.
> 
> What is a "timezone database"?  Is this a standard concept,
> or something you are assuming will be specific to each host?  
> If the latter, why do we need this flexibility?

Its not a standard concept. Its something specific to the OS. For the
last question, you refer the prev answer.

> 
> >7. Security Considerations
> >
> >   The NTP servers option may be used by an intruder DHCP server to 
> >   cause DHCP clients to contact an intruder NTP server,
> resulting in
> >   invalid synchronization of time in client and finally leading to
> >   time critical applications running inaccurately in client machine.
> >   The time accuracy can be crucial to some security algorithms. For 
> >   example, it may cause expired certificates to gain a new life,
> making
> >   the application less secured.
> 
> s/less secured/less secure

Ok. Will update it.

> 
> >   The Timezone option may be used by an intruder DHCP
> server to assign
> 
> >   invalid time zones, leading to timing issues for the applications
> running
> >   on the client machine.
> 
> I think that there is potential for a denial of service
> attack. Given that time synchronization is required for some types of 
> secure access, giving wrong time information to a client could 
> result in the client being unable to access some services.  
> Is that what you are talking about in the above paragraph?  
> If so, I think you should be more explicit.

Whatever you have explained is one of the scenarios. There could be
many. For example, because of wrongly configured timezone, there is a
possibility that some applications which are supposed to start at a
particular time don't get started at that time. Since there could be
many issues like this, I was not more explicit. Probably, I could add
some examples to the text.

> 
> >   To avoid attacks through these options, the DHCP client
> SHOULD use
> >   authenticated DHCP (see section "Authentication of DHCP messages" 
> >   in the DHCPv6 specification [1]).
> 
> Why only a "SHOULD"?  Given the critical nature of time
> infromation to some security protocols, I would prefer a 
> statement that this option MUST only be used when the DHCP 
> messages are authenticated.  Is there a reason not to say that?

As such authentication is not mandatory in the DHCPv6 specification (RFC
3315) except for reconfiguration. That's the reason why "MUST" is not
used here.

> 
> >8. IANA Considerations
> >
> >   IANA is requested to assign an option code to these
> options from the
> >   option-code space defined in section "DHCPv6 Options" of
> the DHCPv6
> >   specification [1].
> 
> Based on earlier experience, you need to explicitly list the
> option codes to be assigned by IANA in this section.

Yes, I will do..

> 
> >10. Informative References
> >
> >   [2]  D. Mills.  Simple Network Time Protocol (SNTP) Version 4 for
> >        IPv4, IPv6 and OSI.  Request for Comments
> (Informational) 2030,
> >        Internet Engineering Task Force, October 1996.
> 
> This should be a reference to NTP, not to SNTP.

Basically, the NTP servers I am referring are SNTP servers. I believe, I
could change the "NTP server option" to "SNTP server option".

Thanks once again for your thorough review.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg