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

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Thu, 8 Nov 2007 16:41:08 +0100

Hello, 

We have just submitted a new draft proposing an NTP option for DHCPv6. 

The goal of this draft is to standardize automatic configuration of
NTPv4 (IPv6) clients over DHCPv6.
We think there is currently no satisfactory solution for configuring
NTPv4 clients from a centralized DHCPv6 server.

We'd be very happy to hear feedback about the draft, and I'm planning to
ask that it becomes a WG draft eventually.

Here's a url:

http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt

Thanks,

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

---

From: Brian Utterback <[email-masked]>
Date: Thu, 08 Nov 2007 12:32:26 -0500

I think that you should eliminate the minpoll, maxpoll, I and B fields,
which would mean you could eliminate the reserved field, although you
might want to keep it.

As a policy request, maxpoll is useless. How can you specify the maximum
poll interval? That just doesn't make sense.

The minpoll parameter make some sense, but since you are depending on
the client implementation to obey it, it seems likely that any such
implementation will either get minpoll right or not. If it gets it
right, then the minpoll parameter is not needed, and if it gets it
wrong then it probably won't be obeyed anyway.

I just don't see the point in having the I field since that is pretty
much a client side kind of issue. The use of the B field might be
useful in some weird circumstances, but I don't see this as something
that the server could know.

The multicast looks okay as is, although I would suggest that there be
advice to leave delay as 0 if possible. The proper delay doesn't seem to
me to be likely to be known by the server and possibly different across
a subnet.

I am not sure about the idea of allowing multiple instances. Is that
normal for DHCP? I understand the need to have multiple addresses
returned, I would have thought a single list would have made more sense,
but that is a DHCP thing, not a NTP thing, so I leave that to the DHCP
experts.

-- 
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: "Mark Elliot" <[email-masked]>
Date: Thu, 8 Nov 2007 09:38:05 -0800

Great idea! I will take a look at the draft! I think its an idea that is
needed! 

-----Original Message-----
From: ntpwg-bounces+melliot=[email-masked]
[mailto:ntpwg-bounces+melliot=[email-masked]] On Behalf
Of Benoit Lourdelet (blourdel)
Sent: Thursday, November 08, 2007 7:41 AM
To: [email-masked]; [email-masked]
Cc: Richard Gayraud (rgayraud)
Subject: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

Hello, 

Here's a url:

Thanks,

Richard and Benoit

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 08 Nov 2007 17:52:23 +0000

Guys,

Thanks for doing this.  I've been sporadically discussing this with
David Hankins.

I have added the URL below to the appropriate section at:

 http://support.ntp.org/Dev/GettingNtpdItsConfiguration

and for those of us who prefer using the TWiki over email for
development discussion, I volunteer the above as a place to (also) have
any discussion about this.

H
--

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Sat, 10 Nov 2007 00:43:41 +0100

Hello,

A possible usage of all the NTP parameters specified in the new options
is to configure router gateway . In that scenario, the goal of a Service
Provider or an Enterprise IT  is to autoconfigure the gateway as much as
possible, including some NTP client behavior, in order to keep the
control. An additional benefit is that the gateway can be shipped to
remote sites virtually without any configuration while keeping full
control of the NTP behavior.

Following that line of thought, I may still see a need for  "minpoll,
maxpoll, I and B fields".

Considering a central DHCP server, the use of remote-id [RFC4649] or
just link-id may tell the server from where 
the request is coming then giving it the knowledge of the delay to
apply.
In the case of a DHCP server hosted by the first hop, the DHCP server is
well positioned to know the delay.

Considering the current option format which includes more than IP
addresses, the choice of multiple occurrences of the 
 same option looks sensible. Should we reduce the new options to IPv6
addresses only, a list makes more sense.

Benoit

-----Original Message-----
From: Brian Utterback [mailto:[email-masked]] 
Sent: Thursday, November 08, 2007 6:32 PM
To: Benoit Lourdelet (blourdel)
Cc: [email-masked]; [email-masked]; Richard Gayraud (rgayraud)
Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

The minpoll parameter make some sense, but since you are depending on
the client implementation to obey it, it seems likely that any such
implementation will either get minpoll right or not. If it gets it
right, then the minpoll parameter is not needed, and if it gets it wrong
then it probably won't be obeyed anyway.

I just don't see the point in having the I field since that is pretty
much a client side kind of issue. The use of the B field might be useful
in some weird circumstances, but I don't see this as something that the
server could know.

> We'd be very happy to hear feedback about the draft, and I'm planning 
> to ask that it becomes a WG draft eventually.
> 
> Here's a url:
> 
>  

--
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: Brian Utterback <[email-masked]>
Date: Sat, 10 Nov 2007 07:21:23 -0500

> control of the NTP behavior.
I'm sorry, but I still don't see it. Are you saying that the router
is a DHCP client and gets the server from DHCP? Okay fine,
but how does minpoll, maxpoll, I and B get used? I still
don't see the point of maxpoll here at all, that is, I don't even
get what it means to the client to get this value imposed.
See, minpoll says "do not poll more often than this",
but maxpoll would mean "do not poll less often than this".
This just doesn't make sense to me.

> maxpoll, I and B fields".

Now, I could see the I and B meaning "do not do this" rather than "do 
this". If I and B are 0, then
it means to do whatever you want, but if they are 1, then do not do it. 
It doesn't
make sense to tell a client to use iburst when it wasn't going to 
anyway. Same with burts, although
in a strange set of ceircumstances I could imagine the need for burst 
being known centrally,
so maybe the B flag makes some kind of sense as is.
> well positioned to know the delay.

Oh, agreed, it is possible for the delay to be known. But I just don't 
think it is likely
that it will ever be used correctly in that scenario. All I said is that 
it should generally
be left at 0 unless there is a good reason not to.

> addresses only, a list makes more sense.

Okay.

--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.

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 11 Nov 2007 04:33:58 +0000

Brian,

We need to think about scenarios for server discovery. Without prejudice 
on the message formats, a virgin client might be directed to either:

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.

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.

3. Specify a list of <addresses> to send to, each together with the mode 
and  minpoll. I don't think maxpoll is useful either.

4. Specify a manycast server group address, ttl limit and beacon interval.

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.

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.

Dave

---

From: Brian Utterback <[email-masked]>
Date: Sun, 11 Nov 2007 07:37:59 -0500

David L. Mills wrote:
> 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.

> The client should be smart enough to use/not use iburst and preempt 

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?

Okay.
> 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.

> 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

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 11 Nov 2007 17:06:47 +0000

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
> This argues for having another possible field/format, where a string 
> for lookup is given.
>
>>
> 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
> 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.
>
>
>>
> 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.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 11 Nov 2007 10:52:59 -0800

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

---

From: Danny Mayer <[email-masked]>
Date: Sun, 11 Nov 2007 23:34:31 -0500

> http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt

I reviewed this draft, even though I'm in the middle of reviewing the
autokey draft, and I find it misconceived.

1) The draft seems geared to only the reference implementation of NTP
rather than being implementation agnostic. There is also reference to
SNTP which the reference implementation is not and in any case SNTP
implementations are likely to have different terms and requirements for
configuration.

2) The server must never be specified as an IP address but always as a
DNS name. If you wish to use only IPv6 there are options to do so. It is
easy to configure a DNS server for the specific purpose if it is local
to the site. We have had too many incidents of hardcoded addresses which
cause major incorrect usage of ntp servers not to mention clients that
continue to try and use the same server months and even years after it
has stopped being an NTP server. The only time you might use an IPv6
address here is if the address is site-local or link-local. A future
enhancement to the reference implementation will requery the DNS for new
address information in the case of failure of responses from the
configured NTP server and will allow easy migration of NTP services.
This also ignores the pool option now available in the development NTP
reference code.

3) The additional fields that you specify should *never* be set unless
you understand exactly what you are doing. We always recommend the use
of iburst (and not i-burst BTW) so it's not necessary to specify this.
The use of burst contradicts the last sentence of the last paragraph of
Section 2.1. The use of minpoll and maxpoll is similarly bad for exactly
the same reasons. You need to have very special reasons to set these to
anything other than the default.

4) There is no autokey option even though the Section 6 discusses
security considerations which seem to be for DHCPv6 only without any
consideration whatsoever for NTP. These packet options provide a
convenient way of distributing autokey keys to the clients but it is not
 an option under this draft

5) The multicast option similarly has flaws. The only practical values
are FF02::101 and FF05::101 which are reserved for NTP usage unless you
are planning to use other ones. The delay however is position-dependent
on the wire and a DHCPv6 server is never going to know what that delay
is likely to be so there is no way for it to determine what to set it to.

6) I have not read either RFC 3315 or RFC4075 but section 6 Security
Considerations totally ignores NTP and other time issues. If you are
provisioning NTP on the client you *cannot* use any authentication
mechanism that assumes that the time on the client has any valid value.
Furthermore there is nothing to prevent the client receiving invalid NTP
configuration options. If DHCPv6 itself is using time-dependent
authentication mechanisms it is flawed, possibly fatally so since the
client will not have the correct time in the first place. I see no way
to fix this nor how to prevent a rogue system sending its own packets
and having them accepted as valid.

I'm going to stop here but I recommend that this draft does not proceed
and needs to be totally rewritten.

Danny

---

From: Brian Utterback <[email-masked]>
Date: Mon, 12 Nov 2007 10:55:36 -0500

> separately. The DHCP server would be responsible only for the opaque key ID.

I see what you mean, but I am not sure about the use case here.
Certainly if the keys are pre-configured on both the clients and the
servers, then the key id is a must.  But I am concerned about the
roaming laptop mode here. If I bring my laptop to a network, I would
like to be able to get enough info from the DHCP server to allow me
to securely connect to the server and have it be authenticated. Perhaps
a public key distribution scheme?

> another issue. I'm assuming the DHCP server is behind the firewall.

Right. Out of the realm of our discussion.

> This does not seem useful.

If you get a broadcast address to use then you should be a broadcast
client. I don't see the usefulness of a DHCP client being a symmetric
anything. Perhaps this is a failure of imagination on my part.

-- 
blu

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 13 Nov 2007 03:33:24 +0000

Brian,

Roaming laptops is what NTP Autokey is designed for. All a properly 
configued laptop would not need anything except a flag that says to use 
it and possibly the public group key. Heck with NTP; use Autokey to 
authenticate the server for anything.

Dave

Brian Utterback wrote:

>> 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.
>
>
>> (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.
>
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 12 Nov 2007 09:02:06 -0500

[This is a resend since the dhcpwg SMTP list server rejected my email
for no obvious reason]

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 13 Nov 2007 09:15:54 -0800

Dave -
There is ANOTHER issue facing this WG and that is that just like the 
"description's" of the NTP Process the AutoKEY system needs to be 
accountable to a standard which allows data captured from such a source to 
be admitted in a court of law and now that there are formal standards many 
of the cool methods of delivering time over networks from a physics 
perspective dont mean squat now to the Courts.

The case that set this standard was called Lorraine v Markel CIVIL ACTION 
NO. PWG-06-1893 and it came out of the US District Court in Maryland on May 
4th 2007 from a Judge (a Chief Magistrate Judge) by the name of Paul Grimm. 
Google the actual ruling here: 
http://www.google.com/search?q=lorraine+v+markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF

Bluntly, the world changed a tad on May 4th and while this effort is pointed 
at the physics of operating NTP, these new controls impact any work with any 
other Standardized Protocol as well... What this means to people who NTP is 
a part of their commercial offering, is that they MUST apply these new 
standards to this code and its support as well, or they must use their own 
internal code-base's rather than depending on one here. I think this ruling 
re-set the bar heighth, and it is now much higher - even for an Academic 
Entity. As to how this effects this WG, we need to build tools that are 
capable of being used in these key application contexts or this protocol 
will likely be ultimately replaced.

Just my two cents,

Todd Glassey

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Nov 2007 10:41:30 +0100

Todd,

> http://www.google.com/search?q=lorraine+v+markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF

A massive triumph of legal formalism over common sense, IMHO.

> will likely be ultimately replaced.

I'm a little slow this morning... I can't figure out how this standard applies
to NTP. Can you explain what it means, from a protocol and a software point of
view (plain English preferred, technical gibberish okay, no legalese please)?

- --
Shane

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 14 Nov 2007 06:57:37 -0800

----- Original Message ----- 
From: "Shane Kerr" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 14, 2007 1:41 AM
Subject: Re: [ntpwg] Digital Evidence Standards and a statement that this 
directly effects NTP and its use...

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Todd,
>
> TS Glassey wrote:
>>

Yeah - I hear this same statement from Systems Administrator's - the same 
buch of guys and girls that keep failing those IT Security Audits... so I 
look to their commentary as their way of getting out of doing a honest day's 
work. If that statement offfends you as much as a buch of Systems 
Administrator's trying to control the world of Information Security becuase 
they are too freaking lazy to 'do it right', well... you explain to me why 
so many folks fail those audits again and again ???

This ruling sets the world of the System Administrator on its arse and did 
so globally by eliminating the concept that there is no-such thing as a 
digital original. In fact there is and the issue is that while document 
conterfeiting used to be more difficult, now a days it is as easy as saying 
'cp file1-name counterfeit-file name'...

> to NTP.

OK Shane, I personally think the ruling means that there are now 
requirement's for tight and reliable evidence ganthering and maintanence in 
all aspects of the use of something creating digital evidence, especially 
when those processes run automatically below the general control of the 
end-user... It sets a new bar-height for demonstrating the quality of the 
system and the security in place for its use. So in some senses its NOT the 
NTP protocol itslef but its use that are impacted. Certianly the integrity 
of the code management process will become a real issue.

For what its worth this matter is before the US Appellate Court right now to 
get it advanced into real precedent "standard" from the persusave precedent 
it is now and all concerned will need to understand this and comply with it.

> Can you explain what it means, from a protocol and a software point of

1)    REAL reliable NTP user models MUST be developed. That means Use 
Statment's and what the system will provide in the form of timestamps per 
second based on some baseline metric.

2)    A real TEST PLAN needs to exist for each program in the NTP Suite and 
that will  be executed by the supporting party. Its MUCH better for the 
commercial relying parties if they dont develop the core of this TEST PLAN 
but rather just customize the one used to pre-certify the operations of NTP 
in their environment.

3)    The entity holding the Code Base will have to take full responsibility 
for that as well, meaning that they will become liable for screwup's or 
damages that people suffer using the code.

4)    The "No warranty for fitness" language needs to be removed from the 
license IMHO, because if there is no accountability in the time transfer 
process there is no point in using it.

Hmmm- what would that mean for the ISC by the way? - could it step to the 
plate and put in place a secured and audited change control process and 
service? Could it and will it bear the expense of those?

Just my two cents.

Todd Glassey

>
> - --
> Shane
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHOsLAMsfZxBO4kbQRAk8uAKCjfp0XvQUKcCat2oBvUDOBgZ39fwCfWtcN
> 5ejJMaSb3blH3h/9kohaioo=
> =4DDy
> -----END PGP SIGNATURE-----

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 14 Nov 2007 16:24:25 +0000

Ted,

There may be much merit in the case you cite; however, this is a 
volunteer group and neither a cabal of lawyers nor capable of high 
finance. If you have a specific plan, are willing to direct and 
contribute to it and suffient labor is available, let's do it. If you 
have very specific proposals that can be implemented without serious 
committment of effort, let's hear that, too. Better yet, find a lawyer 
needing to fill out his required 100 hours of pro-bono time per year and 
have him translate your legal issues to actionable projects.

Dave

TS Glassey wrote:

> accountable to a standard which allows data captured from such a 
> source to be admitted in a court of law and now that there are formal 
> standards many of the cool methods of delivering time over networks 
> from a physics perspective dont mean squat now to the Courts.
>
> The case that set this standard was called Lorraine v Markel CIVIL 
> ACTION NO. PWG-06-1893 and it came out of the US District Court in 
> Maryland on May 4th 2007 from a Judge (a Chief Magistrate Judge) by 
> the name of Paul Grimm. Google the actual ruling here: 
> Bluntly, the world changed a tad on May 4th and while this effort is 
> pointed at the physics of operating NTP, these new controls impact any 
> work with any other Standardized Protocol as well... What this means 
> to people who NTP is a part of their commercial offering, is that they 
> MUST apply these new standards to this code and its support as well, 
> or they must use their own internal code-base's rather than depending 
> on one here. I think this ruling re-set the bar heighth, and it is now 
> much higher - even for an Academic Entity. As to how this effects this 
> WG, we need to build tools that are capable of being used in these key 
> application contexts or this protocol will likely be ultimately replaced.
>
> Just my two cents,
>
> Todd Glassey
>
> ----- Original Message ----- From: "David L. Mills" <[email-masked]>

---

From: Danny Mayer <[email-masked]>
Date: Thu, 15 Nov 2007 23:26:19 -0500

Brian Utterback wrote:
> 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.

DHCPv6 uses IPSEC for security. However, as I pointed out in my own
response, if you are provisioning an NTP server then it means that NTP
is not running at the time and any security that requires reasonably
close timestamps at both ends is likely to fail.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 15 Nov 2007 22:19:16 -0500

> maxpoll, I and B fields".

No you don't, as I stated elsewhere, iburst should always be used by
default but neither burst nor adjustments to the minpoll and maxpoll
values should be made except under very special circumstances. burst is
extremely unfriendly to the server and minpoll and maxpoll can make the
algorithms used in NTP less stable. You really have to be an expert in
NTP and its algorithms to change these from their default value.

> well positioned to know the delay.

That's not true. The delay is between the NTP client and the NTP server
and includes delays of any intermediary points like a router.

> addresses only, a list makes more sense.

