Re: midcom mib notes

Wes,

Many thanks for all these comments!

I am sorry that they did not make it into the version that
was just posted.  We will certainly cover all of them in the
next version.

Please see detailed replies inline.

--On 09.07.2004 22:38 Uhr -0700 Wes Hardaker wrote:

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

Below you will find just replies to the other comments.
I will address the two ** comments in a separate message.

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

Sounds good.  We will make it a discussion issue for the next version.

> 4.2.2 P. #3: "SNMP agent repeats" -> "snmp manager repeats".

Will be fixed,

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

I share your observation.  Do you think we should mention it?

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

Fixed in current version.

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

You are addressing a notification as response on the session termination
request.  You are right, instead of sending a notification carrying
midcomSessionRowStatus, we can also use a get request to this object.

We did not choose this way, because we considered it more effort on the
manager side.  Since the agent may terminate a session by sending the
midcomSessionTermination at any time, the agent needs to have a listener
for this event anyway.  With the mechanism suggested by the draft,
the agent just needs to write to midcomSessionRowStatus and does not
have issues another get request, because it will receive the notification
and the listener will terminate the session.

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

When retrieving the status of a single policy rule, you might want to
get a snapshot of a consistent single entry of the rule table.

I fully agree with you that it is not required to receive a consistent
snapshot of the entire rule table.

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

I am not sure about this.
Definitely, the current phrasing is a true statement.

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

Right.  We will remove USM from this paragraph.

> 4.3, 3rd P: USM -> VACM

Yep.  Will be fixed.

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

Yes.  This phrasing is much better.

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

The midcomRuleTable does not have a RowStatus objects in its entries.
Therefore setting the lifetime to 0 is the only way of requesting a
row to be removed from the table.

The midcomRuleStorageTime is an optional feature that keeps
a terminated policy in the table for a specified time.  Implementations
that do not support it can have midcomRuleStorageTime read-only with a
constant value of 0.

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

No.  We can have overlapping rules.  Since we only have 'allow' actions
and no 'deny' actions, overlapping firewalls rules do not conflict.

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

The only future extension that we are thinking about is supporting
attack/intrusion detection systems by supporting 'deny' actions
that overrule all 'allow' actions'.  Martin an I already
implemented it for the SIMCO protocol (draft-stiemerling-midcom-simco-06).
This feature needs exactly one additional (higher) priority level.

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

OK.

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

We will add a note on that.

> 6.4 step 2: modcomSessionTable -> midcomSessionTable

Thanks for this catch.

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

Yes.  But there is also another reason:  There may be more than one
manager taking care of a single policy rule.  The notification is sent
to all managers that have an entry in the session table and that have
access to the affected policy rule.  These notifications ensure that
all managers of a policy rule are informed about state changes as
requested by the MIDCOM requirements (RFC 3304).  For uniformly treating
all these managers, we chose so send the notification to all of them
including the manager that requested the state change.

> 6.4 step 6: read all -> reads all

Will be fixed.

> 6.6 step 6: ditto.

Yes.  Also in 6.5 step 4.

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

I'd like to check this against the MIDCOM requirements.
Let's discuss in San Diego.

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

I do not see your point here.  The following sentence explicitly
lists the affected tables.

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

OK,  let's try to clean up the VACM configuration discussion in the entire
document.

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

I will have a look at 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."

Fine.

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

Can you make a suggestion for fixing this?

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


> --
> Wes Hardaker
> Sparta
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom