[LEAPSECS] DNS examples

[Steffen Nurpmeso]

Rob Seaman <seaman at noao.edu> wrote:
 |On Jan 22, 2015, at 7:47 AM, Steffen Nurpmeso <sdaoden at yandex.com> wrote:
 |> Rob Seaman <seaman at noao.edu> wrote:
 |>> I think it’s clear that DNS won’t support all leap second \
 |>> use cases, but that it may provide a high reliability / \
 |>> low latency method for some specific purposes.  Here is \
 |>> PHK’s specific example...
 |> 
 |> Below a simple C version for the interested.  It doesn't \

 |We should be careful not to settle on a specific encoding \
 |yet.  PHK himself was discussing different options after providing \
 |his python example.  Notes on the different parts of the encoding:

I actually have had written a patch (attached) on top of the
second source with two changes that somewhat tend into that
direction.

 |1) IPv4 class E - yes, we should do it this way with the expectation \
 |that an IPv6 implementation will ultimately replace it, likely \
 |with more features, longer checksums, etc.
 |
 |2) Count of months - yes (as opposed to only supporting June/December, \
 |for instance).  There is a value here in simplicity and this \
 |should simply be an integer count starting with January 1972. \
 | Making it more clever would increase the likelihood of bad \
 |implementations, plus January = 1 provides for easy modulo arithmetic.

One of them is that the count of months start 2014 not 1972, which
extends the representable range of years until 2099.  It is hard
to believe that all the engineering and developing that _will_
take place until 2057 won't introduce other mechanisms, whatever
they will be, but i thought it is quite useless to count the 42
years that will never be tracked by us: why not introduce yet
another Y2.1K problem.

 |3) Count of leap seconds.  Again, keep this as simple as possible \
 |and just use an integer representing the explicit difference \
 |between TAI and UTC.  Due to the huge leverage of the accumulated \
 |35s we're starting with, this can be an unsigned count.  (That \
 |is, by the time we saw a couple of dozen straight negative \
 |leap seconds eating into this total we would start to get \
 |the idea that refactoring was necessary.)

And the other adjustment was that the base drift now is 9-bit, not
8-bit, still signed though, reaching from -255 to +255.

 |4) Flags.  The current encoding fits a -1/0/1 triad in two \
 |bits.  Suggest that this should rather be two separate flags: \
 | Is there a leap second?  Is the leap second positive or negative? \
 | Alternately the fourth case could be used for some separate \
 |option, but I haven't been able to see what that would usefully be.

And here i simply reduced that from 2-bit to a single bit, stating
wether it is a positive leapsecond.  Only if a leapsecond occurs
the DNS record will be updated at all, so it really makes no sense
to store more than a single bit.

 |5) CRC.  A CRC is a hash/checksum tuned to be sensitive to \
 |bit errors, e.g., errors in transport.  While catching these \
 |is of interest to us, the bigger issue is to detect lies introduced \
 |by bogus public wifi, etc.  Lies come in the form of different \
 [.]

What i think: that all can't be helped unless DNS is secured by
itself.  Maybe there will be (my gut feeling was always against
DNSSEC) DNS/DTLS and/or DNS/TLS-ALPN (in addition to DNSSEC).
But nonetheless using a CRC in the PHK DNS A record offers some
protection against address spoofing, since in order to redirect
you need to have a address that generates a valid CRC again, and
first of all you need to know at first glance.
I've just read again that "Unlike IPv4, when UDP packets are
originated by an IPv6 node, the UDP checksum is not optional."
[RFC 2460].
There are people in existence for who adjusting a CRC-5 or CRC-6
is nothing but a finger exercise.  I'm not one of those :)

 |6) Size of fields.  There is an advantage to using more standard \
 |size ints than 11-bit unsigned months and 7-bit signed leap \
 |seconds most recently suggested.  For instance, a 12-bit month \
 |tally would provide coverage for three centuries into the \
 |future.  And an 8-bit unsigned count would permit more than \
 |200 leap seconds during that time.  So the first half of the \
 |pseudo-address would be the class E pedestal followed by the \
 |months, and the second half would be the leap tally, two flags \
 |plus a 6-bit checksum.  A 6-bit checksum still would detect \
 |more than 98% of the very few errors/lies that manage to get \
 |past the class E check.
 |
 |An alternate that would preserve space for the 8-bit CRC would \
 |be to combine the "Is there a leap?" flag as a sign bit on \
 |a 12-bit signed month tally, and the positive/negative flag \
 |as a sign bit on an 8-bit signed TAI-UTC offset.  This would \
 |provide for 90+ future leap seconds (assuming all positive) \
 |over a bit more than a century to come.  One might expect \
 |we would have transitioned to IPv6 by then, retiring this format naturally.
 |
 |The parsing would be quite straightforward for a 4 + 12 + \
 |8 + 8 layout, and the flags would be recoverable as simple \
 |+/- tests, with absolute values for the magnitudes.  Plus \
 |the simplicity of modulo arithmetic for the month of the year. \
 | Presumably we would want 2's-complement ints.

Well.  PHK follows the IERS format which uses the 1st of the month
after the leap second, i.e., the second after the leap occurred.
When really thinking about it.. i would maybe have started off
trying to use the day which will introduce the leap second, but
i don't know the rationale behind the decision.  With 2 bits for
a day number (X - 28) the exact date of the leap second could be
collected from the record without any further calculation.
I would consider this as an improvement.  The checksum had to be
adjusted or dropped.
With the diff below (i'm not using bitfields) we'd end up

  * - Months since 2014: 10-bit

Until 2099-04 (-01).

  * - Base drift before leapsecond: 9-bit

These 9-bit are in effect an 8-bit unsigned count plus a sign bit.

  * - Drift adjustment: 1-bit (set: positive)
  * - CRC-8 PHK checksum: 8-bit

--steffen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phk-utcdrift.diff
Type: text/x-diff
Size: 3096 bytes
Desc: not available
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150122/8aceec72/attachment.diff>