Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6

Ted...From an audit perspective Time Transfer is one of those things that 
needs an audit profile for it, and adding more loopholes is the way to make 
the security model harder to prove not easier.

Todd

----- Original Message ----- 
From: "Ted Lemon" <mellon@fugue.com>
To: "Brian Utterback" <brian.utterback@sun.com>
Cc: <ntpwg@lists.ntp.org>; <dhcwg@ietf.org>; "Richard Gayraud (rgayraud)" 
<rgayraud@cisco.com>
Sent: Sunday, November 25, 2007 6:42 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

> On Nov 25, 2007, at 7:28 PM, Brian Utterback wrote:
>> So, the advantage of serving a FQDN is that the client is forced to
>> resolve the host and get the IP
>> addresses from DNS and removal of an IP from the DNS name system will
>> cause all the traffic
>> to that IP to eventually disappear.
>
> The client is not *forced* to do anything.   Whether or not it does
> what you describe depends on the implementation.   On a practical
> level, there is no difference between refreshing information from the
> DNS and refreshing information from DHCP.
>
>> We can specify in the DHCP protocol that when the DHCP lease is
>> renewed,
>> that the
>> NTP client must accept a new IP address and if different from the old
>> one, cease using
>> the old one.  We can specify that the DHCP client may only serve site
>> local addresses
>> unless the IP addresses served are themselves the result of periodic
>> DNS
>> lookup if
>> FQDN's. We can specify that the FQDN used may not be hard coded and
>> must be
>> configurable.
>
> You can specify things until you're blue in the face, but no
> specification that you write forces the implementor to do anything.
> As a practical matter, specifying things like this isn't really going
> to accomplish your goals.
>
> It's probably good to write a requirement that the NTP server MUST
> process updates from the DHCP client each time the client refreshes
> the NTP server addresses option, but the reason this will get
> implemented is that clients that don't implement it won't work reliably.
>
> I would expect the DHC working group to choose between using IP
> addresses or using FQDNs.   We don't like to have flags that switch
> between these, because they create implementation complexity and cause
> interoperability problems.
>
> I am in favor of using IP addresses because it uses less space in the
> packet, because it simplifies client-side implementations, and because
> every DHCP server of which I'm aware will take either an IP address or
> a domain name in any configuration field where an IP address is called
> for, and will look the IP address up in the DNS if a domain name was
> provided.   So you get the exact functionality you want, without any
> complexity on the part of the client.
>
> _______________________________________________
> 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