Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 7 Apr 2004 15:09:07 -0600

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 

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

---

From: Thomas Anders <[email-masked]>
Date: Thu, 08 Apr 2004 12:23:30 +0200

Hi all,

Jean-Francois Mule wrote:
> 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?

It's left up to "vendor differentiation" to ensure that if an operator allows
DSx for NCS SCNs, the CMTS MUST NOT allow *any* DSx (w/o gate id) to succeed.
We'd weight the involved risks too high to rely on "vendor differentiation"
here. Rather, if we add SC objects to the SIG MIB, the corresponding DSx
authorization should be properly addressed by the specifications (enabling
proper certification testing) also.

We should either go the whole way or not go it at all.

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

If this is the original intention of the specs (which I still doubt), then it's
ambiguous at best.

Isn't it extremely non-obvious to pass a DSx-REQ for a PacketCable NCS flow to
be used by a PacketCable MTA as defined by a PacketCable MTA config file setting 
based on the PacketCable SIG MIB to the CMTS *DOCSIS* Auth Module instead of the
*PacketCable* Auth Module?

Best regards,
Thomas

-- 
Thomas Anders (thomas.anders at blue-cable.de)