RE: MIDCOM MIB design question

Hi David,

--On 11.12.2003 1:40 Uhr -0500 Harrington, David wrote:

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

I think the security community made experiences differing from yours.

Let's take your example and replace the thief by one of your kids.
You would give your kid AND your wife access to the coins you collect
somewhere in the kitchen for giving tips to delivery service or for
paying stamps and so on.  But you probably would only give your wife
access to your checking account and block access from your kids to the
account.

Coming back to the MIDCOM MIB problem.  On  one side, there is a set of
objects that concerns the entire protocol operations: statistics, the
list of entities that established policies using the MIDCOM protocol,
the number of failed attempts to establish a MIDCOM session, etc.
This should not be accessible to all potential entities that are allowed
to use the MIDCOM protocol.  On the other side, there is the set of
objects implementing the MIDCOM protocol. This set should be accessible
to a wider group of users.

Now, Tom said that this security issue could be handled more easily if
we would use separate modules. I do not see anything wrong with this.

Thanks,

    Juergen

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