idnits 2.17.1 draft-ietf-tictoc-security-requirements-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The mechanism also SHOULD not require excessive storage of client state in the master, nor significantly increase bandwidth consumption. -- The document date (March 12, 2012) is 4427 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Traps' is defined on line 690, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Working Group Tal Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational Karen O'Donoghue 4 Expires: September 2012 ISOC 5 March 12, 2012 7 TICTOC Security Requirements 8 draft-ietf-tictoc-security-requirements-01.txt 10 Abstract 12 As time synchronization protocols are becoming increasingly common 13 and widely deployed, concern about their exposure to various security 14 threats is increasing. This document defines a set of requirements 15 for security solutions for time synchronization protocols, focusing 16 on the IEEE 1588 and NTP. This document also discusses the security 17 impacts of time synchronization protocol practices, the time 18 synchronization performance implications of external security 19 practices, the dependencies between other security services and time 20 synchronization. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 12, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................. 3 63 2. Conventions Used in this Document ............................ 4 64 2.1. Terminology ............................................. 4 65 2.2. Abbreviations ........................................... 4 66 3. Security Threats ............................................. 5 67 3.1. Packet interception and manipulation .................... 5 68 3.2. Spoofing ................................................ 5 69 3.3. Replay attack ........................................... 5 70 3.4. Rogue master attack ..................................... 5 71 3.5. Packet Interception and Removal ......................... 6 72 3.6. Packet delay manipulation ............................... 6 73 3.7. Cryptographic performance attacks ....................... 6 74 3.8. DoS attacks ............................................. 6 75 3.9. Time source spoofing (e.g. GPS fraud) ................... 6 76 4. Security Requirements ........................................ 6 77 4.1. Clock Identity Authentication ........................... 6 78 4.1.1. Authentication of Masters .......................... 7 79 4.1.2. Proventication of Masters .......................... 7 80 4.1.3. Authentication of Slaves ........................... 7 81 4.1.4. PTP: Authentication of Transparent Clocks........... 8 82 4.1.5. PTP: Authentication of Announce Messages ........... 8 83 4.2. Data integrity .......................................... 9 84 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 9 85 4.2.1.1. Hop by Hop Integrity Protection ............... 9 86 4.2.1.2. End to End Integrity Protection .............. 10 87 4.3. Availability ........................................... 10 88 4.4. Replay Protection ...................................... 10 89 4.5. Cryptographic Keys & Security Associations ............. 10 90 4.5.1. Security Association .............................. 10 91 4.5.2. Unicast and Multicast ............................. 11 92 4.5.3. Key Freshness ..................................... 11 93 4.6. Performance ............................................ 11 94 4.7. Confidentiality......................................... 12 95 4.8. Protection against packet delay attacks ................ 12 96 4.9. Combining Secured with Unsecured Nodes ................. 12 97 4.9.1. Secure Mode ....................................... 13 98 4.9.2. Hybrid Mode ....................................... 13 99 5. Summary of Requirements ..................................... 13 100 6. Additional security implications ............................ 14 101 7. Issues for Further Discussion ............................... 15 102 8. Security Considerations ..................................... 15 103 9. IANA Considerations ......................................... 15 104 10. Acknowledgments ............................................ 15 105 11. References ................................................. 15 106 11.1. Normative References .................................. 15 107 11.2. Informative References ................................ 16 109 1. Introduction 111 As time synchronization protocols are becoming increasingly common 112 and widely deployed, concern about the resulting exposure to various 113 security threats is increasing. If a time synchronization protocol is 114 compromised, the applications it serves are prone to a range of 115 possible attacks including Denial-of-Service or incorrect behavior. 117 This document focuses on the security aspects of the Precision Time 118 Protocol ([IEEE 1588]) and the Network Time Protocol ([NTPv4]). The 119 Network Time Protocol was defined with an inherent security protocol, 120 defined in [NTPv4] and in [AutoKey]. The IEEE 1588 includes an 121 experimental security protocol, defined in Annex K of the standard, 122 but this Annex was never formalized into a fully defined security 123 protocol. 125 This document attempts to add clarity to the time synchronization 126 protocol security requirements discussion by addressing a series of 127 questions. It is expected that this document will evolve into 128 possibly two documents including one on requirements and one 129 providing clarity around the additional questions raised below. Until 130 the discussion has matured sufficiently, it will be captured in this 131 document. The four primary questions addressed by this draft include: 133 (1) What are the threats that need to be addressed for the time 134 synchronization protocol, and thus what security services need to be 135 provided? (e.g. a malicious NTP server or PTP master) 136 (2) What external security practices impact the security and 137 performance of time keeping, and what can be done to mitigate these 138 impacts? (e.g. an IPSec tunnel in the synchronization traffic path) 140 (3) What are the security impacts of time synchronization protocol 141 practices? (e.g. on-the-fly modification of timestamps) 143 (4) What are the dependencies between other security services and 144 time synchronization? (e.g. which comes first - the certificate or 145 the timestamp?) 147 It is expected that the final version of this document will define a 148 set of requirements for security solutions for time synchronization 149 protocols, focusing on the IEEE 1588 and NTP. 151 2. Conventions Used in this Document 153 2.1. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [KEYWORDS]. 159 This document describes security requirements, and thus requirements 160 are phrased in the document in the form "the security mechanism 161 MUST/SHOULD/...". Note, that the phrasing does not imply that this 162 document defines a specific security mechanism, but defines the 163 requirements that every security mechanism should comply to. 165 This document refers to both PTP and NTP. For the sake of 166 consistency, throughout the document the term "master" applies to 167 both a PTP master and an NTP server. Similarly, the term "slave" 168 applies to both PTP slaves and NTP clients. The general term "clock" 169 refers to masters, slaves and PTP Transparent Clocks (TC). The term 170 "protocol packets" is refers generically to PTP and NTP messages. 172 2.2. Terms & Abbreviations 174 BC Boundary Clock 176 MITM Man In The Middle 178 NTP Network Time Protocol 180 OC Ordinary Clock 182 PTP Precision Time Protocol 183 Secured clock A clock that supports a security mechanism that 184 complies to the requirements in this document 186 TC Transparent Clock 188 Unsecured clock A clock that does not support a security mechanism 189 according to the requirments in this document 191 3. Security Threats 193 The following section defines the security threats that are discussed 194 in subsequent sections. 196 3.1. Packet interception and manipulation 198 A packet interception and manipulation attack results when a Man-In- 199 The-Middle (MITM) attacker intercepts timing protocol packets, alters 200 them and relays them to their destination, allowing the attacker to 201 maliciously tamper with the protocol. This can result in a situation 202 where the time protocol is apparently operational but providing 203 intentionally inaccurate information. 205 3.2. Spoofing 207 In spoofing, an attacker masquerades as a legitimate node in the 208 network. For example, an attacker can impersonate the master, 209 allowing malicious distribution of false timing information. As with 210 packet interception and manipulation, this can result in a situation 211 where the time protocol is apparently operational but providing 212 intentionally inaccurate information. 214 3.3. Replay attack 216 In a replay attack, an attacker records protocol packets and replays 217 them at a later time. This can also result in a situation where the 218 time protocol is apparently operational but providing intentionally 219 inaccurate information. 221 3.4. Rogue master attack 223 In a rogue master attack, an attacker causes other nodes in the 224 network to believe it is a legitimate master. As opposed to the 225 spoofing attack, in the Rouge Master attack the attacker does not 226 fake its identity, but rather manipulates the master election 227 process. For example, in PTP, an attacker can manipulate the Best 228 Master Clock Algorithm (BMCA), and cause other nodes in the network 229 to believe it is the most eligible candidate to be a grandmaster. 231 3.5. Packet Interception and Removal 233 A packet interception and removal attack results when a Man-In-The- 234 Middle attacker intercepts and drops protocol packets, preventing the 235 destination node from receiving the timing information. 237 3.6. Packet delay manipulation 239 In a packet delay manipulation scenario, a Man-In-The-Middle attacker 240 intercepts protocol packets, and relays them to their destination 241 after adding a maliciously computed delay. 243 3.7. Cryptographic performance attacks 245 In cryptographic performance attacks, an attacker transmits fake 246 protocol packet, causing high utilization of the cryptographic engine 247 at the receiver, which attempts to verify the integrity of these fake 248 packets. 250 3.8. DoS attacks 252 There are many possible Layer 2 and Layer 3 Denial of Service 253 attacks. As the target's availability is compromised, the timing 254 protocol is affected accordingly. 256 3.9. Time source spoofing (e.g. GPS fraud) 258 In time source spoofing, an attacker spoofs the accurate time source 259 of the master. For example, if the master uses a GPS based clock as 260 its reference source, an attacker can spoof the GPS satellites, 261 causing the master to use a false reference time. 263 4. Security Requirements 265 4.1. Clock Identity Authentication 267 Requirement 269 The security mechanism MUST provide a means for each clock to 270 authenticate the sender of a protocol packet. 272 Discussion 274 In the context of this document, authentication refers to: 276 o Identification: verifying the identity of the peer clock. 278 o Authorization: verifying that the peer clock is permitted to play 279 the role that it plays in the protocol. For example, some nodes 280 may be permitted to be masters, while other nodes are only 281 permitted to be slaves or TCs. 283 The following subsections describe 4 distinct cases of clock 284 authentication. 286 4.1.1. Authentication of Masters 288 Requirement 290 The security mechanism MUST support an authentication mechanism, 291 allowing slave clocks to authenticate the identity of master clocks. 293 4.1.2. Proventication of Masters 295 Requirement 297 The security mechanism MUST support a proventication mechanism, to be 298 used in cases where end-to-end authentication is not possible. 300 Discussion 302 Slaves and transparent clocks authenticate masters in order to ensure 303 the authenticity of the time source. 305 In some cases a slave is connected to an intermediate master, that is 306 not the primary time source. For example, in PTP a slave can be 307 connected to a Boundary Clock (BC), which in turn is connected to a 308 grandmaster. A similar example in NTP is when a client is connected 309 to a stratum 2 server, which is connected to a stratum 1 server. In 310 both the PTP and the NTP cases, the slave authenticates the 311 intermediate master, and the intermediate master authenticates the 312 primary master. This inductive authentication process is referred to 313 in [AutoKey] as proventication. 315 4.1.3. Authentication of Slaves 317 Requirement 319 The security mechanism SHOULD provide a means for a master to 320 authenticate its slaves. 322 Discussion 323 Slaves are authenticated by masters in order to verify that the slave 324 is authorized to receive timing services from the master. 326 Authentication of slaves prevents unauthorized clocks from receiving 327 time services, and also reduces unnecessary load on the master clock, 328 by preventing the master from serving unauthorized clocks. It could 329 be argued that the authentication of slaves could put a higher load 330 on the master then serving the unauthorized clock. This tradeoff will 331 need to be discussed further. 333 4.1.4. PTP: Authentication of Transparent Clocks 335 Requirement 337 The security mechanism for PTP SHOULD provide a means for a master to 338 authenticate the TCs. 340 Discussion 342 Transparent clocks are authenticated by peer masters, slaves and TCs. 344 Authentication of TCs, much like authentication of slaves, reduces 345 unnecessary load on the master clock and peer TCs, by preventing the 346 master from serving unauthorized clocks. It also prevents malicious 347 TCs from attacking the protocol by manipulating the correctionField. 348 It could also be argued that the authentication could result in a 349 higher load then merely serving the unauthorized devices. This 350 tradeoff will need to be discussed further. 352 4.1.5. PTP: Authentication of Announce Messages 354 Requirement 356 The security mechanism for PTP MUST support authentication of 357 Announce messages. 359 Discussion 361 Master election is performed in PTP using the Best Master Clock 362 Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock 363 attributes using Announce messages, and the best master is elected 364 based on the information gathered from all the candidates. Announce 365 messages must be authenticated in order to prevent malicious master 366 attacks. 368 Note, that this subsection specifies a requirement that is not 369 necessarily included in 4.1.1. or in 4.1.3. , since the BMCA is 370 initiated before clocks have been defined as masters or slaves. 372 4.2. Data integrity 374 Requirement 376 The security mechanism MUST protect the integrity of protocol 377 packets. 379 Discussion 381 While subsection 4.1. refers to ensuring WHO sent the protocol 382 packet, this subsection refers to ensuring that the packet arrived 383 intact. The integrity protection mechanism ensures the authenticity 384 and completeness of data from the data originator. 386 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 388 Requirement 390 A security mechanism for PTP MUST support hop-by-hop integrity 391 protection. 393 Requirement 395 A security mechanism for PTP SHOULD support end-to-end integrity 396 protection. 398 Discussion 400 Specifically in PTP, when protocol packets are subjected to 401 modification by TCs, the integrity protection can be enforced in one 402 of two approaches, end-to-end or hop-by-hop. 404 4.2.1.1. Hop by Hop Integrity Protection 406 Each hop that needs to modify a protocol packet: 408 o Verifies its integrity. 410 o Modifies the packet, i.e., modifies the correctionField. 412 o Re-generates the integrity protection, e.g., re-computes a Message 413 Authentication Code. 415 In the hop-by-hop approach, the integrity of protocol packets is 416 protected by induction on the path from the originator to the 417 receiver. 419 This approach is simple, but allows malicious TCs to modify protocol 420 packets. 422 4.2.1.2. End to End Integrity Protection 424 In this approach, the integrity protection is maintained on the path 425 from the originator of a protocol packet to the receiver. This allows 426 the receiver to validate the protocol packet without the ability of 427 intermediate TCs to manipulate the packet. 429 Since TCs need to modify the correctionField, a separate integrity 430 protection mechanism is used specifically for the correctionField. 432 The end-to-end approach limits the TC's impact to the correctionField 433 alone, while the rest of the protocol packet is protected on an end- 434 to-end basis. 436 4.3. Availability 438 Requirement 440 The security mechanism MUST be resistant to DoS attacks from an 441 external attacker. 443 Discussion 445 This requirement is attained by clock authentication, as described in 446 4.1. . 448 4.4. Replay Protection 450 Requirement 452 Protocol messages MUST be resistant to replay attacks. 454 4.5. Cryptographic Keys & Security Associations 456 4.5.1. Security Association 458 Requirement 460 The security protocol MUST support an association protocol where: 462 o Two or more clocks authenticate each other. 464 o The clocks generate and agree on a cryptographic session key. 466 Discussion 468 The security requirements in 4.1. and 4 .2. require usage of 469 cryptographich mechanisms, deploying cryptographic keys. A security 470 association is an essential building block in these mechanisms. 472 4.5.2. Unicast and Multicast 474 Requirement 476 The security mechanism MUST support security association protocols 477 for unicast and for multicast associations. 479 Discussion 481 A unicast protocol requires an association protocol between two 482 clocks, whereas a multicast protocol requires an association protocol 483 among two or more clocks, where one of the clocks is a master. 485 4.5.3. Key Freshness 487 Requirement 489 The cryptographic keys MUST be refreshed periodically. 491 Requirement 493 The association protocol MUST be invoked periodically, where each 494 instance of the association protocol MUST produce a different session 495 key. 497 4.6. Performance 499 Requirement 501 The security mechanism MUST be designed in such a way that it does 502 not degrade the quality of the time transfer. 504 Requirement 506 The mechanism SHOULD be relatively lightweight, as client 507 restrictions often dictate a low processing and memory footprint, and 508 because the server may have extensive fan-out. 510 Requirement 512 The mechanism also SHOULD not require excessive storage of client 513 state in the master, nor significantly increase bandwidth 514 consumption. 516 4.7. Confidentiality 518 Requirement 520 The security mechanism MAY provide confidentiality protection of the 521 protocol packets. 523 Discussion 525 In the context of time synchronization, confidentiality is typically 526 of low importance, since timing information is typically not 527 considered secret information. 529 Confidentiality can play an important role when service providers 530 charge payment for time synchronization services, but these cases are 531 rather esoteric. 533 Confidentiality can also prevent an MITM attacker from identifying 534 protocol packets. Thus, confidentiality can assist in protecting the 535 timing protocol against packet delay attacks, where the attacker 536 selectively adds delay to time protocol packets. 538 4.8. Protection against packet delay attacks 540 Requirement 542 The security mechanism MAY include a means to detect packet delay 543 attacks. 545 Requirement 547 The security mechanism MAY include a protection switching mechanism 548 that allows a node that detects a delay attack to switch over to a 549 secondary master. 551 4.9. Combining Secured with Unsecured Nodes 553 Integrating a security mechanism into a time synchronized system is a 554 complex process, and in some cases may require a gradual process, 555 where new equipment supports the security mechanism, and is required 556 to interoperate with legacy equipment without the security features. 558 4.9.1. Secure Mode 560 Requirement 562 The security mechanism MUST support a secure mode, where only secured 563 clocks are permitted to take part in the synchronization protocol. A 564 protocol packet received from an unsecured clock MUST be discarded. 566 4.9.2. Hybrid Mode 568 Requirement 570 The security protocol MAY support a hybrid mode, where both secured 571 and unsecured clocks are permitted to take part in the protocol. 573 A master in the hybrid mode MUST be a secured clock. 575 A secured slave in the hybrid mode MUST discard all protocol packets 576 received from unsecured clocks. 578 Discussion 580 The hybrid mode allows both secured and unsecured clocks to take part 581 in the synchronization protocol. It is essential that the existence 582 of unsecured clocks does not compromise the security provided to 583 secured clocks. Hence, secured slaves only "trust" protocol packets 584 received from a secured clock. An unsecured clock can receive 585 protocol packets from either secured clocks, or unsecured clocks. 587 5. Summary of Requirements 589 +-----------+--------------------------------------+---------------+ 590 | Section | Requirement | Type | 591 +-----------+--------------------------------------+---------------+ 592 | 4.1. | Authentication of sender. | MUST | 593 | +--------------------------------------+---------------+ 594 | | Authentication of master. | MUST | 595 | +--------------------------------------+---------------+ 596 | | Proventication. | MUST | 597 | +--------------------------------------+---------------+ 598 | | Authentication of slaves. | SHOULD | 599 | +--------------------------------------+---------------+ 600 | | PTP: Authentication of TCs. | SHOULD | 601 | +--------------------------------------+---------------+ 602 | | PTP: Authentication of Announce | SHOULD | 603 | | messages. | | 604 +-----------+--------------------------------------+---------------+ 605 | 4.2. | Integrity protection. | MUST | 606 | +--------------------------------------+---------------+ 607 | | PTP: hop-by-hop integrity protection.| MUST | 608 | +--------------------------------------+---------------+ 609 | | PTP: end-to-end integrity protection.| SHOULD | 610 +-----------+--------------------------------------+---------------+ 611 | 4.3. | Protection against DoS attacks. | MUST | 612 +-----------+--------------------------------------+---------------+ 613 | 4.4. | Replay protection. | MUST | 614 +-----------+--------------------------------------+---------------+ 615 | 4.5. | Security association. | MUST | 616 | +--------------------------------------+---------------+ 617 | | Unicast and multicast associations. | MUST | 618 | +--------------------------------------+---------------+ 619 | | Key freshness. | MUST | 620 +-----------+--------------------------------------+---------------+ 621 | 4.6. | Performance: no degradation in | MUST | 622 | | quality of time transfer. | | 623 | +--------------------------------------+---------------+ 624 | | Performance: lightweight. | SHOULD | 625 | +--------------------------------------+---------------+ 626 | | Performance: storage, bandwidth. | MUST | 627 +-----------+--------------------------------------+---------------+ 628 | 4.7. | Confidentiality protection. | MAY | 629 +-----------+--------------------------------------+---------------+ 630 | 4.8. | Protection against delay attacks. | MAY | 631 +-----------+--------------------------------------+---------------+ 632 | 4.9. | Secure mode. | MUST | 633 | +--------------------------------------+---------------+ 634 | | Hybrid mode. | MAY | 635 +-----------+--------------------------------------+---------------+ 636 Table 1 Summary of Security Requirements 638 6. Additional security implications 640 This section will discuss additional security implications as 641 outlined in the questions below. Contributions are welcome and 642 encouraged. 644 o What external security practices impact the security and 645 performance of time keeping? (and what can be done to mitigate 646 these impacts?) 648 o What are the security impacts of time synchronization protocol 649 practices? (e.g. on-the-fly modification of timestamps) 651 o What are the dependencies between other security services and time 652 synchronization? 654 7. Issues for Further Discussion 656 This section will discuss additional issues as identified below. 658 o The key distribution is outside the scope of this document. 659 Although this is a cardinal element in any security system, it is 660 not a security requirement, and is thus not described here. 662 8. Security Considerations 664 The security considerations of network timing protocols are presented 665 throughout this document. 667 9. IANA Considerations 669 There are no new IANA considerations implied by this document. 671 10. Acknowledgments 673 This document was prepared using 2-Word-v2.0.template.dot. 675 11. References 677 11.1. Normative References 679 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 [NTPv4] Mills, D., Delaware, U., Martin, J., Burbank, J., 683 Kasch, W., "Network Time Protocol Version 4: Protocol 684 and Algorithms Specification", RFC 5905, June 2010. 686 [AutoKey] Haberman, B., Mills, D., "Network Time Protocol 687 Version 4: Autokey Specification", RFC 5906, June 688 2010. 690 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., 691 "Traps and pitfalls in secure clock synchronization" 692 in Proceedings of 2007 International Symposium for 693 Precision Clock Synchronization for Measurement, 694 Control and Communication, ISPCS 2007, pp. 18-24, 695 2007. 697 11.2. Informative References 699 [IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588 700 IEEE Standard for a Precision Clock Synchronization 701 Protocol for Networked Measurement and Control Systems 702 Version 2", IEEE Standard, 2008. 704 Authors' Addresses 706 Tal Mizrahi 707 Marvell 708 6 Hamada St. 709 Yokneam, 20692 Israel 711 Email: talmi@marvell.com 713 Karen O'Donoghue 714 7167 Goby Lane 715 King George, VA 22485 717 Email: odonoghue@isoc.org