No you should be using a DNS name and not IP addresses. The client then
can use the DNS to lookup the name and get a bunch of IP addresses. The
new pool option will then configure all of them (up to 10) for NTP servers.

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 Nov 2007 10:33:08 -0500

Ralph Droms wrote:
> DHCPv6 does not use IPSEC between the client and the server.  Rather,
> it uses a shared key for authentication and message verification.
>
> It is possible to use IPSEC between a relay agent and a server.
>

Thanks for the correction. As long as the shared key authentication does
not depend on a valid time in any way then this is fine.

Danny
> - Ralph
>
> On Nov 15, 2007, at Nov 15, 2007,11:26 PM, Danny Mayer wrote:
>
>> Brian Utterback wrote:
>> dhcwg mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 Nov 2007 15:51:00 -0500

David W. Hankins wrote:
> On Thu, Nov 15, 2007 at 11:26:19PM -0500, Danny Mayer wrote:
>> Brian Utterback wrote:
> Although DHCPv6 does have a signature verification mechanism, it does
> not encrypt carried configuration.
> 
> So unless you're transferring public keys for NTP, there's an exposure
> problem I'm not sure you're aware of.  Just making sure you know, I'm
> not familiar with the keys discussed in this context.
> 
I am aware of it, thanks. It was part of what I was trying to hilight.
> 
> Next, I want to make sure that your expectations of the services
> DHCPv6 can provide are set appropriately.
> 
> Others have pointed out DHCPv6's authentication mechanism uses shared
> secrets; there is also a similar mechanism for DHCPv4, RFC3118
> "Authentication for DHCP Messages" (which 3315 says its method is
> based upon).  You should know that this has not been well deployed in
> DHCPv4, and it shares very similar design features to RFC3315's
> authentication.  The primary problem is that for most networks in
> operation, "configure a shared secret on all of your clients" defeats
> the purpose of the "Dynamic" in DHCP.  If you have to manually
> configure all your clients with a key, why bother using DHCP at all?
> You may as well manually configure them all with the final
> configuration state and skip a lot of needless machinery.
> 

Well we are only responding to an effort to do this via DHCP. We cannot
say for sure that this is the best method to do this and obviously it's
not the only method. Of course you might say why bother with DHCP for
that matter?

> So although it can be done, no one actually does it.
> 
> I understand that 3315 authentication has precisely the same barrier,
> that the client's keys are distributed "out of band."  I have no
> reason to think that IPv6 makes operators more interested in manually
> configuring clients to obtain dynamic configuration state than they
> have been in IPv4.
> 
> This is surmountable I think, it's possible the authentication methods
> might be extended and improved to remove this barrier to adoption, but
> there have been zero drafts to date which attempt to do so.
> 
> So, expectations.
> 
> 
> Your expectations should be:  No one will use 3315 authentication as
> it is, and therefore you will not have a cryptographically secured
> means to deliver this information on real networks.  People will,
> however, take special care with their DHCPv6 protocol packets on their
> networks (firewalling, etc, just as many always have done in IPv4),
> and there exists the potential for improvement and actual deployment
> of cryptographic trust here at some future date.

Agreed.

There are a whole slew of issues regarding provisioning of a system
during the booting process (and other times) that need to be worked out.
Specifically the network configuration and booting order of network
configs for DHCP, DNS, NTP, syslog, SSH, SNMP, etc.

At some point we really need to sit down and thrash out how to do this
in a secure way, in what order that it makes sense, error conditions,
etc. I'm not sure what the DHCP folks have been discussing so I bring it
all up and you can tell us what's already been solved and how.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 18 Nov 2007 22:58:51 -0500

Brian Utterback wrote:
>> just link-id may tell the server from where the request is coming then
>> giving it the knowledge of the delay to
>> apply.
> Oh, agreed, it is possible for the delay to be known. 

I consider that it is most unlikely for the DHCP server to know the
delay. Consider DHCP server D, client C and NTP server N. Each are in
different locations on the physical wire (wireless and other medium are
  similar). D may know its own delay to N but C is elsewhere on the
wire. You might be able to figure out the delay between D and C but how
does it relate to the delay between C and N? They are in different
locations on the wire. Is C closer to N, further away, on another
segment of the network?

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 18 Nov 2007 22:59:06 -0500

> me to be likely to be known by the server and possibly different across

No, there's a problem there too. A multicast client by default needs to
do authentication. That means that you either provide it a key file (or
the contents thereof) or you have to disable authentication in which
case you have to accept whatever you receive including rogues. You need
to pick one and act accordingly.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 18 Nov 2007 22:59:19 -0500

Dave,

I don't see how. The DHCP server and the NTP server are different nodes
on the network, unless the DHCP server is going to provide the NTP
service as well but that's a bad assumption to make even though the DHCP
server SHOULD be running NTP, if only for itself.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 18 Nov 2007 23:45:23 -0500

Ted Lemon wrote:
> On Thu, 2007-11-15 at 19:19 -0800, Danny Mayer wrote:
>   
>> No you should be using a DNS name and not IP addresses. The client
>> then can use the DNS to lookup the name and get a bunch of IP
>> addresses. The new pool option will then configure all of them
>> (up to 10) for NTP servers.
>>     
>  
> True, but not really important, since the DHCP server is normally
> configured with a domain name, not an IP address.   So it can do the
> lookup and return those ten IP addresses to the client.   So you get the
> same effect whether you send the FQDN to the client and make it do the
> lookup, or do the lookup on the server.   The advantage of doing it on
> the server is (1) you don't have to send an FQDN, and (2) the client
> doesn't need to have a resolver.
>
>   
I have no idea what configuring the DHCP server with a domain name has
to do with anything.
The addresses of NTP servers are not related to domain names.
Furthermore by looking up the IP
addresses for the client means that the client loses flexibility of
being able to do a new lookup when
one of those NTP servers stop responding to queries. This capability is
not in the currently
implementation of the NTP reference implementation but will be there in
the next few months.
There is *no* avantage to not sending a FQDN and plenty of disadvantages
to not doing so.
Would you like a list of vendors who have hardcoded IP addresses into
their devices without
permission of the operator of that NTP server causing headaches for not
just the owner of the
NTP Server but also for the users of those devices? The NTP reference
implementation expects
the existence of a resolver so you haven't gained anything.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 19 Nov 2007 05:17:33 +0000

Danny,

As I understand it, the DHCP client broadcasts a request to the DHCP 
server and receives a response. There is an opportunity for the DHCP 
client to measure the delay, should it be so instrumented. In no way did 
I intend the DHCP server run NTP for any business but itself.

The discussion has left me a little uneasy about the specificy of the 
message formats to the current NTP implementation. Things like minpoll 
and maxpoll could be interpreted in context to protect the NTP servers, 
but in the DHCP environment that probably is not an issue. There is no 
real need to reveal broadcast mode servers. As long as the client knows 
the address mask, it can generate the broadcast address to listen on. It 
doesn't make sense to advertise symmetric modes, as these are usually 
reserved for serious low-stratum campus servers. This leaves only 
client/server mode as useful. However, the key ID is important, as the 
NTP client and server should share the same bag of keys and the client 
might not know the current server key ID.

Some perspective on the issues can be gained from our experience with 
other discovery schemes like broadcast, manycast and the pool. Broadcast 
provides the server address (for delay measurements), stratum and key 
ID. Manycast servers filter the client stratum and respond only if they 
can provide better time. They also provide the key ID. The pool scheme 
merely provides the server addresses. In all three schemes the client 
can filter the responses for acceptable stratum and then cast out the 
survivors from the population leaving only the best quality survivors. 
The DHCP discovery scheme needs only to provide comparable statistics. A 
client can use any combination of these schemes.

Dave

---

From: Brian Utterback <[email-masked]>
Date: Mon, 19 Nov 2007 08:54:57 -0500

> locations on the wire. Is C closer to N, further away, on another

Also, agreed. One can imagine a setup where the DHCP server has been
configured with the correct broadcast delay for every subnet that it
serves. However, I consider that this is a very rare occurrence and
very error prone. Why bother? Just let the client do the volley and
have done with it. So I agree with you in general, Danny. Having
a broadcast delay served from the DHCP server is usually going to
be a bad idea.

-- 
blu

---

From: Brian Utterback <[email-masked]>
Date: Mon, 19 Nov 2007 09:07:54 -0500

> the existence of a resolver so you haven't gained anything.

As already noted, there is an advantage, namely that the client does
not have to have a resolver. And even if the reference implementation
requires one (Is that really true? Even if no name resolution is
required?) DHCP should remain implementation agnostic.

As far the "hard coded address" problem goes, I don't see that
scenario as very likely. DHCP clients don't tend to remain up
for very long periods. And you don't have the same IP addresses
being served by thousands of DHCP servers. The thing to be careful
of is that the DHCP server not be embedded and replicated with hard
coded addresses, not that the clients only get IP addresses.

That having been said, I would like to see a way to pass a FQDN
as an option, perhaps passing both. Then you could have logic
like "Here's both, use the name if you can, and use the address if
you must."

-- 
blu

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Mon, 19 Nov 2007 17:43:17 +0100

The beauty of offering IP address instead of FQDN is that you totally
control your client.
You don't let any room for interpretation of the result of the
subsequent DNS query in the DHCP Client.

Benoit 

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 3:58 PM
> To: Brian Utterback
> Cc: Danny Mayer; Benoit Lourdelet (blourdel); 
> [email-masked]; [email-masked]; Richard Gayraud (rgayraud)
> Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) 
> Optionsfor DHCPv6
> 
> On Mon, 2007-11-19 at 09:07 -0500, Brian Utterback wrote:
> > That having been said, I would like to see a way to pass a 
> FQDN as an 
> > option, perhaps passing both. Then you could have logic 
> like "Here's 
> > both, use the name if you can, and use the address if you must."
> 
> An option in a protocol that produces no different behavior 
> is just an opportunity for interoperability problems.
> 
> This is actually an old discussion.   Danny's position isn't 
> unheard of,
> but the fact is that there's really no way in which this 
> option is different from the other fifty options that tell 
> DHCP clients how to contact servers.
> 
> There's no reason why this option should use FQDNs while the 
> other fifty use IP addresses, and there are a number of good 
> reasons not to send FQDNs, the first and most obvious of 
> which is that they take up more space in the packet, and 
> space in the packet is very limited.
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 19 Nov 2007 13:05:11 -0500

Ted Lemon wrote:
> An option in a protocol that produces no different behavior is just an
> opportunity for interoperability problems.
>
> This is actually an old discussion.   Danny's position isn't unheard of,
> but the fact is that there's really no way in which this option is
> different from the other fifty options that tell DHCP clients how to
> contact servers.
>
> There's no reason why this option should use FQDNs while the other fifty
> use IP addresses, and there are a number of good reasons not to send
> FQDNs, the first and most obvious of which is that they take up more
> space in the packet, and space in the packet is very limited.
>
>   
There is no way of answering that claim without knowing more about a)
those other 50 options; and
b) how those options are obtained.

So let's step back here for a moment and have someone from the DHCP
community explain exactly
how and when these options are sent to the client. Remember that those
of us concentrating on NTP
have only some idea how DHCP is sending these options. Does DHCP:
a) Send these options unsolicited when it is requested to send an IP
address to be used by the client?;
b) Only send these options when requested by the client?;
c) something else?

When does the client send/receive the request?
a) Upon boot
b) upon lease renew
c) some other time?

Except for a) the NTP server is not going to be taking any options from
the DHCP server unless some
other mechanism (which NTP has not designed) tells it to. That means
that the NTP can be up for months
never updating it's list of NTP server addresses. In the meantime,
Server 1 has stopped running, Server 2
has moved to a different address, Server 3 was always suspect. DCHP has
no say in what to do about this,
at least so far. DNS at least provides a way of getting a fresh set of
addresses.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 21 Nov 2007 04:43:54 +0000

Danny,

The one-way delay on a fast Ethernet is usually in the weenieseconds on 
a fast Ethernet, so I wouldn't worry to much about it. The scenario 
where the DHCP delay would be useful is when for some reason or other 
the client cannot use the client/server volley to measure it. A nonzero 
delay value in the DHCP response would be an explicit indication of that.

Davev

---

From: Danny Mayer <[email-masked]>
Date: Tue, 20 Nov 2007 23:46:08 -0500

Brian Utterback wrote:
> Danny Mayer wrote:
>
>> There is *no* avantage to not sending a FQDN and plenty of
>> disadvantages to not doing so. Would you like a list of vendors who
>> have hardcoded IP addresses into their devices without permission
>> of the operator of that NTP server causing headaches for not just
>> the owner of the NTP Server but also for the users of those
>> devices? The NTP reference implementation expects the existence of
>> a resolver so you haven't gained anything.
>>
>

The reference implementation calls getaddrinfo(). Whether it actually
contacts a resolver depends partly on the O/S.

> scenario as very likely. DHCP clients don't tend to remain up for
> very long periods. And you don't have the same IP addresses being
> served by thousands of DHCP servers. The thing to be careful of is
> that the DHCP server not be embedded and replicated with hard coded
> addresses, not that the clients only get IP addresses.

This laptop that I'm typing on hasn't been restarted in at least a
month. The NTP server (which I am stopping and starting constantly as
I'm testing and debugging code) would not normally be stopped and never
fetches an new addresses once it has them. In the meantime it's changing
networks at least 3 times a day and therefore getting a new address from
DHCP each time. Currently, if the DHCP server were to send me new IP
addresses for the NTP server it would ignore it as it's already running
and doesn't look at anything before it's restarted or you use ntpdc to
change it. So except for bootup, sending me IP addresses every time I
change my local IP address would be useless since the running ntpd
server doesn't get notified, at least not right now.

If you want to use the DHCP server essentially as a resolver (it looks
up the addresses and sends them to the NTP server) that's fine except
there's no mechanism currently in place to do that.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 21 Nov 2007 04:50:10 +0000

Brian,

Trying to put out fires when the network is burning is a good excercise 
in fault containment. When the DNS is broken and the repair party 
arrives, it's good to know the gateway works even if DNS doesn't. I'm 
not sure this exactly applies to NTP, but I sure would like to see the 
NTP servers options include hard coded addresses.

Dave

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2007 20:52:53 -0700

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Nov 2007 23:32:05 -0500

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 16 Nov 2007 05:48:03 -0800

So, expectations.

-- 
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: Ted Lemon <[email-masked]>
Date: Mon, 19 Nov 2007 00:53:14 -0600

> I have no idea what configuring the DHCP server with a domain name has

Yes, I definitely got that impression.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Nov 2007 08:58:26 -0600

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Nov 2007 14:09:58 -0800

> client to measure the delay, should it be so instrumented. In no way did 

I'm not aware of any DHCP message exchanges that are suitable for
RTT measurements in any meaningful way.

Many DHCP message exchanges require physical flushes to disc or other
similar recoverable storage before replying, and in other messages
servers may engage in additional behaviours that rely on additional
RTTs (such as Dynamic DNS updates), or timeouts (such as with ICMP
echoes).

I can go into detail if you wish, but I personally would not use
even the informational messages for any kind of meaningful time
derivation (since even with informational messages, the server may
perform recursive DNS resolution of names in its configuration in
order to deliver IP addresses over DHCP).

-- 
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, 19 Nov 2007 14:56:44 -0800

> space in the packet, and space in the packet is very limited.

There is a concern of which I am aware among the NTP users community
concerning a recent catastrophic event which I think I am reading
in the subtext of this thread.  Lets find out.

A SOHO router manufacturer latched onto the IPv4 address (not the
domain name) of a particular open-to-the-public NTP clock.  The
IPv4 address was hard-coded into their firmware.

Upon the release of this product, said clock was slowly subjected to
what grew into an Entire-Internet scale distributed DDOS.

The operator responsible for the NTP device at said IPv4 address was
not willing nor capable of continuing to supply free bandwidth and
hardened NTP servers to meet this SOHO router manufacturer's global
clocking needs, certainly not free of charge, and ultimately had to
readdress his clock.  I seem to recall he was actually sued by the
SOHO router manufacturer, because all their SOHO routers suddenly
started spitting errors and misbehaving when this free service was
withheld, but my memory is beyond its limits at this point.

So it is possible that the community may strongly desire an otherwise
unusual number of intermediaries between /etc/ntp.conf and the IPv4
addresses they determine.

DHCP is an excellent solution, because it is likely that this SOHO
router was in fact obtaining its own IP address via DHCPv4, so if
it also received its clock via DHCPv4 rather than being hard-
coded, there would never have been a problem to solve.

IPv4 addresses via DHCP are possibly a worse solution, however,
because if it does deliver fixed IPv4 addresses to clients, then a NAT
box acting as a home gateway is a greater operational danger than the
above; imagine if this SOHO router manufacturer had decided to deliver
the fixed IPv4 address they had selected via DHCPv4 to all its
NAT-side clients, in all homes its clones resided, worldwide.

So if the DHCP protocol field required RFC1035 syntax, an IPv4 address
becomes an illegal configuration format, and that may be a desirable
outcome to a segment of the operational community that is concerned
with the historic stickyness of their IPv4 addresses, and the tendency
to get sued for publishing one.

I do not make a judgement at this time, but I would like to caution
the NTP community that additional intermediaries will not necessarily
correct bad behaviour.  In example, putting your clock's location in
DNS resolution into A/AAAA records does not mean a SOHO router
manufacturer can not / will not resolve those addresses and then
hard-code them into products.

I would also like to suggest that some of these concerns may be
mitigated by tracking Ralph Drom's recent 'container option' draft,
wherein a SOHO router may dynamically receive from an 'upstream'
DHCPv6 server the configuration values it should give 'downstream'
DHCPv6 clients.

I'm not aware of an equivalent for DHCPv4 however.

So cautioned, I personally leave it up to the NTP community to
prove to us exactly to what extent it is genuinely useful to have
such intermediaries as DNS (or even DHCP, even if I consider that
a given) involved.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Nov 2007 15:22:25 -0800

> b) Only send these options when requested by the client?;

