Sig MIB, NCS SF Objects -2: SCN provisioning on CMTS

"Jean-Francois Mule" <[email protected]>
Newsgroups gmane.ietf.ipcdn
Message-ID <[email protected]>
> 2/ Are the DOCSIS Service Class Name provisioning on the CMTS 
> (and all the associated policies to authorize flows based on 
> SCN and other rules) too open to vendor differentiation, 
> hence opening up security risks?

Wg consensus seems to be that yes, this is way too open and more spec langage is required to mandate some sort of rule-based authorization on the CMTS.

An Engineering Change has been submitted by Dave Flanagan of Motorola and will be discussed in the PacketCable QoS team tomorrow. To provide total transparency to the IETF ipcdn participants, here's the proposed change:

--- Affected spec: 
    PKT-SP-DQOS-I09-040402
    http://www.packetcable.com/specifications/specifications10.html

--- Old text: 
    section 3.2.5, titled "CMTS Authorization and Behavior"
    paragraph 5
If the PacketCable authorization module receives a bandwidth reservation request without an authorization block, the CMTS MUST reject the request with confirmation code "24: authorization failure". 

--- New proposed text:
If the PacketCable authorization module receives a bandwidth reservation request without an authorization block, the CMTS MUST reject the request with confirmation code "24: authorization failure". 
Note that the above requirement applies to bandwidth requests processed by the PacketCable authorization module. It does not preclude the use of the DOCSIS authorization module to process other requests without an authorization block. The PacketCable authorization module and DOCSIS authorization module are logical functions of the CMTS that approve or deny QoS parameters and classifiers. Conceptually, when a QoS request arrives at the CMTS, the DOCSIS authorization module determines if the request is to be processed within the DOCSIS authorization module itself or hand it off to the PacketCable authorization module.


The one comment I would make would be to add a normative MUST statement on the CMTS to provide some kind of configuration settings for authorizing DSx requests based on SCN (the idea expressed on the list was that we don't care what specific mechanism is in place to allow/allow-some/deny-all as long as there is such a mechanism).

Comments appreciated.
Jean-François
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.