Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

From: Danny Mayer <[email-masked]>
Date: Sat, 08 Dec 2007 23:18:42 -0500

MORAND Lionel RD-CORE-ISS wrote:
> Hi all,
> 
> During the meeting, we discussed again the use of FQDN for advertizing
> NTP servers.
> 
> During the work on the PANA option, we had exactly the same discussion
> (in the meeting and on the mailing list) and the conclusions was the
> same: we SHOULD use IP address list instead of FQDN. The SHOULD is there
> to say that it might be some cases where the use of FQDN would be
> valuable/really required.

Don't you think that you should have also discussed this with the NTP
folks as well? Most of the DHCP discussion only happened because we were
asked to review the draft.

> As it seems that, after at least two long discussions in the same topic,
> there is a "common" understanding on how should be advertize servers, it
> could be useful to capture these conclusions as guidelines in the
> dhc-option-guidelines draft. This would help a lot other working groups
> when they will have to design new options for the same usage.

I'm not yet convinced that this conclusion is really warranted since
this will force NTP to use only a single IP address for each server
instead of being able to use the pool option which provides a lot of
flexibility. It's not in the NTPv4 draft but that shouldn't matter since
 this is about provisioning NTP and not about a specific implementation.
Don't forget that NTP will have to live with the decisions you make
about what you tell it to use. It's either that or the options will get
ignored and neither result is desired. I'd like to discuss how this will
be operationally implemented before we can make a decision on whether or
not IP addresses are the way to go.

I am copying the NTP WG on this so we can get other people's input.

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

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Sun, 9 Dec 2007 19:16:43 +0100

Hello Danny,

I think you are right. This was discussed during both the NTP working 
group and the DHCP working group. At some point, it was told by some
people that the address it better and the worries in NTP community are
due to misunderstanding of how DHCP works. But I believe this is not 
true.

Their main argument is that DHCP is not configured statically, and has
the ability to resolve DNS names, and will, in turn, redistribute this
as an IP.

  => This ignores the NTP pool capability

  => But more importantly, this does not give any guaranty that a vendor 
     will not ship a small home router with a DHCP server inside, with an 
     embeded NTP server address => worst case.

This is why I think we really need to address FQDN. I had the opportunity 
to discuss with a few people after the meetings, and had the feeling this
can be accepted as a consensus.

The syntax to use for this is less consusual. It could be :

  - an option with a 'type-switch' byte : people do not like this
    solution.

  - an option with sub-options (one sub-option for address or one for
    FQDN, plus a few optional ones for parameters like Key-ID)... 
    (most flexible solution)

  - 2 different options. They would have the same additional parameters, 
    which is not that nice...

Again, each option can appear several times in the DHCP message,
so that several NTP serves can be configured.

One question for you Danny : In ntpd.conf, I think we have to 
configure pools with a different keyword than 'servers'. Does this 
means that a pool must be differentiated in the config ? Should it 
be carried as another sub-option in DHCP ?

Thanks,

Richard. 

> -----Original Message-----
> From: Danny Mayer [mailto:[email-masked]] 
> Sent: dimanche 9 décembre 2007 05:19
> To: MORAND Lionel RD-CORE-ISS
> Cc: DHC WG; NTP Working Group; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] NTP option: IP address and/or FQDN
> 
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Danny Mayer <[email-masked]>
Date: Sun, 09 Dec 2007 13:46:44 -0500

> be carried as another sub-option in DHCP ?

Just let me respond to this one now and the rest I'll respond later.

I'm only speaking here of the reference implementation of NTP.
The pool option is affectively the same as a server option except that
the FQDN will result in multiple addresses each of which will be
configured as a server. You cannot do that today with the server option
but from DHCP's point of view is just a matter of creating multiple
server options with the IP address. server takes either a name or an IP
address but currently only uses the first one it gets back on the list
if it's a FQDN.

If the reference implementation were to get a FQDN from the DHCP server
it would probably be set up as a pool option. If it were to get an IP
address it would use it as a server option.

Danny

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Sun, 9 Dec 2007 20:10:51 +0100

Hello Alain,

