One document matched: draft-ogud-dhc-udp-time-option-00.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-00" 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 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</workgroup>
      
      <abstract>
	<t>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. </t>
	<t> 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 .</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. </t> 
    <t> 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.</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 in 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 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. </t> 
      <t> Any protocol that checks certificates for correctness also
	depends on correct 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="DHC option 152 over UDP"> 
    <t> 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. </t> 
    <t> DHC provides an option for clients to ask about close NTP
    servers, the answer is a DNS FQDN that requires DNS resolution to
    work. </t> 
    <t> <xref target="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. </t> 
    <section title="Protocol change"> 
      <t> 
	Option 152 can be requested over UDP and DHCP server SHOULD
	return a value that is within 10 minutes of current time.
      </t>
      </section>
    </section>
  <section title="IANA considerations">
    <t>None</t> 
    <t>[RFC Editor: Please remove this section before publication ]</t>
      
  </section> 
  <section title="Security considerations"> 
    <t> 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. 
    </t> 
    <t> 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. </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. 
    </t> 
  </section>

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

  <section title="Implementation Experience(???)"> 
    <t> 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. </t> 
  </section> 
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.6926'?>
      <?rfc include='reference.RFC.4033'?>
    </references>
    
    <references title="Informative References">
      <?rfc include='reference.RFC.1034'?>
      <?rfc include='reference.RFC.4034'?>
      <?rfc include='reference.RFC.4035'?>
      <?rfc include='reference.RFC.4253'?>
      <?rfc include='reference.RFC.5246'?>
      <?rfc include='reference.RFC.5280'?>
      <?rfc include='reference.RFC.5905'?>
      <?rfc include='reference.RFC.6347'?>
    </references>
    <section title="Document history"> 
      <t>[RFC Editor: Please remove this section before publication ]</t>
      
      <t> 00 Initial version </t> 
    </section>
  </back>
</rfc>