RE: [dhcwg] DHCP Option for CableLabs Client Configuration

[Ralph Droms <[e-mail]>]

Patrick -

In response to the question at the beginning of your second paragraph, the CMTS is responsible for preventing DHCP server spoofing.  See section 4 of "Cable Modem Termination System – Network Side Interface Specification", SP-CMTS-NSII01-960702.

- Ralph

At 02:34 PM 8/2/2002 -0700, Cosmo, Patrick wrote:

The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM.  The CM passes this list to the MTA  (both devices live in the same physical box).
[Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA?
 
You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure.
 
  The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses.  See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf" rel="nofollow">http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS infrastructure.  The access provider is permitting other business entities to layer services atop its network.  The access provider will have less control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure.  It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones.  Not good if your house is burning down and you need to call the fire department.

Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options.

-----Original Message-----

From: Paul Duffy [mailto:[e-mail]]

Sent: Thursday, August 01, 2002 4:01 PM

To: Erik Nordmark

Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; [e-mail];

[e-mail]; [e-mail]; Matt Osman

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

Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.

2. Some MSO's may decide to deploy DNS on non standard ports.  Its a

flexibility issue.

3. Not using a standard port makes it slightly less prone to attack by

script kiddies.

...I'm out of arguments.   What specific suggestions do you have would give

us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:

> > 1.  A primary use case is for testing/lab/trial deployments.  The only way

> > to configure an MTA (a headless, embedded device) for a non standard port

> > number would be via the CCC sub-option 4/5 mechanism.

>

>That seems like an argument for perhaps an experimental RFC, but

>as I understand it the intent is to make this specification a proposed

>standard.

>

> > 2. Permitting protocol servers to run on a non standard port is not

> without

> > precedence.  Its been pointed out that Paul Vixie's "named" server allows

> > it to be configured on a specific port. Does this mean that Paul is

> > violating Internet Standards ?  Come to think of it, I don't think I've

> > ever seen a protocol server that did not permit configuration of its

> > protocol port.

>

>I don't think anybody has claimed that servers must always use the

>standard port number.

>

>Instead the issue seems to be that the sole reason that these suboptions

>are needed i.e. why the standard DHCP options for DNS servers are not

>sufficient. is the claimed need to support non-standard port numbers.

>

>Why invent a new standard mechanism for this, especially since the utility

>is limited to testing/lab/trials?

>

>   Erik

--

Paul Duffy

Cisco Systems, Inc.

[e-mail]

_______________________________________________

dhcwg mailing list

[e-mail]

https://www1.ietf.org/mailman/listinfo/dhcwg" rel="nofollow">https://www1.ietf.org/mailman/listinfo/dhcwg

--

Paul Duffy

Cisco Systems, Inc.

[e-mail]