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

["Woundy, Richard" <[e-mail]>]

Pall, you need to re-read RFC 2131 again. When a standard DHCP client
chooses an offer, it sends a *broadcast* DHCPREQUEST message which is
relayed to all of the DHCP servers. Here's the relevant text from RFC 2131
section 3.1:
 
  3. The client receives one or more DHCPOFFER messages from one or more
     servers.  The client may choose to wait for multiple responses.
     The client chooses one server from which to request configuration
     parameters, based on the configuration parameters offered in the
     DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected, and that MAY include other options
     specifying desired configuration values.  The 'requested IP
     address' option MUST be set to the value of 'yiaddr' in the
     DHCPOFFER message from the server.  This DHCPREQUEST message is
     broadcast and relayed through DHCP/BOOTP relay agents.  To help
     ensure that any BOOTP relay agents forward the DHCPREQUEST message
     to the same set of DHCP servers that received the original
     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
     value in the DHCP message header's 'secs' field and be sent to the
     same IP broadcast address as the original DHCPDISCOVER message.
     The client times out and retransmits the DHCPDISCOVER message if
     the client receives no DHCPOFFER messages.

-- Rich

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, October 16, 2002 5:54 PM
To: Paul Duffy
Cc: [e-mail]; [e-mail]; Thomas Narten
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt



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. 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