This is not really different, but the impact of it will be less
important:

  - If an hardcoded NTP IP address is shipped within a SOHO thing,
    (as it happened in the past), then this IP address is dead, 
    for good. Not usable anymore. Also, I suspect routers on the
    path to this subnet are impacted, unless global internet
    routing tables are updated to drop this traffic upstream.

  - on the other side. If a DNS name is hard-coded, this IP 
    address and subnet issue can be avoided by removing the
    name from the DNS database. 

      . Clients are not supposed to re-query the DNS server
        every 2 seconds after the server replies the name is
        not resolvable.

      . even if they do, the load will be distributed over
        multiple local DNS servers (instead of having a
        single victim IP address).

      . we hope that a poorly coded SOHO equipment will use a 
        pool FQDN rather than a single NTP server name.

I think other people gave other good reasons to use FQDN, but
I do not remember all of them.

Does this help ?

Thanks,

Richard.

> From: Alain Durand [mailto:[email-masked]] 
> Sent: dimanche 9 décembre 2007 19:55
> To: Richard Gayraud (rgayraud); Danny Mayer; MORAND Lionel RD-CORE-ISS
> Cc: DHC WG; Ralph Droms (rdroms); NTP Working Group
> On 12/9/07 10:16 AM, "Richard Gayraud (rgayraud)" <[email-masked]>
> wrote:
> 
> Excuse me if I'm just adding fuel to the fire, but I still 
> fail to see the
> difference between a vendor shipping a home router with a 
> DHCP server that
> has an NTP option embedding a hard-coded IP address and the 
> same vendor
> shipping a similar product with a hard-coded FQDN...
> 
>    - Alain.
>

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 09 Dec 2007 20:17:40 +0000

Guys,

I like the *option* (or ability) to get a FQDN for an NTP server from DHCP.

And I do not know if an NTP server will be talking directly to a DHCP
service or if that will go thru a 'shim' process.  The details of this
mechanism is probably not important.

And if DHCP can feed a *list* of addresses to NTP, that is very useful
as well.  In this case, the DHCP server could take the list of addresses
that FQDN resolves into and pass that list along.

H

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 9 Dec 2007 17:02:24 -0800

----- Original Message ----- 
From: "Richard Gayraud (rgayraud)" <[email-masked]>
To: "Alain Durand" <[email-masked]>; "Danny Mayer" 
<[email-masked]>; "MORAND Lionel RD-CORE-ISS" 
<[email-masked]>
Cc: "DHC WG" <[email-masked]>; "NTP Working Group" 
<[email-masked]>; "Ralph Droms (rdroms)" <[email-masked]>
Sent: Sunday, December 09, 2007 11:10 AM
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

Hello Alain,

  - If an hardcoded NTP IP address is shipped within a SOHO thing,
    (as it happened in the past), then this IP address is dead,
    for good. Not usable anymore.

tsg: Amen.

    Also, I suspect routers on the
    path to this subnet are impacted, unless global internet
    routing tables are updated to drop this traffic upstream.

tsg: Yep...

tsg: The problem here then is that domain owner is permanently tied to that 
overhead and it will follow them forever like the bad IP address variant. 
Imagine if you would a domain name with a bre-built traffic overhead to its 
NTP and DNS server's based on a vendor's actions.

tsg: And you want to rely on people to properly implement the standard? or 
abide by the rules? ... My DNS servers are still absorbing overhead and the 
IP addresses we ran the SJ server on are still slammed by bogus traffic so 
as someone who actually suffers from this I think the DNS traffic is much 
worst than you are painting it.

tsg: There is another issue to address and that is whether the publishing of 
the FQDN itself requires a copyright release. It may, and that would make 
this something that the NTP License would need to address. By the way - the 
reason the world can abuse the coding standard for NTP is pretty much 
totally because the use and deriviative license lets them do it.

Does this help ?

Thanks,

Richard.

---

From: Alain Durand <[email-masked]>
Date: Sun, 09 Dec 2007 10:54:36 -0800

>      embeded NTP server address => worst case.

Excuse me if I'm just adding fuel to the fire, but I still fail to see the
difference between a vendor shipping a home router with a DHCP server that
has an NTP option embedding a hard-coded IP address and the same vendor
shipping a similar product with a hard-coded FQDN...

   - Alain.

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Sun, 9 Dec 2007 14:52:30 +0100

Hi Danny,

In any case it was a statement on what the NTP wg should have had to do.
I was just expressing my own understanding of the outcome of the dhc session.
As I said, I met exactly the same troubles while defining a new dhcp option for locating pana agent in the network.

I think clear guidelines on this topic could be very useful. For instance, instead of providing FQDN, it is often said that the dhcp server could be just another user of the DNS, performing DNS lookup before providing IP address(es) to the dhcp client. The foreseen flexibility of the use of FQDN could be therefore provided while using IP address(es) in dhcp options.

