[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

570.0. "MCC and NS access" by JETSAM::WOODCOCK () Wed Dec 19 1990 14:21

Hi,

We did a little testing in the DEC: namespace last week to determine
the actual "minimum" required access needed to directories and objects
and how that impacts the NS operational concerns. In being able to see
the interaction of your code up front thru a debugger with DNS, I have
a couple of suggestions which *may* be feasible in reducing access 
requirements. The present situation is that MCC will have a difficult
time getting access approved with ANY established NS with any kind of
security guidelines on an INDIVIDUALIZED basis. By this I mean individuals
may find it tough to be granted access for registration purposes. 
Registration would have to be done as a centralized management function. 
Having more flexibility in your registration code may allow for an ease of 
deployment (and sales).

DEC: of course has the same synonym and backtranslation directoies which
MCC puts in place. The only difference is that the node objects are placed
under specific site code directories instead of DNA_NODE. I won't get into
MCC specific root directories. The following is a list of the basic access
requirements on directories and objects for nodes:

.DNA_NODESYNONYM    (R,W,D,T)
.DNA_BACKTRANSLATION.%X49.%X<hex area>   (R,W,D,T)
.<site>             (R,W,D,T)
.<site>.<node>      (R,W,D,T,C)    {Control not mentioned in DOCS}

With these requirements the MCC user has full privs to work with (or
destroy by accident or otherwise) all the mechanisms used by Phase V for
basic communication. This is viewed as a serious security problem and 
therefore registration must be done thru a controlled and centralized body
in an established NS.

By changing your approach of registration you could have the potential of
reducing some of this access.

In registering a node the first function MCC attempts is a CREATE function
because it is assumed that the object does NOT exist. Because of this it
checks for the heavy duty access required and failed if not given. This
seemed to be the general approach for any of the updating needed.

If you were to change your philosophy and take the extra step of assuming
the object and appropriate links are ALREADY there you will find you need
less access. You simply would need read access to verify the node, its
synonym and backtranslation links, are correct. If they are correct then
you could add the MCC specific attributes onto the node object. You would
need write and most likely delete access on the node object for future 
changes (but only the object, not the directories and links). Avoid
delete and control access wherever possible.

While this may be still viewed as a security problem, it will bring you
*MUCH* closer for individuals to gain access within established NSs. If
DNS engineering ever administers access onto specific attributes in the 
future, the problem would then be a non-issue completely with MCC only
given access to MCC attributes on the objects themselves.

If the node or any of the links are incorrect or non-existent, THAT is 
the time to check for full access on all the other required points and
procede much in the fashion you do now.

Also, with node auto-registration in the future the objects may be there
first more often than not. And if new AMs require new attributes, registration
thru an individualized basis may be more appropriate for some companies.

I put this in as a QAR suggestion and also a note because my forte' isn't
DNS and others may be able to add or delete content to its validity and
feasibility.

cheers,
brad...

T.R	Title	User	Date	Lines
570.1	line speed in DNS	JETSAM::WOODCOCK	`Mon Jan 07 1991 13:52`	38
	Hi there, In the base note I made the statement: >>> Registration would have to be done as a centralized management function. Since then I've thought about using MCC a little more in that capacity and came up with a problem attribute [only one so far :-) ]. "LINE SPEED" As a centralized function the MCC users would only be given READ access to everything in the NS. The function would provide all registration/modification services. All the network managers in the corporation would have to inform the registration processors about the various LINE SPEEDS of circuits. This will probably mean beaurocratic pieces of paper work to be submitted on two routers each time there is a line speed change (BAD NEWS) or if a circuit is even moved!! This makes network metrics dependent on a registration process (even worse) and not the control of the circuit owners themselves. Contrary to popular belief line speeds are not all that constant. This will become more and more the case as time goes on. Networks are not only seeing a push for integrated management but also for integrated transmission facilities. IDN, SDN, DLN!! Even vendors are making it easier to change the data rates. When we look to upgrade the Backbone this could mean dozens of circuits. It might last a year. And this goes on thru many other groups also. Line speed is probably labelled as an "orphan attribute" from MCCs viewpoint and other than net configs changing all the time it would seem to make sense to put it in DNS because everyone can use it. But because it does have the potential of change so often (even without notice) it shouldn't be stored there (or any other changing attribute). There is a fine line as to whether DNS is being used as a database in these cases and these attributes would be better off outside of DNS. regards, brad...
570.2	Why won't Line Speed work?	TOOK::CAREY	`Tue Jan 08 1991 14:58`	64
	Brad, You're exactly right that Line Speed is an "orphaned attribute" for DNA4. For Ethernet (CMSA/CD) lines we default it to 10 Mbits/second, but otherwise it is a value supplied by the manager, and maintained in the namespace. I am not entirely clear on the problem here, so I may ask some stupid questions. However, here they come.... 1) I thought that the major problem here was registering the global entities. What would be the problem setting up the name space so that manager's had access to registered objects in the directories they manage? 2) I know we're talking about security here, so there will always be a wide variety of opinions. However, where does it make sense to start seeing security decisions impact available features? What I would like to see: A solution that allows us to keep "Line Speed" globally available for a node4, but doesn't require moving all of these pieces of paper to keep them centrally controlled. Our only other option appears to be keeping this information in a decentralized MIR, which reduces the value of the attribute a lot. So, I think I understand why protecting the Root directory from marauding bands of renegade network managers is a good thing, but I'm not clear on why "Line Speed" gets trapped by this protection. I expected that the procedure would be something like this: o Central Registry Registers node4 in a sub-directory (perhaps by area, for example, such as .AREA4.NODE). This central registry has to have access to the Root for modifying the backtranslation and synonym stuff, but once it is in, it is in. o Network managers have access to their own area directories with the right to modify objects. That means they can SET NODE4 .AREA4.NODE LINE DMR-0 LINE SPEED 71 or whatever they want. I'm not quite sure why that won't work right now, even though it may be that our Registration is a bit overzealous. Do you feel that subdirectories should also be protected against modification by network managers? It may be reasonable, right now I'm thinking, "what does he manage if you won't let him DO anything?" Again, I'm looking for your perspective on this, and for a better understanding for myself to bring home. I've been trying hard to treat the NameSpace as somebody else's problem, so don't be feel free to educate me on what's going on here and how you see it all fitting together from your management perspective. Thanks, -Jim Carey
