Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 22 Jul 2002 11:25:38 -0500

Ralph:

A few likely minor comments regarding this draft:

1. In section 6, it says:

   It should be noted that, although the CCC option will be initially 
   deployed to support PacketCable VOIP applications, the CCC option 
   will also be used to support various non VOIP applications. Use of 
   the CCC option does not necessarily mean that the service provider is 
   a TSP.

Should something be said as to how the DHCP server could distinguish the
various applications so that it only provides the options required for
that particular application (or applications)? I'm primarily concerned
here with the size of the packets and also with the DHCP server providing
unnecessary information (or potentially leaking undesired information) to
other clients.

2. There is basically no information on how clients and servers should
use this option. It says:
    
   9.   Typical use of the CableLabs Client Configuration Option  
    
   Specific usage of the CableLabs Client Configuration option is 
   described in [7].     

While this document may be publicly available, I think the draft should
indicate some basic rules as to when a client requests this option and when
a server sends it (such as only if requested). Perhaps material from the
referenced document can be extracted?

3. As this option could carry a lot of data, it might be good for the I-D
to reference the concatenation handling (draft-ietf-dhc-concat-04.txt).

4. While I have no particular issue with how these suboption numbers are
assigned (by CableLabs), it does seem a bit odd to have two registries of
this information. The following text in 12 seems somewhat contradictory?

   IANA is requested to register codes for future CableLabs Client 
   Configuration Sub-options with an "Expert Review" approval policy as 
   described in RFC 2434 [3]. Future proposed sub-options will be 
   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. 

IANA is really just keeping the record of assigned numbers and not doing
the registry process. This also likely will mean some numbers will be used
without any Internet-Drafts/RFCs ever existing (since CableLabs can assign
numbers without the existence of these documents).

It might be best to just remove IANA's roll here? If an ID or RFC exists,
it documents the suboptions?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 8:07 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [dhcwg] DHCP Option for CableLabs Client Configuration

The DHC WG reviewed "DHCP Option for CableLabs Client Configuration" 
<draft-ietf-dhc-packetcable-02.txt> at the WG meeting in Yokohama.  This 
document is a revision of a spec that has been in front of the WG for a 
while.  CableLabs wants to publish the spec as an RFC and obtain an 
IANA-assigned option code.

Although the WG has seen this specification before, the current draft had 
not been sufficiently reviewed to go to WG last call.  There are several 
changes in the spec that bring it into line with standard DHCP practice for 
the definition of options and sub-options.

Note that this spec defines a slightly different model for assigning 
sub-option codes than is used for other options.  This model is defined to 
coordinate with the CableLabs standards process.

Please read the draft and send comments to the WG mailing list. I expect to 
start a WG last call on the document next Wednesday (7/24).

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Mon, 29 Jul 2002 15:10:17 -0400

I too, just reviewed this document has have some questions/comments.

I agree with Bernie that it's underspecified, and just pointing to the
other documents is insufficient. There should be enough text in this
document so that a DHC implementor can figure out what to do.

1) It's not clear who sends/uses the options (i.e., the MTS or
   CM). 

2) Its also not clear just what the CM does. Is it being a relay agent
that routes DHC packets from MTA's differently than normal DHC
packets?  Reading between the lines a bit, is the following happening?

a) the CM boots first, and requests (and receives?) sub-options 1 & 2.

b) any DHC request from the MTA goes through the CM (the CM is in
effect a relay agent) and the CM relays the DHC request to the DHC
server it learned in step a). The CM knows when it is relaying a MTA
option because the MTA includes a CCC option.

Is my understanding anywhere near correct at this point? (I have more
questions, but the specific questions depend on whether my
understanding is anywhere near correct at this point).

c) the response from the server to the MTA includes some combination
of the remaining suboptions.

3) There are some kerberos-specfic sub-options here. I wonder if they
   make sense from the kerberos perspective (and will try to find
   someone who can answer). Reason I say this is I'm aware of an older
   kerberos ID that put Realm information into a  DNS RR, and the
   realm field was NOT the same as an FQDN (as this ID says it will
   be)

