rohrpost

A commandline mail client to change the world as we see it.
git clone git://r-36.net/rohrpost
Log | Files | Refs | README | LICENSE

+MegBIby0M2YtM1Y59M (83322B)


      1 Return-Path: <mrose@dbc.mtview.ca.us>
      2 Received: from thumper.bellcore.com by greenbush.bellcore.com (4.1/4.7)
      3 	id <AA18372> for nsb; Tue, 1 Sep 92 21:31:43 EDT
      4 Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7)
      5 	id <AA17075> for nsb@greenbush; Tue, 1 Sep 92 21:30:38 EDT
      6 Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690)
      7 	id AA07958; Tue, 1 Sep 92 18:29:38 PDT
      8 To: mh-mime@dbc.mtview.ca.us
      9 Subject: I'd like your opinion
     10 Reply-To: mh-mime@dbc.mtview.ca.us
     11 Mime-Version: 1.0
     12 Date: Tue, 01 Sep 1992 18:24:36 -0700
     13 From: Marshall Rose <mrose@dbc.mtview.ca.us>
     14 Resent-To: Nathaniel Borenstein <nsb@thumper.bellcore.com>
     15 Resent-Date: Tue, 01 Sep 1992 18:29:38 -0700
     16 Resent-From: Marshall Rose <mrose@dbc.mtview.ca.us>
     17 Content-Type:  multipart/mixed; boundary="FOOFOO"
     18 Message-ID: <7821.715397074@dbc.mtview.ca.us>
     19 
     20 --FOOFOO
     21 Content-Type: text/plain; charset="us-ascii"
     22 
     23 For "The Simple Times", the openly-available SNMP newsletter which I
     24 edit, there are two editions: a PostScript edition and a MIME edition.
     25 Both are really MIME messages: the former is just a single
     26 application/postscript content, the latter is a highly-structured
     27 multipart/mixed content which contains text/plain at the leaves.
     28 
     29 I am planning on adding a third edition, richtext, which will be like
     30 the text/plain edition, except all the leafs will be text/richtext.
     31 
     32 I have a couple of crude scripts which take the LaTeX subset I use and
     33 produce richtext.  The only problematic area is handling itemize
     34 environments.  Ideally, I'd like to do a bulleted list, but there really
     35 isn't a richtext directive for this.  So, I've done a hack.
     36 
     37 For those of you that are running Borenstein's richtext viewer (or have
     38 your own), I'd like you to take a look at the message below and tell me
     39 what you think of it.  Is it "rich" enough?
     40 
     41 Thanks,
     42 
     43 /mtr
     44 
     45 --FOOFOO
     46 Content-Type: multipart/mixed; boundary="----- =_baaaaaaaaa1"
     47 
     48 
     49 ------- =_baaaaaaaaa1
     50 Reply-to: The Simple Times <st-editorial@simple-times.org>
     51 To:       The Simple Times Subscribers <st-editorial@simple-times.org>
     52 Fcc:      outbox, simple-times/1.3, /etc/lists/simple-times/mime
     53 Subject:  The Simple Times, volume 1, number 3
     54 MIME-Version: 1.0
     55 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
     56 Content-Description: The Simple Times
     57 
     58 ------- =_aaaaaaaaaa0
     59 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa1"
     60 Content-Description: Issue Information
     61 
     62 ------- =_aaaaaaaaaa1
     63 Content-Type: text/richtext; charset="us-ascii"
     64 Content-Description: Masthead
     65 Content-Transfer-Encoding: quoted-printable
     66 
     67 <bold>The Simple Times</bold>(tm)<nl>
     68 <nl>
     69 <center><nl>
     70 ----------------------------------------------------------------------<nl>
     71 The Bi-Monthly Newsletter of SNMP Technology, Comment, and Events (sm)<nl>
     72 Volume 1, Number 3                                   July/August, 1992<nl>
     73 ----------------------------------------------------------------------<nl>
     74 </center>
     75 
     76 ------- =_aaaaaaaaaa1
     77 Content-Type: text/richtext; charset="us-ascii"
     78 Content-Description: READ-ME
     79 Content-Transfer-Encoding: quoted-printable
     80 
     81 <bold>The Simple Times</bold> is an openly-available publication devoted
     82 to the promotion of the Simple Network Management Protocol (SNMP).
     83 In each issue,
     84 <bold>The Simple Times</bold> presents:
     85 a refereed technical article,
     86 an industry comment,
     87 and several featured columns.
     88 In addition, some issues include brief announcements,
     89 summaries of recent publications,
     90 and an activities calendar.
     91 
     92 ------- =_aaaaaaaaaa1
     93 Content-Type: text/richtext; charset="us-ascii"
     94 Content-Description: Disclaimer
     95 Content-Transfer-Encoding: quoted-printable
     96 
     97 <bold>The Simple Times</bold> is openly-available.
     98 You are free to copy, distribute,
     99 or cite its contents.
    100 However,
    101 any use must credit both the contributor and <bold>The Simple
    102 Times</bold>.
    103 (Note that any trademarks appearing herein are the property of their
    104 respective owners.)
    105 Further,
    106 this publication is distributed on an "as is" basis, without warranty.
    107 Neither the publisher nor any contributor shall have any liability to
    108 any person or entity with respect to any liability,
    109 loss,
    110 or damage caused or alleged to be caused directly or indirectly by the
    111 information contained in <bold>The Simple Times</bold>.
    112 <nl><nl>
    113 <bold>The Simple Times</bold> is available via both electronic-mail and
    114 hard-copy.
    115 
    116 ------- =_aaaaaaaaaa1--
    117 
    118 ------- =_aaaaaaaaaa0
    119 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa2"
    120 Content-Description: Issue Contents
    121 
    122 ------- =_aaaaaaaaaa2
    123 Content-Type: text/richtext; charset="us-ascii"
    124 Content-Description: Technical Article
    125 Content-Transfer-Encoding: quoted-printable
    126 
    127 <bold>Technical Article -- <underline>David L. Partain, Linkoping Universi=
    128 ty</underline></bold>
    129 <nl><nl>
    130 <nl>
    131 In this issue: <italic>An Implementation of SNMP Security</italic>
    132 <nl><nl>
    133 <nl>
    134 In his <italic>Security and Protocols</italic> column in <bold>The Simple =
    135 Times</bold>,
    136 Keith McCloghrie discusses SNMP Security.
    137 In his first two columns,
    138 he briefly explained the new security mechanisms,
    139 outlined the protection that these extensions provide,
    140 and showed how the mechanisms are integrated into SNMP.
    141 In this issue,
    142 I report on my implementation of SNMP Security,
    143 demonstrating that the process is certainly feasible,
    144 and hopefully encouraging further fielding of SNMP Security software.
    145 <nl><nl>
    146 In keeping with the SNMP tradition of ensuring implementation
    147 experience prior to standardization,
    148 several implementations of SNMP Security were written while the proposals =
    149 were
    150 Internet-Drafts. =
    151 
    152 Implementation experience is essential to verify the soundness of the
    153 technology and to highlight those areas in the specifications which are
    154 unclear or perhaps not reasonably implementable.
    155 So, I wrote an implementation as a part of my Master's work under Dr. Jeff=
    156 rey
    157 D. Case at the University of Tennessee at Knoxville.
    158 The implementation is based on the 4BSD/ISODE SNMP package.
    159 <nl><nl>
    160 In this article,
    161 I briefly discuss modifications made to an SNMP implementation to incorpor=
    162 ate
    163 the SNMP Security features.
    164 Further,
    165 we'll examine the cost of realizing these changes,
    166 along with improvements made to
    167 the specifications during the implementation period.
    168 In this way I
    169 hope to provide future implementors with modest guidance for
    170 implementing SNMP Security in a performant and correct fashion.
    171 <nl><nl>
    172 The implementation as a whole progressed quickly and without serious
    173 difficulty.
    174 The largest portion of the time was spent in understanding
    175 the software platform and not in the actual coding.
    176 The methodology I
    177 chose was straightforward:  I first altered the wrappers in the SNMP
    178 message and then implemented the party concept from the SNMP administrativ=
    179 e
    180 model.
    181 These two changes essentially implemented noAuth/noPriv.
    182 I then added the Digest Authentication Protocol,
    183 the next logical step,
    184 followed finally by the Symmetric Privacy Protocol.
    185 <nl><nl>
    186 <nl>
    187 <bold>noAuth/noPriv</bold>
    188 <nl><nl>
    189 Recall from the original SNMP specification that the PDU is wrapped
    190 within a <underline>Message</underline>,
    191 which contains not only the PDU,
    192 but also the community string and the SNMP version number: =
    193 
    194 <nl><nl><indent><smaller><samepage>
    195       Message::=3D
    196 <nl>
    197           SEQUENCE {
    198 <nl>
    199               version
    200 <nl>
    201                   INTEGER { version-1(0) },
    202 <nl>
    203 <nl><nl>
    204               community
    205 <nl>
    206                   OCTET STRING,
    207 <nl>
    208 <nl><nl>
    209               data
    210 <nl>
    211                   PDUs
    212 <nl>
    213           }
    214 <nl>
    215 </samepage></smaller><nl></indent><nl>
    216 This is the sole
    217 wrapper.
    218 SNMP Security's innermost wrapper,
    219 the <underline>SnmpMgmtCom</underline>
    220 (SNMP management communication)
    221 includes the PDU along with the identities of the source and destination
    222 parties,
    223 but neither a community string nor a version:
    224 <nl><nl><indent><smaller><samepage>
    225       SnmpMgmtCom ::=3D
    226 <nl>
    227           [1] IMPLICIT SEQUENCE {
    228 <nl>
    229               dstParty
    230 <nl>
    231                   OBJECT IDENTIFIER,
    232 <nl>
    233               srcParty
    234 <nl>
    235                   OBJECT IDENTIFIER,
    236 <nl>
    237               pdu
    238 <nl>
    239                   PDUs
    240 <nl>
    241           }
    242 <nl>
    243 </samepage></smaller><nl></indent><nl>
    244 The <underline>SnmpMgmtCom</underline> is in turn wrapped in a
    245 <underline>SnmpAuthMsg</underline> (SNMP authenticated message),
    246 which contains the authentication information
    247 (<underline>AuthInformation</underline>,
    248 which is used in an authentication protocol-specific manner),
    249 and the <underline>SnmpMgmtCom</underline>:
    250 <nl><nl><indent><smaller><samepage>
    251       SnmpAuthMsg ::=3D
    252 <nl>
    253           [1] IMPLICIT SEQUENCE {
    254 <nl>
    255               authInfo
    256 <nl>
    257                   AuthInformation,
    258 <nl>
    259               authData
    260 <nl>
    261                   SnmpMgmtCom
    262 <nl>
    263           }
    264 <nl>
    265 </samepage></smaller><nl></indent><nl>
    266 Finally,
    267 the <underline>SnmpPrivMsg</underline> (SNMP private message) contains the=
    268  identity of
    269 the destination party and a possibly encrypted serialization of the
    270 <underline>SnmpAuthMsg</underline>: =
    271 
    272 <nl><nl><indent><smaller><samepage>
    273       SnmpPrivMsg ::=3D
    274 <nl>
    275           [1] IMPLICIT SEQUENCE {
    276 <nl>
    277               privDst
    278 <nl>
    279                   OBJECT IDENTIFIER,
    280 <nl>
    281               privData[1]
    282 <nl>
    283                   IMPLICIT OCTET STRING
    284 <nl>
    285           }
    286 <nl>
    287 </samepage></smaller><nl></indent><nl>
    288 Thus,
    289 the first major step is to change from one SNMP wrapper to a wrapper insid=
    290 e a
    291 wrapper inside a wrapper.
    292 <nl><nl>
    293 The additional change to SNMP for noAuth/noPriv is the implementation
    294 of the party database.
    295 Recall that SNMP Security's administrative
    296 model is based upon the notion of an SNMP party,
    297 which can be thought of as the identity of a particular protocol entity
    298 running at a particular network location and in a particular security cont=
    299 ext.
    300 Of course,
    301 a particular protocol entity may operate as any of several parties
    302 (for example,
    303 one which uses no authentication and no privacy,
    304 and one which uses both),
    305 but each party uniquely identifies that protocol entity.
    306 This specificity contrasts with the community-based model used in the orig=
    307 inal
    308 SNMP,
    309 and is necessary in order to uniquely identify the source and destination =
    310 of a
    311 message.
    312 An
    313 implementation of SNMP Security must of course implement a party
    314 database with all the relevant information for that party.
    315 There are
    316 many possible strategies for implementing the party database,
    317 but care should be taken to provide a stable database which is recoverable=
    318 ,
    319 i.e.,
    320 after crashes.
    321 <nl><nl>
    322 The cost of implementing only noAuth/noPriv in comparison to the original =
    323 SNMP
    324 is apparent.
    325 Three wrappers cost more in processing speed,
    326 agent complexity,
    327 and protocol complexity than a single wrapper.
    328 While this is true,
    329 each wrapper serves an essential role in SNMP Security.
    330 The
    331 destination party from the <underline>SnmpPrivMsg</underline> determines w=
    332 hich privacy
    333 protocol to use,
    334 as this is based upon the destination.
    335 The source party in the <underline>SnmpMgmtCom</underline> determines the =
    336 authentication
    337 protocol.
    338 Thus,
    339 each of the wrappers is necessary,
    340 despite the additional cost.
    341 Further,
    342 the cost of the party database,
    343 which could become quite large,
    344 cannot be avoided if SNMP Security is to be used at all.
    345 <nl><nl>
    346 <nl>
    347 <bold>The Digest Authentication Protocol</bold>
    348 <nl><nl>
    349 Implementation of authentication involved:
    350 including the code to generate the MD5 message digest;
    351 adding clock maintenance;
    352 and,
    353 coding the various steps taken to provide incoming and outgoing
    354 authentication.
    355 <nl><nl>
    356 In order to perform the MD5 message digest procedures,
    357 I extracted the appropriate code from the reference C Programming Language
    358 implementation in the MD5 specification (RFC 1321).
    359 The code
    360 integration required little effort.
    361 Naturally,
    362 optimization of the MD5 code for a particular hardware platform is desirab=
    363 le,
    364 if at all possible.
    365 <nl><nl>
    366 Implementation of the authentication steps required that I first manage
    367 loosely synchronized party clocks.
    368 Each SNMP party has its own party clock,
    369 and any outside parties which communicate with that party must keep their =
    370 view
    371 of that party's clock loosely synchronized with its =
    372 
    373 true value.
    374 This is done to protect against message reordering and replay attacks.
    375 I chose to maintain the party clock as an offset from
    376 the system clock where the agent was running,
    377 which eliminated the burden of having to maintain the clock manually.
    378 <nl><nl>
    379 The initial specification for the granularity of this clock was 100
    380 ticks per second.
    381 Additionally,
    382 the <italic>nonce</italic>,
    383 essentially a sequence counter within one clock tick,
    384 permits (2**32) uniquely identified messages to be sent per clock tick.
    385 Since it is unlikely that a party would exchange (2**39) messages per
    386 second,
    387 the clock granularity was later changed to one tick per second.
    388 This still allows for (2**32) messages to be sent per second while avoidin=
    389 g
    390 clock roll-over for over 100 years for those basing their clocks on a 32-b=
    391 it
    392 system clock.
    393 <nl><nl>
    394 Since the correct operation of the MD5 message digest generation
    395 depends upon the private authentication key,
    396 implementors must take precautions to ensure that the keys with which they=
    397  are
    398 dealing are in fact the required 16 octets.
    399 The initial MIB specification did not
    400 include this requirement (although it was stated elsewhere and is now
    401 in the MIB),
    402 and it is wise to take great care in ensuring correctness of the keys,
    403 just as with any value which must be of a specified length.
    404 This is also true with respect to the length of the private
    405 key used for the Symmetric Privacy Protocol.
    406 <nl><nl>
    407 The cost incurred by the Digest Authentication Protocol lies primarily
    408 in the cost of the digest generation code.
    409 A message digest over the
    410 serialized <underline>SnmpAuthMsg</underline> must be performed for both i=
    411 ncoming and outgoing
    412 messages.
    413 Each implementor would be well advised to optimize this code
    414 as much as possible for the deployment platform.
    415 <nl><nl>
    416 A possible additional cost is incurred if one chooses to serialize the
    417 <underline>SnmpAuthMsg</underline> twice on outgoing messages.
    418 The <underline>SnmpAuthMsg</underline> is serialized
    419 once before the digest is generated with the private authentication key
    420 in the authDigest field.
    421 The authDigest field is then replaced with
    422 the computed digest.
    423 If the implementor does not wish to alter the
    424 serialized BER stream in place,
    425 the <underline>SnmpAuthMsg</underline> must then be serialized again.
    426 (In the initial implementation,
    427 I chose the twice-serialized approach.
    428 In the current implementation,
    429 serialization occurs exactly once.)
    430 <nl><nl>
    431 <bold>The Symmetric Privacy Protocol</bold>
    432 <nl><nl>
    433 The final stage of implementation,
    434 inclusion of the Symmetric Privacy Protocol,
    435 involved the integration of DES encryption code.
    436 The export control restrictions with respect to encryption technology,
    437 prompted the use of a public-domain DES implementation which is readily
    438 available outside the United States.
    439 Implementors should ensure that they understand the export and use
    440 restrictions on the Data Encryption Standard before shipping any SNMP Secu=
    441 rity
    442 code.
    443 (In brief,
    444 some countries limit the export and/or use of authentication and privacy
    445 functions.
    446 Accordingly,
    447 any implementor or user should seek the advice of counsel.)
    448 <nl><nl>
    449 One question,
    450 which did not arise when working on my implementation,
    451 dealt with which portion of the serialized
    452 <underline>SnmpAuthMsg</underline> is to be used for authentication and en=
    453 cryption.
    454 Simply put,
    455 the entire BER tag/length/value stream should be used.
    456 <nl><nl>
    457 <bold>Interoperability Testing</bold>
    458 <nl><nl>
    459 Upon completion of the implementation,
    460 interoperability testing was conducted with independent implementations
    461 written by Jeffrey Case and Keith McCloghrie.
    462 Interoperation was successful nearly immediately with all combinations of
    463 authentication and privacy. =
    464 
    465 <nl><nl>
    466 <nl>
    467 <bold>Performance</bold>
    468 <nl><nl>
    469 I conducted several tests with both the SNMP Security implementation and t=
    470 he
    471 original SNMP implementation,
    472 in order to determine the impact on performance.
    473 Each test consisted of retrieving 18,000 variables
    474 to estimate the average number of variables retrieved per second
    475 that could be exchanged between an agent and manager running on the same
    476 SPARCstation I.
    477 <nl><nl><indent><smaller><samepage>
    478   protocol     vars/sec  %-of 1157  %-of prev
    479 <nl>
    480   =3D=3D=3D=3D=3D=3D=3D=3D     =3D=3D=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=
    481 =3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D=3D
    482 <nl>
    483   1157 (SNMP)    60.97      n/a        n/a
    484 <nl>
    485   noAuth/noPriv  37.97      62%        62%
    486 <nl>
    487   md5/noPriv     32.13      53%        85%
    488 <nl>
    489   md5/des        15.06      25%        47%
    490 <nl>
    491 </samepage></smaller><nl></indent><nl>
    492 Based upon these results,
    493 it is apparent that there is a significant loss of speed with even
    494 noAuth/noPriv.
    495 I attribute this to the additional wrapper processing and the added comple=
    496 xity
    497 prior to processing the PDU.
    498 <nl><nl>
    499 Furthermore,
    500 in a given time period,
    501 the manager will be able to retrieve approximately 85% as many variables w=
    502 ith
    503 md5/noPriv as when using noAuth/noPriv.
    504 This result confirms earlier estimates and appears to be a reasonable pric=
    505 e
    506 to pay for authentication.
    507 <nl><nl>
    508 Finally,
    509 as would be expected,
    510 the use of the Symmetric Privacy Protocol greatly reduces the speed of
    511 variable retrieval.
    512 According to these tests,
    513 only 47% as many variables can be retrieved in a given time period when us=
    514 ing
    515 privacy as with md5/noPriv.
    516 This drops to 40% when compared to noAuth/noPriv.
    517 There can be little doubt that hardware implementations of DES or highly
    518 optimized software would speed processing,
    519 but the degree of speedup is unknown.
    520 <nl><nl>
    521 <nl>
    522 <bold>Conclusions</bold>
    523 <nl><nl>
    524 >From my experience in implementing and testing SNMP Security,
    525 I conclude the following:
    526 <nl><nl><indent>
    527 <underline>=3D</underline> The technology proposed by SNMP Security, insof=
    528 ar as it has been
    529 tested in the field, is sound and implementable.  The implementation
    530 process is quite straightforward.  This in itself is valuable
    531 information.
    532 <nl><nl>
    533 <underline>=3D</underline> A critical factor in writing accurate implement=
    534 ations of SNMP
    535 Security is the clarity of the specifications.  There can be little
    536 argument that the security mechanisms make the Simple Network
    537 Management Protocol significantly less simple.  It is safe to say,
    538 however, that given the changes that occurred to the documents through
    539 the implementation process, the clarity of the protocols will lend
    540 themselves well to accurate implementations.  The specifications for
    541 SNMP Security as of January 1992 did not have ambiguities which
    542 produced interoperability problems.  It is essential that this be the
    543 case, and the interoperation of three independent implementations
    544 confirmed this to a large degree. =
    545 
    546 <nl><nl>
    547 <underline>=3D</underline> SNMP Security, as stated by Keith McCloghrie in=
    548  his column, is "not
    549 free."  The performance statistics presented earlier demonstrate
    550 this.  The cost of authentication, and especially privacy, will likely
    551 mean that noAuth/noPriv will be the most common form of network
    552 management communication.  However, SNMP Security also provides the
    553 necessary mechanism for those wishing to manage their networks more
    554 securely.
    555 <nl><nl>
    556 <underline>=3D</underline> The implementation process confirmed the SNMP c=
    557 ommunity's insistence
    558 that implementation precede standardization.  Among the improvements,
    559 the process removed ambiguities in the specification, such as
    560 redundant terminology for the last authenticated message.  Further,
    561 implementation demonstrated useful simplifications.  The clock tick of
    562 one second is one such example.  Finally, experience demonstrated the
    563 value of possible additions.  For example, Jeffrey Case suggested the
    564 addition of a <underline>partyMaxMessageSize</underline> object to facilit=
    565 ate
    566 determination of the maximum message which can be accepted by a party.
    567 Such changes to the specifications would have been significantly more
    568 difficult to include had standardization already begun.
    569 <nl><nl>
    570 <underline>=3D</underline> Keith McCloghrie stated in his column in the pr=
    571 evious issue of
    572 <bold>The Simple Times</bold> that "an agent implementation which followed=
    573  the
    574 guidelines in the original SNMP protocol specification should be able
    575 to (effect) SNMP security with additional code but very few changes
    576 to the existing code."  My implementation experience verifies this
    577 assertion.  With the exception of wrapper changes and the removal of
    578 <italic>trivial</italic> authentication mechanisms, coding meant additions=
    579  rather
    580 than changes.
    581 </indent><nl><nl> =
    582 
    583 <nl><nl>
    584 <nl>
    585 <bold>Acknowledgements</bold>
    586 <nl><nl>
    587 Since working on this implementation,
    588 it has been incorporated into the 4BSD/ISODE SMP package.
    589 This software will be openly-available when the SMP specification is made
    590 available in early July.
    591 An announcement will be made to the <underline>snmp</underline> mailing li=
    592 st at that time.
    593 <nl><nl>
    594 The MD5 implementation I used is taken from RFC 1321,
    595 and is hereby identified as "derived from the RSA Data Security, Inc. MD5
    596 Message-Digest Algorithm".
    597 
    598 ------- =_aaaaaaaaaa2
    599 Content-Type: text/richtext; charset="us-ascii"
    600 Content-Description: Industry Comment
    601 Content-Transfer-Encoding: quoted-printable
    602 
    603 <bold>Industry Comment -- <underline>Marshall T. Rose</underline></bold>
    604 <nl><nl>
    605 <nl>
    606 Welcome to the third issue of <bold>The Simple Times</bold>.
    607 <nl><nl>
    608 In this issue,
    609 the <italic>Industry Comment</italic> presents a perspective on SNMP evolu=
    610 tion.
    611 But first,
    612 some subscription information:
    613 in his <italic>Interoperability</italic> column in the June 8th issue of
    614 <italic>Communications Week</italic>,
    615 Carl Malamud discussed <bold>The Simple Times</bold>.
    616 In the following two weeks,
    617 about 200 more people subscribed for electronic distribution.
    618 The interesting part is that by the morning of June 10th,
    619 nearly sixty had subscribed -- yes,
    620 there are clearly a lot of people who read <italic>Communications Week</it=
    621 alic> as soon
    622 as it hits their mailbox!
    623 Thanks to Carl and the usual trickle of subscription requests,
    624 there are now over 1000 electronic subscribers
    625 (including several re-distribution lists),
    626 with nearly 11% receiving the MIME edition.
    627 <nl><nl>
    628 <nl>
    629 <bold>Evolving the Internet-standard Network Management Framework</bold>
    630 <nl><nl>
    631 The Internet-standard Network Management Framework has achieved unpreceden=
    632 ted
    633 success in providing interoperable solutions to the problem of managing
    634 networks.
    635 At the heart of this framework is the Simple Network Management Protocol
    636 which provides an effective means for monitoring and controlling
    637 heterogeneous devices.
    638 Although it was initially standardized in 1988,
    639 this management framework has been the subject of continuous incremental
    640 refinement.
    641 Paramount to this refinement has been the commitment to provide ongoing
    642 protocol-compatibility,
    643 so that the management environment evolves gracefully whilst the existing
    644 investment is protected.
    645 <nl><nl>
    646 In March of this year,
    647 the Internet Engineering Steering Group (IESG) issued a call for proposals=
    648  to
    649 evolve the Internet-standard Network Management Framework.
    650 A fundamental observation made in this call is the understanding that the
    651 existing framework provides the foundation for stable and effective networ=
    652 k
    653 management of the Internet.
    654 Further, these management capabilities are used pervasively and continuous=
    655 ly.
    656 In other words,
    657 SNMP is an integral part of the Internet community's installed base.
    658 <nl><nl>
    659 At present,
    660 the Internet-standard Network Management Framework consists of three core
    661 technologies:
    662 a notation for describing management information
    663 (termed the "Structure of Management Information" or SMI),
    664 a collection of modules which define management information
    665 (each termed a "Management Information Base" or MIB),
    666 and,
    667 the management protocol, SNMP.
    668 Historically,
    669 the balance between stability and extensibility has been achieved by allow=
    670 ing
    671 only one kind of change:
    672 new MIB modules may be defined and existing ones may be revised.
    673 <nl><nl>
    674 In one response to the IESG's call,
    675 four people developed the <italic>Simple Management Protocol</italic> (SMP=
    676 ) Framework.
    677 The SMP specification and four independent,
    678 interoperable implementations are scheduled for release at the beginning o=
    679 f
    680 July.
    681 (Perhaps before you read this issue of <bold>The Simple Times</bold>.)
    682 When the deadline nears for the IESG's call for proposals,
    683 the SMP authors will submit the current revision of the SMP specification =
    684 for
    685 consideration.
    686 <nl><nl>
    687 Because other proposals may be forthcoming,
    688 rather than examining the SMP Framework,
    689 the <italic>Industry Comment</italic> looks at the issues associated with =
    690 evolving the
    691 Internet-standard Network Management Framework.
    692 <nl><nl>
    693 <nl>
    694 <bold>Build on Success</bold>
    695 <nl><nl>
    696 An essential goal in any evolutionary scheme
    697 must be to build on the success of the current framework.
    698 To optimize the likelihood of this,
    699 it is important that the evolution be based on the same architectural
    700 principles as its predecessor.
    701 Although some may argue as to the precise details,
    702 there are three goals which provided the underlying guidance for the SNMP
    703 architecture:
    704 <nl><nl><indent>
    705 <underline>=3D</underline> the impact of adding network management to mana=
    706 ged nodes must be
    707 minimal, reflecting a lowest common denominator;
    708 <nl><nl>
    709 <underline>=3D</underline> network management must tend towards universal =
    710 deployment;
    711 and,
    712 <nl><nl>
    713 <underline>=3D</underline> when all else fails, network management must co=
    714 ntinue to function,
    715 if at all possible.
    716 </indent><nl><nl>
    717 Historically,
    718 it is clear that the SNMP philosophy of shifting the burden of management =
    719 away
    720 from the managed nodes and towards the management stations,
    721 has allowed us to tend toward the first two goals.
    722 Further,
    723 the minimal communications infrastructure required by the SNMP
    724 (i.e., a connectionless-mode transport service),
    725 has allowed us to achieve the third goal.
    726 <nl><nl>
    727 A second part of building on the success of the current framework is for a=
    728 n
    729 evolutionary scheme to maximize backward-compatibility.
    730 That is,
    731 for each change under consideration,
    732 a careful cost/benefit analysis must be undertaken.
    733 Whilst the advantages of a feature are often evident,
    734 the impact on the installed base is often hidden.
    735 This means that for each change,
    736 the following questions must receive intense scrutiny:
    737 <nl><nl><indent>
    738 <underline>=3D</underline> will the change affect management stations or a=
    739 gents?
    740 <nl><nl>
    741 <underline>=3D</underline> will the change result in a few or a large numb=
    742 er of modifications?
    743 <nl><nl>
    744 <underline>=3D</underline> will those modifications be large or small?
    745 </indent><nl><nl>
    746 Obviously,
    747 to be consistent with the philosophy of the current framework,
    748 the ideal change is one which has a minimal (or preferably no) impact on
    749 agents,
    750 and in which the modifications are well-localized.
    751 <nl><nl>
    752 In brief,
    753 when evaluating any evolutionary scheme,
    754 independent of its technical details,
    755 great attention must be given to the meta-issues of consistency and
    756 compatibility with the current framework.
    757 <nl><nl>
    758 <nl>
    759 <bold>Management Information</bold>
    760 <nl><nl>
    761 In February of this year,
    762 RFC 1303, <italic>A Convention for Describing SNMP-based Agents</italic>,
    763 was published.
    764 This describes a notation by which an implementor could document the
    765 features and limitations of an agent.
    766 This informational document met with a lot of interest,
    767 because it enables three different kinds of interactions:
    768 First,
    769 within an agent vendor company,
    770 RFC 1303 provides a means for engineering to concisely describe to marketi=
    771 ng
    772 the features of their agent products.
    773 Second,
    774 RFC 1303 provides a means for users to evaluate and compare agent products=
    775 .
    776 Third,
    777 RFC 1303 provides a means for management station implementors to customize
    778 their software to know about different kinds of agents.
    779 The way this third interaction works is simple:
    780 the RFC 1303 notation is machine-parseable,
    781 so an administrator runs a compiler that feeds the definitions into the
    782 management station.
    783 Because each kind of agent contains a unique identity code and RFC 1303
    784 definitions include this information,
    785 as a part of its operations,
    786 the management station interrogates the agent and then sees if it has a RF=
    787 C
    788 1303 definition which corresponds to the kind of agent it is talking to.
    789 <nl><nl>
    790 As a part of evaluating RFC 1303,
    791 a compiler with an "agent evaluator" back-end was built.
    792 The algorithm used by the evaluator looks at the RFC 1303 definition of th=
    793 e
    794 agent's capabilities,
    795 assigns a rating from zero to one-hundred which represents the "goodness" =
    796 of
    797 the agent implementation.
    798 The algorithm is limited in that it can evaluate the agent implementation =
    799 only
    800 in a generic sense.
    801 In the prototype,
    802 when the rating is determined,
    803 it is displayed to the user and a different audio file is rendered.
    804 If the rating is zero,
    805 the message might result in:
    806 <nl><nl><indent>
    807 "You have an excellent agent -- not!"
    808 <nl></indent><nl>
    809 Similarly,
    810 a rating of twenty might be several people laughing,
    811 whilst a rating of forty might result in:
    812 <nl><nl><indent>
    813 "Bogus!"
    814 <nl></indent><nl>
    815 and a rating of eighty might result in:
    816 <nl><nl><indent>
    817 "We can name that tune!"
    818 <nl></indent><nl>
    819 (Of course,
    820 this example of the use of RFC 1303 is purposefully humorous.)
    821 <nl><nl>
    822 However,
    823 RFC 1303 is not without its drawbacks:
    824 in addition to requiring that implementors and users understand this new
    825 notation,
    826 management station implementors must build a compiler for the RFC 1303
    827 notation and then instrument their software accordingly.
    828 Further,
    829 vendors of agent products might resist publication of descriptions of thei=
    830 r
    831 agent implementations as this might provide marketing-fodder information t=
    832 o
    833 their competitors.
    834 Another drawback is that RFC 1303 limits its scope to agent implementation=
    835 s
    836 and doesn't consider user requirements.
    837 That is,
    838 the RFC1303 notation describes the capabilities of an agent,
    839 but doesn't have a way to describe the capabilities expected of an agent i=
    840 f it
    841 is going to operate in a particular user-environment.
    842 So,
    843 it would seem that we need both a way of specifying compliance issues in
    844 addition to agent capabilities.
    845 If we had notations for describing both kinds of information,
    846 then one could imagine that,
    847 in the future,
    848 one could write a program which could automatically compare both kinds of
    849 specifications in order to give a rough feeling for how well an agent
    850 implementation would work in the user's environment.
    851 <nl><nl>
    852 <nl>
    853 <bold>Administrative Framework</bold>
    854 <nl><nl>
    855 In terms of authentication and authorization,
    856 any evolutionary scheme will likely include the work on SNMP Security.
    857 <nl><nl>
    858 As Keith McCloghrie has pointed out in his <italic>Security and Protocols<=
    859 /italic>
    860 column
    861 (and as David Partain confirmed in his technical article on
    862 <italic>An Implementation of SNMP Security</italic>)
    863 security has both benefits and costs.
    864 The challenge for implementors is to provide turn-key solutions which hide=
    865  the
    866 details and allow users to get on with the business of managing their netw=
    867 orks.
    868 <nl><nl>
    869 However,
    870 one should keep in mind that even though the long-awaited SNMP Security
    871 work is largely consistent with the SNMP philosophy,
    872 it still needs a small bit of work.
    873 For example,
    874 SNMP Security,
    875 as presently specified,
    876 mandates ordered delivery for intra-party traffic.
    877 As Keith McCloghrie points out in his column in this issue:
    878 ordered delivery is largely unnecessary,
    879 and perhaps harmful,
    880 for retrieval operations;
    881 further,
    882 ordered delivery for intra-party traffic is inadequate for coordinating
    883 multiple managers performing modification operations.
    884 So,
    885 one might expect some additional work in this area.
    886 <nl><nl>
    887 <nl>
    888 <bold>Management Protocol</bold>
    889 <nl><nl>
    890 In terms of the management protocol,
    891 two issues seem to be at the forefront.
    892 <nl><nl>
    893 First,
    894 SNMP's set-request hasn't seen a great deal of operational use.
    895 There are probably two reasons:
    896 one is that some vendors have used the lack of SNMP Security as an excuse =
    897 to
    898 avoid implementing the set-request.
    899 (This is,
    900 of course,
    901 specious as most vendors use a TELNET-based mechanism to modify a
    902 managed node.
    903 In addition to being no more secure than the original SNMP,
    904 because TELNET uses TCP,
    905 during times of network stress it is less likely to be able to control a
    906 device in comparison to using SNMP's set-request.)
    907 In addition to the "security" issue,
    908 when an SNMP set-request fails,
    909 very limited diagnostic information is returned.
    910 In brief,
    911 the management station asks the agent to do something,
    912 and the agent says:
    913 <nl><nl><indent>
    914 "No!"
    915 <nl></indent><nl>
    916 What we really need is a richer collection of diagnostics,
    917 so the management station can determine if the failure is permanent or
    918 transient in nature,
    919 in addition to receiving a coarse indication of the cause.
    920 In other words,
    921 under any evolutionary scheme,
    922 it would be a good idea for the agent to be able to say:
    923 <nl><nl><indent>
    924 "No, because..."
    925 <nl></indent><nl>
    926 Hopefully,
    927 introduction of SNMP Security and a somewhat richer diagnostic set
    928 will greatly increase the use of SNMP for modifying the behavior of manage=
    929 d
    930 nodes.
    931 <nl><nl>
    932 A second protocol issue that must be dealt with is the question of bulk
    933 retrieval. =
    934 
    935 Historically,
    936 this has been one of the areas of greatest mis-understanding.
    937 The plain fact is that it is impractical to require an agent to provide
    938 an arbitrarily large amount of management information in a single transact=
    939 ion.
    940 Hence,
    941 a solution must be based on the notion of incremental retrieval.
    942 Today,
    943 there are several strategies,
    944 all of which make use of SNMP's get-next operator.
    945 Because of this,
    946 each strategy,
    947 regardless of how cleverly it makes use of parallelism and pipelining,
    948 is limited to retrieving a fixed amount of information in each transaction=
    949 .
    950 This would seem to indicate that we need a new SNMP operator for bulk
    951 retrieval,
    952 one in which the agent helps to decide how much information is returned in=
    953  a
    954 given transaction.
    955 However,
    956 great care must go into the design of such a facility,
    957 as it must not unduly burden the managed node.
    958 <nl><nl>
    959 <nl>
    960 <bold>The Open Question</bold>
    961 <nl><nl>
    962 Finally,
    963 there is one issue which needs a fair bit of thought.
    964 Although the Internet-standard Network Management Framework has been very
    965 successful in allowing us to instrument our managed nodes,
    966 it has been less successful in providing us with management applications.
    967 <nl><nl>
    968 Although there may be many causes for this,
    969 the one thing which seems clear is that management information is currentl=
    970 y
    971 defined strictly on a micro-level.
    972 That is,
    973 we produce a lot of MIB modules containing a lot of managed objects;
    974 but nowhere do we produce documents describing how those objects can be us=
    975 ed to
    976 provide for effective management.
    977 The result is that the majority of management applications are browsers.
    978 These browsers,
    979 regardless of the GUI,
    980 have little management smarts.
    981 (Steve Waldbusser discussed this situation in his
    982 <italic>Applications and Directions</italic> column in the previous issue.=
    983 )
    984 <nl><nl>
    985 Achieving this task may be nigh impossible:
    986 first,
    987 the actual details are very often specific to individual environments;
    988 and,
    989 second,
    990 the actual details are also highly technical and (at present) not very
    991 amenable to machine-processing.
    992 However,
    993 figuring out a way of doing this may very well be the most helpful thing o=
    994 f
    995 all.
    996 The amusing part is that activity is probably outside the scope of any
    997 evolutionary scheme!
    998 
    999 ------- =_aaaaaaaaaa2
   1000 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa3"
   1001 Content-Description: Featured Columns
   1002 
   1003 ------- =_aaaaaaaaaa3
   1004 Content-Type: text/richtext; charset="us-ascii"
   1005 Content-Description: Applications and Directions
   1006 Content-Transfer-Encoding: quoted-printable
   1007 
   1008 <bold>Applications and Directions -- <underline>Steven L. Waldbusser</unde=
   1009 rline></bold>
   1010 <nl><nl>
   1011 <nl>
   1012 In this issue: <italic>The Truth About SNMP Performance</italic>
   1013 <nl><nl>
   1014 <nl>
   1015 One of the most frequently repeated concerns about SNMP is that it won't
   1016 perform well or won't scale up to the large networks of the future.
   1017 This is often vocalized as
   1018 "You shouldn't use SNMP because it isn't efficient enough and will clog th=
   1019 e
   1020 network."
   1021 Unfortunately, =
   1022 
   1023 such statements have not been supported by technical rationale or by direc=
   1024 t
   1025 user experience, and this has left consumers very confused.
   1026 There are many large sites using SNMP today to manage networks.
   1027 These sites have direct experience that should ease the uncertainty in thi=
   1028 s
   1029 area. =
   1030 
   1031 <nl><nl>
   1032 There are two areas to be addressed separately:
   1033 <nl><nl><indent>
   1034 <underline>=3D</underline> overall network load for routine monitoring, an=
   1035 d,
   1036 <nl><nl>
   1037 <underline>=3D</underline> efficiency in downloading large amounts of data=
   1038 .
   1039 </indent><nl><nl>
   1040 In addition,
   1041 there are some up and coming advances that will make the situation even
   1042 better.
   1043 <nl><nl>
   1044 <nl>
   1045 <bold>Routine Monitoring</bold>
   1046 <nl><nl>
   1047 Bill Yeager of Stanford University did some tests with SNMP to find out th=
   1048 e
   1049 real story.
   1050 He designed and implemented a test to simulate a worst-case scenario using
   1051 SNMP.
   1052 His results showed that to monitor all the available
   1053 performance and error information on a host at the interface,
   1054 IP and TCP layers every 5 minutes,
   1055 an average of 16 bytes per second were transferred.
   1056 When one scales this up to the monitoring of a large site at which 400
   1057 routers, hubs, and file servers might be monitored,
   1058 one finds that this would use 6400 bytes per second of bandwidth.
   1059 This is equivalent to a half of one percent of an ethernet bandwidth.
   1060 This is clearly not going to cause any performance problems.
   1061 Commercial products are often more optimized and present even less of a lo=
   1062 ad
   1063 on the network.
   1064 It should also be noted that today's monitoring applications typically loo=
   1065 k at
   1066 much less data on each node than tested here -- the results of this test
   1067 would be typical of the increased demands placed by more sophisticated
   1068 applications in the future.
   1069 <nl><nl>
   1070 Carnegie Mellon University also has a large network,
   1071 on which SNMP has proven to scale very well.
   1072 An SNMP monitoring tool monitors more than 200 devices on the Carnegie Mel=
   1073 lon
   1074 network,
   1075 polling each one once every 15 seconds for status information.
   1076 This also uses much less than one percent of an ethernet's bandwidth -- so
   1077 little in fact,
   1078 that a second computer performs the identical task as a backup.
   1079 Both computers spend less than 5% of their processing on these SNMP tasks,
   1080 which shows that high-powered management station hardware is not required.
   1081 <nl><nl>
   1082 <nl>
   1083 <bold>Downloading Large Amounts of Data</bold>
   1084 <nl><nl>
   1085 Another area of concern is the speed at which SNMP can transfer large amou=
   1086 nts
   1087 of data.
   1088 Some MIBs contain tables with many entries that might account for hundreds=
   1089  of
   1090 kilobytes of data.
   1091 It is important to be able to achieve interactive performance when retriev=
   1092 ing
   1093 this data.
   1094 Because the Remote Network Monitoring (RMON) MIB often stores large amount=
   1095 s of
   1096 utilization and error information about network devices,
   1097 it is important that it can be transferred very efficiently with SNMP.
   1098 When Karen Frisa implemented an RMON MIB agent at Carnegie Mellon,
   1099 and John Chanak developed some RMON MIB tools,
   1100 they had the opportunity to transfer large amounts of information using SN=
   1101 MP.
   1102 For example,
   1103 a host table on a segment of the Carnegie Mellon campus usually grows to m=
   1104 ore
   1105 than 1100 entries.
   1106 It was possible to download this table in roughly 2 seconds.
   1107 Because there were 6 variables per entry being downloaded,
   1108 this resulted in a transfer rate of 3060 variables per second.
   1109 Similarly,
   1110 when downloading packets captured by RMON's filter mechanism,
   1111 780 packet entries were downloaded per second.
   1112 If the packet data alone was downloaded
   1113 (ignoring related data such as length and status),
   1114 the rate rose to 2082 per second.
   1115 In this application,
   1116 enough of each packet was downloaded (64 bytes) to perform a summary decod=
   1117 e.
   1118 These results show dramatically that with SNMP,
   1119 bulk data can be downloaded quite quickly.
   1120 <nl><nl>
   1121 A barrier to the fast download of data is the discovery of previously unkn=
   1122 own
   1123 instances of data.
   1124 Before asking for the value of a variable,
   1125 a management station must know its name.
   1126 The SNMP get-next operator allows the discovery of the names of such
   1127 variables, but unless a sophisticated algorithm is used,
   1128 only one instance may be discovered per packet
   1129 (such a sophisticated algorithm is described in RFC 1187,
   1130 <italic>Bulk Table Retrieval with the SNMP</italic>).
   1131 The RMON MIB was specifically designed to allow another method of discover=
   1132 ing
   1133 instances of data quickly.
   1134 However,
   1135 many other MIBs exist that weren't designed with this in mind.
   1136 It would be desirable to provide a fast and easy mechanism to download dat=
   1137 a
   1138 from any MIB.
   1139 The newly defined Simple Management Protocol (SMP) provides such a mechani=
   1140 sm,
   1141 called the get-bulk operator.
   1142 This operator allows the discovery of many variables per packet,
   1143 speeding the transfer of data and making it more efficient by packing more=
   1144  in
   1145 every PDU.
   1146 Initial testing shows that this operator will improve on the blazing speed=
   1147 s
   1148 cited above,
   1149 and will also make normal operations more efficient,
   1150 requiring less network load than the tests mentioned previously.
   1151 <nl><nl>
   1152 <nl>
   1153 <bold>On The Horizon</bold>
   1154 <nl><nl>
   1155 These results show that SNMP is quite capable of scaling to the very large
   1156 networks of today as well as the larger ones of tomorrow.
   1157 This scaling can be achieved without overloading critical segments with
   1158 network management traffic.
   1159 When fast interactive performance is required for downloading large amount=
   1160 s of
   1161 data, =
   1162 
   1163 SNMP can do the job when the management station or the MIB has had the sma=
   1164 rts
   1165 built in.
   1166 The new Simple Management Protocol will provide the means for any data to =
   1167 be
   1168 quickly downloaded.
   1169 Don't let marketeers with a hidden agenda steer you away from the integrat=
   1170 ed
   1171 network management possible with SNMP and SMP!
   1172 
   1173 ------- =_aaaaaaaaaa3
   1174 Content-Type: text/richtext; charset="us-ascii"
   1175 Content-Description: Ask Dr. SNMP
   1176 Content-Transfer-Encoding: quoted-printable
   1177 
   1178 <bold>Ask Dr. SNMP -- <underline>Jeffrey D. Case</underline></bold>
   1179 <nl><nl>
   1180 <nl>
   1181 Dear <italic>Dr. SNMP</italic>,
   1182 <nl><nl>
   1183 I recently read that the new Simple Management Protocol (SMP) will have a
   1184 mechanism for the efficient retrieval of large amounts of data.
   1185 Will this new mechanism be the one described in RFC 1187,
   1186 <italic>Bulk Table Retrieval with the SNMP</italic>,
   1187 or will it be the one described in the premiere issue of <bold>The Simple =
   1188 Times</bold>?
   1189 Will it be fast and efficient?
   1190 <nl><nl>
   1191 P.S. Will <italic>Dr. SNMP</italic> soon become
   1192 <italic>Dr. SMP</italic>?
   1193 <nl><nl>
   1194 -- <italic>Impatient in Indianapolis</italic>
   1195 <nl><nl>
   1196 <nl>
   1197 Dear <italic>Impatient in Indianapolis</italic>,
   1198 <nl><nl>
   1199 Back on the farm,
   1200 we have a saying:
   1201 <nl><nl><indent>
   1202 "That thing's faster than a scalded dog."
   1203 <nl></indent><nl>
   1204 The answer is yes,
   1205 it will be fast and efficient.
   1206 The new bulk retrieval mechanism uses neither of the mechanisms you ask ab=
   1207 out.
   1208 Instead,
   1209 it uses a new operator,
   1210 called get-bulk,
   1211 which has been optimized to communicate requests for the transfer of large
   1212 quantities of data.
   1213 Responses are communicated via the usual SNMP response mechanism.
   1214 <nl><nl>
   1215 Regarding your postscript,
   1216 SMP really is SNMP.
   1217 But,
   1218 the SMP authors couldn't just call it that,
   1219 because the name "SNMP" belongs to the Internet community.
   1220 The SMP authors tried to be careful to avoid offense by using a different
   1221 name.
   1222 (They were perhaps too sensitive.)
   1223 It is anticipated that,
   1224 over time,
   1225 it will be acceptable to call SMP what it really is,
   1226 SNMP version 2.
   1227 <nl><nl>
   1228 <nl>
   1229 <np>
   1230 Dear <italic>Dr. SNMP</italic>,
   1231 <nl><nl>
   1232 Recently I've been hearing about this new management protocol,
   1233 X.700,
   1234 which is supposed to be well-suited for wide-area network (WAN) management=
   1235 .
   1236 The same people who told me about X.700 also tell me that since SNMP is
   1237 a protocol for managing local-area networks (LANs),
   1238 that I need both protocols for network management.
   1239 <nl><nl>
   1240 -- <italic>Vacillating in Virginia</italic>
   1241 <nl><nl>
   1242 <nl>
   1243 Dear <italic>Vacillating in Virginia</italic>,
   1244 <nl><nl>
   1245 Back on the farm,
   1246 we have a saying:
   1247 <nl><nl><indent>
   1248 "You can give a doggie bone to a pig but it still won't hunt."
   1249 <nl></indent><nl>
   1250 (Dr. SNMP thinks this is right up there with
   1251 "A leopard can't change its spots"
   1252 and
   1253 "A zebra can't change its stripes.")
   1254 <nl><nl>
   1255 What this means is that calling something by a different name won't yield
   1256 fundamental changes in its characteristics and behavior.
   1257 Your question brings four important ideas to mind.
   1258 <nl><nl>
   1259 First,
   1260 there are those who are attempting to avoid the excess baggage
   1261 associated with the name of the OSI management framework,
   1262 anchored by CMIP.
   1263 Consequently,
   1264 they are attempting to use a fresh,
   1265 new name (X.700),
   1266 in order to avoid many of the negative connotations and emotions associate=
   1267 d
   1268 with the "CMIP" label.
   1269 Dr. SNMP is somewhat sympathetic toward the notion of using new names for
   1270 existing protocols.
   1271 However,
   1272 the rationale for using "SMP" instead of "SNMP version 2" is entirely
   1273 different than the motives used in renaming CMIP to X.700:
   1274 SMP really is SNMP,
   1275 with a few problems corrected and a few important enhancements.
   1276 SMP uses the same basic well-engineered framework enjoyed by SNMP but thes=
   1277 e
   1278 minimal changes lead to dramatic results.
   1279 In contrast,
   1280 the X.700 framework really is the CMIP framework,
   1281 albeit without any problems corrected and without any important enhancemen=
   1282 ts.
   1283 The motivations for the name changes are quite different.
   1284 <nl><nl>
   1285 Second,
   1286 Dr. SNMP is less charitable toward the dis-information campaign that seems=
   1287  to
   1288 be underway.
   1289 This dis-information campaign attempts to position SNMP as a LAN managemen=
   1290 t
   1291 technology.
   1292 The truth is that while SNMP has become popular as a LAN management
   1293 technology,
   1294 the original impetus for the design was the monitoring and control of wide
   1295 area network components,
   1296 especially IP routers.
   1297 SNMP can,
   1298 has,
   1299 and will continue to perform this function in many
   1300 production networks.
   1301 <nl><nl>
   1302 Third,
   1303 the dis-information campaign attempts to position X.700 as a superior WAN
   1304 management technology.
   1305 The truth is that the requirements of WAN management are incompatible with
   1306 the characteristics and performance of connection-oriented transports in t=
   1307 he
   1308 lossy environments frequently encountered in wide area networks.
   1309 In other words,
   1310 CMIP is actually better suited for use in LANs than it is for use in WANs.
   1311 <nl><nl>
   1312 Finally,
   1313 the dis-information campaign appears to be too well organized and orchestr=
   1314 ated
   1315 to be an accident.
   1316 Perhaps the next dis-information you hear will be that you need a differen=
   1317 t
   1318 protocol for manager-to-manager communications than is used for
   1319 manager-to-agent communications.
   1320 <nl><nl>
   1321 It is difficult for Dr. SNMP to see how dissimilar communications technolo=
   1322 gies
   1323 and techniques will be helpful.
   1324 Building translators between these frameworks
   1325 (SNMP and CMIP)
   1326 is a difficult problem that many have underestimated.
   1327 The entity models are different.
   1328 The information models are different.
   1329 The naming mechanisms are different.
   1330 The SMIs are different.
   1331 The protocol operations are different.
   1332 The transport assumptions are different.
   1333 Other than that,
   1334 they both have managers and agents!
   1335 <nl><nl>
   1336 In conclusion,
   1337 you do not need two different protocols for managing LANs and WANs.
   1338 
   1339 ------- =_aaaaaaaaaa3
   1340 Content-Type: text/richtext; charset="us-ascii"
   1341 Content-Description: Security and Protocols
   1342 Content-Transfer-Encoding: quoted-printable
   1343 
   1344 <bold>Security and Protocols -- <underline>Keith McCloghrie</underline></b=
   1345 old>
   1346 <nl><nl>
   1347 <nl>
   1348 In previous issues,
   1349 we have looked at the protections provided by SNMP Security and discussed =
   1350 how
   1351 introducing the concept of a SNMP party allows the three primary mechanism=
   1352 s:
   1353 the MD5 message digest algorithm,
   1354 the DES encryption algorithm,
   1355 and loosely synchronized clocks to be integrated into the protocol.
   1356 In this issue,
   1357 we'll discuss some issues involved in implementation and deployment.
   1358 <nl><nl>
   1359 <nl>
   1360 <bold>Using Parties</bold>
   1361 <nl><nl>
   1362 Each SNMP party is unique to the particular SNMP protocol implementation =
   1363 
   1364 where it executes.
   1365 Thus, many parties need to be defined.
   1366 The chosen way to do this is to identify them by OBJECT IDENTIFIERs (OIDs)=
   1367 ,
   1368 of which there is an infinite supply!
   1369 This allows anyone to obtain a branch in the OID tree,
   1370 and allocate party OIDs within that branch.
   1371 <nl><nl>
   1372 However,
   1373 to simplify matters, a set of six initial OIDs have been assigned for use
   1374 with each IP address,
   1375 three for local execution at an agent,
   1376 and three for the agent to communicate with
   1377 (i.e., at a manager).
   1378 The three have different settings of authentication and privacy algorithms=
   1379 ,
   1380 with an appropriate MIB view and access control parameters defined for eac=
   1381 h.
   1382 The extension of these six to the number actually required in an agent can=
   1383 ,
   1384 of course,
   1385 be done through the use of SNMP requests acting on appropriate MIB objects=
   1386 .
   1387 <nl><nl>
   1388 The definitions of new encapsulation schemes for SNMP,
   1389 e.g., over OSI,
   1390 are also defining their own conventions for initial Party OIDs using
   1391 their own addressing schemes.
   1392 Note,
   1393 however,
   1394 that the use of an address as part of an OID is purely administrative,
   1395 as one means of providing uniqueness;
   1396 there is no requirement to have a relationship between protocol stack
   1397 addresses and party identifiers.
   1398 <nl><nl>
   1399 Indeed,
   1400 for agents which need more than six parties,
   1401 the party OIDs for the additional parties would typically not be allocated
   1402 from the <underline>initialPartyId</underline> branch,
   1403 but from some other branch
   1404 (e.g., from a OID subtree within the vendor's tree of the management stati=
   1405 on
   1406 which is being used to create them).
   1407 The only requirement to be met when assigning OIDs is to make them unique
   1408 across the network.
   1409 <nl><nl>
   1410 These initial parties need six secrets.
   1411 As it turns out, all six are the same length.
   1412 Thus, at initial distribution,
   1413 all six secrets can have the same value.
   1414 This does not impair security because all six values should be immediately
   1415 changed by the management station as soon as secure communication begins.
   1416 Changing the secrets thereafter is desirable on a relatively frequent basi=
   1417 s.
   1418 When changed,
   1419 there is no need for humans to be informed of the new values.
   1420 In fact,
   1421 it is better security if humans are not informed.
   1422 Humans are typically lazy,
   1423 and thus are unlikely to change secrets at the desired frequency.
   1424 Thus,
   1425 it is a good practice to have the secrets which are in frequent use change=
   1426 d
   1427 automatically.
   1428 <nl><nl>
   1429 Some parties may be set-up for special use,
   1430 for example:
   1431 for use in emergencies by network fire-fighters who may wish to access an
   1432 agent from wherever they may happen to be at the time.
   1433 The secrets for these parties do not need to be changed periodically,
   1434 but can be left unaltered ready for use at a moment's notice.
   1435 <nl><nl>
   1436 <nl>
   1437 <bold>Using Clocks</bold>
   1438 <nl><nl>
   1439 The clock value for each party must increase with the passage of time,
   1440 even across reboots.
   1441 If these clock values are maintained as offsets from a system clock,
   1442 this is not such an implementation burden as it might appear.
   1443 While it is vital that clock values are never decreased
   1444 (in order to maintain protection against replay),
   1445 speeding them up is explicitly allowed.
   1446 For example,
   1447 in times of network stress,
   1448 a manager can artificially advance its notion of a party's clock so that e=
   1449 ven
   1450 though communication delays may have increased dramatically,
   1451 a message will still be considered authentic when it arrives at an agent. =
   1452  =
   1453 
   1454 <nl><nl>
   1455 As was discussed in a previous article,
   1456 the use of clocks ensures message timeliness within the limit specified by=
   1457  the
   1458 lifetime.
   1459 The specifications also include another clock-based mechanism,
   1460 called ordered delivery.
   1461 This mechanism specifies that messages delivered out-of-order be discarded=
   1462  as
   1463 unauthentic.
   1464 While this has some benefit for set-requests,
   1465 there is potential for this to be harmful when applied to retrieval reques=
   1466 ts.
   1467 As such the inclusion of ordered delivery has been questioned,
   1468 but no one wants to further delay the specifications,
   1469 so these arguments are moot at this time.
   1470 Due to the inclusion of ordered delivery,
   1471 another variable (called the nonce)
   1472 is introduced to distinguish multiple requests generated within one =
   1473 
   1474 tick of the clock
   1475 (i.e., within one second).
   1476 <nl><nl>
   1477 <nl>
   1478 <bold>Using Secrets</bold>
   1479 <nl><nl>
   1480 Both the MD5 authentication and the DES privacy algorithms for a party
   1481 rely on secrets,
   1482 which must be known by both the originator and the recipient.
   1483 If these algorithms are to maintain their level of security,
   1484 then their secrets must remain secret and not be available to would-be
   1485 attackers. =
   1486 
   1487 So,
   1488 they cannot be transmitted over the network in clear text form.
   1489 Strictly speaking,
   1490 this requires the use of encryption.
   1491 However,
   1492 the MIB objects for these secrets do not represent them in clear text,
   1493 but rather as the XOR-encoding of the previous and new values in set-reque=
   1494 sts,
   1495 and as zero-length strings in get-requests.
   1496 Thus it is possible,
   1497 though not strictly conformant to the specification,
   1498 to change secrets without using encryption.
   1499 The more significant security issue for implementations which do not inclu=
   1500 de
   1501 an encryption capability is the setting-up of new parties,
   1502 when the XOR-encoding of the new secret (with the null string) provides no
   1503 protection from eavesdroppers.
   1504 Indeed,
   1505 until two SNMP protocol entities share a secret,
   1506 secure communication across the network is not possible.
   1507 Thus,
   1508 security requires that initial secrets be distributed manually,
   1509 generated perhaps by the management station,
   1510 and entered into the agent as a piece of initial configuration information=
   1511 .
   1512 This enables secure communication,
   1513 so that subsequent distribution of secrets,
   1514 either for new parties or for the regular changing of secrets of existing
   1515 parties
   1516 (which is very desirable from a security standpoint),
   1517 can be done via SNMP access to appropriately secured MIB objects.  =
   1518 
   1519 <nl><nl>
   1520 The inclusion of DES may be problematic for some implementors because
   1521 of export regulations.
   1522 While products incorporating DES can be exported from most countries,
   1523 the inclusion of DES may incur additional complications.
   1524 As such, it is to be expected that some implementors may choose not to inc=
   1525 lude
   1526 DES in their implementations,
   1527 especially since conformance to the specification only requires DES for ac=
   1528 cess
   1529 to party secrets and, as mentioned above,
   1530 the requirement to use DES for such access is most significant when
   1531 establishing new parties,
   1532 as opposed to changing the secrets of existing parties.
   1533 <nl><nl>
   1534 <nl>
   1535 <bold>Specification Status</bold>
   1536 <nl><nl>
   1537 Finally,
   1538 you might be wondering about the status of the specifications.
   1539 The author has it on good authority that these documents will be published
   1540 as RFCs with a status of proposed standard by mid-July.
   1541 
   1542 ------- =_aaaaaaaaaa3
   1543 Content-Type: text/richtext; charset="us-ascii"
   1544 Content-Description: Standards
   1545 Content-Transfer-Encoding: quoted-printable
   1546 
   1547 <bold>Standards -- <underline>David T. Perkins</underline></bold>
   1548 <nl><nl>
   1549 <nl>
   1550 In May and June,
   1551 there were no new SNMP-related standards that were approved.
   1552 In the pipeline are the <italic>IP Forwarding Table</italic> MIB and the t=
   1553 hree documents
   1554 defining SNMP Security.
   1555 Only after these documents are published as RFCs with proposed
   1556 standard status will they be included in this column.
   1557 <nl><nl>
   1558 In the previous issue,
   1559 the process which is used in the IETF to develop standards was described.
   1560 In this issue,
   1561 the heritage of the SNMP standards is discussed,
   1562 and in the next issue,
   1563 we'll look at the standards process for IEEE committee 802.
   1564 <nl><nl>
   1565 <nl>
   1566 <bold>Summary of Sources and Internet Standards which they Influenced</bol=
   1567 d>
   1568 <nl><nl>
   1569 >From the International Organization for Standardization (ISO), three
   1570 documents provided some initial influence on the Internet-standard Network
   1571 Management Framework:
   1572 <nl><nl><indent>
   1573 <underline>=3D</underline>     <italic>Abstract Syntax Notation One</itali=
   1574 c> (ASN.1), ISO 8824;
   1575 <nl><nl>
   1576 <underline>=3D</underline>     <italic>Basic Encoding Rules</italic> (BER)=
   1577 , ISO 8825; and,
   1578 <nl><nl>
   1579 <underline>=3D</underline>     <italic>Common Management Information Proto=
   1580 col</italic> (CMIP), ISO 9595/9596.
   1581 </indent><nl><nl>
   1582 The documents produced by IEEE committee 802 has had significant influence=
   1583  on
   1584 several media-specific MIBs:
   1585 <nl><nl><indent>
   1586 <underline>=3D</underline> <italic>Token-Passing Bus Access Method and Phy=
   1587 sical Layer Specifications</italic>,
   1588 802.4, was used as the input to the working group that produced RFC
   1589 1230, <italic>IEEE 802.4 Token Bus Interface Type MIB</italic>;
   1590 <nl><nl>
   1591 <underline>=3D</underline> <italic>Token Ring Access Method and Physical L=
   1592 ayer Specifications</italic>, 802.5,
   1593 was used as the input to the working group that produced RFC 1231,
   1594 <italic>IEEE 802.5 Token Ring Interface Type MIB</italic>;
   1595 <nl><nl>
   1596 <underline>=3D</underline> <italic>Media Access Control (MAC) Bridges</ita=
   1597 lic>, 802.1d, was used as the input
   1598 to the working group that produced RFC 1286, <italic>Bridge MIB</italic>; =
   1599 and,
   1600 <nl><nl>
   1601 <underline>=3D</underline> <italic>CSMA/CD Access Method and Physical Laye=
   1602 r Specifications</italic>, 802.3,
   1603 and <italic>802.3 Layer Management</italic>, 802.3h, were used as the inpu=
   1604 t to
   1605 the working groups that produced RFC 1284, <italic>Ether-Like Interface Ty=
   1606 pe MIB</italic>,
   1607 and RFC 1271, <italic>Remote LAN Monitoring MIB</italic>.
   1608 </indent><nl><nl>
   1609 Finally,
   1610 from ANSI committee X3T9,
   1611 revision 6.2 of the <italic>FDDI Station Management (SMT)</italic> documen=
   1612 t was used as
   1613 the input to the working group that produced RFC 1285,
   1614 <italic>FDDI Interface Type MIB</italic>.
   1615 <nl><nl>
   1616 >From this,
   1617 it can be seen that IEEE 802 has been a major influence on SNMP standards.
   1618 The IEEE is currently in the process of developing a management protocol,
   1619 named LAN/MAN Management Protocol (LMMP).
   1620 LMMP,
   1621 sometimes termed CMIP over LLC (CMOL),
   1622 is based on CMIP running on top of the IEEE 802 connectionless logical lin=
   1623 k
   1624 control (LLC type 1).
   1625 At present,
   1626 it appears that the LMMP work in IEEE 802 will not be used in the Internet
   1627 standardization process,
   1628 but the management information documented in IEEE 802 will continue to be
   1629 used as input to IETF standards development process.
   1630 <nl><nl>
   1631 This issue has listed the SNMP standards that have been significantly infl=
   1632 uenced
   1633 by documents from other organizations.
   1634 The next issue will present the process that develops the IEEE network
   1635 management standards.
   1636 <nl><nl>
   1637 <nl>
   1638 <bold>Summary of Standards</bold>
   1639 <nl><nl>
   1640 Full Standards:
   1641 <nl><nl><indent>
   1642 <underline>=3D</underline> 1155 - Structure of Management Information (SMI=
   1643 );
   1644 <nl><nl>
   1645 <underline>=3D</underline> 1157 - Simple Network Management Protocol (SNMP=
   1646 ); and,
   1647 <nl><nl>
   1648 <underline>=3D</underline> 1213 - Management Information Base (MIB-II).
   1649 </indent><nl><nl>
   1650 Draft Standards:
   1651 <nl><nl><indent>
   1652 <underline>=3D</underline> 1212 - Concise MIB definitions.
   1653 </indent><nl><nl>
   1654 Proposed Standards:
   1655 <nl><nl><indent>
   1656 <underline>=3D</underline> 1229 - Extensions to the generic-interface MIB;
   1657 <nl><nl>
   1658 <underline>=3D</underline> 1230 - IEEE 802.4 Token Bus Interface Type MIB;
   1659 <nl><nl>
   1660 <underline>=3D</underline> 1231 - IEEE 802.5 Token Ring Interface Type MIB=
   1661 ;
   1662 <nl><nl>
   1663 <underline>=3D</underline> 1232 - DS1 Interface Type MIB;
   1664 <nl><nl>
   1665 <underline>=3D</underline> 1233 - DS3 Interface Type MIB;
   1666 <nl><nl>
   1667 <underline>=3D</underline> 1239 - Reassignment of experimental MIBs to sta=
   1668 ndard MIBs;
   1669 <nl><nl>
   1670 <underline>=3D</underline> 1243 - AppleTalk MIB;
   1671 <nl><nl>
   1672 <underline>=3D</underline> 1253 - OSPF version 2 MIB;
   1673 <nl><nl>
   1674 <underline>=3D</underline> 1269 - BGP version 3 MIB;
   1675 <nl><nl>
   1676 <underline>=3D</underline> 1271 - Remote LAN Monitoring MIB;
   1677 <nl><nl>
   1678 <underline>=3D</underline> 1284 - Ether-Like Interface Type MIB;
   1679 <nl><nl>
   1680 <underline>=3D</underline> 1285 - FDDI Interface Type MIB;
   1681 <nl><nl>
   1682 <underline>=3D</underline> 1286 - Bridge MIB;
   1683 <nl><nl>
   1684 <underline>=3D</underline> 1289 - DECnet phase IV MIB;
   1685 <nl><nl>
   1686 <underline>=3D</underline> 1304 - SMDS Interface Protocol (SIP) Interface =
   1687 Type MIB;
   1688 <nl><nl>
   1689 <underline>=3D</underline> 1315 - Frame Relay DTE Interface Type MIB;
   1690 <nl><nl>
   1691 <underline>=3D</underline> 1316 - Character Device MIB;
   1692 <nl><nl>
   1693 <underline>=3D</underline> 1317 - RS-232 Interface Type MIB; and,
   1694 <nl><nl>
   1695 <underline>=3D</underline> 1318 - Parallel Printer Interface Type MIB.
   1696 </indent><nl><nl>
   1697 Experimental:
   1698 <nl><nl><indent>
   1699 <underline>=3D</underline> 1187 - Bulk table retrieval with the SNMP;
   1700 <nl><nl>
   1701 <underline>=3D</underline> 1224 - Techniques for managing asynchronously g=
   1702 enerated alerts;
   1703 <nl><nl>
   1704 <underline>=3D</underline> 1227 - SNMP MUX protocol and MIB;
   1705 <nl><nl>
   1706 <underline>=3D</underline> 1228 - SNMP Distributed Program Interface (SNMP=
   1707 -DPI);
   1708 <nl><nl>
   1709 <underline>=3D</underline> 1238 - CLNS MIB;
   1710 <nl><nl>
   1711 <underline>=3D</underline> 1283 - SNMP over OSI; and,
   1712 <nl><nl>
   1713 <underline>=3D</underline> 1298 - SNMP over IPX.
   1714 </indent><nl><nl>
   1715 Informational:
   1716 <nl><nl><indent>
   1717 <underline>=3D</underline> 1147 - A network management tool catalog;
   1718 <nl><nl>
   1719 <underline>=3D</underline> 1215 - A convention for defining traps for use =
   1720 with the SNMP;
   1721 <nl><nl>
   1722 <underline>=3D</underline> 1303 - A convention for describing SNMP-based a=
   1723 gents; and,
   1724 <nl><nl>
   1725 <underline>=3D</underline> 1321 - MD5 message-digest algorithm.
   1726 </indent><nl><nl>
   1727 Historical:
   1728 <nl><nl><indent>
   1729 <underline>=3D</underline> 1156 - Management Information Base (MIB-I).
   1730 </indent><nl><nl>
   1731 
   1732 ------- =_aaaaaaaaaa3
   1733 Content-Type: text/richtext; charset="us-ascii"
   1734 Content-Description: Working Group Synopses
   1735 Content-Transfer-Encoding: quoted-printable
   1736 
   1737 <bold>Working Group Synopses -- <underline>Robert L. Stewart</underline></=
   1738 bold>
   1739 <nl><nl>
   1740 <nl>
   1741 Once again the working groups supplied plenty of discussion,
   1742 with the prize going to the SNMP mailing list,
   1743 which doesn't even have a working group.
   1744 Be aware that the following synopses present my condensation of many
   1745 statements by many people.
   1746 Although I try to present the flavor and summary of the discussion as it
   1747 occurred,
   1748 I do not include either direct quotes or attribute,
   1749 nor do I edit for correctness.
   1750 If you want to know who really said what,
   1751 subscribe to the mailing lists.
   1752 There's no substitute for being there.
   1753 <nl><nl>
   1754 <nl>
   1755 <bold>SNMP Mailing List</bold>
   1756 <nl><nl>
   1757 Someone designing a MIB asked the best way to report an absolute time,
   1758 suggesting either the UNIX format,
   1759 <underline>DisplayString</underline>,
   1760 or elapsed <underline>TimeTicks</underline>.
   1761 A respondent pointed out that all three approaches had both good and bad
   1762 points.
   1763 This issue was left unresolved.
   1764 <nl><nl>
   1765 Someone asked about good objects to monitor to detect network congestion.
   1766 One opinion held that monitoring <underline>icmpInSrcQuenchs</underline> a=
   1767 nd
   1768 <underline>icmpOutSrcQuenchs</underline> was a good idea.
   1769 Another respondent noted that SNMP  is not well suited to congestion contr=
   1770 ol
   1771 which requires intelligence in hosts,
   1772 routers,
   1773 and bridges.
   1774 The response that SNMP can monitor congestion got agreement,
   1775 if using <underline>ifOutDiscards</underline> or
   1776 <underline>ifOutOctets</underline>,
   1777 with the caveat that source quench itself is optional and defaults to bein=
   1778 g
   1779 disabled.
   1780 A different respondent said they use the ICMP objects because agents runni=
   1781 ng
   1782 on UNIX often cannot supply <underline>ifOutOctets</underline>.
   1783 <nl><nl>
   1784 Someone asked for a UNIX library for MIB-I,
   1785 MIB-II and private MIBs,
   1786 and wondered if the API could be standardized.
   1787 Someone else suggested built-in SNMP for UNIX,
   1788 e.g.,
   1789 an extensible agent,
   1790 and SNMP and ASN.1 libraries,
   1791 all of which could be produced by an IETF working group.
   1792 A respondent noted that implementation specifications are not consistent w=
   1793 ith
   1794 the IETF mission.
   1795 <nl><nl>
   1796 Some asked if,
   1797 in promiscuous mode,
   1798 should all packets be counted in the MIB-II interfaces table,
   1799 or just those packets addressed locally?
   1800 The Interface Extensions MIB says that its receive address table holds onl=
   1801 y
   1802 the addresses used in non-promiscuous mode.
   1803 So,
   1804 the behavior depends on whether the interface being modeled is a MIB-II
   1805 interface.
   1806 In the case of repeater ports,
   1807 which are not MIB-II interfaces,
   1808 counting is not done;
   1809 but,
   1810 if both a bridge and router are using the same interface,
   1811 and it is thus promiscuous,
   1812 all packets are counted.
   1813 <nl><nl>
   1814 Someone asked how does an NMS determine the maximum message size that an a=
   1815 gent
   1816 can accept,
   1817 and on error,
   1818 should the NMS retry progressively smaller sizes or simply drop to the
   1819 minimum size?
   1820 The recommended procedure is to guess initially,
   1821 and then start decreasing until the  complaints stop.
   1822 Unfortunately,
   1823 a long,
   1824 string-valued,
   1825 variable may make the problem insoluble.
   1826 A followup asked that since the request is usually smaller than response,
   1827 how does an agent know the maximum response size?
   1828 The answer was that the SNMP Security Party MIB includes a maximum message
   1829 size.
   1830 <nl><nl>
   1831 Someone asked if enumerated INTEGERs could be negative,
   1832 even though they may not be zero-valued.
   1833 The answer was that use of negative values appears to be within the letter=
   1834 ,
   1835 but not the spirit,
   1836 of the SMI.
   1837 So,
   1838 negative-valued enumerations should not be used.
   1839 <nl><nl>
   1840 There was a fairly long discussion on the parallel processing of incoming =
   1841 SNMP
   1842 requests which produced many warnings for agent implementors.
   1843 <nl><nl>
   1844 Someone asked if order of processing of the variable bindings in a set-req=
   1845 uest
   1846 was important.
   1847 In particular,
   1848 can a manager make any assumption about the order in which processing will
   1849 occur.
   1850 A respondent indicated that the processing must occur "as if simultaneousl=
   1851 y".
   1852 Another respondent observed that there should be no external way to detect=
   1853  the
   1854 order of processing.
   1855 <nl><nl>
   1856 Someone offered to the public domain a utility to monitor a logfile and
   1857 send SNMP traps under conditions from a regular expression.
   1858 The host is <underline>wuarchive.wustl.edu</underline> and the file is
   1859 <underline>/pub/log2sd.tar.Z</underline>
   1860 <nl><nl>
   1861 There were some questions about EMANATE,
   1862 a technology for multiplexing agents on a single host,
   1863 which was announced in the trade press.
   1864 These questions were referred for off-line discussion as EMANATE is a
   1865 commercial product used as a local-mechanism and is out of customary
   1866 IETF concerns.
   1867 <nl><nl>
   1868 Someone asked for real data on SNMP overhead.
   1869 A respondent indicated that a test using a home-grown tool based on the CM=
   1870 U
   1871 package showed that polling for key objects at reasonable periods of 5 and=
   1872  10
   1873 minutes generated negligible Ethernet overhead and very useful information=
   1874 .
   1875 The experimenter concluded that monitoring up to 200 systems this way was =
   1876 not
   1877 intrusive.
   1878 (See this issue's <italic>Applications and Directions</italic> column for =
   1879 further
   1880 discussion.)
   1881 Another respondent suggested traps backed by polling for a "last changed"
   1882 time-stamp,
   1883 carefully designed to avoid fast-changing objects such as normal  message
   1884 counters.
   1885 <nl><nl>
   1886 A message concerning the <italic>Communications Week</italic> story on SMP=
   1887 ,
   1888 a proposed new version of SNMP,
   1889 indicated that the SMP specification and four implementations will
   1890 be available before a planned Birds-of-a-Feather (BOF) at the Boston IETF.
   1891 The message then went on to plead for no follow-up questions to the four S=
   1892 MP
   1893 authors as they have a lot of work to do by then.
   1894 The <italic>Communications Week</italic> reporter asked for community reac=
   1895 tions.
   1896 Although there was some concern over previous contributions of the propose=
   1897 rs
   1898 giving their work too much weight,
   1899 the general consensus was that having relatively complete work by competen=
   1900 t
   1901 people was a good starting place for the open process.
   1902 <nl><nl>
   1903 Someone asked how an agent should respond if it does not implement an obje=
   1904 ct
   1905 in a MIB group which is mandatory for the agent's managed node.
   1906 The immediate,
   1907 first reply was that the agent should return noSuchName.
   1908 Then began an interminable,
   1909 thundering flame war,
   1910 replete with denigration of individuals and companies over a topic that ha=
   1911 s
   1912 been discussed much the same way several times over the past four years.
   1913 The "dogmatic architectural purists" maintained the strict position,
   1914 with justification based on the intention to have a stable,
   1915 predictable base for advanced network management applications.
   1916 The "heretical pragmatic iconoclasts" held that returning a static value
   1917 promoted easy compliance and was necessary due to many existing
   1918 implementations that lacked real information and had to interoperate with =
   1919 NMSs
   1920 that treated noSuchName as a serious failure.
   1921 Those of the "Inquisition" called such responses lies and declared such NM=
   1922 Ss
   1923 broken,
   1924 and the "heretics" retreated behind interoperability and marketing pressur=
   1925 e.
   1926 This discussion will no doubt replay itself in the future,
   1927 perhaps at the Boston IETF.
   1928 <nl><nl>
   1929 Someone noted that statistics in the <italic>Internet Monthly Report</ital=
   1930 ic> showed an
   1931 error rate on one network that was 2000 times better than a second network=
   1932 ,
   1933 and then asked if this was possible.
   1934 One respondent indicated that the information was probably true but could =
   1935 be
   1936 misleading;
   1937 for example,
   1938 9870 errors on a DS1 could indicate a single burst.
   1939 Another respondent said the numbers were for a single interface,
   1940 not a network,
   1941 and that the "good" interface was an Ethernet,
   1942 while the other interfaces were DS1 circuits.
   1943 A followup asked if a new MIB object was needed to indicate what is =
   1944 
   1945 expected as "normal".
   1946 The responses which followed indicated that the concept of "normal" was
   1947 murky.
   1948 <nl><nl>
   1949 Finally,
   1950 there was a very long discussion about the effect of export restrictions
   1951 on SNMP's new security mechanisms.
   1952 The discussion started with several questions:
   1953 are there any changes in U.S.  export regulations,
   1954 is authentication useful without privacy,
   1955 will public domain implementations have privacy,
   1956 can an implementation be compliant without privacy,
   1957 how will the market react if privacy is omitted,
   1958 why hasn't the press caught on to this situation,
   1959 and can the IAB or IETF help.
   1960 The ensuing discussion was rife with fear, uncertainty, and doubt.
   1961 <nl><nl>
   1962 <nl>
   1963 <bold>Bridge MIB Working Group</bold>
   1964 <nl><nl>
   1965 The working group will meet in Boston to consider changes and elevation to=
   1966  =
   1967 
   1968 Draft Standard.
   1969 <nl><nl>
   1970 <nl>
   1971 <bold>Chassis MIB Working Group</bold>
   1972 <nl><nl>
   1973 Someone observed that when adding a repeater port to a box that has other
   1974 functions,
   1975 it gets a LOT more complicated,
   1976 e.g.,
   1977 requiring implementation of the Chassis MIB,
   1978 the Repeater MIB (possibly for multiple repeaters),
   1979 and the Party and View MIBs.
   1980 However,
   1981 under such a model,
   1982 how can one identify a particular repeater port given the IP address of th=
   1983 e
   1984 agent.
   1985 The one respondent indicated that a MIB view model would work,
   1986 and that the Party MIB could be useful for this.
   1987 <nl><nl>
   1988 <nl>
   1989 <bold>DECnet Phase IV MIB Working Group</bold>
   1990 <nl><nl>
   1991 A NMS provider asked for an agent to test against,
   1992 but received no public
   1993 responses.
   1994 <nl><nl>
   1995 In response to several questions he had received,
   1996 the editor said there is no counter for multicast bytes sent because it
   1997 was not in Phase IV DECnet;
   1998 however,
   1999 such an object will be added to the list for the next edit.
   2000 The editor also solicited responses from those interested in interoperabil=
   2001 ity
   2002 testing in the Fall.
   2003 <nl><nl>
   2004 Finally,
   2005 although the working group has concluded its charter,
   2006 the mailing list will remain for implementation discussion.
   2007 <nl><nl>
   2008 <nl>
   2009 <bold>Domain Name Service MIB</bold>
   2010 <nl><nl>
   2011 The mailing list received a new DNS MIB draft in PostScript and ASCII form=
   2012 s.
   2013 The new version of the MIB is now almost 50% smaller.
   2014 <nl><nl>
   2015 <nl>
   2016 <bold>Ethernet MIB Working Group</bold>
   2017 <nl><nl>
   2018 The chair asked if the group needs a meeting at the Boston IETF,
   2019 solicited the participation of IEEE 802.3 people in the group,
   2020 and asked if there were any objections to advancing the MIB forward.
   2021 There were no public responses.
   2022 <nl><nl>
   2023 The mailing list has moved to
   2024 <underline><underline>enet_mib@ftp.com</underline></underline>
   2025 <nl><nl>
   2026 <nl>
   2027 <bold>FDDI MIB Working Group</bold>
   2028 <nl><nl>
   2029 Someone asked if the FDDI trap document had been completely dropped.
   2030 The answer,
   2031 as agreed to by the working group,
   2032 was yes.
   2033 <nl><nl>
   2034 <nl>
   2035 <bold>Host MIB Working Group</bold>
   2036 <nl><nl>
   2037 Someone asked if the presentation made at the San Diego IETF could be
   2038 distributed to the mailing list.
   2039 In response,
   2040 a strawman proposal was distributed.
   2041 <nl><nl>
   2042 The working group was officially formed,
   2043 chartered to define "SNMP MIB objects that instrument
   2044 characteristics common to all internet hosts".
   2045 <nl><nl>
   2046 Request Address:
   2047 <underline><underline>hostmib-request@andrew.cmu.edu</underline></underlin=
   2048 e>
   2049 <nl><nl>
   2050 <nl>
   2051 <bold>IP over Large Public Data Networks (IPLPDN) Working Group</bold>
   2052 <nl><nl>
   2053 Questions about IP over X.25 were referred to the X.25 MIB working group.
   2054 <nl><nl>
   2055 Someone seeking information on an ISDN MIB got two responses:
   2056 first,
   2057 a masters student is writing such a MIB as a part of thesis work,
   2058 with the final form due May 14 prior to submission to the IETF;
   2059 and,
   2060 second,
   2061 a company is working on IP over ISDN experiments,
   2062 with results one or two months out.
   2063 <nl><nl>
   2064 The Boston meeting agenda includes the Frame Relay MIB and the X.25 MIB.
   2065 <nl><nl>
   2066 <nl>
   2067 <bold>Multiport Repeater MIB Working Group</bold>
   2068 <nl><nl>
   2069 Someone suggested changing the syntax of
   2070 <underline>rptrPortAdminState</underline> to be consistent with other MIBs=
   2071 .
   2072 As all other standard MIBs are that way,
   2073 the editors agreed.
   2074 A followup asked a similar question about
   2075 <underline>rptrPortAutoPartitionState</underline>.
   2076 The editors agreed,
   2077 if there were no objections from working group.
   2078 There were no public responses.
   2079 <nl><nl>
   2080 For the meeting at the Boston IETF,
   2081 the only agenda item is MAU MIB.
   2082 <nl><nl>
   2083 Someone wanted to know if on-line detection of health or failure could be =
   2084 done
   2085 reliably and with common meaning.
   2086 A respondent indicated that such information is very implementation-specif=
   2087 ic.
   2088 Further discussion brought a proposed wording change,
   2089 pending editor approval.
   2090 <nl><nl>
   2091 A new Internet-Draft is available with all changes.
   2092 <nl><nl>
   2093 <nl>
   2094 <bold>NOCtools Working Group</bold>
   2095 <nl><nl>
   2096 A message sought tools and volunteers to update entries,
   2097 asking that replies be sent to
   2098 <underline><underline>noctools-request@merit.edu</underline></underline>
   2099 <nl><nl>
   2100 <nl>
   2101 <bold>OSPF Working Group</bold>
   2102 <nl><nl>
   2103 For the meeting at the Boston IETF,
   2104 the agenda includes discussion on the MIB and traps.
   2105 <nl><nl>
   2106 <nl>
   2107 <bold>PPP Working Group</bold>
   2108 <nl><nl>
   2109 A solicitation for MIB comments received the response it looks good so far=
   2110  but
   2111 is still too big.
   2112 <nl><nl>
   2113 Someone asked that since the counter
   2114 <underline>pppLinkPacketTooLongs</underline> counts
   2115 DISCARDED packets longer than MRU,
   2116 should it count packets that are too long but not discarded?
   2117 In response,
   2118 the MIB was changed to include "too long for any reason which results in a
   2119 loss of information or lack of communication".
   2120 If such frames are discarded,
   2121 then their count is also included in <underline>ifInErrors</underline>.
   2122 <nl><nl>
   2123 There was a long and detailed discussion of reusing <underline>ifIndex</un=
   2124 derline> for
   2125 internal PPP layers which included analysis of code and data size.
   2126 Someone argued against filling the MIB-II interfaces table with internal P=
   2127 PP
   2128 details,
   2129 and also noted that counting everything was,
   2130 in general,
   2131 a bad policy.
   2132 There were also objections to optional objects or objects relating to
   2133 unfinished PPP features being required in all MIB implementations.
   2134 <nl><nl>
   2135 Distribution of a new MIB draft elicited comments on various specific obje=
   2136 cts
   2137 and a general objection to the MIB's technique for presenting optional or
   2138 negotiated features.
   2139 The conclusion was to word the MIB so that it doesn't imply a particular
   2140 implementation strategy.
   2141 <nl><nl>
   2142 The editor announced separate documents available as Internet-Drafts for:
   2143 LCP,
   2144 Security,
   2145 IP,
   2146 and Bridging,
   2147 and solicited comments at the Boston IETF.
   2148 <nl><nl>
   2149 <nl>
   2150 <bold>Remote Network Monitoring (RMON) MIB Working Group</bold>
   2151 <nl><nl>
   2152 Someone asked if it is valid to add a new control table entry for either
   2153 invalid or noSuchName entries,
   2154 which is preferred,
   2155 and are there other
   2156 methods?
   2157 A respondent indicated that new entries must be created with createEntry
   2158 status,
   2159 preferably by attempting to set status for a random index.
   2160 A followup objected that a random index won't work in an agent with a smal=
   2161 l,
   2162 fixed table.
   2163 The original respondent noted that the agent should accept any unused inde=
   2164 x
   2165 and map it to internal entries.
   2166 <nl><nl>
   2167 Someone asked for a way to stop data collection but leave results in place=
   2168 .
   2169 A respondent suggested a "freeze" EntryStatus but noted that this is
   2170 inconsistent with concurrent use by multiple managers and prefers a way to
   2171 snapshot.
   2172 <nl><nl>
   2173 Someone asked how possible inconsistencies among interdependent objects sh=
   2174 ould
   2175 be dealt with,
   2176 and went on to suggest various ways to interpret the NMS intent,
   2177 such as order sensitivity.
   2178 This drew the response that agents can't do the NMS job and should ignore
   2179 inconsistencies not prohibited by the MIB specification.
   2180 (It was further noted that SNMP prohibits order sensitivity.)
   2181 <nl><nl>
   2182 A question about RMON extensions for higher level protocols received the r=
   2183 eply
   2184 that such work is scheduled after the Token Ring RMON work completes.
   2185 <nl><nl>
   2186 A long discussion of sensing stations in a token ring reached no clear
   2187 conclusion.
   2188 <nl><nl>
   2189 Someone asked if <underline>historyControlDataSource</underline>,
   2190 (an OID for an interface)
   2191 and <underline>channelIfIndex</underline>
   2192 (an INTEGER for an interface) should be the same.
   2193 A respondent said the two objects are different because the former
   2194 will someday point to other things but the latter may not.
   2195 <nl><nl>
   2196 <nl>
   2197 <bold>SNMP Security Working Group</bold>
   2198 <nl><nl>
   2199 Someone asked that when creating a new MD5 party,
   2200 if a DEFVAL of the empty string could be used for the shared secret.
   2201 The response was that the empty string is appropriate for noAuth parties,
   2202 but is inappropriate for MD5 parties.
   2203 <nl><nl>
   2204 Someone asked about a working group meeting at the Boston IETF.
   2205 After some discussion,
   2206 it was decided to have an implementor's BOF instead.
   2207 <nl><nl>
   2208 Someone asked when a MIB view should be evaluated.
   2209 A respondent noted that is an implementation decision,
   2210 but that it is sensible to evaluate VarBinds as they are processed,
   2211 keeping in mind that evaluation for get-next occurs after the processing,
   2212 not before.
   2213 <nl><nl>
   2214 A late-breaking message said the final Internet-Drafts have been
   2215 approved for standardization by the IAB.
   2216 <nl><nl>
   2217 <nl>
   2218 <bold>X.25 MIB Working Group</bold>
   2219 <nl><nl>
   2220 Someone asked about archives.
   2221 The response is that they are kept on the host <underline>dg-rtp.dg.com</u=
   2222 nderline> in the
   2223 directory <underline>x25mib/</underline>.
   2224 <nl><nl>
   2225 All three documents were reissued with various changes,
   2226 mostly suggested by
   2227 editor,
   2228 and with little group discussion.
   2229 
   2230 ------- =_aaaaaaaaaa3--
   2231 
   2232 ------- =_aaaaaaaaaa2
   2233 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa4"
   2234 Content-Description: Miscellany
   2235 
   2236 ------- =_aaaaaaaaaa4
   2237 Content-Type: text/richtext; charset="us-ascii"
   2238 Content-Description: Activities Calendar
   2239 Content-Transfer-Encoding: quoted-printable
   2240 
   2241 <bold>Activities Calendar</bold>
   2242 <nl><nl>
   2243 <nl><nl><indent>
   2244 <underline>=3D</underline> 24th Meeting of the IETF
   2245 <nl><nl>
   2246 July 13-17, Boston, MA
   2247 <nl><nl>
   2248 For information: +1 703-620-8990
   2249 <nl><nl>
   2250 <underline>=3D</underline> SMP BOF (at the Boston IETF)
   2251 <nl><nl>
   2252 Wednesday, June 15, 7:00-10:00pm
   2253 <nl><nl>
   2254 For information: +1 703-620-8990
   2255 <nl><nl>
   2256 <underline>=3D</underline> 25th Meeting of the IETF
   2257 <nl><nl>
   2258 November 16-20, Washington, DC
   2259 <nl><nl>
   2260 For information: +1 703-620-8990
   2261 </indent><nl><nl>
   2262 
   2263 ------- =_aaaaaaaaaa4--
   2264 
   2265 ------- =_aaaaaaaaaa2--
   2266 
   2267 ------- =_aaaaaaaaaa0
   2268 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa5"
   2269 Content-Description: Administrative Information
   2270 
   2271 ------- =_aaaaaaaaaa5
   2272 Content-Type: text/richtext; charset="us-ascii"
   2273 Content-Description: Publication Information
   2274 Content-Transfer-Encoding: quoted-printable
   2275 
   2276 <bold>The Simple Times</bold> is published with a lot of help from the
   2277 SNMP community.
   2278 <nl><nl>
   2279 <nl>
   2280 			      Publication Staff<nl>
   2281 <nl>
   2282         Coordinating Editor:<nl>
   2283 	    Dr. Marshall T. Rose    Dover Beach Consulting, Inc.<nl>
   2284 <nl>
   2285         Featured Columnists:<nl>
   2286              Dr. Jeffrey D. Case    SNMP Research, Inc.<nl>
   2287                                     University of Tennessee<nl>
   2288                 Keith McCloghrie    Hughes LAN Systems, Inc.<nl>
   2289                 David T. Perkins    SynOptics Communications, Inc.<nl>
   2290                Robert L. Stewart    Xyplex, Inc.<nl>
   2291             Steven L. Waldbusser    Carnegie Mellon University<nl>
   2292 <nl>
   2293 <nl>
   2294                              Contact Information<nl>
   2295 <nl>
   2296                 Postal: The Simple Times<nl>
   2297                         c/o Dover Beach Consulting, Inc.<nl>
   2298                         420 Whisman Court<nl>
   2299                         Mountain View, CA  94043-2112<nl>
   2300 <nl>
   2301                   Tel:          +1 415-968-1052<nl>
   2302                   Fax:          +1 415-968-2510<nl>
   2303                E-mail:          st-editorial@simple-times.org<nl>
   2304                  ISSN:          1060-6068<nl>
   2305 
   2306 ------- =_aaaaaaaaaa5
   2307 Content-Type: text/richtext; charset="us-ascii"
   2308 Content-Description: Submissions
   2309 Content-Transfer-Encoding: quoted-printable
   2310 
   2311 <bold>The Simple Times</bold> solicits high-quality articles of
   2312 technology and comment.
   2313 Technical articles are refereed to ensure that the content is
   2314 marketing-free.
   2315 By definition,
   2316 commentaries reflect opinion and, as such,
   2317 are reviewed only to the extent required to ensure commonly-accepted
   2318 publication norms.
   2319 <nl><nl>
   2320 <bold>The Simple Times</bold> also solicits terse announcements of
   2321 products and services,
   2322 publications,
   2323 and events.
   2324 These contributions are reviewed only to the extent required to ensure
   2325 commonly-accepted publication norms.
   2326 <nl><nl>
   2327 Submissions are accepted only in electronic form.
   2328 A submission consists of ASCII text.
   2329 (Technical articles are also allowed to reference encapsulated
   2330 PostScript figures.)
   2331 Submissions may be sent to the contact address above,
   2332 either via electronic-mail or via magnetic media
   2333 (using either 8mm <italic>tar</italic> tape,
   2334 1/4inch <italic>tar</italic> cartridge-tape,
   2335 or 3-1/2inch MS-DOS floppy-diskette).
   2336 <nl><nl>
   2337 Each submission must include the author's full name,
   2338 title,
   2339 affiliation,
   2340 postal and electronic mail addresses,
   2341 telephone,
   2342 and fax numbers.
   2343 Note that by initiating this process,
   2344 the submitting party agrees to place the contribution into the public
   2345 domain.
   2346 
   2347 ------- =_aaaaaaaaaa5
   2348 Content-Type: text/richtext; charset="us-ascii"
   2349 Content-Description: Subscriptions Information
   2350 Content-Transfer-Encoding: quoted-printable
   2351 
   2352 <bold>The Simple Times</bold> is available via electronic-mail in three
   2353 editions:
   2354 <italic>PostScript</italic>,
   2355 <italic>MIME</italic> (the multi-media 822 mail format),
   2356 and
   2357 <italic>richtext</italic> (a simple page description language).
   2358 For more information,
   2359 send a message to
   2360 <nl><nl><ident>
   2361     st-subscriptions@simple-times.org
   2362 </ident><nl><nl>
   2363 with a <italic>Subject</italic> line of
   2364 <nl><nl><ident>
   2365     help
   2366 </ident><nl><nl>
   2367 In addition,
   2368 <bold>The Simple Times</bold> has numerous hard-copy distribution
   2369 outlets.
   2370 Contact your favorite SNMP vendor and see if they carry it.
   2371 If not,
   2372 contact the publisher and ask for a list.
   2373 (Communications via e-mail or fax are preferred).
   2374 
   2375 ------- =_aaaaaaaaaa5--
   2376 
   2377 ------- =_aaaaaaaaaa0--
   2378 
   2379 ------- =_baaaaaaaaa1--
   2380 
   2381 --FOOFOO--
   2382