[Git][NTPsec/ntpsec][master] Begin design notes for NTPv5.

[Eric S. Raymond]

Eric S. Raymond pushed to branch master at NTPsec / ntpsec


Commits:
433c44bb by Eric S. Raymond at 2017-01-09T08:05:22-05:00
Begin design notes for NTPv5.

- - - - -


2 changed files:

- devel/README
- + devel/ntpv5.txt


Changes:

=====================================
devel/README
=====================================
--- a/devel/README
+++ b/devel/README
@@ -22,6 +22,9 @@ ifdex-ignores::
 make-tarball::
 	Script for building a release tarball.
 
+ntpv5.txt::
+	Design notes towards NTPv5.
+
 packaging.txt::
 	Guidance for binary package builders.
 


=====================================
devel/ntpv5.txt
=====================================
--- /dev/null
+++ b/devel/ntpv5.txt
@@ -0,0 +1,125 @@
+= Preliminary design notes for the NTPv5 protocol =
+
+NTPv4 is showing its age.  There are functional capabilities that
+would be very useful if they could be standardized, but are not.
+
+This document will first list these missing bits, then discuss
+ways to incopporate them.
+
+== The missing data: a semantic view ==
+
+=== REFIDs ===
+
+Reference IDs are used by Stratum 1 sources to identify clocks and
+clock types, and by hosts at higher strata to perform loop detection.
+
+The REFID field is 4 octets long, sufficient to hold an IPv4 address
+for loop detection. This is inadequate for IPV6, so the reference ID of
+an IPv6 host is a 4-octet hash of itscactual address. Hash collisions
+have been observed in the wild, possiblty resulting in false-positive
+loop detection.
+
+The new protocol should support REFIDs at least as long as an IPv6
+address (8 octets).
+
+=== Timescale ===
+
+Most servers ship UTC.  Some ship TAI. Some perform leap-second
+smearing, some do not.
+
+The new protocol should enable a server to advertise its timescale,
+including its current leapsecond offset.
+
+=== Era ===
+
+NTP dates are 64-bit counters based on an epoch.
+
+The new protocol should enable a server to ship a year identifying its
+epoch.
+
+=== NTS ===
+
+The IETF is attempting to develop a new cryptographic standard for
+secure/authenticated time exchange: Network Time Security.
+
+The new protocol needs to allow a block of data of as-yet unspecified
+and possibly variable size to be dedicated to NTS use.
+
+== Extensions vs. replacement ==
+
+There are three possible scenarios for NTPv5 design.
+
+=== NTPv4+ ===
+
+In this incremental approach, the NTP port number (123) is retained
+and the 48-byte header v4 header is preserved. New data fields are
+passed in RFC7822 extension blocks.  The NTP version number is
+not incremented; "v5" becomes a set of required extension blocks.
+
+A difficulty with this approach is that some firewalls and routers are
+known to silently discard RFC7822 extension blocks as a way of
+preventing DoS attacks.  This would create propagation issues
+difficult to diagnose.
+
+=== NTPNG ===
+
+In this approach, a new port number is allocated. The protocol is
+design is unconstrained except that it must carry the semantic
+content of the v4 header minus the unused Reference Timestamp
+field.
+
+The principal difficulty with this approach is that getting all the world's
+firewalls to pass through a new port is not easy.
+
+=== Newmode ===
+
+In this approach, the the NTP port number is retained.  So is the
+first 32 bytes of the v4 packet header structure, so that the version
+number and packet mode are at the same offset as in v4. The version
+field *is* incremented to 5.
+
+The following payload is design is unconstrained except that it must
+carry the semantic content of the v4 header minus the unused Reference
+Timestamp field.
+
+implementations might not reject Version 5 packets, and therefore
+mis-parse the header.  NP Classic and NTPsec *do* perform this check.
+
+== Payload format design for the NTPNG and Newmode cases ==
+
+NTP is running out of version numbers.  The version field is only 3
+bits wide.  Accordingly, the Newmode payload should be structured like
+PNG, as a sequence of self-describing chunks that can be retired and
+replaced as needed to change payload semantics.
+
+Though NTPNG is not constrained by the width of the v4 mode field,
+the versionless semantics of a PNG-style chunk stream would confer a
+desirable degree of flexibility.
+
+The PNG standard can be found at https://www.w3.org/TR/PNG/
+
+A chunk system appropriate for NTP can be summarized as follows:
+
+* Each chunk begins with a four-octet big-endian length.  The length
+  does not count itself.
+
+* Each chunk continues with a 4-octet type identifier composed of
+  printable ASCII characters.
+
+* If the first character is uppercase, the chunk is *critical*; that
+  is, implementations encountering a critical chunk type they do not
+  recognize should treat the packet as erroneous.
+
+* If the first character is not uppercase, the chunk is non-critical
+  and may be skipped.
+
+* Chunk content is not constrained and is interpreted based in the
+  chunk type.
+
+Note that this is not identical to PNG chunk layout; one difference is
+that PNG chunks have only two-byte lengths and always end with a CRC.
+This chunk system is deliberately more similar to RFC7822 extension
+blocks.
+
+// end
+



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/433c44bbf76571e543365b07a9b7e01e907796af
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20170109/bcfd72be/attachment.html>