4) Options 4 & 5 don't make sense to me immediately. Why would the MTA
   need special DNS servers (as opposed to just using the ones through
   it's ISP?) And, why can't the normal DNS server option be used
   here? If the MTA's DHC requests get routed to the TSP-specific DHC
   server, it can know to return an appropriate DNS server. Why is a
   special suboption needed? 

5) I find it odd that there are retransmission controlling timer
   settings being communicated via DHC. Is there something broken in
   Kerberos that requires that standard values be overridden?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 30 Jul 2002 09:15:57 -0400

Paul,

> 1. On the advice of several DHCP and Cablelabs experts, we specifically did 
> not duplicate Cablelabs specification content in this draft.  We decided to 
> define CCC sub-option syntax and content in the draft, with specific 
> Cablelabs specifications elaborating on exactly how and when the CCC 
> sub-options are used.  The idea is to avoid significant duplication of text 
> and the inevitable synchronization problems that would result between 
> multiple documents.

I agree that duplication of text is not a good idea. But this document
could include enough background information and details so that one
could implement/review it without having to look at the other
document. I.e, *this* document should make it clear what the DHCP
operations are. The other document can indicate how the values in the
option are to  be used.

Looking at the other  document, I see now that:

1) The DHC server is supposed to include the CCC option in its
   Advertise. The MTA uses that information in selecting a
   server. This is normal DHCP, and the document  could easily make
   this part clear.

1a) the client identifies itself with a "user class" option, this
    allows the DHC server to know to include the CCC option. Correct?
    In any case, the document could easily make it clear what the
    normal steps are here.

2) Once the MTA has chosen a server, it seems to me like normal DHCP
   would apply. At this point, some of the specific options don't make
   sense (or maybe this is a wording thing).

>       |    4    |  MTA    | TSP's Primary Domain Name Server Address   |  
>       +---------+---------+--------------------------------------------+  
>       |    5    |  MTA    | TSP's Secondary Domain Name Server Address |  

Is there ever a reason for the MTA to use a "normal" DNS server
vs. the "TSP DNS"? I would assume not. Thus, the above option appears
redundent with the normal DHC option for identifying DNS servers. Can
someone clarify here if this is/is not the case?

3) It's not immediately clear whether/how the CM uses these
   options. They seem specific to the MTA.  Does the CM use these
   options?

4)

>      |    9    |         | Reserved for future CableLabs use          |  
   
I find it odd that this document says "reserved", when the cablelabs
document pretty clearly defines this option and what it means. Please
clarify.

5)

>   8.1. TSP's DHCP Server Address Sub-Options

There are number of formats, some of which include a port number. It
appears the MTA takes the DHC server address and sends followup DHC
messages to *that* particular server (possibly at a redirected port).

This seems like a change to basic DHC behavior on the client. Seems to
me that this is inappropriate and unnecessary (at least in some
cases). Also, I find it unfortunate that someone outside of the IETF
seems to be specifying behavior that changes basic DHCP behavior.

First, to redirect the client to a specific DHC server, it would seem
better to just have the MTA client pick the server based on the DHC
advertisement. This can already be done in DHC today. (i.e, the client
just uses the server that sent an advertisement that the MTA liked.)
No special option is needed.

*If* the DHC WG thinks that modifying the basic DHC client processing
rules in order to redirect the client to other servers (and ports) via
a specific option is a good idea, it would be better for the WG to
define a general way of doing this.

Seems to me that Cablelabs is extending/modifying basic DHC processing
rules inappropriately, something that the IETF/DHC WG should retain
control over.

I'd like to better understand the requirements here.

> A PacketCable MTA's realm name and domain name are not the same.  A 
> PacketCable deployment will typically be a large, multi vendor 
> situation.  The authentication realms and domain name space are kept 
> separate.

This is not what I read the document to say:

>    8.4. TSP's Kerberos Realm Name Sub-Option  
>         
>    The PacketCable architecture requires an MTA to authenticate itself 
>    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 
>    the TSP's Kerberos Key Distribution Center (KDC) entity.  
>             
>    The Kerberos Realm name is an FQDN.  The sub-option is encoded as 
>    follows: 

I read the above as the Realm name is a FQDN. Please clarify.    

> >    it's ISP?)

> The PacketCable specs draw a hard line between data access provider and 
> telephony service provider.  The access provider is responsible for 
> provisioning the CM, the telephony service provider provisions the 
> MTA.  These two business entities are assumed to have their own DHCP and 
> DNS infrastructure.

