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

[Harlan Stenn <[e-mail]>]

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.

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

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?
- Should the server respond with correct, or leap-smeared time?

This leads to the follow-on questions:

- How can the client know if it's getting correct, or leap-smeared time?
- How can one tell if a client is following a leap-smearing server?

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

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

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.

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.

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.

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.

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