RE: MIDCOM MIB design question

Hi Tom,

So I have a pile of money in my house. There are two people outside my
house - one is my wife, and the other a thief. For simplicity, I could
have two doors in my house; one I would lock to keep the thief out, and
the other I'd leave unlocked so my wife could get in. How secure is my
money?

dbh

> -----Original Message-----
> From: Tom Taylor [mailto:[email protected]] 
> Sent: Wednesday, December 10, 2003 11:27 PM
> To: Harrington, David
> Cc: Juergen Quittek; [email protected]; [email protected]
> Subject: Re: [midcom] MIDCOM MIB design question
> 
> 
> I know you can use views to separate out what one user sees 
> vs. another, 
> but I figured separation by module was cleaner.  Juergen is talking 
> about separating what the administrator is interested in from 
> what the 
> MIDCOM agent is interested in.  Agreed that they both address 
> the same 
> underlying data structures, but I would think security setup would be 
> simpler if you could specify access by module rather than 
> having to do 
> it object by object.
> 
> Harrington, David wrote:
> 
> > Hi Juergen,
> > 
> > SNMP is a protocol that manipulates sets of data on remote 
> devices. The
> > set of data is typically used by many users. You separate 
> mib data sets
> > by the functionality they contain, not by which "user" will use it. 
> > 
> > It would be really helpful if you were more explicit about the
> > requirements and the separate objects you think are needed 
> in each mib.
> > Objects that "serve management purposes" means nothing to 
> me. It depends
> > on the manager.
> > 
> > I might have one network manager or application whose job 
> is to monitor
> > performance, and he/it might use ifInOctets in its 
> calculations. I might
> > have a second application whose job is to isolate faulty 
> interfaces, and
> > it might use ifInOctets. I might have an intruder detection 
> system that
> > watches for anomalies and it might use ifInOctets. I 
> wouldn't want three
> > duplicate ifInOctet objects to rpvoide this information 
> just because I
> > happen to have three different managers/users looking at 
> the datum for
> > different purposes.
> > 
> > You did list three things as management:
> > 1)  the priority with which requested pinholes are configured in the
> > firewall,
> > 2) a table showing the mapping of MIDCOM pinholes to 
> firewall resources
> > or of MIDCOM NAT sessions/bindings to NAT resources,
> > 3) a protocol statistics table listing the set of active MIDCOM
> > sessions, protocol errors, etc.
> > 
> > I'm not quite sure what type of priority you are referring to in 1).
> > Priority relative to what? To other pinholes? To other 
> firewall rules?
> > To other MIDCOM rules within a group? To other MIDCOM groups? The
> > priority of the operator performing the opeation? The 
> priority of the
> > operation versus other tasks the device needs to perform? 
> > 
> > The MIDCOM MIB manipulates the mappings of MIDCOM pinholes 
> to resources,
> > so the map available to monitor this mapping belongs in the 
> same mib, in
> > my opinion. You don't need to duplicate the information 
> just so another
> > user can read it.
> > 
> > Statistics are about the MIDCOM sessions and whatnot being 
> configured in
> > this mib. You don't need to separate which mib this is in.
> > 
> > It is generally better to keep the status related to a 
> functionality in
> > the same mib as the configuration of the functionality. 
> Statistics are
> > part of status, and so are the configuration settings.
> > 
> > dbh
> > 
> > 
> >>-----Original Message-----
> >>From: Tom Taylor [mailto:[email protected]] 
> >>Sent: Wednesday, December 10, 2003 1:13 PM
> >>To: Juergen Quittek
> >>Cc: [email protected]; [email protected]
> >>Subject: Re: [midcom] MIDCOM MIB design question
> >>
> >>
> >>I'd say they should be in separate modules because they are 
> >>likely to be 
> >>implemented on separate boxes on the SNMP client side.
> >>
> >>Juergen Quittek wrote:
> >>
> >>
> >>>Dear all,
> >>>
> >>>In the MIDCOM working group we are developing a protocol 
> >>
> >>for dynamically
> >>
> >>>requesting pinholes in firewalls and bindings/sessions on NATs.
> >>>
> >>>The working group decided to use SNMP as basic protocol and 
> >>
> >>now we are
> >>
> >>>defining a MIDCOM MIB module.  While doing this, we found 
> >>
> >>that we are
> >>
> >>>defining two separate groups of objects:  Objects 
> >>
> >>implementing the MIDCOM
> >>
> >>>protocol (for which we already have a protocol semantics 
> >>
> >>document, see
> >>
> >>>draft-ietf-midcom-semantics-06.txt) and objects serving management 
> >>>purposes.
> >>>Management purposes include for example configurations, such as
> >>> - the priority with which requested pinholes are 
> configured in the 
> >>>firewall,
> >>> - a table showing the mapping of MIDCOM pinholes to 
> >>
> >>firewall resources
> >>
> >>>   or of MIDCOM NAT sessions/bindings to NAT resources
> >>> - a protocol statistics table listing the set of active 
> >>
> >>MIDCOM sessions,
> >>
> >>>   protocol errors, etc.
> >>>
> >>>For these two groups of objects there are also two separate 
> >>
> >>groups of 
> >>
> >>>users:
> >>> - middlebox controllers sending requests for dynamic 
> >>
> >>pinholes and NAT
> >>
> >>>   sessions/bindings
> >>> - network managers configuring the middlebox (firewall or NAT) and
> >>>   monitoring its operation
> >>>
> >>>The middlebox controllers only need access to the objects 
> >>
> >>implementing
> >>
> >>>the MIDCOM protocol.
> >>>
> >>>The network managers would rather use the objects serving 
> >>
> >>management 
> >>
> >>>purposes
> >>>although in some cases they might need to access the other 
> >>
> >>group also.
> >>
> >>>Now, we have a draft defining these objects and the 
> >>
> >>following question:
> >>
> >>>Does someone have an opinion about whether these two groups 
> >>
> >>of objects
> >>
> >>>should be contained in a single MIB module or in two separate ones?
> >>>
> >>>Usually, this problem does not occur, because most control 
> protocol,
> >>>say GSMP are not defined on top of SNMP.  Therefore in 
> GSMP there is
> >>>a clear separation between the protocol and the MIB with 
> >>
> >>objects serving
> >>
> >>>network management purposes.  But in our case, SNMP is 
> used for both
> >>>purposes.
> >>>
> >>>Thanks,
> >>>
> >>>  Juergen
> >>
> >>
> >>_______________________________________________
> >>midcom mailing list
> >>[email protected]
> >>https://www1.ietf.org/mailman/listinfo/midcom
> >>
> > 
> > 
> 
>