OK. But I think there may be cleaner ways of doing this (using
existing DHC mechanisms) than the proposed options.

> >And, why can't the normal DNS server option be used

> CCC sub-options 4/5 allow an optional port number where the standard DNS 
> options do not.

How important is this? Is this critical?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 30 Jul 2002 15:19:40 -0400

> We could add a paragraph or two describing, in general terms, that the DHCP 
> client requests the CCC option and provide option 60 to identify its client 
> type to the server...the server then determines the CCC sub-option content 
> that would be included in responses.

This would be helpful.

> But we would defer to the specific Cablelabs specifications to
> define the exact sub-option content in the responses. How does that
> sound ?

Could you give an example? Are you talking about removing all the text
from the current ID? I'm not sure I'm in favor of that either.

> Again, sub-options 4 and 5 permit port numbers.  Normal DNS options
>  do not...

Some comments.

First, let's consider the case where the port number version is not
used, i.e., DNS servers are accessed at the normal port numbers. In
this case, how does this option differ from option 6 (the standard
Domain Option)? My sense (from what I understand) is they are the
same. In that case, I would say use that option and don't even define
a sub-option that allows specification of the DNS server without a
port number. No need to define a redundant option.

Second, there has apparently not been an issue in general with the
Domain Option not specifying an alternate port number, presumably
because its not required in general. Why is it required in your spec?
Just saying "it's a requirement" isn't very illuminating.

> Per the PacketCable specs, MTA uses sub-option 4/5.  See the provisioning 
> flows in the MTA prov spec (referenced in the draft).

I just looked at the MTA provising draft. It is not at all clear to me
that the CM needs any of these sub-options. Can you please point me to
the sections in the document that explain how the CM uses them and
what specific sub-options it uses?

> The PacketCable MTA prov spec is incorrect.  It will be updated soon. 
> Sub-option 9's usage was dropped just prior to the draft's posting.  The 
> draft is correct and authoritative regarding sub-option 
> definitions/syntax.  Any duplication of the draft's text in the PacketCable 
> specs will soon be removed.

OK. But I will note that the classification of the document is
"ISSUED" (per the cover page), which corresponds to

     "A stable document, which has undergone rigorous member and vendor
     review and is suitable for product testing and development, cross-vendor
     interoperability, and for certification testing."

Can you clarify what the next steps for the document are and when it
will get updated?     

> Sub-options 1 and 2 are the mechanism via which the access provider
> strictly controls which business entities are permitted to offer
> telephony service over its network.  This is described in the
> PacketCable MTA prov spec.

Right. In other words, the MTA needs to use a special DNS server and
get special client-specific configuration. What I don't quite
understand is why that requires Cablelabs-specific options. This seems
(mostly) doable with standard DHCP. In that case, I'd prefer that
approach be used to just defining a bunch of specific (redundant)
options.

Specifically, if the client includes in its Discover with an "I'm a
MTA" option, and the DHC servers return an "I'm a MTA DHC server"
(which the client then selects), this is all fine and consistent with
DHC. From that point on, the MTA DHC server can send it normal
options, and those will be interpreted as the ones that the MTA should
use. You don't need a special option that says "MTA must use this DNS
server rather than the regular server".

I'd like to understand what is wrong with the above reasoning.

> Do sub-options 1 and 2 really constitute "modifying the basic DHC
> client" and "changing basic DHCP behavior"?

IMO, Yes. They modify the way the DHC client behaves. Note that DHC
clients today can select the server based on what it advertises. But
the option you've defined changes that in the following way:

  - it doesn't say "chose this server that sent you the offer", it
    seems to say "choose the server whose address is encoded in the
    sub-option". That's a very different semantic

  - or, it says, from now on, use a different port number when sending
    DHCP requests (again, a *very* different semantic).

> Cablelabs and the several dozen companies that have vetted this
> draft have absolutely no interest in anything but standard
> protocols.  There are several prototype DHCP servers and multiple
> clients running this draft.  This is the first mention that
> Cablelabs has distorted the basic DHCP protocol.

That is why it is important to get DHCP options reviewed within the
IETF, where the DHCP experts are.

