Internet DRAFT - draft-ogud-dhc-udp-time-option

draft-ogud-dhc-udp-time-option







DHC, 6MAN                                                 O. Gudmundsson
Internet-Draft                                             Shinkuro Inc.
Intended status: Informational                         December 01, 2013
Expires: June 04, 2014


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

Abstract

   Many small inexpensive computing devices like home routers, Rasberry
   Pi etc. do not have a battery to allow clock chip to keep track of
   time, 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 to 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, DHCPv6 and ND.

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 June 04, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Gudmundsson               Expires June 04, 2014                 [Page 1]

Internet-Draft          DHCP quick and dirty time          December 2013


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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.  Current Time options  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Option allocations  . . . . . . . . . . . . . . . . . . .   4
   3.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  DHCP Current Time option  . . . . . . . . . . . . . . . .   4
     3.2.  DHCPv6 Current Time option  . . . . . . . . . . . . . . .   4
     3.3.  Neighbor Discovery option . . . . . . . . . . . . . . . .   5
   4.  Security considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Internationalizaiton Considerations . . . . . . . . . . . . .   5
   6.  Implementation Experience . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Document history . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

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, or are booting after few weeks or moths of inactivity.

   This draft proposes to use an new DHCPv4 and v6 options to provide
   rough current time, the draft also proposes an identical RA option
   for IPv6 environments that use auto configuration.




Gudmundsson               Expires June 04, 2014                 [Page 2]

Internet-Draft          DHCP quick and dirty time          December 2013


1.1.  Why knowing time is getting more important

   Applications and services that use time are getting more and more
   important, in particular when 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 server lookups succeed if the system clock has rough idea of
   current time otherwise DNSSEC signatures fail temporal validation
   checks.  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 has potentially the same false-negative behavior before
   time synchronization completes.

   This proposal also helps in the cases when NTP servers are not
   reachable.  This is not a replacement for NTP just an aid at boot
   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.  Current Time options

   Many of the devices that boot without accurate clock get their IPv4
   addresses from DHCP [RFC2131] [RFC3315] 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.

   DHCP provides an option for clients to ask about NTP servers, the
   answer is a DNS FQDN that requires DNS resolution to work.

   On networks that use IPv6 autoconfiguration Neighbor Discovery
   [RFC4861] options can be used to provide the same service.

   These option(s) are designed to provide "rough" time not accurate
   time, NTP MUST be used by clients when available to get accurate
   time.



Gudmundsson               Expires June 04, 2014                 [Page 3]

Internet-Draft          DHCP quick and dirty time          December 2013


   Entities that provide Current-Time answers SHOULD return time that is
   within 10 minutes of current time.

2.1.  Option allocations

   All the options defined below are fixed size options of 8 bytes/64
   bits, the value returned is a 64-bit POSIX time_t in network byte
   order.  The time returned is always in UTC.

   "Current Time" DHCP IPv4 option code is TBD1 see section Section 3.1

   DHCPv6 OPTION_CURRENT_TIME DHCPv6 code is TBD2 see section
   Section 3.2.

   ND "Current Time Option" code is TBD3 see Section 3.3.

3.  IANA considerations

3.1.  DHCP Current Time option

   IANA is requested to make an allocation of an option code in the DHCP
   registry named "Dynamic Host Configuration Protocol (DHCP) and
   Bootstrap Protocol (BOOTP) Parameters", sub registry "BOOTP Vendor
   Extensions and DHCP Options".  The registration entry is:

    Tag = TBD1;
    Name = "Current Time ";
    Data Length = 8 ;
    Meaning = "Rough Current time" ;
    Reference = "[This-document]";


3.2.  DHCPv6 Current Time option

   IANA is requested to make an allocation of an option code in the DHCP
   registry named "Dynamic Host Configuration Protocol for IPv6
   (DHCPv6)" sub-registry "DHCP Option Codes".  The registered entry is:

    Value = TBD2;
    Description = "OPTION_CURRENT_TIME";
    Reference= "[This-document]";










Gudmundsson               Expires June 04, 2014                 [Page 4]

Internet-Draft          DHCP quick and dirty time          December 2013


3.3.  Neighbor Discovery option

   IANA is requested to make an allocation of an option in the "Internet
   Control Message Protocol version 6 (ICMPv6) Parameters" sub-registry
   "IPv6 Neighbor Discovery Option Formats"

    Type = TBD3
    Description = "Current time option"
    Reference = "[This document]"


4.  Security considerations

   Devices that have alternate means to get accurate current time via
   Radio signals etc.  SHOULD NOT use the options specified in this
   document.

   DHCP and ND clients with dynamic address currently depend on "address
   provider" for getting decent IP address.  The client is totally
   dependent on the "address provider" to tell it where to find DNS
   resolvers that the client can use to locate other services such as
   NTP.  Having a client accept a "current time" from the "address
   provider" server when the client does not have accurate time, does
   not put the client in any worse state than not knowing the current
   time.  The onus is on the client configuration to know if the "system
   time" at boot is reasonable, and when it is not, then use the options
   specified above to get "better" guess of time.

   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.  For example in our work on home routers
   using Unbound DNS resolver we start the resolver in recursive mode
   only, once time is accurate and path has been shown to pass DNSSEC
   records through, unbound resolution mode is changed to validating.

5.  Internationalizaiton Considerations

   NONE

6.  Implementation Experience

   This document is motivated by deploying validating resolvers on a
   home routers without accurate clocks.

7.  References





Gudmundsson               Expires June 04, 2014                 [Page 5]

Internet-Draft          DHCP quick and dirty time          December 2013


7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

7.2.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [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.

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

Appendix A.  Document history

   [RFC Editor: Please remove this section before publication ]

   00 Initial version

   01 Changed document to use a new 64 bit DHCPv4 option, added DHCPv6
   option and ND option.  Deleted references to Bulk Query, reworked
   security considerations.





Gudmundsson               Expires June 04, 2014                 [Page 6]

Internet-Draft          DHCP quick and dirty time          December 2013


Author's Address

   Olafur Gudmundsson
   Shinkuro Inc.
   4922 Fairmont Av, Suite 250
   Bethesda, MD  20814
   USA

   Email: ogud@ogud.com










































Gudmundsson               Expires June 04, 2014                 [Page 7]