[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 5859

Network Working Group                                         R. Johnson
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                             March 6, 2010
Expires: September 7, 2010


                 TFTP Server Address Option for DHCPv4
                 draft-raj-dhc-tftp-addr-option-06.txt

Abstract

   This memo documents existing usage for the "TFTP Server Address
   Option".  The option number currently in use is 150.  This memo
   documents the current usage of the option in agreement with RFC 3942
   [RFC3942], which declares that any pre-existing usages of option
   numbers in the range 128 - 223 should be documented and the working
   group will try to officially assign those numbers to those options.
   The option is defined for DHCPv4 and works only with IPv4 addresses.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 7, 2010.

Copyright Notice

   Copyright (c) 2010 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



Johnson                 Expires September 7, 2010               [Page 1]

Internet-Draft              TFTP Serv. Addr.                  March 2010


   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 BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.































Johnson                 Expires September 7, 2010               [Page 2]

Internet-Draft              TFTP Serv. Addr.                  March 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  TFTP Server Address Option Definition . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9








































Johnson                 Expires September 7, 2010               [Page 3]

Internet-Draft              TFTP Serv. Addr.                  March 2010


1.  Introduction

   Voice over IP ("VoIP") devices, such as IP phones, have a need to
   download their configuration from a configuration server on the
   network.  There are commonly accepted methods to discover this server
   via DHCP; the "sname" field in the DHCP header [RFC2131], the "TFTP
   Server name" option (#66) [RFC2132].  Both of these sources of
   information, however, contain the TFTP server's hostname.  That
   hostname must then be translated to an IP address.  The usual method
   to accomplish this would be DNS [RFC1034].  This means the firmware
   in a VoIP device (with possibly limited flash, memory, and/or
   processing resources) would need to implement the DNS protocol in
   order to perform this translation.  This would also introduce an
   additional unnecessary point of failure whereby the device is
   dependent on the DNS server infrastructure in order to boot up and
   communicate with its call agent.

   In order to eliminate DNS as a point of failure and keep the firmware
   in such a VoIP device to a minimum the "VoIP Configuration Server
   Address" option (150) was introduced.  This option allows the DHCP
   server to pass one or more IP addresses of the VoIP Configuration
   Server(s) instead of the hostname, thus making the information
   directly usable by the VoIP device.

   Other reasons for this option are that, (1) the "siaddr" field is not
   configurable on some DHCP servers, (2) the "siaddr" field only allows
   for one IPv4 address and it is desirable to have the ability to
   configure multiple IP addresses for redundancy, (3) some DHCP servers
   have been found to fill in their own IPv4 address as siaddr, (4) some
   customers were already using the "siaddr" field for other purposes,
   and finally (5) the configuration server may use a protocol other
   than TFTP to serve configuration files, making the use of the "TFTP
   Server name" option (option code 66) inappropriate.

   In cases where other download server address information also appears
   in the response packet, such as "sname" and "TFTP Server name", it is
   left to the device to decide which piece of information to use.














Johnson                 Expires September 7, 2010               [Page 4]

Internet-Draft              TFTP Serv. Addr.                  March 2010


2.  Conventions

   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 RFC 2119 [RFC2119].














































Johnson                 Expires September 7, 2010               [Page 5]

Internet-Draft              TFTP Serv. Addr.                  March 2010


3.  TFTP Server Address Option Definition

   The TFTP Server Address option is a DHCP option [RFC2132].  The
   option contains one or more IPv4 addresses which the client MAY use.
   The current use of this option is for downloading configuration from
   a VoIP server via TFTP, however the option may be used for purposes
   other than contacting a VoIP Configuration Server.

   The format of the option is:

    Code   Len   IPv4 Configuration Server Address(es)
   +-----+-----+-----+-----+-----+-----+
   | 150 |  n  |     IPv4 address      | ...
   +-----+-----+-----+-----+-----+-----+


                                 Figure 1

   The option minimum length (n) is 4.

   The "Len" field must specify a length which is an integral multiple
   of 4 octets (4, 8, 12, etc.).  If an option is received where this is
   not the case, the option information MUST be ignored, but further
   option processing may continue.  Dividing this "Len" value by 4 will
   give number of IPv4 VoIP Configuration Server addresses which are
   specified in the option.

   The option MUST NOT be specified by the DHCP Client as it is intended
   only to be returned from the DHCP Server.  If the DHCP Client wants
   to receive this information from the server, it needs to include the
   number 150 in the DHCP "Parameter List" option (55).

   Server addresses SHOULD be listed in order of preference and the
   client SHOULD use the addresses sequentially but may be configurable
   to use addresses randomly.  The client may use as many or as few of
   the addresses provided as it likes.  For example, if client is only
   capable of accepting 2 configuration server addresses, it may ignore
   any other addresses provided after the second address.

   Each TFTP server address which is being used by the client should be
   tried a total of 4 times with a 4 second wait time before proceeding
   to the next address.

   When this option appears along with the TFTP Server Name option
   (option 66) [RFC2132], this option SHOULD have priority over option
   66.

   There is currently no defined IPv6 DHCP equivalent of this option.



Johnson                 Expires September 7, 2010               [Page 6]

Internet-Draft              TFTP Serv. Addr.                  March 2010


4.  Security Considerations

   A rogue DHCP Server could use this option in order to coerce a Client
   into downloading configuration from an alternate Configuration Server
   and thus gain control of the device's configuration.  This, however,
   is no more of a security threat than similar attacks using other DHCP
   options which specify server names or addresses, of which there are
   many.  If this is a concern, then DHCP Authentication may be used,
   but even secure delivery of an address over DHCP does not protect the
   subsequent insecure download over TFTP.  TFTP itself provides no
   authentication or access control mechanisms, so even if DHCP messages
   were authenticated, downloading the configuration would still be
   insecure, unless some object-level security mechanisms would be used.

   Where security concerns are an issue, it is suggested that
   configuration files should be signed by a trusted agent.
   Configuration files may also be encrypted based on a configuration
   parameter on the DHCP client device.  In other words, there are
   various methods to ensure the integrity of configuration data
   independent from insuring the integrity of the this DHCP option or
   even DHCP itself.  The full extent of such options is far too broad
   to be addressed in this document.

   Message authentication in DHCP for intradomain use where the out-of-
   band exchange of a shared secret is feasible and is defined in
   [RFC3118].  Potential exposures to attack are discussed in section 7
   of the DHCP protocol specification in [RFC2131].
























Johnson                 Expires September 7, 2010               [Page 7]

Internet-Draft              TFTP Serv. Addr.                  March 2010


5.  IANA Considerations

   IANA is requested to assign DHCP option number 150 for this option,
   in accordance with [RFC3942].















































Johnson                 Expires September 7, 2010               [Page 8]

Internet-Draft              TFTP Serv. Addr.                  March 2010


6.  References

6.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.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC3942]  Volz, B., "Reclassifying Dynamic Host Configuration
              Protocol version 4 (DHCPv4) Options", RFC 3942,
              November 2004.

6.2.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.



























Johnson                 Expires September 7, 2010               [Page 9]

Internet-Draft              TFTP Serv. Addr.                  March 2010


Author's Address

   Richard A. Johnson
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 526 4000
   Email: raj@cisco.com









































Johnson                 Expires September 7, 2010              [Page 10]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/