idnits 2.17.1 draft-ietf-ipsec-flowmon-mib-tc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 23 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 Mar 2003) is 7710 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: 'RFC2119' is mentioned on line 95, but not defined == Unused Reference: 'IPDOI' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'SECARCH' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'IKE' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'ISAKMP' is defined on line 442, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2407 (ref. 'IPDOI') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. 'SECARCH') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 2271 (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (Obsoleted by RFC 2575) Summary: 20 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Madson, Cisco Systems Inc. 2 IPsec Working Group L. Temoshenko, Cisco Systems. 3 INTERNET-DRAFT: C. Pellecuru, Cisco Systems. 4 Expires in six months B. Harrison, Tivoli Systems. 5 S. Ramakrishnan, Cisco Systems. 6 17 Mar 2003 8 IPsec Flow Monitoring MIB Textual Conventions 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 This document is a submission to the IETF Internet Protocol Security 17 Working Group. Comments are solicited and should be addressed to the 18 working group mailing list (ipsec@lists.tislabs.com) or to the 19 editor(s). 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To learn the current status of any Internet-Draft, please check the 38 "id- abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 40 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 Distribution of this memo is unlimited. 45 Copyright Notice 47 Copyright (C) The Internet Society (2001-03). All Rights Reserved. 49 Abstract 50 This document describes the SMI textual coventions required to 51 support the definition of IPsec MIBs. It is necessary to separate 52 the definition of the textual conventions into a separate document 53 due to their dependence on IANA assigned numbers for transforms 54 and Diffie-Hellman groups supported by IPsec protocol. 56 Table of Contents 58 1. Introduction ..............................................3 59 1.1 Overview ..................................................3 60 1.2 The SNMPv2 Network Management Framework ...................3 61 2. MIB Definitions ...........................................4 62 3. Intellectual Property .....................................9 63 4. Acknowledgements .........................................10 64 5. Security Considerations...................................10 65 6. IANA Considerations.......................................10 66 7. Revision History .........................................10 67 8. References ...............................................10 68 9. Editors' Addresses .......................................12 69 11. Expiration ...............................................13 70 12. Full Copyright Statement .................................13 72 1. Introduction 74 1.1. Overview 76 To support the management needs of IPsec-based networks, we have 77 defined the IPsec Flow Monitor MIB (module IPSEC-FLOW-MONITOR-MIB). 78 The MIB defines a number of objects with enumeration syntax which 79 refer to the numbers assigned by IANA to denote specific elements 80 (e.g.: transforms and Diffie-Hellman groups). 82 The IANA assigned numbers for ISAKMP and IPsec would continue to 83 evolve as new transforms and Diffie-Hellman groups of standardized. 84 To insulate the definition of the MIB from these changes, it is 85 necessary to define the textual conventions for various types of 86 MIB elements in a separate document. 88 The purpose of this draft is to define these textual conventions. 90 Sections 3, 4, 5, 6, 7, 8, 9, 10 and 11 are administrative in nature. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 1.2. The SNMPv2 Network Management Framework 98 The SNMP Management Framework presently consists of five major 99 components: 101 1) An overall architecture, described in RFC 2271 [2271]. 103 2) Mechanisms for describing and naming objects and events for the 104 purpose of management. The first version of this Structure of 105 Management Information (SMI) is called SMIv1 and described in RFC 106 1155 [1155], RFC 1212 [1212] and RFC 1215 [1215]. The second 107 version, called SMIv2, is described in RFC 1902 [1902],RFC 1903 108 [1903] and RFC 1904 [1904]. 110 3) Message protocols for transferring management information. The 111 first version of the SNMP message protocol is called SNMPv1 and 112 described in RFC 1157 [1157]. A second version of the SNMP message 113 protocol, which is not an Internet standards track protocol, is 114 called SNMPv2c and described in RFC 1901 [1901] and RFC 1906 115 [1906]. The third version of the message protocol is called 116 SNMPv3 and described in RFC 1906 [1906], RFC 2272 [2272] and RFC 117 2274 [2274]. 119 4) Protocol operations for accessing management information. The 120 first set of protocol operations and associated PDU formats is 121 described in RFC 1157 [1157]. A second set of protocol operations 122 and associated PDU formats is described in RFC 1905 [1905]. 124 5) A set of fundamental applications described in RFC 2273 [2273] and 125 the view-based access control mechanism described in RFC 2275 126 [2275]. 128 2. MIB Definitions 130 IPSEC-FLOW-MIB-TC DEFINITIONS ::= BEGIN 132 IMPORTS 133 experimental, 134 MODULE-IDENTITY FROM SNMPv2-SMI 135 -- mib-2 FROM RFC1213-MIB 136 TEXTUAL-CONVENTION FROM SNMPv2-TC; 138 ipsecFlowMibTC MODULE-IDENTITY 139 LAST-UPDATED "200302171158Z" 140 ORGANIZATION "Tivoli Systems and Cisco Systems" 141 CONTACT-INFO 142 "Tivoli Systems 143 Research Triangle Park, NC 145 Cisco Systems 146 170 W Tasman Drive 147 San Jose, CA 95134 148 USA 150 Tel: +1 800 553-NETS 151 E-mail: cs-ipsecmib@external.cisco.com 152 bret_harrison@tivoli.com" 154 DESCRIPTION "This MIB module defines the textual conventions 155 used in the IPsec Flow Monitoring MIB. This includes 156 Internet DOI numbers defined in RFC 2407, ISAKMP numbers 157 defined in RFC 2408, and IKE numbers defined in RFC 2409. 159 Revision control of this document after publication 160 will be under the authority of the IANA." 162 -- Placeholder anchor 163 ::= { experimental 170 } 165 -- +++++++++++++++++++++++++++++++++++++++++++++++++++ 166 -- Standard Textual Conventions 167 -- +++++++++++++++++++++++++++++++++++++++++++++++++++ 169 ControlProtocol ::= TEXTUAL-CONVENTION 170 DISPLAY-HINT "d" 171 STATUS current 172 DESCRIPTION 173 "The protocol used for keying and control. The value of 174 cp_none indicate manual administration of IPsec tunnels. 175 This enumeration will be expanded as new keying protocols 176 are standardized." 178 SYNTAX INTEGER { 179 reserved(0), 180 cpNone(1), 181 cpIkev1(2), 182 cpIkev2(3), 183 cpKink(4), 184 cpOther(5) 185 } 187 Phase1PeerIdentityType ::= TEXTUAL-CONVENTION 188 DISPLAY-HINT "d" 189 STATUS current 190 DESCRIPTION 191 "The type of IPsec Phase-1 peer identity. 192 The peer may be identified by one of the 193 ID types defined in IPSEC DOI. 195 id_dn represent the binary DER encoding of the 196 identity." 198 SYNTAX INTEGER { 199 reserved(0), 200 idIpv4Addr(1), 201 idFqdn(2), 202 idDn(3), 203 idIpv6Addr(4), 204 idUserFqdn(5), 205 idIpv4AddrSubnet(6), 206 idIpv6AddrSubnet(7), 207 idIpv4AddrRange(8), 208 idIpv6AddrRange(9), 209 idDerAsn1Gn(10), 210 idKeyId(11) 212 } 214 IkeNegoMode ::= TEXTUAL-CONVENTION 215 DISPLAY-HINT "d" 216 STATUS current 217 DESCRIPTION 218 "The IPsec Phase-1 IKE negotiation mode." 219 SYNTAX INTEGER { 220 reserved(0), 221 main(1), 222 aggressive(2) 223 } 225 IkeHashAlgo ::= TEXTUAL-CONVENTION 226 DISPLAY-HINT "d" 227 STATUS current 228 DESCRIPTION 229 "The hash algorithm used in IPsec Phase-1 230 IKE negotiations." 231 SYNTAX INTEGER { 232 reserved(0), 233 md5(1), 234 sha(2), 235 tiger(3), 236 sha256(4), 237 sha384(5), 238 sha512(6) 239 } 241 IkeAuthMethod ::= TEXTUAL-CONVENTION 242 DISPLAY-HINT "d" 243 STATUS current 244 DESCRIPTION 245 "The authentication method used in IPsec Phase-1 IKE 246 negotiations." 247 SYNTAX INTEGER { 248 reserved(0), 249 preSharedKey(1), 250 dssSignature(2), 251 rsaSignature(3), 252 rsaEncryption(4), 253 revRsaEncryption(5), 254 elGamalEncryption(6), 255 revElGamalEncryption(7), 256 ecsdaSignature(8), 257 gssApiV1(9), 258 gssApiV2(10) 260 } 262 DiffHellmanGrp ::= TEXTUAL-CONVENTION 263 DISPLAY-HINT "d" 264 STATUS current 265 DESCRIPTION 266 "The Diffie Hellman Group used in negotiations. 267 reserved -- reserved groups 268 modp768 -- 768-bit MODP 269 modp1024 -- 1024-bit MODP 270 modp1536 -- 1536-bit MODP group 271 ec2nGP155 -- EC2N group on GP[2^155] 272 ec2nGP185 -- EC2N group on GP[2^185] 273 ec2nGF163 -- EC2N group over GF[2^163] 274 ec2nGF283 -- EC2N group over GF[2^283] 275 ec2nGF409 -- EC2N group over GF[2^409] 276 ec2nGF571 -- EC2N group over GF[2^571] 277 " 278 SYNTAX INTEGER { 279 reserved(0), 280 modp768(1), 281 modp1024(2), 282 ec2nGP155(3), 283 ec2nGP185(4), 284 modp1536(5), -- 1536-bit MODP group 285 ec2nGF163(6), 286 ec2nGF283(8), 287 ec2nGF409(10), 288 ec2nGF571(12) 289 } 291 EncapMode ::= TEXTUAL-CONVENTION 292 DISPLAY-HINT "d" 293 STATUS current 294 DESCRIPTION 295 "The encapsulation mode used by an IPsec Phase-2 296 Tunnel." 297 SYNTAX INTEGER{ 298 reserved(0), 299 tunnel(1), 300 transport(2) 301 } 303 EncryptAlgo ::= TEXTUAL-CONVENTION 304 DISPLAY-HINT "d" 305 STATUS current 306 DESCRIPTION 307 "The encryption algorithm used in negotiations." 308 SYNTAX INTEGER { 309 reserved(0), 310 espDes(1), 311 esp3des(2), 312 espRc5(3), 313 espIdea(4), 314 espCast(5), 315 espBlowfish(6), 316 esp3idea(7), 317 espRc4(8), 318 espNull(9), 319 espAes(10) 320 } 322 Spi ::= TEXTUAL-CONVENTION 323 DISPLAY-HINT "x" 324 STATUS current 325 DESCRIPTION 326 "The type of the SPI associated with IPsec Phase-2 security 327 associations." 328 SYNTAX INTEGER (256..4294967295) 330 AuthAlgo ::= TEXTUAL-CONVENTION 331 DISPLAY-HINT "d" 332 STATUS current 333 DESCRIPTION 334 "The authentication algorithm used by a 335 security association of an IPsec Phase-2 Tunnel." 336 SYNTAX INTEGER{ 337 reserved(0), 338 hmacMd5(2), 339 hmacSha(3), 340 desMac(4), 341 hmacSha256(5), 342 hmacSha384(6), 343 hmacSha512(7), 344 ripemd(8) 345 } 347 CompAlgo ::= TEXTUAL-CONVENTION 348 DISPLAY-HINT "d" 349 STATUS current 350 DESCRIPTION 351 "The compression algorithm used by a 352 security association of an IPsec Phase-2 Tunnel." 353 SYNTAX INTEGER{ 354 reserved(0), 355 compOui(1), 356 compDeflate(2), 357 compLzs(3), 358 compLzjh(4) 359 } 361 EndPtType ::= TEXTUAL-CONVENTION 362 DISPLAY-HINT "d" 363 STATUS current 364 DESCRIPTION 365 "The type of identity use to specify an IPsec End Point." 366 SYNTAX INTEGER { 367 reserved(0), 368 idIpv4Addr(1), 369 idFqdn(2), 370 idUserFqdn(3), 371 idIpv4AddrSubnet(4), 372 idIpv6Addr(5), 373 idIpv6AddrSubnet(6), 374 idIpv4AddrRange(7), 375 idIpv6AddrRange(8), 376 idDerAsn1Dn(9), 377 idDerAsn1Gn(10), 378 idKeyId(11) 379 } 380 END 382 3. Intellectual Property 384 The IETF takes no position regarding the validity or scope of any 385 intellectual property or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; neither does it represent that it 389 has made any effort to identify any such rights. Information on the 390 IETF's procedures with respect to rights in standards-track and 391 standards-related documentation can be found in BCP-11. Copies of 392 claims of rights made available for publication and any assurances of 393 licenses to be made available, or the result of an attempt made to 394 obtain a general license or permission for the use of such 395 proprietary rights by implementors or users of this specification can 396 be obtained from the IETF Secretariat. 398 The IETF invites any interested party to bring to its attention any 399 copyrights, patents or patent applications, or other proprietary 400 rights which may cover technology that may be required to practice 401 this standard. Please address the information to the IETF Executive 402 Director. 404 4. Acknowledgements 406 The editors would like to thank: Ajay Dankar, Jamal Mohamed, Mayank 407 Jain, Roy Pereira, David McGrew and Lauren Heintz. 409 5. Security Considerations 411 Since this MIB defines only textual conventions, there are no 412 security considerations. Security considerations exist only when 413 managed objects are defined with these textual conventions. 415 6. IANA Considerations 417 This document is the MIB definitions corresponding to a group of 418 assigned numbers which are maintained by the IANA. The IANA will 419 maintain the MIB in this document as they make new assignments. 421 This MIB will be maintained in the same manner as the IANAifType-MIB. 423 7. Revision History 425 This section will be removed before publication. 427 Mar 03, 2003. Initial release as draft-ietf-ipsec-mib-tc-00.txt 428 by separating out the definitions from 429 draft-ietf-ipsec-flow-monitoring-mib-01.txt. 431 8. References 433 [IPDOI] Piper, D., "The Internet IP Security Domain of 434 Interpretation for ISAKMP", RFC2407, November 1998 436 [SECARCH] Kent, S., Atkinson, R., "Security Architecture for the 437 Internet Protocol", RFC2401, November 1998 439 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 440 RFC2409, November 1998 442 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 443 "Internet Security Association and Key Management Protocol 444 (ISAKMP)", RFC2408, November 1998 446 [1902] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 447 "Structure of Management Information for version 2 of the 448 Simple Network Management Protocol (SNMPv2)", RFC 1902, 449 January 1996. 451 [2271] Harrington, D., Presuhn, R., and B. Wijnen, "An 452 Architecture for Describing SNMP Management Frameworks", 453 RFC 2271, January 1998 455 [1155] Rose, M., and K. McCloghrie, "Structure and Identification 456 of Management Information for TCP/IP-based Internets", RFC 457 1155, May 1990 459 [1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 460 1212, March 1991 462 [1215] M. Rose, "A Convention for Defining Traps for use with the 463 SNMP", RFC 1215, March 1991 465 [1903] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 466 and S. Waldbusser, "Textual Conventions for Version 2 of 467 the Simple Network Management Protocol (SNMPv2)", RFC 1903, 468 January 1996. 470 [1904] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 471 and S. Waldbusser, "Conformance Statements for Version 2 of 472 the Simple Network Management Protocol (SNMPv2)", RFC 1904, 473 January 1996. 475 [1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 476 Network Management Protocol", RFC 1157, May 1990. 478 [1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 479 and S. Waldbusser, "Introduction to Community-based 480 SNMPv2", RFC 1901, January 1996. 482 [1906] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 483 and S. Waldbusser, "Transport Mappings for Version 2 of the 484 Simple Network Management Protocol (SNMPv2)", RFC 1906, 485 January 1996. 487 [2272] Case, J., Harrington D., Presuhn R., and B. Wijnen, 488 "Message Processing and Dispatching for the Simple Network 489 Management Protocol (SNMP)", RFC 2272, January 1998. 491 [2274] Blumenthal, U., and B. Wijnen, "User-based Security Model 492 (USM) for version 3 of the Simple Network Management 493 Protocol (SNMPv3)", RFC 2274, January 1998. 495 [1905] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 496 and S. Waldbusser, "Protocol Operations for Version 2 of 497 the Simple Network Management Protocol (SNMPv2)", RFC 1905, 498 January 1996. 500 [2273] Levi, D., Meyer, P., and B. Stewart, MPv3 Applications", 501 RFC 2273, SNMP Research, Inc., Secure Computing 502 Corporation, Cisco Systems, January 1998. 504 [2275] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 505 Access Control Model (VACM) for the Simple Network 506 Management Protocol (SNMP)", RFC 2275, January 1998. 508 9. Editor's Addresses 510 Cheryl Madson 511 Cisco Systems 512 170 W Tasman Drive 513 San Jose, Ca 95134 514 Phone: +1 (408) 527 2817 515 EMail: cmadson@cisco.com 517 Leo Temoshenko 518 Cisco Systems 519 170 W Tasman Drive 520 San Jose, Ca 95134 521 USA 522 Phone: +1 (919) 392 8381 523 EMail: leot@cisco.com 525 Chinna Narasimha Reddy Pellacuru 526 Cisco Systems 527 170 W Tasman Drive 528 San Jose, Ca 95134 529 USA 530 Phone: +1 (408) 527 3109 531 EMail: pcn@cisco.com 533 Bret Harrison 534 Tivoli Systems Inc. 535 3901 S. Miami Blvd 536 Durham, NC. 27703 537 Phone: +1 (919) 224-1000 538 EMail: bret_harrison@tivoli.com 540 S Ramakrishnan 541 Cisco Systems 542 170 W Tasman Drive 543 San Jose, Ca 95134 544 USA 545 Phone: +1 (408) 527 7309 546 EMail: rks@cisco.com 548 10. Expiration 550 This draft expires Sep 17, 2003. 552 11. Full Copyright Statement 554 Copyright (C) The Internet Society (2001). All Rights Reserved. 555 This document and translations of it may be copied and furnished to 556 others, and derivative works that comment on or otherwise explain it 557 or assist in its implementation may be prepared, copied, published 558 and distributed, in whole or in part, without restriction of any 559 kind, provided that the above copyright notice and this paragraph 560 are included on all such copies and derivative works. However, this 561 document itself may not be modified in any way, such as by removing 562 the copyright notice or references to the Internet Society or other 563 Internet organizations, except as needed for the purpose of 564 developing Internet standards in which case the procedures for 565 copyrights defined in the Internet Standards process must be 566 followed, or as required to translate it into languages other than 567 English. 569 The limited permissions granted above are perpetual and will not be 570 revoked by the Internet Society or its successors or assigns. 572 This document and the information contained herein is provided on an 573 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 574 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 575 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 576 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 577 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.