Re: [Ntp] Objections to the current language in draft-ietf-data-minimization

[Harlan Stenn <[e-mail]>]

On 3/26/2019 5:29 AM, Martin Burnicki wrote:
> Harlan Stenn wrote:
>> On 3/26/2019 3:26 AM, Martin Burnicki wrote:
>>> Harlan Stenn wrote:
> [...]
>>>> For better or worse, a noticeable group of time server operators now
>>>> offer leap-smeared time in response to NTP mode 3 (client) requests.
>>>> Sometimes this is what the clients want, sometimes it is not.
>>>
>>> The question is whether it is important what the client wants.
>>
>> I submit it will be important to the operator of the client, and that
>> may or may not be the same organization that operates the servers.
>>
>> What would happen if some of the general pool operators decided to offer
>> leap smearing?
> 
> I think I've read in the advices for pool servers that they should *not
> at all* use smeared time, so by definition no pool servers should
> provide smeared time.
> 
> I also think the pool maintainers pretty much know that this would be
> very dangerous, and will not allow for a mixed pool.

I'm not suggesting a mixed pool.

But I can certainly see the use by a vendor pool to have that pool offer
whatever time they choose, or have *.smeared.ntp.org as servers that are
known to smear the same way.

> In the past it happened that some pool servers were stratum-2 servers
> that synchronized to Google's smearing servers. This is clearly a
> misconfiguration (intentionally or not), and I think the pool's
> monitoring system should try to detect this and kick them out of the pool.
> 
> Of course the problem remains for clients which have just recently
> received the IP address of affected servers from the pool's DNS system.
> 
>> Compare this to the vendors Foo, and Bar, who have separately arranged
>> to offer foo.pool.ntp.org and bar.pool.ntp.org.  If Foo decides its
>> clients should use correct time, they have their pool servers offer
>> correct time.  If Bar decides its clients should use leap smeared time,
>> they have their pool servers offer that.
> 
> No, if the pool should support leap smearing then an extra pool should
> be set up with a different name. In addition, if this happened at all,
> vendors Foo, and Bar would have to agree *how* their servers smear the
> time: which interval, which shape, only before the LS or symmetrically, ...
> 
> Otherwise this would cause even more confusion than it does now.

Agreed.

> [...]
>>> Agreed. What should the server do if the client doesn't accept a
>>> proposed poll interval? There are lots of simple, dump clients out there
>>> where I doubt they can and do change the poll interval at all.
>>
>> All we can do is make a good-faith offer.  This satisfies our
>> responsibility *to* the client.  We are not responsible *for* the
>> client's behavior.  If the client doesn't honor our poll request and
>> doesn't sync well enough, then if the client doesn't care then ... they
>> don't care.  If the clients *do* care they have an opportunity to make a
>> different choice.
> 
> This is fine since it's optional and compatible with simple client
> implementations.
> 
> [...]
>>>> - Does the client want leap-smeared time?
>>>
>>> Is it important what the client wants?
>>> Or just what the operator has decided to enforce?
>>
>> It depends.  I touched on this above.  And sometimes servers will send
>> client requests to monitor and track other systems.
> 
> This is again a completely different scenario since monitoring results
> are normally not used to discipline the own system time.

Of course.  But if there are systems that are communicating with each
other using modes 3/4, implementing this proposal will wipe out most all
of the data in the mode 3 query.

It's about information, not actual time synchronization.

>> One of my goals here is to give the recipient of these responses the
>> tools and information that will allow them to make choices that are
>> right for them.
>>
>>>> - Should the server respond with correct, or leap-smeared time?
>>>
>>> IMO, if the server has been configured to provide leap-smeared time then
>>> it should do so by default, but eventually there may be exceptions. See
>>> below.
>>
>> :)
>>
>> And what happens if a server operator changes their mind about this at
>> some point in the future?
> 
> Public server shouldn't smear at all,

Many agree with you, including me.  But that doesn't stop an increasing
number of Very Big Players from doing it anyway.

> and if the operator of a private server decides
> to change this he should know which clients are affected.

I'm not so sure about this.  How can the operator of a private server be
expected to know or care who is contacting it?

> It's the same if an operator decides to let his server start smearing
> leap seconds.

>>>> This leads to the follow-on questions:
>>>>
>>>> - How can the client know if it's getting correct, or leap-smeared time?
>>>
>>> If the server supports this (e.g. current ntpd does), the client can
>>> *optionally* check the refid received from the server and see that it's
>>> the special "smear REFID". This should be just informational.
>>
>> Yes.
>>
>>>> - How can one tell if a client is following a leap-smearing server?
>>>
>>> Again, if the client detects the "smear REFID" received from its system
>>> peer a monitoring program like ntpq could display the appropriate
>>> information.
>>
>> This goes to the SUGGESTED-REFID.  Even if it's not used, I currently
>> believe that if ntpd in 4.4.0 syncs to a leap-smearing source, even if
>> that source does not use SUGGEST-REFID, there will be code to make sure
>> that the client's published system peer is a leap-smear REFID, for the
>> following reasons:
>>
>> - it shows up in ntpq.
>> - it allows the 2nd half of the leap smear to be applied as expected.
> 
> The question is of legacy NTP clients would put the "smear REFID" into
> packets sent to the server. If they don't do so then your proposal will
> cause problems.

