DHC O. Gudmundsson Internet-Draft Shinkuro Inc. Intended status: Informational November 04, 2013 Expires: May 08, 2014 Providing Time over DHCP for devices w/o reliable clock upon boot draft-ogud-dhc-udp-time-option-00 Abstract Many small inexpensive computing devices like home routers, Rasberry Pi etc. do not have a battery thus the systems have no idea what the current time is upon boot. Number of modern services take Time Synchronization for granted, but operating systems do not allow the start of these services to be deferred until after accurate clock has been confirmed. NTP provides accurate fine grain clock synchronization but in order for NTP to succeed DNS needs work. DNSSEC resolvers will fail if system clock is off by more than little bit. This draft proposes a mechanism to offer "reasonable" current time to devices upon boot via DHCP . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on May 08, 2014. Copyright Notice Copyright (c) 2013 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 Gudmundsson Expires May 08, 2014 [Page 1] Internet-Draft DHCP quick and dirty time November 2013 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Why knowing time is getting more important . . . . . . . 3 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. DHC option 152 over UDP . . . . . . . . . . . . . . . . . . . 3 2.1. Protocol change . . . . . . . . . . . . . . . . . . . . . 3 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security considerations . . . . . . . . . . . . . . . . . . . 4 5. Internationalizaiton Considerations . . . . . . . . . . . . . 4 6. Implementation Experience(???) . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Document history . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Many applications and protocols take it for granted that the system clock is "correct". Applications that perform validity checks against time stamps will in many cases fail if the system time is far enough off. Many smaller less expensive systems that are deployed into homes/offices do not have reliable cocks and/or battery backup thus do not have neither accurate nor rough sense of time when booting. Examples of such devices are Home/Office Gateways/Routers, Entertainment Systems, Rasberry Pie development boards, etc. in these case the cost of adding good clock chip and battery power source for it is deemed to high. Same goes for systems where battery has run out of juice. This draft proposes to use an existing DHCP option that is specified for DHCP bulk queries over TCP to be allowed over UDP for such devices to get a rough idea what time it is. Gudmundsson Expires May 08, 2014 [Page 2] Internet-Draft DHCP quick and dirty time November 2013 1.1. Why knowing time is getting more important Applications and services that use time are getting more and more important, in particular in validating if servers are offering good credentials. For example DNS [RFC1034] is being deployed widely in resolvers with DNSSEC validation [RFC4033] DNSSEC signatures rarely have signature lifetime of more than one month and in some cases few hours. Most devices use NTP [RFC5905] to correct the clock on the device and maintain time. NTP servers are located via DNS look-ups. If the device is performing DNSSEC resolution and/or validation of answers then NTP can only find appropriate NTP servers if the system clock has rough idea of time. This leads to a deadlock NTP can only function if DNS is functioning and DNSSEC can only function if NTP is working. Any protocol that checks certificates for correctness also depends on correct time 1.2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. DHC option 152 over UDP Many of the devices that boot without accurate clock get their IPv4 addresses from DHCP servers, it is natural to allow those DHCP clients to query the server for what time it is, if they choose to do so. Currently this is not specified. DHC provides an option for clients to ask about close NTP servers, the answer is a DNS FQDN that requires DNS resolution to work. [RFC6926] defines number of options for use over TCP for multiple options, one of these options is "Base-Time" (option 152) that is number of seconds since epoch (1970/Jan/1 00:00 UTC). This option is unspecified for UDP use. 2.1. Protocol change Option 152 can be requested over UDP and DHCP server SHOULD return a value that is within 10 minutes of current time. Gudmundsson Expires May 08, 2014 [Page 3] Internet-Draft DHCP quick and dirty time November 2013 3. IANA considerations None [RFC Editor: Please remove this section before publication ] 4. Security considerations DHCP clients currently depends on "address provider" for getting decent IP address and frequently telling it where to find resolvers that the client can use to locate other services such as NTP. Having the client accept a "current time" from the DHCP server does not put the client in any worse state than not knowing the current time. For devices that do not have access to DHCP server they are no worse of than today. Other "address provision" protocols such as RA can add similar options. The alternative to having "address provision" protocols provide time upon request is that the client devices/operating systems become aware that certain capabilities/services can not be enabled until NTP has successfully executed. 5. Internationalizaiton Considerations NONE 6. Implementation Experience(???) The authors of RFC6926 told editors of this document that it was about 3 line change in code for Cisco DHCP server to start offering this service. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", RFC 6926, April 2013. Gudmundsson Expires May 08, 2014 [Page 4] Internet-Draft DHCP quick and dirty time November 2013 7.2. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. Appendix A. Document history [RFC Editor: Please remove this section before publication ] 00 Initial version Author's Address Olafur Gudmundsson Shinkuro Inc. 4922 Fairmont Av, Suite 250 Bethesda, MD 20814 USA Email: ogud@ogud.com Gudmundsson Expires May 08, 2014 [Page 5]