draft-ietf-dhc-packetcable-05.txt   draft-ietf-dhc-packetcable-06.txt 
Internet Engineering Task Force B. Beser Internet Engineering Task Force B. Beser
INTERNET DRAFT Juniper Networks INTERNET DRAFT Juniper Networks
DHC Working Group P. Duffy (ed.) DHC Working Group P. Duffy (ed.)
Document: draft-ietf-dhc-packetcable-05.txt Cisco Systems Document: draft-ietf-dhc-packetcable-06.txt Cisco Systems
December 2002 January 2003
DHCP Option for CableLabs Client Configuration DHCP Option for CableLabs Client Configuration
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 102 skipping to change at line 102
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.
Beser & Duffy Expires June 2003 2 Beser & Duffy Expires July 2003 2
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
skipping to change at line 156 skipping to change at line 156
option. When requested, both the CM and TSP DHCP servers will option. When requested, both the CM and TSP DHCP servers will
populate this option into DHCP responses. See section 9 for further populate this option into DHCP responses. See section 9 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.
Beser & Duffy Expires June 2003 3 Beser & Duffy Expires July 2003 3
7. CableLabs Client Configuration Option Format 7. 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 TBD). 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 | | Code | 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] SHOULD 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 |
skipping to change at line 209 skipping to change at line 209
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
| 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 |
+---------+---------+--------------------------------------------+ +---------+---------+--------------------------------------------+
Beser & Duffy Expires June 2003 4 Beser & Duffy Expires July 2003 4
8. CableLabs Client Configuration Option: Sub-Option Definitions 8. 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 note
that compression, as described in RFC 1035 [3] section 4.1.4, MUST that compression, as described in RFC 1035 [3] section 4.1.4, MUST
NOT be applied. NOT be applied.
- IPv4 addresses MUST be encoded as 4 binary octets in network byte- - IPv4 addresses MUST be encoded as 4 binary octets in network byte-
skipping to change at line 259 skipping to change at line 259
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 |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
Beser & Duffy Expires June 2003 5 Beser & Duffy Expires July 2003 5
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 |
+-----+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+-----+ +-----+
skipping to change at line 303 skipping to change at line 303
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 seconds.
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.
Beser & Duffy Expires June 2003 6 Beser & Duffy Expires July 2003 6
8.4. TSP's AP-REQ/AP-REP Backoff and Retry 8.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 when an AP-REQ/AP-REP message exchange fails. This sub- employed when an AP-REQ/AP-REP message exchange fails. This sub-
option contains parameters required by the backoff/retry mechanism option contains parameters required by the backoff/retry mechanism
outlined in [8]. outlined in [8].
skipping to change at line 350 skipping to change at line 350
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 |
+-----+-----+-----+-----+ +-----+ +-----+-----+-----+-----+ +-----+
Beser & Duffy Expires June 2003 7 Beser & Duffy Expires July 2003 7
8.6. TSP's Ticket Granting Server Utilization Sub-Option 8.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 |
skipping to change at line 399 skipping to change at line 399
device type, thus directing the DHCP server to populate specific CCC device type, thus directing the DHCP server to populate specific CCC
sub-option content in its responses. The details of which CCC sub- sub-option content in its responses. The details of which CCC sub-
options are populated for each specific client type are specified in options are populated for each specific client type are specified in
various Cablelabs project specifications. For example, specific various Cablelabs project specifications. For example, specific
usage of the CCC option for the PacketCable project is described in usage of the CCC 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.
Beser & Duffy Expires June 2003 8 Beser & Duffy Expires July 2003 8
10. IANA Considerations 10. IANA Considerations
IANA has assigned a value of TBD for the DHCP option code described IANA has assigned a value of TBD for the DHCP option code described
in this document. in this document.
11. Legacy Use Information 11. 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 when IANA issues an official option
number. number.
12. Procedure for Adding Additional Sub-options 12. 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 Configuration Sub-options", located in the BOOTP-DHCP Client Configuration Sub-options", located in the BOOTP-DHCP
Parameters Registry. The initial sub-option codes are described in Parameters Registry. The initial sub-option codes are described in
sections of this document. section 7 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 with an "Expert Review" approval policy as Configuration Sub-options via an "IETF Consensus" approval policy as
described in RFC 2434 [2]. Future proposed sub-options will be described in RFC 2434 [2].
assigned a numeric code chosen by CableLabs, which will be
documented in the Internet Drafts that describe the sub-options. The
code assignment will be reviewed by a designated expert from the
IETF prior to publication in an RFC.
13. Security Considerations 13. 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
skipping to change at line 448 skipping to change at line 444
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
Beser & Duffy Expires June 2003 9
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.
Beser & Duffy Expires July 2003 9
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
skipping to change at line 499 skipping to change at line 494
1997. 1997.
14.2. Informational 14.2. Informational
7. "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV- 7. "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV-
I05-021127. http://www.packetcable.com/specifications.html 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
Beser & Duffy Expires June 2003 10
9. R. Droms and W. Arbaugh, "Authentication for DHCP Messages", RFC 9. R. Droms and W. Arbaugh, "Authentication for DHCP Messages", RFC
3118, June 2001 3118, June 2001
Beser & Duffy Expires July 2003 10
15. Acknowledgments 15. 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 Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Matt Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas,
Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter
(General Instrument/Motorola); Roger Loots, David Walters (Lucent); (General Instrument/Motorola); Roger Loots, David Walters (Lucent);
Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar,
Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon);
Prithivraj Narayanan (Wipro); and Rich Woundy (AT&T Broadband). Prithivraj Narayanan (Wipro).
The authors would also like to extend a special "thank you" to Rich
Woundy (Comcast) for his thoughtful inputs.
16. Author's Addresses 16. Author's 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
skipping to change at line 554 skipping to change at line 552
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.
Beser & Duffy Expires June 2003 11 Beser & Duffy Expires July 2003 11
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.
Beser & Duffy Expires June 2003 12 Beser & Duffy Expires July 2003 12
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/