OK, and I am genuinely curious how big a problem it will be.  Especially
since Somebody had to decide what server to connect to.

Remember, in the case you describe it appears to be pretty clear that
highly accurate and well-synchronized time is not very important.  Do
you disagree?  And the problem you are talking about is that after the
leap second event, eventually the client will correct a half-second of
offset.  That might happen immediately (in the case of behavior like
sntp), or it could take ~6 poll intervals.

>>>> If the client sends a packet
>>>> with LI=0x3, the server SHOULD also respond with correct time with an LI
>>>> value of 0x0, 0x1, or 0x2.
>>>
>>> No, here I disagree. If the client sends leap bits 0x3 this means it is
>>> currently not synchronized, and the server may be the only time source
>>> the client has. If the server operator has decided to let the server
>>> smear the leap second then it should really do so in this case.
>>
>> I considered this case, and this is why I made the decision I wrote above.
>>
>> If the client is able to handle the leap second then we should give it
>> the opportunity to do so.  There's a chance the client will iburst, so
>> it will likely sync after 6 of the 8 iburst polls.  In this case, the
>> 7th poll will contain either LI=0, meaning it doesn't believe that a
>> leap event is pending, or it will send LI=1.  As soon as it sends either
>> of these, the server knows how to respond to the client.  And if the
>> time is close enough or in the leap smear period, the server may well be
>> telling the client to use a shorter poll interval, so even if the client
>> went from LI=3 to LI=0 it will continue to use a shorter poll interval
>> and shift from correct time to smeared time.
> 
> And how do you know from the beginning if a client uses iburst?

As a server I have no idea.  But if it's running ntpd or similar, it
will still sync up in about 6 polls, no matter what the poll interval is.

> What if a simple client always just sends LI 0x03?

Then it will get the documented response.

>> I even think I have a way to help this along even better, with an update
>> to the EXTENDED-INFORMATION extension field.
>>
>>>> If the client sends its request with an LI value of 0x0 before leap
>>>> smearing starts, the server SHOULD respond with correct time with an LI
>>>> value of 0x0, 0x1, or 0x2.
>>>
>>> No. If the server has been configured to smear the time and hide the
>>> leap second then it should do so by default, which also means *not* to
>>> send a leap second warning to a client unless the client clearly
>>> indicates in its request that it anyway knows about the upcoming leap
>>> second. Only in this case the server should send the leap second warning
>>> flag 0x1 or 0x2 and true UTC instead of smeared time.
>>
>> If you want your server to ALWAYS send smeared time, then you are right.
> 
> That's the intended behavior when using leap second smearing.

There's what the server intends, and what the client intends.  They may
or may not be the same...

>> If you want your server to offer correct time to clients that know how
>> to handle the leap second and smeared time to clients that do not state
>> they know how to handle a leap second, then I probably disagree with you
>> and I'd appreciate our discussing this more so we can come to an agreement.
> 
> My main goals would be to not break compatibility with existing clients,
> don't make configuration more complex than absolutely necessary, and
> only if possible without side affects provide optional ways to improve
> the client's behavior and resulting accuracy.

If you know your clients and how they will behave, in what way does this
proposal do worse than what you have now?

I'm pretty certain that with what I've described, you can set up your
system to behave exactly same way with the new code that you have it
behave with the old code.

And if it behaves the same way, where is the problem?

Do you disagree?