> We look to the DHCP gurus for further guidance here...but PacketCable 
> requires an "iron fist" mechanism that allows the access provider to 
> control who is allowed to offer telephony service over its network.

I believe that normal DHCP does this already. I don't understand how
the proposed extensions are needed (at least in the case of the DHC
and DNS options).

> Its a requirement of the PacketCable architecture.

Why? How important a requirement? Its clearly not needed in all
cases, since some forms of the option do not include a port number.

Thomas

---

From: Paul Duffy <[email-masked]>
Date: Mon, 29 Jul 2002 17:00:55 -0400

Thomas/Bernie,

A few points of clarification:

2. CableLabs specifications that employ the CCC option (PacketCable, 
CableHome, etc.) describe specific CCC option usage. CCC client devices use 
DHCP option 60 to identify the "client type" or "project", thus telling the 
DHCP server which CCC sub-options it should be populating in its responses.

>1) It's not clear who sends/uses the options (i.e., the MTS or

Per comments above...this information is included in the Cablelab's 
specs.  It was decided to refer to the external spec rather than repeat the 
information in the draft.

>packets?

No.  The CM is not specified to behave as a relay agent.

>Reading between the lines a bit, is the following happening?
>

Correct, from the access provider's infrastructure...

>option because the MTA includes a CCC option.

No.  The CM is not specified to behave as a relay agent.

>of the remaining suboptions.

...correct.  Sub-option content is determined by the content of option 60 
(in the request)

>    Kerberos that requires that standard values be overridden?

They are present to allow boot time configuration of corresponding MIB 
objects on a device.  For finer grained control....

>Thomas

I hope this helps.  Please let me know if there are any other points I 
might clarify.

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Paul Duffy <[email-masked]>
Date: Tue, 30 Jul 2002 16:17:58 -0400

Thomas...inline....

>I read the above as the Realm name is a FQDN. Please clarify.

Looks like we need to correct this section of the draft.  It should say the 
Kerberos Realm name should be encoded per RFC 1510.  The Kerberos Realm 
name is not an FQDN.

Cheers,
--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Paul Duffy <[email-masked]>
Date: Tue, 30 Jul 2002 12:48:58 -0400

Hi Thomas...inline please...

>operations are. The other document can indicate how the values in the

Again, we were advised not to do this.  This would require significant 
additions be made to the draft (per multiple Cablelabs projects).  This 
would become a large, difficult synchronization headache.

We could add a paragraph or two describing, in general terms, that the DHCP 
client requests the CCC option and provide option 60 to identify its client 
type to the server...the server then determines the CCC sub-option content 
that would be included in responses.  But we would defer to the specific 
Cablelabs specifications to define the exact sub-option content in the 
responses. How does that sound ?

>someone clarify here if this is/is not the case?

Again, sub-options 4 and 5 permit port numbers.  Normal DNS options do not...

Sub-options 1 and 2 are the mechanism via which the access provider 
strictly controls which business entities are permitted to offer telephony 
service over its network.  This is described in the PacketCable MTA prov spec.

Do sub-options 1 and 2 really constitute "modifying the basic DHC client" 
and "changing basic DHCP behavior"?  Cablelabs and the several dozen 
companies that have vetted this draft have absolutely no interest in 
anything but standard protocols.  There are several prototype DHCP servers 
and multiple clients running this draft.  This is the first mention that 
Cablelabs has distorted the basic DHCP protocol.

>I read the above as the Realm name is a FQDN. Please clarify.

I need to review this point.  I'll get back to you shortly...

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 31 Jul 2002 03:26:43 +0200 (CEST)

> Its a requirement of the PacketCable architecture.

In the Internet architecture the DNS servers/resolvers use a standard port
number. Thus it seems like the PacketCable architecture doesn't conform
to the Internet architecture. 

This sure looks odd.

Are we (the WG and the IETF) reviewing this draft supposed to blindly agree
with the packetcable architecture? Or are we supposed to review that
architecture first?

Confused
  Erik

---

From: Paul Duffy <[email-masked]>
Date: Wed, 31 Jul 2002 15:15:08 -0400

Thomas,

The high level issues you've raised...

1. Suggested text addition to the draft...generally describe how the CCC 
option is used....

