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

[Paul Duffy <[e-mail]>]

At 05:53 PM 10/16/2002 -0400, [e-mail] wrote:

>My understanding per RFC 2131 was that when client receives offers from 
>multiple offers for DHCP Broadcast, the client can select a DHCP and send 
>a unicast request to the DHCP the client selects. Couldn't the MTA do a 
>unicast message to the TSP's DHCP server using the DHCP address the MTA 
>receives from the cable modem. I tend to think that this will eliminate 
>tearing up the DHCP protocol for PacketCable MTA.

Pall,

I am not understanding how a PacketCable MTA is "tearing up" the DHCP 
protocol.  Please elaborate...


>I would think, this would be easy for vendore to implement also since it 
>is within RFC 2131. Am I missing somethings here.
>
>My opinions are mys own and has nothing to do with my employer.
>
>
>Pall Ramanathan
>
>
>
>
>
>
>Paul Duffy <[e-mail]>
>Sent by: [e-mail]
>
>10/16/2002 03:26 PM
>
>         To:        Thomas Narten <[e-mail]>
>         cc:        [e-mail]
>         Subject:        Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt
>
>
>Hello Thomas,
>
>Please find responses inline...formed from several conversations with
>various PacketCable participants.
>
>I'll try to have a new draft ready for next week.  We'd greatly appreciate
>your effort to keep this moving along swiftly.
>
>Cheers,
>
>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.
> >
> >Thomas
> >
> > >   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?)
>
>RFC 2131 Section 4.4.1 "The time over which the client collects messages
>and the mechanism used to select one DHCPOFFER are implementation
>dependent".   PacketCable does not feel CCC.1/.2 in any way modifies the RFC.
>
> > >    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.
>
>No, an MTA DHCP client never populates CCC option content into its any if
>its requests.  The PacketCable MTA provisioning  specification (section 7)
>contains detailed descriptions of when the CCC option is/is not populated
>into DHCP messaging.
>
>PacketCable's intent is to specify option syntax in the draft/RFC, while
>referring to the PacketCable MTA prov specification for usage
>details.  Otherwise, we're going to end up pulling large pieces of the
>PacketCable provisioning spec into this draft...lots of duplication between
>the documents (which I thought we agreed was undesirable).
>
>That said, I can add a sentence or two stating that the client never
>populates CCC option content into DHCP request messages.
>
> >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
> >sense.
>
>As stated in the IETF draft writer's guidelines and the beginning of the
>our draft..."It is inappropriate to use Internet-Drafts as reference
>material or to cite them other than as work in progress".  I took this to
>mean referencing non RFC docs is prohibited.  Attempting to maximize the
>speed at which this draft might progress through the IETF process, I tried
>to adhere as faithfully as possible to those guidelines...PacketCable did
>not consider ANY drafts for reference within this draft.
>
>If you feel inclusion of this draft is a hard requirement, PacketCable will
>have to open this issue with the manufacturers...further delaying the
>progress of this draft (not good for us).  I'm also going to need an RFC #
>for the ref ?
>
> > >    - 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.)
>
>Agreed. PacketCable will state compression "is/is not" allowed in the draft
>(following discussion with the MTA manufacturers).
>
> >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?
>
>Agreed. No additional values are planned. PacketCable will state "IANA does
>not need to maintain a registry".
>
> >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.)
>
>This is a specific need of a PacketCable MTA.  It does not present any
>issues with the Kerberos RFCs.  The CCC option is, by definition, Cablelabs
>specific, so PacketCable does not see this causing any issues with non
>Cablelabs devices.
>
> >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:
>
>Agreed, too late.  PacketCable simply can not absorb the delay that would
>result if we split the realm name sub-option out into a distinct DHCP
>option draft.
>
> >"Douglas E. Engert" <[e-mail]> writes:
> >
> > > You should also look at:
> > > " Distributing Kerberos KDC and Realm Information with DNS"
> > > 
> http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt
> >
> > > 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?
>
>1. Agreed, we prefer to stick to the DHCP route.
>2. PacketCable does not see where this draft applies.  This draft appears
>to describe how one uses DNS to turn a realm name into a KDC
>address.  CCC.6 describes how the realm name initially arrives at the MTA .
>3. Again, this would be citing a draft (which I understood to be not
>acceptable)
>
> > >    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
>
>Agreed.  I'll spell out the names.
>
> > >    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)
>
>I'll defer comment on this issue to the Cablelabs folks.
>
> > >    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
> >(privately):
> >
> >Jonathan Trostle <[e-mail]> 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 <[e-mail]> 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
>
>Agree that the security section could use some beefing up.
>
> >Finally, references should be split into normative/non-normative
> >sections.
>
>nit: I have a single reference section primarily because I followed the
>example of many other drafts/RFCs...assuming this would be adequate.
>
>I'll split it.
>
> >_______________________________________________
> >dhcwg mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/dhcwg
>
>--
>
>Paul Duffy
>Cisco Systems, Inc.
>[e-mail]
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>

--

Paul Duffy
Cisco Systems, Inc.
[e-mail]