draft-ietf-dhc-packetcable-06.txt   rfc3495.txt 
Internet Engineering Task Force B. Beser Network Working Group B. Beser
INTERNET DRAFT Juniper Networks Request for Comments: 3495 Juniper Networks
DHC Working Group P. Duffy (ed.) Category: Standards Track P. Duffy, Ed.
Document: draft-ietf-dhc-packetcable-06.txt Cisco Systems Cisco Systems
January 2003 March 2003
DHCP Option for CableLabs Client Configuration
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with Dynamic Host Configuration Protocol (DHCP) Option
all provisions of Section 10 of RFC 2026. for CableLabs Client Configuration
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 This document specifies an Internet standards track protocol for the
months and may be updated, replaced, or obsoleted by other documents Internet community, and requests discussion and suggestions for
at any time. It is inappropriate to use Internet-Drafts as improvements. Please refer to the current edition of the "Internet
reference material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
2. Abstract Abstract
This document defines a DHCP option that will be used to configure This document defines a Dynamic Host Configuration Protocol (DHCP)
various devices deployed within CableLabs architectures. option that will be used to configure various devices deployed within
Specifically, the document describes DHCP option content that will be CableLabs architectures. Specifically, the document describes DHCP
used to configure one class of CableLabs client device: a PacketCable option content that will be used to configure one class of CableLabs
Media Terminal Adapter (MTA). The option content defined within this client device: a PacketCable Media Terminal Adapter (MTA). The
document will be extended as future CableLabs client devices are option content defined within this document will be extended as
developed. future CableLabs client devices are developed.
3. Table of Contents Table of Contents
1. Status of this Memo..........................................1 1. Conventions used in this document............................ 2
2. Abstract.....................................................1 2. Terminology.................................................. 2
3. Table of Contents............................................1 3. Introduction................................................. 3
4. Conventions used in this document............................2 4. CableLabs Client Configuration Option Format................. 4
5. Terminology..................................................2 5. CableLabs Client Configuration Option: Sub-Option Definitions 5
6. Introduction.................................................2 5.1. TSP's DHCP Server Address Sub-Options.................. 5
7. CableLabs Client Configuration Option Format.................4 5.2. TSP's Provisioning Server Address Sub-Option........... 6
8. CableLabs Client Configuration Option: Sub-Option Definitions 5 5.3. TSP's AS-REQ/AS-REP Backoff and Retry.................. 6
8.1. TSP's DHCP Server Address Sub-Options.......................5 5.4. TSP's AP-REQ/AP-REP Backoff and Retry.................. 7
8.2. TSP's Provisioning Server Address Sub-Option................5 5.5. TSP's Kerberos Realm Name Sub-Option................... 8
8.3. TSP's AS-REQ/AS-REP Backoff and Retry.......................6 5.6. TSP's Ticket Granting Server Utilization Sub-Option.... 8
8.4. TSP's AP-REQ/AP-REP Backoff and Retry.......................7 5.7. TSP's Provisioning Timer Sub-Option.................... 8
8.5. TSP's Kerberos Realm Name Sub-Option........................7 6. Informational Description of CCC Option Usage................ 9
8.6. TSP's Ticket Granting Server Utilization Sub-Option.........8 7. IANA Considerations.......................................... 9
8.7. TSP's Provisioning Timer Sub-Option.........................8 8. Legacy Use Information....................................... 9
9. Informational Description of CCC Option Usage................8 9. Procedure for Adding Additional Sub-options.................. 9
10. IANA Considerations..........................................9 10. Security Considerations...................................... 10
11. Legacy Use Information.......................................9 11. References................................................... 10
12. Procedure for Adding Additional Sub-options..................9 11.1. Normative References................................... 10
13. Security Considerations......................................9 11.2. Informative References................................. 11
14. References..................................................10 12. Acknowledgments.............................................. 11
15. Acknowledgments.............................................11 13. Authors' Addresses........................................... 12
16. Author's Addresses..........................................11 14. Full Copyright Statement..................................... 13
17. Full Copyright Statement....................................11
4. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in BCP 14, RFC 2119 [1].
5. Terminology 2. Terminology
Definitions of terms used throughout this document: Definitions of terms used throughout this document:
* "Telephony Service Provider" or "TSP" * "Telephony Service Provider" or "TSP"
The business entity from which a subscriber receives telephony The business entity from which a subscriber receives telephony
service. service.
See RFC 2131[6] for additional DHCP terminology. See RFC 2131 [6] for additional DHCP terminology.
6. Introduction 3. Introduction
Cable Television Laboratories, Inc. (CableLabs) is a non-profit Cable Television Laboratories, Inc. (CableLabs) is a non-profit
research and development consortium that serves the cable television research and development consortium that serves the cable television
industry via design and specification of new and emerging broadband industry via design and specification of new and emerging broadband
service architectures. Several CableLabs initiatives define DHCP service architectures. Several CableLabs initiatives define DHCP
clients that have specific DHCP configuration requirements. One such clients that have specific DHCP configuration requirements. One such
initiative is the PacketCable project. initiative is the PacketCable project.
The PacketCable project is aimed at architecting, qualifying, and The PacketCable project is aimed at architecting, qualifying, and
supporting Internet-based multimedia services over cable-based packet supporting Internet-based multimedia services over cable-based packet
networks. These new multimedia services will include telephony and networks. These new multimedia services will include telephony and
videoconferencing, delivered using the basic Internet Protocol (IP) videoconferencing, delivered using the basic Internet Protocol (IP)
technology that is used to send data via the Internet. technology that is used to send data via the Internet.
PacketCable 1.0 provides Voice over IP (VoIP) service delivery. The PacketCable 1.0 provides Voice over IP (VoIP) service delivery. The
VoIP service is supported at the customer site by two key components: VoIP service is supported at the customer site by two key components:
a Cable Modem (CM) and a Media Terminal Adapter (MTA). The CM a Cable Modem (CM) and a Media Terminal Adapter (MTA). The CM
converts the cable RF signals to/from various IP voice protocols, converts the cable RF signals to/from various IP voice protocols,
while the MTA converts the VoIP protocols into analog telephony while the MTA converts the VoIP protocols into analog telephony
compatible with a common telephone. compatible with a common telephone.
The CM and MTA may be packaged together or separately. If packaged The CM and MTA may be packaged together or separately. If packaged
together, the unit is referred to as an Embedded-MTA (EMTA - depicted together, the unit is referred to as an Embedded-MTA (EMTA - depicted
in Figure 1). If packaged separately, the MTA is referred to as a in Figure 1). If packaged separately, the MTA is referred to as a
Standalone MTA (SMTA). Standalone MTA (SMTA).
|----------------------------------------------| |----------------------------------------------|
| | | |
| |-----------| |-------------| | | |-----------| |-------------| |
| | | | | | | | | | | |
Telephony | | Media | internal | Cable | | RF Link Telephony | | Media | internal | Cable | | RF Link
---------_|---| Terminal |===========| Modem |----|------- ----------|---| Terminal |===========| Modem |----|-------
Link | | Adapter | connection| | | Link | | Adapter | connection| | |
| |-----------| |-------------| | | |-----------| |-------------| |
| | | |
|----------------------------------------------| |----------------------------------------------|
Figure 1. PacketCable 1.0 Embedded-MTA Figure 1. PacketCable 1.0 Embedded-MTA
The CM and MTA are distinct IP devices: each has its own MAC address The CM and MTA are distinct IP devices: each has its own MAC address
and IP configuration. The CM and MTA utilize the DHCP protocol to and IP configuration. The CM and MTA utilize the DHCP protocol to
obtain IP configuration. It is assumed that the CM and MTA may be obtain IP configuration. It is assumed that the CM and MTA may be
administered by different business entities. The CM communicates administered by different business entities. The CM communicates
with and is configured by the data access provider's DHCP servers. with and is configured by the Data Access Provider's (DAP's) DHCP
Likewise, the MTA communicates with and is configured by the servers. Likewise, the MTA communicates with and is configured by
Telephony Service Provider's (TSP's) DHCP servers. the Telephony Service Provider's (TSP's) DHCP servers.
The PacketCable architecture requires that the business entity The PacketCable architecture requires that the business entity
controlling configuration of the CM also determines which business controlling the configuration of the CM also determines which
entities control the configuration of the MTA. This is similar to business entities control the configuration of the MTA. This is
the example found in the PSTN system: individuals can pick their long similar to the example found in the PSTN system: individuals can pick
distance carriers even though the ultimate control of their telephone their long distance carriers even though the ultimate control of
remains with the local carrier. their telephone remains with the local carrier.
Due to specific needs of the MTA configuration process (described in Due to specific needs of the MTA configuration process (described in
[7]), a new CableLabs Client Configuration (CCC) option is needed for [7]), a new CableLabs Client Configuration (CCC) option is needed for
the DHCP protocol. Both CM and MTA DHCP clients will request this the DHCP protocol. Both CM and MTA DHCP clients will request this
option. When requested, both the CM and TSP DHCP servers will option. When requested, both the DAP and TSP DHCP servers will
populate this option into DHCP responses. See section 9 for further populate this option into DHCP responses. See section 6 for further
operational details. operational details.
It should be noted that, although the CCC option will be initially It should be noted that, although the CCC option will be initially
deployed to support PacketCable VOIP applications, the CCC option deployed to support PacketCable VOIP applications, the CCC option
will also be used to support various non VOIP applications. Use of will also be used to support various non VOIP applications. Use of
the CCC option does not necessarily mean that the service provider is the CCC option does not necessarily mean that the service provider is
a TSP. a TSP.
7. CableLabs Client Configuration Option Format 4. CableLabs Client Configuration Option Format
The option begins with a tag octet containing the option code (code The option begins with a tag octet containing the option code (code
TBD). A length octet follows the tag octet. The value of the length 122). A length octet follows the tag octet. The value of the length
octet does not include itself or the tag octet. The length octet is octet does not include itself or the tag octet. The length octet is
followed by "length" octets of sub-option content (total length, not followed by "length" octets of sub-option content (total length, not
sub-option count). The option layout is depicted below: sub-option count). The option layout is depicted below:
+------+--------+--------------+--------------+---+--------------+ +------+--------+--------------+--------------+---+--------------+
| Code | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n | | 122 | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n |
+------+--------+--------------+--------------+---+--------------+ +------+--------+--------------+--------------+---+--------------+
When the total length of a CCC option exceeds 255 octets, the When the total length of a CCC option exceeds 255 octets, the
procedure outlined in [4] MUST be employed to split the option into procedure outlined in [4] MUST be employed to split the option into
multiple, smaller options. multiple, smaller options.
A sub-option begins with a tag octet containing the sub-option code. A sub-option begins with a tag octet containing the sub-option code.
A length octet follows the tag octet. The value of the length octet A length octet follows the tag octet. The value of the length octet
does not include itself or the tag octet. The length octet is does not include itself or the tag octet. The length octet is
followed by "length" octets of sub-option information. The sub- followed by "length" octets of sub-option information. The sub-
option layout is depicted below: option layout is depicted below:
+-------------------+--------+------------------------+ +-------------------+--------+------------------------+
| Sub-option Code | Length | Sub-option information | | Sub-option Code | Length | Sub-option information |
+-------------------+--------+------------------------+ +-------------------+--------+------------------------+
The sub-option codes are summarized below. The sub-option codes are summarized below.
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
skipping to change at line 204 skipping to change at page 5, line 30
| 5 | MTA | TSP's AP-REQ/AP-REP Backoff and Retry | | 5 | MTA | TSP's AP-REQ/AP-REP Backoff and Retry |
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
| 6 | MTA | TSP's Kerberos Realm Name | | 6 | MTA | TSP's Kerberos Realm Name |
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
| 7 | MTA | TSP's Ticket Granting Server Utilization | | 7 | MTA | TSP's Ticket Granting Server Utilization |
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
| 8 | MTA | TSP's Provisioning Timer Value | | 8 | MTA | TSP's Provisioning Timer Value |
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
| 9 - 255 | | Reserved for future extensions | | 9 - 255 | | Reserved for future extensions |
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
8. CableLabs Client Configuration Option: Sub-Option Definitions
5. CableLabs Client Configuration Option: Sub-Option Definitions
The following sections provide detailed descriptions of each sub- The following sections provide detailed descriptions of each sub-
option. There are a few general formatting rules: option. There are a few general formatting rules:
- Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035
[3] section 3.1. Note that a terminating 0 is required. Also note [3] section 3.1. Note that a terminating 0 is required. Also
that compression, as described in RFC 1035 [3] section 4.1.4, MUST note that compression, as described in RFC 1035 [3] section 4.1.4,
NOT be applied. MUST NOT be applied.
- IPv4 addresses MUST be encoded as 4 binary octets in network byte-
order (high order byte first).
- All multi-octet quantities MUST be encoded per network byte-
ordering.
8.1. TSP's DHCP Server Address Sub-Options - IPv4 addresses MUST be encoded as 4 binary octets in network
byte-order (high order byte first).
- All multi-octet quantities MUST be encoded per network byte-
ordering.
5.1. TSP's DHCP Server Address Sub-Options
The TSP DHCP Server Address sub-options identify the DHCP servers The TSP DHCP Server Address sub-options identify the DHCP servers
from which an MTA is permitted to accept a DHCP OFFER. Sub-option 1 from which an MTA is permitted to accept a DHCP OFFER. Sub-option 1
is the address of the TSP's primary DHCP server. Sub-option 2 is the is the address of the TSP's primary DHCP server. Sub-option 2 is the
address of the TSP's secondary DHCP server. address of the TSP's secondary DHCP server.
The sub-option length MUST be 4 and the sub-option MUST include the The sub-option length MUST be 4 and the sub-option MUST include the
DHCP server's IPv4 address as follows: DHCP server's IPv4 address as follows:
Code Len Address Code Len Address
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| 1/2 | 4 | a1 | a2 | a3 | a4 | | 1/2 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
8.2. TSP's Provisioning Server Address Sub-Option 5.2. TSP's Provisioning Server Address Sub-Option
This option contains the address of the TSP's Provisioning server. This option contains the address of the TSP's Provisioning server.
MTAs communicate with the Provisioning server at various stages in MTAs communicate with the Provisioning server at various stages in
their provisioning process. their provisioning process.
The address can be configured as either an IPv4 address or as an The address can be configured as either an IPv4 address or as an
FQDN. The encoding of sub-option 3 will adhere to one of 2 formats. FQDN. The encoding of sub-option 3 will adhere to one of 2 formats.
1. IPv4 address. The sub-option length MUST be 5. The length octet 1. IPv4 address. The sub-option length MUST be 5. The length octet
MUST be followed by a single octet that indicates the specific MUST be followed by a single octet that indicates the specific
address type that follows. This type octet MUST be set to 1 to address type that follows. This type octet MUST be set to 1 to
indicate an IPv4 address. The type octet MUST be followed by 4 indicate an IPv4 address. The type octet MUST be followed by 4
octets of IPv4 address: octets of IPv4 address:
Code Len Type Address Code Len Type Address
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
| 3 | 5 | 1 | a1 | a2 | a3 | a4 | | 3 | 5 | 1 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
2. FQDN. The length octet MUST be followed by a single octet that 2. FQDN. The length octet MUST be followed by a single octet that
indicates the specific address type that follows. This type octet indicates the specific address type that follows. This type octet
MUST be set to 0 to indicate an FQDN. The type octet MUST be MUST be set to 0 to indicate an FQDN. The type octet MUST be
followed by the encoded FQDN: followed by the encoded FQDN:
Code Len Type FQDN Code Len Type FQDN
+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+ +-----+
| 3 | n+1 | 0 | f1 | f2 |...| fn | | 3 | n+1 | 0 | f1 | f2 |...| fn |
+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+ +-----+
It is not anticipated that additional type codes, beyond IPv4 (1) and It is not anticipated that additional type codes, beyond IPv4 (1) and
FQDN (0), will be required. Thus, IANA will not be required to FQDN (0), will be required. Thus, IANA will not be required to
maintain a registry of type codes. maintain a registry of type codes.
8.3. TSP's AS-REQ/AS-REP Backoff and Retry 5.3. TSP's AS-REQ/AS-REP Backoff and Retry
This sub-option configures an MTA's Kerberos AS-REQ/AS-REP timeout, This sub-option configures an MTA's Kerberos AS-REQ/AS-REP timeout,
backoff, and retry mechanism. backoff, and retry mechanism.
RFC-1510 [5] does not define a backoff/retry mechanism to be RFC 1510 [5] does not define a backoff/retry mechanism to be employed
employed when an AS-REQ/AS-REP message exchange fails. This sub- when an AS-REQ/AS-REP message exchange fails. This sub-option
option contains parameters required by the backoff/retry mechanism contains parameters required by the backoff/retry mechanism outlined
outlined in [8]. in [8].
The encoding of this sub-option is depicted below: The encoding of this sub-option is depicted below:
Code Len Nom Timeout Max Timeout Max Retries Code Len Nom Timeout Max Timeout Max Retries
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | | 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The length octet of this sub-option MUST contain the value 12. The length octet of this sub-option MUST contain the value 12.
The length octet MUST be followed by 4 octets containing the AS- The length octet MUST be followed by 4 octets containing the AS-
REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit
unsigned quantity in units of seconds. unsigned quantity in units of milliseconds.
The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout
value. This value is a 32 bit unsigned quantity in units of seconds value. This value is a 32 bit unsigned quantity in units of seconds.
The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry
count. This value is a 32 bit unsigned quantity. count. This value is a 32 bit unsigned quantity.
8.4. TSP's AP-REQ/AP-REP Backoff and Retry 5.4. TSP's AP-REQ/AP-REP Backoff and Retry
This sub-option configures an MTA's Kerberos AP-REQ/AP-REP timeout, This sub-option configures an MTA's Kerberos AP-REQ/AP-REP timeout,
backoff, and retry mechanism. backoff, and retry mechanism.
RFC-1510 [5] does not define a backoff/retry mechanism to be RFC 1510 [5] does not define a backoff/retry mechanism to be employed
employed when an AP-REQ/AP-REP message exchange fails. This sub- when an AP-REQ/AP-REP message exchange fails. This sub-option
option contains parameters required by the backoff/retry mechanism contains parameters required by the backoff/retry mechanism outlined
outlined in [8]. in [8].
The encoding of this sub-option is depicted below: The encoding of this sub-option is depicted below:
Code Len Nom Timeout Max Timeout Max Retries Code Len Nom Timeout Max Timeout Max Retries
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 5 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | | 5 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The length octet of this sub-option MUST contain the value 12. The length octet of this sub-option MUST contain the value 12.
The length octet MUST be followed by 4 octets containing the AP- The length octet MUST be followed by 4 octets containing the AP-
REQ/AP-REP nominal (initial) timeout value. This value is a 32 bit REQ/AP-REP nominal (initial) timeout value. This value is a 32 bit
unsigned quantity in units of seconds. unsigned quantity in units of seconds.
The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout
value. This value is a 32 bit unsigned quantity in units of seconds. value. This value is a 32 bit unsigned quantity in units of seconds.
The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry
count. This value is a 32 bit unsigned quantity. count. This value is a 32 bit unsigned quantity.
8.5. TSP's Kerberos Realm Name Sub-Option 5.5. TSP's Kerberos Realm Name Sub-Option
The PacketCable architecture requires an MTA to authenticate itself The PacketCable architecture requires an MTA to authenticate itself
to the TSP's network via the Kerberos protocol. A Kerberos Realm to the TSP's network via the Kerberos protocol. A Kerberos Realm
name is required at the MTA to permit a DNS lookup for the address of name is required at the MTA to permit a DNS lookup for the address of
the TSP's Kerberos Key Distribution Center (KDC) entity. the TSP's Kerberos Key Distribution Center (KDC) entity.
The Kerberos Realm name MUST be encoded per the domain style realm The Kerberos Realm name MUST be encoded per the domain style realm
name described in RFC 1510 [5]. This realm name MUST be all capital name described in RFC 1510 [5]. This realm name MUST be all capital
letters and conform to the syntax described in RFC 1035 [3] section letters and conform to the syntax described in RFC 1035 [3] section
3.1. The sub-option is encoded as follows: 3.1. The sub-option is encoded as follows:
Code Len Kerberos Realm Name Code Len Kerberos Realm Name
+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+ +-----+
| 6 | n | k1 | k2 |...| kn | | 6 | n | k1 | k2 |...| kn |
+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+ +-----+
8.6. TSP's Ticket Granting Server Utilization Sub-Option
5.6. TSP's Ticket Granting Server Utilization Sub-Option
This sub-option encodes a boolean value which indicates whether an This sub-option encodes a boolean value which indicates whether an
MTA should or should not utilize a TGT (Ticket Granting Ticket) when MTA should or should not utilize a TGT (Ticket Granting Ticket) when
obtaining a service ticket for one of the PacketCable application obtaining a service ticket for one of the PacketCable application
servers. The encoding is as follows: servers. The encoding is as follows:
Code Len Value Code Len Value
+-----+-----+-----+ +-----+-----+-----+
| 7 | 1 | 1/0 | | 7 | 1 | 1/0 |
+-----+-----+-----+ +-----+-----+-----+
The length MUST be 1. The last octet contains a Boolean value which The length MUST be 1. The last octet contains a Boolean value which
MUST be either 0 or 1. A value of 1 MUST be interpreted as true. A MUST be either 0 or 1. A value of 1 MUST be interpreted as true. A
value of 0 MUST be interpreted as false. value of 0 MUST be interpreted as false.
8.7. TSP's Provisioning Timer Sub-Option 5.7. TSP's Provisioning Timer Sub-Option
The provisioning timer defines the maximum time allowed for the MTA The provisioning timer defines the maximum time allowed for the MTA
provisioning process to complete. If this timer expires before the provisioning process to complete. If this timer expires before the
MTA has completed the provisioning process, the MTA should reset the MTA has completed the provisioning process, the MTA should reset the
timer and re-start its provisioning process from the beginning. timer and re-start its provisioning process from the beginning.
The sub-option length MUST be 1 and a value between 1 and 30 The sub-option length MUST be 1. The value octet specifies 0 to 255
(minutes, inclusive) MUST be used. If any other value is specified, minutes. A value of 0 means the timer MUST be disabled.
the MTA MUST treat the sub-option as non-populated.
Code Len Value Code Len Value
+-----+-----+---------+ +-----+-----+---------+
| 8 | 1 | (1..30) | | 8 | 1 | (0..255)|
+-----+-----+---------+ +-----+-----+---------+
9. Informational Description of CCC Option Usage. 6. Informational Description of CCC Option Usage.
Cablelabs client devices issue DHCP requests that include DHCP Cablelabs client devices issue DHCP requests that include DHCP
options 55 (Parameter Request List) and 60 (Vendor Class options 55 (Parameter Request List) and 60 (Vendor Class Identifier).
Identifier). Option 55 will request the CCC option from the DHCP Option 55 will request the CCC option from the DHCP server. Option
server. Option 60 will indicate the specific Cablelabs client 60 will indicate the specific Cablelabs client device type, thus
device type, thus directing the DHCP server to populate specific CCC directing the DHCP server to populate specific CCC sub-option content
sub-option content in its responses. The details of which CCC sub- in its responses. The details of which CCC sub-options are populated
options are populated for each specific client type are specified in for each specific client type are specified in various Cablelabs
various Cablelabs project specifications. For example, specific project specifications. For example, specific usage of the CCC
usage of the CCC option for the PacketCable project is described in option for the PacketCable project is described in [7].
[7].
Note that client devices never populate the CCC option in their DHCP Note that client devices never populate the CCC option in their DHCP
requests. requests.
10. IANA Considerations 7. IANA Considerations
IANA has assigned a value of TBD for the DHCP option code described IANA has assigned a value of 122 for the DHCP option code described
in this document. in this document.
11. Legacy Use Information 8. Legacy Use Information
The CableLabs Client Configuration option initially used the site- The CableLabs Client Configuration option initially used the site-
specific option value of 177 (0xB1). The use of the site-specific specific option value of 177 (0xB1). The use of the site-specific
option is to be deprecated when IANA issues an official option option is to be deprecated now that IANA has issued an official
number. option number.
12. Procedure for Adding Additional Sub-options 9. Procedure for Adding Additional Sub-options
IANA is requested to maintain a new number space of "CableLabs IANA is requested to maintain a new number space of "CableLabs Client
Client Configuration Sub-options", located in the BOOTP-DHCP Configuration Sub-options", located in the BOOTP-DHCP Parameters
Parameters Registry. The initial sub-option codes are described in Registry (http://www.iana.org/assignments/bootp-dhcp-parameters).
section 7 of this document. The initial sub-option codes are described in section 4 of this
document.
IANA is requested to register codes for future CableLabs Client IANA is requested to register codes for future CableLabs Client
Configuration Sub-options via an "IETF Consensus" approval policy as Configuration Sub-options via an "IETF Consensus" approval policy as
described in RFC 2434 [2]. described in RFC 2434 [2].
13. Security Considerations 10. Security Considerations
Potential exposures to attack in the DHCP protocol are discussed in Potential exposures to attack in the DHCP protocol are discussed in
section 7 of the DHCP protocol specification [6] and in section 7 of the DHCP protocol specification [6] and in
Authentication for DHCP Messages [9]. Authentication for DHCP Messages [9].
The CCC option can be used to misdirect network traffic by providing The CCC option can be used to misdirect network traffic by providing
incorrect DHCP server addresses, incorrect provisioning server incorrect DHCP server addresses, incorrect provisioning server
addresses, and incorrect Kerberos realm names to a Cablelabs client addresses, and incorrect Kerberos realm names to a Cablelabs client
device. This misdirection can lead to several threat scenarios. A device. This misdirection can lead to several threat scenarios. A
Denial of Service (DoS) attack can result from address information Denial of Service (DoS) attack can result from address information
being simply invalid. A man-in-the-middle attack can be mounted by being simply invalid. A man-in-the-middle attack can be mounted by
providing addresses to a potential snooper. A malicious TSP can providing addresses to a potential snooper. A malicious TSP can
steal customers from the customer selected TSP, by altering the steal customers from the customer selected TSP, by altering the
Kerberos realm designation. Kerberos realm designation.
These threats are mitigated by several factors. These threats are mitigated by several factors.
Within the cable delivery architecture required by PacketCable, the Within the cable delivery architecture required by PacketCable, the
DHCP client is connected to a network through a cable modem and the DHCP client is connected to a network through a cable modem and the
CMTS (head-end). The CMTS is explicitly configured with a set of CMTS (head-end). The CMTS is explicitly configured with a set of
DHCP servers to which DHCP requests are forwarded. Further, a DHCP servers to which DHCP requests are forwarded. Further, a
correctly configured CMTS will only allow downstream traffic from correctly configured CMTS will only allow downstream traffic from
specific IP addresses/ranges. specific IP addresses/ranges.
Assuming that server addresses and Kerberos realm name were Assuming that server addresses and Kerberos realm name were
successfully spoofed to the point that a malicious client device was successfully spoofed to the point that a malicious client device was
able to contact a KDC, the client device must still present valid able to contact a KDC, the client device must still present valid
certificates to the KDC before being service enabled. Given the certificates to the KDC before being service enabled. Given the
computational overhead of the certificate validation process, this computational overhead of the certificate validation process, this
situation could present a DoS opportunity. situation could present a DoS opportunity.
Finally, it is possible for a malicious (although certified) TSP to Finally, it is possible for a malicious (although certified) TSP to
redirect a customer from the customer's selected TSP. It is assumed redirect a customer from the customer's selected TSP. It is assumed
that all TSP's permitted onto an access providers network are that all TSP's permitted onto an access providers network are trusted
trusted entities that will cooperate to insure peaceful coexistence. entities that will cooperate to insure peaceful coexistence. If a
If a TSP is found to be redirecting customers, this should be TSP is found to be redirecting customers, this should be handled as
handled as an administrative matter between the access provider and an administrative matter between the access provider and the TSP.
the TSP.
14. References 11. References
14.1. Normative 11.1. Normative References
1. S. Bradner, "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
2. T. Narten and H. Alvestrand, "Guidelines for Writing an IANA [2] Narten, N. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
3. P. Mockapetris, "Domain Names - Implementation and Specification [3] Mockapetris, P., "Domain Names - Implementation and
", RFC 1035, November 1987 Specification", STD 13, RFC 1035, November 1987.
4. T. Lemon and S. Cheshire, "Encoding Long Options in the Dynamic [4] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
5. J. Kohl and C. Neuman, "The Kerberos Network Authentication [5] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993. Service (V5)", RFC 1510, September 1993.
6. R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997. 1997.
14.2. Informational 11.2. Informative References
7. "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV- [7] "PacketCable MTA Device Provisioning Specification", PKT-SP-
I05-021127. http://www.packetcable.com/specifications.html PROV-I05-021127. http://www.packetcable.com/specifications.html
8. "PacketCable Security Specification", PKT-SP-SEC-I07-021127, [8] "PacketCable Security Specification", PKT-SP-SEC-I07-021127,
http://www.packetcable.com/specifications.html http://www.packetcable.com/specifications.html
9. R. Droms and W. Arbaugh, "Authentication for DHCP Messages", RFC [9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC
3118, June 2001 3118, June 2001
15. Acknowledgments
12. Acknowledgments
The authors would like to extend a heartfelt thanks to all those who The authors would like to extend a heartfelt thanks to all those who
contributed to the development of the PacketCable Provisioning contributed to the development of the PacketCable Provisioning
specifications: specifications:
Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris, Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris,
Rodney Osborne (Arris Interactive); Steven Bellovin and Chris Melle Rodney Osborne (Arris Interactive); Steven Bellovin and Chris Melle
(AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria Stachelek, (AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria Stachelek, Matt
Matt Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Paul
Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter (General
(General Instrument/Motorola); Roger Loots, David Walters (Lucent); Instrument/Motorola); Roger Loots, David Walters (Lucent); Peter
Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay
Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Prithivraj
Prithivraj Narayanan (Wipro). Narayanan (Wipro).
The authors would also like to extend a special "thank you" to Rich The authors would also like to extend a special "thank you" to Rich
Woundy (Comcast) for his thoughtful inputs. Woundy (Comcast) for his thoughtful inputs.
16. Author's Addresses 13. Authors' Addresses
Burcak Beser Burcak Beser
Juniper Networks Juniper Networks
1194 North Matilda Avenue 1194 North Matilda Avenue
Sunnyvale, CA, 94089 Sunnyvale, CA, 94089
Email: burcak@juniper.net
EMail: burcak@juniper.net
Paul Duffy Paul Duffy
Cisco Systems Cisco Systems
300 Apollo Drive 300 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
Email: paduffy@cisco.com
17. Full Copyright Statement EMail: paduffy@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved. 14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 85 change blocks. 
204 lines changed or deleted 201 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/