idnits 2.17.1 draft-mlichvar-ntp-over-ptp-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jun 24, 2021) is 1037 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Lichvar 3 Internet-Draft Red Hat 4 Intended status: Standards Track Jun 24, 2021 5 Expires: December 26, 2021 7 NTP Over PTP 8 draft-mlichvar-ntp-over-ptp-00 10 Abstract 12 This document specifies a transport for the Network Time Protocol 13 (NTP) client-server mode using the Precision Time Protocol (PTP) to 14 enable hardware timestamping on hardware that can timestamp PTP 15 messages but not NTP messages. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 26, 2021. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The Precision Time Protocol (PTP) [IEEE1588] was designed for highly 52 accurate synchronization of clocks in a network. It relies on 53 hardware timestamping supported in network devices (e.g. interface 54 controllers, switches, and routers) to eliminate the impact of 55 processing and queueing delays on PTP measurements. 57 PTP was originally designed for multicast communication. Later was 58 added a unicast mode, which can be used in larger networks with 59 partial on-path PTP support (e.g. telecom profiles G.8265.1 and 60 G.8275.2). 62 The Network Time Protocol [RFC5905] does not rely on hardware 63 timestamping support, but implementations can use it if it is 64 available to avoid the impact of processing and queueing delays, 65 similarly to PTP. The client-server mode of NTP is functionally 66 similar to the PTP unicast mode. 68 An issue for NTP is hardware that can specifically timestamp only PTP 69 packets. This limitation comes from their design, which does not 70 allow the timestamps to be captured or retrieved at the same rate as 71 packets can be received or transmitted. A filter needs to be 72 implemented in the hardware to inspect each packet and timestamp only 73 those that actually need it. The filter can be usually configured 74 for the PTP transport (e.g. UDPv4, UDPv6, 802.3) and sometimes even 75 the message type (e.g. sync message or delay request) to further 76 reduce the rate of timestamps on the server or client side. This 77 limitation prevents hardware timestamping of NTP messages. It also 78 prevents timestamping of PTP messages if they are secured at the 79 transport layer or below (e.g. IPSec or MACSec). 81 This document specifies a new transport for NTP to enable the PTP- 82 specific timestamping support. It adds a new extension field (TLV) 83 for PTP to contain NTP messages. 85 NTP over PTP does not disrupt normal operation of PTP. A network and 86 even a single host can support both at the same time. 88 The specification does not take advantage of the PTP correctionField 89 modified by PTP transparent clocks as their support for the unicast 90 mode seems to be rare or nonexistent. 92 The client/server mode of NTP, even if using the PTP transport, has 93 several advantages when compared to the PTP unicast mode: 95 o It is more secure. It can use existing security mechanisms 96 specified for NTP like Network Time Security [RFC8915], not losing 97 any of its features. The PTP unicast mode allows an almost- 98 infinite traffic amplification, which can be exploited for denial- 99 of-service attacks and can only be limited by security mechanisms 100 using client authentication. 102 o It needs fewer messages and less network bandwith to get the same 103 number of timestamps. 105 o It is better suited for synchronization in networks without full 106 on-path support. It does not assume the network delay is constant 107 and the number of measurements in opposite directions is symmetric 108 (in PTP sync messages and delay requests have independent timing). 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. PTP transport for NTP 118 A new TLV is defined for PTP to contain NTP messages in the client 119 and server mode. Using other NTP modes in the TLV is not specified. 120 Any transport specified for PTP that supports unicast messaging can 121 be used for NTP over PTP, e.g. UDP on IPv4 and IPv6. 123 The type value of the NTP TLV is TBD. The TLV contains the whole NTP 124 message as would normally be the UDP payload, without any 125 modifications. The TLV does not propagate through boundary clocks. 127 If the UDP transport is used for PTP, the UDP source and destination 128 port numbers MUST be the PTP event port (319). Client port 129 randomization would break the timestamping. 131 The NTP TLV MUST be included in a delay request message. The 132 originTimestamp field and all fields of the header SHOULD be zero, 133 except: 135 o messageType is 1 (delay request) 137 o versionPTP is 2 139 o messageLength is the length of the PTP message including the NTP 140 TLV 142 o domainNumber is TBD 144 o flagField has the unicastFlag bit set 145 An NTP client using the PTP transport sends NTP requests in PTP 146 messages to the server at the same rate as it would normally send 147 them over UDP. 149 A server which supports the NTP TLV MUST check for the domainNumber 150 of TBD and respond to an NTP request with a single PTP message 151 containing the NTP response using the same PTP message format. It 152 MUST NOT send a delay response message. 154 A server which does not support the NTP TLV will not recognize the 155 domain number and ignore the message. If it responded to messages in 156 the domain (e.g. due to misconfiguration), it would send a delay 157 response (to port 320 if using the UDP transport), which would be 158 ignored by the client. 160 Any authenticator fields included in the NTP messages MUST be 161 calculated only over the NTP message following the header of the NTP 162 TLV. 164 Timestamps SHOULD NOT be adjusted for the beginning of the NTP data 165 in the PTP message. They SHOULD still correspond to the ending of 166 the transmission and beginning of the reception (e.g. start of 167 delimiter in the Ethernet frame). 169 Any modifications of the correctionField made by potential one-step 170 end-to-end transparent clocks in the network SHOULD be ignored by the 171 server and client. 173 3. Security Considerations 175 The PTP transport prevents NTP clients from randomizing their source 176 port. It has no other impact on security of NTP. 178 4. References 180 4.1. Normative References 182 [IEEE1588] 183 Institute of Electrical and Electronics Engineers, "IEEE 184 std. 1588-2019, "IEEE Standard for a Precision Clock 185 Synchronization for Networked Measurement and Control 186 Systems."", 11 2019, . 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, 190 DOI 10.17487/RFC2119, March 1997, 191 . 193 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 194 "Network Time Protocol Version 4: Protocol and Algorithms 195 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 196 . 198 4.2. Informative References 200 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 201 Sundblad, "Network Time Security for the Network Time 202 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 203 . 205 Author's Address 207 Miroslav Lichvar 208 Red Hat 209 Purkynova 115 210 Brno 612 00 211 Czech Republic 213 Email: mlichvar@redhat.com