[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