RE: [dhcwg] DHCP Option for CableLabs Client Configuration

[Ralph Droms <[e-mail]>]

Patrick,

At 03:31 PM 8/2/2002 -0700, Cosmo, Patrick wrote:
>Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not 
>MTAs?

Good question; the text reads:

Network layer requirements for the CMTS exist beyond transparency to IP 
traffic. The CMTS
must also support:

· variable length subnet masks
· classless addressing
· IP multicast addressing and forwarding
· Internet Group Management Protocol (IGMP)
· proxy ARP
· filtering of DHCP downstream-bound broadcast packets to protect against 
BOOTP server spoofing

I would read the text to apply to all DHCP server spoofing.

- Ralph


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