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