I have no strong opinion on this topic, being not a dhcp expert myself. But as a "client" of the dhc wg, I'm interested by a clear statement.

BR,

Lionel

> -----Message d'origine-----
> De : Danny Mayer [mailto:[email-masked]] 
> Envoyé : dimanche 9 décembre 2007 05:19
> À : MORAND Lionel RD-CORE-ISS
> Cc : Ralph Droms; DHC WG; NTP Working Group
> Objet : Re: [dhcwg] NTP option: IP address and/or FQDN
> 
> > same: we SHOULD use IP address list instead of FQDN. The SHOULD is 
> > there to say that it might be some cases where the use of 
> FQDN would 
> > be valuable/really required.
> 
> Don't you think that you should have also discussed this with 
> the NTP folks as well? Most of the DHCP discussion only 
> happened because we were asked to review the draft.
> 
> > As it seems that, after at least two long discussions in the same 
> > topic, there is a "common" understanding on how should be advertize 
> > servers, it could be useful to capture these conclusions as 
> guidelines 
> > in the dhc-option-guidelines draft. This would help a lot other 
> > working groups when they will have to design new options 
> for the same usage.
> 
> I'm not yet convinced that this conclusion is really 
> warranted since this will force NTP to use only a single IP 
> address for each server instead of being able to use the pool 
> option which provides a lot of flexibility. It's not in the 
> NTPv4 draft but that shouldn't matter since  this is about 
> provisioning NTP and not about a specific implementation.
> Don't forget that NTP will have to live with the decisions 
> you make about what you tell it to use. It's either that or 
> the options will get ignored and neither result is desired. 
> I'd like to discuss how this will be operationally 
> implemented before we can make a decision on whether or not 
> IP addresses are the way to go.
>

---

From: <[email-masked]>
Date: Mon, 10 Dec 2007 09:23:52 -0000

The main problem with the DHCP doing the DNS lookup on behalf of it's NTP clients, is that architecturally, that's a complete mess. The pools demonstrate why. Many NTP servers are set up with the same Pool address for say three servers. They get three different NTP servers to point at from the DNS queries they generate.

So are we going to move some of the NTP features into DHCP, or accept where the boundaries are and let each system do what it's good at?

Tony Flavin

-----Original Message-----
From: ntpwg-bounces+anthony.flavin=[email-masked] [mailto:ntpwg-bounces+anthony.flavin=[email-masked]] On Behalf Of MORAND Lionel RD-CORE-ISS
Sent: 09 December 2007 13:53
To: Danny Mayer
Cc: DHC WG; NTP Working Group; Ralph Droms
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

Hi Danny,

In any case it was a statement on what the NTP wg should have had to do. I was just expressing my own understanding of the outcome of the dhc session. As I said, I met exactly the same troubles while defining a new dhcp option for locating pana agent in the network.

BR,

Lionel

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

---

From: Brian Utterback <[email-masked]>
Date: Mon, 10 Dec 2007 07:49:55 -0500

>     routing tables are updated to drop this traffic upstream.
To elaborate, not only is the IP address forever dead, the bandwidth 
continues to be consumed.
I suspect that if we see many more such situations, there will have to 
be a mechanism
installed in the Internet routers like the certificate revocation 
protocol in PKI. A way to
tell all routers everywhere that certain IP addresses are never to be 
forwarded.

Brian Utterback

---

From: Danny Mayer <[email-masked]>
Date: Mon, 10 Dec 2007 08:46:31 -0500

What I think I'd like to do is go back to basics and look at the targets
of dhcp requests/options and for each type look at what is the desirable
set of NTP configuration information each type would need. At least that
way I would understand what options would be needed. I'm finding it
rather difficult going from the the DHCP server/options forward without
knowing or understanding the targets.

Danny

MORAND Lionel RD-CORE-ISS wrote:
> Hi Danny,
> 
> In any case it was a statement on what the NTP wg should have had to
> do. I was just expressing my own understanding of the outcome of the
> dhc session. As I said, I met exactly the same troubles while
> defining a new dhcp option for locating pana agent in the network.
> 
> I think clear guidelines on this topic could be very useful. For
instance, instead of providing FQDN, it is often said that the dhcp
server could be just another user of the DNS, performing DNS lookup
before providing IP address(es) to the dhcp client. The foreseen
flexibility of the use of FQDN could be therefore provided while using
IP address(es) in dhcp options.
> 
> I have no strong opinion on this topic, being not a dhcp expert
myself. But as a "client" of the dhc wg, I'm interested by a clear
statement.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 10 Dec 2007 09:23:39 -0500

