Subject: [midcom] (no subject)

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 9 Jan 2003 08:03:26 -0500

I'd like to correct what I believe was a false impression left before
Christmas, regarding the requirements for access control for MIDCOM objects.
IMHO the critical issue is NOT mutual exclusion.  After all, the worst that
can happen is that one Agent deletes a policy rule for which another agent
is trying to extend the lifetime.  This is just as much of a mess if it
happens sequentially as it would be if it happens simultaneously in some
fashion, and points up a (non-MIDCOM) requirement for behind-the-scenes
coordination between Agents.

The critical requirement instead is that once a policy rule has been
created, the only part that the Agent can change is the requested lifetime.
Assuming the Agent has the authority, it can read a policy rule and it can
delete it, but it cannot change its component parts.

Turning from access to another topic, the part that will need careful
handling is the reserved address sub-object.  Depending on the function of
the Middlebox, this contains zero, one, or two addresses.  This sub-object
can either be created in advance through a reserve operation, or created
simultaneously with the rest of the policy rule.  When the policy rule is
instantiated, the reserved address sub-object becomes bound to it.  The
question is what key to use for the reserved address sub-object when it is
created in advance.  One possibility is to think of it as one component of a
policy rule whose other components have yet to be set.  Coming back to
access, I am wondering what restrictions we should impose so the reserved
address sub-object is not hijacked between the time of reservation and the
time of policy rule instantiation.

One final point, probably nothing to do with access: the obvious key for a
policy rule is the combination of the creating Agent's identity and the
Middlebox-generated policy rule identifier.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)
 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom