Subject: [ipcdn] NCS Signaling MIB SC Objects

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Thu, 1 Apr 2004 11:35:45 -0800

Jean-Francois,

Please comment on the CL position regarding the deletion of the following service class objects from the NCS MIB as proposed by ETSI. The last notes I have indicate the CL DQoS team was investigating this issue as originally raised by tComlabs. Thanks.

>Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState objects from the current MIB definition until a workable form of its associated mechanisms is defined.
>The removal of these objects from the MIB does not mean that there is no more mechanism to establish a separate NCS Service Flow, because such a Service Flow can still be defined in the Cable Modem config file (with the use of a Service Class Name if desired). This works, because in this case the Service Flow is set up during the CM Registration process, without the need for DSA messaging. This is also probably the way it is currently done, since the use of the above MIB objects is not possible with an IPCablecom/PacketCable compliant CMTS.
>Leaving the MIB objects in place, while awaiting the definition of a workable mechanism is not an option either, because this new definition would most likely have different MIB requirements.
Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
[email-masked]

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 6 Apr 2004 16:12:24 -0600

Hi Wim,

We had some additional discussions internal between the PacketCable & DOCSIS guys, and we concur on our spec(s) interpretation (Greg on the DOCSIS side, Kevin and I on the PacketCable side). More importantly, the CMTS vendors seem to be in sync with our interpretation based on what we have seen in our labs ([CMTS vendors, feel free to speak up here]).

Here's what we can summarize:
1)  The PacketCable specs do not intend to imply (nor require) that DSx-REQs that lack a PacketCable Auth Block be authorized by the "PacketCable Authorization Module".  While we do define the behavior of the "PacketCable Authorization Module", we do not preclude CMTS to employ other modules to authorize DOCSIS-based DSx requests. Perhaps the text could be clarified in DQOS sec. 3.2.5 to add some informative text around that. However, our understanding is that vendors are clear on this already.  The PacketCable compliant CMTS will support at least two independent authorization modules: one for DSx-REQs that contain a PacketCable Auth Block as defined in DQOS I09, and one for those that do not. Again, if there is no packetcable TLV in the DSx req, why shouldn't this request be processed by a docsis authorization module? 

2)  The treatment of DSx-REQs that lack a PacketCable Auth Block is currently in the realm of vendor differentiation.  DOCSIS only requires that the CMTS authorize the request in some manner.  Whether that authorization defaults to "allow" for all requests, "deny" for all requests, or some rules in between is left to the CMTS vendor and its QoS policy configurations.

3)  This feature is defined so that the operator can configure high-priority signaling flows for the MTAs on their system.  In order to use this feature, they will need to take a number of steps, including configuration of the CMTS to allow (ie "pre-authorize") the creation of service flows based on the SCN in the MTA config file. And Greg, Kevin and I strongly agree that these mib objects are more suited in the MTA config file than in the CM one.

4)  Even if the operator misconfigures the CMTS (either by not defining the SCN, or by not "pre-authorizing" it), or the CMTS doesn't support this feature, the MTA will only attempt to create the signaling flow, and then upon failure,  default to sending all signaling traffic on the primary US/DS service flows.

Therefore, we maintain that these 3 mib objects are pertinent and should stay in the MTA mib.

Jean-François 

> -----Original Message-----
> From: Wim De Ketelaere [mailto:[email-masked]]
> Sent: Thursday, April 01, 2004 11:04 PM
> To: Jean-Francois Mule; 'Beacham Gordon-CGB005'; 'David De Reu'
> Cc: [email-masked]; Richard Woundy @ Comcast; Kevin Johns
> Subject: [ipcdn] RE: NCS Signaling MIB SC Objects
> 
> 
> Hi all,
> 
> 
> I do not discuss the usefullness of the objects,
> I just believe they don't work due to the way the spec is
> currently written for the CMTS.
> 
> 
> section 3.2.5 of DQOS-IO8 clearly specifies:
> 
> If the PacketCable Authorization Module receives a bandwidth
> reservation request (i.e. a DSA) without an authorization 
> block, the CMTS must reject the request.
Note the informative statement (lowercase) is on the PacketCable Auth Module. Note that a PacketCable CMTS is a DOCSIS compliant CMTS as well and when it sees a DSx request from the eCM embedded in the MTA that does not contain any packetcable tlvs, the CMTS has no way of saying: but hey, that's a PacketCable MTA request so one could argue that this requirement is really for those DSA requests that do contain some packetcable tlvs but the request is malformed or wrong.

> Unless the dQoS specification is changed so that a clear
> distinction is made between what is meant
> 
> for PacketCable authorization
> and what is not, 
> 
>  I still don't see how it can work.
I hope my earlier email and the explanations above have helped clarified this.

> It is clearly not the intention of the PacketCable
> specification that any DSA for a SCN will always succeed, 
That is a question of MSO policy authorization and is left for vendor differentiation. Some QoS policy configuration & information models are available in IETF but this is out of the scope of our QoS specs. 

> this would be 
> a very easy theft-of-service scenario,.....
An operator would have to allow this.

> The DSA for the SCN will be a valid DSA on the DOCSIS level,
> but if the CMTS has PacketCable enabled, it will not pass the 
> authorization module and be rejected for that reason, this 
 ^
 PacketCable authorization module
  and again, it does not even hit the PacketCable auth module but that it gets handled by the plain docsis auth module.

> is, unless we change something on the requirements for a CMTS. 
> 
> But I don't have an easy solution for that, just stating that
> any SCN can be allowed without authorization opens up a 
> security hole,...
Operator decision.

> Just stating that it is valid on the DOCSIS level and is
> therefor okay is, I believe, a too easy answer, this would 
> make any PacketCable compliant CMTS, non-DOCSIS compliant. A 
> PacketCable CMTS MUST reject a DSA without the authorization 
> block present !
We disagree.