In general, and in context of this discussion, it is most important to
understand that DHCP servers (both v4 and v6) provide exactly those
options the DHCP clients request (via the DHCPv4 Parameter Request
List option, or the DHCPv6 Option Request Option).

A server might be configured to send additional options explicitly,
but doing so is no guarantee that the client will use the options.

The request lists are essentially an advertisement of what options
the client is willing to digest, and the order of priority it places
in them (in the event of packet space exhaustion, earlier options
will preclude later).

In DHCPv4, there are approximately 312 bytes available for DHCP
options, considering realistic operational deployment.  Less if you
don't want to bear support costs.  Some of those must be textual
(domain name, search path), but the majority have been and continue
to be carried in binary IP address forms.

In DHCPv6, there are potentially 64k bytes available for DHCP options,
with some handwaving for the (extremely brief) headers, recursive
headers due to DHCPv6 relay paths, and the various options that are
'mandatory' for normal operation...you are still left with a "large"
potential for options payload.  This is much more than four times the
available packet space, considering IPv6 addresses are "only" four
times larger than IPv4 addresses.

> When does the client send/receive the request?

It depends, and in either protocol is at the discretion of the client.

> a) Upon boot

Obviously the client will obtain an address upon booting.  Upon
rebooting...

In DHCPv4, we have the INIT-REBOOT state, so the client sends a
request that effectively extends its lease, and new configuration
state is loaded along with that.

In DHCPv6, we have the Confirm message, which allows a client to
continue to use its previous binding (or not, sending it back to
the beginning), and no new configuration state is loaded.

Any change in configuration (such as its absence) is detected, and
new values (or lack thereof) are adopted.

> b) upon lease renew

Yes.  New values from the network always supplant older ones.  How
to integrate this onto e.g. a Unix-like system is unclear, and
realistically many configuration values are "sticky" with running
applications (such as /etc/resolv.conf contents that are loaded
once when firefox starts and never again).

So all of this is academic if your ntpd runs once at startup on
a laptop that "sleeps" rather than being shutdown, and never
reloads its configuratoin file with fresh values from the DHCP
client.

Ostensibly you would want to have some closer integration with the
DHCP client to receive these configuration events in near real time.

> c) some other time?

Both DHCP protocols include a mechanism to reconfigure/force the
renewal of configuration information causing a client to enter into
the renewal event at any time, but the DHCPv4 method is not well
deployed, and the DHCPv6 method is not clearly well used (to me, maybe
someone else will comment).

I don't know if you will find this document helpful;

http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-00.txt

But I (rather egotistically) think it is a good read for background
information for any authors looking to write new DHCP options.

It expires Jan. 2 2008.  I should probably rev it soon, but doubt I
will have the time available until approx Jan 15...

---

From: Ralph Droms <[email-masked]>
Date: Mon, 19 Nov 2007 18:41:18 -0500

draft-droms-dhc-container-opt-01.txt defines container options for  
both DHCPv4 and DHCPv6.

- Ralph

On Nov 19, 2007, at Nov 19, 2007,5:56 PM, David W. Hankins wrote:
> [...]

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 21 Nov 2007 05:24:36 +0000

Guys,

Is this about mechanism or policy?

I would suspect (and hope) it is about mechanism.

In that case one must be able to "offer" either a name or an IPv4
address or an IPv6 address.

If one *also* wishes to address policy issues, that's OK (IMO).

But (again IMO) the underlying mechanism needs to support names and/or
addresses.

H

---

From: "M. Warner Losh" <[email-masked]>
Date: Tue, 20 Nov 2007 22:57:00 -0700 (MST)

In message: <[email-masked]>
            "David W. Hankins" <[email-masked]> writes:
: I seem to recall he was actually sued by the
: SOHO router manufacturer, because all their SOHO routers suddenly
: started spitting errors and misbehaving when this free service was
: withheld, but my memory is beyond its limits at this point.

Poul-Henning Kamp wasn't sued by Linksys.  He contacted them to get
made whole for the damage their firmware caused to him in direct
bandwidth costs.  Linksys released new firmware and agreed to make him
happy in other ways that was never released to the public.

The problem of a hard-coded IPv4 address remains, but in this instance
eventually the right thing happened.  Or as close as one can get in
today's less than ideal world.

Warner

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Wed, 21 Nov 2007 08:06:19 +0100

About those 50 options ... For DHCPv6, listing already defined options
specifying an IP service,
I find option : 22,27,28,31,34, 40 that have hardcoded IPv6 addresses.

So far, I cant find any IP service defined by an FQDN for DHCPv6.

Benoit 

> From: Danny Mayer [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 7:05 PM
> To: Ted Lemon
> Cc: Brian Utterback; Benoit Lourdelet (blourdel); 
> Options for DHCPv6
> is just an 
> > There's no reason why this option should use FQDNs while the other 
> > fifty use IP addresses, and there are a number of good 
> reasons not to 
> > send FQDNs, the first and most obvious of which is that 
> they take up 
> > more space in the packet, and space in the packet is very limited.
> >
> >   
> There is no way of answering that claim without knowing more 
> about a) those other 50 options; and
> So let's step back here for a moment and have someone from 
> the DHCP community explain exactly how and when these options 
> are sent to the client. Remember that those of us 
> concentrating on NTP have only some idea how DHCP is sending 
> these options. Does DHCP:
> a) Send these options unsolicited when it is requested to 
> send an IP address to be used by the client?;
> Except for a) the NTP server is not going to be taking any 
> options from the DHCP server unless some other mechanism 
> (which NTP has not designed) tells it to. That means that the 
> NTP can be up for months never updating it's list of NTP 
> server addresses. In the meantime, Server 1 has stopped 
> running, Server 2 has moved to a different address, Server 3 
> was always suspect. DCHP has no say in what to do about this, 
> at least so far. DNS at least provides a way of getting a 
> fresh set of addresses.
> 
> Danny
>

---

From: Brian Utterback <[email-masked]>
Date: Wed, 21 Nov 2007 08:12:20 -0500

> there's no mechanism currently in place to do that.

Well, certainly we would need a way to update the servers used by
ntpd. The obvious choice is to restart, but the requests I made to
the hackers list for arbitrary command line config specification
was specifically to allow just such a mechanism for update be
available to the O/S when new servers came in via DHCP.

-- 
blu

---

From: Brian Utterback <[email-masked]>
Date: Wed, 21 Nov 2007 10:01:18 -0500

Dave, I think you misunderstood. By saying the "hard-coded address"
sceanrio as "not very likely" I meant that a DHCP caused fiasco like
the Netgear/Wisc. one was not likely, even if IP addresses are supplied
in the DHCP field. In other words, we are once again in violent
agreement here.

-- 
blu

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 21 Nov 2007 07:18:58 -0800

----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "Ralph Droms" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Brian Utterback" 
<[email-masked]>; "Richard Gayraud ((rgayraud))" 
<[email-masked]>
Sent: Friday, November 16, 2007 7:33 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options 
forDHCPv6

> not depend on a valid time in any way then this is fine.

That potentially eliminates the use of  KRB5 Tokens

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 21 Nov 2007 07:34:49 -0800

Seems like there are two ways to deal with this, either define a set of 
pre-existing names and services ala RFC1918 type thingee or through some 
lookup process in DHCP. Either way it seems that this also plugs into the 
NEA functionality as well.

Todd
----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "Danny Mayer" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Ted Lemon" <[email-masked]>; 
"Richard Gayraud (rgayraud)" <[email-masked]>
Sent: Wednesday, November 21, 2007 5:12 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor 
DHCPv6

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 21 Nov 2007 08:53:23 -0800

On Wed, Nov 21, 2007 at 11:10:11AM -0500, Mark Stapp wrote:
> very long, a client who got NTP addresses and found itself having 
> trouble with them all could also use the INFORMATION-REQUEST message to 
> check whether the addresses were still valid, outside of the normal 
> renewal timers.

We have at least one DHCPv4 client that does this, and it is not
adviseable.  I don't want to get into a nuts and bolts 'thing' for
the NTP people, we can talk about that on DHC separately if you like.

The short version of my opinion is that it's preferrable to renew
early, if you take any special action at all.  If the operator
selects a long lease time, without specifying a short renew time,
they are selecting this behaviour by design.  So an even better
interpretation is to just wait the normal renew interval, even it
is terribly long.

No special action is best by far.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 21 Nov 2007 08:58:26 -0800

> NEA functionality as well.

Isn't there already an 'all ntp servers' multicast address allocated?

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 21 Nov 2007 19:09:32 +0000

David,

The true story of the U. Wisconsiin incident, along with others at NIST 
and USNO, is in: Mills, D.L., J. Levine, R. Schmidt and D. Plonka. 
Coping with overload on the Network Time Protocol public servers. Proc. 
Precision Time and Time Interval (PTTI) Applications and Planning 
Meeting (Washington DC, December 2004), 5-16. The paper is also on the 
web: www.eecis.udel.edu/~mills/papers.html.

So far as I know, Netgear had no plans to sue U. Wisconsin or the ISP. 
However, my very strong advice to U. Wisconsin was to sue Netgear. The 
incidents are what prompted the in-your-face practices in the latest 
SNTP RFC, as well as the traffic grooming and Kiss-o'Death response in 
recent NTP distributions.

I don't know what the argument is about with respect to IPV4 and NAT. I 
would assume best practice would be for the firewall to run NTP and 
provide its nonroutable IPv4 address behind the firewall. In principle, 
it could hand out a routable IPv4 (or IPv6) address of an outside server 
and translate only the return address. Frankly, I would rather the SOHO 
do broadcast, rather than be stung by a raft of clients.

Dave

David W. Hankins wrote:

> ------------------------------------------------------------------------
>

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 21 Nov 2007 19:19:18 +0000

David,

Yes; the IANA has allocated IPv4 and IPv6 addresses for multicast NTP. 
Most of our department servers and clients use them.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Wed, 21 Nov 2007 14:34:39 -0500

> Isn't there already an 'all ntp servers' multicast address allocated?

FF02::101 and FF05::101 are reserved for link-local and site-local.
Actually the whole FFxx::101 space is reserved for NTP.

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 21 Nov 2007 16:05:14 -0800

----- Original Message ----- 
From: "Harlan Stenn" <[email-masked]>
To: "Ted Lemon" <[email-masked]>
Cc: <[email-masked]>; "Danny Mayer" <[email-masked]>; "Richard Gayraud 
(rgayraud)" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 20, 2007 9:24 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Options 
forDHCPv6

> Is this about mechanism or policy?

Both

> But (again IMO) the underlying mechanism needs to support names and/or

true.

---

From: Danny Mayer <[email-masked]>
Date: Fri, 23 Nov 2007 22:46:19 -0500

> addresses they determine.

No, we don't want that, we want to ensure that we don't repeat the
mistake of hardware manufacturers (and for that matter software
developers) embedding fixed addresses in their implementations.

> to get sued for publishing one.

This is one of the problems that the NTP pool servers face. The pool DNS
servers pass out different addresses on a regular basis but the NTP
clients are hanging onto the addresses. One of my urgent projects is to
get at least the reference implementation of ntpd to do another DNS
lookup in case the NTP server is not responding after a specified number
of request packets don't get a response. Pool servers that get removed
from the pool are continuing to receive NTP request packets for a very
long time. We cannot do anything about third-party clients but we can
certainly have the reference implementation do the right thing. The new
pool configuration option is also helpful because it now makes use of
multiple IP addresses returned by the DNS lookup.

Agreed.

> DHCPv6 server the configuration values it should give 'downstream'

We'd have to figure out how to integrate that if we were to do that.

> such intermediaries as DNS (or even DHCP, even if I consider that

DNS is required for the pool configuration option. IP addresses are
strongly discouraged from the server configuration option for the same
reasons. The only time I can see allowing DHCP provided IP addresses is
if those addresses are link-local or site-local. That way we'd guarantee
that they were not going to bombard a remote NTP server with requests.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 23 Nov 2007 22:46:12 -0500

> reloads its configuratoin file with fresh values from the DHCP

That's currently the situation with the reference implementation of
ntpd. It gets its configuration information and doesn't go back. You can
update some of the configuration information using ntpdc, changing
servers for example, but it won't reread the config file itself right
now. So for the DHCP client to have an influence on what it uses for
servers it either needs to use ntpdc, send private mode 7 NTP packets,
restart ntpd, or have some sort of interface for ntpd to get updated
values from the DHCP client.

> DHCP client to receive these configuration events in near real time.

See above.

> someone else will comment).

Well, if ntpd can poke the DHCP client for new values, presumably it can
request new values from the DHCP server to pass back to ntpd. That's not
even defined.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sat, 24 Nov 2007 21:15:13 -0500

> But (again IMO) the underlying mechanism needs to support names and/or

Let me make an alternative suggestion which would make sense (at least
to me).

The IPv6 address sent by the server MUST be a site-local or link-local
address or, for an IPv4 address a local LAN address as specified by the
netmask. The client MUST ignore any addresses that don't meet this criteria.

This way the DHCP admins are restricted to use only those NTP servers
that the business owns and cannot configure one outside their own
address spaces.

Would this satisfy both sides?

The other issues with the options we've already discussed and we leave
open for now the issue of specifying NTP authentication keys for a
separate discussion.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sat, 24 Nov 2007 21:15:49 -0500

Mark Stapp wrote:
> yes, this is another reason why the DHCP folks have generally used
> addresses in options. it just removes a dependency among the various
> clients in the system, and it doesn't usually have any significant
> drawback.
> 
> there seems to be a concern that delivering addresses via DHCP somehow
> makes them difficult to update over time. just to reiterate: it's often
> the case that the information at the DHCP server is updated. the updated
> information flows out to clients as they renew. if the lease timers were
> -- Mark

Mark,

My biggest worry is the "set and forget" attitude of a system admin who
has more than just NTP servers to worry about. The reality is that NTP
is a long-running daemon on the client and unless something happens it
will continue to query the same client, not just for days, but for
months and even years. We can propose that the DHC client updates the
NTP server but I have yet to see anything that proposes to do that. If
the sysadmin sets up the list of NTP servers for the DHC client to use
when is he/she going to go back and check if they are still valid?

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sat, 24 Nov 2007 21:16:23 -0500

Mark,

Danny

---

From: Ted Lemon <[email-masked]>
Date: Sat, 24 Nov 2007 20:40:26 -0600

> Would this satisfy both sides?

This is sort of like when a spendthrift congresscritter says "look, we  
want to take half of that national park for oil exploration, but  
you've objected that visitors to the park won't want to look at the  
oil derricks, so let's compromise: we'll take the *whole* park.   That  
satisfies our needs, and satisfies your objection as well.

There is simply no need for the kind of complexity you're proposing.    
The reason why DHCP is such a success is because it's a great place to  
put your client configuration control information.   It works.    
Network administrators keep it up to date.   Clients refresh their  
configurations periodically.   The problem you're afraid will happen  
is not going to happen.

Please stop trying to create additional complexity to deal with a  
problem that's not going to happen.   The whole point of DHCP is to  
PREVENT the kind of problem you're worried about.   You don't need to  
complexify it to accomplish your goals - it already accomplishes them!

---

From: Danny Mayer <[email-masked]>
Date: Sat, 24 Nov 2007 23:06:28 -0500

Ted Lemon wrote:
> want to take half of that national park for oil exploration, but you've
> objected that visitors to the park won't want to look at the oil
> derricks, so let's compromise: we'll take the *whole* park.   That

Let's stop being silly about this shall we? NTP servers have a real
problem and we want to be sure that proposals don't make the situation
worse.

> There is simply no need for the kind of complexity you're proposing.

Of course there is. There have been enough DDOS attacks on NTP servers
that we need to consider all of the ways that easy propogation of
targets don't work. Just remember that DNSSEC took over 10 years to
develop and is still in the starting stages of being rolled out.

> put your client configuration control information.   It works.   Network
> administrators keep it up to date.   Clients refresh their
> configurations periodically.

That's nice. But let's make sure that it doesn't cause problems when you
do that.

>   The problem you're afraid will happen is
> not going to happen.

You're too late. It already has. We are already in the situation that we
need to take defensive measures against existing errant NTP clients.

> complexify it to accomplish your goals - it already accomplishes them!

The minimal complexity suggested is necessary since DHCP will do
*nothing* to prevent the kind of problem that I'm worried about. To the
contrary it will most likely *cause* the problem. You don't see the
problem, we have to live with it.

Danny

---

From: Brian Utterback <[email-masked]>
Date: Sun, 25 Nov 2007 07:49:55 -0500

> need to take defensive measures against existing errant NTP clients.

No it hasn't. AFAIK, there has not been a case of multitudes of clients 
that received NTP server
IP addresses from DHCP spamming servers abusively for extended periods 
of time. My gut feel
is that Ted is correct and that this is not likely to be a problem.

However, the fact that we have had other situations develop into just 
such problems means
that examining the proposal for potential abuse scenarios is worthwhile. 
Before we start
looking for a compromise solution, perhaps we should look more closely 
at the problem.

For instance, I don't see the problem as being any worse than an 
ntp.conf file that has
the server given by an IP address. If you are going to restrict DHCP, 
perhaps we
should consider not allowing IP addresses in the ntp.conf file. If you 
think that
is absurd, then perhaps the DHCP restriction is absurd as well. Or 
perhaps not.

Brian Utterback

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 06:18:09 -0800

Brian - "Likely" isn't something that Auditor's will let you resell as a 
commercial product. Likely means that the security model of NTP is broken. 
Time transfer MUST be assured and reliable or NTP is more of a curiosity 
than the key to the everything many of us believe it to be.

