Subject: Re: [ntpwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Mar 2008 14:52:24 -0400

In addition after attending today's NTP session, I think you'd be far
better to:

1. Make use of the existing OPTION_SNTP_SERVERS (RFC4075) but request
that IANA rename this to OPTION_NTP_SERVERS and explain why (that SNTP
refers to a client implementation, not the server and thus it should be
NTP_SERVERS which can be used by either NTP or SNTP clients).

Note: As the option usage is not changing, this is the correct to do. It
would be a very bad idea to request a new option because then many
servers will need to have both the OPTION_SNTP_SERVERS and the new
option configured with the same list of servers which is kind of
useless.

2. Define a new OPTION_NTP_DOMAIN_NAME option that is used to specify
the domain name of an NTP server. You can allow multiple of these
options if the ability to provide multiple domain names is desired. See
RFC 3898 which defines the NIS/NISP "servers" and "domain name" options.

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Wednesday, March 12, 2008 2:20 PM
To: Benoit Lourdelet (blourdel); [email-masked]'
Cc: DHC WG
Subject: draft-gayraud-dhcpv6-ntp-opt-01.txt

One issue in draft-gayraud-dhcpv6-ntp-opt-01.txt is that the
NTP_SUBOPTION_SRV_FQDN suboption "fqdn" data must be DNS wire encoded as
described in RFC 3315, Section 8 (Representation and Use of Domain
Names).

Thus:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    NTP_SUBOPTION_SRV_FQDN     |        suboption-len = 15     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      'n'      |      't'      |      'p'      |      '.'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      'e'      |      'x'      |      'a'      |      'm'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      'p'      |      'l'      |      'e'      |      '.'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      'c'      |      'o'      |      'm'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       sub-option-code: NTP_SUBOPTION_SRV_FQDN  (2)

       sub-option-len:  length of the included FQDN (15) 
 
Would actually be:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    NTP_SUBOPTION_SRV_FQDN     |        suboption-len = 17     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       3       |      'n'      |      't'      |      'p'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       7       |      'e'      |      'x'      |      'a'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      'm'      |      'p'      |      'l'      |      'e'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       3       |      'c'      |      'o'      |      'm'      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       0       |
     +-+-+-+-+-+-+-+-+

       sub-option-code: NTP_SUBOPTION_SRV_FQDN  (2)

       sub-option-len:  length of the included FQDN (17)

Also, usually DHCP option definitions just define the option format
without giving a specific example.

- Bernie
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Sat, 15 Mar 2008 22:37:32 -0400

> NTP_SERVERS which can be used by either NTP or SNTP clients).

That's not quite right. Yes, I'm being picky. There are SNTP servers 
defined in RFC4330 and in the NTPv4 draft, but they can be used by 
either NTP servers (on their client side) as well as by SNTP clients. 
NTP servers can be used by either NTP servers (on their client side) as 
well as by SNTP clients.

That said I know of no SNTP servers in existence unless the time 
standards agencies (NIST in Boulder, Colorado), US Navy, NPL 
(Teddington, England), etc. have them. Most use NTP servers.

That said, I agree that renaming these options is the right thing to do, 
either that or obsoleting them.

> RFC 3898 which defines the NIS/NISP "servers" and "domain name" options.

What would be the use of this? It doesn't have anythnig to do with NTP 
since NTP doesn't care about domains. Can you clarify?

Danny
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Danny Mayer <[email-masked]>
Date: Sat, 15 Mar 2008 23:48:20 -0400

Bernie Volz (volz) wrote:
> I think the general thought is that domain names can get you an address
> or addresses. So, why can't an NTP client (or server) make use of DNS to
> lookup the domain name (FQDN) and make use of the addresses? [While a
> perfect user of a domain name would adhere to the TTL of the information
> and re-query when the TTL is up to obtain the newest information, this
> rarely happens - the application is more likely to look up the name once
> and then use the address it found.]
> 

You used the term domain name rather than FQDN which is what confused 
me. I make a careful distinction between the two (when I put my DNS hat on).

> Or, are you saying that NTP servers (or SNTP servers if any exists)
> aren't ever entered in the DNS?
> 

NTP almost alway uses FQDN and look up the addresses in DNS. Use of the 
pool for example requires DNS lookups.

