[dhcwg] 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
>
>>
>

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