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