Todd Glassey

----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "Danny Mayer" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Ted Lemon" <[email-masked]>; 
"Richard Gayraud (rgayraud)" <[email-masked]>
Sent: Sunday, November 25, 2007 4:49 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor 
DHCPv6

---

From: Brian Utterback <[email-masked]>
Date: Sun, 25 Nov 2007 14:52:45 -0500

But we are not talking about anything to due with the security model, 
assurance or reliability. The
question at hand is how to avoid abusive spamming of servers by 
persistent and pervasive clients.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 12:55:38 -0800

----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Danny Mayer" <[email-masked]>; <[email-masked]>; <[email-masked]>; 
"Ted Lemon" <[email-masked]>; "Richard Gayraud (rgayraud)" 
<[email-masked]>
Sent: Sunday, November 25, 2007 11:52 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor 
DHCPv6

> question at hand is how to avoid abusive spamming of servers by persistent 
> and pervasive clients.

OK but that sounds like Integrity of Opertions insurance to me, si?

Isnt the issue is how to authenticate any control processes since without 
this I can slam the server's with bad requests to make it unavailable to the 
legit users.

?????

Todd

>> commercial product. Likely means that the security model of NTP is 
>> broken. Time transfer MUST be assured and reliable or NTP is more of a 
>> curiosity than the key to the everything many of us believe it to be.
>>
>> Todd Glassey
>>
>> Cc: <[email-masked]>; <[email-masked]>; "Ted Lemon" 
>> <[email-masked]>; "Richard Gayraud (rgayraud)" <[email-masked]>

---

From: Brian Utterback <[email-masked]>
Date: Sun, 25 Nov 2007 16:24:06 -0500

> this I can slam the server's with bad requests to make it unavailable to the 
Sort of. We aren't talking about any protection from malicious clients, 
we are dealing with the inadvertent
slamming of a server due to long term up time of multiple clients that 
use the same IP address forever and
ever.  If a client is served an IP address at start up time, it has no 
choice but to use that address for the
entire time it is up and running. If a particular DHCP server serves the 
same IP to all of its clients, the
problem is multiplied. If the DHCP happens to be an embedded client, 
with the server IP hard-coded and
this embedded client is deployed to multiple thousands of home 
appliances, then we have the Netgear/Wisc
fiasco again.

Is this scenario likely enough to be worth making major modifications to 
the way DHCP does things?
This is what seems unlikely to Ted and I. Rather than jump through hoops 
at the client protocol
level, a requirement that the IP served not be hard coded at the server 
might be enough. A compromise
on Danny's compromise might be that the addresses must either be 
site-local, or determined dynamically
by the server via DNS lookup.

Brian Utterback

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 15:20:13 -0800

----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>; "Danny Mayer" <[email-masked]>; "Ted Lemon" 
<[email-masked]>; "Richard Gayraud (rgayraud)" <[email-masked]>; 
<[email-masked]>
Sent: Sunday, November 25, 2007 1:24 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor 
DHCPv6

>> this I can slam the server's with bad requests to make it unavailable to 
>> the legit users.
>>
>> ?????
>>
>> Todd
>>
>>
> Sort of. We aren't talking about any protection from malicious clients, we 
> are dealing with the inadvertent
> slamming of a server due to long term up time of multiple clients that use 
> the same IP address forever and
> ever.

Yeah... its a possibility especially with systems/appliances that hardcoded 
the server addresses into their firmware... I still get several hundred 
thousand hits a day on the old SJ NIST Server address.

> If a client is served an IP address at start up time, it has no choice but 
> to use that address for the
> entire time it is up and running.

You mean the DHCP lease? True unless the connection is forced to be renewed. 
Otherwise, as long as the connection is in place one would think its proper 
to have the service address remain the same.  The same is not true of NTP 
server's though. Those should expire per some settable policy such that a 
NTP Discovery is redone every 'period' to insure the proper operations of 
the Audit/Evidence model produced.

BTW - Didnt we bring up the idea of a independant  Time Server 
Discovery/Selection protocol some time ago. This is a dance that is done 
periodically to renew the validity of the policy controls in the NTP system.

>  If a particular DHCP server serves the same IP to all of its clients, the
> problem is multiplied. If the DHCP happens to be an embedded client, with 
> the server IP hard-coded and
> this embedded client is deployed to multiple thousands of home appliances, 
> then we have the Netgear/Wisc
> fiasco again.

Yeah - I lost use of several IP's permanently because of this issue...

> by the server via DNS lookup.

I agree that DNS is another way to carry the Time Server addresses, and they 
could easily be setup as Well Known Services, which might work pretty well.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 17:30:52 -0600

On Nov 25, 2007, at 3:24 PM, Brian Utterback wrote:
> If a client is served an IP address at start up time, it has no  

This is simply not true.   The client would get the currently- 
configured NTP server IP address every time it renews its lease.    
It's true that some NTP clients may not bother to check their  
configuration information for updates, but it is not true that they  
have no choice - checking for configuration updates is trivial.

Indeed, I would say that at this late date, a network service that  
gets its configuration information from the DHCP client, but does not  
follow updates to that information, is broken.  Information provided  
by the local DHCP server will most likely change when the client moves  
from network to network.   The information that worked on one network  
may not work at all on another.   This is true whether the information  
is a domain name or an IP address.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Nov 2007 11:09:02 +1100

> is a domain name or an IP address.

I would think that this should be a push operation from the dhcp
client rather than a pull operation.  A trivial push would be for
the DHCP client to re-start the NTP client on address change (NTP
server and optionally lease address change).

I already do the later as the NTP client doesn't notice lease address
changes.

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: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 18:16:58 -0600

On Nov 25, 2007, at 5:20 PM, TS Glassey wrote:
> to have the service address remain the same.

This is a very frustrating discussion.   Do you guys ever actually use  
DHCP in operation?   Connections aren't "forced to be renewed."   DHCP  
clients renew their leases periodically.   It's possible to set up a  
DHCP server to give out a lease that doesn't need to be renewed, but  
nobody ever does that.   Even if some random person at one site  
somewhere does it, they're not going to have enough clients to cause  
you trouble - it's only a large site that will cause you trouble, and  
trust me, they can't operate their network without regular lease  
renewals.

So in practice, for any significant source of NTP traffic, you are  
going to have DHCP lease renewals.   There aren't going to be any  
exceptions to this.

Furthermore, for clients that only do the lightweight DHCP protocol,  
there is a required refresh interval.   So again, this simply isn't a  
problem.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 18:40:18 -0600

On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote:
> client rather than a pull operation.

Sure, but it amounts to the same thing.   This is trivial to do with  
the ISC DHCP client (which I presume is the one you use).   It's also  
trivial to do on Linux with dbus.   Mac OS X and Windows handle it  
differently still, but they already have mechanisms in place for doing  
this.   So the point is that if the will exists to make it happen,  
it's trivial to make it happen.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 16:48:03 -0800

----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Brian Utterback" <[email-masked]>; <[email-masked]>; 
"Richard Gayraud (rgayraud)" <[email-masked]>; <[email-masked]>
Sent: Sunday, November 25, 2007 4:16 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) Optionsfor 
DHCPv6

> DHCP in operation?

Yes all the time.

>  Connections aren't "forced to be renewed."   DHCP  clients renew their 
> leases periodically.

Sorry Ted... they most assuredly do expire and if the user wants to continue 
to use those services the transport MUST renew its lease to have an IP 
address. That's what 'forces' the lease renegotiation

> It's possible to set up a  DHCP server to give out a lease that doesn't 
> need to be renewed, but  nobody ever does that.

Uh yes they do and its one of the problems with this type of system too.

> Even if some random person at one site  somewhere does it, they're not 
> going to have enough clients to cause  you trouble - it's only a large 
> site that will cause you trouble, and  trust me, they can't operate their 
> network without regular lease  renewals.

Ted, here again this is a policy issue.

>
> So in practice, for any significant source of NTP traffic, you are  going 
> to have DHCP lease renewals.   There aren't going to be any  exceptions to 
> this.
>

Ted - this is about auditing and what's needed for digital evidence.  So we 
disagree here. NTP will not be run on platforms constrained by those issues 
if we are not careful and properly setup NTP so that the trust factor's it 
operates off of are secured as well.

Todd

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 16:50:59 -0800

So Ted how does the DHCP server get refreshed to know that NTP Server "A" is 
dead now?

Todd

----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: <[email-masked]>; "Danny Mayer" <[email-masked]>; "Richard Gayraud 
(rgayraud)" <[email-masked]>; <[email-masked]>
Sent: Sunday, November 25, 2007 4:40 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

---

From: Brian Utterback <[email-masked]>
Date: Sun, 25 Nov 2007 20:28:30 -0500

I think we are all arguing at cross purposes. We have people reasoning 
about what will be,
some about what is, some about what could be and some about what should be.

The question on the floor is very simple. Is it sufficient for the DHCP 
option to follow convention
and serve an IP address or is it necessary to instead serve a string 
that represents a FQDN that should
be used for a DNS lookup and periodically re-resolved.

It has been suggested that if you are going to serve up a string, a URL 
that points to a configuration
file to be used would offer the most general mechanism for 
configuration, but this is highly problematic
since there is no implementation agnostic configuration language it it 
is way, way out of scope to think
about making one. This this idea is rejected.

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 disadvantage is that it forces client to run and configure a 
resolver and potentially adds a lot
of overhead to the DHCP protocol.

Ted maintains that as a practical matter, the same effect is achieved 
with the IP address.
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.

Not all of these "can"s and "must"s may be necessary or perhaps they are not
sufficient. If we decide on using the IP address, then we must also 
decide on the
musts and shoulds and mays.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 17:44:42 -0800

BLU  :-)

----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "Ted Lemon" <[email-masked]>
Cc: <[email-masked]>; "Danny Mayer" <[email-masked]>; "Richard Gayraud 
(rgayraud)" <[email-masked]>; <[email-masked]>
Sent: Sunday, November 25, 2007 5:28 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

> be used for a DNS lookup and periodically re-resolved.

I would san "NO" if it is also to be required to present stateful info on 
the status of the TS system...

> about making one. This this idea is rejected.

Agreed

> to that IP to eventually disappear.

But not the surious traffic to the name servers; The issues before  were not 
just the NTP traffic but the DNS traffic to resolve those names as well. I 
can speak to that first hand too.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 20:26:41 -0600

> So Ted how does the DHCP server get refreshed to know that NTP  

Like most DNS servers, most DHCP servers are operated by network  
administrators.   So the network administrator goes in and updates one  
or the other, and the next time a request comes in, the DHCP server  
gets the new IP address and returns it, whether it gets it from the  
DNS or from its own configuration.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 18:32:34 -0800

----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Mark Andrews" <[email-masked]>; <[email-masked]>; "Richard 
Gayraud (rgayraud)" <[email-masked]>; <[email-masked]>
Sent: Sunday, November 25, 2007 6:26 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

> administrators.   So the network administrator goes in and updates one  or 
> the other, and the next time a request comes in, the DHCP server  gets the 
> new IP address and returns it, whether it gets it from the  DNS or from 
> its own configuration.
>

Which makes the Network Administrator liable for screw-up's and the damages 
therein... Sorry this one is a no-sale IMHO.

Todd

---

From: Brian Utterback <[email-masked]>
Date: Sun, 25 Nov 2007 21:42:31 -0500

> therein... Sorry this one is a no-sale IMHO.

Okay, Todd. The proposal is pretty much SOP right now, with some slight
refinements. If you deem that a show-stopper, I think the onus is on
you to suggest a reasonable alternative.

blu

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 20:42:25 -0600

> 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.

> FQDN's. We can specify that the FQDN used may not be hard coded and  

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.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 20:43:27 -0600

> therein... Sorry this one is a no-sale IMHO.

Why?   Network administrators are already responsible for all the  
other fields in the DHCP server - why is the NTP server address special?

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 18:49:35 -0800

----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Ted Lemon" <[email-masked]>; <[email-masked]>; <[email-masked]>; 
"Richard Gayraud (rgayraud)" <[email-masked]>
Sent: Sunday, November 25, 2007 6:42 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

>>> gets the new IP address and returns it, whether it gets it from the  DNS 
>>> or from its own configuration.
>>>
>>>
>>
>> Which makes the Network Administrator liable for screw-up's and the 
>> damages therein... Sorry this one is a no-sale IMHO.
>>
>>
>
> refinements.

OK, SOP for who?

> If you deem that a show-stopper, I think the onus is on

I still don't know that the service is needed I have heard a couple of 
people mandate that they think this is necessary but in actuality I still 
haven't heard anything that makes this mandatory. Especially since without 
any pain at all its pretty easy to create a set of known NTP servers and 
just use the local DNS service to propagate these. WKS inside of DNS is a 
simple method that is time tested.

Todd

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 18:54:08 -0800

Ted :-)

----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Mark Andrews" 
<[email-masked]>; "Richard Gayraud (rgayraud)" <[email-masked]>
Sent: Sunday, November 25, 2007 6:43 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

>> damages
> Why?   Network administrators are already responsible for all the  other 
> fields in the DHCP server - why is the NTP server address special?
>

Ted there are issues with the Old-School methods and if you believe that 
they are the right way to operate your network nothing I can say from either 
someone who has written subpicosecond event capture code as well as auditing 
profiles for securing and making the evidence believable.

So lets just agree to disagree about this. The addition of NTP servers in 
this instance opens more liabilities than it solves problems for whether 
anyone likes that or not. Sorry, but your neat fix here opens new security 
issues and allows NTP servers to become also impacted by DHCP security 
issues.

Sorry but reality is what it is, and adding this support to DHCP opens more 
problems than it solves.

Todd

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Nov 2007 21:57:12 -0500

> I already do the later as the NTP client doesn't notice lease address

You must be running an old NTP server. As of 4.2.4 ntpd rescans the
interfaces for local interface address changes. You can disable
rescanning by using -U 0 on the startup command line.

Danny

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Nov 2007 14:00:06 +1100

> therein... Sorry this one is a no-sale IMHO.
 
	There is no system that a network administrator can't screw
	up.

	DHCP is not the same as embedded in firmware.

	"Cease and Desist" will work with DHCP as there is a
	configuration knob that can be changed.  It's also not a
	knob that is shipped set.

	Mark

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 26 Nov 2007 03:05:51 +0000

Guys,

Just to pick a random message on this thread to respond to, I think
it would be Swell if a DHCP server could send back some configuration
information for the benefit of an NTP server.

If the information is "here's *a* server you should use" I would like to
see that information be either an IP (v4 or v6) or a DNS name.

If it is a *list* of servers, I would like to see that list contain any
of IPs (v4 or v6) and/or hostnames.

If it is more generic "ntp configuration information" then prehaps
regardless of whatever other formats are proffered, I would be happy to
see a URL as a choice.

Also please remmeber that there is an excellent chance that there will
be something in between ntp on the client and the incoming DHCP packet
that "handles" the information and ntp may *never* actually directly
talk to the DHCP server.  OTOH, it might.

If anybody cares, please visit (and comment if you like):

H

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 19:06:23 -0800

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" <[email-masked]>
To: "Brian Utterback" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Richard Gayraud (rgayraud)" 
<[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 21:14:23 -0600

On Nov 25, 2007, at 8:54 PM, TS Glassey wrote:
> Sorry but reality is what it is, and adding this support to DHCP  
> opens more problems than it solves.

If one of the options here is for you guys to take your marbles and go  
home, I'd be all in favor of that - I don't see this converging on a  
good solution, and I'd rather that we have no solution for now than a  
bad solution - we can always try again later.   You guys remind me of  
a first-time motorcycle passenger who freaks out when the bike leans  
over in a turn, and tries to get it to stand back up.

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Nov 2007 22:10:49 -0500

> it's trivial to make it happen.

It's trivial to send a private mode 7 NTP packet (along with an
appropriate password) to the reference implementation of ntpd telling it
to add or remove a server from its list of servers to use. As far as I
know only ntpdc does this currently and it's not a DHC client.

Danny

---

From: Brian Utterback <[email-masked]>
Date: Sun, 25 Nov 2007 22:23:30 -0500

TS Glassey wrote:
> people mandate that they think this is necessary but in actuality I 
> still haven't heard anything that makes this mandatory. Especially 
> since without any pain at all its pretty easy to create a set of known 
> NTP servers and just use the local DNS service to propagate these. WKS 
> inside of DNS is a simple method that is time tested.
>
> Todd

Okay, so your suggestion is to not have a DHCP NTP field at all, but to have
the clients use WKS and DNS resolution to find servers. Fair enough.

blu

---

From: Brian Utterback <[email-masked]>
Date: Sun, 25 Nov 2007 22:38:17 -0500

> Sorry but reality is what it is, and adding this support to DHCP opens more 

Truly? In your audited world, can't you just preclude the use
of DHCP based server discovery if it poses such a problem?

blu

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 19:09:27 -0800

Mark
That's the problem. its not that I think that its not a good idea to be able 
to propagate a set of NTP servers to any set of users, and DHCP is something 
that most operator's have running, but DNS is a better solution I think 
especially if there is a set of basic Time Services and addressing ala 
RFC1918 defined for them per the suggestion I sent in some months ago.

Todd
----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Ted Lemon" <[email-masked]>; <[email-masked]>; "Richard Gayraud 
(rgayraud)" <[email-masked]>; <[email-masked]>
Sent: Sunday, November 25, 2007 7:00 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

>> > or

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Nov 2007 22:56:11 -0500

> the clients use WKS and DNS resolution to find servers. Fair enough.

Actually SRV records are what should get used. WKS is rather obsolete.

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 20:03:27 -0800

