[dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

Dave I can understand the ISC's goal in using DHCP but how does this
work for the users?

DHCP also has problems with being constrained to the same subnet unless
provisions are made for its propagation... maning that without special
provisions for propagating DHCP across a local subnet this may not be of any
use at all. Especially since today its VERY rare to find anyone who wants to
route DHCP through their network, so maybe the IETF's new NEA protocol could
be a solution for this???

Todd

----- Original Message ----- 
From: "David L. Mills" <mills@udel.edu>
Cc: <ntpwg@lists.ntp.org>; <dhcwg@ietf.org>
Sent: Sunday, November 11, 2007 9:06 AM
Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

> Brian,
>
> My model about the keys is that the DHCP server would supply a key ID
> for the NTP server(s) as configured, but not the keys themselves. The
> keys would have to be configured for the NTP server and client
> separately. The DHCP server would be responsible only for the opaque key
> ID.
>
> There is an issue about the security of the DFCP server itself; that is
> another issue. I'm assuming the DHCP server is behind the firewall.
>
> The mode specification could be any of the valid NTP modes. If client
> (3) it would be an ordinary client/server association. A means would be
> necessary to specify broadcast client, as that is not a mode in the
> strict sense. It could be symmetric active (1), in which case the victim
> would initiate that type association. To specify symmetric passive (2)
> means that the victim should wait for a symmetric active (1) packet.
> This does not seem useful.
>
> Dave
>
> Brian Utterback wrote:
>
>> David L. Mills wrote:
>>
>>>
>>> 1. Listen for broadcast/multicast on <address> and do/do not execute
>>> a volley. I like the delay field to enable/disable that and have
>>> added it to ntpd. In principle, the delay can be determined from the
>>> DHCP packets themselves, a feature that might be added.
>>>
>> Right, I am fine with having the delay given and novolley specified.
>> You can't determine the delay from the DHCP
>> packets because the DHCP server is likely not the NTP server. The DHCP
>> server may be multiple hops away.
>>
>>> 2. Troll the pool at one of the pool DNS names, us.pool.ntp.org, etc.
>>> The client should be smart enough to use/not use iburst and preempt
>>> flags.
>>
>>
>> This argues for having another possible field/format, where a string
>> for lookup is given.
>>
>>>
>>> 3. Specify a list of <addresses> to send to, each together with the
>>> mode and  minpoll. I don't think maxpoll is useful either.
>>
>>
>> What other mode than active client do you envision?
>>
>>>
>>> 4. Specify a manycast server group address, ttl limit and beacon
>>> interval.
>>
>>
>> Okay.
>>
>>>
>>> In the broadcast/multicast, pool and manycast schemes, we need the
>>> optional tos floor and tos ceiling and tos cohort commands as well.
>>> All schemes may need the key ID or Autokey flag.
>>
>>
>> Interesting. I agree that a key needs to be specified somehow, but it
>> is not clear
>> to me how to do it. We have to assume that the client does not have
>> the same NTP
>> keys. However, we would like a way to specify a server and keys
>> securely, so that
>> the security of the network depends only on the security of DHCP.
>> Again I am not
>> up to date, *is* there a secure DHCP? If so, then how to get keys to
>> the clients
>> becomes an issue.
>>
>>
>>>
>>> All this makes me nervous. A possible alternative is simply to send a
>>> configuration file like the ntpq program can now. However, this of
>>> course is implemention specific. It might be useful to provide the
>>> name of a local configuration file only. The most important thing is
>>> to make it flexible for use by current ntpd and possibly others.
>>>
>> It seems (as you said) that a general purpose configuration mechanism
>> is needed. One that
>> is implementation neutral. We have talked in the past about config
>> over LDAP and HTTP.
>> Maybe we need to revist that. It would not have to be built into ntpd,
>> though, it could easily
>> live as a separate process.
>>
>> Brian
>>
>>>
>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg

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