[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [midcom] 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:taylor@nortelnetworks.com]
> Sent: Wednesday, December 10, 2003 11:27 PM
> To: Harrington, David
> Cc: Juergen Quittek; mibs@ops.ietf.org; midcom@ietf.org
> 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:taylor@nortelnetworks.com]
> >>Sent: Wednesday, December 10, 2003 1:13 PM
> >>To: Juergen Quittek
> >>Cc: mibs@ops.ietf.org; midcom@ietf.org
> >>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
> >>midcom@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/midcom
> >>
> >
> >
>
>