"Cablelabs client devices will issue DHCP requests that include options 55 
and 60.  Option 50 will request the CCC option from the DHCP 
server.  Option 60 will specify the specific Cablelabs client type, thus 
directing the DHCP server to populate specific CCC sub-option content in 
its responses.  The details of which CCC sub-options are populated for each 
specific client type are spelled out in the various Cablelabs project 
specifications.  For example, the PacketCable MTA Device Provisioning 
Specification [ref] defines the specific set of CCC sub-options that must 
be populated in DHCP responses to CMs and MTAs in a PacketCable deployment."

The point here is that different Cablelabs client devices will use a 
different set of CCC sub-options.  I don't think we want to get into cross 
pollinating the various specifications.  The CCC option draft describes 
"what" the option is, the specific Cablelabs specs describe "when" and 
"how" its used.

2. General PacketCable provisioning flow (as it relates to the CC 
option).  This is a boiled down version of section 7 of the MTA prov 
spec.  I'm NOT suggesting this gets added to the draft.

PacketCable device provisioning proceeds as follows.

DOCSIS 1.1 provisioning steps:

a. CM issues broadcast discover which includes option 60 of "docsis1.1:..." 
and requests CCC option in option 55.
b. One or more offers arrive at the CM.  The offers MUST include the CCC 
option w/ sub-options 1/2.
c. CM selects one of the offers containing the CCC option and completes the 
DHCP exchange.
d. CM completes the rest of its DOCSIS provisioning process.

The key here is that the access provider's tightly controlled DHCP 
infrastructure sends the CM a specific list of valid, legal, PacketCable 
DHCP/DNS/SNMP server addresses for a specific service 
provider.  PacketCable 1.0 scopes Embedded MTAs only, meaning the CM and 
MTA physically reside in an integrated box.  The CCC sub-option 1/2 info is 
transferred by the CM component to the MTA component (how this occurs is 
implementation specific).

This is the mechanism via which the access provider strictly controls which 
business entities are allowed to offer PacketCable service (or any other 
type of service) over its network. It also permits the access provider to 
direct a specific device to a specific service provider....you can have 
multiple PacketCable service providers on the same access network.

Continuing...

PacketCable 1.0 provisioning steps:

e.MTA issues broadcast discover which includes option 60 of "pktc1.0:..." 
and requests CCC option in option 55.
f. One or more offers arrive at the MTA.  These offers must include the CCC 
option with sub-options 3, 4, 6 (5, 7, 8, 10, 11 are optional) to be 
considered "valid".
g. The MTA selects a valid offer from the set of DHCP servers identified in 
CCC sub-option 1/2.
h. MTA completes the rest of the DHCP exchange
i. MTA completes the rest of the secure provisioning steps

The access providers are assumed to be offering multiple types of services 
(from different business entities) over their data network.  The CCC 
options 1 through 5 are used by the access providers to direct the various 
client types to a restricted set of infrastructure servers that support the 
specific service type from a specific service provider.  It was felt that 
this approach also makes the system a bit more difficult to hack.

4. Port numbers on CCC sub-options 1/2/3/4/5

Don't what more I can add here.  This has been in the architecture since 
day one...additional control for the service providers.  Your comment 
suggesting "if no port number, use DHCP option 6, if port number, use CCC 
sub-option 4/5"... as a developer...I'd rather just deal with the single 
CCC sub-option 4/5 and leave it at that.  The implementation would be 
simpler (for both client and server).

5. Cablelabs specification development process.

Specifcations start out as Works In Progress. Essentially, discussion 
documents.
Following initial agreement by the participants, the WIP goes to a Draft 
status (D0x).  Protoypes are typically developed at this stage.
When everyone is satisfied that the Draft will actually work, the spec goes 
to a Interim stage (I0x).  At this point the spec goes under rigorous 
change control and multiple vendors come out for compliance wave testing at 
the Cablelabs facility (essentially, a rigorous  bake-off).

Its typical that a specification will go through several I0x stages.

Specifically, the PacketCable MTA prov spec is just now coming up on its 
I04 release.  We will be filing change requests on I04 to clean up the 
sections that deal with the CCC option.

Matt Osman from Cablelabs will have to comment if you need more detail here.

Helps ?

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]