----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Mark Andrews"
<[email-masked]>; "Richard Gayraud (rgayraud)" <[email-masked]>
Sent: Sunday, November 25, 2007 7:14 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)
OptionsforDHCPv6

>> Sorry but reality is what it is, and adding this support to DHCP  opens
>> more problems than it solves.
>
> home, I'd be all in favor of that - I don't see this converging on a  good
> solution, and I'd rather that we have no solution for now than a  bad
> solution - we can always try again later.   You guys remind me of  a
> first-time motorcycle passenger who freaks out when the bike leans  over
> in a turn, and tries to get it to stand back up.
>

Ted, opinions are wonderful, everyone has one, even you. As to the 
Motorcycle commentary - I used to race for Team Montessa so, I do know how 
to lean through a turn... and my commentary about the introduction of new 
risks to make the incidental world of the Systems/Network Administrator 
easier, I understand the goal its just the wrong way to go about it.

Todd

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 20:06:22 -0800

BLU
----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Ted Lemon" <[email-masked]>; <[email-masked]>; <[email-masked]>; 
"Richard Gayraud (rgayraud)" <[email-masked]>
Sent: Sunday, November 25, 2007 7:23 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

>> haven't heard anything that makes this mandatory. Especially since 
>> without any pain at all its pretty easy to create a set of known NTP 
>> servers and just use the local DNS service to propagate these. WKS inside 
>> of DNS is a simple method that is time tested.
>>
>> Todd
>

Yes and no. My suggestion is that the DCHP system could be used if it also 
had some reliable names which were predefined.

My real suggestion is that we need a Time and Trust Service Discovery 
protocol which would work sort of like how DHCP and DNS work but that also 
allows for critical events to be pushed forward as well. This would also 
work for CRL and OCSP type queries to satisfy validity of the underlying 
certificate source.

Todd

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 25 Nov 2007 20:15:26 -0800

Danny
I was trying to stay as compatible as possible, but yes in the Microsoft 
world Service Records (SRV's) are the current manner to do this.  The 
problem I see is that SRV's cannot return the key as well as the address for 
secured service lookup.

Todd
----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "Brian Utterback" <[email-masked]>
Cc: "TS Glassey" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Ted Lemon" <[email-masked]>; "Richard Gayraud 
(rgayraud)" <[email-masked]>
Sent: Sunday, November 25, 2007 7:56 PM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Nov 2007 22:27:14 -0600

> problem I see is that SRV's cannot return the key as well as the  

Are you guys seriously proposing using DNSSEC as a way to secure the  
keys to NTP?   By how many orders of magnitude do you think this  
increases the value of the DNS root key?

Based on the messages that I see flying by, with talk of "audit" and  
"keys", I don't even understand why we're having this discussion.   If  
DHCP is the cornerstone of your security model, you are doomed.   If  
DNSSEC is the cornerstone of your security model, you're putting all  
of your eggs in a single basket.   It's no wonder we're not converging  
here - what you're proposing to do is essentially impossible!

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Nov 2007 23:41:13 -0500

Ted,

Let me try and outline the problem again and please come up with an idea
which solves this.

1) The DHCP environment is divided into essentially two groups: Hardware
like Netgear and Linksys routers and Software like ISC's DHCP Server and
Nominum's Dynamic Configuration Server. IETF doesn't allow you to create
a protocol which differentiate between these cases.

The software side of the DHCP implementations are usually run by
organizations for their internal use and are actively maintained. I have
few worries about these since it's easy to deal with (relatively
speaking) errors that the sysadmins make.

The SOHO routers are different since the DHCP servers are built into the
firmware and shipped in their 10's of thousands to individuals and small
businesses who want wireless connections and routers but don't want to
be in the business of configuring and maintaining them.

So let's say Acme Routers ships a router with a builtin DHCP server
which provides NTP server addresses to provide to the DHCP clients and
they put just one address in it. Now say Starbucks gets all excited
about how cheap they are and buys them for all their coffee stores. Now
you have DHCP providing and amplication DDOS attack as all of those
people sitting there laptops are all set up with the same NTP server
address and sending NTP packets to the same NTP server. Note that in the
UWisc/Netgear incident it was the NTP server built into the router that
was the problem but it was only one server. Here we are having the
router distributing the address to other systems which then do the dirty
work and you'd get 10 times the effect of a Netgear incident. This is
the problem that I'm trying to solve or rather mitigate.

I refer you to the UWisc/Netgear incident paper that Dave Mills and Dave
Plonka wrote:
http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf
The brief slide version is here:
http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf
It also discusses the loads on a number of other servers inclusing NIST
and USNO

PHK's incident with D-Link is written up here:
http://news.bbc.co.uk/2/hi/technology/4906138.stm

I await your suggestions on how to prevent the routers becoming
amplifiers via DHCP to bombarding NTP servers.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Nov 2007 23:55:39 -0500

Ted Lemon wrote:
> DNSSEC is the cornerstone of your security model, you're putting all of
> your eggs in a single basket.   It's no wonder we're not converging here
> - what you're proposing to do is essentially impossible!

We are not suggesting this at all. His suggestion makes no sense to me
either. At least we are on the same side for some things!

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 25 Nov 2007 23:56:58 -0500

Ted,

Danny

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Nov 2007 16:05:30 +1100

Danny this really is a non-issue.

	A SOHO DHCP server side will learn its values from the
	SOHO DHCP client side.  SOHO DHCP servers do this today
	for lots of values it returns to the SOHO network.

	Today you have a check box on SOHO routers that says
		[ ] DNS servers learn from network.
	If it is not checked you get a dialog to fill in.

	Tomorrow you will have a check box on SOHO routers that says
		[ ] NTP servers learn from network.
	If it's not checked you will get a dialog to fill in.

	Similarly IPv6 PD requests will chain through multiple DHCP
	servers until you find one which will allocate the space requested.

	Mark

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Mon, 26 Nov 2007 10:20:59 +0100

Danny,

I want to highlight that the  UWisc/Netgear happened without DHCP and I
suspect that a similar incident 
 may happen again. DHCP as you described it could be an amplification
factor but with millions of CPE wrongly configured
 there is no need of DHCP to have things going wrong.

Correctly deployed, an off-the-shelf SOHO router should not have any
server hardcoded -You will never prevent people
 from doing bad thing on a CPE router anyway - and should receive its IP
services server (including NTP) from the provider.

For all other cases, Enterprise where the DHCP server is managed by IT
people of the same administrative domain and ISP settop boxes with DHCP
managed with the Telcos, an DHCPv6 NTP hardcoded address is not going to
hurt anybody as a DHCP Client wont use an expired IP service address for
ever.

Mandating the use of site local address may complicate deployments in
the case of company mergers in the initial stage.
Again, the DHCP server is managed by people of the same administrative
domain that are supposed to configure it with 
 correct IP addresses.

The way NTP is deployed in many SP networks is to use a hierarchy of NTP
server, so that the NTP server is very close to 
 NTP Client. In many case the client is pointing to an NTP server in the
same Point Of Presence.

In enterprise deployments, if IT bothers relying on NTP, they will
deploy their own NTP servers and wont rely on public
 NTP servers. Needless to say that top of the hierarchy enterprise NTP
servers wont use DHCP for configuration.

Benoit

> From: ntpwg-bounces+blourdel=[email-masked] 
> [mailto:ntpwg-bounces+blourdel=[email-masked]] On 
> Behalf Of Danny Mayer
> Sent: Monday, November 26, 2007 5:41 AM
> To: Ted Lemon
> Let me try and outline the problem again and please come up 
> with an idea which solves this.
> 
> 1) The DHCP environment is divided into essentially two 
> groups: Hardware like Netgear and Linksys routers and 
> Software like ISC's DHCP Server and Nominum's Dynamic 
> Configuration Server. IETF doesn't allow you to create a 
> protocol which differentiate between these cases.
> 
> The software side of the DHCP implementations are usually run 
> by organizations for their internal use and are actively 
> maintained. I have few worries about these since it's easy to 
> deal with (relatively
> The SOHO routers are different since the DHCP servers are 
> built into the firmware and shipped in their 10's of 
> thousands to individuals and small businesses who want 
> wireless connections and routers but don't want to be in the 
> business of configuring and maintaining them.
> 
> So let's say Acme Routers ships a router with a builtin DHCP 
> server which provides NTP server addresses to provide to the 
> DHCP clients and they put just one address in it. Now say 
> Starbucks gets all excited about how cheap they are and buys 
> them for all their coffee stores. Now you have DHCP providing 
> and amplication DDOS attack as all of those people sitting 
> there laptops are all set up with the same NTP server address 
> and sending NTP packets to the same NTP server. Note that in 
> the UWisc/Netgear incident it was the NTP server built into 
> the router that was the problem but it was only one server. 
> Here we are having the router distributing the address to 
> other systems which then do the dirty work and you'd get 10 
> times the effect of a Netgear incident. This is the problem 
> that I'm trying to solve or rather mitigate.
> 
> I refer you to the UWisc/Netgear incident paper that Dave 
> Mills and Dave Plonka wrote:
> It also discusses the loads on a number of other servers 
> inclusing NIST and USNO
> 
> I await your suggestions on how to prevent the routers 
> becoming amplifiers via DHCP to bombarding NTP servers.
> 
> Danny

---

From: <[email-masked]>
Date: Mon, 26 Nov 2007 11:27:06 -0000

Surely an ISP DNS must suffer the same issue. How do DNS implementations
deal with the same problem given that the "attack" traffic then happens
far more often. 

-----Original Message-----
From: ntpwg-bounces+anthony.flavin=[email-masked]
[mailto:ntpwg-bounces+anthony.flavin=[email-masked]] On Behalf Of
Danny Mayer
Sent: 26 November 2007 04:41
To: Ted Lemon
Cc: [email-masked]; [email-masked]; Richard Gayraud (rgayraud)
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)
OptionsforDHCPv6

Ted,

Danny

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Nov 2007 23:01:23 +1100

> deal with the same problem given that the "attack" traffic then happens

	If the SOHO boxs all handed out the same address for the DNS
	servers then there would be a problem.

	It reality there isn't because ISP's configure the DHCP
	servers to point to the ISP's caching DNS servers.  The SOHO
	boxes just re advertise what they have learnt from upstream.

	ISP's will do similar things with NTP servers.  They will point
	the DHCP clients to their NTP servers.  SOHO routeres will just
	re advertise what they learnt.

	This is a non-issue.
	
	Mark

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Nov 2007 07:56:32 -0500

> happy in other ways that was never released to the public.

It wasn't Linksys, it was D-Link. According to the note on his Web site
Poul was satisfied with whatever was agreed upon.

Danny

---

From: Brian Utterback <[email-masked]>
Date: Mon, 26 Nov 2007 09:21:17 -0500

> work for CRL and OCSP type queries to satisfy validity of the underlying 

Sounds great to me, Todd. I really think that you should pursue that.
I don't think that this is that protocol and I don't think it is
fair to hold up this one because it isn't that one.  Write a spec,
make a prototype and publish them, and then we can talk about that
one.

-- 
blu

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 26 Nov 2007 07:45:41 -0800

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, November 26, 2007 3:27 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

> a protocol which differentiate between these cases.

Which documents why the IETF is broken. Its run by people who do what they 
want to do rather than by folks who want any and all standards to be vetted 
and brought forth. If this wasnt true there would be a simple and well 
defined vetting process.

> they put just one address in it.

OK...

> Now say Starbucks gets all excited
> about how cheap they are and buys them for all their coffee stores.

yeah... but this is only twenty or thirty thousand nationwide... what's a 
real problem is where someone produces a CABLE MODEM which has hardcoded NTP 
service addresses programmed into the units, and that becomes 75,000 or more 
units per medium sized city.

> Now
> address and sending NTP packets to the same NTP server.

You mean like what happened to PHK, my and other Time Servers last year?

> Note that in the

NetGear was upright and stepped to the plate unlike the other suppliers, 
especially our friends in SoCal IMHO - 
http://en.wikipedia.org/wiki/NTP_vandalism

> It also discusses the loads on a number of other servers inclusing NIST

Having been a victim of the last flurry and other providers bashing of the 
public time servers let me ask how would they know what the loads on the 
server's are?

They also didnt calculate the DNS overhead into the bigger picture as well, 
so its not just the NTP traffic, but the DNS overhead on the front side of 
the NTP transaction. The real issue here is the California Supreme Court 
ruling on whether IP addresses and Domain Names are protectable as IP's 
which are unique to those users.

> amplifiers via DHCP to bombarding NTP servers.

NTP needs a server and server-policy discovery model. DHCP isnt it either, 
nor is DNS really, but they can both be used to prime the pump per se 
though.

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 26 Nov 2007 08:37:33 -0800

----- Original Message ----- 
From: "Brian Utterback" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Ted Lemon" <[email-masked]>; 
"Richard Gayraud (rgayraud)" <[email-masked]>
Sent: Monday, November 26, 2007 6:21 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

>> protocol which would work sort of like how DHCP and DNS work but that 
>> also allows for critical events to be pushed forward as well. This would 
>> also work for CRL and OCSP type queries to satisfy validity of the 
>> underlying certificate source.
>>
>> Todd
>>
>

I have - already. In fact there are several implementations already written 
too. One for Solaris and another port to OS/X. The problem is that I am not 
willing to give away any and all rights to this protocol specification as 
you folks have done by taking NTP into the IETF.

Better yet, look at the continuously revised participation requirements in 
the IETF and you will realize that most of this and all WG member's have 
committed fraud in representing to the IETF that they have a legal status to 
represent their sponsor's IP rights. I.e the new rules per BCP78/79.

> fair to hold up this one because it isn't that one.

My objection is in creating mandatory components of the NTP package which 
are not minimalistic. Implementing this code over DHCP would be a security 
nightmare from the Audit Perspective, so what I propose is that if you want 
to add this support - its you folks who make this a BCP for configuring and 
operating NTP.

Todd

> Write a spec,

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Mon, 26 Nov 2007 18:10:00 +0100

Mark and David,

If we consider the already defined DHCPv4 and DHCPv6 Options, IP
services are, in (almost) all cases, passed as an address and not as a
name.  
If we come to the conclusion that FQDN is really mandatory for NTP, I
don't see why we should not retrofit this to all existing IP services
Options.

Honestly, I would like the DHCP veterans to come forward and tell us why
they made so many bad decisions in the past :-;

Benoit

> From: Mark Stapp (mjs) 
> Sent: Wednesday, November 21, 2007 5:10 PM
> To: David L. Mills
> Cc: [email-masked]; [email-masked]
> yes, this is another reason why the DHCP folks have generally 
> used addresses in options. it just removes a dependency among 
> the various clients in the system, and it doesn't usually 
> have any significant drawback.
> 
> there seems to be a concern that delivering addresses via 
> DHCP somehow makes them difficult to update over time. just 
> to reiterate: it's often the case that the information at the 
> DHCP server is updated. the updated information flows out to 
> clients as they renew. if the lease timers were very long, a 
> client who got NTP addresses and found itself having trouble 
> with them all could also use the INFORMATION-REQUEST message 
> to check whether the addresses were still valid, outside of 
> the normal renewal timers.
> 
> -- Mark
> 
> David L. Mills wrote:
> > Brian,
> > 
> > Trying to put out fires when the network is burning is a good 
> > excercise in fault containment. When the DNS is broken and 
> the repair 
> > party arrives, it's good to know the gateway works even if DNS 
> > doesn't. I'm not sure this exactly applies to NTP, but I sure would 
> > like to see the NTP servers options include hard coded addresses.
> > 
> > Dave
> > 
> > Brian Utterback wrote:
> > 
> >>
> >> Danny Mayer wrote:
> >>
> >>> disadvantages to not doing so.
> >>> Would you like a list of vendors who have hardcoded IP addresses 
> >>> into their devices without permission of the operator of that NTP 
> >>> server causing headaches for not just the owner of the NTP Server 
> >>> but also for the users of those devices? The NTP reference 
> >>> implementation expects the existence of a resolver so you haven't 
> >>> gained anything.
> >>>
> >>

---

From: <[email-masked]>
Date: Mon, 26 Nov 2007 17:15:05 -0000

That's not really a surprise. A box that is powering up, needs IP
addresses as it may not be able to resolve DNS yet. However DHCP is not
restricted to passing addresses.

Tony 

-----Original Message-----
From: ntpwg-bounces+anthony.flavin=[email-masked]
[mailto:ntpwg-bounces+anthony.flavin=[email-masked]] On Behalf Of
Benoit Lourdelet (blourdel)
Sent: 26 November 2007 17:10
To: Mark Stapp (mjs); David L. Mills
Cc: [email-masked]; [email-masked]
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)Options for
DHCPv6

Mark and David,

Benoit

> for DHCPv6

> makes them difficult to update over time. just to reiterate: it's 
> often the case that the information at the DHCP server is updated. the

> updated information flows out to clients as they renew. if the lease 
> timers were very long, a client who got NTP addresses and found itself

> having trouble with them all could also use the INFORMATION-REQUEST 
> message to check whether the addresses were still valid, outside of

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 26 Nov 2007 10:28:40 -0800

> that they were not going to bombard a remote NTP server with requests.

In this case, you would have to make similar requirements of any IP
addresses delivered via the intermediaries between the DHCP option
and ntp.conf, or else you really haven't gotten that gurantee.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 26 Nov 2007 10:42:16 -0800

> ntpd. It gets its configuration information and doesn't go back. You can

You can classify this as an ntpd problem, or a system integration
problem.

In the former, you might want to accept a HUP sometimes.  In the
latter, all the tools to restart the daemon are already available.

Whichever one you choose, you'll still get the job done.  If ntpd
accepts HUPs, maybe you can optimize 'keeping your clock synched'
across reconfiguration events.

> values from the DHCP client.

