Subject: ARC comments

From: Randy Presuhn <[email-masked]>
Date: Sun, 14 Jul 2002 18:15:23 -0700 (PDT)

Hi -

Here are a few comments on
draft-ietf-disman-conditionmib-02.txt Most are "mehanical",
but 4, 6, 7, and 8 are technical.

1) please add all the boilerplate required by section 10 of
   RFC 2026, including the full copyright notice (mentioned
   in the table of contents, but absent from the document)

2) Section 9: please change "Author's Address" to "Authors'
   Addresses", An-ni Huynh's address is incomplete.  remove
   "Name:" etc from Dave Perkins' entry.  add "USA" and a
   phone number

3) Section 8: please split into Normative References and
   Informative References.  Strawman: all are normative EXCEPT:
   RFC2571, 1155, 1212, 1215, 1157, 1901, 2570, 1213, 2863.

4) Section 6:
   a) should identify the specific objects that are
      read-create or read-write
   b) since this affects notification generation, should
      note that they 1) are also subject to RFC 2573 and VACM
      for forwarding 2) notifications may be used to mount
      DoS attacks
   c) since table is indexed by resource ID, VACM configuration
      for potentially-re-assigned on reboot resource ids
      (e.g. interface indexes) is problematic
   d) since table is indexed by resource ID, unless VACM
      is configured correctly the table can "leak" resource
      instance ids.

5) Document needs to be spell-checked.  Examples: "Amendement",
   "controled" "detectes".

6) (major technical) the indexing structure for arcTable
   currently uses arcIndex and arcAlarmType.  The arcIndex
   index makes sense.  The arcAlarmType index is currently
   defined as IANAItuProbableCause.  How does a management
   system know which value of IANAItuProbableCuase to supress
   a particular notification type?

7) Which objects' values must survive a re-boot?

8) The  arcMIBTITimeInterval and arcMIBCDTimeInterval are
   currently read-write scalars.  If subagent technology were
   used to implement this mib, (for example, in a system with
   intelligent line cards) it would be simpler if these were
   in the table.  (Also, the names are not particularly helpful.)

9) IANAItuProbableCause is NOT in ALARM-MIB.  Correct IMPORTS.

10) Update MODULE-IDENTITY to look more like other MIBs from
    the WG (I.e., organization should be the working group,
    etc.)

11) Document needs an "IANA Considerations" section to
    allocate the since object identifier for the Module
    Identity.  "mib-2 yy" should have a comment saying that
    the value will be assigned by IANA.

12) Much of the DESCRIPTION in the module identity belongs
    in the arcTable DESCRIPTION.

13) Phrases to fix:
      "The scope of thie MIB is target for" "For examples"
      "until later on explicitly allowed by" word "states"
      missing in "or NALM-QI-CD, as described"

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Mon, 15 Jul 2002 22:55:10 -0400

Dear all,

The following captures the discussion I had with Randy this morning on his comments. They will be presented and further discussed in this afternoon's Disman WG meeting, in particular the open issues.

Regards,
Kam

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Sunday, July 14, 2002 9:15 PM
> To: [email-masked]
> Subject: ARC comments
> 
> 
> Hi -
> 

Agree. Section 11 created. Text from RFC 2026 Section 10.4 (c) added.

>    "Name:" etc from Dave Perkins' entry.  add "USA" and a

Agree. Done.

>    RFC2571, 1155, 1212, 1215, 1157, 1901, 2570, 1213, 2863.

Agree. ^^^ is definitely informative. Others need discussion.
   
                        ^^^^        ^^^^  ^^^^

>       read-create or read-write

Agree. The following new 3rd paragraph added:

   "The following objects are defined with a MAX-ACCESS clause of 
    read-write or read-create: arcMIBTITimeInterval, arcMIBCDTimeInterval,
    arcState, arcNalmTimeRemaining, and arcRowStatus."

