RE: RE: NCS Signaling MIB SC Objects

Thomas wrote:
> 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.
Thank you for your comment. I'm trying to understand your concern in more details. Could you help us and elaborate on what "security problems" you are seeing with this approach?

Here's my brief analysis:
 - a CMTS is pre-provisioned by the MSO operator with a specific SCN. Securing this CMTS provisioning interface is out of scope of this E-MTA mib discussion. One should assume that MSOs use secure means to provision key parameters on their CMTSes. Note that this SCN is associated with particular traffic qos profiles for NCS signaling (such parameters could be even restricted to the specific NCS UDP port, etc.).
 - the specific SCN is passed to the E-MTA in the configuration file during provisioning (using Secure software download).
 - Access to this MIB object is manageable via std SNMPv3 USM/VACM/etc. mechanisms.

IF the management operations that are in full control of the MSO operators are done in a secure manner (authentication of mgmt operations, privacy on CMTS write/MTA read operations of SCN, restriction of traffic profiles to specific MTA IP adds && NCS protocol UDP ports), the security threats seem quite minimal and can be mitigated by setting strict profile parameters:
  - theft of bandwidth: in an attacker does obtain a valid SCN, if the traffic profile is restricted to the NCS UDP port (udp 2327/2727), the attacker may gain access to a special SF as long as its applications use NCS ports (and use that with the NCS sendto ports). I fail to see what real theft this may entail.
  - denial of service: I do not see any. Worst case, if the NCS SF is not usable, you have best effort.
  - other threats?

> Even 
> worse, much like Wim, we don't think it fits with the current specs.
I went over the informative must statement Wim indicated and explained that it pertains to the "PacketCable Authorization Module". It is our understanding that these DSx msg would appear like traditional DOCSIS DSx coming from the CM and therefore, they are not expected to hit the packetcable auth module and are not subject to this requirement.

Jean-François