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]
