Subject: RE: initial docsNmAccessTable contents

From: "Bob Himlin" <[email-masked]>
Date: Mon, 29 Mar 1999 09:25:07 -0800

We also implement default rows in the docsDevNmAccessTable.  Recently, we
had a request from an MSO that the modem delete all the default rows and
start over if an attempt was made to SET the docsDevNmAccessTable using the
configuration file.  I think this is reasonable behavior, as MSOs who are
building configuration files do not want to necessarily know the structure
of everyone's default NmAccessTable.

Bob Himlin
TurboNet Communications

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Raftus
Sent: Monday, March 29, 1999 4:36 AM
To: Michael W. Patrick; [email-masked]
Subject: Re: initial docsNmAccessTable contents

Here at Cadence we took the same approach as you - made 'private' and
'public' the initial two rows, which can be disabled through a config file
if desired.

At 05:59 AM 29/03/99 -0500, Michael W. Patrick wrote:
>Other CM vendors,
>
>How did you resolve the issue of providing by default read access for
>the "public" community and read/write access to "private"?
>
>We initially implemented an empty docsDevNmAccessTable, thinking that
>an operator HAD to provide initial rows in the config file with
>the "SNMP MIB Object" TLV in order to access the "public" or "private"
>community.  During the pretesting week before CW7,
>we found out that we failed some qualification scripts
>because the cablelabs scripts assumed both "private" and
>"public" were accessible, per longstanding SNMP tradition.
>(Jason, was that a misconception on our part?)
>
>We didn't think it made sense to provide access to "private" and
>"public" WITHOUT including these in docsDevNmAccessTable, so our
>solution was to make these the initial two rows in the table.
>That way, you get "public" and "private" by default, and you
>can disable them with SETs in the config file to set, say,
>docsDevNmInterfaces to zero.
>
>I don't think our approach is unreasonable, but I'm sure it differs
>with many (most?) of the rest of the vendors. What did you all do
>to support public/private?
>
>Shouldn't we have an ECN to an OSS spec to clarify default
>access to public/private? I think it should state either 1) that they are
the
>first two rows in docDevNmAccessTable by default, or else 2)
>that a config file must define rows for them in order to provide
>access.
>
>What I think we should NOT permit is "hard-coded" access to "public"
>and "private" that cannot be disabled. I think that at any time
>that "public" and/or "private" is recognized by the modem, those
>community names must appear in docsDevNmAccessTable.
>
>Regards,
>-mike
>
>

David Raftus
Senior Firmware Designer
Cadence Design Systems
1130 Morrison Drive, Suite 310
Ottawa, Ontario  K2H 9N6

email: [email-masked]
phone: 613-726-2767
fax:   613-828-2378

---

From: [email-masked] (Randall Atkinson)
Date: Mon, 29 Mar 1999 15:06:40 -0800

On Mar 29  9:25, Bob Himlin wrote:
% Recently, we had a request from an MSO that the modem delete all the
% default rows and start over if an attempt was made to SET the
% docsDevNmAccessTable using the configuration file.

	I believe this is what most vendors are already doing.  Any road,
we believe this is the correct behaviour.  Further, we would be unhappy
with any default configuration that permitted any read-write access on
the
CMCI (ethernet/USB) interface.

% as MSOs who are building configuration
% files do not want to necessarily know the structure of everyone's
default
% NmAccessTable.

	A good rationale.

>community names must appear in docsDevNmAccessTable.

	Fully agree.

Ran
[email-masked]

---

From: "Bob Himlin" <[email-masked]>
Date: Mon, 29 Mar 1999 15:29:20 -0800

I would like to get clarification on the read protect requirement of the
docsDevNmAccessTable.  The MIB-04 states the following:

docsDevNmAccessEntry OBJECT-TYPE
        SYNTAX      DocsDevNmAccessEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "Controls access to SNMP objects by a particular network
             management station. For each entry in this table, the
             contents are not readable unless the management station
             has read-write permission."
        INDEX { docsDevNmAccessIndex  }
        ::= {  docsDevNmAccessTable 1 }

What we are trying to pinpoint is the definition of "management station".
For instance, is a "management station" defined as an IP host, or an IP host
using a specific community string?  An example of two rows in this table
that might be used to accommodate a typical NMS, which uses community
strings "public" for GETs and GET-NEXTs and "private" for SETs is the
following:

docsDevNmAccessIndex.1 = 1
docsDevNmAccessIp.1 = 192.168.10.0
docsDevNmAccessIpMask.1 = 255.255.255.0
docsDevNmAccessCommunity.1 = public
docsDevNmAccessIpControl.1 = read(2)
docsDevNmAccessInterfaces.1 = DEFVAL
docsDevNmAccessStatus.1 = active(1)
docsDevNmAccessIndex.2 = 2
docsDevNmAccessIp.2 = 192.168.10.0
docsDevNmAccessIpMask.2 = 255.255.255.0
docsDevNmAccessCommunity.2 = private
docsDevNmAccessIpControl.2 = readWrite(3)
docsDevNmAccessInterfaces.2 = DEFVAL
docsDevNmAccessStatus.2 = active (1)

