One document matched: draft-ogud-dhc-udp-time-option-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "./reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-ogud-dhc-udp-time-option-01" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes"?>
  <?rfc compact="yes" ?>

  <front>
    <title abbrev="DHCP quick and dirty time ">
      Providing Time over DHCP and ND for devices w/o reliable clock upon boot</title>
     
      <author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
	<organization>Shinkuro Inc.</organization>
	<address>
	  <postal>
	    <street>4922 Fairmont Av, Suite 250</street>
	    <city>Bethesda</city>
	    <region>MD</region>
	    <code>20814</code>
	    <country>USA</country>
	  </postal>
	  <email>ogud@ogud.com</email>
	</address>
      </author>

      <date />
      
      <area>Internet</area>
      
      <workgroup>DHC, 6MAN</workgroup>
      
      <abstract>
	<t>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. </t>
	<t> 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.</t> 
      </abstract>
  </front>

  <middle>
  <section title="Introduction"> 
    <t> 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. 
    </t> 
    <t> 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. 
    </t>


    <section title="Why knowing time is getting more important"> 
      <t> Applications and services that use time are getting more and
	more important, in particular when validating if servers are
	offering good credentials. 
      </t> 
      <t> For example DNS <xref target="RFC1034" /> is being deployed
	widely in resolvers with DNSSEC validation <xref target="RFC4033"/>
 	DNSSEC signatures rarely have signature lifetime of more than
	one month and in some cases few hours. </t> 
      <t> Most devices use NTP <xref target="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. </t> 
      <t> Any protocol that checks certificates for correctness also
	depends on correct time has potentially the same
	false-negative behavior before time synchronization completes.
      </t> 
      <t> 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.  
      </t> 
    </section>
    <section title="Requirements notation">
      <t>
	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
	<xref target="RFC2119" />.
      </t>
    </section>
  </section> 

  <section title="Current Time options"> 
    <t> Many of the devices that boot without accurate clock get their
      IPv4 addresses from
      DHCP <xref target="RFC2131"/> <xref target="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. 
    </t>  
    <t> DHCP provides an option for clients to ask about NTP
      servers, the answer is a DNS FQDN that requires DNS resolution to
      work. 
    </t> 
    <t> On networks that use IPv6 autoconfiguration Neighbor Discovery
    <xref target="RFC4861"/>
      options can be used to provide the same service.
    </t> 
    <t> 
      These option(s) are designed to provide "rough" time not accurate
      time, NTP MUST be used by clients when available to get accurate time. 
    </t> 
    <t> 
      Entities that provide Current-Time answers SHOULD return
      time that is within 10 minutes of current time.
    </t>
      <section title="Option allocations"> 
	<t> 
	  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. 
	</t> 
	<t> 
	  "Current Time" DHCP IPv4 option code is TBD1 see section
	  <xref target="D-4"/>
	</t>
	<t> 
	  DHCPv6 OPTION_CURRENT_TIME DHCPv6 code is TBD2 see section <xref target="D-6"/>.
	</t> 
	<t>
	  ND "Current Time Option" code is TBD3 see <xref target="N-D"/>. 
	</t> 
      </section>
    </section>

  
  <section title="IANA considerations">
    <section title="DHCP Current Time option" anchor="D-4"> 
      <t> 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: 
	<figure> <artwork>
	Tag = TBD1;
	Name = "Current Time ";
	Data Length = 8 ;
	Meaning = "Rough Current time" ;
	Reference = "[This-document]";
	</artwork> </figure>
      </t> 
    </section>
    <section title="DHCPv6 Current Time option" anchor="D-6"> 
      <t> 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: 
	<figure> <artwork>
	Value = TBD2;
	Description = "OPTION_CURRENT_TIME";
	Reference= "[This-document]";
	</artwork> </figure>
      </t> 
    </section>
    
    <section title="Neighbor Discovery option" anchor="N-D">
      <t>
	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"
	<figure> <artwork>
	Type = TBD3
	Description = "Current time option" 
	Reference = "[This document]"
	</artwork> </figure>
      </t> 
    </section>
      
  </section> 
  <section title="Security considerations"> 
    <t> Devices that have alternate means to get accurate current time via
      Radio signals etc. SHOULD NOT use the options specified in this
      document. 
    </t> 
    <t> 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.   
    </t> 
    <t> 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.  
    </t> 
  </section>

  <section title="Internationalizaiton Considerations"> 
    <t> NONE</t>
  </section> 

  <section title="Implementation Experience"> 
    <t> This document is motivated by deploying validating
    resolvers on a home routers without accurate clocks.
    </t>
  </section> 
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.2131'?>
      <?rfc include='reference.RFC.3315'?>
      <?rfc include='reference.RFC.4861'?>
    </references>
    
    <references title="Informative References">
      <?rfc include='reference.RFC.1034'?>
      <?rfc include='reference.RFC.4033'?>
      <?rfc include='reference.RFC.4034'?>
      <?rfc include='reference.RFC.4035'?>
      <?rfc include='reference.RFC.5905'?>
    </references>
    <section title="Document history"> 
      <t>[RFC Editor: Please remove this section before publication ]</t>
      <t> 00 Initial version </t> 
      <t> 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. </t> 
    </section>
  </back>
</rfc>