Subject: snmpconf Re: ipsec-cfg MIB

From: Jon Saperia <[email-masked]>
Date: Tue, 08 Aug 2000 09:27:03 -0400

on 08/07/2000 4:18 PM, Ricky Charlet at [email-masked] wrote:

> Our work will conform to the IPsec Policy Model document as it morphs
> its way toward standard (draft-ietf-ipsp-config-policy-model-01.txt). We
> will also have assistance from the SNMP-CONF folks to help us conform to
> best current practices and philosophies of SNMP-CONF. I spoke with a few
> representatives in that community and got enthusiastic response.

Hi, I have forwarded this to the SNMPCONF WG list as well since they are of
course interested.  I brought this issue up at our interim meeting this
weekend and you are correct, there are people who are very interested in
working with you on this task.

I will ask one of them to make contact.

/jon

---

From: Ricky Charlet <[email-masked]>
Date: Tue, 08 Aug 2000 12:19:59 -0600

David Waitzman wrote:
> 
> I wrote:
> > > The MIBs have some 4096 octet strings.  Does this conform with the
> > > current BCP for SNMP?   I would have thought a much clumsier split of
> > > the objects into <MMS sized hunks is necessary.
> 
> 
> Ricky Charlet wrote:
> > I'm very glad of your comment that we should focus on conforming to BPC
> > of SNMPCONF as we develop the IPsec Policy MIB. But I have to admit that
> > I can't pace your acronym 'MMS'. Could you explain further please?
> 
> I was using "BCP" as in its generic sense of "Best Current Practice",
> not referring to a particular draft.
> 
> "MMS" means maximum message size, and limits the packet size, so if the
> MMS is assumed to be 1500 or so octets, then a 4096 octet variable can't
> ever fit.  Early SNMPv1 assumed for safety an MMS of 484 bytes (a
> minimum value that all managers/agents needed to work with)!  RFC1351
> may have the first explicit definition of the term in SNMP space.
> 
> He also wrote:
> > The large majority of the octect strings are our "common names" (look
> > at the Textual Convention we defined. These are used as indicies to all
> > the tables. The reasons that we create these octet strings has to do
> > with our managment software and its capabilities rather than any SNMP
> > BPC.
> 
> I understand.
> 
> And he also wrote:
> > That mib is a work for future Redcreek devices.  I'd be glad to answer
> > questions about it but not on this list. This discussion will have to be
> > about the IETF work on a new IPsec Policy MIB.
> 
> That means that you don't (yet) have proof by deployment that the MIB
> works.  That's quite ok and is just a useful data point if people
> reading the MIB think they see problems of the form "how can this
> possibly work"?
> 
> -david

Ah ha, Now I'm getting what you are talking about.  Those 4K byte MIB
objects are intended to hold certificates which have an undetermined
maximum size. I think that you are proposing that overly large objects
with unclear maximum sizes like these be downloaded to the device as a
series of smaller blocks. I think the idea has merit. And I would be
intersted in what folks in the SNMPCONF space have to say about a BCP
when sending down very large objects to divices. Therefore, I am cross
posting this to [email-masked]

-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903

---

From: Jon Saperia <[email-masked]>
Date: Sun, 13 Aug 2000 17:36:34 -0400

> posting this to [email-masked]

I have now caught up on this thread. Beyond IPSec MIB Module questions and a
IPSec Policy MIB Module, the question raised above is a general one. I have
copied Mike MacFaden who is my co-author on the SNMCONF BCP. This discussion
points to a deficiency in the BCP in that we do not discuss the issue of
single data elements that are potentially larger than a single PDU. We
discuss in terms of MIB design and manager/agent interactions multi-PDU
transactions - more work needs to be done here as well.

Specific suggestions for how to best deal with this with the current
architecture are welcome.

/jon

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Aug 2000 10:23:37 -0700

Hi,

So four courses of action come to mind and there are probably 
others/combinations.
Have all of them been discussed besides #3?

Choice 1: Use the universal type "octet string"
   Pro: Simple to understand, follows requirement of not
          making mgmt itself more difficult than technology being managed.
   Con: Any PDU carrying this object will exceed MTU, bad performance results
           Certificate size is implicitly bounded at 65535 bytes per rfc 
2578 pg 6

Choice 2: Use a form of indirection, abstract the certs in the mib
   Pro: Follows the first bcp - use the "correct level of abstraction"
          Certificates are not artificially limited in size
   Con: Problem of actually getting the certificate transferred not solved.

Choice 3: Break Certificate into smaller chunks
     How done: A table could list the certs, and operations can move a cert 
into
     a distribution table that would then have major and minor index and some
     discussion on how to break apart/glue the certs into rows.
     Pro: Certificates are not artificially limited in size
     Con: Manipulating certificates becomes painful, and scaling to large 
number
             of certs will be difficult.

Choice 4: Punt and wait for bulk transfer to be resolved in some future SNMP wg
      pro:  A standard and non painful way of transferring arbitrarily 
large objects exists
      won't be a problem to migrate to.
      con: Certs handled in non-standard way until such a standard exists

Regards,
Mike MacFaden
www.riverstonenet.com

At 05:36 PM 8/13/2000 -0400, Jon Saperia wrote:
>Now I'm getting what you are talking about.  Those 4K byte MIB