[Git][NTPsec/ntpsec][master] Documentation ans spec improvements.

Eric S. Raymond gitlab at mg.gitlab.com
Wed Feb 6 05:34:34 UTC 2019


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


Commits:
682d28a2 by Eric S. Raymond at 2019-02-06T05:25:37Z
Documentation ans spec improvements.

- - - - -


4 changed files:

- devel/ntpv5.adoc
- devel/nts.adoc
- docs/warp.adoc
- pylib/packet.py


Changes:

=====================================
devel/ntpv5.adoc
=====================================
@@ -40,13 +40,7 @@ epoch.
 
 === NTS
 
-The IETF is attempting to develop a new cryptographic standard for
-secure/authenticated time exchange: Network Time Security.
-Further information on this is available at:
-https://tools.ietf.org/wg/ntp/
-
-The new protocol needs to allow a block of data of as-yet unspecified
-and possibly variable size to be dedicated to NTS use.
+The new protocol needs to support NTS extension fields.
 
 == Extensions vs. replacement
 
@@ -59,6 +53,10 @@ 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.
 
+There can be a way to unambiguously detect v5 packets.  The stratum
+field is 8 bits, but only the low five bits are used.  We can mark
+v5 packets by setting the high three bits.
+
 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
@@ -160,6 +158,124 @@ always report accurate, unsmeared time), but standardize a formula for
 translating NTP time into smeared UNIX time seen by other
 applications.
 
+== Decruftifying Mode 6
+
+It should be possible to shift a copy of mode 6 to UTF-8 JSON-RPC and
+rebadge it as a new mode 7.  The following is an overly verbose
+partial mockup of a transaction chain querying peer-stats.  All the
+numbers should be in _decimal_ without the hexadecimal timestamps and
+such.
+
+[source, json]
+----
+{
+   "jsonrpc" : "2.0",
+   "id" : 1,
+   "params" : {},
+   "method" : "readstat"
+}
+{
+   "jsonrpc" : "2.0",
+   "id" : 1,
+   "result" : {
+      "answer" : {
+         "associations" : [
+            62414,
+            62413,
+            62408,
+            62407,
+            62406,
+            62405,
+            62402,
+            62401,
+            62400,
+            62399,
+            62398
+         ]
+      }
+   }
+}
+
+{
+   "jsonrpc" : "2.0",
+   "id" : 2,
+   "params" : {
+      "association" : 62398
+   },
+   "method" : "readvar"
+}
+{
+   "jsonrpc" : "2.0",
+   "id" : 2,
+   "result" : {
+      "answer" : {
+         "hmode" : 3,
+         "filtdisp" : [
+            14.68,
+            1.5,
+            2.36,
+            3.45,
+            4.75,
+            5.19,
+            6.19,
+            7.12
+         ],
+         "keyid" : 0,
+         "dstadr" : "127.0.0.1",
+         "jitter" : 2.792031,
+         "dstport" : 123,
+         "rootdelay" : 0,
+         "dispersion" : 8.528601,
+         "flash" : 0,
+         "filtoffset" : [
+            -829.24,
+            -831.68,
+            -833.19,
+            -832.72,
+            -832.48,
+            -831.32,
+            -831.14,
+            -830.83
+         ],
+         "reach" : 255,
+         "mode" : 2,
+         "rootdisp" : 0,
+         "ppoll" : 6,
+         "reftime" : 3757323811.47605,
+         "delay" : 0,
+         "offset" : -829.240892,
+         "pmode" : 4,
+         "srcadr" : "127.127.46.0",
+         "precision" : -8,
+         "headway" : 0,
+         "hpoll" : 6,
+         "rec" : 3757323811.5776,
+         "xmt" : 3757323811.57759,
+         "stratum" : 0,
+         "srchost" : "GPSD(0)",
+         "unreach" : 0,
+         "srcport" : 123,
+         "leap" : 0,
+         "refid" : "GPSD",
+         "filtdelay" : [
+            0,
+            0,
+            0,
+            0,
+            0,
+            0,
+            0,
+            0
+         ]
+      },
+      "association" : 62398
+   }
+}
+
+
+...
+----
+
 
 // end
 


=====================================
devel/nts.adoc
=====================================
@@ -425,6 +425,10 @@ A wholly made up example cookie.
 
 == Unresolved issues for the next RFC WG
 
+The binary KE request-response format is unfortunate for all the usual
+reasons (endianness issues etc). At the expected transaction volume,
+the encode/decode overhead shouldn't be an issue.
+
 How to make NTS-KE work, securely, with pooled servers?
 
 The binary KE request-response format is unfortunate for all the usual
@@ -451,129 +455,7 @@ Network Time Security explicitly only supports modes 3 and 4 at this time.
 I see no reason why NTS could not be expanded to cover modes 1, 2, 6, and 7.
 Expansion to cover modes 6&7 should require an authentication token extension.
 