>       for forwarding 2) notifications may be used to mount

Agree. The following paragraph is added as new 2nd paragraph:

   "In particular, the ARC setting feature defined in the MIB affects 
    alarm notification generation. Unauthorized access to the write-able 
    objects could cause omission of alarm notifications or flooding 
    of unwanted alarm notifications from the netowrk.  

>       (e.g. interface indexes) is problematic

*** Need discussion in the group. 
    In particular, ifIndex is not garanteed for persistence 
    across re-boot.  (look at IF MIB?)

>       is configured correctly the table can "leak" resource

*** Need discussion in the group. 
    Certain resources may be sensitive for security reason. 
    In this MIB, resource is used for index. 

> 5) Document needs to be spell-checked.  Examples: "Amendement",

Agree. Corrected.

>    a particular notification type?

**** Need discussion in the group.
     Proposal for consideration: 
     Add NotificationId as a third index.
     NotificationId will be used to provision the notification to 
     be suppressed. NotificationId=0.0 implies all notifications.
     IANAProbableCause=0 implies all applicable probable causes for the
     resource. (Need to register new value "0" for IANAProbableCause).
     If this new index added, the MIB can also be used under generic 
     alarm mib framework.
     If this proposal is accepted, text and conformance sections need
     update.  

> 7) Which objects' values must survive a re-boot?

The values of the columnar objects arcMIBTITimeInterval and
arcMIBCDTimeInterval must survive a re-boot. The following sentence
is added to the DESCRIPTION clause of these two objects.

    "Instances of this object persist across agent restarts."

The values of all objects in the arcTable must survive a re-boot.
The following sentence is added to the DESCRIPTION clause of arcEntry.

    "Instances of this conceptual row persist across agent restarts."

>    in the table.  (Also, the names are not particularly helpful.)

**** Need discussion in the group. 
     Cost/Benefit w.r.t. single timer control vs per entry control.

     Benefit for per-entry timer control:
     Simpler for subagent. Don't need memory sharing among subagents.

     Benefit & needs for single timer control:
     Allow the manager to have a single control for the whole system.
     Allow the manager to provision/modify the time even when the arc
     table is empty.

> 9) IANAItuProbableCause is NOT in ALARM-MIB.  Correct IMPORTS.

Agree. Change to IANA-ITU-ALARM-TC.