The client itself has no need to do this.  The operating system's
configuration management system which accepts DHCP input needs to
solve this problem.

For ISC, we call this "dhclient-script", and although we package
several examples with our software I know of no actual operating
systems that use them...they all cook their own scripts that
integrate with their configuration management.

Still, it is trivial;

	if [ x$new_ntp_servers != x$old_ntp_servers ] ; then
		rewrite_ntp_conf()
		rcntp force-reload
	fi

> request new values from the DHCP server to pass back to ntpd. That's not

Presently, all the poking is in the opposite direction.  What I was
referring to here is that there are Server->Client messages that can
suggest the client needs to update its config, rather than wait for
the usual lease renewal timer to expire.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 26 Nov 2007 11:03:12 -0800

> http://news.bbc.co.uk/2/hi/technology/4906138.stm

Yes, I thought this was a subtext of this discussion, and in my
opinion is more important than any of the security subdiscussions.

It is also good to have my facts straightened, I was going from memory
before.

> amplifiers via DHCP to bombarding NTP servers.

I do not believe there is any reasonable way we can provide this
with complete assuredness.

It may appear that if you gave the DNS name via DHCP that the clock's
administrator can now do clever things with DNS replies to ease the
pain on the individual clocks.  So mitigation tools may exist.

However it also opens the doorway for a clock manufacturer to set
the static value to a domain name they control - and deliver A records
for other folks' clocks.

You're screwed either way...in this case, you have some control over
firmware that has not been upgraded.

So my current recommendation is still to use binary IP addresses,
and track Ralph Drom's existing draft (which covers both v4 and v6,
I also stand corrected), in carefully explaining how a DHCP server
supplying it is expected to come by the configuration values:
Either manually supplied by the operator, or reflecting options
gained upstream.  No default values.

It's my estimation that this is the best compromise between managing
the risk of DDOS and scaling the DHCP protocol.

But I believe that the NTP community is now very well versed in the
concerns and facts surrounding this case, and I look forward to
reading your draft - whatever it might say.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2007 13:14:44 -0600

> they put just one address in it.

There simply is no defense against this.   If a vendor of a broadly- 
distributed device does something stupid, someone gets shafted.

You can write a requirement into the draft, and if they read it and  
follow it, that's really great, but my experience is that people skim  
drafts - they don't read them carefully.   They read carefully when  
something breaks and they have to figure out what they did wrong, but  
for a case like this, it won't be obviously broken until there are  
millions of units in the field all providing the same information.

So yes, by all means put a paragraph like this in the draft:

DHCP servers MUST NOT contain a default or predefined value for the  
NTP option.   DHCP servers MUST NOT send an NTP option unless a value  
has been explicitly configured by an administrator or end user.

The best defense you have against people doing this is that the NTP  
mass murder problem has made the news a couple of times, and people  
have been sued over it.   So a sensible vendor of SOHO equipment or  
cable modems is going to do the right thing, because they don't want  
to get sued.

Furthermore, CableLabs has a process for doing conformance testing, so  
if you want to be really sure that this never happens again, you  
should work with them to add this to their requirements and their  
certification process.   At that point, a device wouldn't be able to  
be certified if it did the wrong thing, and this would be a real and  
meaningful protection for you.

But the main point that I keep making and that people keep ignoring is  
that this problem is not solved by using a domain name in place of an  
IP address.   Using the domain name simply means that the place where  
the badness would occur is different.   It's still a problem for the  
SOHO box or cable modem to be preconfigured with a name like  
"NTP.POMME.FR" - the only difference is that in that case not only  
will the NTP server at NTP.POMME.FR get slammed, but also the name  
server for NTP.POMME.FR will get slammed.

So my point is that whether we use an IP address or a domain name, the  
same problem still occurs.   So the fact that the problem exists can't  
be used as a justification for using one over the other.

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 26 Nov 2007 11:35:56 -0800

Ted if that is all you are doing here then lets also send this to the NEA 
people too...

Todd
----- Original Message ----- 
From: "Ted Lemon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Mark Andrews" <[email-masked]>; "TS 
Glassey" <[email-masked]>; "Richard Gayraud (rgayraud)" 
<[email-masked]>
Sent: Monday, November 26, 2007 11:14 AM
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
OptionsforDHCPv6

> something breaks and they have to figure out what they did wrong, but  for 
> a case like this, it won't be obviously broken until there are  millions 
> of units in the field all providing the same information.
>
> DHCP servers MUST NOT contain a default or predefined value for the  NTP 
> option.   DHCP servers MUST NOT send an NTP option unless a value  has 
> been explicitly configured by an administrator or end user.
>
> The best defense you have against people doing this is that the NTP  mass 
> murder problem has made the news a couple of times, and people  have been 
> sued over it.   So a sensible vendor of SOHO equipment or  cable modems is 
> going to do the right thing, because they don't want  to get sued.
>
> Furthermore, CableLabs has a process for doing conformance testing, so  if 
> you want to be really sure that this never happens again, you  should work 
> with them to add this to their requirements and their  certification 
> process.   At that point, a device wouldn't be able to  be certified if it 
> did the wrong thing, and this would be a real and  meaningful protection 
> for you.
>
> that this problem is not solved by using a domain name in place of an  IP 
> address.   Using the domain name simply means that the place where  the 
> badness would occur is different.   It's still a problem for the  SOHO box 
> or cable modem to be preconfigured with a name like  "NTP.POMME.FR" - the 
> only difference is that in that case not only  will the NTP server at 
> NTP.POMME.FR get slammed, but also the name  server for NTP.POMME.FR will 
> get slammed.
>
> same problem still occurs.   So the fact that the problem exists can't  be 
> used as a justification for using one over the other.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2007 13:52:34 -0600

> Ted if that is all you are doing here then lets also send this to  

It would be really great if instead of shooting these offhand, cryptic  
comments out whenever I send you a thoughtful explanation of why I  
don't agree with what you want to do, you explain in clear, plain  
english why what I said didn't make sense to you, or what mistake I  
made in my thinking that means that what I said isn't correct. I'm  
sure these quips seem funny and enjoyable to you, but to me they're  
just so much nonsense.   They certainly don't serve to advance your  
agenda, whatever it is.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Nov 2007 15:44:19 -0500

I'd like to apologize to Ted over this and thank Mark for his input. I
hadn't realized until Mark piped up with his response that these servers
were getting all of their information from upstream and therefore there
was always some sort of human at the end of the chain actively managing
this in the SOHO routers. I hadn't wanted to get into the details of how
DHCP servers worked but it was crucial for an understanding of the
configuration mechanism.

So I withdraw my objections to using IPv6 addresses in these options but
I strongly recommend a sentence or two be added to the Security section
to warn people about the amplifying effects of provisioning NTP server
addresses to clients in this way and their potential for DDOS attacks.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 26 Nov 2007 21:30:50 +0000

Danny,

There are two mitigating factors at work here, both mentioned in 
rfc4330. First, if the router hardcodes anything, use a DNS name, not an 
address. Second, any hardcoded name/address must point to a resource 
operated by the manufacturer or another site only with permission of the 
operator.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 26 Nov 2007 21:41:13 +0000

Danny,

FYI, in the current implementation it is possible to send configuration 
commands in file syntax from ntpq (mode 6). This is preferred as the 
commands and responses are in human readable ASCII. This is what 
prompted my suggestion that the DFCP NTP response could well be in the 
form or a preprogrammed mode-6 command and could be some other ASCII 
string if something other than current NTP is involved.

Dave

---

From: Mark Stapp <[email-masked]>
Date: Wed, 21 Nov 2007 11:10:11 -0500

yes, this is another reason why the DHCP folks have generally used 
addresses in options. it just removes a dependency among the various 
clients in the system, and it doesn't usually have any significant drawback.

-- Mark

---

From: Mark Stapp <[email-masked]>
Date: Mon, 26 Nov 2007 14:08:14 -0500

making it possible to convey NTP servers in dhcpv6 doesn't seem to me to 
be any different than conveying them in dhcpv4 was. that was done 
something like ten years ago, and as far as I know that hasn't been a 
problem.

I do wonder why some folks seem to think that using DNS names would 
somehow be "safer" than using v6 addresses. if someone shipped a server 
with a canned list of DNS names for NTP servers, there would be a 
problem until the owners of the NTP servers named moved them. I don't 
see how that'd be any better than the analogous mistake involving IP 
addresses.

shipping a DHCP server with a canned configuration would not be good, so 
let's hope it doesn't happen. Mark Andrews's email seems to me to 
summarize what happens: 'home' routers have a dhcp client face and a 
dhcp server face, and use the client to populate the server.

aside from the catastrophe hypothetical, is there any really strong 
reason - anything to do with the NTP protocol - that would prevent the 
use of ipv6 addresses?

Thanks,
Mark

---

From: Brad Knowles <[email-masked]>
Date: Tue, 27 Nov 2007 01:01:04 -0600

>	re advertise what they learnt.

No, the ISPs don't work this way.  I have yet to see many ISPs that 
have demonstrated any capacity or interest in setting up their own 
NTP server.  If they use NTP at all, in almost all cases they rely on 
external NTP servers.  It is these same external servers that they 
would plug into their DHCP servers (because they can't be bothered to 
run their own NTP servers), and which would then be passed on to the 
clients.

Which leads us to the mess that Danny is trying to help prevent.

>	This is a non-issue.

I'm not convinced of that.

-- 
Brad Knowles <[email-masked]>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Brad Knowles <[email-masked]>
Date: Tue, 27 Nov 2007 01:08:28 -0600

>  server for NTP.POMME.FR will get slammed.

Not true.  The NS and A records for NTP.POMME.FR will presumably have 
a lifetime that is measured in hundreds, thousands, tens of 
thousands, or maybe even hundreds of thousands of seconds, and they 
will be cached on the remote end.

However, each and every one of those hundreds of thousands or 
millions of misconfigured NTP clients will be pounding the 
NTP.POMME.FR machine once every sixty seconds or so, unless they've 
managed to back off to just pounding it ever thousand seconds or so. 
If they're misconfigured, or the machine is not responding, they may 
pound it every second -- or maybe many hundreds of times per second.

There's a huge difference here.  Like, orders of magnitude.  Possibly 
many orders of magnitude.

>  be used as a justification for using one over the other.

The difference is that once an IP address is given out, it can't be 
changed to point somewhere else.

Once a name is given out, it can always be changed to point to a 
different IP address.  The current reference implementation would not 
re-resolve that name into the new IP address, but at least all 
new(er) instances would catch the new IP address, and life would be 
able to continue.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 27 Nov 2007 01:32:42 -0600

On 11/21/07, Mark Stapp wrote:

>  information flows out to clients as they renew.

But in the case of NTP clients, that assumes that they know that 
there is a renewal, and that they need to update their configuration. 
Which seems to imply that there would need to be something in the NTP 
protocol standard that says something like:

	If you got your other-protocol-specific configuration via DHCP,
	then you need to make sure that you're fully DHCP-aware and
	that you pick up all changes when the DHCP client renews the lease.

>                                                  if the lease timers were

Which implies that the NTP client now needs to become fully DHCP aware.

NTP is a weird beast.  It's not like a mail or news server, which can 
pretty much always continue to use the same upstream server as 
defined in the configuration file, and never needs to worry about 
watching for DHCP lease renewals.

NTP is one of those layer 2.5 things that doesn't have the name Cisco 
branded on the side, and doesn't look like a router, switch, or hub, 
and therefore your traditional network admins may not understand it. 
It also doesn't have the name Microsoft or Sun stamped on the side, 
and therefore your traditional host administrators aren't necessarily 
going to know anything about it.

This is a piece of network systems infrastructure which acts as glue 
at the interface between the network itself and the hosts on the 
network, and since it's an edge case on both sides of the equation, 
we need to be careful in how we handle it.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 27 Nov 2007 01:38:36 -0600

>  see how that'd be any better than the analogous mistake involving IP

If the name was "pool.ntp.org", today that load would be spread over 
more than 1500 hosts around the world, and we hope that there will be 
many more participants in the pool in the future.  Moreover, Ask 
Bjorn Hansen has apparently done a fairly good job of building a 
robust load-balancing nameserver architecture for this system, and so 
far as I know would be able to handle a UWisc or PHK-scale disaster 
plus the "normal" load.

Now, 1500 versus millions of misconfigured clients, that's not such a 
great bet.  But it's orders of magnitude better than just a single IP 
address.

>  reason - anything to do with the NTP protocol - that would prevent the

At the technical level, no.  IP addresses (of both forms) and names 
should have no technical difference.  Of course, this assumes that if 
you're handing out IPv6 addresses that you'll have full IPv6 stacks 
on both sides and a fully IPv6-compatible network underneath, and if 
you hand out IPv4 addresses that you're connected to the appropriate 
IPv4 network (and not isolated on some IPv6-only island), but that's 
a different matter.

At the practical operations level, yes.  See above.

---

From: Hal Murray <[email-masked]>
Date: Tue, 27 Nov 2007 00:34:33 -0800

> Which implies that the NTP client now needs to become fully DHCP aware.

I was going to say something like that too...  But I poked around a bit.

One alternative is that the DHCP client is NTP aware.  :)

/sbin/dhclient-script on my Linux box stuffs server lines into ntp.conf   I 
think it's smart enough to restart ntpd if the list of ntp servers changes.  
I didn't check all the fine print or try to test it.  Ugly, but probably good 
enough.

A comment says dhclient-script came from NetBSD so others have probably 
copied the idea.

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

---

From: Hal Murray <[email-masked]>
Date: Tue, 27 Nov 2007 00:58:49 -0800

> somehow be "safer" than using v6 addresses. if someone shipped a
> server  with a canned list of DNS names for NTP servers, there would
> be a  problem until the owners of the NTP servers named moved them. I
> don't  see how that'd be any better than the analogous mistake
> involving IP addresses.

I think that suggestion is coming from the NTP community rather than DHCP.  
Using names rather than addresses provides a layer of indirection which is a 
powerful tool for recovering from screwups.

If Joe-Idiot hard wires 123.123.123.123 into his dumb box and then ships a 
zillion units, the guy who owns 123.123.123.123 is screwed.  Updating the 
firmware on enough units to make a difference won't ever happen.

If ntp.example.com gets wired in, you at least have a chance to play DNS 
games to distribute the load.

> shipping a DHCP server with a canned configuration would not be good,
> so  let's hope it doesn't happen. Mark Andrews's email seems to me to

That's another form of indirection.

It seems like a sensible approach to me.  On the other hand, a lot of boxes 
were shipped that didn't work that way.  For those who haven't read it, 
Wikipedia has a good summary of the NTP mess:
  http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse

This problem has code in (at least) two places:  One is the DHCP server.  The 
other is the NTP client.  Either can screw it up.

The examples on the Wiki page didn't involve DHCP but a simple screwup in a 
DHCP server could generate similar results.  The obvious example is that if 
somebody has a NTP server address they are using for an internal NTP client 
and it is hard wired, they could easily use the same variable when they need 
something to stuff into a DHCP packet.

My vote would be to add some extra wording to emphasize this area.  Just 
saying "MUST" is too likely to get ignored.

I think the key idea is that you have to be very careful if the addresses (or 
names) you are giving out are not on your network.

As far as I can tell, all of this discussion holds for both IPv4 and IPv6.

I have no strong opinions on name vs address.  The extra level of indirection might be important.  On the other hand, it might be simpler to cleanly document and correctly implement a system that didn't have that extra layer of complexity.

---

From: <[email-masked]>
Date: Tue, 27 Nov 2007 09:05:05 -0000

Completely wrong.

I can assure you that we do run our own NTP servers, and our customer
routers are pre-configured with a Name not an IP address to get to them.
We let our DNS servers sort out the load balancing issues (if we ever
get any).

It's working fine, and several hundred-thousand clients can't be wrong!
 
Tony Flavin

-----Original Message-----
From: Brad Knowles [mailto:[email-masked]] 
Sent: 27 November 2007 07:01
To: Mark Andrews; Flavin,AJ,Tony,DMJ R
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)
OptionsforDHCPv6

>	re advertise what they learnt.

No, the ISPs don't work this way.  I have yet to see many ISPs that have
demonstrated any capacity or interest in setting up their own NTP
server.  If they use NTP at all, in almost all cases they rely on
external NTP servers.  It is these same external servers that they would
plug into their DHCP servers (because they can't be bothered to run
their own NTP servers), and which would then be passed on to the
clients.

---

From: Brian Utterback <[email-masked]>
Date: Tue, 27 Nov 2007 08:55:25 -0500

> Which implies that the NTP client now needs to become fully DHCP aware.

Maybe. Maybe not. Simply make the requirement and let the
implementation decide how to fulfill it.

The reality is that the current reference implementation is
pretty robust around restarting the daemon. If the kernel
discipline is in use, the latest frequency correction will
continue to be in effect even during the downtime. Simply
have the DHCP subsystem create a new config file and restart.

Or use the ntpq/ntpdc facility to let the DHCP subsystem do
dynamic reconfiguration.

Or use another interface between the two that is more suitable
for the purpose (since the ntpq/ntpdc interface is somewhat
fragile as an internal interface).

Or make the ntpd daemon itself DHCP aware.

There lots of possibilities.

-- 
blu

---

From: Brian Utterback <[email-masked]>
Date: Tue, 27 Nov 2007 09:03:49 -0500

Well, kudos to ISP's that do it right. My experience is that
most of them are not nearly as responsible. None of the last
three ISP's I have used at home (all in the U.S. top ten) even
provided NTP servers, let alone served them up in DHCP options.
Of course, none of the last 4 routers I used would have done
anything with them if they had.

-- 
blu

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Nov 2007 09:04:34 -0500

> You can classify this as an ntpd problem, or a system integration

