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 (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
• 1.1. Why knowing time is getting more important
• 1.2. Requirements notation
• 2. DHC option 152 over UDP
• 2.1. Protocol change
• 3. IANA considerations
• 4. Security considerations
• 5. Internationalizaiton Considerations
• 6. Implementation Experience(???)
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Document history
• Author's Address

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.

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.

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

7.2. Informative References

Appendix A. Document history

[RFC Editor: Please remove this section before publication ]

00 Initial version

Author's Address