midcom mib notes

[Note: the most major architectural comment is marked below as ** for
those that don't want to read the more minor ones]

I had a chance to skim through the current mibcom mib a week or two
ago.  I wrote down the following high-level comments about things:

4.2.1, last P: Using INFORMs would fix some of your notification
issues here.  Considering your architecture, I'd suggest making
INFORMs the default at least when sending notifications.

4.2.2 P. #3: "SNMP agent repeats" -> "snmp manager repeats".  Note
that the "specified period of time" and how many times to retry is
manager stack dependent, though most are configurable that I've ever
seen.

4.2.2, last P: "as is needed" -> "as it is needed"

4.2.4.2: why is this not done via a set then a get by the manager?
What does the notification buy you here?

4.2.4.3, 2nd P: actually it doesn't matter what the protocol is.
There isn't a protocol that can deal with changing data over time.
Data does change over time (period) and I don't think it's even wise
to try and protect against changing data (consider multi-process and
multi-threaded environments...  You'd never want to lock all the data
during a huge data-gathering process).

4.2.5, 1st P: authorization is per message in any decently designed protocol
(as it should be), not per session.  You have to authorize each
message being sent in a generic protocol.  I suggest you drop the
authorization word in the first sentence.

4.3, 2nd P: I don't think USM configuration is needed to do access
control policy stuff.  Just the VACM is likely ever needed.

4.3, 3rd P: USM -> VACM

4.3, 5th P: "can not be realized by" -> "may not be realizable using"

5.1.2, 3rd P: I'm not sure why you're not just deleting the row
instead of setting it 0 like you are.  Is it because you're trying to
leave the row actually around for monitoring purposes?

5.2.2, 1st P: If all rules are executed at the same priority this
means that you can never ever have two rules which overlap, right?  Is
this always going to be the case in the future?  Are you ever going to
open one rule that has slightly greater permissions than another more
specific one?  If so, the order of execution is critical there.  From
a IPSP data-model point of view (rfc3585), this would have to be
realized as a single rule at the configured priority but using a
compound set of ipheader filters (this addrs/ports or this addrs/ports
or ... -> bypass).

6: Thank you for doing this section.  There are far too many RFCs
without examples that really help the reader understand things better.

6.1, step 3: note that createAndWait is less popular than createAndGo
so you may want to switch to using that in your example.

6.3 step 1: note that an agent crash will prevent the notification
from ever being sent even when the agent's notion of the session
disappears.  Managers should be aware of this.

6.4 step 2: modcomSessionTable -> midcomSessionTable

6.4 step 5: is the purpose of this notification just because the agent
may take a while and the manager doesn't want to poll for the
value and thus can wait instead?

6.4 step 6: read all -> reads all

6.6 step 6: ditto.

section 8.1:  SHOULD support confidentiality.  I don't think you can
MUST for that.

8.1, 6th P: "the initial index" -> "the initial index of multiple
tables within the MIB"

8.3, 2nd P: I think you need to more clearly spell out when you expect
to explicitly put rules into the VACM and where and when you expect
this to happen.  It is alluded to in many places in the document, but
I think making it more explicitly clear would really help people doing
implementations.

MIB:

** midcomSessionIndexNext: Why is this needed?  It will be used
underneath the midcomSessionOwner object and the sessionID is then
local to the manager itself anyway.  A manager shouldn't need to read
this value as it should know about its existing sessions under its own
owner string.  Or you could just have an owner string without session
indexes at all, and have managers just use multiple owner strings for
creating separate sessions (possibly with a common prefix for access
control purposes).

** midcomSessionRuleNewIndex: why can't this be global instead of
per-session?  Why is rule-creation done this way.  It would be much
simile to just have a manager create rules in the ruleTable underneath
its owner string with any unused session number it wants.  Rules are
already not prioritized, so there shouldn't be conflicts.  I actually
think the entire notion of sessions is not needed at all and doesn't
provide any additional security that it seems the MIB sort of hints it
might be providing?  There is no security gain that I can see here for
this increase in complexity.  I think you could construct a solution
that doesn't require sessions at all that would significantly reduce
the complexity in the result without sacrificing anything other than
the net effect that "you have an explicit session".

midcomRuleTransportProtocol: I think an existing TC exists for
protocol numbers?  The "Protocol" TC is available in the
INTEGRATED-SERVICES-MIB (RFC2213).  You might consider reusing it.

midcomConfigFirewallTable:  more text to end the last sentence with:
configured...  "for devices that are capable of collecting like-rules
into named groups of rules."

midcomRscFirewallRuleId: doesn't match how rules are used within
IPSP.  Rules are referenced by name (and ordered by number within
groups).

-- 
Wes Hardaker
Sparta