It's an ntpd problem though we have several methods of updating the
server using ntpdc and ntpq.

> across reconfiguration events.

We really do *not* want to use HUP since that causes a restart and
that's a bad idea for ntpd which is designed to be long-running. It
frequently takes several hours for it to settle now into a stable state
and disciplining the clock. A HUP would disrupt this. Rereading the
configuration file is not straightforward either as you could well be
changing its operational behavior and not just changing server settings.
For what you are talking about with the DHCP provided NTP server
addresses you really only need something like ntpdc -c "add server ..."
comands.

> configuration management system which accepts DHCP input needs to

Sorry, that's what I meant.

> the usual lease renewal timer to expire.

If the address provided by DHCP is not providing NTP service ntpd will
drop it. So in this case it has no recourse.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Nov 2007 09:11:14 -0500

> the static value to a domain name they control - and deliver A records

With the pool config option you can now point to the pool (pool.ntp.org)
and each time you make a query you will get a different list of
addresses to use. The pool also is grouped into areas and countries and
provides a much better loading on the NTP servers in the list. ntpd will
configure up to 10 of these addresses to use.

> firmware that has not been upgraded.

We prefer the pool.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Nov 2007 09:18:47 -0500

> see how that'd be any better than the analogous mistake involving IP

Because with the pool you are likely to get a different list of
addresses every time you ask (modulo caching DNS Servers of course).

> reason - anything to do with the NTP protocol - that would prevent the

ntpd fully supports IPv4 and IPv6 addresses.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Nov 2007 13:16:31 -0500

Mark,

Slipping on my DNS hat for a moment, the whole point of DNS is that you
don't have to hardcode IP addresses in everything. You also benefit by
being able to put more than one IP address for the same name. It's safer
because the admin of the server doesn't have to worry when he moves a
service from on server to another. All he/she has to do is update the
DNS and not notify 1 million or so people that it's been moved. Can you
imagine moving a web server without it?

> reason - anything to do with the NTP protocol - that would prevent the 

It does use IPv6 addresses when it's presented with one. Now what
happens if that address is not running an NTP server? With DNS you can
get more than one address back and try another address or requery the
DNS to see if the address changed.

Danny

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 27 Nov 2007 11:22:15 -0800

> drop it. So in this case it has no recourse.

That's correct; there is no recourse and in DHCP's philosphy there
shouldn't be.

DHCP delivers a configuration state with an expiration time and
renewal time.  If that configuration is incorrect or flawed or
unusable at some point in its advertised lifetime (as set by the
operator of the DHCP server), it isn't a problem that can be solved
by going back to the well; the configuration is likely to have not
changed.  Going back to the well without some indication (the
reconfigure extensions) just creates useless traffic.

The theory is that DHCP server operators use lease lifetimes as a
tool for limiting stale configuration and for scheduling outages
and configuration changes (reducing the lease lifetimes as changeovers
approach).

I have a vague feeling that you've found the way to express a need for
this DHCP option to be configured via DNS names.  As I stated before,
I reserve any judgement until there's a draft.

---

From: Mark Stapp <[email-masked]>
Date: Tue, 27 Nov 2007 14:39:07 -0500

yes, I think I understand the issue. it's certainly ok to have an option 
payload that uses DNS names if that's what the service needs to use. I 
was only trying to clarify whether it was possible to use addresses or 
not, since it's only possible to use addresses in the dhcpv4 form of the 
option.

maybe what's happening is that the dhcp folks are hearing: "well, yes, 
the dhcpv4 option used addresses, but that's not really being used in 
the real world much, so let's not do the v6 option that way." if that's 
what's happening, it's certainly possible to develop an option format 
using DNS names.

are there circumstances where addresses would be preferred or necessary, 
or would DNS names _always_ be useable? my intuition is that there are 
probably some cases where it might be necessary to supply addresses, so 
it might be safest to develop an encoding that permits both. we have 
examples of things like that: the SIP servers option (RFC3361) allows a 
list of _either_ addresses or names, and the use of suboptions would 
allow mixed lists.

-- Mark

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 27 Nov 2007 21:00:15 +0000

Brad,

The advice to use DNS which is in the RFC and web lists is so folks can 
change the NT server IP address from time to time and update the DNS 
accordingly. If the DHCP server followed that advice, it would 
occasionally re-resolve the name and pass the new IP address to its 
clients. It is not at all clear that this advice is followed in the real 
world.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Nov 2007 22:00:34 -0500

Ted Lemon wrote:
> On Nov 27, 2007, at 4:00 PM, David L. Mills wrote:
>> If the DHCP server followed that advice, it would
> It is followed, actually.   E.g., the Nominum DHCP server (DCS) just
> looks the name up every time, under the assumption that the caching name
> server is going to perform better than any ad hoc resolver we might
> stuff into the DHCP server.   The ISC DHCP server caches names for an
> hour - a decision I made when caching name servers weren't as good as
> they are now, and when I was a lot more naive about DNS than I am now. 
> I can't speak for the other vendors, so you'd have to ask them, but I'd
> be really surprised if they didn't do the same thing - if you cache the
> value, you have to cache it some/where/ - it's not quite the same as
> when a server looks up an address in the DNS so that it can connect to
> that address.
> 

This was the next question to ask of course. How many of the addresses
in the reply are cached for distribution as appropriate? With the pool
config option we use as many as 10 returned from the DNS query. How many
of these would we expect to get if we relied on DHCP to supply those IP
addresses.

> I don't know what SOHO routers do, in general - it would be interesting
> to investigate.

Volunteers?

Danny

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 27 Nov 2007 21:55:01 +0800

> We let our DNS servers sort out the load balancing issues (if we ever
Yes, I would like to agree that DNS servers could do solve such
kind of load balancing issue.

-Hui

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Nov 2007 15:21:20 -0500

> That's correct; there is no recourse and in DHCP's philosphy there

Just to be clear, most DHCP options provide lists of IP addresses, not  
single IP addresses, so it amounts to the same thing.   Indeed, in  
every server of which I am aware, if you configure the DHCP server  
with a domain name that resolves to multiple IP addresses, and the  
option so configured supports multiple IP addresses, then the DHCP  
server sends each IP address.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Nov 2007 18:09:40 -0500

It is followed, actually.   E.g., the Nominum DHCP server (DCS) just  
looks the name up every time, under the assumption that the caching  
name server is going to perform better than any ad hoc resolver we  
might stuff into the DHCP server.   The ISC DHCP server caches names  
for an hour - a decision I made when caching name servers weren't as  
good as they are now, and when I was a lot more naive about DNS than I  
am now.  I can't speak for the other vendors, so you'd have to ask  
them, but I'd be really surprised if they didn't do the same thing -  
if you cache the value, you have to cache it some/where/ - it's not  
quite the same as when a server looks up an address in the DNS so that  
it can connect to that address.

I don't know what SOHO routers do, in general - it would be  
interesting to investigate.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 28 Nov 2007 04:07:55 -0600

>  not, since it's only possible to use addresses in the dhcpv4 form of the

As I see it, one problem is that we really kinda want to be able to 
pass a reasonably complete client configuration, and not just the IP 
addresses or names of one or more NTP servers.  I mean, how would the 
client know which type of method to use in communicating with the 
specified servers?  How much NTP Reference Implementation 
configuration file syntax do we really want to try to encode into the 
DHCP standard, and do we want all DHCP and NTP client implementations 
to be forced to have to deal with that?

I think we might have a relatively easy way out of this problem -- a 
level of indirection that doesn't directly involve either host names 
or IP addresses.

Imagine this: a simple NTP client configuration server, listening on 
TCP port 123.  This could be as simple as a single line in 
/etc/inetd.conf on the machine:

	ntp stream tcp nowait/3/10 nobody /bin/cat   cat /etc/ntp.client

Or, it could be more complex -- a server that checks the IP address 
of the incoming connection, and if it's a client on network A then 
give it one configuration file (maybe unicast), if it's a client on 
network B then give it a different configuration file (e.g., 
broadcast), if it's a client from the outside world either ignore it 
or give it a commented-out file that describes the "Rules of 
Engagement".

Of course, you would want this server to be outside the ntpd binary, 
for obvious security & performance reasons.

The server would be unlikely to be pounded by clients, since it would 
be consulted only on DHCP lease assignment or renewal (as opposed to 
every 64-1024 seconds), and it would be easy enough to have the 
server and client provide & check timestamps and file contents hashes 
to see if the configuration file has actually changed and needs to be 
re-downloaded.

I guess you might even be able to encode timestamps and hash values 
in the DHCP packet, so that the client could compare that against 
what it might already have cached, so that it would know whether or 
not it even needs to contact the NTP configuration server, but I'm 
not sure I'd want to build in that additional complexity.

You could optionally insist that the client and server communicate 
only via SSL on this port, so that you've got a reasonably secure 
channel for transmitting things like NTP certificates.

Of course, the configuration server does not necessarily need to be 
an NTP server itself, although it certainly could be.  And not all 
NTP servers would necessarily need to have configuration servers also 
running on the same machine.

If you want to update your NTP client configuration across your 
network, you do the same sorts of things you'd do with changes to 
your DNS infrastructure -- reduce your DHCP lease expiration time, 
update the file, ensure that all the clients have picked that up, 
then restore your previous DHCP lease expiration times.  Of course, 
that's assuming you don't have some other obvious way to forcibly 
expire all leases, and you don't use something like ntpdc to connect 
to each of the clients to cause them to do a re-load.

If we keep it simple enough, so that simple configuration clients can 
be implemented with netcat, and simple configuration servers could be 
implemented with a single line in /etc/inetd.conf, I think we might 
have a winner.

Of course, I would strongly recommend that people DO NOT actually 
implement real-world clients or servers with netcat or inetd in this 
manner.  However, if we make it the goal that the protocol be simple 
enough to implement in this way, then I think we can avoid a lot of 
headache and unnecessary complexity, while obtaining the critical 
features we seem to have been casting about for.

Obviously, you could just provide an URL for the configuration file, 
and let webservers deal with the problem -- and that would deal with 
the SSL issue, too.  But I'm concerned that web servers are pretty 
heavyweight beasts for this task (thinking about embedded devices), 
and I'm not convinced that you'd have an easy way of extending the 
webserver solution to include automatically grabbing the 
certificates, etc....  I guess you might be able to point it at a 
tarball or a zip file, but that somehow seems a little ugly -- and 
presumes that all clients would have to be able to handle tarballs or 
zip files, which I'm also not yet willing to assert.

Moreover, while the DHCP server would presumably know where the 
client is, I'm not sure we'd have an obvious way to tell the DHCP 
server to determine what type of NTP service that the DHCP client 
should be running, and therefore which URL to hand out.  If we remove 
that complexity from the DHCP server and incorporate just the minimum 
complexity we need in an NTP-specific configuration server, I think 
we can more easily do that.

It seems to me that we need to keep the NTP-specific knowledge within 
the NTP problem space, and try to have minimal impact on other areas 
like DHCP.  The less that these two areas are forced to have impact 
on each other, the more flexibility that their respective 
administrative groups will be able to have to set them up however 
makes the most sense for their organization.

Am I insane?  Have I missed something obvious?  Please keep in mind 
that it's almost 4am and I'm not entirely sure that I've examined 
this idea from all sides, but I have been thinking about this for a 
while and I am not currently aware of any obvious gaping holes in the 
concept.

I'm very interested to hear what people have to say on this subject.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Nov 2007 09:43:29 -0500

On Nov 27, 2007, at 10:00 PM, Danny Mayer wrote:
> How many

Ten.

> Volunteers?

There are so many of them - it's not really as easy as that.   That's  
why I was suggesting working with cablelabs - since the last time  
there was a big meltdown it was a cable modem that did it, it would be  
good to get them on board for compliance testing.

Right now, as far as I know there aren't any SOHO routers that even  
support the NTP option, so it's sort of a non-issue.

---

From: <[email-masked]>
Date: Wed, 28 Nov 2007 15:09:34 -0000

Also many SOHO routers only use SNTP, so just query the first in the
list they are given.

Not many become a NTP server for the home network, so ALL home devices
would need to have this information filtered down to them.

Tony 

-----Original Message-----
From: ntpwg-bounces+anthony.flavin=[email-masked]
[mailto:ntpwg-bounces+anthony.flavin=[email-masked]] On Behalf Of
Ted Lemon
Sent: 28 November 2007 14:43
To: Danny Mayer
Cc: [email-masked]; [email-masked] WG; Ted Lemon
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)
OptionsforDHCPv6

On Nov 27, 2007, at 10:00 PM, Danny Mayer wrote:
> How many
> of these would we expect to get if we relied on DHCP to supply those 
> IP addresses.

Ten.

There are so many of them - it's not really as easy as that.   That's  
why I was suggesting working with cablelabs - since the last time there
was a big meltdown it was a cable modem that did it, it would be good to
get them on board for compliance testing.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 28 Nov 2007 09:31:48 -0800

> in the reply are cached for distribution as appropriate? With the pool

Precisely as many as appear in the DNS reply.  There is no upper or
arbitrary limit internally, so DNS limits apply.  If the query is
made via TCP, I understand the DNS reply packet can be up to 64KB,
of which a subset would be actual answers.

Note that although the construction of the option contents from DNS
names has no internal limit, the resulting data buffer may be too
large to fit into a DHCP reply packet (~312 bytes, possibly another
192 bytes) particularly with other higher priority configuration
values present.  In this situation, the data is omitted entirely
rather than truncated for inclusion.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Nov 2007 15:31:53 -0500

On Nov 28, 2007, at 2:23 PM, Josh Littlefield wrote:
> Perhaps you're confusing a problematic proprierary router that happens
> to embed a standard cable modem, with a standard cable modem.

That could certainly be the case.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Nov 2007 15:31:53 -0500

---

From: Danny Mayer <[email-masked]>
Date: Thu, 29 Nov 2007 01:25:14 -0500

Ted Lemon wrote:
> This is a different situation from a router vendor putting a default
> value in, in the sense that an ISP providing configuration information
> is actively advising their customer to do something, whereas a router
> vendor is just doing it.

Unfortunately it looks like yet another router vendor is doing this.
Information about this showed up in my email this afternoon. It's the
reason that I'm so leary of just having IP addresses. It's virtually
impossible to get the firmware updated in already shipped routers.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 29 Nov 2007 01:37:10 -0500

Danny

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 28 Nov 2007 18:19:29 -0500

Looking at several of the models mentioned
http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse, it appears
that most (if not all of) the "cable/DSL routers" are really dual-port
Ethernet routers that would sit downstream of a cable modem or DSL CPE,
in the subscriber's home network.

Two examples:

Netgear HR314 Cable/DSL High-Speed Wireless Router
http://kbserver.netgear.com/datasheets/HR314_ds_v3.pdf

SMC7004VBR Barricade(tm) Cable/DSL Broadband Router
http://www.smc.com/files/AN/ds_SMC7004VBR.pdf

(I couldn't find the D-Link model.)

These devices would look like subscriber computers from the broadband
provider's perspective.

Since these devices don't connect directly to the cable network, they
wouldn't be tested by CableLabs for conformance to specifications like
DOCSIS, because such specifications wouldn't apply.

-- Rich

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, November 28, 2007 3:32 PM
To: Josh Littlefield
Cc: [email-masked]; David L. Mills; Ted Lemon; [email-masked] WG
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP)
OptionsforDHCPv6

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 28 Nov 2007 14:23:43 -0500

> good to get them on board for compliance testing.

I have to ask, what would a cable modem have to do with anything.  Cable
modems do not use NTP (you can go read the DOCSIS spec to confirm that
if you like.) CableHome and PacketCable also do not use NTP.  They all
use RFC 868 TOD.

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 28 Nov 2007 14:28:53 -0500

DOCSIS and PacketCable for certain do not use NTP.

John
========================================= 
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
dc) 168*45683*22
=========================================

-----Original Message-----
From: Josh Littlefield [mailto:[email-masked]]
Sent: Wed 11/28/2007 2:23 PM
To: Ted Lemon
Cc: [email-masked]; David L. Mills; [email-masked] WG
Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) OptionsforDHCPv6

-josh

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Thu, 29 Nov 2007 18:36:58 +0100

Hello All,

Thank you very much for all your comments about our draft. 
Benoit and I did not expect such a passionate discussion when we 
submitted it 3 weeks ago.

With this email, I would like to summarize the current 
situation, objections, issues, and possible solutions. We will 
try to take into account as much as possible of the remarks and 
questions. The possibility of an increased risk of catastrophic 
event will be considered very carefully and will be mitigated.

First of all, I would like to expose again the motivation for 
this work (I believe there was some confusion about the 
rationale for it):

System administrators like to configure a large number of hosts 
from a centralized DHCP server. Today, DHCP is a protocol of 
choice for remote configuration of IP hosts. DHCPv6 is lacking 
the ability to configure NTP clients. This is our main 
motivation. So, this work is not intended to address some 
hypothetical NTP requirement to improve its peer discovery 
mechanisms. Instead, this work is intended to address a DHCPv6 
need to include NTP configuration. In other words, we are 
working in the context of DHCPv6, to make it more comprehensive. 
One may argue that some other protocol than DHCP might be more 
suitable for this, but our precise purpose is to extend DHCPv6 
expressiveness.

This is not a replacement for existing NTP configuration 
mechanisms. This will simplify the work of system administrators 
(or ISPs) by allowing global, remote configuration of NTP 
clients, instead of individual, per-host configuration of the 
ntpd.conf file. 

