Re: midcom mib notes

Hi Wes,

Thanks for the detailed comments. Below are my comments on some of your
responses.

regards,
suresh

--- Wes Hardaker <[email protected]> wrote:
> 
> [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).
> 
[suresh] I agree. I doubt, if this was the intent of the requirements doc.

RFC 3411 does support bulk data request via the GetBulkRequest-PDU operation.
Even if the midcom module supported this, the midcom clients may not support
receiving large fragments. So, if atomicity continues to be a requirement, we
cant win this even with GetBulkrequest operation in SNMP. 

> 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.
> 
[suresh] I disagree. The requirement is per-session authorization. There are
many protocols that determine authorization soon afetr the authenticaion is
complete. The authors are merely stating the requirement.

> 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?
> 
[suresh] Rules may be impacted asynchronously by the actions taken by the
midcom module - such as end-to-end sesion or a BIND being deleted. When that
happens, Midcom clients are notified asynchronously. The failed rules are kept
a bit longer so the midcom client can review the rules after the failure
notification.

> 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

[suresh] ah, it seems like you are asserting that two rules are considered to
be of the same priority, if and only if the two rules do not overlap. This was
not obvious. 

> 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

[suresh] right.

> 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).
> 
[suresh] I donot follow what you are saying here. If one asks the question:
"can there be firewall rules from midcom clients that can overlap with each
other?" I woudl say, yes. The overlap can be over the n-tuple (or) the
authorization (permit/deny) of the filer.

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

> 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.
>
[suresh] Agreed.
 
> 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?
> 
[suresh] I believe, so.

> 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).
> 
[suresh] I dont parse the last sentence. How does an SNMP manager use multiple
owner strings for creating separate sessions? 

> ** midcomSessionRuleNewIndex: why can't this be global instead of
> per-session?  Why is rule-creation done this way.  It would be much

[suresh] Basically, the midcom client must have an authorized midcom session in
order to execute midcom rules. Hence the requirement to allow a midcom client
to generate a rule only from the midcom session entry he/she is assigned.
 
> simile to just have a manager create rules in the ruleTable underneath
> its owner string with any unused session number it wants.  Rules are

[suresh] Well, the session entry must be real, valid and owned by the same SNMP
manager.

> 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".
> 
[suresh] Session entry, as it sends, represents a midcom client, as opposed to
merely the SNMP manager. Session entry also fulfills the midcom session
requirements (SE, ST). Lastly, I believe, the midcom client construct is
necessary during notifications.

> 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
> 
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom
> 


=====