Re: RE: NCS Signaling MIB SC Objects
Thomas Anders <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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)