idnits 2.17.1 draft-stenn-ntp-suggest-refid-04.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 abstract seems to contain references ([RFC5905]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2018) is 2031 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) == Unused Reference: 'RFC7384' is defined on line 229, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7384 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Stenn 3 Internet-Draft Network Time Foundation 4 Intended status: Standards Track October 3, 2018 5 Expires: April 6, 2019 7 Network Time Protocol Suggest REFID Extension Field 8 draft-stenn-ntp-suggest-refid-04 10 Abstract 12 NTP has been widely used through several revisions, with the latest 13 being RFC 5905 [RFC5905]. A core component of the protocol and the 14 algorithms is the Reference ID, or REFID, which is used to identify 15 the source of time used for synchronization. Traditionally, when the 16 source of time was another system the REFID was the IPv4 address of 17 that other system. The core purpose of the REFID is to prevent a 18 one-degree timing loop, where if A has several timing sources that 19 include B, if B decides to get its time from A we don't want A then 20 deciding to get its time from B. The REFID is considered to be 21 "public data" and is a vital core-component of the base NTP packet. 22 If a system's REFID is the IPv4 address of its system peer, an 23 attacker can try to use that information to send spoofed time packets 24 to either or both the target or the target's server, attempting to 25 cause a disruption in time service. This proposal is a backward- 26 compatible way for a time source to tell its peers or clients "If you 27 use me as your system peer, use this nonce as your REFID." This 28 nonce SHOULD be untraceable to the original system, and if it is used 29 as the REFID this type of attack is prevented. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 6, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 2. The REFID . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. The Suggested REFID Extension Field . . . . . . . . . . . . . 3 69 4. Generating and Sending the Suggested REFID Extension Field . 4 70 5. Receiving a Suggested REFID Extension Field . . . . . . . . . 5 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 NTP has been widely used through several revisions, with the latest 80 being RFC 5905 [RFC5905]. A core component of the protocol and the 81 algorithms is the Reference ID, or REFID, which is used to identify 82 the source of time used for synchronization. Traditionally, when the 83 source of time was another system, the REFID was the IPv4 address of 84 that other system. If the remote system was using IPv6 for its 85 connection, a 4 octet digest value of the IPv6 address was used. The 86 purpose of the REFID is to prevent a one-degree timing loop, where if 87 A has several timing sources that include B, if B decides to get its 88 time from A we don't want A then deciding to get its time from B. 89 The REFID is considered to be "public data" and is a vital core- 90 component of the base NTP packet. If a system's REFID is the IPv4 91 address of its system peer, an attacker can try to use that 92 information to send spoofed time packets to either or both the target 93 or the target's server, attempting to cause a disruption in time 94 service. This proposal is a backward-compatible way for a time 95 source to tell its peers or clients "If you use me as your system 96 peer, use this nonce as your REFID." This nonce, a Suggested REFID, 97 SHOULD be untraceable to the sending system. If the receiving system 98 uses this Suggested REFID nonce instead of the IPv4 address as its 99 REFID, this type of attack and information disclosure is prevented. 101 The NTP protocol was designed with a mechanism that allowed for a 102 depth-1 loop detection to avoid a simple "time loop". Recently, this 103 mechanism was discovered to be a potential vulnerability exploit. 104 The best way to mitigate this vulnerability is to decouple the IPv4 105 address of the server from its REFID. But there is no current way 106 for a potential time source to tell the other party any other 107 alternative to use as the REFID. This proposal creates an extension 108 field to accomplish this. 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. The REFID 118 The core reason for the REFID in the NTP Protocol is to prevent a 119 timing loop of degree 1. Put another way, if servers A and B are 120 exchanging time with each other and server B decides to follow A as 121 its system peer, the REFID that B will use must be able to identify 122 server A. The interpretation of a REFID is based on the stratum, as 123 documented in RFC 5905 [RFC5905], section 7.3, "Packet Header 124 Variables". At Stratum 2+, which will be the case if servers A and B 125 are exchanging packets over IPv4, if server B follows A, then B will 126 have A's IPv4 address as its REFID. When A asks B for its time, A 127 will see that B is synchronized to A because B will tell A that its 128 REFID is A's IPv4 address, so when A sees its IP address as B's 129 REFID, A knows that if it were to follow B for its time then there 130 would be a timing loop. In this case, A will not select B as a 131 potential source of time. 133 3. The Suggested REFID Extension Field 135 Since there is no way in the base NTP packet for "this" instance of 136 an NTP server to tell the "other" instance what REFID it should use 137 if the "other" instance decides to use "this" instance as its system 138 peer, the best available way to convey this information is via an 139 extension field. 141 0 1 2 3 142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 143 +---------------+---------------+-------------------------------+ 144 | Field Type | Field Length | 145 +-------------------------------+-------------------------------+ 146 | Suggested REFID | 147 +---------------------------------------------------------------+ 149 NTP Extension Field: REFID Suggestion 151 Field Type: TBD (Recommendation for IANA: 0x0006 (Suggested REFID)) 153 Field Length: 0x0008 155 Suggested REFID: The 4 octets of the suggested REFID. This value 156 SHOULD be 0xFDxxxxxx, where the bottom 3 octets SHOULD be random 157 values. 159 Examples: When decoded as an IPv4 address, suggested REFIDs would 160 decode as 253.0.0.0 thru 253.255.255.255. 162 4. Generating and Sending the Suggested REFID Extension Field 164 A system that decides to send a Suggested REFID extension field 165 SHOULD generate a new Suggested REFID for each new association. It 166 MAY generate a new Suggested REFID for any association in any 167 response. In addition to remembering the IP-based REFID, the sender 168 MUST also remember its most-recent Suggested REFID. 170 Since the core NTPv4 and earlier protocols do not contain any way to 171 tell the recipient what to use as a REFID and RFC 5905 [RFC5905] uses 172 the IPv4 address of the sender as the REFID if the association is 173 effected over an IPv4 connection, this means that an attacker can 174 simply send an NTP client request to a server knowing that server's 175 system peer will be returned as the REFID in the response packet. At 176 this point, an attacker can, if that REFID is an IPv4 address, begin 177 to launch attacks at the target forging the putative IP of the 178 target's time source, or the attacker can start forging packets to 179 the putative time server claiming to be from the target, in an 180 attempt to cause the time server to limit or deny time service to the 181 target. 183 Using a nonce for the REFID that is only recognized by the sending 184 machine effectively prevents this type of attack. 186 If servers S1, S2, and S3 are all exchanging time with each other and 187 are all using the Suggested REFID mechanism, there is a 3 in 188 16,777,216 (2^24) chance that two different servers in the same group 189 will happen to choose the same nonce, and that would produce a false- 190 positive timing loop detection. If the Suggested REFID is never 191 changed, this false-positive condition will occur for potentially a 192 long time. This small risk can be reduced by periodically generating 193 a new Suggested REFID. 195 5. Receiving a Suggested REFID Extension Field 197 An NTP server keeps track of the IP address it uses to talk to a 198 client. If an NTP server chooses to send a Suggested REFID to an 199 association, it MUST remember this value. When checking for a timing 200 loop, the Suggested REFID must also be included in the list of tested 201 REFID values. 203 6. Acknowledgements 205 The author wishes to acknowledge the contributions of Martin Burnicki 206 and Sam Weiler. 208 7. IANA Considerations 210 This memo requests IANA to allocate NTP Extension Field Type 0x0006 211 (Suggested REFID) for this proposal. 213 8. Security Considerations 215 Additional information TBD 217 9. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, 221 DOI 10.17487/RFC2119, March 1997, 222 . 224 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 225 "Network Time Protocol Version 4: Protocol and Algorithms 226 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 227 . 229 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 230 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 231 October 2014, . 233 Author's Address 235 Harlan Stenn 236 Network Time Foundation 237 P.O. Box 918 238 Talent, OR 97540 239 US 241 Email: stenn@nwtime.org