We try to be implementation agnostic. As someone mentioned, 
the parameters we selected exist in the reference implementation,
but they are also clearly defined as part of the NTPv4 
specification. The relevance of these parameters in DHCP 
will be discussed. Some of will be removed, some will be added 
(I encourage people in the NTP WG to propose some other useful 
parameters). All depends on the level of expressiveness we want 
to give to DHCP regarding NTP. In any case, all parameters will 
be optional (in the same way they are in ntpd.conf). Only the 
server identity will be required (IP address or FQDN depending 
on the outcome of the discussion about this).

That being said, I tried to collect all the issues you raised in 
a sort of 'dashboard' that I will update.

Issue #1: DHCPv6 NTP option may trigger some catastrophic event
---------------------------------------------------------------

This is similar to what happened in the past with hardcoded NTP 
servers IP addresses in SOHO routers. We can imagine that a 
badly designed SOHO equipment with an embedded DHCP server would 
advertise a hardcoded address over the SOHO LAN. There has been 
no consensus yet about the validity of this scenario:

- Some people think adding the possibility to carry an FQDN 
  instead of an IP address will solve this,

- Others think FQDN will not solve the issue but move it to the 
  DNS system, (though it might reduce the amplitude of the issue 
  due to the distributed nature of DNS),

- Others think this is a non-issue as DHCP servers in SOHO 
  equipments only redistribute information they got from their 
  client side. Bigger DHCP servers are manually configured. 
  
  The same problem would happen to DNS servers if SOHO equipments 
  would contain hardcoded DNS servers addresses. But in the case 
  of DNS, DHCP have contributed to avoid the issue rather than 
  amplifying it (please refer to the 2 messages Mark Andrews sent
  on sunday and monday for details).

Unless we all agree with Mark Andrews that this is a non-issue, 
we need to fully understand the exact use case involved if this 
problem can happen, and provide a way to avoid it. Next week 
discussions might be a good opportunity to clarify this.

=> Possible solutions include:

 - use of FQDN,

 - add clear statement an NTP server IP address MUST NOT be 
   hardcoded in a DHCP servers, unless it points to an equipments 
   operated by the vendor. describe the risk in the document 
   itself

 - mandatory use of FQDN ?

 - aren't KOD packets part of the solution ? (This draft only 
   addresses NTPv4 clients with IPv6 connectivity). Maybe we 
   can enforce support for KOD for clients supporting DHCP NTP 
   configuration.

Issue #2: Use of FQDN should be allowed for DNS indirection
-----------------------------------------------------------

Regardless the outcome of Issue #1, there seems to be some 
interest in the community to carry either an IP address or an 
FQDN (ntpd.conf also offers FQDN as a way to specify server 
identity).

We could re-define the option syntax to use sub-options. FQDN 
and Server address being 2 possible sub-options. Other 
parameters (if suitable) could also be defined as sub-options.

Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst)
--------------------------------------------------------------

When writing the first version of this draft, one of our goals 
was to allow better control of the tradeoff between NTP clock 
precision and traffic generated over a LAN. IPv6 has a large 
address space, and an IPv6 subnet can contain a huge number of 
hosts. Thus, it may be suitable to reduce the amount of traffic 
generated by NTP clients. On the other hand, some deployments 
may require fast and precise clock synchronization. Hence the 
Maxpoll, Minpoll, Burst and IBurst parameters. Again, these are 
not mandatory and will rarely be used.

- some people says you have to be an expert to set these 
  parameters and these should not be opened.

=> I do not understand why theworkstation users (controlling 
   their individual ntpd.conf file) would be more skilled to 
   set these parameters than network administrators (controlling
   the DHCP server)? 

If some parameter is questionable in a DHCP option, I think it 
is also questionable as an ntpd.conf option. Isn't it?

I do remember examples of customers requesting that their NTP 
clients quickly sync (and acquire time) on startup. If the network 
administrator wants NTP this kind of behavior, he will set the 
Burst flag to reach fast NTP convergence. Anything I missed here?

Issue #4: "maxpoll is useless"
------------------------------

Even people who like additional parameters, agree to say that 
maxpoll is useless (Brian, Dave). Could you explain why this is 
useless?.

Issue #5: "delay is useless"
----------------------------

The delay field serves as a trigger to enable/disable the 
client volley in multicast mode. Again, I don't understand why 
this is useless. The goal of this parameter is not to have the 
DHCP server to measure the network delay. It is simply to allow 
the network administrator to manually configure a constant delay 
to compensate for having no volley (please refer to  
http://www.cis.udel.edu/~mills/ntp/html/confopt.html where the
'broadcastdelay' option has a similar purpose). I believe the 
default 4ms might not be suitable for all network topologies.

Issue #6: "multiple instances versus list of addresses"
-------------------------------------------------------

The use of multiple instances of the same DHCP option to 
advertise several NTP servers seems to be somewhat confusing. 
Depending on the decision made for other issues, we will 
probably change the syntax of the options (or sub-options if 
any).

Having a list of "struct" or "records" is not usual in DHCP and 
it is not guaranteed that implementations will support it. This 
is why we opted for the simpler "multiple instances option" as 
we have some per-server configuration parameters (Key-ID, issue 
#7, might become another one). Any suggestion for a better 
syntax allowing a list of "struct" to be carried over DHCPv6 is 
welcome.

The sub-option syntax would enable easier future evolutions, but 
it seems difficult to use it to attach per-server parameters like
Burst or Key-ID (unless we consider the order of sub-options to 
be relevant, which is a bit weird, isn't it?).

Issue #7: Key ID
----------------

Some people suggest it might be useful to carry a Key ID with 
each server name/address. There is no opposition to this I 
believe.

Issue #8: Carrying an URL for a config file
-------------------------------------------

This has been suggested a few times, but has 2 major drawbacks:

 - It requires the client to be ftp/tftp/http-enabled (a lot 
   of complexity on the client),
   
 - It would be implementation dependant,

If sub-options are used in the DHCP message, we will certainly 
have the same level of flexibility. 

----

Please tell me if I made any mistakes, I would like to converge 
on a comprehensive list of issues.

Thanks you very much,

Richard.

---

From: Brian Utterback <[email-masked]>
Date: Thu, 29 Nov 2007 14:21:47 -0500

> Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst)

The ntp.conf file is overly flexible for most users and
gives more than enough rope to hang yourself mightily if youstart to 
stray from the usual settings.

We strongly discourage the use of maxpoll and minpoll by naive
users. Likewise you should never configure burst unless you
know what you are doing. On the other hand, you should probably
always configure iburst and I suspect that it will someday morph
into a noiburst option with iburst being the default.

> is also questionable as an ntpd.conf option. Isn't it?

Yep. There are a boat load of questionable parameters in the ntp.conf
file.

> Burst flag to reach fast NTP convergence. Anything I missed here?

That would be iburst, not burst.

> Issue #4: "maxpoll is useless"

Two reasons. First, the general reason that you should not be
specifying minpoll and maxpoll, is that it is unnecessary and
detrimental to the time keeping. Any reasonable client will
use the optimum polling period. Shorter poll intervals do not
necessarily give you more accuracy, nor longer ones less. There
is an optimum poll period that the client calculates and given
the likely round trip times in most DHCP configurations, that
optimum will already be in between the current min and max polls.

While having a minpoll makes a bit of sense, (i.e. do not poll
more often then *this*) maxpoll doesn't make sense at all. If
you lower it, then you are saying "do not poll less often than
*this*, even though you would like to." This is essentially
saying to use more resources than you would like to, so that
you get lower quality time synch. Making the maxpoll higher
than the default likewise doesn't make much sense, since it
is unlikely that the clients will get higher than the default
anyway. As long as the clients are in between the min and max,
it is best to let them do their own thing.

> Issue #5: "delay is useless"

Well, the problem is that the correct delay could be different
for different clients, and is difficult to determine by hand.
I am conflicted. While I agree it would be nice to be able
to tell the clients not to volley, you can't easily get the
right value, meaning you should probably allow the client to
volley.

-- 
blu

---

From: Brad Knowles <[email-masked]>
Date: Thu, 29 Nov 2007 13:31:56 -0600

>    can enforce support for KOD for clients supporting DHCP NTP

Unfortunately, many clients ignore KOD.  We can't depend on this 
being the ultimate saviour in UWisc-type events.

>  Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst)

As I see it, the bigger problem is that there is an amazing amount of 
potential complexity in the configuration file syntax of the 
Reference Implementation, and 99.99% of sites don't need that much 
complexity.  Therefore, I believe it would be a serious mistake to 
try to encode any significant amount of that complexity into DHCP.

Moreover, since the configuration file syntax is not standardized in 
an RFC (as the NTP protocol is), you would be encoding a proprietary 
implementation into your protocol standard.  I think the IETF should 
be violently opposed to doing such a thing.

>     set these parameters than network administrators (controlling

They wouldn't.

>  is also questionable as an ntpd.conf option. Isn't it?

This isn't a transitive case.  A implies B and C implies D does not 
necessarily mean that A implies D.

The difference is that we have an entire file to work with, and it's 
up to us how complex to make that process.  We're not trying to 
encode everything into 512 bits, or even just the "important" parts.

We're also not trying to publish the syntax for all NTP clients as an 
RFC -- this is just our own internal proprietary implementation, and 
doesn't have anything to do with the NTP protocol standard.  Other 
NTP clients are welcome to support a similar syntax (if they like), 
or they could do something totally different.  So long as they 
properly implement the protocol itself, it shouldn't matter what 
configuration file options and syntax they use.

>  Burst flag to reach fast NTP convergence. Anything I missed here?

Using "burst" is inherently bad, unless you own all the resources on 
both sides of the table, and even then it's probably not such a good 
idea in most cases.  This is not a nuclear weapon you want to give to 
J. Random Network Admin, or J. Random Embedded Vendor, or anyone else 
for that matter.

Using "iburst" is generally considered to be okay, since it only does 
a burst of packets on startup, and then operates normally afterwards. 
But in this case, we could argue that we could safely assume that 
iburst should be used in all DHCPv6-derived client configurations, 
and simply drop the entire "burst" or "iburst" configuration option 
altogether.

In fact, I would argue that most of the configuration options are 
unlikely to be useful in the general case.  They have accumulated 
over the decades as the protocol and the Reference Implementation 
have evolved, mostly to solve one or another edge case, and over the 
decades we've had a lot of these edge cases.

In some circumstances, after years of experience with the NTP 
protocol as it has evolved, and the Reference Implementation and how 
it has evolved, we've concluded that the assumptions we made years 
ago are no longer valid.  However, we're caught in a straight-jacket 
that we created for ourselves at the time because we could not see 
the potential need for any other view of the situation at that point. 
So, we have a lot of legacy cruft that has accumulated.  I really 
don't think that you want to try to incorporate our old legacy cruft 
into your new protocol standard.

Keep in mind that the legacy cruft I'm talking about doesn't have 
anything to do with the NTP protocol itself, it has to do with 
certain assumptions at various different points in the code that 
implements the operations related to the protocol, and other clients 
or servers could easily make different assumptions and yet still have 
fully interoperable implementations of the NTP protocol standard.

>  Issue #6: "multiple instances versus list of addresses"

I'm not getting this point at all.  Can you elaborate?

>  Issue #8: Carrying an URL for a config file

This is part of why I like the idea of a Simple NTP Configuration 
Service.  I believe it could be much simpler and easier to implement 
than FTP, TFTP, or HTTP.  And it would let us keep all the NTP 
configuration complexity outside of the DHCP protocol.

>  have the same level of flexibility.

Um, I don't think that your DHCP messages can be as long as our 
configuration files.

I wouldn't make any claims about your ability to have the same level 
of flexibility unless you want to include the full syntax of the 
proprietary configuration files that we support in the Reference 
Implementation.  I'm not sure how that lexer and parser are built, 
but I imagine it shouldn't be a problem to contribute that to a 
willing recipient project.

That said, I really don't think you want to try to implement anything 
remotely close to the full complexity of our configuration files, and 
I really don't think you want to implement anything that does not 
have it's own IETF standards-track RFC to guide you and associated 
working group with which to liaise.

Since none of the configuration file options you've mentioned have 
anything to do with the NTP protocol per se, I think you'd at least 
need to wait until some group takes up the task of standardizing the 
configuration file options and syntax for all NTP servers and clients 
-- including, but not limited to, the Reference Implementation.

There's one common theme here:

	Standard Protocol != Proprietary Configuration File Options/Syntax

One of these you can work with and interface with as part of your 
standard.  The other, I don't think so.

You don't encode Cisco router configuration file syntax into the DHCP 
standard (do you?), and I wouldn't suggest trying to do the same for 
NTP or the NTP Reference Implementation.

---

From: <[email-masked]>
Date: Thu, 29 Nov 2007 19:37:10 -0000

And not easy to implement where you have many thousands of clients as
you have to monitor each one individually to determine whether it is
behaving correctly and hence whether to send it the KOD.

Tony Flavin
-----Original Message-----
From: ntpwg-bounces+anthony.flavin=[email-masked]
[mailto:ntpwg-bounces+anthony.flavin=[email-masked]] On Behalf Of
Brad Knowles
Sent: 29 November 2007 19:32
To: Richard Gayraud (rgayraud); [email-masked]; [email-masked]
Subject: Re: [ntpwg] [dhcwg] Network Time Protocol (NTP)
OptionsforDHCPv6

>    can enforce support for KOD for clients supporting DHCP NTP

Unfortunately, many clients ignore KOD.  We can't depend on this being
the ultimate saviour in UWisc-type events.

>  When writing the first version of this draft, one of our goals  was 
> to allow better control of the tradeoff between NTP clock  precision 
> and traffic generated over a LAN. IPv6 has a large  address space, and

> an IPv6 subnet can contain a huge number of  hosts. Thus, it may be 
> suitable to reduce the amount of traffic  generated by NTP clients. On

> the other hand, some deployments  may require fast and precise clock 
> synchronization. Hence the  Maxpoll, Minpoll, Burst and IBurst 
> parameters. Again, these are  not mandatory and will rarely be used.

As I see it, the bigger problem is that there is an amazing amount of
potential complexity in the configuration file syntax of the Reference
Implementation, and 99.99% of sites don't need that much complexity.
Therefore, I believe it would be a serious mistake to try to encode any
significant amount of that complexity into DHCP.

Moreover, since the configuration file syntax is not standardized in an
RFC (as the NTP protocol is), you would be encoding a proprietary
implementation into your protocol standard.  I think the IETF should be
violently opposed to doing such a thing.

They wouldn't.

>  If some parameter is questionable in a DHCP option, I think it  is 
> also questionable as an ntpd.conf option. Isn't it?

The difference is that we have an entire file to work with, and it's up
to us how complex to make that process.  We're not trying to encode
everything into 512 bits, or even just the "important" parts.

We're also not trying to publish the syntax for all NTP clients as an
RFC -- this is just our own internal proprietary implementation, and
doesn't have anything to do with the NTP protocol standard.  Other NTP
clients are welcome to support a similar syntax (if they like), or they
could do something totally different.  So long as they properly
implement the protocol itself, it shouldn't matter what configuration
file options and syntax they use.

> administrator wants NTP this kind of behavior, he will set the  Burst 
> flag to reach fast NTP convergence. Anything I missed here?

Using "burst" is inherently bad, unless you own all the resources on
both sides of the table, and even then it's probably not such a good
idea in most cases.  This is not a nuclear weapon you want to give to J.
Random Network Admin, or J. Random Embedded Vendor, or anyone else for
that matter.

Using "iburst" is generally considered to be okay, since it only does a
burst of packets on startup, and then operates normally afterwards. 
But in this case, we could argue that we could safely assume that iburst
should be used in all DHCPv6-derived client configurations, and simply
drop the entire "burst" or "iburst" configuration option altogether.

In fact, I would argue that most of the configuration options are
unlikely to be useful in the general case.  They have accumulated over
the decades as the protocol and the Reference Implementation have
evolved, mostly to solve one or another edge case, and over the decades
we've had a lot of these edge cases.

In some circumstances, after years of experience with the NTP protocol
as it has evolved, and the Reference Implementation and how it has
evolved, we've concluded that the assumptions we made years ago are no
longer valid.  However, we're caught in a straight-jacket that we
created for ourselves at the time because we could not see the potential
need for any other view of the situation at that point. 
So, we have a lot of legacy cruft that has accumulated.  I really don't
think that you want to try to incorporate our old legacy cruft into your
new protocol standard.

Keep in mind that the legacy cruft I'm talking about doesn't have
anything to do with the NTP protocol itself, it has to do with certain
assumptions at various different points in the code that implements the
operations related to the protocol, and other clients or servers could
easily make different assumptions and yet still have fully interoperable
implementations of the NTP protocol standard.

>  The use of multiple instances of the same DHCP option to  advertise 
> several NTP servers seems to be somewhat confusing.
>  Depending on the decision made for other issues, we will  probably 
> change the syntax of the options (or sub-options if  any).

>  If sub-options are used in the DHCP message, we will certainly  have 
> the same level of flexibility.

I wouldn't make any claims about your ability to have the same level of
flexibility unless you want to include the full syntax of the
proprietary configuration files that we support in the Reference
Implementation.  I'm not sure how that lexer and parser are built, but I
imagine it shouldn't be a problem to contribute that to a willing
recipient project.

That said, I really don't think you want to try to implement anything
remotely close to the full complexity of our configuration files, and I
really don't think you want to implement anything that does not have
it's own IETF standards-track RFC to guide you and associated working
group with which to liaise.

Since none of the configuration file options you've mentioned have
anything to do with the NTP protocol per se, I think you'd at least need
to wait until some group takes up the task of standardizing the
configuration file options and syntax for all NTP servers and clients
-- including, but not limited to, the Reference Implementation.

	Standard Protocol != Proprietary Configuration File
Options/Syntax

You don't encode Cisco router configuration file syntax into the DHCP
standard (do you?), and I wouldn't suggest trying to do the same for NTP
or the NTP Reference Implementation.