Harlen,
      Several people in Vancouver made the point in the DHC meeting that 
the option should support a list of NTP servers (including me).  By 
acquiring a list via DHCPv6, an NTP implementation can configure the 
pool option correctly.

Regards,
Brian

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 10 Dec 2007 07:58:30 -0800

----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "Richard Gayraud (rgayraud)" <[email-masked]>
Cc: "Danny Mayer" <[email-masked]>; "Ralph Droms (rdroms)" 
<[email-masked]>; "Alain Durand" <[email-masked]>; "NTP 
Working Group" <[email-masked]>; "MORAND Lionel RD-CORE-ISS" 
<[email-masked]>; "DHC WG" <[email-masked]>
Sent: Monday, December 10, 2007 4:49 AM
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

> continues to be consumed.

You mean like what the DLink devices did to Poul-Henning and my server's? We 
formally moved the San Jose NIST Server to a new ISP to address this.

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 10 Dec 2007 07:57:03 -0800

Brian and Harlan...
----- Original Message ----- 
From: "Brian Haberman" <[email-masked]>
To: "Harlan Stenn" <[email-masked]>
Cc: "Danny Mayer" <[email-masked]>; "Ralph Droms (rdroms)" 
Sent: Monday, December 10, 2007 6:23 AM

>> I like the *option* (or ability) to get a FQDN for an NTP server from 

I agree. Will there be autokey data available in that list as well?

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 10 Dec 2007 08:00:19 -0800

Again - Anthony the reason people can misuse NTP en-masse is because of the 
licensing model. If the license didn't let those people abuse NTP then they 
wouldn't do it...

Todd Glassey

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, December 10, 2007 1:23 AM
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

The main problem with the DHCP doing the DNS lookup on behalf of it's NTP 
clients, is that architecturally, that's a complete mess. The pools 
demonstrate why. Many NTP servers are set up with the same Pool address for 
say three servers. They get three different NTP servers to point at from the 
DNS queries they generate.

So are we going to move some of the NTP features into DHCP, or accept where 
the boundaries are and let each system do what it's good at?

Tony Flavin

-----Original Message-----
From: ntpwg-bounces+anthony.flavin=[email-masked] 
[mailto:ntpwg-bounces+anthony.flavin=[email-masked]] On Behalf Of 
MORAND Lionel RD-CORE-ISS
Sent: 09 December 2007 13:53
To: Danny Mayer
Cc: DHC WG; NTP Working Group; Ralph Droms
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

Hi Danny,

In any case it was a statement on what the NTP wg should have had to do. I 
was just expressing my own understanding of the outcome of the dhc session. 
As I said, I met exactly the same troubles while defining a new dhcp option 
for locating pana agent in the network.

I think clear guidelines on this topic could be very useful. For instance, 
instead of providing FQDN, it is often said that the dhcp server could be 
just another user of the DNS, performing DNS lookup before providing IP 
address(es) to the dhcp client. The foreseen flexibility of the use of FQDN 
could be therefore provided while using IP address(es) in dhcp options.

I have no strong opinion on this topic, being not a dhcp expert myself. But 
as a "client" of the dhc wg, I'm interested by a clear statement.

BR,

Lionel

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 10 Dec 2007 07:55:11 -0800

Boy is this commentary going to make me unpopular...  but the key to this 
problem isn't technology - its the License. The real failing in this matter 
is that the NTP License allows people to mis-use NTP  and to do whatever 
they want in hard coding the addresses into the product and based on the 
existing license and the modified license created by the IETF there never 
will be anyway to control the mis-use of NTP.

By the way - as I noted, the IETF's "Any and All" uses model further creates 
this same problem by making those that misuse of the protocol still within 
their licensing models so while it's nice that the WG is worried about 
bad-NTP users or vendor's who do things that damage those of us operating 
public access NIST servers.

As to the issue at bay here - The difference between the two forms (FQDN vs 
IP Addresses programmed into devices) is that:

    1)     While the inclusion of a FQDN means that there will  be a network 
transaction with a DNS server, the overhead of that is usually never added 
into the cost of operating a NTP service. It needs to be accounted for since 
the DNS option formally adds permanent overhead at the DNS level as well.

    2)    Hard coding a IP address into anything creates a permanent 