>>>> If the client sends its request with an LI
>>>> value of 0x0 *during* a leap smear correction, the server SHOULD respond
>>>> with leap-smeared time and an LI value of 0x0, and MAY respond with
>>>> correct time and an LI value of 0x1 or 0x2.
>>>
>>> No. IMO, if the client sends leap bits 0x0 or 0x3 then the server MUST
>>> NOT respond with correct time and an LI value of 0x1 or 0x2 if it has
>>> been configured to smear the leap second.
>>
>> I do see your point and I remember thinking about this a lot, and there
>> was a reason I wrote what I did.  That reason could be as simple as
>> "SHOULD" means "you really really should do this, unless you have a Good
>> Reason not to, in which case you MAY respond with LI=[12] and correct
>> time." Put another way, I'm leaving an "escape hatch" for the
>> possibility that there's a special case that hasn't been considered.
>>
>>>> Furthermore, responses containing leap-smeared time SHOULD include a
>>>> REFID that identifies the "system peer" as a leap-smeared source.  See
>>>> draft-stenn-ntp-leap-smear-refid for more information.  This response
>>>> also SHOULD include a SUGGESTED-REFID extension field, as described by
>>>> draft-stenn-ntp-suggest-refid, to make it obvious that the system is
>>>> following leap-smeared time.  These points address the  two follow-on
>>>> questions.
>>>
>>> This is a good idea, but older clients or other client implementations
>>> may not recognize the LEAP-SMEAR-REFID as a special case, and they may
>>> not even accept a response from a server that has an extension field
>>> they don't expect.
>>
>> Agreed, and that's what the I-DO EF is for.  If the client sends this,
>> the server knows what the client can accept.
>>
>> It's been my experience that we don't want to send unsolicited EFs in
>> server responses.
> 
> That's what I meant.
> 
>>> So eventually extension field handling should be mandatory for v5 of the
>>> NTP protocol, and only if a v5 client request is received the server
>>> should append that extension field.
>>
>> Agreed.
>>
>>> BTW, is there a common place to collect suggestions for v5 of the NTP
>>> protocol?
>>
>> I have a list of our ideas, and I'm happy to set up a place for it.
> 
> That would be appreciated.

OK, I've started that process going.

>>>> The LEAP-SMEAR-REFID and SUGGESTED-REFID extensions have another key
>>>> role during the application of a leap smear - that of making sure the
>>>> system behaves properly during the last half of the 12/12 leap smear
>>>> correction.
>>>>
>>>> Once the leap second has applied, the LI value for correct time reverts
>>>> to 0x0.  When a leap smearing client asks for time during the second
>>>> phase of this correction, it will be sending its requests with LI=0x0,
>>>> as *all* time requests from a leap-smearing client will contain LI=0x0
>>>> when a leap event is not pending.  But in this case, how does the server
>>>> know it should continue sending leap-smeared time, as opposed to correct
>>>> time?  The answer is that the client requests include the client's
>>>> REFID, which in this case SHOULD be a LEAP-SMEAR-REFID.
>>>>
>>>> When a server receives a mode 3 (client) request containing a
>>>> LEAP-SMEAR-REFID during the second phase of a leap-smear correction, the
>>>> server SHOULD respond with leap-smeared time and a LEAP-SMEAR-REFID as
>>>> the SUGGESTED-REFID.
>>>
>>> Of course, the server should continue to send smeared time and the
>>> LEAP-SMEAR-REFID as long as smearing is still in progress, but as I've
>>> mentioned before, it should not append an extension field by default if
>>> the client request is protocol v3 or v4.
>>
>> Certainly not for v3, as EFs didn't exist there.  I'm fine with sending
>> known-allowed EFs in v4 responses.
> 
> Which EF discussed here is known-allow for all or non-current NTPv4
> implementations?

I-DO is the proposal that makes this easy, at least for folks who use
the chalkboard we set up to track EF proposals.  I addressed this with
part of draft-stenn-ntp-extension-fields, but the WG decided that the
proposal was not worth pursuing.

>>> However, if the server *only* responds with leap-smeared time if it
>>> receives the LEAP-SMEAR-REFID from the client then I'd expect that this
>>> *breaks compatibility* with many simple client implementations that are
>>> out in the wild. If such clients won't send this special REFID then they
>>> would get non-smeared time back from the server after the leap second
>>> has occurred, which may cause a 0.5 s time step on the client.
>>
>> Yes.  And in that case there are several options to avoid this problem:
>>
>> - configure the clients to query servers that will give them the time
>> they want (there are several ways to do this),
> 
> That's the basic idea. If the client just has to use smeared time I
> configure a server that provides it, and if I don#t want this I choose a
> "normal" server. This doesn't require any tricks.

Yes.

>> - get motivated to upgrade the client software after the next leap second.
> 
> I think you know this is often not possible due to various reasons.

Of course.  But eventually it works out.

>>> I don't think this consistent with the original idea of leap smearing,
>>> which should explicitly avoid time steps.
>>
>> Yes, but if the client is following a regular server they'll step by a
>> second.  If they follow a leap smear server then they won't step.  And
>> if they follow a "new style" server that offers smeared time to folks
>> who only send a leap smear refid in the last half of the correction then
>> they'll step a half-second correction.
> 
> Yes, and the operators of the client machine will be happy if they
> configured leap smearing to avoid time steps, and now the time sis
> stepped in spite of the smearing.
> 
> Sorry Harlan, but this sounds pretty error prone.

Nobody has to use any of it.  And sure, it's possible to configure
things in a way that causes trouble.

But I'm pretty sure that this proposal gives people the server mechanism
(choices) they need to select the policy they want, and the clients
remain perfectly free and capable to select whatever servers they want.

But please show me how what I'm proposing is *worse* that what we have now.

> Martin
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!