Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt

Paul Duffy <> Mon, 14 October 2002 16:48 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA25841 for <>; Mon, 14 Oct 2002 12:48:49 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id g9EGoWg10572 for; Mon, 14 Oct 2002 12:50:32 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g9EGoWv10569 for <>; Mon, 14 Oct 2002 12:50:32 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA25831 for <>; Mon, 14 Oct 2002 12:48:18 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id g9EGm8v10393; Mon, 14 Oct 2002 12:48:08 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g9EGlsv10359 for <>; Mon, 14 Oct 2002 12:47:54 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA25642 for <>; Mon, 14 Oct 2002 12:45:41 -0400 (EDT)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA29468; Mon, 14 Oct 2002 12:47:45 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Oct 2002 12:47:39 -0400
To: Thomas Narten <>
From: Paul Duffy <>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Thank you...we'll have a detailed response Wednesday.


At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote:
>Background: there was a quite a lot of private discussion/conference
>calls a month or two ago on this document, followed by a revised
>document. Here is my review of the current document.
> >   8.1. TSP's DHCP Server Address Sub-Options
>Seems to me that this options does (however subtly) modify DHC client
>behavior. My understanding is that CCC option 1/2, which
>lists a primary/backup DHC server are sent to the CM, which then
>communicates those two addresses to the MTA (a separate entity). The
>MTA then invokes DHC on its own, but is only allowed to talk to the
>servers whos addresses it received from the CM. In normal DHC, the
>client isn't restricted in anyway in what servers it communicates
>with. Thus, I would argue that CCC options 1/2 do modify the DHC
>protocol, albeit subtly and perhaps not signficantly. I am not
>particularly comfortable with this, but would like to hear more from
>the WG on this point. (Also, is my understanding here correct?)
> >    Due to specific needs of the MTA configuration process (described in
> >    [5]), a new CableLabs Client Configuration (CCC) option is needed for
> >    the DHCP protocol.  Both CM and MTA DHCP clients will request this
> >    option.  When requested, both the CM and TSP DHCP servers will
> >    populate this option into DHCP responses.
>Doesn't the client also provide this option and fill in some info?
>better to say this above (one or two sentences here would suffice). Or
>maybe just merge Section 9 text into the text here.
>Should this document add a normative references to
>draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so
>referencing it shouldn't be a problem)? Seems like that would make
> >    - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035
> >      [7] section 3.1. Note that a terminating 0 is required.
>is compression allowed? (probably not useful -- then say so.)
>For CCC option 3, does IANA need to maintain a registry for other
>"types"? An IANA considerations would seem to be  needed. It could say:
>  - allocation of future types requires IETF Consensus (or whatever)
>  - there will be no additional values, IANA does not need to maintain
>    a registry
>  - something else?
>The CCC options for configuring Kerberos parameters seems odd to me
>(what kerberos document talks about the need for tuning these
>parameters?). The IESG may want this reviewed by someone with kerberos
>clue. (I'm just saying this so that there are no surprises should this
>issue come up later.)
>Also, the kerberos REALM name option seems like one that could easily
>be more general (i.e, not cablelabs specific). But probably too late
>for this. Also:
>"Douglas E. Engert" <> writes:
> > You should also look at:
> > " Distributing Kerberos KDC and Realm Information with DNS"
> >
> > Which describes how to find a KDC using DNS. I should point out that
> > W2K, MIT and I think Hiemdal all have this implemented.
>I assume that cablelabs is familiar with this but still wants to go
>the DHC route?
> >    Cablelabs client devices issue DHCP requests that include DHCP
> >    options 55 and 60.  Option 55 will request the CCC option from the
>nit: would be good include neumonic names (e.g., ORO and class ID)
>here rather than just using the option number rather than assuming
>everyone knows the option meaning
> >    IANA is requested to register codes for future CableLabs Client
> >    Configuration Sub-options with an "Expert Review" approval policy as
> >    described in RFC 2434 [2]. 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.
>1) I think it should be IETF consensus, not expert review. these
>    options need to be reviewed by the IETF before they get implemented
>    and cast in stone. IETF Consensus is the safest way to ensure that
>    this happens.
>2) IANA chooses the values (as it typically does), not
>    cablelabs. (Having cablelabs chose smells a bit like they want the
>    values early for their implementations and/or specs)
> >    13.  Security Considerations
> >
> >    This draft relies on the DHCP protocol [4] for authentication and
> >    security, i.e. it does not provide in excess of what DHCP is (or will
> >    be) providing. It does not expose any security threats beyond what is
> >    currently exposed by other DHCP options.
>The security considerations section is inadequate. It should say
>something about the options themselves and what the security
>implications are should the options be spoofed, etc. That is, what are
>the security issues related to the specific options discussed in the
>document? Is it required that some sort of DHC authentication be used
>in order to prevent vulnerabilities (say) to the configuration of the
>kerberos stuff?
>Note on the kerberos options, the following comment was made
>Jonathan Trostle <> writes:
> > Section 13 (Security Considerations) indicates they are relying on
> > the DHCP protocol for authentication and security (should be more
> > precise about what security services).
> > If the new option data is manipulated, various DoS attacks are possible.
> > One option, Kerberos realm name, is potentially more serious. By modifying
> > the realm, the attacker can change the user's TSP (if I recall correctly,
> > packetcable uses pkinit where the client authenticates the KDC by the
> > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP
> > can act as a TSP for any user and then have access to the user's VoIP
> > and multimedia data. So it would be a good thing if the Kerberos realm
> > name is protected from modification in the DHCP protocol. Alternatively,
> > changing the realm name could be a means by which one TSP steals customers
> > from another TSP without the customer's permission.
>then later,
>Jonathan Trostle <> writes:
> > Tom,
> > Yes, there should be some extra wording in the security considerations at
> > least. I recall an argument that layer 2 encryption protects the link
> > between the modem and the head end, and the DCHP server may be at the head
> > end. But there should definitely be some words indicating that there is
> > protection for the DHCP messages at some layer. If this draft is used in
> > some other scenario (or even in the packetcable scenario possibly) then 
> there
> > is the potential for security vulnerabilities.
> > Jonathan
>Finally, references should be split into normative/non-normative
>dhcwg mailing list


Paul Duffy
Cisco Systems, Inc.

dhcwg mailing list