>     the WG (I.e., organization should be the working group,

Agree. Done.

>     the value will be assigned by IANA.

Agree. The following two notes for the RFC editor were added.

    -- RFC Ed.: replace xxxx with actual RFC number & remove this notice.
    -- RFC Ed.: replace yy with IANA-assigned number & remove this notice.

*** To be added: A new "IANA Considerations" section. Say that:

    "This document requires the allocation of a single object
     identifier beneath the mib-2 subtree for its module identity."

(Search RFC index for "IANA Considerations" for RFC that describes
where the section should go, etc.)

>     in the arcTable DESCRIPTION.

Agree. Move the whole text, except the first paragraph, to the arcTable 
DESCRIPTION.

>       missing in "or NALM-QI-CD, as described"

Agree. Done.

>  Tel: +1 408 546-1006   San Jose, California 95131  USA

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 20 Jul 2002 17:10:31 +0200

>     arcState, arcNalmTimeRemaining, and arcRowStatus."
Note that it is also good to describe what the risks are when such
objects get accessed by unauthorized people. In other words, why
are they a potential security risk if not protected properly.

>     alarm notification generation. Unauthorized access to the 
>     write-able objects could cause omission of alarm notifications 
>     or flooding of unwanted alarm notifications from the netowrk.  
> 
So I guess this relates to the above objects. Would need to check the
complete text to see if that is clear. If not, pls make it so.

.. snip ..

>     "Instances of this conceptual row persist across agent restarts."

Would we want to  s/persist/MUST persist/ ??  or SHOULD?

Bert

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 24 Jul 2002 17:04:29 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Lam, Hing-Kam (Kam)" <[email-masked]>, [email-masked]
> Subject: RE: ARC comments
> Date: Sat, 20 Jul 2002 17:10:31 +0200
...
> are they a potential security risk if not protected properly.

A related point that Kam and I talked about is that even some
of the "not-accessible" data exposed through indexing will
be sensitive in some environments.

...
> Would we want to  s/persist/MUST persist/ ??  or SHOULD?
...

I'd prefer a MUST, but recognize that that in some implementation
environments the persistance may need to be tied to the resource
whose alarms are being controlled.

For example, if an interface card has been removed, it probably
doesn't make sense for the ARC entries corresponding to it to
be reincarnated.  On the other hand, if that card is later
re-inserted, would one expect the ARC entries to re-appear?

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 25 Jul 2002 12:15:36 -0400

Hi,

See inline below.

--Kam

> Sent: Wednesday, July 24, 2002 8:04 PM
> > Message-ID: 
> <[email-masked]
> cent.com>

In response to Bert's comment that "Would need to check the
complete text to see if that is clear. If not, pls make it so",
below is the updated text of Section 6:

6.  Security Considerations

   There are a number of management objects defined in this MIB that
   have a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments. The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.

   In particular, the ARC setting feature defined in the MIB affects 
   alarm notification generation. Unauthorized access to the write-able 
   objects could cause omission of alarm notifications or flooding 
   of unwanted alarm notifications from the netowrk. 

   The following objects are defined with a MAX-ACCESS clause of 
   read-write or read-create: arcMIBTITimeInterval, arcMIBCDTimeInterval,
   arcState, arcNalmTimeRemaining, and arcRowStatus.

   So, it is important to control the GET/SET access to these objects 
   and possibly even encrypt the object values when sending them over the 
   network via SNMP. Not all versions of SNMP provide features for such 
   a secure environment.

   SNMPv1 by itself is not a secure environment. Even if the network
   itself is secure (for example by using IPSec), there is no
   control as to who on the secure network is allowed to access and
   GET/SET (read/change/create/delete) the objects in this MIB.

   It is recommended that the implementers consider the security
   features as provided by the SNMPv3 framework. Specifically, the use
   of the User-based Security Model RFC 2574 [RFC2574] and the View-based
   Access Control Model (VACM) RFC 2575 [RFC2575] is recommended.

   Note that the arc Table is indexed by resource ID. In order to
   prevent leaking of resource instance IDs, VACM should be used and
   correctly configured.

   It is then a customer/user responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB, is properly
   configured to give access to the objects only to those principals
   (users) that have legitimate rights to indeed GET or SET
   (change/create/delete) them.

Any comments?

> re-inserted, would one expect the ARC entries to re-appear?

So will "SHOULD" be more appropriate?
For now, I will use "SHOULD" for version -03 (the one to be 
submitted for WG LC). We can continue discuss this.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 25 Jul 2002 18:50:33 +0200

>    arcState, arcNalmTimeRemaining, and arcRowStatus.

I gues the 3rd para above is the one that details the text in the 
2nd para, right. If so... would this be clearer (assume that people
who read this first time may not yet have looked at the DESCRIPTION
clauses of the objects):

>    of unwanted alarm notifications from the netowrk. These write-able
>    objects (defined with a MAX-ACCESS clause of read-create) are:
>    arcMIBTITimeInterval, arcMIBCDTimeInterval, arcState,
>    arcNalmTimeRemaining, and arcRowStatus.
> 
are those all the writable obkjects in the MIB?
If not, list the others as well

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 25 Jul 2002 13:56:55 -0400

I agree with the suggested change.
The list has all the writable objects, i.e., it is complete.

--Kam

> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Thursday, July 25, 2002 12:51 PM
> To: Lam, Hing-Kam (Kam); 'Randy Presuhn'; [email-masked]