Providing Time over DHCP for devices w/o reliable clock upon boot
draft-ogud-dhc-udp-time-option-00

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]