-=== mode 6 -> mode 7 next
-
-I feel that in keeping with comments. It should be possible to shift a
-copy of mode 6 to UTF-8 JSON-RPC and rebadge it as a new mode 7.  The
-following is an overly verbose partial mockup of a transaction chain
-querying peer-stats.  All the numbers should be in _decimal_ without
-the hexadecimal timestamps and such.
-
-[source, json]
-----
-{
-   "jsonrpc" : "2.0",
-   "id" : 1,
-   "params" : {},
-   "method" : "readstat"
-}
-{
-   "jsonrpc" : "2.0",
-   "id" : 1,
-   "result" : {
-      "answer" : {
-         "associations" : [
-            62414,
-            62413,
-            62408,
-            62407,
-            62406,
-            62405,
-            62402,
-            62401,
-            62400,
-            62399,
-            62398
-         ]
-      }
-   }
-}
-
-{
-   "jsonrpc" : "2.0",
-   "id" : 2,
-   "params" : {
-      "association" : 62398
-   },
-   "method" : "readvar"
-}
-{
-   "jsonrpc" : "2.0",
-   "id" : 2,
-   "result" : {
-      "answer" : {
-         "hmode" : 3,
-         "filtdisp" : [
-            14.68,
-            1.5,
-            2.36,
-            3.45,
-            4.75,
-            5.19,
-            6.19,
-            7.12
-         ],
-         "keyid" : 0,
-         "dstadr" : "127.0.0.1",
-         "jitter" : 2.792031,
-         "dstport" : 123,
-         "rootdelay" : 0,
-         "dispersion" : 8.528601,
-         "flash" : 0,
-         "filtoffset" : [
-            -829.24,
-            -831.68,
-            -833.19,
-            -832.72,
-            -832.48,
-            -831.32,
-            -831.14,
-            -830.83
-         ],
-         "reach" : 255,
-         "mode" : 2,
-         "rootdisp" : 0,
-         "ppoll" : 6,
-         "reftime" : 3757323811.47605,
-         "delay" : 0,
-         "offset" : -829.240892,
-         "pmode" : 4,
-         "srcadr" : "127.127.46.0",
-         "precision" : -8,
-         "headway" : 0,
-         "hpoll" : 6,
-         "rec" : 3757323811.5776,
-         "xmt" : 3757323811.57759,
-         "stratum" : 0,
-         "srchost" : "GPSD(0)",
-         "unreach" : 0,
-         "srcport" : 123,
-         "leap" : 0,
-         "refid" : "GPSD",
-         "filtdelay" : [
-            0,
-            0,
-            0,
-            0,
-            0,
-            0,
-            0,
-            0
-         ]
-      },
-      "association" : 62398
-   }
-}
-
-
-...
-----
-
-== Unresolved issues for the next RFC revision
-
-The binary KE request-response format is unfortunate for all the usual
-reasons (endianness issues etc). At the expected transaction volume,
-the encode/decode overhead shouldn't be an issue.
+More discussion of how to re-do Mode 6 has been moved to ntpv5.adoc.
 
 == Martin Langer's notes == 
 


=====================================
docs/warp.adoc
=====================================
@@ -192,6 +192,9 @@ Metrics] page.
 The principal standard informing the NTPsec software is
 https://tools.ietf.org/html/rfc5905[RFC 5905].
 
+Extension fields are described by
+https://tools.ietf.org/html/rfc5905[RFC 7822].
+
 Older NTP RFCs such as https://tools.ietf.org/html/rfc1305[RFC 1305]
 are no longer relevant.
 


=====================================
pylib/packet.py
=====================================
@@ -17,7 +17,7 @@ the general structure of an NTP packet (Figure 8):
        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   |
+      |LI | VN  |Mode |    Stratum    |     Poll      |  Precision    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Root Delay                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -66,6 +66,27 @@ Stratum and all following fields zeroed out to byte 47.
 
 How to interpret these fields:
 
+Mode is decoded as follows:
+
++-------+--------------------------+
+| Value | Meaning                  |
++-------+--------------------------+
+| 0     | reserved                 |
+| 1     | symmetric active         |
+| 2     | symmetric passive        |
+| 3     | client                   |
+| 4     | server                   |
+| 5     | broadcast                |
+| 6     | NTP control message      |
+| 7     | reserved for private use |
++-------+--------------------------+
+
+While the Stratum field has 8 bytes, only values 0-16 (low 5 bits)
+are legal. Value 16 means 'unsychronized' Value 17-255 are reserved.
+
+LI (Leap Indicator), Version, Poll, and Precision are not described
+here; see RFC5905.
+
 t_1, the origin timestamp, is the time according to the client at
 which the request was sent.
 



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/682d28a2973a1484f47087045cca795df0ff92a4

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/682d28a2973a1484f47087045cca795df0ff92a4
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20190206/e098b785/attachment-0001.html>


More information about the vc mailing list