> If needed I can clarify my reasoning, in a conf call if this
> helps to solve the problem, this problem is already 
> on discussion for too long !
> 
> 
> Thanks,
>   Best regards,
>     Wim
> 
> 
> Wim De Ketelaere
> CTO
> tComLabs
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: 02 April 2004 02:22
> To: Beacham Gordon-CGB005; David De Reu; Wim De Ketelaere
> Cc: [email-masked]; Richard Woundy @ Comcast; Kevin Johns
> Subject: RE: NCS Signaling MIB SC Objects
> 
> 
> Okay, now it is my turn to be reminded to close on some
> issues, I see...
> ;) thx for the reminder.
> 
> We did discuss this question internally with the packetcable
> team. We believe that these 3 MIB objects still make sense 
> and that they must be kept in the NCS signaling MIB. I will 
> try to provide some justification below. I also cc: Kevin 
> Johns who is our PacketCable QoS lead so he can chime in on 
> the responses to this note, and may be Greg White can help too.
> 
> --- Context
> These 3 objects are typically used in the MTA config file to
> indicate specific service class name(s) corresponding to a 
> pre-provisioned set of QoS paramaters on the CMTS. If SET in 
> the MTA config file, the MTA can instruct the CM to generate 
> a SF with the specific service class name
> (SCN) so that the MTA NCS signaling packets can use the 
> special service flow rather than best effort. Unlike 
> PacketCable DQoS which defines AuthBlock and TLVs like gateid 
> for the MTA to use in the DSx msging, the SCN use is not 
> intended to use any of the packetcable gate related 
> parameters => no AuthBlock. DQoS DSx is used to create/modify 
> SF dynamically for the media streams: NCS starts as soon as 
> the MTA provisioning is complete, the MTA registers with the 
> CMS (RSIP, etc.) and a call can be initiated (NCS CRCX with 
> gate info in LCO,...) and QoS can be installed for that call. 
>  The pb is to guarantee some QoS for the NCS data and this is 
> what those objects are for. So these objects are valid to use 
> in a DOCSIS dialog initiated by the embedded CM of the MTA 
> with the CMTS. A DSx message with a classifier and SCN for 
> US|DS and no AuthBlock (hence no gateID) is a valid DOCSIS
> qos message. Upon activation, the SCN-based flow, NCS runs
> over qos SF. 
> 
> --- Response to questions from  both Gordon (4/1) and David
> (1/19) On Thrusday April 1st, Gordon wrote:
> > >Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS,
> > >pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState
> > objects from
> > >the current MIB definition until a workable form of its associated
> > >mechanisms is defined.
> I don't see what's wrong with the mechanism I described
> above. It seems a workable form to me & Kevin.
> 
> 
> Gordon wrote:
> > The removal of these objects from the
> > MIB does not mean that there is no more mechanism to
> > establish a separate NCS Service Flow,  because such a Service 
> > Flow can still be defined in the Cable Modem config file 
> > (with the use of a Service Class Name if desired). 
> This breaks the whole concept of decoupling the data
> provisioning from the voice provisioning. Why ask the data 
> provider to put special CM config for some voice NCS 
> signaling flows that the Telephony Service Provider might 
> use? Why not keep the trigger of a special flow for NCS in 
> the telephony prov, especially since this is an E-MTA with an 
> embedded CM => the MTA f() can very effectively pass the SCN 
> params onto the CM?
> 
> > This
> > works, because in this case the Service Flow is set up during
> > the CM Registration process, without the need for DSA 
> > messaging. 
> An E-MTA has an embedded cable modem and it is valid for an
> E-MTA to initiate plain docsis DSx messaging (in addition to 
> the DQoS flavored ones).
> 
> > This is also probably the way it is currently
> > done,
> See above.
> 
> > since the use of the above MIB objects is not possible
> > with an IPCablecom/PacketCable compliant CMTS. 
> Disagree. See context above: a compliant
> ipcablecom/packetcable CMTS is
> also a compliant DOCSIS CMTS.
> 
> > Leaving the
> > MIB objects in place, while awaiting the definition of a 
> > workable mechanism is not an option either, because this new 
> > definition would most likely have different MIB requirements.
> This works today, and is used.
> 
> 
> On January 19, 2004, David de Reu wrote:
> > (1) pktcSigServiceClassName(US|DS|Mask) objects
> > 
> >    There is still a problem with the
> > pktcSigServiceClassName(US|DS|Mask)
> >    objects (and indirectly with the related 
> pktcSigNcsServiceFlowState
> >    object). Although the MIBs currently reflect the PacketCable PROV
> >    spec text, the proposed system for setting up a signaling service
> >    flow will *NOT* work with a PacketCable/IPCablecom
> compliant CMTS.
> How so? This is incorrect.
> Note that Service Class Names are also used in the so called 
> "PacketCable Multimedia" QoS (a policy server using COPS can invoke a 
> SCN which will trigger the CMTS to initiate DSx with a CM).
> 
> >    This is because the CMTS must reject all DSx messaging
> initiated by
> >    the CM if there is no valid authorization block.
> This assumption is not valid. If no Authblock, treat the DSx like a 
> plain docsis msg (and if there's a correct classifier and a valid 
> pre-provisioned SCN that can be matched on the CMTS, proceed with SF).
> 
> > There is no such
> >    block in this case (there even is no gate on the CMTS). Note that
> Yes no authblock but there's a SCN which matches some pre-provisioned 
> QoS data on the CMTS.
> 
> >    this does not mean that PacketCable takes a step backward
> > compared to
> >    (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that 
> > a CM is not
> >    allowed to initiate DSx messaging, since it is not allowed 
> > to expose
> >    an interface to the outside world to do this. 
> I'm not sure I follow this point.
> 
> > For an
> > embedded MTA in
> >    PacketCable, this interface is present and the DSx 
> > messaging *can* be
> >    initiated by the CM, but the CMTS will accept it only if the
> >    appropriate authorization can take place (using the authorization
> >    block).
> Nope, that is true for an E-MTA initiated DSx message
> compliant to DQoS
> only. I'm told this assertion is not true for a CM initiated DSx msg.
> 
> >    Operationally, the practical solution is quite simple.
> You can add
> >    the necessary MIB objects in the CM config file (specifying the
> If this is for the NCS flow, why not the MTA config file -- again keep 
> the telephony related config param in the MTA portion of the prov.
> 
> >    service flow parameters directly, or alternatively using
> a Service
> >    Class Name (SCN)).
> Well, this is exactly what we are doing here and it just happens to be 
> in the SIG MIB so that the MTA which is the entity generating the NCS 
> traffic knows what SCN <-> SF to use to pass on the data to the eCM.
> 
> > In that case, the CM will set up the
> > service flow
> >    during its registration, without the need for DSx messaging.
> > 
> >    Solution: It is of course not up to the SIG MIB to provide
> > a solution
> >    to this problem. 
> Why not if it is for the NCS signaling?
> 
> > However, if the
> > pktcSigServiceClassName(US|DS|Mask)
> >    objects *are* included in the MIB, then you have a set of 
> > objects of
> >    which you know on forehand that they are useless. 
> We obviously do not agree and this has been in our specs for
> many years
> now.
> 
> > So the question
> >    seems to me: do we want to include these objects in the
> > MIB? We could
> >    also leave them out now, and wait for a correctly functioning
> >    mechanism to be defined in the PacketCable/IPCablecom specs.
> >    Alternatively, if the objects remain in the MIB, then we 
> > have to ask
> >    ourselves what will be required from an MTA: we will 
> > require that the
> >    MTA does the DSA nevertheless, knowing that it will not succeed
> >    anyway?
> 
> 
> I hope I've helped clarified this.
> Jean-François
> 
> 
> 
>

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 7 Apr 2004 13:59:45 -0600

Hi Thomas,

We can address the security concern in the security consideration question (and beef up the text there). As far as the spec interpretation, we could add some text in the description clause to mention that, if these objects are set, the E-MTA eCM will issue a valid DSx msg to be processed by the DOCSIS Authorization Module.

Any other vendors supporting/rejecting these objects?
Jean-François 

> From: Thomas Anders [mailto:[email-masked]] 
> Sent: Wednesday, April 07, 2004 7:17 AM
> To: [email-masked]
> Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects
> 
> 
> Hi all,
> 
> since part of this discussion is related to MSOs, we'd like 
> to speak up.
> 
> Wim>   It is clearly not the intention of the PacketCable
> Wim>   specification that any DSA for a SCN will always succeed,
> JFM>
> JFM> That is a question of MSO policy authorization and is left for 
> JFM> vendor
> differentiation.
> [...]
> Wim>   this would be a very easy theft-of-service scenario
> JFM>
> JFM> An operator would have to allow this.
> [...]
> Wim>   just stating that any SCN can be allowed without authorization
> Wim>   opens up a security hole
> JFM>
> JFM> Operator decision.
> 
> We as an MSO clearly see more (security) problems than 
> benefits with this approach. We can hardly imagine "vendor 
> differentiation" offering any acceptable solution here. Even 
> worse, much like Wim, we don't think it fits with the current specs.
> 
> 
> Best regards,
> Thomas
> 
> -- 
> Thomas Anders (thomas.anders at blue-cable.de)
> Bosch Breitbandnetze GmbH, Berlin, Germany
> 
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 7 Apr 2004 18:18:56 -0400

Speaking as another MSO (and not wearing my co-chair hat)...

I am not personally fond of a "CMTS approving any SCN without
authorization"; that sounds like a great way to enable theft of service. :^(
But I don't think that is what CableLabs is advocating.

One case that seems to make sense is if the service flow is pre-authorized
in the CM configuration file (e.g. Provisioned but not Admitted/Active).
This might be used on an MTA that is initially disabled for telephone
service, to conserve on reserved bandwidth on DOCSIS. When the MTA is
enabled much later for telephony service (via SNMP Sets), the eCM would send
a DSC for the existing provisioned service flow. (Note that the language
that folks point to in the DQOS spec refers to rejecting both DSAs and DSCs
without authorization blocks.)

Another case that might potentially make sense is if the CMTS enforced that
all upstream traffic for a specific SCN be directed only towards the CMS. In
other words, if a CM sends a DSA for the NCS signaling SCN, then for the
resulting service flow, the CMTS would drop all upstream traffic not
directed to the CMS. I'm not sure I'm a big fan of this approach, but I
could see how other operators might use it.

I think in all cases, it should be much more clearly specified in the DQOS
specs that the CMTSs have to implement configuration parameters in order to
permit/deny these types of DSAs/DSCs. In other words, it should be an
operator decision to enable DSAs and DSCs without a PacketCable
authorization block -- not a vendor implementation decision.

-- Rich

-----Original Message-----
From: Thomas Anders [mailto:[email-masked]]
Sent: Wednesday, April 07, 2004 9:17 AM
To: [email-masked]
Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects

Hi all,

since part of this discussion is related to MSOs, we'd like to speak up.

JFM> That is a question of MSO policy authorization and is left for vendor 

We as an MSO clearly see more (security) problems than benefits with this
approach. We can hardly imagine "vendor differentiation" offering any
acceptable solution here. Even worse, much like Wim, we don't think it
fits with the current specs.

Best regards,
Thomas

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 7 Apr 2004 17:43:29 -0700

Hi Thomas,

> approach. 
Could you be more specific on particular (security) concerns you see as the potential problems for SC Objects usage and implementation ?

Thanks,

Eugene Nechamkin

Broadcom Corp,
ph: (604) 233-8500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Thomas Anders
Sent: Wednesday, April 07, 2004 6:17 AM
To: [email-masked]
Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects

Hi all,

Best regards,
Thomas