RE: [dhcwg] DHCP Option for CableLabs Client Configuration

["Cosmo, Patrick" <[e-mail]>]

Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not
MTAs? 
 

-----Original Message-----
From: Ralph Droms [mailto:[e-mail]]
Sent: Friday, August 02, 2002 6:18 PM
To: Cosmo, Patrick
Cc: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List; Erik
Nordmark; Thomas Narten; Bernie Volz (EUD); [e-mail];
[e-mail]; [e-mail]; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration 


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
<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] <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
<https://www1.ietf.org/mailman/listinfo/dhcwg>  

--



Paul Duffy 

Cisco Systems, Inc. 

[e-mail]