570.3	sharing	SMAUG::SMARTIN	`Tue Jan 08 1991 18:56`	22
	With the some effort in the access control area, specific mcc managers could have access to individual DNS objects, and could then change the line speed, without being able to modify other objects in the same directory. It is also possible to set up a directory such that several managers can create things, but neither is capable of modifying or deleting the others objects. If the access control needs to be more complex, or contains access control groups, then sharing DNS directories becomes difficult. The similarities between sharing a file directory on VMS and sharing a DNS directory amongst several users is quite high. - the creator of the dns object has full access to the object from the node & username it was created - default access control entries get copied from the parent directory to the new object Hope this helps... Sally
570.4	future considerations	JETSAM::WOODCOCK	`Tue Jan 08 1991 20:30`	81
	Hi Jim, I've tried to avoid DNS myself but it didn't seem to be working. So I'm trying to be a little proactive now so I can avoid some "enthusiastic" meetings later :-). We are already eye to eye on this but I just what to make sure the future is safe. > 1) I thought that the major problem here was registering the global > entities. What would be the problem setting up the name space so > that manager's had access to registered objects in the directories > they manage? Registration is the major problem. Giving access to a limited set of network managers would "probably" also be ok (I can't oficially speak for DNS). > 2) I know we're talking about security here, so there will always be a > wide variety of opinions. However, where does it make sense to > start seeing security decisions impact available features? When we jeopardize any nodes ability to comminicate on the net. > What I would like to see: > A solution that allows us to keep "Line Speed" globally available for a > node4, but doesn't require moving all of these pieces of paper to keep > them centrally controlled. > Our only other option appears to be keeping this information in a > decentralized MIR, which reduces the value of the attribute a lot. Mutual agreement. > So, I think I understand why protecting the Root directory from > marauding bands of renegade network managers is a good thing, but I'm > not clear on why "Line Speed" gets trapped by this protection. I > expected that the procedure would be something like this: > o Central Registry Registers node4 in a sub-directory (perhaps by > area, for example, such as .AREA4.NODE). This central registry has > to have access to the Root for modifying the backtranslation and > synonym stuff, but once it is in, it is in. > o Network managers have access to their own area directories with > the right to modify objects. That means they can > SET NODE4 .AREA4.NODE LINE DMR-0 LINE SPEED 71 > or whatever they want. If access is limited to certain network managers, say, Area Managers this will most likely fly with DNS admin. The key here is to maintain a LIMITED number of folks to the access on the objects only. So long as this group is limited and manageable they may not have objections. But they would just assume NOBODY gets access as the preferred option (other than R of course). > Do you feel that subdirectories should also be protected against > modification by network managers? It may be reasonable, right now I'm > thinking, "what does he manage if you won't let him DO anything?" > Again, I'm looking for your perspective on this, and for a better > understanding for myself to bring home. Network managers shouldn't need access to directories if the entities are already registered. Also, network managers manage the entities not DNS. There are different folks handling DNS admin now. I'm not sure if it makes sense to keep it this way in the future. Everything you stated would seem to work fine given the graces of DNS admin gods to allow area managers access to the objects only. But I still have concerns for the future. Right now we are only talking about NETWORK managers. What happens when a system management module is developed (not very far off I'm sure) and this module requires a settable attribute which changes. Do we then allow access to SYSTEM managers to the node objects? This same principle may apply to other modules also. What then? Should we be setting a precedence for the future like this? This is why only needing Read access into the NS is preferrable... regards, brad