--- 1/draft-ietf-tictoc-security-requirements-01.txt 2012-06-17 10:14:11.965427162 +0200 +++ 2/draft-ietf-tictoc-security-requirements-02.txt 2012-06-17 10:14:12.005425466 +0200 @@ -1,18 +1,18 @@ TICTOC Working Group Tal Mizrahi Internet Draft Marvell Intended status: Informational Karen O'Donoghue -Expires: September 2012 ISOC - March 12, 2012 +Expires: December 2012 ISOC + June 17, 2012 TICTOC Security Requirements - draft-ietf-tictoc-security-requirements-01.txt + draft-ietf-tictoc-security-requirements-02.txt Abstract As time synchronization protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of requirements for security solutions for time synchronization protocols, focusing on the IEEE 1588 and NTP. This document also discusses the security impacts of time synchronization protocol practices, the time synchronization performance implications of external security @@ -33,21 +33,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 12, 2012. + This Internet-Draft will expire on December 17, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,63 +55,75 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 3 2. Conventions Used in this Document ............................ 4 2.1. Terminology ............................................. 4 - 2.2. Abbreviations ........................................... 4 + 2.2. Terms & Abbreviations ................................... 5 3. Security Threats ............................................. 5 - 3.1. Packet interception and manipulation .................... 5 - 3.2. Spoofing ................................................ 5 - 3.3. Replay attack ........................................... 5 - 3.4. Rogue master attack ..................................... 5 - 3.5. Packet Interception and Removal ......................... 6 - 3.6. Packet delay manipulation ............................... 6 - 3.7. Cryptographic performance attacks ....................... 6 - 3.8. DoS attacks ............................................. 6 - 3.9. Time source spoofing (e.g. GPS fraud) ................... 6 - 4. Security Requirements ........................................ 6 - 4.1. Clock Identity Authentication ........................... 6 - 4.1.1. Authentication of Masters .......................... 7 - 4.1.2. Proventication of Masters .......................... 7 - 4.1.3. Authentication of Slaves ........................... 7 - 4.1.4. PTP: Authentication of Transparent Clocks........... 8 - 4.1.5. PTP: Authentication of Announce Messages ........... 8 - 4.2. Data integrity .......................................... 9 - 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 9 - 4.2.1.1. Hop by Hop Integrity Protection ............... 9 - 4.2.1.2. End to End Integrity Protection .............. 10 - 4.3. Availability ........................................... 10 - 4.4. Replay Protection ...................................... 10 - 4.5. Cryptographic Keys & Security Associations ............. 10 - 4.5.1. Security Association .............................. 10 - 4.5.2. Unicast and Multicast ............................. 11 - 4.5.3. Key Freshness ..................................... 11 - 4.6. Performance ............................................ 11 - 4.7. Confidentiality......................................... 12 - 4.8. Protection against packet delay attacks ................ 12 - 4.9. Combining Secured with Unsecured Nodes ................. 12 - 4.9.1. Secure Mode ....................................... 13 - 4.9.2. Hybrid Mode ....................................... 13 - 5. Summary of Requirements ..................................... 13 - 6. Additional security implications ............................ 14 - 7. Issues for Further Discussion ............................... 15 - 8. Security Considerations ..................................... 15 - 9. IANA Considerations ......................................... 15 - 10. Acknowledgments ............................................ 15 - 11. References ................................................. 15 - 11.1. Normative References .................................. 15 - 11.2. Informative References ................................ 16 + 3.1. Threat Model ............................................ 5 + 3.1.1. Internal vs. External Attackers .................... 5 + 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 6 + 3.2. Threat Analysis.......................................... 6 + 3.2.1. Packet Interception and Manipulation ............... 6 + 3.2.2. Spoofing ........................................... 6 + 3.2.3. Replay Attack ...................................... 6 + 3.2.4. Rogue Master Attack ................................ 6 + 3.2.5. Packet Interception and Removal .................... 7 + 3.2.6. Packet Delay Manipulation .......................... 7 + 3.2.7. Cryptographic Performance Attacks .................. 7 + 3.2.8. L2/L3 DoS Attacks .................................. 7 + 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 7 + 3.3. Threat Analysis Summary ................................. 7 + 4. Security Requirements ........................................ 9 + 4.1. Clock Identity Authentication ........................... 9 + 4.1.1. Authentication of Masters .......................... 9 + 4.1.2. Proventication of Masters .......................... 9 + 4.1.3. Authentication of Slaves .......................... 10 + 4.1.4. PTP: Authentication of Transparent Clocks.......... 10 + 4.1.5. PTP: Authentication of Announce Messages .......... 11 + 4.2. Data integrity ......................................... 11 + 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 11 + 4.2.1.1. Hop by Hop Integrity Protection .............. 12 + 4.2.1.2. End to End Integrity Protection .............. 12 + + 4.3. Availability ........................................... 12 + 4.4. Replay Protection ...................................... 13 + 4.5. Cryptographic Keys & Security Associations ............. 13 + 4.5.1. Security Association .............................. 13 + 4.5.2. Unicast and Multicast ............................. 13 + 4.5.3. Key Freshness ..................................... 14 + 4.6. Performance ............................................ 14 + 4.7. Confidentiality......................................... 14 + 4.8. Protection against packet delay attacks ................ 15 + 4.9. Combining Secured with Unsecured Nodes ................. 15 + 4.9.1. Secure Mode ....................................... 15 + 4.9.2. Hybrid Mode ....................................... 16 + 5. Summary of Requirements ..................................... 16 + 6. Additional security implications ............................ 18 + 6.1. Security and on-the-fly Timestamping ................... 18 + 6.2. Security and Two-Step Timestamping ..................... 18 + 6.3. Intermediate Clocks .................................... 19 + 6.4. The Effect of External Security Protocols on Time + Synchronization ............................................. 19 + 6.5. External Security Services Requiring Time Synchronization20 + 7. Issues for Further Discussion ............................... 20 + 8. Security Considerations ..................................... 20 + 9. IANA Considerations ......................................... 20 + 10. Acknowledgments ............................................ 20 + 11. References ................................................. 21 + 11.1. Normative References .................................. 21 + 11.2. Informative References ................................ 21 1. Introduction As time synchronization protocols are becoming increasingly common and widely deployed, concern about the resulting exposure to various security threats is increasing. If a time synchronization protocol is compromised, the applications it serves are prone to a range of possible attacks including Denial-of-Service or incorrect behavior. This document focuses on the security aspects of the Precision Time @@ -183,90 +197,185 @@ Secured clock A clock that supports a security mechanism that complies to the requirements in this document TC Transparent Clock Unsecured clock A clock that does not support a security mechanism according to the requirments in this document 3. Security Threats - The following section defines the security threats that are discussed - in subsequent sections. + This section discusses the possible attacker types, and analyzes + various attacks against time synchronization protocols. -3.1. Packet interception and manipulation + The literature is rich with security threats of time synchronization + protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. + The threat analysis in this document is mostly based on [TM]. + +3.1. Threat Model + + A time synchronization protocol can be attacked by various types of + attackers. + + The analysis in this documents classifies attackers according to 2 + criteria, as described in 3.1.1. and 3.1.2. + +3.1.1. Internal vs. External Attackers + + In the context of internal and external attackers, the underlying + assumption is that the time synchronization protocol is secured + either by an encryption or an authentication mechanism. + + Internal attackers either have access to a trusted segment of the + network, or possess the encryption or authentication keys. External + attackers, on the other hand, do not have the keys, and are exposed + only to the encrypted or authenticated traffic. Thus, an internal + attacker can maliciously tamper with legitimate traffic in the + network, as well as generate its own traffic and make it appear + legitimate to its attacked nodes. + + Obviously, in the absence of a security mechanism there is no + distinction between internal and external attackers, since all + attackers are internal in practice. + +3.1.2. Man in the Middle (MITM) vs. Packet Injector + + MITM attackers are located in a position that allows interception and + modification of in-flight protocol packets, while a traffic injector + cannot intercept legitimate packets, but can record them, replay old + messages, and generate its own traffic. + +3.2. Threat Analysis + +3.2.1. Packet Interception and Manipulation A packet interception and manipulation attack results when a Man-In- The-Middle (MITM) attacker intercepts timing protocol packets, alters them and relays them to their destination, allowing the attacker to maliciously tamper with the protocol. This can result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information. -3.2. Spoofing +3.2.2. Spoofing In spoofing, an attacker masquerades as a legitimate node in the network. For example, an attacker can impersonate the master, allowing malicious distribution of false timing information. As with packet interception and manipulation, this can result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information. -3.3. Replay attack +3.2.3. Replay Attack In a replay attack, an attacker records protocol packets and replays them at a later time. This can also result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information. -3.4. Rogue master attack +3.2.4. Rogue Master Attack In a rogue master attack, an attacker causes other nodes in the network to believe it is a legitimate master. As opposed to the spoofing attack, in the Rouge Master attack the attacker does not fake its identity, but rather manipulates the master election process. For example, in PTP, an attacker can manipulate the Best Master Clock Algorithm (BMCA), and cause other nodes in the network to believe it is the most eligible candidate to be a grandmaster. -3.5. Packet Interception and Removal +3.2.5. Packet Interception and Removal A packet interception and removal attack results when a Man-In-The- Middle attacker intercepts and drops protocol packets, preventing the destination node from receiving the timing information. -3.6. Packet delay manipulation +3.2.6. Packet Delay Manipulation In a packet delay manipulation scenario, a Man-In-The-Middle attacker intercepts protocol packets, and relays them to their destination after adding a maliciously computed delay. -3.7. Cryptographic performance attacks +3.2.7. Cryptographic Performance Attacks In cryptographic performance attacks, an attacker transmits fake protocol packet, causing high utilization of the cryptographic engine at the receiver, which attempts to verify the integrity of these fake packets. -3.8. DoS attacks +3.2.8. L2/L3 DoS Attacks There are many possible Layer 2 and Layer 3 Denial of Service attacks. As the target's availability is compromised, the timing protocol is affected accordingly. -3.9. Time source spoofing (e.g. GPS fraud) +3.2.9. Master Time Source Spoofing (e.g. GPS fraud) In time source spoofing, an attacker spoofs the accurate time source of the master. For example, if the master uses a GPS based clock as its reference source, an attacker can spoof the GPS satellites, causing the master to use a false reference time. +3.3. Threat Analysis Summary + + The two key factors to a threat analysis are the severity and the + likelihood of each of the analyzed attacks. + + Table 1 summarizes the security attacks presented in 3.2. For each + attack, the table specifies its impact, and its applicability to each + of the attacker types presented in 3.1. + + The Impact column provides an intuition to the severity of each + attack, and the relevant Attacker Type columns provide an intuition + about the how difficult each attack is to implement, and hence about + the likelihood of each attack. + + The impact column in Table 1 can have one of 3 values: + + o False time - slaves align to a false time or frequency value due + to the attack. + + o Accuracy degradation - the attack yields a degradation in the + slave accuracy, but does not completely compromise the slaves' + time and frequency. + + o DoS - the attack causes a denial of service to the attacked node, + whose impact is not restricted to the time synchronization + protocol. + + The Attacket Type columns refer to the 4 possible combinations of the + attacker types defined in 3.1. + ++-----------------------------+-------------------++-------------------+ +| Attack | Impact || Attacker Type | +| +-----+--------+----++---------+---------+ +| |False|Accuracy| ||Internal | Extenal | +| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| ++-----------------------------+-----+--------+----++----+----+----+----+ +|Interception and manipulation| + | | || + | | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Spoofing | + | | || + | + | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Replay attack | + | | || + | + | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Rogue master attack | + | | || + | + | | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Interception and Removal | | + | || + | | + | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Packet delay manipulation | + | | || + | | + | | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Crypt. performance attacks | | | + || + | + | + | + | ++-----------------------------+-----+--------+----++----+----+----+----+ +|DoS attacks | | | + || + | + | + | + | ++-----------------------------+-----+--------+----++----+----+----+----+ +|Master Time source spoofing | + | | || + | + | + | + | ++-----------------------------+-----+--------+----++----+----+----+----+ + Table 1 Threat Analysis - Summary + 4. Security Requirements 4.1. Clock Identity Authentication Requirement The security mechanism MUST provide a means for each clock to authenticate the sender of a protocol packet. Discussion @@ -389,22 +499,21 @@ A security mechanism for PTP MUST support hop-by-hop integrity protection. Requirement A security mechanism for PTP SHOULD support end-to-end integrity protection. Discussion - - Specifically in PTP, when protocol packets are subjected to + Specifically in PTP, when protocol packets are subject to modification by TCs, the integrity protection can be enforced in one of two approaches, end-to-end or hop-by-hop. 4.2.1.1. Hop by Hop Integrity Protection Each hop that needs to modify a protocol packet: o Verifies its integrity. o Modifies the packet, i.e., modifies the correctionField. @@ -430,27 +539,35 @@ protection mechanism is used specifically for the correctionField. The end-to-end approach limits the TC's impact to the correctionField alone, while the rest of the protocol packet is protected on an end- to-end basis. 4.3. Availability Requirement - The security mechanism MUST be resistant to DoS attacks from an - external attacker. + The security mechanism MUST protect the time synchronization protocol + from DoS attacks by external attackers. Discussion - This requirement is attained by clock authentication, as described in - 4.1. . + The protocol availability can be compromised by several different + attacks. An attacker can inject protocol messages to implement the + spoofing attack (3.2.2. ) or the rogue master attack (3.2.4. ), + causing denial of service to the attackee. An authentication + mechanism (4.1. ) limits these attacks strictly to internal + attackers, and thus prevents external attackers from performing them. + + DoS attacks at lower layers of the protocol stack (3.2.8. ) can still + be implemented by external attackers even in the presence of an + authentication mechanism. 4.4. Replay Protection Requirement Protocol messages MUST be resistant to replay attacks. 4.5. Cryptographic Keys & Security Associations 4.5.1. Security Association @@ -506,24 +623,34 @@ The mechanism SHOULD be relatively lightweight, as client restrictions often dictate a low processing and memory footprint, and because the server may have extensive fan-out. Requirement The mechanism also SHOULD not require excessive storage of client state in the master, nor significantly increase bandwidth consumption. +Discussion + + Note that the performance requirements refer to a time- + synchronization-specific security mechanism. In systems where a + security protocol is used for other types of traffic as well, this + document does not place any performance requirements on the security + protocol performance. For example, if IPsec encryption is used for + securing all information between the master and slave node, including + information that is not part of the time protocol, the requirements + in this subsection are not necessarily applicable. + 4.7. Confidentiality Requirement - The security mechanism MAY provide confidentiality protection of the protocol packets. Discussion In the context of time synchronization, confidentiality is typically of low importance, since timing information is typically not considered secret information. Confidentiality can play an important role when service providers @@ -556,40 +683,60 @@ to interoperate with legacy equipment without the security features. 4.9.1. Secure Mode Requirement The security mechanism MUST support a secure mode, where only secured clocks are permitted to take part in the synchronization protocol. A protocol packet received from an unsecured clock MUST be discarded. +Discussion + While the requirement in this subsection is a bit similar to the one + in 4.1. , it explicitly defines the secure mode, as opposed to the + hybrid mode presented in the next subsection. + 4.9.2. Hybrid Mode Requirement The security protocol MAY support a hybrid mode, where both secured and unsecured clocks are permitted to take part in the protocol. - A master in the hybrid mode MUST be a secured clock. +Discussion - A secured slave in the hybrid mode MUST discard all protocol packets - received from unsecured clocks. + The hybrid mode allows both secured and unsecured clocks to take part + in the synchronization protocol. + +Requirement + + A master in the hybrid mode SHOULD be a secured clock. + + A secured slave in the hybrid mode SHOULD discard all protocol + packets received from unsecured clocks. Discussion - The hybrid mode allows both secured and unsecured clocks to take part - in the synchronization protocol. It is essential that the existence - of unsecured clocks does not compromise the security provided to - secured clocks. Hence, secured slaves only "trust" protocol packets - received from a secured clock. An unsecured clock can receive - protocol packets from either secured clocks, or unsecured clocks. + This requirement ensures that the existence of unsecured clocks does + not compromise the security provided to secured clocks. Hence, + secured slaves only "trust" protocol packets received from a secured + clock. An unsecured clock can receive protocol packets from either + secured clocks, or unsecured clocks. + + Note that the security scheme in [NTPv4] with [AutoKey] does not + satisfy this requirement, since nodes prefer the server with the best + clock, and not necessarily the server that supports authentication. + For example, a stratum 2 server is connected to two stratum 1 + servers, Server A, supporting authentication, and server B, without + authentication. If server B has a more accurate clock than A, the + stratum 2 server chooses server B, in spite of the fact it does not + support authentication. 5. Summary of Requirements +-----------+--------------------------------------+---------------+ | Section | Requirement | Type | +-----------+--------------------------------------+---------------+ | 4.1. | Authentication of sender. | MUST | | +--------------------------------------+---------------+ | | Authentication of master. | MUST | | +--------------------------------------+---------------+ @@ -626,41 +773,135 @@ | | Performance: storage, bandwidth. | MUST | +-----------+--------------------------------------+---------------+ | 4.7. | Confidentiality protection. | MAY | +-----------+--------------------------------------+---------------+ | 4.8. | Protection against delay attacks. | MAY | +-----------+--------------------------------------+---------------+ | 4.9. | Secure mode. | MUST | | +--------------------------------------+---------------+ | | Hybrid mode. | MAY | +-----------+--------------------------------------+---------------+ - Table 1 Summary of Security Requirements + Table 2 Summary of Security Requirements 6. Additional security implications - This section will discuss additional security implications as - outlined in the questions below. Contributions are welcome and - encouraged. + This section discusses additional implications of the interaction + between time synchronization protocols and security mechanisms. - o What external security practices impact the security and - performance of time keeping? (and what can be done to mitigate - these impacts?) + This section refers to time synchronization security mechanisms, as + well as to "external" security mechanisms, i.e., security mechanisms + that are not strictly related to the time synchronization protocol. - o What are the security impacts of time synchronization protocol - practices? (e.g. on-the-fly modification of timestamps) +6.1. Security and on-the-fly Timestamping - o What are the dependencies between other security services and time - synchronization? + Time synchronization protocols often require protocol packets to be + modified during transmission and reception. Both NTP and PTP in one- + step mode require clocks to modify protocol packets with the time of + transmission or reception. -7. Issues for Further Discussion + In the presence of a security mechanism, whether encryption or + integrity protection: - This section will discuss additional issues as identified below. + o During transmission the security protocol must be applied after + integrating the timestamp into the packet. + + o During reception, the encryption or integrity check must be + performed before modifying the packet with the time of reception. + + To allow high accuracy, timestamping is typically performed as close + to the transmission or reception time as possible. However, since the + security engine must be placed between the timestamping function and + the physical interface, in some cases it may introduce non- + deterministic latency that causes accuracy degradation. These + performance aspects have been analyzed in the literature, e.g., in + [1588IPsec] and [Tunnel]. + +6.2. Security and Two-Step Timestamping + + PTP supports a two-step mode of operation, where the time of + transmission and the time of reception of protocol packets are + measured without modifying the packets. As opposed to one-step mode, + two step timestamping can be performed at the physical interface even + in the presence of a security mechanism. + + Note that if an encryption mechanism is used, it presents a challenge + to the timestamping mechanism, since time protocol packets are + encrypted when traversing the physical interface, and are thus + impossible to identify. A possible solution to this problem + [IPsecSync] is to include an indication in the encryption header that + identifies time synchronization packets. + +6.3. Intermediate Clocks + + A time synchronization protocol allows slaves to receive time + information from an accurate time source. Time information is sent + over a path that often traverses one or more intermediate clocks. + + o In NTP, time information originated from a stratum 1 server can be + distributed to stratum 2 servers, and in turn distributed from the + stratum 2 servers to NTP clients. In this case, the stratum 2 + servers are a layer of intermediate clocks. + + o In PTP, BCs and TCs are intermediate nodes used to improve the + accuracy of time information conveyed between the grandmaster and + the slaves. + + A common rule of thumb in network security is that end-to-end + security is the best policy, as it secures the entire path between + the data originator and its receiver. The usage of intermediate nodes + implies that if a security mechanism is deployed in the network, all + intermediate nodes must be exposed to the security key since they + must be able to send time information to the slaves, or to modify + time information sent through them. + + This inhehrent property of using intermediate clocks increases the + system's exposure to internal threats, as there is a large number of + nodes that are exposed to the security keys. + +6.4. The Effect of External Security Protocols on Time Synchronization + + Time synchronization protocols are often deployed in systems that use + security mechanisms and protocols. + + A typical example is the 3GPP Femtocell network [3GPP], where IPsec + is used for securing traffic between a Femtocell and the Femto + Gateway. All traffic between these two nodes is secured by IPsec, + including the time synchronization protocol traffic. This use-case is + thoroughly discussed in [IPsecSync]. + + Another typical example is the usage of MACsec encryption in L2 + networks that deploy time synchronization [AvbAssum]. + + The usage of external security mechanisms may affect time + synchronization protocols as follows: + + o Timestamping accuracy can be affected, as described in 6.1. + + o If traffic is secured between two nodes in the network, no + intermediate clocks can be used between these two nodes. In the + [3GPP] example, if traffic between the Femtocell and the Femto + Gateway is encrypted, then time protocol packets are sent over the + underlying network without modification, and thus cannot enjoy the + improved accuracy provided by intermediate clock nodes. + +6.5. External Security Services Requiring Time Synchronization + + Certificate validation requires the sender and receiver to be time + synchronized. Thus, synchronization is required for establishing + security protocols such as IKEv2 and TLS. + + An even stronger interdependence between a time synchronization + protocol and a security mechanism is defined in [AutoKey], which + defines mutual dependence between the acquired time information, and + the authentication protocol that secures it. + +7. Issues for Further Discussion o The key distribution is outside the scope of this document. Although this is a cardinal element in any security system, it is not a security requirement, and is thus not described here. 8. Security Considerations The security considerations of network timing protocols are presented throughout this document. @@ -680,33 +921,70 @@ Requirement Levels", BCP 14, RFC 2119, March 1997. [NTPv4] Mills, D., Delaware, U., Martin, J., Burbank, J., Kasch, W., "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [AutoKey] Haberman, B., Mills, D., "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010. +11.2. Informative References + + [IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588 + IEEE Standard for a Precision Clock Synchronization + Protocol for Networked Measurement and Control Systems + Version 2", IEEE Standard, 2008. + [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., "Traps and pitfalls in secure clock synchronization" in Proceedings of 2007 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2007, pp. 18-24, 2007. -11.2. Informative References + [TM] T. Mizrahi, "Time synchronization security using IPsec + and MACsec", ISPCS 2011, pp. 38-43, 2011. - [IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588 - IEEE Standard for a Precision Clock Synchronization - Protocol for Networked Measurement and Control Systems - Version 2", IEEE Standard, 2008. + [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the + precise time protocol (short paper)," 8th + International Conference on Information and + Communication Security (ICICS 2006), pp. 50-59, 2006. + + [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, + "Secure Time Synchronization in Sensor Networks", ACM + Trans. Info. and Sys. Sec., Volume 11, Issue 4, July + 2008. + + [AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", + IEEE 802.1 AVB Plenary, work in progress, May 2012. + + [IPsecSync] Y. Xu, "IPsec security for packet based + synchronization", IETF, draft-xu-tictoc-ipsec- + security-for-synchronization (work in progress), 2011. + + [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved + Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in + progress), 2011. + + [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec + tunnels - An analysis", in Proceedings of 2010 + International Symposium for Precision Clock + Synchronization for Measurement, Control and + Communication, ISPCS 2010, pp. 83-90, 2010. + + [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure + tunneling of high precision clock synchronisation + protocols and other timestamped data", in Proceedings + of the 8th IEEE International Workshop on Factory + Communication Systems (WFCS), vol. ISBN 978-1-4244- + 5461-7, pp. 303-313, 2010. Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com