reliance on that IP address which ***WILL*** cause the same NTP overhead as 
the FQDN model but not the DNS overhead.

So the question is here whether the NTP License will mandate these 
requirements to use NTP and if it doesn't then this is a total waste of time 
since those that violate the license will not be culpable for that.

Sorry it is what it is...

Todd Glassey

----- Original Message ----- 
From: "Alain Durand" <[email-masked]>
To: "Richard Gayraud (rgayraud)" <[email-masked]>; "Danny Mayer" 
Sent: Sunday, December 09, 2007 10:54 AM

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 10 Dec 2007 08:34:27 -0800

> abide by the rules? ... My DNS servers are still absorbing overhead and the 

I seem to recall you said you were the victim of a hardcoded IPv4
address.  How are your nameservers involved?

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 10 Dec 2007 08:52:46 -0800

On Mon, Dec 10, 2007 at 09:23:52AM -0000, [email-masked] wrote:
> Many NTP servers are set up with the same Pool address for say three
> servers. They get three different NTP servers to point at from the

I don't understand the complaint.  Is it that you fear DHCP can only
give out single IPv4 addresses?

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 10 Dec 2007 09:02:02 -0800

David
The SJ Server was hit by both misuses by different players.  FWIW We had the
same problem that Poul-Henning did only Poul-Henning's settlement was
apparently exclusive of anyone who suffered damage and is assumed by the
public to have solved the problem entirely, which we all know isn't true. We
had to move the server and increase its bandwidth because of this. It was a
pain.

Todd Glassey

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 10 Dec 2007 09:06:04 -0800

> > when they will have to design new options for the same usage.

At present it only says one word on the subject; 'late-binding'.

What I thought that "obviously" meant was, "DNS is the obvious right
tool for the job if you want the (IP address or SRV or whatever) to
be discovered at a time much later than DHCP's completion, such as
from user input or at the very start of some alternate chain of
events."

So for example, t'were it me, I'd configure an rfc1035 domain name
for the outbound mail gateway.  This is a function that happens in
a practically random way; whenever the user sends mail.  It isn't
an event that follows from a reconfiguration event, nor something
that is 'always on'.  It's always done after bootstrapping is
fully complete (or else your mailer is stuck in 'offline mode').

It's also something that isn't presently carried by DHCP, nor is it
likely to be preferred to be.

So, it could probably say more.

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 10 Dec 2007 09:22:37 -0800

David
I want to also point out I don't hold Poul-Henning accountable for this
fiasco or the scam that was perpetrated on the rest of the Time Service
Operator's that this abuse hurt, it was the commercial player who pulled
this one off.

The funny part is that this list didn't react to the "Kamp Settlement" 
either,
in pointing out that a single settlement for those damages would leave the
rest of those who suffered those damages, footing the bill for loading those
actions caused forever essentially.

Todd Glassey

---

From: Rob Seaman <[email-masked]>
Date: Mon, 10 Dec 2007 10:04:18 -0700

On Dec 10, 2007, at 8:55 AM, TS Glassey wrote:

> the key to this problem isn't technology - its the License.

and...

On Dec 10, 2007, at 6:46 AM, Danny Mayer wrote:

> What I think I'd like to do is go back to basics [...] I'm finding  
> it rather difficult going from the the DHCP server/options forward  
> without knowing or understanding the targets.

and...

On Dec 10, 2007, at 5:49 AM, Brian Utterback wrote:

> I suspect that if we see many more such situations, there will have  
> to be a mechanism
> protocol in PKI. A way to tell all routers everywhere that certain  
> IP addresses are never to be forwarded.

and...

On Dec 10, 2007, at 2:23 AM, <[email-masked]> <[email-masked] 

> The main problem with the DHCP doing the DNS lookup on behalf of  
> it's NTP clients, is that architecturally, that's a complete mess.  
> [...]
>
> So are we going to move some of the NTP features into DHCP, or  
> accept where the boundaries are and let each system do what it's  
> good at?

and...

On Dec 9, 2007, at 6:52 AM, MORAND Lionel RD-CORE-ISS wrote:

> But as a "client" of the dhc wg, I'm interested by a clear statement.

and on and on.

All this tussling over details has been very engaging.  The exchange  
about motorcycles was particularly entertaining.  However, positional  
negotiations are a poor way to arrive at a functioning consensus.   
There seems to be some notion that we're involved in some zero sum  
game and that there have to be losers as well as winners.  Rather,  
this is a pure architectural design issue and the NTP edifice of all  
will either stand or fall together.

