Network Working Group R. Johnson
Internet-Draft Cisco Systems, Inc.
Intended status: Informational July 8, 2008
Expires: January 9, 2009
VoIP Configuration Server Address Option
draft-raj-dhc-tftp-addr-option-04.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 January 9, 2009.
Johnson Expires January 9, 2009 [Page 1]
Internet-Draft VoIP Configuration Server Address Option July 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], 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. VoIP Configuration Server Address Option Definition . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Johnson Expires January 9, 2009 [Page 2]
Internet-Draft VoIP Configuration Server Address Option July 2008
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" 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.
Johnson Expires January 9, 2009 [Page 3]
Internet-Draft VoIP Configuration Server Address Option July 2008
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 January 9, 2009 [Page 4]
Internet-Draft VoIP Configuration Server Address Option July 2008
3. VoIP Configuration Server Address Option Definition
The VoIP Configuration Server Address option is a DHCP option
[RFC2132]. The option contains one or more IPv4 addresses of the
VoIP Configuration Server which the client MAY use.
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 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.
Johnson Expires January 9, 2009 [Page 5]
Internet-Draft VoIP Configuration Server Address Option July 2008
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 more
easily done with the VoIP Configuration Server Address option than it
was with the "TFTP Server Name" option, because in the latter 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].
Potential exposures to attack are discussed in section 7 of the DHCP
protocol specification in [RFC2131].
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.
Johnson Expires January 9, 2009 [Page 6]
Internet-Draft VoIP Configuration Server Address Option July 2008
5. IANA Considerations
IANA is requested to assign DHCP option number 150 for this option,
in accordance with [RFC3942].
Johnson Expires January 9, 2009 [Page 7]
Internet-Draft VoIP Configuration Server Address Option July 2008
6. 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.
[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.
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration
Protocol version 4 (DHCPv4) Options", RFC 3942,
November 2004.
Johnson Expires January 9, 2009 [Page 8]
Internet-Draft VoIP Configuration Server Address Option July 2008
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 January 9, 2009 [Page 9]
Internet-Draft VoIP Configuration Server Address Option July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Johnson Expires January 9, 2009 [Page 10]