draft-ietf-tictoc-security-requirements-11.txt   draft-ietf-tictoc-security-requirements-12.txt 
TICTOC Working Group T. Mizrahi TICTOC Working Group T. Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Intended status: Informational
Expires: January 2015 July 21, 2014 Expires: March 2015 September 3, 2014
Security Requirements of Time Protocols Security Requirements of Time Protocols
in Packet Switched Networks in Packet Switched Networks
draft-ietf-tictoc-security-requirements-11.txt draft-ietf-tictoc-security-requirements-12.txt
Abstract Abstract
As time and frequency distribution protocols are becoming As time and frequency distribution protocols are becoming
increasingly common and widely deployed, concern about their exposure increasingly common and widely deployed, concern about their exposure
to various security threats is increasing. This document defines a to various security threats is increasing. This document defines a
set of security requirements for time protocols, focusing on the set of security requirements for time protocols, focusing on the
Precision Time Protocol (PTP) and the Network Time Protocol (NTP). Precision Time Protocol (PTP) and the Network Time Protocol (NTP).
This document also discusses the security impacts of time protocol This document also discusses the security impacts of time protocol
practices, the performance implications of external security practices, the performance implications of external security
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2015. This Internet-Draft will expire on March 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3.2.1. Packet Manipulation ................................ 8 3.2.1. Packet Manipulation ................................ 8
3.2.2. Spoofing ........................................... 9 3.2.2. Spoofing ........................................... 9
3.2.3. Replay Attack ...................................... 9 3.2.3. Replay Attack ...................................... 9
3.2.4. Rogue Master Attack ................................ 9 3.2.4. Rogue Master Attack ................................ 9
3.2.5. Packet Interception and Removal ................... 10 3.2.5. Packet Interception and Removal ................... 10
3.2.6. Packet Delay Manipulation ......................... 10 3.2.6. Packet Delay Manipulation ......................... 10
3.2.7. L2/L3 DoS Attacks ................................. 10 3.2.7. L2/L3 DoS Attacks ................................. 10
3.2.8. Cryptographic Performance Attacks ................. 10 3.2.8. Cryptographic Performance Attacks ................. 10
3.2.9. DoS Attacks against the Time Protocol ............. 10 3.2.9. DoS Attacks against the Time Protocol ............. 10
3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 11 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 11
3.2.11. Exploiting Vulnerabilities in the Time Protocol .. 11
3.2.12. Network Reconnaissance ........................... 11
3.3. Threat Analysis Summary ................................ 11 3.3. Threat Analysis Summary ................................ 11
4. Requirement Levels .......................................... 13 4. Requirement Levels .......................................... 13
5. Security Requirements ....................................... 13 5. Security Requirements ....................................... 14
5.1. Clock Identity Authentication and Authorization ........ 14 5.1. Clock Identity Authentication and Authorization ........ 14
5.1.1. Authentication and Authorization of Masters ....... 15 5.1.1. Authentication and Authorization of Masters ....... 15
5.1.2. Recursive Authentication and Authorization of Masters 5.1.2. Recursive Authentication and Authorization of Masters
(Chain of Trust) ......................................... 15 (Chain of Trust) ......................................... 16
5.1.3. Authentication and Authorization of Slaves ........ 16 5.1.3. Authentication and Authorization of Slaves ........ 17
5.1.4. PTP: Authentication and Authorization of P2P TCs by the 5.1.4. PTP: Authentication and Authorization of P2P TCs by the
Master ................................................... 17 Master ................................................... 17
5.1.5. PTP: Authentication and Authorization of Control 5.1.5. PTP: Authentication and Authorization of Control
Messages ................................................. 18 Messages ................................................. 18
5.2. Protocol Packet Integrity .............................. 19 5.2. Protocol Packet Integrity .............................. 19
5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 20
5.2.1.1. Hop-by-Hop Integrity Protection .............. 19 5.2.1.1. Hop-by-Hop Integrity Protection .............. 20
5.2.1.2. End-to-End Integrity Protection .............. 20 5.2.1.2. End-to-End Integrity Protection .............. 20
5.3. Spoofing Prevention .................................... 20 5.3. Spoofing Prevention .................................... 21
5.4. Availability ........................................... 21 5.4. Availability ........................................... 22
5.5. Replay Protection ...................................... 22 5.5. Replay Protection ...................................... 22
5.6. Cryptographic Keys and Security Associations ........... 22 5.6. Cryptographic Keys and Security Associations ........... 23
5.6.1. Key Freshness ..................................... 22 5.6.1. Key Freshness ..................................... 23
5.6.2. Security Association .............................. 23 5.6.2. Security Association .............................. 23
5.6.3. Unicast and Multicast Associations ................ 24 5.6.3. Unicast and Multicast Associations ................ 24
5.7. Performance ............................................ 24 5.7. Performance ............................................ 25
5.8. Confidentiality......................................... 25 5.8. Confidentiality......................................... 26
5.9. Protection against Packet Delay and Interception Attacks 26 5.9. Protection against Packet Delay and Interception Attacks 26
5.10. Combining Secured with Unsecured Nodes ................ 27 5.10. Combining Secured with Unsecured Nodes ................ 27
5.10.1. Secure Mode ...................................... 27 5.10.1. Secure Mode ...................................... 27
5.10.2. Hybrid Mode ...................................... 27 5.10.2. Hybrid Mode ...................................... 28
6. Summary of Requirements ..................................... 28 6. Summary of Requirements ..................................... 29
7. Additional security implications ............................ 30 7. Additional security implications ............................ 30
7.1. Security and on-the-fly Timestamping ................... 30 7.1. Security and on-the-fly Timestamping ................... 31
7.2. PTP: Security and Two-Step Timestamping ................ 30 7.2. PTP: Security and Two-Step Timestamping ................ 31
7.3. Intermediate Clocks .................................... 31 7.3. Intermediate Clocks .................................... 31
7.4. External Security Protocols and Time Protocols.......... 32 7.4. External Security Protocols and Time Protocols.......... 32
7.5. External Security Services Requiring Time .............. 32 7.5. External Security Services Requiring Time .............. 33
7.5.1. Timestamped Certificates .......................... 32 7.5.1. Timestamped Certificates .......................... 33
7.5.2. Time Changes and Replay Attacks ................... 33 7.5.2. Time Changes and Replay Attacks ................... 33
8. Issues for Further Discussion ............................... 33 8. Issues for Further Discussion ............................... 33
9. Security Considerations ..................................... 33 9. Security Considerations ..................................... 34
10. IANA Considerations......................................... 33 10. IANA Considerations......................................... 34
11. Acknowledgments ............................................ 33 11. Acknowledgments ............................................ 34
12. References ................................................. 33 12. References ................................................. 34
12.1. Normative References .................................. 33 12.1. Normative References .................................. 34
12.2. Informative References ................................ 34 12.2. Informative References ................................ 34
13. Contributing Authors ....................................... 35 13. Contributing Authors ....................................... 36
1. Introduction 1. Introduction
As time protocols are becoming increasingly common and widely As time protocols are becoming increasingly common and widely
deployed, concern about the resulting exposure to various security deployed, concern about the resulting exposure to various security
threats is increasing. If a time protocol is compromised, the threats is increasing. If a time protocol is compromised, the
applications it serves are prone to a range of possible attacks applications it serves are prone to a range of possible attacks
including Denial-of-Service (DoS) or incorrect behavior. including Denial-of-Service (DoS) or incorrect behavior.
This document discusses the security aspects of time distribution This document discusses the security aspects of time distribution
skipping to change at page 6, line 28 skipping to change at page 6, line 28
o Clock - A node participating in the protocol (either PTP or NTP). o Clock - A node participating in the protocol (either PTP or NTP).
A clock can be a master, a slave, or an intermediate clock (see A clock can be a master, a slave, or an intermediate clock (see
corresponding definitions below). corresponding definitions below).
o Control packets - Packets used by the protocol to exchange o Control packets - Packets used by the protocol to exchange
information between clocks that is not strictly related to the information between clocks that is not strictly related to the
time. NTP uses NTP Control Messages. PTP uses Announce, Signaling time. NTP uses NTP Control Messages. PTP uses Announce, Signaling
and Management messages. and Management messages.
o End-to-end security - A security approach where secured packets o End-to-end security - A security approach where secured packets
sent from a source to a destination is not modified by sent from a source to a destination are not modified by
intermediate nodes. intermediate nodes, allowing the destination to authenticate the
source of the packets, and to verify their integrity.
In the context of confidentiality, end-to-end encryption
guarantees that intermediate nodes cannot eavesdrop to en-route
packets. However, as discussed in Section 5. , confidentiality is
not a strict requirement in this document.
o Grandmaster - A master that receives time information from a o Grandmaster - A master that receives time information from a
locally attached clock device, and not through the network. A locally attached clock device, and not through the network. A
grandmaster distributes its time to other clocks in the network. grandmaster distributes its time to other clocks in the network.
o Hop-by-hop security - A security approach where secured packets o Hop-by-hop security - A security approach where secured packets
sent from a source to a destination may be modified by sent from a source to a destination may be modified by
intermediate nodes. In this approach intermediate nodes share the intermediate nodes. In this approach intermediate nodes share the
encryption key with the source and destination, allowing them to encryption key with the source and destination, allowing them to
re-encrypt or re-authenticate modified packets before relaying re-encrypt or re-authenticate modified packets before relaying
skipping to change at page 7, line 33 skipping to change at page 7, line 33
o Unsecured clock - A clock that does not support a security o Unsecured clock - A clock that does not support a security
mechanism according to the requirements in this document. mechanism according to the requirements in this document.
3. Security Threats 3. Security Threats
This section discusses the possible attacker types and analyzes This section discusses the possible attacker types and analyzes
various attacks against time protocols. various attacks against time protocols.
The literature is rich with security threats of time protocols, e.g., The literature is rich with security threats of time protocols, e.g.,
[Traps], [AutoKey], [TM], [SecPTP], and [SecSen]. The threat analysis [Traps], [AutoKey], [TimeSec], [SecPTP], and [SecSen]. The threat
in this document is mostly based on [TM]. analysis in this document is mostly based on [TimeSec].
3.1. Threat Model 3.1. Threat Model
A time protocol can be attacked by various types of attackers. A time protocol can be attacked by various types of attackers.
The analysis in this document classifies attackers according to 2 The analysis in this document classifies attackers according to 2
criteria, as described in Section 3.1.1. and Section 3.1.2. criteria, as described in Section 3.1.1. and Section 3.1.2.
3.1.1. Internal vs. External Attackers 3.1.1. Internal vs. External Attackers
skipping to change at page 11, line 22 skipping to change at page 11, line 22
grandmaster. For example, if the grandmaster uses a GPS based clock grandmaster. For example, if the grandmaster uses a GPS based clock
as its reference source, an attacker can jam the reception of the GPS as its reference source, an attacker can jam the reception of the GPS
signal, or transmit a signal similar to one from a GPS satellite, signal, or transmit a signal similar to one from a GPS satellite,
causing the grandmaster to use a false reference time. causing the grandmaster to use a false reference time.
Note that this attack is outside the scope of the time protocol. Note that this attack is outside the scope of the time protocol.
While various security measures can be taken to mitigate this attack, While various security measures can be taken to mitigate this attack,
these measures are outside the scope of the security requirements these measures are outside the scope of the security requirements
defined in this document. defined in this document.
3.2.11. Exploiting Vulnerabilities in the Time Protocol
Time protocols can be attacked by exploiting vulnerabilities in the
protocol, implementation bugs, or misconfigurations (e.g.,
[NTPDDoS]). It should be noted that such attacks cannot typically be
mitigated by security mechanisms. However, when a new vulnerability
is discovered, operators should react as soon as possible, and take
the necessary measures to address it.
3.2.12. Network Reconnaissance
An attacker can exploit the time protocol to collect information such
as addresses and locations of nodes that take part in the protocol.
Reconnaissance can be applied either by passively eavesdropping to
protocol packets, or by sending malicious packets and gathering
information from the responses. By eavesdropping to a time protocol,
an attacker can learn the network latencies, which provide
information about the network topology and node locations.
Moreover, properties such as the frequency of the protocol packets,
or the exact times at which they are sent can allow fingerprinting of
specific nodes; thus, protocol packets from a node can be identified
even if network addresses are hidden or encrypted.
3.3. Threat Analysis Summary 3.3. Threat Analysis Summary
The two key factors to a threat analysis are the impact and the The two key factors to a threat analysis are the impact and the
likelihood of each of the analyzed attacks. likelihood of each of the analyzed attacks.
Table 1 summarizes the security attacks presented in Section 3.2. Table 1 summarizes the security attacks presented in Section 3.2.
For each attack, the table specifies its impact, and its For each attack, the table specifies its impact, and its
applicability to each of the attacker types presented in Section 3.1. applicability to each of the attacker types presented in Section 3.1.
Table 1 clearly shows the distinction between external and internal Table 1 clearly shows the distinction between external and internal
skipping to change at page 22, line 46 skipping to change at page 23, line 28
and availability of the protocol. Common encryption and and availability of the protocol. Common encryption and
authentication mechanisms include replay prevention mechanisms that authentication mechanisms include replay prevention mechanisms that
typically use a monotonously increasing packet sequence number. typically use a monotonously increasing packet sequence number.
5.6. Cryptographic Keys and Security Associations 5.6. Cryptographic Keys and Security Associations
5.6.1. Key Freshness 5.6.1. Key Freshness
Requirement Requirement
The security mechanism MUST provide a means to refresh the
cryptographic keys.
The cryptographic keys MUST be refreshed frequently. The cryptographic keys MUST be refreshed frequently.
Requirement Level Requirement Level
The requirement level of this requirement is 'MUST' since key The requirement level of this requirement is 'MUST' since key
freshness is an essential property for cryptographic algorithms, as freshness is an essential property for cryptographic algorithms, as
discussed below. discussed below.
Discussion Discussion
Key freshness guarantees that both sides share a common updated Key freshness guarantees that both sides share a common updated
secret key. It also helps in preventing replay attacks. Thus, it is secret key. It also helps in preventing replay attacks. Thus, it is
important for keys to be refreshed frequently. Note that the term important for keys to be refreshed frequently. Note that the term
'frequently' is used without a quantitative requirement, as the 'frequently' is used without a quantitative requirement, as the
skipping to change at page 25, line 31 skipping to change at page 26, line 14
5.8. Confidentiality 5.8. Confidentiality
Requirement Requirement
The security mechanism MAY provide confidentiality protection of the The security mechanism MAY provide confidentiality protection of the
protocol packets. protocol packets.
Requirement Level Requirement Level
The requirement level of this requirement is 'MAY' since it does not The requirement level of this requirement is 'MAY' since the absence
prevent severe threats, as discussed below. of this requirement does not expose the protocol to severe threats,
as discussed below.
Discussion Discussion
In the context of time protocols, confidentiality is typically of low In the context of time protocols, confidentiality is typically of low
importance, since timing information is typically not considered importance, since timing information is typically not considered
secret information. secret information.
Confidentiality can play an important role when service providers Confidentiality can play an important role when service providers
charge their customers for time synchronization services, and thus an charge their customers for time synchronization services, and thus an
encryption mechanism can prevent eavesdroppers from obtaining the encryption mechanism can prevent eavesdroppers from obtaining the
skipping to change at page 32, line 49 skipping to change at page 33, line 24
Cryptographic protocols often use time as an important factor in the Cryptographic protocols often use time as an important factor in the
cryptographic algorithm. If a time protocol is compromised, it may cryptographic algorithm. If a time protocol is compromised, it may
consequently expose the security protocols that rely on it to various consequently expose the security protocols that rely on it to various
attacks. Two examples are presented in this section. attacks. Two examples are presented in this section.
7.5.1. Timestamped Certificates 7.5.1. Timestamped Certificates
Certificate validation requires the sender and receiver to be roughly Certificate validation requires the sender and receiver to be roughly
time synchronized. Thus, synchronization is required for establishing time synchronized. Thus, synchronization is required for establishing
security protocols such as IKEv2 and TLS. security protocols such as IKEv2 and TLS. Other authentication and
key exchange mechanisms, such as Kerberos, also require the parties
involved to be synchronized [Kerb].
An even stronger interdependence between a time protocol and a An even stronger interdependence between a time protocol and a
security mechanism is defined in [AutoKey], which defines mutual security mechanism is defined in [AutoKey], which defines mutual
dependence between the acquired time information, and the dependence between the acquired time information, and the
authentication protocol that secures it. This bootstrapping behavior authentication protocol that secures it. This bootstrapping behavior
results from the fact that trusting the received time information results from the fact that trusting the received time information
requires a valid certificate, and validating a certificate requires requires a valid certificate, and validating a certificate requires
knowledge of the time. knowledge of the time.
7.5.2. Time Changes and Replay Attacks 7.5.2. Time Changes and Replay Attacks
skipping to change at page 33, line 39 skipping to change at page 34, line 18
throughout this document. throughout this document.
10. IANA Considerations 10. IANA Considerations
There are no new IANA considerations implied by this document. There are no new IANA considerations implied by this document.
11. Acknowledgments 11. Acknowledgments
The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, The authors gratefully acknowledge Stefano Ruffini, Doug Arnold,
Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell
Smiley, and Shawn Emery for their thorough review and helpful Smiley, Shawn Emery, Dan Romascanu, Stephen Farrell, Kathleen
Moriarty, and Joel Jaeggli for their thorough review and helpful
comments. The authors would also like to thank members of the TICTOC comments. The authors would also like to thank members of the TICTOC
WG for providing feedback on the TICTOC mailing list. WG for providing feedback on the TICTOC mailing list.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
12. References 12. References
12.1. Normative References 12.1. Normative References
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
"1588 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems Version 2", IEEE Standard, 2008.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
12.2. Informative References 12.2. Informative References
[1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec
tunnels - An analysis", in Proceedings of 2010 tunnels - An analysis", in Proceedings of 2010
International Symposium for Precision Clock International Symposium for Precision Clock
Synchronization for Measurement, Control and Synchronization for Measurement, Control and
Communication, ISPCS 2010, pp. 83-90, 2010. Communication, ISPCS 2010, pp. 83-90, 2010.
[3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved
Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in
skipping to change at page 34, line 38 skipping to change at page 35, line 26
Attacks against Time Synchronization Protocols", Attacks against Time Synchronization Protocols",
accepted, to appear in Proceedings of the accepted, to appear in Proceedings of the
International IEEE Symposium on Precision Clock International IEEE Symposium on Precision Clock
Synchronization for Measurement, Control and Synchronization for Measurement, Control and
Communication, ISPCS, 2012. Communication, ISPCS, 2012.
[Hack] S. McClure, J. Scambray, G. Kurtz, Kurtz, "Hacking [Hack] S. McClure, J. Scambray, G. Kurtz, Kurtz, "Hacking
exposed: network security secrets and solutions", exposed: network security secrets and solutions",
McGraw-Hill, 2009. McGraw-Hill, 2009.
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
"1588 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems Version 2", IEEE Standard, 2008.
[IPsec] S. Kent, K. Seo, "Security Architecture for the [IPsec] S. Kent, K. Seo, "Security Architecture for the
Internet Protocol", IETF, RFC 4301, 2005. Internet Protocol", IETF, RFC 4301, 2005.
[IPsecSync] Y. Xu, "IPsec security for packet based [IPsecSync] Y. Xu, "IPsec security for packet based
synchronization", IETF, draft-xu-tictoc-ipsec- synchronization", IETF, draft-xu-tictoc-ipsec-
security-for-synchronization (work in progress), 2011. security-for-synchronization (work in progress), 2011.
[Kerb] S. Sakane, K. Kamada, M. Thomas, J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)",
2006.
[MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and [MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and
Metropolitan Area Networks - Media Access Control Metropolitan Area Networks - Media Access Control
(MAC) Security", 2006. (MAC) Security", 2006.
[NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., [NTPDDoS] "Attackers use NTP reflection in huge DDoS attack",
"Network Time Protocol Version 4: Protocol and TICTOC mail archive, 2014.
Algorithms Specification", RFC 5905, June 2010.
[SecPTP] J. Tsang, K. Beznosov, "A security analysis of the [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the
precise time protocol (short paper)," 8th precise time protocol (short paper)," 8th
International Conference on Information and International Conference on Information and
Communication Security (ICICS 2006), pp. 50-59, 2006. Communication Security (ICICS 2006), pp. 50-59, 2006.
[SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava,
"Secure Time Synchronization in Sensor Networks", ACM "Secure Time Synchronization in Sensor Networks", ACM
Trans. Info. and Sys. Sec., Volume 11, Issue 4, July Trans. Info. and Sys. Sec., Volume 11, Issue 4, July
2008. 2008.
[TM] T. Mizrahi, "Time synchronization security using IPsec [TimeSec] T. Mizrahi, "Time synchronization security using IPsec
and MACsec", ISPCS 2011, pp. 38-43, 2011. and MACsec", ISPCS 2011, pp. 38-43, 2011.
[Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R.,
"Traps and pitfalls in secure clock synchronization" "Traps and pitfalls in secure clock synchronization"
in Proceedings of 2007 International Symposium for in Proceedings of 2007 International Symposium for
Precision Clock Synchronization for Measurement, Precision Clock Synchronization for Measurement,
Control and Communication, ISPCS 2007, pp. 18-24, Control and Communication, ISPCS 2007, pp. 18-24,
2007. 2007.
[Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure
 End of changes. 29 change blocks. 
43 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/