Danny

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 15 Mar 2008 23:18:56 -0400

- Bernie

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: Saturday, March 15, 2008 10:38 PM
To: Bernie Volz (volz)
Cc: Benoit Lourdelet (blourdel); [email-masked]; DHC WG
Subject: Re: [dhcwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

Danny

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Mon, 17 Mar 2008 08:56:10 +0100

Bernie,
 
You are beating a dead horse here. A 200 e-mail discussion lead to the
consensus that we needed FQDN and IP address.

Regards

Benoit

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Sunday, March 16, 2008 4:19 AM
To: [email-masked]
Cc: Benoit Lourdelet (blourdel); [email-masked]; DHC WG
Subject: RE: [dhcwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

- Bernie

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]]
Sent: Saturday, March 15, 2008 10:38 PM
To: Bernie Volz (volz)
Cc: Benoit Lourdelet (blourdel); [email-masked]; DHC WG
Subject: Re: [dhcwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

> refers to a client implementation, not the server and thus it should 
> be NTP_SERVERS which can be used by either NTP or SNTP clients).
> 

> Note: As the option usage is not changing, this is the correct to do. 
> It would be a very bad idea to request a new option because then many 
> options if the ability to provide multiple domain names is desired. 
> See RFC 3898 which defines the NIS/NISP "servers" and "domain name"
options.

Danny
> NTP_SUBOPTION_SRV_FQDN suboption "fqdn" data must be DNS wire encoded 
> as described in RFC 3315, Section 8 (Representation and Use of Domain 
> Names).
> 
> Thus:
> 
>       0                   1                   2                   3

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Mon, 17 Mar 2008 08:58:17 +0100

RFC4075 is bogus , it should not have been used anyway as is impossible
to use in proper part.

Let us obsolete it and start with proper option naming.

Benoit 

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: Sunday, March 16, 2008 3:38 AM
To: Bernie Volz (volz)
Cc: Benoit Lourdelet (blourdel); [email-masked]; DHC WG
Subject: Re: [dhcwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

options.

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 17 Mar 2008 09:26:09 -0700

Benoit... Bernie - The people who have to sign off on the use of DHCP's NTP 
service model are the auditor community so it would be easier if the 
terminology was more specific to their use than ours IMHO...

More commentary inline below.

todd glassey//

>> be NTP_SERVERS which can be used by either NTP or SNTP clients).

But there is another trust/use issue from the evidence gathering side, and 
that is that NTP and SNTP Sources need to be known independantly, especially 
since in a secured environment it may be necessary to pass a AutoKEY token 
with the DHCP response to allow for use of Time in an environment where all 
access is controlled and logged.

> NTP servers can be used by either NTP servers (on their client side) as

You mean "used in SNTP Mode" and that is OK as long as that server is setup 
for use in that manner, i.e. doesnt have AutoKEY setup for all Unicast & 
Multicast requests one would think eh?

> (Teddington, England), etc. have them. Most use NTP servers.

Agreed.

> since NTP doesn't care about domains. Can you clarify?

Yes - Many DOMAIN NAME stratification's may call for differing levels of 
evidentiary colleciton of data from, and so this does indeed make sense.

Todd Glassey

---

From: Danny Mayer <[email-masked]>
Date: Thu, 20 Mar 2008 23:07:58 -0400

> terminology was more specific to their use than ours IMHO...

No. This is the IETF working group, not the auditors working group. An 
auditor needs to learn the lingo of the IETF if they are going to be 
able to do a credible job of auditing. This is a red herring. We don't 
discuss auditing here.

> access is controlled and logged.

It makes no difference whether or not it's an NTP server or an SNTP 
server. The NTP protocol is identical whether you are dealing with NTP 
or SNTP servers and clients. You already know the source addresses and 
this is not relevant to the DHCP protocol.

> Multicast requests one would think eh?

No I meant what I said. It doesn't matter what the server is. Autokey 
would benefit by using DHCP options to distribute it. The problem with 
distributing autokey is that it needs to be associated with the server 
address since it is specific with that server.

> evidentiary colleciton of data from, and so this does indeed make sense.

No. NTP does not care about domains and does not use them. The only 
network part that's important to NTP is the server, peer, broadcast 
addresses.

Danny