Assume an NMS is configured to use "public" for all its GET and GET-NEXT
PDUs, "private" for SETs.  If the read protection on docsDevNmAccessTable
implemented in the CM uses the community string of the GET or GET-NEXT PDUs
used to attempt to walk the table to qualify what a "management station" is,
then the docsDevNmAccesTable is not readable, even though the NMS has
read-write permission (i.e. it can write objects in the MIB).  Is this not a
realistic scenario to consider (an NMS using different strings for GET vs.
SET)?

Bob Himlin
TurboNet Communications

---

From: "Mike St. Johns" <[email-masked]>
Date: Mon, 29 Mar 1999 18:05:09 -0800

Bob - 

If you send a PDU with a community string of public and an IP address of 
192.168.10.5 it matches the first entry.  If you send a PDU with a community 
string of private and an IP address of 192.168.10.5 it matches the second 
entry.   An SNMP agent has no state with respect to its management agent (at 
least in V1).  The only thing it considers for its access decision is the 
current PDU - and for this table it considers both the community string entry 
and the IP address from the PDU.

This is clarified in the language in the -07 version of the MIB.  I'd 
recommend checking that version as you have questions as the existing objects 
(e.g. the ones that haven't been deprecated or deleted since -04) have mostly 
had additional or corrective descriptive text added.  The -07 version has just 
(as of about 2 hours ago) passed the MIB doctor with minor edits - I'll be 
doing the -08 mib tomorrow for publication and advancement to standard and 
that should be it.

With respect to your scenario - generally, no, this isn't a realistic 
scenario. A management station rarely uses different community strings based 
on the SNMP message type.  The granularity is generally between read-only 
managers and read-write managers.

Mike

---

From: [email-masked] (Randall Atkinson)
Date: Tue, 30 Mar 1999 08:47:40 -0800

It has ALWAYS been the case with SNMP that the
access controls are based on (Source IP Addr + Community
String contained in the SNMP PDU).

So using IP Address alone doesn't conform with SNMP RFCs
nor with the DOCSIS/MCNS/IPCDN MIBs.

Please consider that normal systems are multi-user, so even
if "Jane" knows the read-write string, "Joe" might only know
the "read-only" string.  Assuming that everyone is using
Windoz to manage their systems is invalid.

Ran

---

From: "Bob Himlin" <[email-masked]>
Date: Tue, 30 Mar 1999 10:49:22 -0800

I am aware of the access control model for generic SNMP.

The docsDevNmAccessTable is a special case, in that it is called out in the
MIB that even if a management station has read access (as judged by IP
address & community string), it cannot read this
particular table unless "it" also has write access.  It is this special
treatment of the docsDevNmAccessTable that prompted my request for
clarification.  The read access rules for docsDevNmAccessTable are different
than the read access rules for any other table.

There are two ways to implement the read protection of docsDevNmAccessTable
(as opposed to the read access decision on any other table).  One is to
simply use the IP address, community string, and interface information
contained in each arriving PDU and make the read-protect decision based on
the first docsDevNmAccessTable row that matches all of these items.  If you
implement it this way, and a GET PDU arrives from 192.168.10.5 directed at
the docsDevNmAccessTable containing community string "public" (referring
back to my example), the CM will not return the object.  Whereas a GET PDU
from 192.168.10.5 directed at the docsDevNmAccessTable containing the
"private" community string would return the object.  Same "management
station", different behavior depending on the community string used for
GETs.

The other way to implement the read protection for docsDevNmAccessTable is
to scan the entire table for any row that matches IP address & interface,
but not necessarily community string.  If there exists a row that allows
readWrite access to this "management station", using any community string,
AND the "management station" has at least read access as determined using
the community string in the GET PDU, the CM returns the object.  I thought
that this way of implementing the read protection would produce more
consistent results in the case where one "management station" uses different
community strings for GETs vs. SETs.

I am getting the sense, however, that the correct implementation is the
first way, for the reasons you state in your example.  "Jane" knows the
read-write string, "Joe" knows the read-only string, and it is impossible or
inconvenient to distinguish between "Jane" and "Joe" based on IP address.
That is the clarification I asked for.

Bob Himlin
TurboNet Communications

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Randall Atkinson
Sent: Tuesday, March 30, 1999 8:48 AM
To: [email-masked]; [email-masked]
Subject: Re: Read protection requirement of docsDevNmAccessTable

Ran

---

From: David Raftus <[email-masked]>
Date: Tue, 30 Mar 1999 14:16:24 -0500

Hi everyone,

At Cadence we have implemented a variation of Bob's first interpretation.
We do look for the first entry that matches all security parameters - IP
address, community string, interface, etc. However, if the ip address is
listed as 'any' (oxff.ff.ff.ff), and the access given is 'read', we
continue looking for a specific ip address that may have read-write access.
We do not reject the NMS until we have evaluated all possibilities.

>Windoz to manage their systems is invalid.

David Raftus
Lead Designer
Cadence Design Systems