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.

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. Current Time options
• 2.1. Option allocations
• 3. IANA considerations
• 3.1. DHCP Current Time option
• 3.2. DHCPv6 Current Time option
• 3.3. Neighbor Discovery option
• 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, 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.

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.

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

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

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:

3.2. DHCPv6 Current Time option

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

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:

3.3. Neighbor Discovery option

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

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"

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

7.1. Normative References

7.2. Informative References

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.

Author's Address