idnits 2.17.1 draft-ietf-pppext-secmib-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [5,6], [10], [11], [12], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (11 May 1993) is 11307 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 561 looks like a reference -- Missing reference section? '5' on line 573 looks like a reference -- Missing reference section? '6' on line 577 looks like a reference -- Missing reference section? '1' on line 549 looks like a reference -- Missing reference section? '2' on line 555 looks like a reference -- Missing reference section? '4' on line 567 looks like a reference -- Missing reference section? '7' on line 581 looks like a reference -- Missing reference section? '8' on line 584 looks like a reference -- Missing reference section? '9' on line 588 looks like a reference -- Missing reference section? '10' on line 591 looks like a reference -- Missing reference section? '11' on line 594 looks like a reference -- Missing reference section? '12' on line 597 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 4 The Definitions of Managed Objects for 5 the Security Protocols of 6 the Point-to-Point Protocol 8 11 May 1993 10 Frank Kastenholz 11 FTP Software, Inc 12 2 High Street 13 North Andover, Mass 01845 USA 15 kasten@ftp.com 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are 20 working documents of the Internet Engineering Task Force 21 (IETF), its Areas, and its Working Groups. Note that other 22 groups may also distribute working documents as Internet 23 Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or 27 obsoleted by other documents at any time. It is not 28 appropriate to use Internet Drafts as reference material or to 29 cite them other than as a ``working draft'' or ``work in 30 progress.'' Please check the 1id-abstracts.txt listing 31 contained in the internet-drafts Shadow Directories on 32 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or 33 munnari.oz.au to learn the current status of any Internet 34 Draft. 36 This document will be submitted to the Internet Activities 37 Board as a Proposed Standard. This document defines an 38 experimental extension to the SNMP MIB. Upon publication as a 39 Proposed Standard, a new MIB number will be assigned. This is 40 a working document only, it should neither be cited nor quoted 41 in any formal document. 43 This document will expire before 16 Nov. 1993. 45 Distribution of this document is unlimited. 47 Please send comments to the author. 49 1. Abstract 51 This memo defines an experimental portion of the Management 52 Information Base (MIB) for use with network management 53 protocols in TCP/IP-based internets. In particular, it 54 describes managed objects used for managing the Security 55 Protocols on subnetwork interfaces using the family of 56 Point-to-Point Protocols[8, 9, 10, 11, & 12]. 58 This memo does not specify a standard for the Internet 59 community. 61 2. The Network Management Framework 63 The Internet-standard Network Management Framework consists of 64 three components. They are: 66 RFC 1155 which defines the SMI, the mechanisms used for 67 describing and naming objects for the purpose of 68 management. RFC 1212 defines a more concise description 69 mechanism, which is wholly consistent with the SMI. 71 RFC 1213 defines MIB-II, the core set of managed objects 72 for the Internet suite of protocols. 74 RFC 1157 which defines the SNMP, the protocol used for 75 network access to managed objects. 77 The Framework permits new objects to be defined for the 78 purpose of experimentation and evaluation. 80 3. Objects 82 Managed objects are accessed via a virtual information store, 83 termed the Management Information Base or MIB. Objects in the 84 MIB are defined using the subset of Abstract Syntax Notation 85 One (ASN.1) [3] defined in the SMI. In particular, each 86 object type is named by an OBJECT IDENTIFIER, an 87 administratively assigned name. The object type together with 88 an object instance serves to uniquely identify a specific 89 instantiation of the object. For human convenience, we often 90 use a textual string, termed the descriptor, to refer to the 91 object type. 93 3.1. Format of Definitions 95 Section 5 contains the specification of all object types 96 contained in this MIB module. The object types are defined 97 using the conventions defined in the SMI, as amended by the 98 extensions specified in [5,6]. 100 4. Overview 102 4.1. Object Selection Criteria 104 To be consistent with IAB directives and good engineering 105 practice, an explicit attempt was made to keep this MIB as 106 simple as possible. This was accomplished by applying the 107 following criteria to objects proposed for inclusion: 109 (1) Require objects be essential for either fault or 110 configuration management. In particular, objects for 111 which the sole purpose was to debug implementations were 112 explicitly excluded from the MIB. 114 (2) Consider evidence of current use and/or utility. 116 (3) Limit the total number of objects. 118 (4) Exclude objects which are simply derivable from others in 119 this or other MIBs. 121 4.2. Structure of the PPP 123 This section describes the basic model of PPP used in 124 developing the PPP MIB. This information should be useful to 125 the implementor in understanding some of the basic design 126 decisions of the MIB. 128 The PPP is not one single protocol but a large family of 129 protocols. Each of these is, in itself, a fairly complex 130 protocol. The PPP protocols may be divided into three rough 131 categories: 133 Control Protocols 134 The Control Protocols are used to control the operation 135 of the PPP. The Control Protocols include the Link 136 Control Protocol (LCP), the Password Authentication 137 Protocol (PAP), the Link Quality Report (LQR), and the 138 Challenge Handshake Authentication Protocol (CHAP). 140 Network Protocols 141 The Network Protocols are used to move the network 142 traffic over the PPP interface. A Network Protocol 143 encapsulates the datagrams of a specific higher-layer 144 protocol that is using the PPP as a data link. Note that 145 within the context of PPP, the term "Network Protocol" 146 does not imply an OSI Layer-3 protocol; for instance, 147 there is a Bridging network protocol. 149 Network Control Protocols (NCPs) 150 The NCPs are used to control the operation of the Network 151 Protocols. Generally, each Network Protocol has its own 152 Network Control Protocol; thus, the IP Network Protocol 153 has its IP Control Protocol, the Bridging Network 154 Protocol has its Bridging Network Control Protocol and so 155 on. 157 This document specifies the objects used in managing one of 158 these protocols, namely the PPP Authentication Protocols. 160 4.3. MIB Groups 162 Objects in this MIB are arranged into several MIB groups. 163 Each group is organized as a set of related objects. 165 These groups are the basic unit of conformance: if the 166 semantics of a group are applicable to an implementation then 167 all objects in the group must be implemented. 169 The PPP MIB is organized into several MIB Groups, including, 170 but not limited to, the following groups: 171 o The PPP Link Group 172 o The PPP LQR Group 173 o The PPP LQR Extensions Group 174 o The PPP IP Group 175 o The PPP Bridge Group 176 o The PPP Security Group 178 This document specifies the following group: 180 PPP Security Group 181 The PPP Security Group contains all configuration and 182 control variables that apply to PPP security. 184 Implementation of this group is optional. Implementation 185 is optional since the variables in this group provide 186 configuration and control for the PPP Security functions. 187 Thus, these variables should be protected by SNMPv2 188 security. If an agent does not support SNMPv2 with 189 privacy it is strongly advised that this group not be 190 implemented. See the section on "Security 191 Considerations" at the end of this document. 193 5. Definitions 195 PPP-SEC-MIB DEFINITIONS ::= BEGIN 197 IMPORTS 198 experimental, Counter 199 FROM RFC1155-SMI 200 OBJECT-TYPE 201 FROM RFC-1212 202 ppp 203 FROM PPP-LCP-MIB; 205 pppSecurity OBJECT IDENTIFIER ::= { ppp 2 } 207 pppSecurityProtocols OBJECT IDENTIFIER ::= { pppSecurity 1 } 209 -- The following uniquely identify the various protocols 210 -- used by PPP security. These OBJECT IDENTIFIERS are 211 -- used in the pppSecurityConfigProtocol and 212 -- pppSecuritySecretsProtocol objects to identify to which 213 -- protocols the table entries apply. 215 pppSecurityPapProtocol OBJECT IDENTIFIER ::= 216 { pppSecurityProtocols 1 } 217 pppSecurityChapMD5Protocol OBJECT IDENTIFIER ::= 218 { pppSecurityProtocols 2 } 220 -- PPP Security Group 221 -- Implementation of this group is optional. 223 -- This table allows the network manager to configure 224 -- which security protocols are to be used on which 225 -- link and in what order of preference each is to be tried 227 pppSecurityConfigTable OBJECT-TYPE 228 SYNTAX SEQUENCE OF PppSecurityConfigEntry 229 ACCESS not-accessible 230 STATUS mandatory 231 DESCRIPTION 232 "Table containing the configuration and 233 preference parameters for PPP Security." 235 ::= { pppSecurity 2 } 237 pppSecurityConfigEntry OBJECT-TYPE 238 SYNTAX PppSecurityConfigEntry 239 ACCESS not-accessible 240 STATUS mandatory 241 DESCRIPTION 242 "Security configuration information for a 243 particular PPP link." 244 INDEX { pppSecurityConfigLink, 245 pppSecurityConfigPreference } 246 ::= { pppSecurityConfigTable 1 } 248 PppSecurityConfigEntry ::= SEQUENCE { 249 pppSecurityConfigLink 250 INTEGER, 251 pppSecurityConfigPreference 252 INTEGER, 253 pppSecurityConfigProtocol 254 OBJECT IDENTIFIER, 255 pppSecurityStatus 256 INTEGER 257 } 259 pppSecurityConfigLink OBJECT-TYPE 260 SYNTAX INTEGER(0..2147483648) 261 ACCESS read-write 262 STATUS mandatory 263 DESCRIPTION 264 "The value of ifIndex that identifies the entry 265 in the interface table that is associated with 266 the local PPP entity's link for which this 267 particular security algorithm shall be 268 attempted. A value of 0 indicates the default 269 algorithm - i.e., this entry applies to all 270 links for which explicit entries in the table 271 do not exist." 272 ::= { pppSecurityConfigEntry 1 } 274 pppSecurityConfigPreference OBJECT-TYPE 275 SYNTAX INTEGER(0..2147483648) 276 ACCESS read-write 277 STATUS mandatory 278 DESCRIPTION 279 "The relative preference of the security 280 protocol identified by 281 pppSecurityConfigProtocol. Security protocols 282 with lower values of 283 pppSecurityConfigPreference are tried before 284 protocols with higher values of 285 pppSecurityConfigPreference." 286 ::= { pppSecurityConfigEntry 2 } 288 pppSecurityConfigProtocol OBJECT-TYPE 289 SYNTAX OBJECT IDENTIFIER 290 ACCESS read-write 291 STATUS mandatory 292 DESCRIPTION 293 "Identifies the security protocol to be 294 attempted on the link identified by 295 pppSecurityConfigLink at the preference level 296 identified by pppSecurityConfigPreference. " 297 ::= { pppSecurityConfigEntry 3 } 299 pppSecurityConfigStatus OBJECT-TYPE 300 SYNTAX INTEGER { 301 invalid(1), 302 valid(2) 303 } 304 ACCESS read-write 305 STATUS mandatory 306 DESCRIPTION 307 "Setting this object to the value invalid(1) 308 has the effect of invalidating the 309 corresponding entry in the 310 pppSecurityConfigTable. It is an 311 implementation-specific matter as to whether 312 the agent removes an invalidated entry from the 313 table. Accordingly, management stations must 314 be prepared to receive tabular information from 315 agents that corresponds to entries not 316 currently in use. Proper interpretation of 317 such entries requires examination of the 318 relevant pppSecurityConfigStatus object." 319 DEFVAL { valid } 320 ::= { pppSecurityConfigEntry 4 } 322 -- This table contains all of the ID/Secret pair information. 324 pppSecuritySecretsTable OBJECT-TYPE 325 SYNTAX SEQUENCE OF PppSecuritySecretsEntry 326 ACCESS not-accessible 327 STATUS mandatory 328 DESCRIPTION 329 "Table containing the identities and secrets 330 used by the PPP authentication protocols. As 331 this table contains secret information, it is 332 expected that access to this table be limited 333 to those SNMP Party-Pairs for which a privacy 334 protocol is in use for all SNMP messages that 335 the parties exchange. This table contains both 336 the ID and secret pair(s) that the local PPP 337 entity will advertise to the remote entity and 338 the pair(s) that the local entity will expect 339 from the remote entity. This table allows for 340 multiple id/secret password pairs to be 341 specified for a particular link by using the 342 pppSecuritySecretsIdIndex object." 343 ::= { pppSecurity 3 } 345 pppSecuritySecretsEntry OBJECT-TYPE 346 SYNTAX PppSecuritySecretsEntry 347 ACCESS not-accessible 348 STATUS mandatory 349 DESCRIPTION 350 "Secret information." 351 INDEX { pppSecuritySecretsLink, 352 pppSecuritySecretsIdIndex } 353 ::= { pppSecuritySecretsTable 1 } 355 PppSecuritySecretEntry ::= SEQUENCE { 356 pppSecuritySecretsLink 357 INTEGER, 358 pppSecuritySecretsIdIndex 359 INTEGER, 360 pppSecuritySecretsDirection 361 INTEGER, 363 pppSecuritySecretsProtocol 364 OBJECT IDENTIFIER, 365 pppSecuritySecretsIdentity 366 OCTET STRING, 367 pppSecuritySecretsSecret 368 OCTET STRING, 369 pppSecuritySecretsStatus 370 INTEGER 371 } 373 pppSecuritySecretsLink OBJECT-TYPE 374 SYNTAX INTEGER(0..2147483648) 375 ACCESS read-only 376 STATUS mandatory 377 DESCRIPTION 378 "The link to which this ID/Secret pair applies. 379 By convention, if the value of this object is 0 380 then the ID/Secret pair applies to all links." 381 ::= { pppSecuritySecretsEntry 1 } 383 pppSecuritySecretsIdIndex OBJECT-TYPE 384 SYNTAX INTEGER(0..2147483648) 385 ACCESS read-only 386 STATUS mandatory 387 DESCRIPTION 388 "A unique value for each ID/Secret pair that 389 has been defined for use on this link. This 390 allows multiple ID/Secret pairs to be defined 391 for each link. How the local entity selects 392 which pair to use is a local implementation 393 decision." 394 ::= { pppSecuritySecretsEntry 2 } 396 pppSecuritySecretsDirection OBJECT-TYPE 397 SYNTAX INTEGER { 398 local-to-remote(1), 399 remote-to-local(2) 400 } 401 ACCESS read-write 402 STATUS mandatory 403 DESCRIPTION 404 "This object defines the direction in which a 405 particular ID/Secret pair is valid. If this 406 object is local-to-remote then the local PPP 407 entity will use the ID/Secret pair when 408 attempting to authenticate the local PPP entity 409 to the remote PPP entity. If this object is 410 remote-to-local then the local PPP entity will 411 expect the ID/Secret pair to be used by the 412 remote PPP entity when the remote PPP entity 413 attempts to authenticate itself to the local 414 PPP entity." 415 ::= { pppSecuritySecretsEntry 3 } 417 pppSecuritySecretsProtocol OBJECT-TYPE 418 SYNTAX OBJECT IDENTIFIER 419 ACCESS read-write 420 STATUS mandatory 421 DESCRIPTION 422 "The security protocol (e.g. CHAP or PAP) to 423 which this ID/Secret pair applies." 424 ::= { pppSecuritySecretsEntry 4 } 426 pppSecuritySecretsIdentity OBJECT-TYPE 427 SYNTAX OCTET STRING (SIZE(0..255)) 428 ACCESS read-write 429 STATUS mandatory 430 DESCRIPTION 431 "The Identity of the ID/Secret pair. The 432 actual format, semantics, and use of 433 pppSecuritySecretsIdentity depends on the 434 actual security protocol used. For example, if 435 pppSecuritySecretsProtocol is 436 pppSecurityPapProtocol then this object will 437 contain a PAP Peer-ID. If 438 pppSecuritySecretsProtocol is 439 pppSecurityChapMD5Protocol then this object 440 would contain the CHAP NAME parameter." 441 ::= { pppSecuritySecretsEntry 5 } 443 pppSecuritySecretsSecret OBJECT-TYPE 444 SYNTAX OCTET STRING (SIZE(0..255)) 445 ACCESS read-write 446 STATUS mandatory 447 DESCRIPTION 448 "The secret of the ID/Secret pair. The actual 449 format, semantics, and use of 450 pppSecuritySecretsSecret depends on the actual 451 security protocol used. For example, if 452 pppSecuritySecretsProtocol is 453 pppSecurityPapProtocol then this object will 454 contain a PAP Password. If 455 pppSecuritySecretsProtocol is 456 pppSecurityChapMD5Protocol then this object 457 would contain the CHAP MD5 Secret." 458 ::= { pppSecuritySecretsEntry 6 } 460 pppSecuritySecretsStatus OBJECT-TYPE 461 SYNTAX INTEGER { 462 invalid(1), 463 valid(2) 464 } 465 ACCESS read-write 466 STATUS mandatory 467 DESCRIPTION 468 "Setting this object to the value invalid(1) 469 has the effect of invalidating the 470 corresponding entry in the 471 pppSecuritySecretsTable. It is an 472 implementation-specific matter as to whether 473 the agent removes an invalidated entry from the 474 table. Accordingly, management stations must 475 be prepared to receive tabular information from 476 agents that corresponds to entries not 477 currently in use. Proper interpretation of 478 such entries requires examination of the 479 relevant pppSecuritySecretsStatus object." 480 DEFVAL { valid } 481 ::= { pppSecuritySecretsEntry 7 } 483 END 484 6. Acknowledgements 486 This document was produced by the PPP working group. In 487 addition to the working group, the author wishes to thank the 488 following individuals for their comments and contributions: 490 Bill Simpson -- Daydreamer 491 Glenn McGregor -- Merit 492 Jesse Walker -- DEC 493 Chris Gunner -- DEC 494 7. Security Considerations 496 The PPP MIB affords the network operator the ability to 497 configure and control the PPP links of a particular system, 498 including the PPP authentication protocols. This represents a 499 security risk. 501 These risks are addressed in the following manners: 503 (1) All variables which represent a significant security risk 504 are placed in separate, optional, MIB Groups. As the MIB 505 Group is the quantum of implementation within a MIB, the 506 implementor of the MIB may elect not to implement these 507 groups. 509 (2) The implementor may choose to implement the variables 510 which present a security risk so that they may not be 511 written, i.e., the variables are READ-ONLY. This method 512 still presents a security risk, and is not recommended, 513 in that the variables, specifically the PPP 514 Authentication Protocols' variables, may be easily read. 516 (3) Using SNMPv2, the operator can place the variables into 517 MIB views which are protected in that the parties which 518 have access to those MIB views use authentication and 519 privacy protocols, or the operator may elect to make 520 these views not accessible to any party. In order to 521 facilitate this placement, all security-related variables 522 are placed in separate MIB Tables. This eases the 523 identification of the necessary MIB View Subtree. 525 (4) The PPP Security Protocols MIB (this document) contains 526 several objects which are very sensitive from a security 527 point of view. 529 Specifically, this MIB contains objects that define the 530 PPP Peer Identities (which can be viewed as "userids") 531 and the secrets used to authenticate those Peer 532 Identities (similar to a "password" for the "userid"). 534 Also, this MIB contains variables which would allow a 535 network manager to control the operation of the security 536 features of PPP. An intruder could disable PPP security 537 if these variables were not properly protected. 539 Thus, in order to preserve the integrity, security and 540 privacy of the PPP security features, an implementation 541 will allow access to this MIB only via SNMPv2 and then 542 only for parties which are privacy enhanced. Other 543 access modes, e.g., SNMPv1 or SNMPv2 without privacy- 544 enhancement, are very dangerous and the security of the 545 PPP service may be compromised. 547 8. References 549 [1] M.T. Rose and K. McCloghrie, Structure and Identification 550 of Management Information for TCP/IP-based internets, 551 Internet Working Group Request for Comments 1155. 552 Network Information Center, SRI International, Menlo 553 Park, California, (May, 1990). 555 [2] K. McCloghrie and M.T. Rose, Management Information Base 556 for Network Management of TCP/IP-based internets - MIB-2, 557 Internet Working Group Request for Comments 1213. 558 Network Information Center, SRI International, Menlo 559 Park, California, (March, 1991). 561 [3] Information processing systems - Open Systems 562 Interconnection - Specification of Abstract Syntax 563 Notation One (ASN.1), International Organization for 564 Standardization. International Standard 8824, (December, 565 1987). 567 [4] Information processing systems - Open Systems 568 Interconnection - Specification of Basic Encoding Rules 569 for Abstract Notation One (ASN.1), International 570 Organization for Standardization. International Standard 571 8825, (December, 1987). 573 [5] Rose, M., and K. McCloghrie, Editors, Concise MIB 574 Definitions, RFC 1212, Performance Systems International, 575 Hughes LAN Systems, March 1991. 577 [6] Rose, M., Editor, A Convention for Defining Traps for use 578 with the SNMP, RFC 1215, Performance Systems 579 International, March 1991. 581 [7] K. McCloghrie, Extensions to the Generic-Interface MIB, 582 RFC1229, Hughes LAN Systems, May 1991. 584 [8] W. Simpson, The Point-to-Point Protocol for the 585 Transmission of Multi-protocol Datagrams over Point-to- 586 Point Links, RFC 1331, May 1992. 588 [9] G. McGregor, The PPP Internet Protocol Control Protocol, 589 RFC 1332, Merit, May 1992. 591 [10] F. Baker, Point-to-Point Protocol Extensions for 592 Bridging, RFC1220, ACC, April 1991. 594 [11] B. Lloyd, and Simpson, W., PPP Authentication Protocols 595 RFC1334, October 1992. 597 [12] W. Simpson, PPP Link Quality Monitoring, RFC 1333, May 598 1992. 600 Table of Contents 602 Status of this Memo .................................... 1 603 1 Abstract .............................................. 2 604 2 The Network Management Framework ...................... 3 605 3 Objects ............................................... 4 606 3.1 Format of Definitions ............................... 4 607 4 Overview .............................................. 5 608 4.1 Object Selection Criteria ........................... 5 609 4.2 Structure of the PPP ................................ 5 610 4.3 MIB Groups .......................................... 6 611 5 Definitions ........................................... 8 612 6 Acknowledgements ...................................... 16 613 7 Security Considerations ............................... 17 614 8 References ............................................ 19