TEXT 28
Draft-alavarez-hamelin-tictoc-sic-05.txt Guest on 13th August 2020 04:37:58 AM
  1.  
  2.  
  3.  
  4.  
  5. TICTOC                                           J. Alvarez-Hamelin, Ed.
  6. Internet-Draft                     Universidad de Buenos Aires - CONICET
  7. Updates: none (if approved)                                 D. Samaniego
  8. Intended status: Standards Track                               A. Ortega
  9. Expires: November 1, 2020                    Universidad de Buenos Aires
  10.                                                                  R. Geib
  11.                                                         Deutsche Telekom
  12.                                                           April 30, 2020
  13.  
  14.  
  15.          Synchronizing Internet Clock frequency protocol (sic)
  16.                   draft-alavarez-hamelin-tictoc-sic-05
  17.  
  18. Abstract
  19.  
  20.    Synchronizing Internet Clock Frequency specifies a new secure method
  21.    to synchronize difference clocks on the Internet, assuring smoothness
  22.    (i.e., frequency stability) and robustness to man-in-the-middle
  23.    attacks.  In 90% of all cases, Synchronized Internet Clock Frequency
  24.    is highly accurate, with a Maximum Time Interval Error less than 25
  25.    microseconds by a minute.  Synchronized Internet Clock Frequency is
  26.    based on a regular packet exchange and works with commodity terminal
  27.    hardware.
  28.  
  29. Requirements Language
  30.  
  31.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  32.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  33.    document are to be interpreted as described in [RFC2119].
  34.  
  35. Status of This Memo
  36.  
  37.    This Internet-Draft is submitted in full conformance with the
  38.    provisions of BCP 78 and BCP 79.
  39.  
  40.    Internet-Drafts are working documents of the Internet Engineering
  41.    Task Force (IETF).  Note that other groups may also distribute
  42.    working documents as Internet-Drafts.  The list of current Internet-
  43.    Drafts is at https://datatracker.ietf.org/drafts/current/.
  44.  
  45.    Internet-Drafts are draft documents valid for a maximum of six months
  46.    and may be updated, replaced, or obsoleted by other documents at any
  47.    time.  It is inappropriate to use Internet-Drafts as reference
  48.    material or to cite them other than as "work in progress."
  49.  
  50.    This Internet-Draft will expire on November 1, 2020.
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 1]
  57. Internet-Draft               (sic frequency)                  April 2020
  58.  
  59.  
  60. Copyright Notice
  61.  
  62.    Copyright (c) 2020 IETF Trust and the persons identified as the
  63.    document authors.  All rights reserved.
  64.  
  65.    This document is subject to BCP 78 and the IETF Trust's Legal
  66.    Provisions Relating to IETF Documents
  67.    (https://trustee.ietf.org/license-info) in effect on the date of
  68.    publication of this document.  Please review these documents
  69.    carefully, as they describe your rights and restrictions with respect
  70.    to this document.  Code Components extracted from this document must
  71.    include Simplified BSD License text as described in Section 4.e of
  72.    the Trust Legal Provisions and are provided without warranty as
  73.    described in the Simplified BSD License.
  74.  
  75. Table of Contents
  76.  
  77.    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  78.    2.  sic frequency protocol overview . . . . . . . . . . . . . . .   3
  79.    3.  The formal definition of sic frequency protocol . . . . . . .   8
  80.      3.1.  Algorithm description . . . . . . . . . . . . . . . . . .   8
  81.      3.2.  Protocol definitions  . . . . . . . . . . . . . . . . . .  13
  82.      3.3.  Protocol packet specification . . . . . . . . . . . . . .  15
  83.      3.4.  Minimum sic deployment  . . . . . . . . . . . . . . . . .  16
  84.    4.  Implementation of sic frequency protocol  . . . . . . . . . .  17
  85.      4.1.  Evaluation  . . . . . . . . . . . . . . . . . . . . . . .  17
  86.    5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  19
  87.    6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
  88.    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
  89.    8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
  90.    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
  91.      9.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
  92.      9.2.  Informative References  . . . . . . . . . . . . . . . . .  21
  93.    Appendix A.  Example of RTT to NTP servers  . . . . . . . . . . .  21
  94.    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
  95.  
  96. 1.  Introduction
  97.  
  98.    There are different types of clock synchronization on the Internet.
  99.    NTP [RFC5905] remains one of the most popular because a potential
  100.    user does not need any extra hardware, and it is practically a
  101.    standard in most of the operating systems distributions.  Its working
  102.    principle relies on time servers having some kind of precise clock
  103.    source, like atomic clocks or GPS based.  For most of the needs, NTP
  104.    provides an accurate synchronization.  Moreover, NTP recently
  105.    incorporates some strategies oriented to avoid man-in-the-middle
  106.    (MitM) attacks.  NTPs potential accuracy is in the order of tens of
  107.    milliseconds.
  108.  
  109.  
  110.  
  111. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 2]
  112. Internet-Draft               (sic frequency)                  April 2020
  113.  
  114.  
  115.    Synchronizing Internet Clock frequency (sic frequency) is a protocol
  116.    providing synchronized difference clocks in two endpoints connected
  117.    to the Internet.  While synchronized absolute clocks aim on a
  118.    measurement of exact time differences between them, synchronized
  119.    difference clocks allow measurements during identical time intervals
  120.    at two locations.  This is useful if loads, packet loss or a
  121.    variation in delay is to be measured.
  122.  
  123.    The sic frequency design is close to TSClocks (see below) but it
  124.    takes advantage of statistics to perform better. sic frequency
  125.    synchronization relies on Internet based delay measurements.  Route
  126.    changes are frequent, so we include its detection.  Finally, our
  127.    implementation also contemplates the protection to MitM attacks,
  128.    including the signature of measurements in each packet. sic frequency
  129.    does neither put constrains on the quality of a server's clock, nor
  130.    does it require a limitation of the distance of synchronized end
  131.    systems.
  132.  
  133.    Another proposal is the TSClocks [ToN2008], which take advantage of
  134.    the internal computers' clock.  This work has been shown a very
  135.    interesting solution because it is not expensive and can be used in
  136.    any computer connected to the Internet.  This solution was proposed
  137.    in the beginning at LAN (Local Area Network) level, and then it has
  138.    been extended to other situations.  In [ToN2008] authors report a
  139.    difference clock error of about half of hundred of microseconds for a
  140.    WAN connection with 40ms of RTT (Round Trip Time).
  141.  
  142.    When accuracy and stability are needed, further options arise, e.g.,
  143.    the PTP clock [RFC8173] (this mechanism was also defined as the IEEE
  144.    Std. 1588-2008).  The PTP clock however incorporates specialized
  145.    hardware to provide a highly accurate clock, which is required in
  146.    each point to be synchronised.  Also the GPS (Global Position System)
  147.    requires specialized hardware in every point of measurement.  While
  148.    GPS may be less expensive than PTP, the GPS unit requires a sky clear
  149.    view for working.  The latter may be costly or impossible in some
  150.    locations.
  151.  
  152.    Finally, we mention the [ITU-G.8260] shows a methodology to measure
  153.    delays in networks.  It is based on filtering that selects some
  154.    packets to perform the delay computation.  The packet selection is
  155.    based on the minimum and average RTT, and we show that both of them
  156.    have some statistical problems to determine (see Section 2).
  157.  
  158. 2.  sic frequency protocol overview
  159.  
  160.    Synchronizing Internet Clock frequency (sic frequency) is a protocol
  161.    providing synchronized difference clocks in two endpoints connected
  162.    to the Internet.  Synchronized difference clocks allow measurements
  163.  
  164.  
  165.  
  166. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 3]
  167. Internet-Draft               (sic frequency)                  April 2020
  168.  
  169.  
  170.    during identical time intervals at two locations.  This is useful if
  171.    loads, packet loss or a variation in delay is to be measured.  The
  172.    model of typical Internet time-measurement is shown in Figure 1.
  173.  
  174.                                XXXXXXXX  XXXXXXXX
  175.                           XXXXXX      XXX       X
  176.                          XX                    XXX
  177.        +----+----------+XX                       XXXX
  178.             |          XX                           XX
  179.             |          X         Internet           XX
  180.             |          XX                         XXX
  181.          +--+------+    XXXXXX                    XX+---------+------+
  182.          |         |         X                  XX            |
  183.          |  Client |         XX                  XXX          |
  184.          |         |          XX XXX      XXXXX    XX     +---+----+
  185.          |         |           XXX  XXXXXXX   XXXXXX      |        |
  186.          +---------+                                      | Server |
  187.                                                           |        |
  188.                                                           |        |
  189.                                                           +--------+
  190.  
  191.                Figure 1: The clock synchronization of sic.--
  192.  
  193.    In this model, sic frequency performs measurements with packets in
  194.    the way shown in Figure 2.
  195.  
  196.                               t2      t3
  197.        Server +--------[email protected]*----------------------------->
  198.                              /         \_                     C_s [s]
  199.                             /            \_
  200.                            /               \_
  201.                           /                  \_
  202.                          /                     \_
  203.                         /                        \_
  204.                        /                           \_
  205.                       /                              \_
  206.                      /                                 \_
  207.                     /                                    \_
  208.                    /                                       \_ C_c [s]
  209.        Client +---*[email protected]>
  210.                   t1                                         t4
  211.  
  212.                      Figure 2: Time line of packets.--
  213.  
  214.    Here, C_s is the server clock, C_c is the client clock and t1...t4
  215.    are timestamps.
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 4]
  222. Internet-Draft               (sic frequency)                  April 2020
  223.  
  224.  
  225.    Figure 2 shows a horizontal time line for client and server.  The
  226.    diagonal lines depict a packet traversing some physical space (wires,
  227.    routers, and switches).  The packet travel times are not assumed to
  228.    be identical, because routes and background load may differ in each
  229.    direction.
  230.  
  231.    The difference between the client clock C_c and the server clock C_s
  232.    can be modeled as:
  233.  
  234.                 C_c = C_s + phi                           ,
  235.  
  236.                 phi(t) = C_c(t) - C_s(t) ,              (1)
  237.  
  238.    where phi is the absolute clock difference.  If RTT is constant (i.e.
  239.    little or no background load) and routes are symmetric in both
  240.    directions, the difference between clocks can be computed as:
  241.  
  242.                 phi[c->s] = t1 - ( t2 - RTT/2 ) ,       (2)
  243.  
  244.                 phi[c<-s] = t4 - ( t3 + RTT/2 ) ,       (3)
  245.  
  246.    and phi[c->s] = phi[c<-s].  The general equation for the RTT is:
  247.  
  248.                 RTT = ( t2 - t1 ) + ( t4 - t3 ) .       (4)
  249.  
  250.    Computing Equations 2 and 3 for the this simplified case allows
  251.    calculation of phi as a function of RTT.  Note that if routes are not
  252.    symmetrical it is impossible to determine the absolute clocks'
  253.    difference.
  254.  
  255.    The sic frequency protocol is based on statistics, background
  256.    traffic- and network behavior observations.  The RTT between two
  257.    endpoints follows a heavy-tailed distribution.  An alpha-stable
  258.    distribution shows as one possible model [traffic-stable].  This
  259.    distribution can be characterized by four parameters: the
  260.    localization "delta," the stretching "gamma," the tail "alpha," and
  261.    the symmetry "beta," [alfa-estables].  The location parameter is
  262.    highly related to the mode of the distribution: delta > 0.  The
  263.    stretching is related to the dispersion: gamma > 0.  The symmetry, -1
  264.    <= beta <= 1, indicates if the distribution is skewed to the right
  265.    (the tail decays to the left) for positive values or the opposite
  266.    direction for negatives ones.  Finally, the tail alpha, defined in
  267.    (0,2], indicates if the distribution is Gaussian one when alpha=2, a
  268.    power law without variance for alpha <2, and also without statistic
  269.    mean for alpha<1.  The alpha-stable distribution is the
  270.    generalization of the Central Limit Theorem for any distribution
  271.    (i.e., it includes the cases without variance or mean).
  272.  
  273.  
  274.  
  275.  
  276. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 5]
  277. Internet-Draft               (sic frequency)                  April 2020
  278.  
  279.  
  280.    Then, the phi(t) estimation involves the subtraction of two alpha-
  281.    stable random variables, which yields on another alfa-stable
  282.    distribution but symmetrical [alfa-estables].  Due to the
  283.    characteristic of this result, i.e., a fixed mode and symmetry, a
  284.    good estimator of the mode is the median.
  285.  
  286.    Therefore, sic performs periodic measurements to infer the difference
  287.    of two clocks in the Internet taking advantage of the empiric
  288.    observations.  The periodicity of RTT measurements is set to 1
  289.    second.
  290.  
  291.    The parameters of the simple skew model [ToN2008] are estimated by
  292.    the following equation:
  293.  
  294.                 phi(t) = K + F * t ,                    (5)
  295.  
  296.    where phi(t) = C_c - C_s, K is a constant representing the absolute
  297.    difference of time of client clock C_c and server clock C_s, and F is
  298.    the rate parameter.  As sic frequency is a difference clock, we only
  299.    estimate the frequency parameter "F."
  300.  
  301.    Note that the "K" parameter cannot be estimated using just endpoints
  302.    measurements.  Estimating the "K" parameter accurately is out of
  303.    scope, and we use K=min(RTT)/2, as it used in several synchronization
  304.    protocols under the assumption of symmetric paths.  Considering the
  305.    following asymmetry definition,
  306.  
  307.                          t[c->s]
  308.                 A = 1 - --------- ,                     (6)
  309.                          t[c<-s]
  310.  
  311.    where t[c->s] is the minimum delay measured from the client to the
  312.    server.  The maximum asymmetry A of equation 6 is A=1, which is
  313.    unlucky, and this establishes the hard bound for the error of K as
  314.    min(RTT): if t[c->s] approaches RTT, t[c->s] approaches zero.  The
  315.    difference between the two is phi (t), and this difference hence is
  316.    close to min(RTT), if A=1.  In our experiments the error in
  317.    estimation phi(t) was always less than min(RTT)/2.
  318.  
  319.    Another problem with most of the synchronization protocols is the
  320.    estimation of the minimum RTT, which depends upon the time-window
  321.    within which the RTT is captured.  A minimum RTT can only be measured
  322.    in the absence of any cross traffic.  In a first step, the minimum
  323.    RTT measured during a window of 10 minutes (mRTT10m) is captured.
  324.    Based on these values, the minimum RTT over a week (mRTTw) is
  325.    determined.  RTTee is defined as mRTT10m - mRTTw.  Figure 3 shows the
  326.    the RTT estimation error captured during an experiment where the
  327.    minimum latency between probes was 9431 microseconds during one week,
  328.  
  329.  
  330.  
  331. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 6]
  332. Internet-Draft               (sic frequency)                  April 2020
  333.  
  334.  
  335.    i.e., mRTTw=9431 microseconds.  Notice that mRTT10m varies a lot, and
  336.    the observed values can be more than 450 microseconds above the
  337.    minimum RTT over a week.  This error is a consequence of the
  338.    statistical behavior of the RTT which can be modeled by the alfa-
  339.    stable distribution.
  340.  
  341.    Finally, it is mostly believed there always exist NTP servers at less
  342.    than five hops with few milliseconds of RTT, because of the NTP
  343.    deployment.  In Appendix A we show a typical case in Latin America
  344.    region where the RTT differ notably form host in the same city
  345.    (Buenos Aires).  This example reveals that in some countries could be
  346.    not possible to have this desired situation and other synchronization
  347.    tools are needed.
  348.  
  349.     Error of the min(RTT)
  350.     [micro-seconds]
  351.       500 +------|-------|------|------|------|-------|------|------+
  352.           |      +       +      +   O  +      +       +      +      |
  353.           |                         *                               |
  354.       400 |-+                       **                     O      +-|
  355.           |                        * *             O   O   ** O  O  |
  356.           |                     O  * *             **  *   ** ** ** |
  357.       300 |-+                  * O*O * O      O*  * O*O *  * O  O *-|
  358.           |         O*   O    O       * *     * O *     * *        *|
  359.           |  O      * O  **   *       * O    *  * *     O**        O|
  360.       200 |-* *     * * * O   *       O  * O*O   *        O       +-|
  361.           |** O  O *   ** *   *          * *     O                  |
  362.           |O   * ***   O   *  *           *                         |
  363.       100 |-+   O  O       O *            O                       +-|
  364.           |                 **                                      |
  365.           |                 **                                      |
  366.         0 |-+    +       +   O  +      +      +       +      +    +-|
  367.           +------|-------|------|------|------|-------|------|------+
  368.           0     50      100    150    200    250     300    350    400
  369.                                                         time [minutes]
  370.  
  371.    Figure 3: Min RTT error, estimated every 10 minutes along 7 hours.--
  372.  
  373.    The sic frequency protocol estimates phi(t) of Equation 5 using
  374.    measurement statistics and taking advantage of the inherent RTT
  375.    properties, i.e., the heavy tail distribution and its alfa-stable
  376.    distribution model.  The basic sic frequency operation is to
  377.    periodically send packets, estimate phi(t), and correct the local
  378.    clock with:
  379.  
  380.                   t_c = t + phi(t) ,                  (7)
  381.  
  382.  
  383.  
  384.  
  385.  
  386. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 7]
  387. Internet-Draft               (sic frequency)                  April 2020
  388.  
  389.  
  390.    where t_c is the corrected time and t the local clock time (notice
  391.    that phi(t) is calculated according to Equation 1).
  392.  
  393.    The sic protocol also detects route changes by seeking a non-
  394.    negligible difference between the minimum RTT of the actual and past
  395.    round trip measurement.  The next section also discusses different
  396.    mechanisms to detect route changes by RTT evaluation.
  397.  
  398. 3.  The formal definition of sic frequency protocol
  399.  
  400.    Section 3.1 presents the sic frequency algorithm.  In addition,
  401.    parameters and their definitions are introduced.  Finally, formal
  402.    packet formats are provided.
  403.  
  404.    The sic frequency protocol MUST sign the packets with the
  405.    deterministic Elliptic Curve Digital Signature Algorithm (ECDSA)
  406.    specified by [RFC6979] to protect sic frequency from MitM attacks.
  407.    To avoid delays when a packet is signed, sic frequency signs them in
  408.    a deferred fashion.  That is, in each packet carries the signature of
  409.    the previous packet (see algorithms in Figure 6 and Figure 5 ).
  410.  
  411. 3.1.  Algorithm description
  412.  
  413.    sic frequency implementations MUST support the formal description
  414.    specified by this section.  Once activated, the sic frequency
  415.    protocol MUST operate permanently while a client and a receiver
  416.    exchange measurement packets. sic frequency works with three states:
  417.    NOSYNC, PRESYNC, and SYNC.  These states are triggered by the
  418.    variables errsync, presync, and synck.
  419.  
  420.    Lines 1 to 4 of the pseudocode in Figure 4 initialize the required
  421.    data structures needed and set the sic frequency state to NOSYNC.  In
  422.    NOSYNC state, a complete measurement window estimates phi's by
  423.    Equation 2 (see line 8).  Notice that also Equation 3 can be used, or
  424.    an average of both Equations.  During the experiments, using a single
  425.    equation only resulted in estimations with a smaller error.  The
  426.    possible explanation is that measurements are affected by the same
  427.    type of traffic.
  428.  
  429.    The median of the measurement window is also computed in line 9,
  430.    while lines 10-12 are used to verify if there is a path change in the
  431.    measurements.  When an appreciable difference is detected (bounded by
  432.    errRTT) in line 13, the "else" clause is executed and the systems re-
  433.    initiates the cycle (see lines 17-22).  Notice that line 13 verifies
  434.    if the absolute value of the minimum RTTs is lower than a percentage
  435.    of minimum over the complete RTT window.
  436.  
  437.  
  438.  
  439.  
  440.  
  441. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 8]
  442. Internet-Draft               (sic frequency)                  April 2020
  443.  
  444.  
  445.    The sic frequency algorithm specification is presented by three
  446.    tables of pseudocode.  The parameters are explained after the third
  447.    table.
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496. Alvarez-Hamelin, et al. Expires November 1, 2020                [Page 9]
  497. Internet-Draft               (sic frequency)                  April 2020
  498.  
  499.  
  500.  =======================================================================
  501.  |                     sic frequency algorithm                         |
  502.  =======================================================================
  503.  1  Wmedian <-0, Wm <-0, WRTT <-0, actual_m <-0, actual_c <-0
  504.  2  presync <- INT_MAX - P, epochsync <- INT_MAX - P, n_to <-0
  505.  3  synck <- false, errsync <- epoch, set(0, 0, NOSYNC), e_prev<-epoch
  506.  4  send_sic_packet(SERVER_IP, TIMEOUT)
  507.  5  for each timer(RUNNING_TIME) == 0
  508.  6   |   (epoch, t1, t2, t3, t4, to) <- send_sic_p(SERVER_IP,TIMEOUT)
  509.  7   |   if (to == false) then
  510.  8   |    |   Wm <- t1 - t2 + (t2 - t1 + t4 - t3)/2
  511.  9   |    |   Wmedian <- median(Wm)
  512.  10  |    |   WRTT <- t4 - t1 size(W)
  513.  11  |    |   RTTf <- min(WRTT[size(WRTT)/2,size(WRTT)])
  514.  12  |    |   RTTl <- min(WRTT[0,size(WRTT)/2])
  515.  13  |    |   if ((|RTTf - RTTl| <= errRTT * min(WRTT)) then
  516.  14  |    |    |   if (epoch >= presynck + P))  then
  517.  15  |    |    |    |   presynck <- true
  518.  16  |    |    |   end if
  519.  17  |    |    else
  520.  18  |    |    |   synck <- false, Wmedian <- 0
  521.  19  |    |    |   Wm <- 0, errsync <- epoch, n_to <- 0
  522.  20  |    |    |   epoch_sync <- INT_MAX - P, pre_sync <- INT_MAX - P
  523.  21  |    |    |   set(0, 0, NOSYNC)
  524.  22  |    |   end if
  525.  23  |    |   if ((synck == true) && (epoch >= epochsync + P)) then
  526.  24  |    |    |   (m, c) <- linear_fit(Wmedian)
  527.  25  |    |    |   actual_c <- c
  528.  26  |    |    |   actual_m <- (1-alpha) * m + alpha * actual_m
  529.  27  |    |    |   epochsync <- epoch,  n_to <- 0
  530.  28  |    |    |   set(actual_m, actual_c, SYNC)
  531.  29  |    |    else
  532.  30  |    |    |   if (epoch == errsync + MEDIAN_MAX_SIZE) then
  533.  31  |    |    |    |   presync <- epoch
  534.  32  |    |    |   end if
  535.  33  |    |    |   if (epoch >= presync + P) then
  536.  34  |    |    |    |   (actual_m, actual_c) <- linear_fit(Wmedian)
  537.  35  |    |    |    |   synck <- true , epoch_sync <- epoch
  538.  36  |    |    |    |   set(actual_m, actual_c, PRESYNC)
  539.  37  |    |    |   end if
  540.  38  |    |    end if
  541.  39  |    else
  542.  40  |    |   to <- false
  543.  41  |   end if
  544.  42 end for
  545.  =======================================================================
  546.  
  547.                   Figure 4: Formal description of sic.--
  548.  
  549.  
  550.  
  551. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 10]
  552. Internet-Draft               (sic frequency)                  April 2020
  553.  
  554.  
  555.    Several conditions should be verified to pass from NOSYNC to PRESYNC.
  556.    First, the "else" condition of line 29 should occur, and also the
  557.    elapsed time between errsync and actual epoch should be
  558.    MEDIAN_MAX_SIZE (30-32).  Therefore, when it also P time is passed
  559.    form presync, the condition on line 33 is true, and the system
  560.    arrives at PRESYNC, providing an initial estimation of phi.
  561.  
  562.    Then, if there is no route change, the condition in line 14 will be
  563.    true when the time was increased in another P period.  Then, the
  564.    system is in SYNC state, and it provides the estimation of phi(t) in
  565.    line 28.  Notice that every P time the estimation of phi(t) is
  566.    computed unless a route change occurs (lines 13 and 17-22).
  567.  
  568.    The function in line 6: (epoch, t1, t2, t3, t4, to) <-
  569.    send_sic_packet(SERVER_IP, TIMEOUT), has a special treatment.  It
  570.    sends the packets specified in (Section 3.3), which have signatures.
  571.    To avoid the processing delay caused by the signature computation, we
  572.    implemented a policy to send the signature of the previous packet,
  573.    and if an error is detected, we can stop the synchronization just one
  574.    loop ahead.
  575.  
  576.    Figure 5 illustrates how the client side MUST implement the function
  577.    send_sic_p (SERVER_IP, TIMEOUT).  This function computes the
  578.    timestamp t1 in line 1, build and send the UDP packet in lines 2-3.
  579.    Then, if there is no timeout, it calculates the t4 timestamp (line
  580.    5), and if no packets were lost, verifies the signature of the
  581.    previous one in lines 8-18.  If the signature is not valid with the
  582.    received certificate, then the system MUST change to NOSYNC state
  583.    immediately (see line 11).  NOSYNC state MUST also be set, if the
  584.    limit of time without receiving packets MAX_to is reached.  Finally,
  585.    it stores the received packet into prev_rcv_pck (a global variable)
  586.    to use in the next packet (line 19).  Notice that n_to, the lost
  587.    packets, is a global variable, as well as the epoch of the previous
  588.    packet: e_prev.
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 11]
  607. Internet-Draft               (sic frequency)                  April 2020
  608.  
  609.  
  610.  =======================================================================
  611.  |                function: send_sic_p(server, TIMEOUT)                |
  612.  =======================================================================
  613.  1  t1 <- get_timestamp()
  614.  2  sic_P <- sic_pck(t1, 0, 0, prev_sig)
  615.  3  (to, rcv_sic_pck) <- send(sic_P,UDP_PORT, SERVER_IP, TIMEOUT)
  616.  4  if (to == false) then
  617.  5   |  t4 <- get_timestamp()
  618.  6   |  epoch <- trunc_to_seconds(t1)
  619.  7   |  prev_sig <- get_signature(sic_P)
  620.  8   |  if (epoch - e_prev <= RUNNING_TIME) then
  621.  9   |   |  if (n_to < MAX_to) then
  622.  10  |   |   |  if (verify(prev_rcv_pck,rcv_sic.CERT) == false) then
  623.  11  |   |   |   |  set(0, 0, NOSYNC)
  624.  12  |   |   |  else
  625.  13  |   |   |   |  n_to <- 0,  e_prev <- epoch
  626.  14  |   |   |  end if
  627.  15  |   |  else
  628.  16  |   |   |   set(0, 0, NOSYNC)
  629.  17  |   |  end if
  630.  18  |  end if
  631.  19  |  prev_rcv_pck <- rcv_sic_pck
  632.  20  |  t2 <- rcv_sic_pck.t2
  633.  21  |  t3 <- rcv_sic_pck.t3
  634.  22 else
  635.  23  |  n_to <- n_to + 1
  636.  24 end if
  637.  25 return (epoch, t1, t2, t3, t4, to)
  638.  =======================================================================
  639.  
  640.                    Figure 5: The send_sic_p function.--
  641.  
  642.    The server sic algorithm is presented in Figure 6.  It uses
  643.    prev_sic_P{}, which is a structure to store the received previous
  644.    signatures, indexed by the IP client addresses (CLIENT_add contains
  645.    its IP and UDP port); and the same for prev_sig{} with the previously
  646.    sent signatures.  Line 6 verifies either signature is null because it
  647.    is the first packet, or it is a valid signature.  In both cases, the
  648.    algorithm process the packet computing t3, building up the sic
  649.    frequency packet, sending it and computing its signature (stored to
  650.    send in the next reply) in lines 7-11.  Next, the actual packet is
  651.    stored in the prev_sic_P{} structure, line 13.
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 12]
  662. Internet-Draft               (sic frequency)                  April 2020
  663.  
  664.  
  665.  =======================================================================
  666.  |                        sic Server algorithm                         |
  667.  =======================================================================
  668.  1  prev_sic_P{} <- null, prev_sig{} <-- null
  669.  2  while (RUNNING == true) then
  670.  3   |   if (receive() == true) then
  671.  4   |    |  t2 <- get_timestamp()
  672.  5   |    |  prev_sig <- get_signature(prev_sic_P{receive().CLIENT_add})
  673.  6   |    |  if (prev_sig == null)  ||
  674.      |    |           (verify(prev_sig, CLIENT_add.CERT) == true)  then
  675.  7   [    |   |  t3 <- get_timestamp()
  676.  8   |    |   |  sic_P<-sic_pack(t1, t2, t3, prev_sig)
  677.  9   |    |   |  send(sic_P, CLIENT_add.UDP, CLIENT_add.IP, TIMEOUT)
  678.  10  |    |   |  prev_sig <- get_signature(sic_P)
  679.  11  |    |   |  prev_sig{receive().CLIENT_add} <- prev_sig
  680.  12  |    |  end if
  681.  13  |    |  prev_sic_P{receive().CLIENT_add} <- receive().sic_pack
  682.  14  |   end if
  683.  15  end while
  684.  =======================================================================
  685.  
  686.  
  687.                  Figure 6: Algorithm sic for the Server.--
  688.  
  689. 3.2.  Protocol definitions
  690.  
  691.    We provide a formal definition of each used constant and variables;
  692.    the RECOMMENDED values are displayed in parentheses at the end of the
  693.    description.  These constant and variables MUST be represented in a
  694.    sic frequency implementation.  All the types MUST be respected.  They
  695.    are expressed in "C" programming language running on a 64-bit
  696.    processor.
  697.  
  698.    a.  Constants used for the sic frequency algorithm (Figure 4)
  699.  
  700.        1.   RUNNING_TIME: is the period between sic packets are sent (1
  701.             second).
  702.  
  703.        2.   MEDIAN_MAX_SIZE: is the window size used to compute the
  704.             median of the measurements (600).
  705.  
  706.        3.   P: is the period between phi's estimation (60).
  707.  
  708.        4.   alpha: is a float in the [0,1], the coefficient of the
  709.             autoregressive estimation of the slope of phi(t) (0.05).
  710.  
  711.        5.   TIMEOUT: is the maximum time in seconds that a sic packet
  712.             reply is expected (0.8 seconds).
  713.  
  714.  
  715.  
  716. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 13]
  717. Internet-Draft               (sic frequency)                  April 2020
  718.  
  719.  
  720.        6.   SERVER_IP: is the IP address of the server (@IP in version 4
  721.             or 6).
  722.  
  723.        7.   errRTT: is a float that bounds the maximum difference to
  724.             detect a route change (0.2).
  725.  
  726.        8.   MAX_to: is an integer representing the maximum number of
  727.             packet lost (P/10).
  728.  
  729.        9.   CERT: is a public certificate of the other end, it is used
  730.             to verify signs of the packets.
  731.  
  732.        10.  UDP_PORT: is an integer with the port UDP where the service
  733.             is running on the server. (4444)
  734.  
  735.        11.  SERVER_IP: is the IP address of the server.
  736.  
  737.        12.  CLIENT_IP: is the IP address of the client.
  738.  
  739.    b.  States used for the sic frequency algorithm (Figure 4)
  740.  
  741.        1.  NOSYNC: a boolean indicates that it is not possible to
  742.            correct the local time.
  743.  
  744.        2.  PRESYNC: an integer indicates that sic is almost (P
  745.            RUNNING_TIME) seconds from the synchronization.
  746.  
  747.        3.  SYNC: a boolean indicates that sic is synchronized.
  748.  
  749.    c.  Variables used for the sic frequency algorithms (Figure 4,
  750.        Figure 5 and Figure 6)
  751.  
  752.        1.   errsync: is an integer with the UNIX timestamp epoch of the
  753.             initial NOSYNC cycle.  It is used to complete the window or
  754.             measurements (Wm) to compute their medians.
  755.  
  756.        2.   presync: is an integer with the UNIX timestamp epoch of the
  757.             initial PRESYNC cycle.  It is used to wait until (P
  758.             RUNNING_TIME) seconds to the linear fit of phi(t).
  759.  
  760.        3.   synck: is an integer with the UNIX timestamp epoch of the
  761.             initial SYNC cycle.  Every P RUNNING_TIME) seconds the
  762.             phi(t) function is estimated.
  763.  
  764.        4.   epochsync: is an integer with the last UNIX timestamp epoch
  765.             of synchronization.  It is used to compute a new estimation
  766.             of phi(t), every (P RUNNING_TIME) seconds.
  767.  
  768.  
  769.  
  770.  
  771. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 14]
  772. Internet-Draft               (sic frequency)                  April 2020
  773.  
  774.  
  775.        5.   epoch: is an integer with UNIX timestamp in seconds.  It
  776.             carries the initial epoch of each sic measurement packet.
  777.  
  778.        6.   t1, t2, t3, t4: are long long integers to store the t UNIX
  779.             timestamps in microseconds.
  780.  
  781.        7.   actual_m : is a double with the slope for the phi(t)
  782.             estimation.
  783.  
  784.        8.   actual_c: is a double with the intercept for the phi(t)
  785.             estimation.
  786.  
  787.        9.   Wm: is an array of doubles of MEDIAN_MAX_SIZE.  It stores
  788.             the instantaneous estimates of phi(t).
  789.  
  790.        10.  Wmedian: is an array of doubles of P size.  It saves the
  791.             computed medians of Wm every RUNNING_TIME.
  792.  
  793.        11.  WRTT: is an array of doubles of (2 P) size.  It stores the
  794.             calculated RTT of last measurements.
  795.  
  796.        12.  RTTl: is a double with the minimum of last P RTTs.  It is
  797.             used to detect changes on the route from the client to the
  798.             server.
  799.  
  800.        13.  RTTf: is a double with the minimum of previous P RTTs.  It
  801.             is used to detect changes on the route from the client to
  802.             the server.
  803.  
  804.        14.  n_to: is an integer representing the number of lost packets
  805.             in the actual synchronization window P.
  806.  
  807.        15.  e_prev: is an integer with the UNIX timestamp epoch of the
  808.             last valid packet.
  809.  
  810.        16.  prev_rcv_pck: is a sic packet structure, the previous
  811.             received one.
  812.  
  813. 3.3.  Protocol packet specification
  814.  
  815.    The sic frequency uses UNIX microsecond format timestamps.  Regarding
  816.    Figure 2, the client takes a timestamp t1 just before it sends the
  817.    packet.  When the server receives the packet, it immediately computes
  818.    t2, and just before it is sent back to the client, it computes t3.
  819.    When the client receives the packet, it calculates t4.
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 15]
  827. Internet-Draft               (sic frequency)                  April 2020
  828.  
  829.  
  830.    The server does not need the timestamp t1 because the proposed
  831.    protocol synchronizes a client with the server clock.  This
  832.    information could however be useful for the server for future use.
  833.  
  834.    The packets respects the NTP4 fortmat as they are defined in the
  835.    Section A.1.2 of [RFC5905] and the signature of the fields, shown in
  836.    Figure 7.  We use the time formats of 64 bits with seconds and
  837.    fraction of seconds.  They MUST be sent as UDP data, and it MUST have
  838.    the mentioned fields.
  839.  
  840.    The client and server certificates SHOULD be valid and signed ones
  841.    (only for experimentation user MAY use autogenerated ones).
  842.  
  843.        +-----------------------------------------------------------+
  844.        |  NTP_packet (t1_c,t2_s,t3_s)  |  Sig_r n-1  |  Sig_s n-1  |
  845.        +-----------------------------------------------------------+
  846.                              Client --> Server
  847.  
  848.        +-----------------------------------------------------------+
  849.        |  NTP_packet (t1_c,t2_s,t3_s)  |  Sig_r n-1  |  Sig_s n-1  |
  850.        +-----------------------------------------------------------+
  851.                              Server --> Client
  852.  
  853.               Figure 7: Packet format for the sic protocol.--
  854.  
  855. 3.4.  Minimum sic deployment
  856.  
  857.    To deploy the sic frequency algorithm, as a minimum a Server and one
  858.    Client are needed.  The Server can support multiple clients.  The
  859.    maximum number of clients is for further study.  The Server clock is
  860.    considered the master one, and all clients synchronize with it.  The
  861.    Server side runs sic frequency as a server with a UDP_PORT number, as
  862.    specified by the algorithm shown in Figure 6.
  863.  
  864.    Client sic runs the algorithm shown in Figure 4 and also SHOULD
  865.    provide the corrected time as
  866.  
  867.    t = actual_c + actual_m * timestamp     (8)
  868.  
  869.                                  Figure 8
  870.  
  871.    Different ways of doing this task are possible:
  872.  
  873.       Providing a client capable of reading the variables actual_m and
  874.       actual_c in shared memory and producing the result of Equation 8.
  875.  
  876.       Providing a service in a UDP port answering the correct timestamp
  877.       queries with Equation 8.
  878.  
  879.  
  880.  
  881. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 16]
  882. Internet-Draft               (sic frequency)                  April 2020
  883.  
  884.  
  885.       Other solution.
  886.  
  887. 4.  Implementation of sic frequency protocol
  888.  
  889.    In this section we present the prove of the sic concept through some
  890.    test that we already performed, and the current implementation of sic
  891.    in C language.  Our implementation is publicly available
  892.    [sic-implementation].
  893.  
  894.    This protocol implements protection against MitM attacks.  The
  895.    identity of endpoints is guarantee by signed certificates using the
  896.    deterministic Elliptic Curve Digital Signature Algorithm (ECDSA)
  897.    specified in the [RFC6979].  Server and Client should use signed and
  898.    valid ECDSA certificates to ensure their identity, and each side has
  899.    is responsible to verify the public certificate of the other side
  900.    before to run the algorithm in Figure 4.
  901.  
  902. 4.1.  Evaluation
  903.  
  904.    To verify the sic proposal, we tested it using three hosts with GPS
  905.    units.  The first two were located at Buenos Aires, and the third at
  906.    Los Angeles.  We slightly modified the algorithm in Figure 4 to
  907.    trigger each measurement using the PPS (pulse per second) signal
  908.    provided by the GPS unit.  Then, recording the client and server
  909.    clocks with the PPS signal, we can determine the real phi function of
  910.    Equation 1, within the GPS error (it is several orders of magnitude
  911.    smaller than the error of the sic frequency protocol).
  912.  
  913.    We use MTIE defined as follows (Maximum Time Interval Error, see
  914.    [ToIM1996]):
  915.  
  916.                 MTIE = max [phi(t')] - min [phi (t)] ,  (9)
  917.  
  918.    for every t' and t in the interval [t,t+s]; and we chose s=60
  919.    seconds.  We first used two host (RaspBerriesPI-2) connected back to
  920.    back to analyze the minimum achievable precision, yielding a MTIE of
  921.    15.8 microseconds for the 90 percentile.  Then, we selected two real
  922.    cases of study, one national and other international.  In Figure 9 we
  923.    show the result of the MTIE, evaluated in 60 seconds intervals, for
  924.    the experiment Buenos Aires-Buenos Aires (RTT of 10ms) and Buenos
  925.    Aires-Los Angeles (RTT of 198ms).  The percentile 90 corresponds to
  926.    18.35 microseconds for the Buenos Aires case, and 25.4 microseconds
  927.    for the Los Angeles case.  The percentile 97.5 corresponds to 30
  928.    microseconds for the Buenos Aires case, and 42 microseconds for the
  929.    Los Angeles case.  We display the quartiles in Figure 10.  These
  930.    measurements were performed during a week in each case.
  931.  
  932.  
  933.  
  934.  
  935.  
  936. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 17]
  937. Internet-Draft               (sic frequency)                  April 2020
  938.  
  939.  
  940.      CDF
  941.          +--|-------|-------|-----|-------|----------|------|------+
  942.        1 |-+        +       +     + #########*#*#*#*#*#*#*#*#******|
  943.          |                      ##### *******                      |
  944.          |                   ####  ****                            |
  945.      0.8 |-+                ##   ***                             +-|
  946.          |                ###   **                                 |
  947.          |               ##   ***                                  |
  948.      0.6 |-+            ##   **                                  +-|
  949.          |             ##   **                                     |
  950.          |            ##   **                                      |
  951.      0.4 |-+        ##    **                                     +-|
  952.          |         ##    **                                        |
  953.          |        ##    **                                         |
  954.      0.2 |-+     ##   ***                                        +-|
  955.          |    ####  ***                  Buenos Aires  #######     |
  956.          | ####   ***                    Los Angeles   *******     |
  957.        0 |##******* +       +     +       +     +    +      +    +-|
  958.          +--|-------|-------|-----|-------|-----|----|------|------+
  959.             7       10      15    20      30    40   50     70    100
  960.                                                       [micro-seconds]
  961.  
  962.       Figure 9: Cumulative distribution function of the MTIE (60s).--
  963.  
  964.          |Buenos Aires (10ms) | Los Angeles (198ms) |local NTP4 (12ms)
  965.      ====+====================+=====================+=================
  966.       Q3 |      14.69         |        19.29        |      9059
  967.      ----+--------------------+---------------------+-----------------
  968.       Q2 |      11.60         |        14.93        |      5245
  969.      ----+--------------------+---------------------+-----------------
  970.       Q1 |       9.41         |        12.26        |      3338
  971.  
  972.    Figure 10: Table with MTIE quartiles for two RTT sic cases, and for a
  973.          local NTP4 system (the numbers indicate microseconds).--
  974.  
  975.    We also conducted another test for NTP4 in Buenos Aires, Argentina.
  976.    We used a host with GPS, whose PPS signal triggered a process to log
  977.    actual timestamps.  This host was also running NTP4 with the server
  978.    time.afip.gov.ar, also located at Buenos Aires city, with an average
  979.    RTT of 12ms.  Applying the same process of the previous cases, we
  980.    obtained that the following quartiles Q3: 9.1ms, Q2: 5.2ms, and Q1:
  981.    3.3ms for the MTIE of the NTP4 measurements (also reported in
  982.    Figure 10).  Finally, the percentile 90 of the NTP4's MTIE is 11.1ms.
  983.  
  984.    The comparison of NTP4 with frequency sic shows that this new method
  985.    performs two orders of magnitude better.
  986.  
  987.  
  988.  
  989.  
  990.  
  991. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 18]
  992. Internet-Draft               (sic frequency)                  April 2020
  993.  
  994.  
  995. 5.  Conclusions
  996.  
  997.    This document presents the sic algorithm to synchronize host clock
  998.    frequency using the Internet and resistant to MitM attacks.  It also
  999.    shows the complete specification, implementation, and experiments
  1000.    results that support it working principle.  In particular, sic
  1001.    frequency provides a clock rate stability of less than 1ppm for most
  1002.    of the time.
  1003.  
  1004. 6.  Security Considerations
  1005.  
  1006.    Following [RFC7384] enumeration of Time Protocols in packet-switched
  1007.    networks, the proposed encryption of timing packets, based on a
  1008.    mechanism of secure key distribution, provides the following
  1009.    characteristics:
  1010.  
  1011.       3.2.1 Packet Manipulation: Prevented by packet signature.
  1012.  
  1013.       3.2.2 Spoofing: Prevented by packet signature and secure key
  1014.       distribution.
  1015.  
  1016.       3.2.3 Replay Attack: Prevented by chain signing of packets.
  1017.  
  1018.       3.2.4 Rogue Master Attack: Prevented by secure key distribution.
  1019.  
  1020.       3.2.5 Packet Interception and Removal: If several packets are
  1021.       removal, the protocol do not arrive to SYNC state.
  1022.  
  1023.       3.2.6 Packet Delay Manipulation: Not prevented.  Future versions
  1024.       may prevent this using over-specification of timing (using
  1025.       redundant masters)
  1026.  
  1027.       3.2.7 L2/L3 DoS attacks: Not prevented.  This can be prevented in
  1028.       future versions using over-specification of timing and redundant
  1029.       masters time servers.
  1030.  
  1031.       3.2.8 Cryptographic performance attacks: Not an issue in ECDSA.
  1032.  
  1033.       3.2.9 DoS attacks agains the time protocol: Prevented by secure
  1034.       key distribution.
  1035.  
  1036.       3.2.10 Grandmaster Time source attack (GPS attacks): Not
  1037.       prevented.  Future versions may prevent this using over-
  1038.       specification of timing (using several time servers) .
  1039.  
  1040.       3.2.11 Exploiting vulnerabilities in the time protocol: Not
  1041.       prevented, future vulnerabilities are unknown.
  1042.  
  1043.  
  1044.  
  1045.  
  1046. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 19]
  1047. Internet-Draft               (sic frequency)                  April 2020
  1048.  
  1049.  
  1050.       3.2.12 Network Reconnaissance: Not prevented in this version.  No
  1051.       countermeasures were done in node anonymization.
  1052.  
  1053.    The Packet Delay manipulation is one of the hardest problems to solve
  1054.    because there exist some smart ways to attack any synchronization
  1055.    protocol.  Even thou, the sic frequency protocol can protect itself
  1056.    because can identify several attacks of this type, i.e., it is
  1057.    challenging to mimic traffic behavior.  But, this emulation of
  1058.    behavior can be easy overcomed regarding the distribution of the
  1059.    RTTs, which have to be a heavy tailed one.  This way the analysis
  1060.    should be studied to assure the implementation of robust and light
  1061.    test of the raw data.
  1062.  
  1063. 7.  IANA Considerations
  1064.  
  1065.    This memo makes no requests of IANA.
  1066.  
  1067. 8.  Acknowledgements
  1068.  
  1069.    The authors thank to Ethan Katz-Bassett, Zahaib Akhtar, the USC and
  1070.    CAIDA for lodging the testbed of sic frequency.
  1071.  
  1072. 9.  References
  1073.  
  1074. 9.1.  Normative References
  1075.  
  1076.    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  1077.               Requirement Levels", BCP 14, RFC 2119,
  1078.               DOI 10.17487/RFC2119, March 1997,
  1079.               <https://www.rfc-editor.org/info/rfc2119>.
  1080.  
  1081.    [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
  1082.               "Network Time Protocol Version 4: Protocol and Algorithms
  1083.               Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
  1084.               <https://www.rfc-editor.org/info/rfc5905>.
  1085.  
  1086.    [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
  1087.               Algorithm (DSA) and Elliptic Curve Digital Signature
  1088.               Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
  1089.               2013, <https://www.rfc-editor.org/info/rfc6979>.
  1090.  
  1091.    [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
  1092.               Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
  1093.               October 2014, <https://www.rfc-editor.org/info/rfc7384>.
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 20]
  1102. Internet-Draft               (sic frequency)                  April 2020
  1103.  
  1104.  
  1105.    [RFC8173]  Shankarkumar, V., Montini, L., Frost, T., and G. Dowd,
  1106.               "Precision Time Protocol Version 2 (PTPv2) Management
  1107.               Information Base", RFC 8173, DOI 10.17487/RFC8173, June
  1108.               2017, <https://www.rfc-editor.org/info/rfc8173>.
  1109.  
  1110. 9.2.  Informative References
  1111.  
  1112.    [alfa-estables]
  1113.               Uchaikin, V. and V. Zolotarev, "Chance and stability:
  1114.               stable distributions and their applications.",  Walter de
  1115.               Gruyter. (Book), 1999.
  1116.  
  1117.    [ITU-G.8260]
  1118.               ITU, T. S. S. O., "Definitions and terminology for
  1119.               synchronization in packet networks (Recommendation ITU-T
  1120.               G.8260)", August 2015.
  1121.  
  1122.    [sic-implementation]
  1123.               Samariego, E., Ortega, A., and J. Alvarez-Hamelin,
  1124.               "Synchronizing Internet
  1125.               Clocks",  https://github.com/CoNexDat/SIC, February 2018.
  1126.  
  1127.    [ToIM1996]
  1128.               Bregni, S., "Measurement of maximum time interval error
  1129.               for telecommunications clock stability
  1130.               characterization",  Bregni S. Measurement of maximum time
  1131.               interval error for telecommunicIEEE transactions on
  1132.               instrumentation and measurement. 45(5):900-906, October
  1133.               1996.
  1134.  
  1135.    [ToN2008]  Veitch, D., Ridoux, J., and S. Korada, "Robust
  1136.               synchronization of absolute and difference clocks over
  1137.               networks.",  IEEE.ACM Transactions on Networking (TON)
  1138.               17.2 (2009): 417-430, 2009.
  1139.  
  1140.    [traffic-stable]
  1141.               Carisimo, E., Grynberg, S., and J. Alvarez-Hamelin,
  1142.               "Influence of traffic in stochastic behavior of
  1143.               latency.",  7th PhD School on Traffic Monitoring and
  1144.               Analysis (TMA), Ireland, Dublin,, June 2017.
  1145.  
  1146. Appendix A.  Example of RTT to NTP servers
  1147.  
  1148.    This appendix shows an experiment to measure the RTT and the distance
  1149.    in hops from four different points to a time server in Buenos Aires
  1150.    city (the capital of Argentina).  We did the measures two times from
  1151.    the four points, and we used one hundred packets to determine some
  1152.    statistical parameters.  Next traceroute measurements show that the
  1153.  
  1154.  
  1155.  
  1156. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 21]
  1157. Internet-Draft               (sic frequency)                  April 2020
  1158.  
  1159.  
  1160.    number of hops and RTT are very different from each point also
  1161.    changes a lot.  For instance, taking a distinctive look at the STD,
  1162.    average, and maximum is possible to detect huge variations.  We
  1163.    provide here a case in Argentina, trying to reach an NTP server from
  1164.    4 different points at the Buenos Aires city.
  1165.  
  1166. -------------------------------------------------------------------------
  1167.  
  1168. host1$ mtr -r -c 100 time.afip.gov.ar
  1169. Start: Tue Mar 27 19:03:51 2018
  1170. HOST: raspbian-server             Loss%  Snt  Last  Avg  Best  Wrst StDev
  1171.   1.|-- gw-vlan-srv.innova-red.ne  0.0%  100   2.2  2.8   2.1  37.7   4.9
  1172.   2.|-- rnoc5.BUENOS-AIRES.innova  0.0%  100   2.3  3.8   2.1  55.8   7.9
  1173.   3.|-- 10.5.10.2                  0.0%  100   2.5  2.6   2.2   3.1   0.0
  1174.   4.|-- 200.0.17.104               0.0%  100   3.1  3.1   2.4  13.7   1.1
  1175.   5.|-- 172.18.2.53                0.0%  100   4.8  5.7   3.8  12.4   1.7
  1176.   6.|-- time.afip.gob.ar           0.0%  100   5.2  5.2   3.8  12.0   1.3
  1177.  
  1178. host1$ mtr -r -c 100 time.afip.gov.ar
  1179. Start: Tue Mar 27 18:57:06 2018
  1180. HOST: raspbian-server             Loss%  Snt  Last  Avg  Best  Wrst StDev
  1181.   1.|-- gw-vlan-srv.innova-red.ne  0.0%   50   2.4  2.8   2.0  34.2   4.5
  1182.   2.|-- rnoc5.BUENOS-AIRES.innova  0.0%   50   2.1  3.8   2.1  52.8   7.7
  1183.   3.|-- 10.5.10.2                  0.0%   50   2.7  2.9   2.2  15.6   1.8
  1184.   4.|-- 200.0.17.104               0.0%   50   2.8  3.0   2.3   3.9   0.0
  1185.   5.|-- 172.18.2.53                0.0%   50   4.5  5.8   3.8  17.8   2.2
  1186.   6.|-- time.afip.gob.ar           0.0%   50   4.7  9.9   4.2 238.5  33.0
  1187.  
  1188. -------------------------------------------------------------------------
  1189.  
  1190. host2$ mtr -r -c 100 time.afip.gov.ar
  1191. Start: Tue Mar 27 19:03:47 2018
  1192. HOST: ws-david                    Loss%  Snt  Last  Avg  Best  Wrst StDev
  1193.   1.|-- 10.10.96.1                 0.0%  100   0.3  0.2   0.2   0.3   0.0
  1194.   2.|-- 200.16.116.171             0.0%  100   1.0  5.9   0.6 158.4  22.9
  1195.   3.|-- static.33.229.104.190.cps  1.0%  100   1.6  2.5   1.5  80.6   8.0
  1196.   4.|-- static.129.192.104.190.cp  0.0%  100   2.1  1.9   1.8   3.0   0.1
  1197.   5.|-- 200.0.17.104               1.0%  100   2.0  2.2   1.8   9.4   0.7
  1198.   6.|-- 172.18.2.53                0.0%  100   3.2  4.2   3.1  12.0   1.5
  1199.   7.|-- auth.afip.gob.ar           0.0%  100   4.2  4.5   3.3   9.8   1.2
  1200.  
  1201. host2$ mtr -r -c 100 time.afip.gov.ar
  1202. Start: Tue Mar 27 18:57:00 2018
  1203. HOST: ws-david                    Loss%  Snt  Last  Avg  Best  Wrst StDev
  1204.   1.|-- 10.10.96.1                 0.0%   50   0.3  0.3   0.2   0.7   0.0
  1205.   2.|-- 200.16.116.171             0.0%   50   0.9  6.7   0.7 196.5  29.1
  1206.   3.|-- static.33.229.104.190.cps  2.0%   50   1.6  1.7   1.5   2.2   0.0
  1207.   4.|-- static.129.192.104.190.cp  0.0%   50   2.1  2.0   1.7   2.4   0.0
  1208.  
  1209.  
  1210.  
  1211. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 22]
  1212. Internet-Draft               (sic frequency)                  April 2020
  1213.  
  1214.  
  1215.   5.|-- 200.0.17.104               0.0%   50   2.0  2.1   1.8   2.6   0.0
  1216.   6.|-- 172.18.2.53                0.0%   50   4.8  4.3   3.2   9.1   1.3
  1217.   7.|-- time.afip.gob.ar           0.0%   50   4.3  9.4   3.3 234.9  32.7
  1218.  
  1219. -------------------------------------------------------------------------
  1220.  
  1221. host3$ mtr -r -c 100 time.afip.gov.ar
  1222. Start: 2018-03-27T19:03:51-0300
  1223. HOST: aleph.local                 Loss%  Snt  Last  Avg  Best  Wrst StDev
  1224.  1.|-- 10.17.71.254               0.0%  100   4.7  30.3   3.5 280.4  52.4
  1225.  2.|-- 10.255.254.250             0.0%  100   2.5  31.1   1.8 285.4  59.2
  1226.  3.|-- 209.13.133.10              0.0%  100  30.5  43.9   2.3 237.2  64.9
  1227.  4.|-- host169.advance.com.ar     3.0%  100  36.0  64.8   3.1 404.4  86.9
  1228.  5.|-- 200.32.33.33               2.0%  100 106.9  70.6   2.8 315.0  80.4
  1229.  6.|-- 200.32.34.66               5.0%  100  93.1  56.8   2.7 336.1  74.5
  1230.  7.|-- 200.32.33.38               7.0%  100  42.8  58.0   2.9 357.8  76.7
  1231.  8.|-- 209.13.139.211             4.0%  100  46.2  56.7   2.8 298.8  69.9
  1232.  9.|-- 209.13.139.209             1.0%  100  84.5  57.1   2.6 277.7  72.3
  1233. 10.|-- 209.13.166.211             1.0%  100  43.4  63.5   3.2 390.6  78.7
  1234. 11.|-- 200.32.34.137              2.0%  100  68.7  64.1   3.7 259.5  75.5
  1235. 12.|-- 200.32.33.37               0.0%  100   4.1  56.9   3.3 249.6  64.3
  1236. 13.|-- 200.32.34.121              3.0%  100  10.9  65.0   4.1 415.7  85.1
  1237. 14.|-- 200.32.33.241              2.0%  100 252.6  61.8   3.8 355.9  74.5
  1238. 15.|-- 200.16.206.198             3.0%  100 188.0  54.6   3.1 461.7  74.9
  1239. 16.|-- 172.18.2.53                2.0%  100 133.4  53.1   4.3 402.1  69.2
  1240. 17.|-- time.afip.gob.ar           4.0%  100  72.5  54.1   4.9 343.2  66.9
  1241.  
  1242. host3$ mtr -r -c 100 time.afip.gov.ar
  1243. Start: 2018-03-27T18:57:05-0300
  1244. HOST: aleph.local                 Loss%  Snt  Last  Avg  Best  Wrst StDev
  1245.  1.|-- 10.17.71.254               0.0%   50 125.6  88.1   3.7 392.4  79.3
  1246.  2.|-- 10.255.254.250             0.0%   50  62.1  54.8   2.1 333.2  68.0
  1247.  3.|-- 209.13.133.10              0.0%   50   4.0  33.9   2.4 280.8  51.3
  1248.  4.|-- host169.advance.com.ar     2.0%   50   4.1  21.3   2.9 236.7  40.4
  1249.  5.|-- 200.32.33.33               2.0%   50   4.5  32.2   3.2 341.3  69.4
  1250.  6.|-- 200.32.34.66               4.0%   50   7.7  26.0   3.5 278.8  55.8
  1251.  7.|-- 200.32.33.38               2.0%   50   4.8  29.4   3.0 221.3  43.4
  1252.  8.|-- 209.13.139.211             0.0%   50  84.8  40.3   3.1 250.4  53.0
  1253.  9.|-- 209.13.139.209             0.0%   50  25.1  35.0   2.8 249.2  55.4
  1254. 10.|-- 209.13.166.211             0.0%   50   3.7  33.5   2.6 188.9  54.3
  1255. 11.|-- 200.32.34.137              0.0%   50   5.6  28.2   3.7 224.3  51.1
  1256. 12.|-- 200.32.33.37               0.0%   50   3.7  24.2   3.5 189.5  44.9
  1257. 13.|-- 200.32.34.121              0.0%   50   4.7  30.8   4.0 213.2  51.6
  1258. 14.|-- 200.32.33.241              0.0%   50  14.4  33.1   3.9 364.6  67.2
  1259. 15.|-- 200.16.206.198             0.0%   50   5.0  58.2   3.1 300.7  88.5
  1260. 16.|-- 172.18.2.53                0.0%   50   9.4 117.8   4.4 315.1 103.4
  1261. 17.|-- time.afip.gob.ar           0.0%   50 199.6 120.2   5.2 484.0  96.2
  1262.  
  1263.  
  1264.  
  1265.  
  1266. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 23]
  1267. Internet-Draft               (sic frequency)                  April 2020
  1268.  
  1269.  
  1270. -------------------------------------------------------------------------
  1271.  
  1272. host4$ mtr -r -c 100 time.afip.gov.ar
  1273. Start: 2018-03-27T19:03:51-0300
  1274. HOST: cnet                        Loss%  Snt  Last  Avg  Best  Wrst StDev
  1275.  1.|-- 157.92.58.1                0.0%  100   6.6   2.8   0.3  12.8   2.5
  1276.  2.|-- ???                       100.0  100   0.0   0.0   0.0   0.0   0.0
  1277.  3.|-- ???                       100.0  100   0.0   0.0   0.0   0.0   0.0
  1278.  4.|-- host98.131-100-186.static  0.0%  100   5.7   5.6   1.5   9.4   2.2
  1279.  5.|-- host130.131-100-186.stati  0.0%  100   6.5   6.3   2.5  10.3   2.2
  1280.  6.|-- 200.0.17.104               0.0%  100   2.4   2.7   2.3  15.6   1.4
  1281.  7.|-- ???                       100.0  100   0.0   0.0   0.0   0.0   0.0
  1282.  8.|-- time.afip.gob.ar           0.0%  100   4.9   7.6   3.9 243.0  23.9
  1283.  
  1284. host4$ mtr -r -c 100 time.afip.gov.ar
  1285. Start: Tue Mar 27 18:41:40 2018
  1286. HOST: cnet                        Loss%  Snt  Last   Avg  Best Wrst StDev
  1287.  1.|-- 157.92.58.1                0.0%   50   4.0   1.6   0.3   9.1   1.6
  1288.  2.|-- ???                       100.0   50   0.0   0.0   0.0   0.0   0.0
  1289.  3.|-- ???                       100.0   50   0.0   0.0   0.0   0.0   0.0
  1290.  4.|-- host98.131-100-186.static  0.0%   50   4.7   5.5   1.5  10.9   2.4
  1291.  5.|-- host130.131-100-186.stati  0.0%   50   8.4   6.5   2.6  10.5   2.2
  1292.  6.|-- 200.0.17.104               0.0%   50   2.5   2.8   2.3  11.0   1.2
  1293.  7.|-- ???                       100.0   50   0.0   0.0   0.0   0.0   0.0
  1294.  8.|-- time.afip.gob.ar           0.0%   50   4.9   9.2   3.8 226.7  31.4
  1295.  
  1296. --------------------------------------------------------------------------
  1297.  
  1298. Authors' Addresses
  1299.  
  1300.    Jose Ignacio Alvarez-Hamelin (editor)
  1301.    Universidad de Buenos Aires - CONICET
  1302.    Av. Paseo Colon 850
  1303.    Buenos Aires  C1063ACV
  1304.    Argentina
  1305.  
  1306.    Phone: +54 11 5285-0716
  1307.    Email: [email protected]
  1308.    URI:   http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 24]
  1322. Internet-Draft               (sic frequency)                  April 2020
  1323.  
  1324.  
  1325.    David Samaniego
  1326.    Universidad de Buenos Aires
  1327.    Av. Paseo Colon 850
  1328.    Buenos Aires  C1063ACV
  1329.    Argentina
  1330.  
  1331.    Phone: +54 11 5285-0716
  1332.    Email: [email protected]
  1333.  
  1334.  
  1335.    Alfredo A. Ortega
  1336.    Universidad de Buenos Aires
  1337.    Av. Paseo Colon 850
  1338.    Buenos Aires  C1063ACV
  1339.    Argentina
  1340.  
  1341.    Phone: +54 11 5285-0716
  1342.    Email: [email protected]
  1343.  
  1344.  
  1345.    Ruediger Geib
  1346.    Deutsche Telekom
  1347.    Heinrich-Hertz-Str. 3-7
  1348.    Darmstadt  64297
  1349.    Germany
  1350.  
  1351.    Phone: +49 6151 5812747
  1352.    Email: [email protected]
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358. Alvarez-Hamelin, et al. Expires November 1, 2020               [Page 25]

Paste is for source code and general debugging text.

Login or Register to edit, delete and keep track of your pastes and more.

Raw Paste

Login or Register to edit or fork this paste. It's free.