idnits 2.17.1 draft-ogud-dhc-udp-time-option-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 -- The document date (December 01, 2013) is 3799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4034' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 260, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC, 6MAN O. Gudmundsson 3 Internet-Draft Shinkuro Inc. 4 Intended status: Informational December 01, 2013 5 Expires: June 04, 2014 7 Providing Time over DHCP and ND for devices w/o reliable clock upon boot 8 draft-ogud-dhc-udp-time-option-01 10 Abstract 12 Many small inexpensive computing devices like home routers, Rasberry 13 Pi etc. do not have a battery to allow clock chip to keep track of 14 time, thus the systems have no idea what the current time is upon 15 boot. Number of modern services take Time Synchronization for 16 granted, but operating systems do not allow the start of these 17 services to be deferred until after accurate clock has been 18 confirmed. 20 NTP provides accurate fine grain clock synchronization but in order 21 for NTP to succeed DNS needs to work. DNSSEC resolvers will fail if 22 system clock is off by more than little bit. This draft proposes a 23 mechanism to offer "reasonable" current time to devices upon boot via 24 DHCP, DHCPv6 and ND. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 04, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Why knowing time is getting more important . . . . . . . 3 62 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. Current Time options . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Option allocations . . . . . . . . . . . . . . . . . . . 4 65 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. DHCP Current Time option . . . . . . . . . . . . . . . . 4 67 3.2. DHCPv6 Current Time option . . . . . . . . . . . . . . . 4 68 3.3. Neighbor Discovery option . . . . . . . . . . . . . . . . 5 69 4. Security considerations . . . . . . . . . . . . . . . . . . . 5 70 5. Internationalizaiton Considerations . . . . . . . . . . . . . 5 71 6. Implementation Experience . . . . . . . . . . . . . . . . . . 5 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 7.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Appendix A. Document history . . . . . . . . . . . . . . . . . . 6 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 Many applications and protocols take it for granted that the system 81 clock is "correct". Applications that perform validity checks 82 against time stamps will in many cases fail if the system time is far 83 enough off. Many smaller less expensive systems that are deployed 84 into homes/offices do not have reliable cocks and/or battery backup 85 thus do not have neither accurate nor rough sense of time when 86 booting. Examples of such devices are Home/Office Gateways/Routers, 87 Entertainment Systems, Rasberry Pie development boards, etc. in these 88 case the cost of adding good clock chip and battery power source for 89 it is deemed to high. Same goes for systems where battery has run 90 out of juice, or are booting after few weeks or moths of inactivity. 92 This draft proposes to use an new DHCPv4 and v6 options to provide 93 rough current time, the draft also proposes an identical RA option 94 for IPv6 environments that use auto configuration. 96 1.1. Why knowing time is getting more important 98 Applications and services that use time are getting more and more 99 important, in particular when validating if servers are offering good 100 credentials. 102 For example DNS [RFC1034] is being deployed widely in resolvers with 103 DNSSEC validation [RFC4033] DNSSEC signatures rarely have signature 104 lifetime of more than one month and in some cases few hours. 106 Most devices use NTP [RFC5905] to correct the clock on the device and 107 maintain time. NTP servers are located via DNS look-ups. If the 108 device is performing DNSSEC resolution and/or validation of answers, 109 then NTP server lookups succeed if the system clock has rough idea of 110 current time otherwise DNSSEC signatures fail temporal validation 111 checks. This leads to a deadlock NTP can only function if DNS is 112 functioning and DNSSEC can only function if NTP is working. 114 Any protocol that checks certificates for correctness also depends on 115 correct time has potentially the same false-negative behavior before 116 time synchronization completes. 118 This proposal also helps in the cases when NTP servers are not 119 reachable. This is not a replacement for NTP just an aid at boot 120 time. 122 1.2. Requirements notation 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Current Time options 130 Many of the devices that boot without accurate clock get their IPv4 131 addresses from DHCP [RFC2131] [RFC3315] servers, it is natural to 132 allow those DHCP clients to query the server for what time it is, if 133 they choose to do so. Currently this is not specified. 135 DHCP provides an option for clients to ask about NTP servers, the 136 answer is a DNS FQDN that requires DNS resolution to work. 138 On networks that use IPv6 autoconfiguration Neighbor Discovery 139 [RFC4861] options can be used to provide the same service. 141 These option(s) are designed to provide "rough" time not accurate 142 time, NTP MUST be used by clients when available to get accurate 143 time. 145 Entities that provide Current-Time answers SHOULD return time that is 146 within 10 minutes of current time. 148 2.1. Option allocations 150 All the options defined below are fixed size options of 8 bytes/64 151 bits, the value returned is a 64-bit POSIX time_t in network byte 152 order. The time returned is always in UTC. 154 "Current Time" DHCP IPv4 option code is TBD1 see section Section 3.1 156 DHCPv6 OPTION_CURRENT_TIME DHCPv6 code is TBD2 see section 157 Section 3.2. 159 ND "Current Time Option" code is TBD3 see Section 3.3. 161 3. IANA considerations 163 3.1. DHCP Current Time option 165 IANA is requested to make an allocation of an option code in the DHCP 166 registry named "Dynamic Host Configuration Protocol (DHCP) and 167 Bootstrap Protocol (BOOTP) Parameters", sub registry "BOOTP Vendor 168 Extensions and DHCP Options". The registration entry is: 170 Tag = TBD1; 171 Name = "Current Time "; 172 Data Length = 8 ; 173 Meaning = "Rough Current time" ; 174 Reference = "[This-document]"; 176 3.2. DHCPv6 Current Time option 178 IANA is requested to make an allocation of an option code in the DHCP 179 registry named "Dynamic Host Configuration Protocol for IPv6 180 (DHCPv6)" sub-registry "DHCP Option Codes". The registered entry is: 182 Value = TBD2; 183 Description = "OPTION_CURRENT_TIME"; 184 Reference= "[This-document]"; 186 3.3. Neighbor Discovery option 188 IANA is requested to make an allocation of an option in the "Internet 189 Control Message Protocol version 6 (ICMPv6) Parameters" sub-registry 190 "IPv6 Neighbor Discovery Option Formats" 192 Type = TBD3 193 Description = "Current time option" 194 Reference = "[This document]" 196 4. Security considerations 198 Devices that have alternate means to get accurate current time via 199 Radio signals etc. SHOULD NOT use the options specified in this 200 document. 202 DHCP and ND clients with dynamic address currently depend on "address 203 provider" for getting decent IP address. The client is totally 204 dependent on the "address provider" to tell it where to find DNS 205 resolvers that the client can use to locate other services such as 206 NTP. Having a client accept a "current time" from the "address 207 provider" server when the client does not have accurate time, does 208 not put the client in any worse state than not knowing the current 209 time. The onus is on the client configuration to know if the "system 210 time" at boot is reasonable, and when it is not, then use the options 211 specified above to get "better" guess of time. 213 The alternative to having "address provision" protocols provide time 214 upon request is that the client devices/operating systems become 215 aware that certain capabilities/services can not be enabled until NTP 216 has successfully executed. For example in our work on home routers 217 using Unbound DNS resolver we start the resolver in recursive mode 218 only, once time is accurate and path has been shown to pass DNSSEC 219 records through, unbound resolution mode is changed to validating. 221 5. Internationalizaiton Considerations 223 NONE 225 6. Implementation Experience 227 This document is motivated by deploying validating resolvers on a 228 home routers without accurate clocks. 230 7. References 231 7.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 237 2131, March 1997. 239 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 240 and M. Carney, "Dynamic Host Configuration Protocol for 241 IPv6 (DHCPv6)", RFC 3315, July 2003. 243 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 244 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 245 September 2007. 247 7.2. Informative References 249 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 250 STD 13, RFC 1034, November 1987. 252 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 253 Rose, "DNS Security Introduction and Requirements", RFC 254 4033, March 2005. 256 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 257 Rose, "Resource Records for the DNS Security Extensions", 258 RFC 4034, March 2005. 260 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 261 Rose, "Protocol Modifications for the DNS Security 262 Extensions", RFC 4035, March 2005. 264 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 265 Time Protocol Version 4: Protocol and Algorithms 266 Specification", RFC 5905, June 2010. 268 Appendix A. Document history 270 [RFC Editor: Please remove this section before publication ] 272 00 Initial version 274 01 Changed document to use a new 64 bit DHCPv4 option, added DHCPv6 275 option and ND option. Deleted references to Bulk Query, reworked 276 security considerations. 278 Author's Address 280 Olafur Gudmundsson 281 Shinkuro Inc. 282 4922 Fairmont Av, Suite 250 283 Bethesda, MD 20814 284 USA 286 Email: ogud@ogud.com