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

[Harlan Stenn <[e-mail]>]

On 3/26/2019 3:26 AM, Martin Burnicki wrote:
> Harlan Stenn wrote:
>> In my opinion, draft-ietf-ntp-data-minimization-04, like its -03
>> predecessor, exclusively focuses on ways to expose as little information
>> as possible and completely ignores and discounts the costs or problems
>> that can and in some cases will occur if its recommendations are followed.
>>
>> If my claims are accepted, section 1. Introduction of
>> draft-ietf-ntp-data-minimization should be appropriately rewritten to
>> remove its incorrect, or at least misleading, claims, and many of the
>> “SHOULD” recommendations in the document should be changed to “MAY”.
>>
>> In particular, draft-ietf-ntp-data-minimization blindly and explicitly
>> recommends setting LI, the poll interval, and the REFID to 0, with no
>> offered analysis for the costs or benefits of the effects of these
>> recommendations.
> 
> I basically agree with Harlan. Even though these details are not
> *required* in client/server mode, they can help to optimize the client's
> behavior and performance.
> 
>> In this email I’ll use a leap second event to illustrate these points.
>>
>> Regardless of whether or not you believe leap smearing is “good”, there
>> are time servers out there that only offer correct time, some that only
>> offer leap-smeared time, and some that offer one or the other -
>> depending on how they’re asked.
>>
>> 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?

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.

> Leap second smearing is a hack to hide a leap second from the client(s),
> and the operator decides to so so, or not.

Agreed.  And I'd augment that to say it's Good if we give arbitrary
clients a way to detect this, and if they choose, make decisions based
on what the server tells them.

>> Regardless, there is clear value and benefit in being able to see if:
>>
>> a server is offering correct, or leap-smeared time
>> a client is following a correct, or a leap-smearing server
>>
>> Let’s look a the poll interval first.  If a server knows a leap second
>> event is coming, it is in a position to look at the poll interval from
>> the client and send back a recommended poll interval that will make sure
>> the client properly handles leap second handling.  Yes, even if the
>> client “lies” and doesn’t tell the server its actual poll interval, the
>> server can respond conservatively, and be responsible to the client.
>> This behavior may well cause an unnecessary increase in the server load.
>>  It is also possible that the server may choose to remember the IP and
>> port of the incoming request to independently try and verify the actual
>> poll interval used.  But this is also a case of cost-shifting, and I am
>> opposed to it.
> 
> 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.

>> Now let’s move to the approaching leap second event.  In this case, I’ll
>> be assuming the behavior of what I call 12/12 leap smearing, where a
>> half-second of correction is applied beginning at UTC noon on the day of
>> the leap second (ie, for 12 hours’ time), and the final half-second of
>> correction is applied starting at midnight UTC after the leap second was
>> applied until UTC noon on the day after the leap second (ie, for the
>> remaining 12 hours’ time).
>> To save folks from having to look it up, NTP communicates knowledge
>> about pending leap events via the first two bits of the NTP packet,
>> known as the LI, or Leap Indicator bits:
>>
>>  0x0	Normal time
>>  0x1	Last minute of the last DOM has 61 seconds
>>  0x2	Last minute of the last DOM has 59 seconds
>>  0x3	Not synchronized
>>
>> NTP instances sending mode 3 (client request) queries expect to receive
>> a mode 4 (server) response.  This response may be the correct time, and
>> it may be leap-smeared time.  The key questions are:
>>
>> - 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.

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?

>> 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 following simple solution handles both of the first two questions.
>>
>> If the client sends its request with LI values of 0x1 or 0x2, it is
>> telling the server that it believes a leap event is pending.  In this
>> case the server SHOULD respond with correct time with an LI value of
>> 0x0, 0x1, or 0x2; not leap-smeared time.
> 
> This sounds reasonable at the first glance. If the client has already
> received a the leap second announcement from a different source then it
> is anyway aware of the leap second and will handle it normally. In this
> case it doesn't make much sense to spoof this client and send him a
> smeared time to hide the leap second.
> 
>> 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.

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.

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.

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

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

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

> 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),
- get motivated to upgrade the client software after the next leap second.

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

But we're back to the case where we have to ask the question "how
important is it to the client to have accurate time?"

> On the other hand, this problem wouldn't even arise if the leap second
> smearing is 24/0 and thus is finished if the leap second occurs.

Yes, and that's a local policy choice which some folks may well choose
to select.

>> When the leap-smear correction has ended, normal query/responses will
>> again be in effect.
>>
>> Finally, servers should know when a leap event is about to occur.  Other
>> systems may not have this information.  It’s polite, cooperative, and
>> informative if the client sends its poll interval to the server.  A
>> server that knows a leap second event is coming SHOULD reply with a
>> suggested poll interval that will, even in the face of dropped UDP
>> packets, allow the client that pays attention to the suggested poll
>> interval from the server to re-query often enough to quickly track these
>> events and stay well-synchronized.
> 
> This is correct. If a client has increased its poll interval in
> continuous operation because the frequency correction is stable then
> it's a good idea to let the server suggest a shorter poll interval
> before the leap smearing starts and ends.
> 
> This should be really helpful to minimize the client's time offset error
> caused by the frequency change at the beginning and end of the smear
> interval.
> 
>> In short, if you care about data minimization more than you care about
>> having accurate synchronized time, minimize away.
>>
>> If you are primarily interested in having accurate synchronized time,
>> playing nice with others, getting the time you want and be able to see
>> what's going on during a leap second event:
>>
>> - be honest with your LI bits
>> - be honest when reporting your poll interval
>> - pay attention if a server asks you to adjust your poll interval
>> - consciously choose the REFID in your messages
>>
>> The upcoming (full) Reference Implementation release of ntp-4.4.0 from
>> the NTP Project will have these behaviors in it.
> 
> Exactly as you've described it above? This will break compatibility with
> non-ntpd-4.4.x clients.

Out of the box the default configuration will behave the same way
ntp-4.2.8 behaves.  Admins will have the *option* to select something
different.

> Martin

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