[Ntp] A different NTPv5 design

[Miroslav Lichvar <[e-mail]>]

I thought I should propose a more conservative design for NTPv5 than
what Daniel posted few weeks ago. It's an evolution of NTPv4,
following the "If it ain't broke, don't fix it" rule. It uses some
ideas from the Daniel's proposal and I think it addresses the same set
of NTPv4 issues from the wiki page, but it still looks like the NTP
everyone knows. Authentication is still optional.

A minimal support can be easily implemented in existing NTP servers
and other software/hardware that needs to work with NTP packets.
Responding to NTPv5 requests with NTPv4 packets works as with the
previous versions.

The design is described here as changes to NTPv4. If people think they
would support something like this, I can write it as a full draft. The
draft would just specify the protocol. The algorithms would be expected
to have a separate draft if there is a need to have (some of) them
specified.

Changes in packet structure
---------------------------

- Packets cannot have a MAC field appended (it's replaced by an extension
  field)

- Extension fields can be of any length, even indivisible by 4, but are
  padded to 4 octets (NTPv4 extension fields are compatible with NTPv5)

- Servers ignore unknown extension fields and pad responses to the
  length of the request using a padding extension field (i.e. clients
  can rely on getting a useful response even when requesting an
  unsupported extension field)

Removed fields in header
------------------------

- Reference ID is removed (replaced by an extension field)

- Reference timestamp is removed (unused in NTPv4)

Modified fields in header
-------------------------

- Mode can have only a value of 3 (client) and 4 (server)
  - broadcast mode is less accurate and difficult to secure (leave this
    mode to PTP)
  - symmetric mode has security issues, is rarely useful and can be
    replaced with an (authorized) extension field requesting reversed
    synchronization using the client-server mode
  - monitoring and management protocols should use a different port

- Leap indicator is set up to 14 days before the leap second
  - enough time for distribution, but no risk of leap seconds
    getting stuck between subsequent months

- Poll value in a response is the minimum polling interval to be used
  by the client

- Root delay and dispersion are shifted to left by 12 bits
  - resolution of ~4ns and maximum value of 16 seconds

- Client requests follow the data minimization draft (with some
  modifications for the new fields)

New fields in header
--------------------

- Flags (5 bits)
  - Multi-message response
    - client indicates it's willing to deal with follow-up messages
      (valid cookie is required)
    - server indicates that a follow-up message may follow this message
      (i.e. the client should wait for more messages before processing
      the response)
  - Follow-up message
    - server indicates this is a follow-up message, which has a more
      accurate transmit timestamp. Multiple follow-up messages are
      allowed. All messages in the response are in the server mode and
      have the same length.
    - if the client gets a response with the multi-message or
      follow-up bit set, it waits for a message with the multi-message
      bit unset (e.g. for up to 10 milliseconds). It uses the latest
      transmit timestamp from the messages it received. As the receive
      timestamp of the response it can use the receive timestamp of the
      message which didn't have the follow-up bit set, or the timestamp
      of the first message it received (which had the shortest delay).
  - (Interleaved mode, which has the opposite memory/bandwidth tradeoff
     to the multi-message response, could be requested with a separate
     flag, or it could use the origin timestamp as before)

- Timescale (3 bits)
  - client selects the timescale (UTC, TAI, UT1, leap-smeared UTC,...)
    for timestamps in the response
  - server responds in the requested timescale, or a different timescale
    if the requested one is not supported

- Era (8 bits)
  - server provides the NTP era of the receive timestamp, which
    extends the unambiguous interval from ~136 years to ~35000 years
  - (clients can still have a hardcoded pivot date and ignore the
    era number to simplify the operations with the timestamps)

- Timescale-specific field (16 bits)
  - with the UTC and TAI timescales server provides the TAI-UTC
    offset of the receive timestamp as a signed integer
    (0x8000 if unknown)
  - with a leap-smeared timescale it can be an identifier of the
    smearing function to enable a reconstruction of UTC/TAI

- Cookie (64 bits)
  - server provides clients with a cookie tied to their address
  - client returns the latest cookie it received to enable a
    multi-message response
  - server key is rotated frequently (unlike in NTS) to shorten the
    interval when a leaked cookie can be exploited for amplification
    attacks

Extension fields
----------------

- Padding
  - used for padding requests and responses

- MAC
  - replacement for NTPv3/NTPv4 MACs

- Reference IDs
  - requested by clients that operate as servers to get a set of
    reference IDs in order to avoid a synchronization loop
  - uses a bloom filter similarly to the Daniel's proposal

- Correction field
  - modified by routers/switches to compensate for their processing and
    queuing delays
  - same or similar to the correction field proposed for NTPv4

- Monotonic timestamp
  - an extra receive timestamp (with a step counter) from a clock
    which has an unsynchronized phase and can be used for a frequency
    transfer in the selected timescale
  - similar to the recv field in the Daniel's proposal
  - not expected to be supported by all servers and clients

NTPv5 packet format
-------------------

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |LI | VN  |Mode |    Stratum    |     Poll      |  Precision    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Root Delay                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Root Dispersion                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Flags  |Scale|     Era       |       Timescale-specific      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                            Cookie (64)                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Origin Timestamp (64)                    +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Receive Timestamp (64)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Transmit Timestamp (64)                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                    Extension Field 1 (variable)               .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                    Extension Field N (variable)               .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


-- 
Miroslav Lichvar