The diversity of points of view is a strength of the working groups,  
not a weakness.  Surely the need that is most evident here is to carry  
out a coherent analysis of the trade-offs.  This is a rich literature  
in system engineering, see for example:

	http://www.sie.arizona.edu/sysengr/publishedPapers/quantitativeMethods.pdf

The first step to studying the trade-offs between several options is  
to coherently describe those options.  Do we have a half-page  
description for each of the major variations that have been  
discussed?  You can't tell the players without a scorecard.  The  
proposed solutions can be purely technical - or purely legal.

A lot of us are skeptical of licensing.  The way to make the case is  
to provide explicit data, scoring functions, figures of merit,  
sensitivity and risk analyses - not to simply state that licensing  
will save the day.  A discussion and detailed dissection of a business  
model(s) would be entirely appropriate, too.  How will corporate  
entities react to licensing?  How will they react to changes to  
technical standards?

By all means include both the status quo - and blue-sky solutions - in  
the matrix of options to be scored.  We may be convinced already that  
neither extreme will satisfice - but 1) we may be wrong, and 2)  
including such extremes sharpens the challenge to the other proposed  
solutions.

Simply elucidating the criteria key to such a trade-off is worth the  
price of admissions to get us past comparing apples and oranges.  Yes,  
yes - we want to keep inane vendors from fielding devices tailor made  
for D.O.S., but is this really a complete list of the important NTP/ 
DHCP issues?

NTP is as much a risk factor to DHCP as DLink has been to NTP.  Should  
there be an attempt to characterize the full range of risks before  
deciding which will result in actionable changes to technology (or to  
its licensing)?

Rob Seaman
National Optical Astronomy Observatory

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Dec 2007 08:23:53 +1100

The NTP servers option is for pointing CPE / in house
	equipment at NTP servers.  Preferably those servers should
	be run by the ISP or are in-house.  The servers pointed to
	the NTP servers option should be the ones configured to use
	the pool servers.

	The deployment model with DHCP is different to the manual
	deployment model.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 10 Dec 2007 21:39:53 +0000

Todd,

> public access NIST servers.

I think in some ways you have a great point here.

