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