Subject: Re: snmpconf Comments on BCP-09

From: Randy Presuhn <[email-masked]>
Date: Thu, 1 Aug 2002 15:38:26 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Thu, 01 Aug 2002 16:11:37 -0400
> To: [email-masked]
> From: "Wayne F. Tackabury" <[email-masked]>
> Subject: Re: snmpconf Comments on BCP-09
> Cc: "David T. Perkins" <[email-masked]>
> In-Reply-To: <[email-masked]>
...
> A further liability of authentication traps can be seen when they
> are being generated in the face of a Denial Of Service (DOS) attack, in the
> form of a flood of PDUs with invalid community strings, on the
> agent system.  If it is bad enough that the system is having to
> respond to and recover from the invalid agent data accesses, but the
> problem will be compounded if a separate Autentication notification
> PDU is sent to each recipient on the management network.
...

It's not just authentication failure notifications that warrant
caution.  See point (4) in the security considerations section of
draft-ietf-adslmib-adslext-10.txt which describes this fun case:

|    4) ADSL layer connectivity from the ATU-R will permit the subscriber
|    to manipulate both the ADSL link directly and the ADSL overhead
|    control channel(AOC)/embedded operations channel (EOC)
|    for their own loop.  For example,  unchecked or unfiltered
|    fluctuations initiated by the subscriber could generate sufficient
|    notifications to potentially overwhelm either the management
|    interface to the network or the element manager.  Other attacks
|    affecting the ATU-R portions of the MIB may also be possible.

 ------------------------------------------------------
 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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 2 Aug 2002 15:11:39 +0200

Nit:
> >16) Section 3.12, last para, reference to RFC 2591 is not correct.
> >     Note that RFC 2591 (section 6) is incorrect (or at least
> >     misleading) in its description that implies that VACM
> >     provides per user access control. VACM does not provide
> >     per user, but instead provides per group granularity.
> >     This makes a difference, and renders the last paragraph
> >     in section 3.12 pretty bogus.
> 
> Point taken.  The sentence in the middle now reads:
> 
> If so, an "OwnerString" may be used as the first component of a table's 
> index to allow VACM to be used to protect access to subsets of rows, at 
> least at the level of securityName or groupName provided. RFC 2591 
> [23], Section 6  presents this technique in detail.
> 
Note that RFC2591 has now been obsoleted by RFC3231.

Further...

- Please not that RFc-Editor requires References to be split in
  normative and non-normative these days.
  See: http://www.rfc-editor.org/policy.html towards the bottom

- RFC Editor always worries about refences to web pages.
  How stable are they?

- I see that various other docs (I-Ds) are now RFCs.
  You may want to re-check all your references. I guess they
  were created a long time ago and things may have changed
  (often for the better).

Further, I am not sure if section 6 is meant as the
Security Considerations section. I know that Sec ADs
(and many others) will look for that section. If it is meant
that way, then maybe better name it that way.
Otherwise, add such a section, describe the security
considerations of this document, and also point to sect 6.

I sse that the word MUST is used once (in a quoted piece
of text from INET-ADDRESS-MIB). I think I can live with that
with reference to RFC2119. Not sure if all IESG members
will accept that. You might just want to add the reference
and put some words about the use of such terms in intro
of document.
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 2 Aug 2002 15:45:29 +0200

I will need to check the example MIB itself.
I think it IS IMPORTANT to make sure we do a good job
at that mib. It is in a BCP and potentially many people
will/may use it as an example. So the better shape it
is in, the better it can help to develop better MIBs
in the future. 

I would also make clear in the DESCRIPTION clause of
the MODULE-IDENTITY what exactly this example MIB
tries to focus on and tries explain in the example.

Thanks,
Bert

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Fri, 02 Aug 2002 11:21:37 -0400

>- RFC Editor always worries about refences to web pages.

The only one there was the best reference at the time to the structure of 
Cisco access control lists.  In the mean time, several excellent books have 
come out on the subject.  I'll change the reference to point at them.

>(and many others) will look for that section.

Looking over BCPs of the last year or so, about 2/3 of them have a short 
security consid's section, not the typically heavily finessed one that 
accompanies protocol specification RFCs and the like.  We can add that, a 
paragraph which basically serves as a pointer to the areas in the BCP where 
items of security interest were discussed.

We should pass along your observation on MUST in quoted materials to Scott 
Bradner, for whenever RFC 2119 is due for an update.  Clearly, they didn't 
mean for RFC 2119 to apply to previously RFC-approved material in block quotes.

Regards,
Wayne

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 2 Aug 2002 17:43:41 +0200

> material in block quotes.
I am checking with Scott.

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 5 Aug 2002 10:31:54 +0200

The one occurence of MUST (in a quoted text from another
document) is OK without ref to rfc2119.

Thanks,
Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: vrijdag 2 augustus 2002 17:44
> To: [email-masked]
> Subject: RE: snmpconf Comments on BCP-09
> 
>

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 5 Aug 2002 11:54:38 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Fri, 02 Aug 2002 18:23:13 -0700
> To: [email-masked]
> From: Andy Bierman <[email-masked]>
> In-Reply-To: <[email-masked]>
> References: <[email-masked]>
...
> This practice is problematic. The 128 sub-OID limit is an arbitrary
> rule that was added to SMIv2.  The SMIng WG is likely to change the
> limit to 256 sub-OIDs in SMIv3. (I think there should be no limit,
> or a limit of 65535 subOIDs!) It was placed there with the assumption 
> that SNMP PDUs (over UDP) were <= 484 octets in length.  It was
> placed there without much forethought and before it was fashionable
> to use strings in an INDEX clause.
> 
> The current practice of creating an arbitrary SIZE clause that allows
> for (128 - static_oid_length - 1) sub-OIDs is going to cause more
> problems over time than it solves.  There is absolutely no "protocol sense"
> to the limit of 128.  When it changes to a larger number in the
> near future, all MIBs that artificially conform to this limit will be 
> obsolete, and will need to be updated. 
...

Don't forget that this CLR is also enshrined in RFC 1905, and
lives on in the update <draft-ietf-snmpv3-update-proto-08.txt>
It's not just an SMI CLR, it's also part of the protocol
specification.

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 13 Aug 2002 09:05:55 -0700 (PDT)

Hi -

> Date: Tue, 13 Aug 2002 11:13:48 +0200
> Message-Id: <[email-masked]>
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> In-reply-to: <[email-masked]>
> 	([email-masked])
> References: <[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
>  <[email-masked]> <[email-masked]>
> Reply-To: [email-masked]
> 
> 
> >>>>> David T Perkins writes:
> 
> David> 6) David> Fine grained access control assignment - a desirable
> David> property is to allow management apps to create resource
> David> instances via an SNMP set, and to gain "exclusive" or "owner"
> David> access as found in file creation operations found in many
> David> operating systems, such as the Unix variants. However, the
> David> VACM-based access control is VERY different than Unix-like file
> David> access control. A design pattern was introduced in the MIB
> David> modules from the DISMAN WG which attempted to mimic the
> David> Unix-like access control behavior on creation. This design
> David> pattern is flawed (and many have not yet realized it). Please
> David> describe the objective, show the MIB design pattern and
> David> describe how it is flawed.
> 
> Can you please send a message to the DISMAN WG list which explains why
> the design pattern is flawed so that we can all understand the issue
> and either fix it or at least document it somewhere?
...

As disman WG chair, I'd welcome such a discussion on the
disman WG mailing list.

 Randy Presuhn          BMC Software, Inc.  SJC-1.3141