And as proof of concept, I invite you to show how well this will work by
using these very same techiniques to solve something like the spam,
phishing, or malware problems.  I won't ask for a "finish-line" solution
(ie, "At 200902281234, the last piece of spam email was sent", but if
you can get that race actually started then I'll have much more
confidence that this will work.

And just to ask, what are some of the 2nd and 3rd order effects of your
proposal? I'm talking holistically here.  Like "the wall" in a General
Systems Theory analysis.

H

---

From: Chuck Anderson <[email-masked]>
Date: Mon, 10 Dec 2007 12:39:20 -0500

> licensing model. If the license didn't let those people abuse NTP then they 

Bull.  People will abuse things even if they aren't "allowed" to by 
some license agreement.  Just look at all the vendors out there who 
are violating the terms of the GPL license.  Restrictions on use are 
evil and not compatible with open source software.
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Tue, 11 Dec 2007 12:45:47 -0500

> evil and not compatible with open source software.

Why are we even discussing licensing here? This has nothing whatsoever
to do with licensing. This is a red herring.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 11 Dec 2007 14:42:34 -0500

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 11 Dec 2007 11:50:09 -0800

My apologies Danny (/list). You are right this is the technologies list and 
not the
legal list.

Todd

---

From: Danny Mayer <[email-masked]>
Date: Wed, 12 Dec 2007 21:28:18 -0500

>         pool FQDN rather than a single NTP server name.

There is an even simpler solution to this. Have the DNS name remain but
have it point to 127.0.0.1 or ::1. That way only itself is impacted.
Normally one isn't supposed to do this but in this case it's good
solution and solves just about every problem and does not affect other
nodes in the network.

Danny

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2007 19:37:40 -0700

> have it point to 127.0.0.1 or ::1. That way only itself is impacted.

That doesn't stop the traffic to the name server.

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 12 Dec 2007 18:53:03 -0800

The only thing that possibly could stop the traffic to the name server is 
some external controls (like that thing I cant talk about on this list :-)

Todd
----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: "Danny Mayer" <[email-masked]>
Cc: "DHC WG" <[email-masked]>; "Ralph Droms (rdroms)" <[email-masked]>; 
"NTP Working Group" <[email-masked]>
Sent: Wednesday, December 12, 2007 6:37 PM
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2007 20:37:45 -0700

> some external controls (like that thing I cant talk about on this  

We can talk about the giant two-headed purple elephant that's sitting  
in the room here with me instead, if you like.   It's just as real.

There is no fix for the "idiotic misconfiguration" problem.   All the  
wishing in the world isn't going to change that.

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 12 Dec 2007 19:42:38 -0800

----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Ted Lemon" <[email-masked]>; "Danny Mayer" <[email-masked]>; "DHC 
WG" <[email-masked]>; "Ralph Droms (rdroms)" <[email-masked]>; "NTP 
Working Group" <[email-masked]>
Sent: Wednesday, December 12, 2007 7:37 PM
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

> We can talk about the giant two-headed purple elephant that's sitting  in 
> the room here with me instead, if you like.   It's just as real.
>

sure there is. But this group doesnt want to talk about how it would work 
because it has nothing to do with technology.  The funy thing is your saying 
that there isnt such a cure doesnt change that there in fact is just such a 
cure. Its like running into the sun and proclaiming in pitch black outside. 
You proclamation doesnt change that if the license was restrictive and it 
was violated that the commercial consequences from that would corral the 
market... sorry but it is what it is Ted.

If you want to prove me wrong allow me to change the license so that those 
damaged by its misuse have a contractual claim against those causing the 
damage.

Todd

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2007 21:36:48 -0700

> market... sorry but it is what it is Ted.

I'm just pointing out the obvious.   I'm sorry it's so difficult for  
you to see.   Let me illustrate with an example.   Remember when that  
router vendor hard-coded the NTP server IP addresses in their millions  
of boxes, and a well-known NTP server got so badly hammered that there  
was no fix?

They were legally liable for the damage they did.   Just like someone  
would be if they violated the license.   But the damage was still  
done, and couldn't be undone.   And so it would be with the license.    
So the license doesn't help - it doesn't stop the mistake that you  
with you could stop.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 12 Dec 2007 23:44:17 -0500

> the room here with me instead, if you like.   It's just as real.

I would prefer to do that actually. You cannot stop the traffic but you
can try and reduce it. A positive answer to a DNS query will reduce
subsequent queries. Removing the answer will cause the query to be tried
again by misbehaving clients.

> wishing in the world isn't going to change that.

agreed.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 13 Dec 2007 00:06:25 -0500

> shipping a similar product with a hard-coded FQDN...

A DHCP server sending out a fixed address will likely cause an
amplification attack since every dhcp client will then query that same
IP address. A FQDN can result in different addresses being used by each
client since each client can get a different IP address as an answer if
the authorative DNS is configured to return multiple A and/or AAAA
records. The owner can also change the address from time to time and
just update the DNS with new information. Changing the address to
127.0.0.1 and ::1 will result in it sending queries to itself with a
terrific reduction in IP traffic.

Danny

---

From: <[email-masked]>
Date: Thu, 13 Dec 2007 08:26:55 -0000

Except the name server will only get the request once (assuming it
resolves to something), Whereas the Hard-coded IP address would be
getting a request every 64 seconds or so. Much less traffic.

All of this misses the point though. If a manufacturer does something
really dumb, as they have in the past, then their are problems for all.
However, I don't think that this is solvable within the NTP
specification itself. The best answer is education as a carrot and the
threat of a whole load of bad press as a stick.

Tony Flavin

-----Original Message-----
Ted Lemon
Sent: 13 December 2007 02:38

---

From: Hal Murray <[email-masked]>
Date: Thu, 13 Dec 2007 00:55:25 -0800

> Whereas the Hard-coded IP address would be getting a request every 64
> seconds or so. Much less traffic.

You are assuming a particular retransmission heuristic.

In one prominent case, the retransmission rate was onc per second.

A sane approach would use exponential backoff to get a long term average load 
that is much less than every 64 seconds.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Thu, 13 Dec 2007 11:06:52 +0100

I think it does (help to reduce the traffic to the name server):

  - The NTP client will keep trying 127.0.0.1 for some time before
    re-resolving (NTP associations take some time to fail when
    moblized).

  - SOHO routers often embed NAT and act as DNS servers regarding
    the home network. So they will receive this NS traffic, and
    should catch the retries.

Richard.

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: jeudi 13 décembre 2007 03:38
> To: Danny Mayer
> Cc: Richard Gayraud (rgayraud); DHC WG; NTP Working Group; 
> Ralph Droms (rdroms)
> > There is an even simpler solution to this. Have the DNS 
> name remain  
> > but

---

From: Brian Utterback <[email-masked]>
Date: Thu, 13 Dec 2007 08:35:43 -0500

> So the license doesn't help - it doesn't stop the mistake that you  

I think I see Todd's point. The liability scales with the intentional
malice. With increased liability comes increased responsibility (
to paraphrase Spiderman).

However, I don't see how you could license the protocol and it is
from incorrect implementations that we need protection, so anything that
decreases the likelihood of using the reference implementation is a
net loss in my opinion.
-- 
blu

"You've added a new disk. Do you want to replace your current
drive, protect your data from a drive failure or expand your
storage capacity?" - Disk management as it should be.
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2007 06:44:08 -0700

> getting a request every 64 seconds or so. Much less traffic.

This isn't actually true - because it's a DHCP server's configuration  
that we're worried about, it's entirely possible that every device  
that gets an address from it will individually query the name server.

Having said that, I can't dispute your conclusion.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2007 06:47:52 -0700

On Dec 13, 2007, at 6:35 AM, Brian Utterback wrote:
> malice.

Failing to read a license isn't malice.   But again, I don't disagree  
with your conclusion.   If I saw a license like that on the source  
code, I'd just write new source code.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 13 Dec 2007 08:47:52 -0500

Brian Utterback wrote:
>> done, and couldn't be undone.   And so it would be with the
>> license.    So the license doesn't help - it doesn't stop the mistake
>> that you  with you could stop.
>>
> 

Please. This is not a license problem and you cannot solve it through a
license. Please stop talking about licensing like it was a magic wand.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Dec 2007 01:39:26 -0500

> acquiring a list via DHCPv6, an NTP implementation can configure the

Not really. pool and lists of servers are equivalent but only in the
sense that pool needs a FQDN while a list is a set of server addresses
and you would configure them as individual server addresses. However,
you can look up a FQDN but an IP address is fixed for the duration,
whatever that duration may be.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Dec 2007 01:41:38 -0500

> deciding which will result in actionable changes to technology (or to  

This is exactly why I asked for a clear statement on what the target
DHCP clients are for the dhcp options being discussed. After that you
can discuss what is the best way to configure those target clients and
at that point once we have agreement on that (or at least an idea of
what is needed) we can provide a recommendation on the options.

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 16 Dec 2007 06:05:33 -0800

Who maintains the pool list by the way?

Todd Glassey

----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "Brian Haberman" <[email-masked]>
Cc: "Ralph Droms (rdroms)" <[email-masked]>; "Alain Durand" 
<[email-masked]>; "NTP Working Group" 
<[email-masked]>; "MORAND Lionel RD-CORE-ISS" 
<[email-masked]>; "DHC WG" <[email-masked]>
Sent: Saturday, December 15, 2007 10:39 PM
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 16 Dec 2007 06:07:17 -0800

----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "Rob Seaman" <[email-masked]>
Cc: "NTP Working Group" <[email-masked]>; "DHC WG" <[email-masked]>
Sent: Saturday, December 15, 2007 10:41 PM
Subject: Re: [ntpwg] [dhcwg] NTP option: IP address and/or FQDN

>>> IP addresses are never to be forwarded.

NEA (the IETF's new effort would do this pretty well).

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Dec 2007 12:23:34 -0500

Hemant Singh (shemant) wrote:
> Folks,
> 
> Sorry for the delayed reply. I also have not been following this thread
> at all. I have just heard in the IETF meeting about using FQDN vs. IP
> address discussion or using both.
> 
> I would like to point folks to the MGCP VoIP protocol in RFC 3435 where
> they also had to decide between FQDN and IP address. See section 2.1.4
> of this RFC where Call Agent is the server that serves MGCP clients to
> talk with the Call Agent. 
> 
> My 2 cents.
> 
> Hemant 

This section of RFC 3435 is interesting though not really an exact
parallel. That section basically wants you to use FQDN and use all of
the addresses if one fails. That part is what we want to do especially
with the pool. It also, interestingly, wants it to keep track of the TTL
of the records. Unfortunately getaddrinfo() and friends don't return
that information, so it's hard to see how that part could be implemented
without going to a raw DNS protocol. This gets really interesting with
NTP which may jump the time by any amount at least initially, so you
don't know what the TTL left is.

MGCP also operates in a totally different manner since VOIP, although it
can daisy-chain through a number of proxies is limited to the number of
systems likely to be involved. NTP on the other hand expects every node
in a network to be using NTP.

Danny