VoIP Configuration Server Address Option
draft-raj-dhc-tftp-addr-option-03.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 20, 2008.

Abstract

This memo documents existing usage for the "VoIP Configuration Server Address Option" (previously known as the "TFTP Server IP Address Option". The option number currently in use is 150. This memo documents the current usage of the option in agreement with [RFC3942] (Volz, B., “Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options,” November 2004.), 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.

Table of Contents

1.  Introduction
2.  Conventions
3.  VoIP Configuration Server Address Option Definition
4.  Security Considerations
5.  IANA Considerations
6.  References
§  Author's Address
§  Intellectual Property and Copyright Statements

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] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.), the "TFTP Server name" option (#66) [RFC2132] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.). 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] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) 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 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, and (4) some customers were already using the "siaddr" field for other purposes. (5) The configuration server may use a protocol other than TFTP to serve configuration files, making the use of the "TFTP Server name" opion (#66) in 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.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  VoIP Configuration Server Address Option Definition

The VoIP Configuration Server Address option is a DHCP option [RFC2132] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.). The option contains one or more IPv4 addresses of the VoIP Configuration Server which the client should use, if needed.

The format of the option is:

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

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 SHOULD be ignored. Dividing this "Len" value by 4 will give number of IPv4 VoIP Configuration Server addresses which are specified in the option.

The option SHOULD 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 SHOULD include the number 150 in the DHCP "Parameter List" option (55)."

Server addresses SHOULD be listed in order of preference.

The client may use as many or as few of the addresses provided. For example, if client is only capable of accepting 2 configuration server addresses, it may ignore any other addresses provided after the second address. A client SHOULD accept an offer that contains more addresses than it is capable of utilizing and ignore those that it is not capable of using.

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 is easier done with the VoIP Configuration Server Address option than it was with the "TFTP Server Name" option, because in the later case the attack would need to control DNS responses as well as inserting the rogue DHCP option information. If this is a concern, then either DHCP Authentication may be used, or the "TFTP Server Name" option may be used instead.

Message authentication in DHCP for intradomain use where the out-of- band exchange of a shared secret is feasible is defined in [RFC3118] (Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” June 2001.). Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.).

Other out-of-band methods of verifying the validity of the VoIP Configuration Server Address, such as certificates of trust, could be used to mitigate some security concerns.

5.  IANA Considerations

IANA is requested to assign DHCP option number 150 for this option, in accordance with [RFC3942] (Volz, B., “Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options,” November 2004.).

6. References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.