idnits 2.17.1 draft-garcia-martinez-sendmib-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (September 11, 2012) is 4244 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission A. Garcia-Martinez 3 Internet-Draft M. Bagnulo 4 Intended status: Standards Track UC3M 5 Expires: March 15, 2013 September 11, 2012 7 Management Information Base for the SEcure Neighbor Discovery (SEND) 8 protocol 9 draft-garcia-martinez-sendmib-05 11 Abstract 13 This memo defines a portion of the Management Information Base (MIB) 14 for managing the SEND (SEcure Neighbor Discovery) Protocol. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on March 15, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. The Internet-Standard Management Framework . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 39 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 40 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 62 1. The Internet-Standard Management Framework 64 For a detailed overview of the documents that describe the current 65 Internet-Standard Management Framework, please refer to section 7 of 66 RFC 3410 [RFC3410]. Managed objects are accessed via a virtual 67 information store, termed the Management Information Base or MIB. 68 MIB objects are generally accessed through the Simple Network 69 Management Protocol (SNMP). Objects in the MIB are defined using the 70 mechanisms defined in the Structure of Management Information (SMI). 71 This memo specifies a MIB module that is compliant to the SMIv2, 72 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 73 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 75 2. Overview 77 This document defines SEND-MIB, the portion of the Management 78 Information Base (MIB) to be used for managing the SEcure Neighbor 79 Discovery (SEND) [RFC3971] protocol. SEND specifies security 80 mechanisms to protect the Neighbor Discovery (ND) Protocol [RFC4861], 81 [RFC4862], so it is IPv6-specific. To protect the ND protocol, it 82 relies on the following elements 83 o Certification Path, anchored on trusted parties, which can be used 84 to certify the authority of the routers. A Certification Path can 85 be exchanged among routers and hosts by means of two ICMP 86 messages, the Certification Path Solicitation message and the 87 Certification Path Advertisement message. 88 o Cryptographically Generated Address (CGA) [RFC3972], an IPv6 89 address which can be used to prove address ownership 90 o RSA Signature option, which protects ND messages by using keying 91 material related to a Certification Path or a CGA. 93 SEND-MIB provides means to monitor and configure most of the elements 94 related with SEND operation in hosts. In particular, it allows 95 managing: 96 o Authority attestation and verification. The following objects are 97 related to authority verification management in the receiver: 98 * sendCgaVerificationMinbits and sendCgaVerificationMaxbits 99 objects specify respectively the minimum and maximum number of 100 bits that a key of a received CGA must have to be usable by 101 SEND. 102 * For each ND message type, a specific sendRsaVerificationMethod 103 object indicates the method through which the authority of the 104 remote node is determined (Certification Path and/or CGA). 105 o Timestamp verification. The parameters that control the 106 verification of the Timestamp option to provide anti-replay 107 protection for unsolicited advertisements and redirects are 108 managed through the discrete objects sendTimestampDelta, 109 sendTimestampFuzz and sendTimestampDrift. 110 o Cryptographic information repository. Two tables store, after 111 proper validation, the cryptographic information required by SEND: 112 * The sendTrustAnchorTable stores the trust anchors configured in 113 the node. Read-create access to the objects of this table 114 enables the use of network management protocols to create them. 115 * The sendCertTable stores the certificates received in 116 Certification Path Advertisement messages. This information is 117 stored as a linked list in order to reflect the dependencies of 118 the certificates to a trust anchor or to other certificates of 119 a Certification Path. 120 * The sendCgaLocalTable indicates which of the CGA addresses 121 available in the node (shown in a non-SEND specific table 122 defined in the CGA-MIB [I-D.garcia-martinez-cgamib]) can be 123 used for SEND operation. 124 o Compatibility with non-SEND devices. The sendAcceptUnsecured 125 object manages the acceptance of unsecured ND messages in a 126 system-wide basis. If unsecured ND messages are accepted, it is 127 useful to know which of the information received is secured. To 128 do so, three tables augment existing tables containing ND 129 information [RFC4293] to indicate whether the information related 130 to an address prefix, a default router, or an association between 131 an IP address and a physical address has been secured by SEND. 132 These tables are sendIpAddressPrefixSecuredTable, 133 sendIpDefaultRouterSecuredTable and 134 sendIpNetToPhysicalSecuredTable. Finally, 135 sendIgnoreUnsecuredDadFirstTentative controls DAD operation in 136 links shared with non-SEND devices. 137 o SEND statistics. System-wide objects show statistics accounting 138 for secured and unsecured messages, and messages with validation 139 errors, for both ND and Certification Path Advertisement messages. 141 Note that SEND-MIB depends on the implementation of the CGA-MIB 142 [I-D.garcia-martinez-cgamib] for some of its objects, so it requires 143 the CGA-MIB to exist in the managed system in which SEND-MIB is 144 implemented. SEND-MIB also complements the information of IP-MIB 145 tables[RFC4293]. 147 SEND-MIB does not aim to manage SEND operation in routers, except for 148 configurations common to both routers and hosts. The approach taken 149 in this document is similar to that of IP-MIB [RFC4293], which does 150 not provide objects to manage the generation of Router Advertisement 151 messages, and in particular it does not provide means to manage 152 prefix options. In a similar way, SEND-MIB does not provide means to 153 manage the generation of Certification Path Advertisement, the 154 security configuration of Router Advertisement messages, or the 155 configuration of certification material in the routers. These 156 configuration capabilities are left for future specifications. 158 3. Conventions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 4. Definitions 166 SEND-MIB DEFINITIONS ::= BEGIN 168 IMPORTS 170 MODULE-IDENTITY, OBJECT-TYPE, 171 Unsigned32, mib-2, TimeTicks, 172 Integer32, Counter32 FROM SNMPv2-SMI 173 TEXTUAL-CONVENTION, TestAndIncr, 174 RowStatus, StorageType, RowPointer FROM SNMPv2-TC 175 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 176 ipAddressPrefixEntry, ipDefaultRouterEntry, 177 ipNetToPhysicalEntry FROM IP-MIB 178 cgaLocalEntry FROM CGA-MIB; 180 sendMIB MODULE-IDENTITY 181 LAST-UPDATED "201209100000Z" 182 ORGANIZATION "IETF" 183 CONTACT-INFO 184 "Editor: 186 Alberto Garcia-Martinez 187 U. Carlos III de Madrid 188 Avenida Universidad, 30 189 Leganes, Madrid 28911 190 Spain 191 Email: alberto.garcia@uc3m.es" 193 DESCRIPTION 194 "The MIB module for managing the SEND protocol. 196 Copyright (c) 2012 IETF Trust and the persons identified 197 as the document authors. 198 All rights reserved. This version of this MIB module is 199 part of RFC yyyy; see the RFC itself for full legal 200 notices." 202 -- RFC Ed.: replace yyyy with actual RFC number & remove this 203 -- note 205 REVISION "201209100000Z" 206 DESCRIPTION 207 "Initial version, published as RFC yyyy." 209 -- RFC Ed.: replace yyyy with actual RFC number & remove 210 -- this note 212 ::= { mib-2 XXX } 214 -- RFC Ed.: replace XXX with actual number assigned by IANA & 215 -- remove this note 217 -- 218 -- The textual conventions we define and use in this MIB. 219 -- 221 SendRsaVerificationMethod ::= TEXTUAL-CONVENTION 222 STATUS current 223 DESCRIPTION 224 "Acceptable authorization method to validate the RSA 225 signature option of a received NDP message. 226 In the trustAnchor(1) method, the option is verified 227 according to the keying information obtained from a 228 Certification Path rooted in a trust anchor known by both 229 sender and receiver. The sender may claim additional 230 authorization through the use of CGAs, but in this case it 231 is neither required nor verified. 232 In the cga(2) method, the CGA property of the sender's 233 address is verified. The sender may claim additional 234 authority through a trust anchor, but in this case it is 235 neither required nor verified. 236 In the trustAnchorAndCga(3) method, both the trust anchor 237 and the CGA verification are required. 238 Finally, with the trustAnchorOrCga(4) method, either the 239 trust anchor or the CGA verification is required." 240 REFERENCE "RFC 3971 : section 5.2.3" 241 SYNTAX INTEGER { 242 trustAnchor(1), 243 cga(2), 244 trustAnchorAndCga(3), 245 trustAnchorOrCga(4) 246 } 248 SendCertificateIndex ::= TEXTUAL-CONVENTION 249 DISPLAY-HINT "d" 250 STATUS current 251 DESCRIPTION 252 "A unique value, greater than zero, for each certificate 253 within a table. 254 The management station MUST select a pseudo-random number, 255 so that this value could be used as an index. If this 256 index was already in use, SO an 'inconsistentValue' was 257 returned in response to the management protocol set 258 operation, the management station SHOULD select a new 259 pseudo-random number and retry the operation. 260 The value for each certificate must remain constant at 261 least from one re-initialization of the entity's network 262 management system to the next re-initialization." 263 SYNTAX Unsigned32 (1..4294967295) 265 SendX509ASN1DEREncodedRouterAuthCert ::= TEXTUAL-CONVENTION 266 DISPLAY-HINT "4096x" 267 STATUS current 268 DESCRIPTION 269 "A Router Authorization Certificate, i.e. an X.509v3 270 certificate as defined in [RFC5280]. It SHOULD contain at 271 least one instance of the X.509 extension for IP addresses 272 as defined in [RFC3279]. The certificate is encoded as an 273 ASN.1 DER [CCITT.X690.2002] object." 274 REFERENCE "RFC 3971: 6.3.1, RFC 5280, ITU-T Recommendation X.690" 275 SYNTAX OCTET STRING (SIZE (0..4096)) 277 SendSecurityStatus ::= TEXTUAL-CONVENTION 278 STATUS current 279 DESCRIPTION 280 "A value that specifies whether the information associated 281 to the entry in which an object of this type is defined 282 has been secured by SEND or not." 283 SYNTAX INTEGER { 284 sendSecured(1), 285 sendNotSecured(2) 286 } 288 send OBJECT IDENTIFIER ::= { sendMIB 1 } 290 -- 291 -- Operational status of SEND 292 -- 294 -- 295 -- Authority verification 296 -- 298 sendCgaVerificationMinbits OBJECT-TYPE 299 SYNTAX Integer32 (384 .. 2147483647) 300 MAX-ACCESS read-write 301 STATUS current 302 DESCRIPTION 303 "Minimum acceptable key length for public keys used in the 304 verification of remote CGA. The minimum RSA key length 305 required for a CGA is 384 bits [RFC3972]." 306 REFERENCE "RFC 3971 : section 5.1.3" 307 DEFVAL { 1024 } 308 ::= { send 1 } 310 sendCgaVerificationMaxbits OBJECT-TYPE 311 SYNTAX Integer32 (384 .. 2147483647) 312 MAX-ACCESS read-write 313 STATUS current 314 DESCRIPTION 315 "Maximum acceptable key length for public keys used in the 316 verification of remote CGA. The value of this object can 317 limit the amount of computation needed when verifying SEND 318 messages. 319 When set to 2147483647, it indicates that the node does 320 not check for any maximum key length. 321 This value MUST be equal or greater than 322 sendCgaVerificationMinbits, and SHOULD be at least 2048 323 bits [RFC3971]." 324 REFERENCE "RFC 3971 : section 5.1.3" 325 ::= { send 2 } 327 -- 328 -- objects related with the authorization method used for verifying 329 -- RSA signature options for each NDP message type 330 -- 332 sendRsaVerificationMethodNS OBJECT-TYPE 333 SYNTAX SendRsaVerificationMethod 334 MAX-ACCESS read-write 335 STATUS current 336 DESCRIPTION 337 "This object indicates the method through which the 338 authority of the remote node is determined in the Neighbor 339 Solicitation messages received. 340 It affects all interfaces of the node." 341 REFERENCE "RFC 3971 : section 5.2.3" 342 ::= { send 3 } 344 sendRsaVerificationMethodNA OBJECT-TYPE 345 SYNTAX SendRsaVerificationMethod 346 MAX-ACCESS read-write 347 STATUS current 348 DESCRIPTION 349 "This object indicates the method through which the 350 authority of the remote node is determined in the Neighbor 351 Advertisement messages received. 352 It affects all interfaces of the node." 353 REFERENCE "RFC 3971 : section 5.2.3" 354 ::= { send 4 } 356 sendRsaVerificationMethodRS OBJECT-TYPE 357 SYNTAX SendRsaVerificationMethod 358 MAX-ACCESS read-write 359 STATUS current 360 DESCRIPTION 361 "This object indicates the method through which the 362 authority of the remote node is determined in the Router 363 Solicitation messages received. 364 It affects all interfaces of the node." 365 REFERENCE "RFC 3971 : section 5.2.3" 366 ::= { send 5 } 368 sendRsaVerificationMethodRA OBJECT-TYPE 369 SYNTAX SendRsaVerificationMethod 370 MAX-ACCESS read-write 371 STATUS current 372 DESCRIPTION 373 "This object indicates the method through which the 374 authority of the remote node is determined in the Router 375 Advertisement messages received. 376 It affects all interfaces of the node." 377 REFERENCE "RFC 3971 : section 5.2.3" 378 ::= { send 6 } 380 sendRsaVerificationMethodRedirect OBJECT-TYPE 381 SYNTAX SendRsaVerificationMethod 382 MAX-ACCESS read-write 383 STATUS current 384 DESCRIPTION 385 "This object indicates the method through which the 386 authority of the remote node is determined in the Redirect 387 messages received. 389 It affects all interfaces of the node." 390 REFERENCE "RFC 3971 : section 5.2.3" 391 ::= { send 7 } 393 -- 394 -- objects associated to timestamp verification management 395 -- 397 sendTimestampDelta OBJECT-TYPE 398 SYNTAX Unsigned32 399 UNITS "seconds" 400 MAX-ACCESS read-write 401 STATUS current 402 DESCRIPTION 403 "The maximum difference in absolute value between the 404 timestamp included in a Neighbor Discovery message and the 405 reception time of the message, measured in seconds with 406 the local clock. 407 It corresponds to the variable TIMESTAMP_DELTA defined in 408 [RFC3971]." 409 REFERENCE "RFC 3971 : section 5.3.4.2, RFC 3971 : section 10.2" 410 DEFVAL { 300 } 411 ::= { send 8 } 413 sendTimestampFuzz OBJECT-TYPE 414 SYNTAX TimeTicks 415 UNITS "milliseconds" 416 MAX-ACCESS read-write 417 STATUS current 418 DESCRIPTION 419 "Time in milliseconds, used to check upon the reception of 420 a new SEND message if the following inequality holds: 421 TSnew + sendTimestampFuzz > TSlast + (RDnew - RDlast) x (1 422 - sendTimestamDrift) - sendTimestampFuzz 423 With 424 TSnew: timestamp of the newly received SEND message 425 TSlast: timestamp of the previously received SEND message 426 RDnew: reception time of the newly received SEND message 427 RDlast: reception time of the previously received SEND 428 message. 429 This object corresponds to the variable TIMESTAMP_FUZZ 430 defined in [RFC3971]." 431 REFERENCE "RFC 3971 : 5.3.4.2, RFC 3971 : section 10.2" 432 DEFVAL { 100 } 433 ::= { send 9 } 435 sendTimestampDrift OBJECT-TYPE 436 SYNTAX Integer32 (0..10000) 437 UNITS "0.01 Percentage" 438 MAX-ACCESS read-write 439 STATUS current 440 DESCRIPTION 441 "The maximum clock drift allowed when validating the 442 timestamp of a received Neighbor Discovery message, 443 measured in parts per 10000 (or 0.01 percentage). It 444 corresponds to the variable TIMESTAMP_DRIFT defined in 445 [RFC3971]." 446 REFERENCE "RFC 3971 : 5.3.4.2, RFC 3971 : section 10.2" 447 DEFVAL { 100 } 448 ::= { send 10 } 450 -- 451 -- Cryptographic information repository 452 -- 454 -- 455 -- table of trust anchors known by a node 456 -- 458 sendTrustAnchorSpinLock OBJECT-TYPE 459 SYNTAX TestAndIncr 460 MAX-ACCESS read-write 461 STATUS current 462 DESCRIPTION 463 "An advisory lock used to allow cooperating SNMP managers 464 to coordinate their use of the set operation in creating 465 or modifying rows within the sendTrustAnchorTable table. 466 In order to use this lock to coordinate the use of set 467 operations, managers should first retrieve 468 sendTrustAnchorSpinLock. They should then determine the 469 appropriate row to create or modify, selecting a pseudo- 470 random number for the sendTrustAnchorIndex. Finally, they 471 should issue the appropriate set command including the 472 retrieved value of sendTrustAnchorSpinLock. If another 473 manager has altered the table in the meantime, then the 474 value of sendTrustAnchorSpinLock will have changed and the 475 creation will fail as it will be specifying an incorrect 476 value for sendTrustAnchorSpinLock. It is suggested, but 477 not required, that the sendTrustAnchorSpinLock be the 478 first var bind for each set of objects representing a 479 'row' in a PDU." 481 ::= { send 11 } 483 sendTrustAnchorTable OBJECT-TYPE 484 SYNTAX SEQUENCE OF SendTrustAnchorEntry 485 MAX-ACCESS not-accessible 486 STATUS current 487 DESCRIPTION 488 "The list of trust anchors that are used for validating 489 the authority of the Certification Path of a remote node. 490 Entries can be created to configure new anchors. Anchor 491 entries can also be deleted. 492 Note that the removal of entries in this table SHOULD 493 result in the deletion of the certificates belonging to 494 Certification Paths rooted in this anchor. 495 Note that if SEND has been enabled in a host, there SHOULD 496 be at least one anchor." 497 REFERENCE "RFC 3971 : 6.5" 498 ::= { send 12 } 500 sendTrustAnchorEntry OBJECT-TYPE 501 SYNTAX SendTrustAnchorEntry 502 MAX-ACCESS not-accessible 503 STATUS current 504 DESCRIPTION 505 "A trust anchor provided in the form of a self-signed 506 certificate. 507 When the value of the sendTrustAnchorStatus of an entry 508 has been set once to enabled(2), the sendTrustAnchorCert 509 MUST remain unmodified." 510 INDEX { sendTrustAnchorIndex } 511 ::= { sendTrustAnchorTable 1 } 513 SendTrustAnchorEntry ::= SEQUENCE { 514 sendTrustAnchorIndex SendCertificateIndex, 515 sendTrustAnchorCert SendX509ASN1DEREncodedRouterAuthCert, 516 sendTrustAnchorStatus INTEGER, 517 sendTrustAnchorRowStatus RowStatus, 518 sendTrustAnchorStorageType StorageType 519 } 521 sendTrustAnchorIndex OBJECT-TYPE 522 SYNTAX SendCertificateIndex 523 MAX-ACCESS not-accessible 524 STATUS current 525 DESCRIPTION 526 "A unique value, greater than zero, for each trust anchor. 527 The management station MUST select a pseudo-random number 528 to use it as the index. If this index was already in use, 529 so an 'inconsistentValue' was returned in response to the 530 management protocol set operation, the management station 531 SHOULD select a new pseudo-random number and retry the 532 operation. 533 The value of the sendTrustAnchorIndex for each trust 534 anchor MUST remain constant at least from one re- 535 initialization of the entity's network management system 536 to the next re-initialization." 537 ::= { sendTrustAnchorEntry 1 } 539 sendTrustAnchorCert OBJECT-TYPE 540 SYNTAX SendX509ASN1DEREncodedRouterAuthCert 541 MAX-ACCESS read-create 542 STATUS current 543 DESCRIPTION 544 "Variable-length field containing the trust anchor in the 545 form of a self-signed certificate. 546 Upon a set operation, an 'inconsistentValue' error MUST be 547 returned if the value is not a valid DER-encoded ASN.1 548 certificate. 549 This object MUST NOT be modified once the 550 cgaLocalRowStatus object has been set to enabled(2)." 551 ::= { sendTrustAnchorEntry 2 } 553 sendTrustAnchorStatus OBJECT-TYPE 554 SYNTAX INTEGER { 555 disabled(1), 556 enabled(2) } 557 MAX-ACCESS read-create 558 STATUS current 559 DESCRIPTION 560 "This columnar object indicates whether the row can be 561 used as a Trust Anchor in the managed system or not. 562 When set to enabled(1), the administrator requires the 563 trust anchor to be available for validating the authority 564 of Certification Paths. Conversely, when set to 565 disabled(2), the administrator requires the anchor not to 566 be available for validating the authority of Certification 567 Paths." 568 DEFVAL { disabled } 569 ::= { sendTrustAnchorEntry 3 } 571 sendTrustAnchorRowStatus OBJECT-TYPE 572 SYNTAX RowStatus 573 MAX-ACCESS read-create 574 STATUS current 575 DESCRIPTION 576 "The status of this conceptual row. 577 Once set to enabled, the value of sendTrustAnchorCert 578 cannot be changed." 579 ::= { sendTrustAnchorEntry 4 } 581 sendTrustAnchorStorageType OBJECT-TYPE 582 SYNTAX StorageType 583 MAX-ACCESS read-create 584 STATUS current 585 DESCRIPTION 586 "The storage type for this conceptual row. If this object 587 has a value of permanent(4), then no other objects are 588 required to be able to be modified." 589 DEFVAL { volatile } 590 ::= { sendTrustAnchorEntry 5 } 592 -- 593 -- table of the certificates part of a Certification Path 594 -- received from a remote router 595 -- 597 sendCertTable OBJECT-TYPE 598 SYNTAX SEQUENCE OF SendCertEntry 599 MAX-ACCESS not-accessible 600 STATUS current 601 DESCRIPTION 602 "A list of standard Public Key Certificates (PKC, in the 603 sense of [RFC5280]) which can be used by the SEND node. 604 The managed element populates the entries in this table 605 with the information being received from Certification 606 Path Advertisement messages. Only verified certificates, 607 i.e. certificates verified to the trust anchor or to a 608 certificate that has been verified before (i.e. which 609 validly belongs to a Certification Path), are included in 610 the table.Certificates being certified by a trust anchor 611 contain a RowPointer element that points to the parent 612 entry in the sendTrustAnchorTable (note that there MAY be 613 many certificates rooted to the same trust anchor). 614 Certificates being signed by another certificate in the 615 table contain a RowPointer element that points to the 616 parent certificate in this table, to reflect the 617 dependencies of the certificates forming a Certification 618 Path. 619 Entries in this table can be removed as a result of the 620 normal operation of SEND. Additionally, the deletion of 621 an anchor on which a Certification Path is rooted MUST 622 result in the deletion of all the certificates of the 623 Certification Path. 624 In the period since the certificate has been verified to 625 the time at which it is possible to check the information 626 obtained from the Certificate Revocation List, the 627 sendCertStatus object indicates that the certificate is 628 provisional(1). 629 The managed element can delete entries if the periodic 630 Certificate Revocation List check fails (either in the 631 provisional or in the valid states). In this case, all 632 certificates depending on the revoked one MUST be 633 deleted." 634 REFERENCE "RFC 3971 : 6.4.2, RFC 3971 : 6.4.6" 635 ::= { send 13 } 637 sendCertEntry OBJECT-TYPE 638 SYNTAX SendCertEntry 639 MAX-ACCESS not-accessible 640 STATUS current 641 DESCRIPTION 642 "Information related with a particular certificate." 643 INDEX { sendCertIndex } 644 ::= { sendCertTable 1 } 646 SendCertEntry ::= SEQUENCE { 647 sendCertIndex SendCertificateIndex, 648 sendCertCert SendX509ASN1DEREncodedRouterAuthCert, 649 sendCertParentCertificate RowPointer, 650 sendCertStatus INTEGER 651 } 653 sendCertIndex OBJECT-TYPE 654 SYNTAX SendCertificateIndex 655 MAX-ACCESS not-accessible 656 STATUS current 657 DESCRIPTION 658 "A unique value, greater than zero, for each certificate. 659 The management station MUST select a pseudo-random number 660 to use it as index. If this index was already in use, so 661 an 'inconsistentValue' was returned in response to the 662 management protocol set operation, the management station 663 SHOULD select a new pseudo-random number and retry the 664 operation. 665 The value of the sendTrustAnchorIndex for each certificate 666 MUST remain constant at least from one re-initialization 667 of the entity's network management system to the next re- 668 initialization." 670 ::= { sendCertEntry 1 } 672 sendCertCert OBJECT-TYPE 673 SYNTAX SendX509ASN1DEREncodedRouterAuthCert 674 MAX-ACCESS read-only 675 STATUS current 676 DESCRIPTION 677 "Variable-length field containing the certificate 678 information." 679 ::= { sendCertEntry 2 } 681 sendCertParentCertificate OBJECT-TYPE 682 SYNTAX RowPointer 683 MAX-ACCESS read-only 684 STATUS current 685 DESCRIPTION 686 "For the first certificate of a Certification Path, this 687 object points to the row of the sendTrustAnchorTable of 688 the anchor that certifies this certificate. For 689 certificates other than the first of a Certification Path, 690 the object points to the parent certificate entry in this 691 table." 692 ::= { sendCertEntry 3 } 694 sendCertStatus OBJECT-TYPE 695 SYNTAX INTEGER { 696 provisional(1), 697 valid(2) 698 } 699 MAX-ACCESS read-only 700 STATUS current 701 DESCRIPTION 702 "The status of the certificate. 703 A certificate has a sendCertStatus value of 704 provisional(1)if a Certificate Revocation List check has 705 not been performed due to the lack of connection to 706 internet. After validating the certificate in the CRL, 707 sendCertStatus is changed to valid(2). Note that if 708 subsequent checks to the CRL result in invalidation of the 709 certificate, the certificate is removed from the table, so 710 no state is required for this case." 711 REFERENCE "RFC 3971 : section 6.3.1" 712 ::= { sendCertEntry 4 } 714 -- 715 -- CGA addresses configured in this node 716 -- 717 sendCgaLocalTable OBJECT-TYPE 718 SYNTAX SEQUENCE OF SendCgaLocalEntry 719 MAX-ACCESS not-accessible 720 STATUS current 721 DESCRIPTION 722 "A table containing one column which indicates if each 723 entry of CGA-MIB:cgaLocalTable can be used by SEND or not. 724 An entry in the CGA-MIB:cgaLocalTable may not be used by 725 SEND if, for example, it does not comply with the minimum 726 key length specified by SEND. Note that other policies 727 MAY be used to filter out configured CGA for SEND use." 728 REFERENCE "[I-D.garcia-martinez-cgamib]" 729 ::= { send 14 } 731 sendCgaLocalEntry OBJECT-TYPE 732 SYNTAX SendCgaLocalEntry 733 MAX-ACCESS not-accessible 734 STATUS current 735 DESCRIPTION 736 "An entry of the sendCgaLocalTable. 737 This table augments the CGA-MIB:cgaLocalTable, i.e. every 738 entry in this table has a one-to-one correspondence with 739 an entry in the CGA-MIB:cgaLocalTable." 740 AUGMENTS { cgaLocalEntry } 741 ::= { sendCgaLocalTable 1 } 743 SendCgaLocalEntry ::= SEQUENCE { 744 sendCgaLocalStatus INTEGER 745 } 747 sendCgaLocalStatus OBJECT-TYPE 748 SYNTAX INTEGER { 749 validForSend(1), 750 notValidForSend(2) 751 } 752 MAX-ACCESS read-only 753 STATUS current 754 DESCRIPTION 755 "The value of this object indicates if its corresponding 756 entry in CGA-MIB:cgaLocalTable can be used by SEND or not 757 when properly configured as an IP address." 758 ::= { sendCgaLocalEntry 1 } 760 -- 761 -- compatibility with non-SEND devices 762 -- 764 sendAcceptUnsecured OBJECT-TYPE 765 SYNTAX INTEGER { 766 acceptSecuredAndUnsecured(1), 767 acceptOnlySecured(2) 768 } 769 MAX-ACCESS read-write 770 STATUS current 771 DESCRIPTION 772 "This object indicates whether the node accepts or not 773 unsecured messages. When its value is 774 acceptSecuredAndUnsecured(1), both secured and unsecured 775 messages are processed, while when its value is 776 acceptOnlySecured(2) unsecured messages are ignored. 777 The acceptance of unsecured messages is allowed to ease 778 transition from unsecured to secured links." 779 REFERENCE "RFC 3971 : section 8" 780 DEFVAL { acceptOnlySecured } 781 ::= { send 15 } 783 -- 784 -- Compatibility with non-SEND devices: security status of ND related 785 -- information 786 -- 788 -- 789 -- Augmentation of tables of [RFC4293] to indicate whether the 790 -- information included in an entry in the 791 -- IP-MIB:ipAddressPrefixTable, IP-MIB:ipDefaultRouterTable and 792 -- IP-MIB ipNetToPhysicalTable has been secured or not 793 -- 795 -- augmentation of IP-MIB:ipAddressPrefixTable 797 sendIpAddressPrefixSecuredTable OBJECT-TYPE 798 SYNTAX SEQUENCE OF SendIpAddressPrefixSecuredEntry 799 MAX-ACCESS not-accessible 800 STATUS current 801 DESCRIPTION 802 "A table that contains one column indicating if each entry 803 in the IP-MIB:ipAddressPrefixTable is secured or not. An 804 entry in the IP-MIB:ipAddressPrefixTable is secured if the 805 last message of the Router Advertisement message that 806 caused the creation or last update of the entry was 807 secured. An entry in IP-MIB:ipAddressPrefixTable is 808 unsecured otherwise. This table contains one row for 809 every address prefix entry on the node. This table 810 augments the basic address prefix information of the IP- 811 MIB:ipAddressPrefixEntry. 813 If an entry in the ipAddressPrefixTable is deleted, the 814 corresponding entry in the sendIpAddressPrefixSecuredTable 815 MUST be deleted." 816 REFERENCE "RFC 3971: section 8, ipAddressPrefixEntry is defined 817 in the IP-MIB [RFC4293]." 818 ::= { send 16 } 820 sendIpAddressPrefixSecuredEntry OBJECT-TYPE 821 SYNTAX SendIpAddressPrefixSecuredEntry 822 MAX-ACCESS not-accessible 823 STATUS current 824 DESCRIPTION 825 "An entry of the sendIpAddressSecuredTable. Each row is 826 for an address prefix. 827 This table augments the IP-MIB:ipAddressPrefixTable, i.e., 828 every entry in this table has a one-to-one correspondence 829 with an entry in the IP-MIBipAddressPrefixTable." 830 AUGMENTS { ipAddressPrefixEntry } 831 ::= { sendIpAddressPrefixSecuredTable 1 } 833 SendIpAddressPrefixSecuredEntry ::= SEQUENCE { 834 sendIpAddressPrefixSecuredStatus SendSecurityStatus 835 } 837 sendIpAddressPrefixSecuredStatus OBJECT-TYPE 838 SYNTAX SendSecurityStatus 839 MAX-ACCESS read-only 840 STATUS current 841 DESCRIPTION 842 "The value of this object indicates whether its 843 corresponding entry in the IP-MIB:ipAddressPrefixTable is 844 secured (if the last Router Advertisement message that 845 caused the creation or last update of the entry was 846 secured by SEND) or not. 847 If the value of the object sendAcceptUnsecured is set to 848 acceptOnlySecured(2), then the value of this object MUST 849 contain sendSecured(1)." 850 ::= { sendIpAddressPrefixSecuredEntry 1 } 852 -- augmentation of IP-MIB:ipDefaulRouterTable 854 sendIpDefaultRouterSecuredTable OBJECT-TYPE 855 SYNTAX SEQUENCE OF SendIpDefaultRouterSecuredEntry 856 MAX-ACCESS not-accessible 857 STATUS current 858 DESCRIPTION 859 "A table that contains one column indicating whether each 860 entry in the IP-MIB:ipDefaultRouterTable is secured or 861 not. An entry in IP-MIB:ipDefaultRouterTable is secured 862 if the last message of the Router Advertisement message 863 that caused the creation or last update of the entry was 864 secured. An entry in IP-MIB:ipDefaultRouterTable is 865 unsecured otherwise. This table contains one row for 866 every address prefix entry on the node. This table 867 augments the basic address prefix information of the IP- 868 MIB:ipDefaultRouterEntry. 869 If an entry in the ipDefaultRouterTable is deleted, the 870 corresponding entry in the sendIpDefaultRouterSecuredTable 871 MUST be deleted." 873 REFERENCE "RFC 3971 : section 8 874 ipDefaultRouterEntry is defined in the IP-MIB [RFC4293]." 875 ::= { send 17 } 877 sendIpDefaultRouterSecuredEntry OBJECT-TYPE 878 SYNTAX SendIpDefaultRouterSecuredEntry 879 MAX-ACCESS not-accessible 880 STATUS current 881 DESCRIPTION 882 "An entry of the sendIpDefaultRouterSecuredTable. Each 883 row is for a default router. 884 This table augments the IP-MIB:ipDefaultRouterTable, i.e., 885 every entry in this table has a one-to-one correspondence 886 with an entry in the IP-MIB:ipDefaultRouterTable." 887 AUGMENTS { ipDefaultRouterEntry } 888 ::= { sendIpDefaultRouterSecuredTable 1} 890 SendIpDefaultRouterSecuredEntry ::= SEQUENCE { 891 sendIpDefaultRouterSecuredStatus SendSecurityStatus 892 } 894 sendIpDefaultRouterSecuredStatus OBJECT-TYPE 895 SYNTAX SendSecurityStatus 896 MAX-ACCESS read-only 897 STATUS current 898 DESCRIPTION 899 "The value of this object indicates whether its 900 corresponding entry in the IP-MIB:ipDefaultRouterTable is 901 secured (if the last Router Advertisement message that 902 caused the creation or last update of the entry was 903 secured by SEND) or not. 905 If the value of the object sendAcceptUnsecured is set to 906 acceptOnlySecured(2), then the value of this object MUST 907 contain sendSecured(1)." 908 ::= { sendIpDefaultRouterSecuredEntry 1 } 910 -- augmentation of IP-MIB:ipNetToPhysicalTable 912 sendIpNetToPhysicalSecuredTable OBJECT-TYPE 913 SYNTAX SEQUENCE OF SendIpNetToPhysicalSecuredEntry 914 MAX-ACCESS not-accessible 915 STATUS current 916 DESCRIPTION 917 "A table that contains one column indicating if each entry 918 in the IP-MIB:ipNetToPhysicalTable is secured or not. An 919 entry in IP-MIB:ipNetToPhysicalTable is secured if the 920 last ND message that caused the creation or last update of 921 the entry was secured. An entry in IP- 922 MIB:ipNetToPhysicalEntry is unsecured otherwise. This 923 table contains one row for every address prefix entry on 924 the node. This table augments the basic address prefix 925 information of the IP-MIB:ipNetToPhysicalEntry. 926 If an entry in the IP-MIB:ipNetToPhysicalTable is deleted, 927 the corresponding entry in the 928 sendIpNetToPhysicalSecuredTable MUST be deleted." 929 REFERENCE "RFC 3971 : section 8 930 ipNetToPhysicalEntry is defined in the IP-MIB [RFC4293]." 931 ::= { send 18 } 933 sendIpNetToPhysicalSecuredEntry OBJECT-TYPE 934 SYNTAX SendIpNetToPhysicalSecuredEntry 935 MAX-ACCESS not-accessible 936 STATUS current 937 DESCRIPTION 938 "An entry of the sendIpNetToPhysicalSecuredTable. Each 939 row is for a neighbor. 940 This table augments the IP-MIB:ipNetToPhysicalTable, i.e., 941 every entry in this table has a one-to-one correspondence 942 with an entry in the IP-MIB:ipNetToPhysicalTable. 943 If the value of sendIpNetToPhysicalSecuredStatus for an 944 entry is sendSecured(1), and the CGA has been used for 945 validating this information, an entry in CGA- 946 MIB:cgaRemoteTable MUST exist containing the CGA parameter 947 data structure of the CGA of the neighbor node." 948 AUGMENTS { ipNetToPhysicalEntry } 949 ::= { sendIpNetToPhysicalSecuredTable 1 } 951 SendIpNetToPhysicalSecuredEntry ::= SEQUENCE { 952 sendIpNetToPhysicalSecuredStatus SendSecurityStatus 953 } 955 sendIpNetToPhysicalSecuredStatus OBJECT-TYPE 956 SYNTAX SendSecurityStatus 957 MAX-ACCESS read-only 958 STATUS current 959 DESCRIPTION 960 "The value of this object indicates whether its 961 corresponding entry in the IP-MIB:ipNetToPhysicalTable is 962 secured (if the last ND message that caused the creation 963 or last update of the entry was secured by SEND). 964 If the value of the object sendAcceptUnsecured is set to 965 acceptOnlySecured(2), then the value of this object MUST 966 contain sendSecured(1)." 967 ::= { sendIpNetToPhysicalSecuredEntry 1 } 969 sendIgnoreUnsecuredDadFirstTentative OBJECT-TYPE 970 SYNTAX INTEGER { 971 acceptUnsecuredDadFirstTentative(1), 972 ignoreUnsecuredDadFirstTentative(2) 973 } 974 MAX-ACCESS read-write 975 STATUS current 976 DESCRIPTION 977 "This object specifies whether the node accepts or ignores 978 unsecured advertisements received when performing 979 Duplicate Address Detection for the first CGA tentative 980 address. sendIgnoreUnsecuredDadFirstTentative can be 981 configured to ignoreUnsecuredDadFirstTentative(2) as a 982 recovery mechanism for cases in which attacks against the 983 first address become common. Note that for the second and 984 third tentative addresses, only secured advertisements are 985 considered." 986 REFERENCE "RFC 3971 : section 8" 987 DEFVAL { acceptUnsecuredDadFirstTentative } 988 ::= { send 19 } 990 -- 991 -- SEND statistics 992 -- 994 sendStatsInNDMsgs OBJECT-TYPE 995 SYNTAX Counter32 996 MAX-ACCESS read-only 997 STATUS current 998 DESCRIPTION 999 "The total number of ND messages (Neighbor Solicitation, 1000 Neighbor Advertisement, Router Solicitation, Router 1001 Advertisements and Redirects) that the node received. 1002 Note that this counter includes all the messages counted 1003 by sendStatsInNDSecuredWithErrors." 1004 ::= { send 20 } 1006 sendStatsInNDSecuredValidMsgs OBJECT-TYPE 1007 SYNTAX Counter32 1008 MAX-ACCESS read-only 1009 STATUS current 1010 DESCRIPTION 1011 "The total number of ND messages (Neighbor Solicitation, 1012 Neighbor Advertisement, Router Solicitation, Router 1013 Advertisements and Redirects) that were both secured and 1014 successfully validated according to the rules specified in 1015 [RFC3971]." 1016 REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2" 1017 ::= { send 21 } 1019 sendStatsInNDSecuredInvalidMsgs OBJECT-TYPE 1020 SYNTAX Counter32 1021 MAX-ACCESS read-only 1022 STATUS current 1023 DESCRIPTION 1024 "The total number of ND messages (Neighbor Solicitation, 1025 Neighbor Advertisement, Router Solicitation, Router 1026 Advertisements and Redirects) that contained any kind of 1027 SEND security information, but were not successfully 1028 validated according to the rules specified in [RFC3971]. 1029 Note that these messages MAY be further processed by the 1030 node as unsecured messages (and counted in 1031 sendStatsInNDUnsecuredMsgs), depending on the 1032 configuration of the node." 1033 REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2" 1034 ::= { send 22 } 1036 sendStatsInNDUnsecuredMsgs OBJECT-TYPE 1037 SYNTAX Counter32 1038 MAX-ACCESS read-only 1039 STATUS current 1040 DESCRIPTION 1041 "The total number of ND messages (Neighbor Solicitation, 1042 Neighbor Advertisement, Router Solicitation, Router 1043 Advertisements and Redirects) processed as unsecured. It 1044 includes messages that did not contain any security 1045 information defined in SEND, and messages containing 1046 security information for which validation failed and were 1047 finally processed as unsecured." 1048 ::= { send 23 } 1050 sendStatsInNDSecuredWithErrors OBJECT-TYPE 1051 SYNTAX Counter32 1052 MAX-ACCESS read-only 1053 STATUS current 1054 DESCRIPTION 1055 "The number of ND messages (Neighbor Solicitation, 1056 Neighbor Advertisement, Router Solicitation, Router 1057 Advertisements and Redirects) received by the node which 1058 were validated as secured but had ICMP-specific errors 1059 (bad ICMP checksums, bad length, bad format, etc.). Note 1060 that it does not include the messages counted by 1061 sendStatsInNDUnsecuredMsgs." 1062 ::= { send 24 } 1064 sendStatsOutNDMsgs OBJECT-TYPE 1065 SYNTAX Counter32 1066 MAX-ACCESS read-only 1067 STATUS current 1068 DESCRIPTION 1069 "The total number of ND messages (Neighbor Solicitation, 1070 Neighbor Advertisement, Router Solicitation, Router 1071 Advertisements and Redirects) that the node attempted to 1072 send. This counter includes all messages counted by 1073 sendStatsOutNDSecuredErrors." 1074 ::= { send 25 } 1076 sendStatsOutNDSecuredMsgs OBJECT-TYPE 1077 SYNTAX Counter32 1078 MAX-ACCESS read-only 1079 STATUS current 1080 DESCRIPTION 1081 "The number of secured ND messages (Neighbor Solicitation, 1082 Neighbor Advertisement, Router Solicitation, Router 1083 Advertisements and Redirects) attempted to be sent by the 1084 node." 1085 REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2" 1086 ::= { send 26 } 1088 sendStatsOutNDSecuredErrors OBJECT-TYPE 1089 SYNTAX Counter32 1090 MAX-ACCESS read-only 1091 STATUS current 1092 DESCRIPTION 1093 "The number of secured ND messages (Neighbor Solicitation, 1094 Neighbor Advertisement, Router Solicitation, Router 1095 Advertisements and Redirects) attempted to be sent by the 1096 node that was not sent due to problems discovered within 1097 ICMP, such as a lack of buffers. This value SHOULD NOT 1098 include errors discovered outside the ICMP layer, such as 1099 the inability of IP to route the resultant datagram. In 1100 some implementations, there may be no types of error that 1101 contribute to this counter's value." 1102 ::= { send 27 } 1104 sendStatsInCertMsgs OBJECT-TYPE 1105 SYNTAX Counter32 1106 MAX-ACCESS read-only 1107 STATUS current 1108 DESCRIPTION 1109 "The number of Certification Path Advertisement messages 1110 received by the node." 1111 ::= { send 28 } 1113 sendStatsInCertVerifiedMsgs OBJECT-TYPE 1114 SYNTAX Counter32 1115 MAX-ACCESS read-only 1116 STATUS current 1117 DESCRIPTION 1118 "The number of Certification Path Advertisement messages 1119 received by a node which could be verified according to 1120 the verification procedure defined in section 6.3 of 1121 [RFC3971]." 1122 REFERENCE "RFC 3971 : section 6.3" 1123 ::= { send 29 } 1125 sendStatsInCertInvalidMsgs OBJECT-TYPE 1126 SYNTAX Counter32 1127 MAX-ACCESS read-only 1128 STATUS current 1129 DESCRIPTION 1130 "The number of Certification Path Advertisement messages 1131 received by a host which it could not verify successfully, 1132 according to the verification procedure defined in section 1133 6.3 of [RFC3971]. It does not include messages counted by 1134 sendStatsInCertErrors." 1135 REFERENCE "RFC 3971 : section 6.3" 1136 ::= { send 30 } 1138 sendStatsInCertErrors OBJECT-TYPE 1139 SYNTAX Counter32 1140 MAX-ACCESS read-only 1141 STATUS current 1142 DESCRIPTION 1143 "The number of Certification Path Advertisement messages 1144 received that had ICMP-specific errors (bad ICMP 1145 checksums, bad length, bad format, etc.). Note that it 1146 does not include the messages counted by 1147 sendStatsInCertFailedMessages." 1148 ::= { send 31 } 1150 -- 1151 -- conformance information 1152 -- 1154 sendMIBConformance OBJECT IDENTIFIER ::= { sendMIB 2 } 1156 sendMIBCompliances OBJECT IDENTIFIER ::= { sendMIBConformance 1 } 1158 sendMIBGroups OBJECT IDENTIFIER ::= { sendMIBConformance 2 } 1160 -- compliance statement #1 1162 sendMIBCompatibleCompliance MODULE-COMPLIANCE 1163 STATUS current 1164 DESCRIPTION 1165 "Compliance statement for a managed element that supports 1166 compatible operation with non-SEND devices, and it is 1167 fully configurable (read-create access for the 1168 sendTrustAnchorGroup, and read-write access for all 1169 writable objects)." 1170 MODULE -- this module 1171 MANDATORY-GROUPS { 1172 sendAuthorityGroup, sendTimestampGroup, 1173 sendTrustAnchorGroup, sendCertGroup, 1174 sendCgaLocalGroup, sendCompatibilityGroup, 1175 sendStatsGroup } 1177 OBJECT sendTrustAnchorRowStatus 1178 SYNTAX RowStatus { active(1), notInService (2) } 1179 WRITE-SYNTAX RowStatus { active(1), notInService (2), 1180 createAndGo(4), destroy(6) } 1181 DESCRIPTION 1182 "Support for createAndWait is not required." 1184 OBJECT sendCgaVerificationMaxbits 1185 MIN-ACCESS read-only 1186 DESCRIPTION 1187 "An agent is not required to provide write access to this 1188 object, since this object MAY not be configurable." 1190 ::= { sendMIBCompliances 1 } 1192 -- compliance statement #2 1194 sendMIBSendOnlyCompliance MODULE-COMPLIANCE 1195 STATUS current 1196 DESCRIPTION 1197 "Compliance statement for an managed element that does not 1198 support compatible operation with non-SEND devices and it 1199 is fully configurable (read-create access for the 1200 sendTrustAnchorGroup, and read-write access for all 1201 writable objects)." 1202 MODULE -- this module 1203 MANDATORY-GROUPS { 1204 sendAuthorityGroup, sendTimestampGroup, 1205 sendTrustAnchorGroup, sendCertGroup, 1206 sendCgaLocalGroup, sendStatsGroup } 1208 OBJECT sendTrustAnchorRowStatus 1209 SYNTAX RowStatus { active(1), notInService (2) } 1210 WRITE-SYNTAX RowStatus { active(1), notInService (2), 1211 createAndGo(4), destroy(6) } 1212 DESCRIPTION 1213 "Support for createAndWait is not required." 1215 OBJECT sendCgaVerificationMaxbits 1216 MIN-ACCESS read-only 1217 DESCRIPTION 1218 "An agent is not required to provide write access to this 1219 object, since this object MAY not be configurable." 1221 ::= { sendMIBCompliances 2 } 1223 -- compliance statement #3 1225 sendMIBCompatibleReadOnlyCompliance MODULE-COMPLIANCE 1226 STATUS current 1227 DESCRIPTION 1228 "Compliance statement for a managed element that supports 1229 compatible operation with non-SEND devices, but it is 1230 implemented without support for the creation of rows in 1231 the sendTrustAnchorGroup, and with read-only access for 1232 the remaining writable objects." 1233 MODULE -- this module 1235 MANDATORY-GROUPS { 1236 sendAuthorityGroup, sendTimestampGroup, 1237 sendTrustAnchorGroup, sendCertGroup, 1238 sendCgaLocalGroup, sendCompatibilityGroup, 1239 sendStatsGroup } 1241 OBJECT sendCgaVerificationMinbits 1242 MIN-ACCESS read-only 1243 DESCRIPTION 1244 "An agent is not required to provide write access to this 1245 object." 1247 OBJECT sendCgaVerificationMaxbits 1248 MIN-ACCESS read-only 1249 DESCRIPTION 1250 "An agent is not required to provide write access to this 1251 object." 1253 OBJECT sendRsaVerificationMethodNS 1254 MIN-ACCESS read-only 1255 DESCRIPTION 1256 "An agent is not required to provide write access to this 1257 object." 1259 OBJECT sendRsaVerificationMethodNA 1260 MIN-ACCESS read-only 1261 DESCRIPTION 1262 "An agent is not required to provide write access to this 1263 object." 1265 OBJECT sendRsaVerificationMethodRS 1266 MIN-ACCESS read-only 1267 DESCRIPTION 1268 "An agent is not required to provide write access to this 1269 object." 1271 OBJECT sendRsaVerificationMethodRA 1272 MIN-ACCESS read-only 1273 DESCRIPTION 1274 "An agent is not required to provide write access to this 1275 object." 1277 OBJECT sendRsaVerificationMethodRedirect 1278 MIN-ACCESS read-only 1279 DESCRIPTION 1280 "An agent is not required to provide write access to this 1281 object." 1283 OBJECT sendTimestampDelta 1284 MIN-ACCESS read-only 1285 DESCRIPTION 1286 "An agent is not required to provide write access to this 1287 object." 1289 OBJECT sendTimestampFuzz 1290 MIN-ACCESS read-only 1291 DESCRIPTION 1292 "An agent is not required to provide write access to this 1293 object." 1295 OBJECT sendTimestampDrift 1296 MIN-ACCESS read-only 1297 DESCRIPTION 1298 "An agent is not required to provide write access to this 1299 object." 1301 OBJECT sendTrustAnchorSpinLock 1302 MIN-ACCESS not-accessible 1303 DESCRIPTION 1304 "An agent is not required to implement this object. 1305 However, if an agent provides write access to any of the 1306 other objects in the sendTrustAnchorGroup, it SHOULD 1307 provide write access to this object as well." 1309 OBJECT sendTrustAnchorCert 1310 MIN-ACCESS read-only 1311 DESCRIPTION 1312 "An agent is not required to provide write access to this 1313 object." 1315 OBJECT sendTrustAnchorStatus 1316 MIN-ACCESS read-only 1317 DESCRIPTION 1318 "An agent is not required to provide write or create 1319 access to this object." 1321 OBJECT sendTrustAnchorRowStatus 1322 SYNTAX RowStatus { active(1) } 1323 MIN-ACCESS read-only 1324 DESCRIPTION 1325 "An agent is not required to provide write or create 1326 access to this object. In this case, the only value 1327 permitted is active(1)." 1329 OBJECT sendTrustAnchorStorageType 1330 MIN-ACCESS read-only 1331 DESCRIPTION 1332 "An agent is not required to provide write or create 1333 access to this object. If an agent allows this object to 1334 be written or created, it is not required to allow this 1335 object to be set to nonVolatile(3), permanent(4) or 1336 readOnly(5)." 1338 OBJECT sendAcceptUnsecured 1339 MIN-ACCESS read-only 1340 DESCRIPTION 1341 "An agent is not required to provide write access to this 1342 object." 1344 OBJECT sendIgnoreUnsecuredDadFirstTentative 1345 MIN-ACCESS read-only 1346 DESCRIPTION 1347 "An agent is not required to provide write access to this 1348 object." 1349 ::= { sendMIBCompliances 3 } 1351 -- compliance statement #4 1353 sendMIBSendOnlyReadOnlyCompliance MODULE-COMPLIANCE 1354 STATUS current 1355 DESCRIPTION 1356 "Compliance statement for an agent that does not support 1357 compatible operation with non-SEND devices and it is 1358 implemented without support for read-create (i.e., in 1359 read-only mode)." 1361 MODULE -- this module 1363 MANDATORY-GROUPS { sendAuthorityGroup, sendTimestampGroup, 1364 sendTrustAnchorGroup, sendCertGroup, 1365 sendCgaLocalGroup, sendStatsGroup } 1367 OBJECT sendCgaVerificationMinbits 1368 MIN-ACCESS read-only 1369 DESCRIPTION 1370 "An agent is not required to provide write access to this 1371 object." 1373 OBJECT sendCgaVerificationMaxbits 1374 MIN-ACCESS read-only 1375 DESCRIPTION 1376 "An agent is not required to provide write access to this 1377 object." 1379 OBJECT sendRsaVerificationMethodNS 1380 MIN-ACCESS read-only 1381 DESCRIPTION 1382 "An agent is not required to provide write access to this 1383 object." 1385 OBJECT sendRsaVerificationMethodNA 1386 MIN-ACCESS read-only 1387 DESCRIPTION 1388 "An agent is not required to provide write access to this 1389 object." 1391 OBJECT sendRsaVerificationMethodRS 1392 MIN-ACCESS read-only 1393 DESCRIPTION 1394 "An agent is not required to provide write access to this 1395 object." 1397 OBJECT sendRsaVerificationMethodRA 1398 MIN-ACCESS read-only 1399 DESCRIPTION 1400 "An agent is not required to provide write access to this 1401 object." 1403 OBJECT sendRsaVerificationMethodRedirect 1404 MIN-ACCESS read-only 1405 DESCRIPTION 1406 "An agent is not required to provide write access to this 1407 object." 1409 OBJECT sendTimestampDelta 1410 MIN-ACCESS read-only 1411 DESCRIPTION 1412 "An agent is not required to provide write access to this 1413 object." 1415 OBJECT sendTimestampFuzz 1416 MIN-ACCESS read-only 1417 DESCRIPTION 1418 "An agent is not required to provide write access to this 1419 object." 1421 OBJECT sendTimestampDrift 1422 MIN-ACCESS read-only 1423 DESCRIPTION 1424 "An agent is not required to provide write access to this 1425 object." 1427 OBJECT sendTrustAnchorSpinLock 1428 MIN-ACCESS not-accessible 1429 DESCRIPTION 1430 "An agent is not required to implement this object. 1431 However, if an agent provides write access to any of the 1432 other objects in the sendTrustAnchorGroup, it SHOULD 1433 provide write access to this object as well." 1435 OBJECT sendTrustAnchorCert 1436 MIN-ACCESS read-only 1437 DESCRIPTION 1438 "An agent is not required to provide write access to this 1439 object." 1441 OBJECT sendTrustAnchorRowStatus 1442 SYNTAX RowStatus { active(1) } 1443 MIN-ACCESS read-only 1444 DESCRIPTION 1445 "An agent is not required to provide write or create 1446 access to this object." 1448 OBJECT sendTrustAnchorStorageType 1449 MIN-ACCESS read-only 1450 DESCRIPTION 1451 "An agent is not required to provide write or create 1452 access to this object. If an agent allows this object to 1453 be written or created, it is not required to allow this 1454 object to be set to nonVolatile(3), permanent(4) or 1455 readOnly(5)." 1457 ::= { sendMIBCompliances 4 } 1459 -- Units of conformance 1461 sendAuthorityGroup OBJECT-GROUP 1462 OBJECTS { 1463 sendCgaVerificationMinbits, 1464 sendCgaVerificationMaxbits, 1465 sendRsaVerificationMethodNS, 1466 sendRsaVerificationMethodNA, 1467 sendRsaVerificationMethodRS, 1468 sendRsaVerificationMethodRA, 1469 sendRsaVerificationMethodRedirect 1470 } 1471 STATUS current 1472 DESCRIPTION 1473 "The group of objects that control SEND authority 1474 attestation and verification processes. These objects 1475 manage the acceptable size of the CGAs being used and the 1476 checks that are applied to incoming SEND authority 1477 information." 1478 ::= { sendMIBGroups 1 } 1480 sendTimestampGroup OBJECT-GROUP 1481 OBJECTS { 1482 sendTimestampDelta, sendTimestampFuzz, sendTimestampDrift 1483 } 1484 STATUS current 1485 DESCRIPTION 1486 "The group of objects that control the verification of the 1487 Timestamp option to provide anti-replay protection" 1488 ::= { sendMIBGroups 2 } 1490 sendTrustAnchorGroup OBJECT-GROUP 1491 OBJECTS { 1492 sendTrustAnchorSpinLock, 1493 sendTrustAnchorCert, 1494 sendTrustAnchorStatus, 1495 sendTrustAnchorRowStatus, 1496 sendTrustAnchorStorageType 1497 } 1498 STATUS current 1499 DESCRIPTION 1500 "The group of objects for managing the anchors used for 1501 validating the authority of the Certification Path of a 1502 remote node." 1503 ::= { sendMIBGroups 3 } 1505 sendCertGroup OBJECT-GROUP 1506 OBJECTS { 1507 sendCertCert, 1508 sendCertParentCertificate, 1509 sendCertStatus 1510 } 1511 STATUS current 1512 DESCRIPTION 1513 "The group of objects for storing the certificates that 1514 belong to a Certification Path received from a remote 1515 router." 1516 ::= { sendMIBGroups 4 } 1518 sendCgaLocalGroup OBJECT-GROUP 1519 OBJECTS { 1520 sendCgaLocalStatus 1521 } 1522 STATUS current 1523 DESCRIPTION 1524 "The group for the object pointing to the CGA which can be 1525 used by SEND as local addresses." 1526 ::= { sendMIBGroups 5 } 1528 sendCompatibilityGroup OBJECT-GROUP 1529 OBJECTS { sendAcceptUnsecured, sendIpAddressPrefixSecuredStatus, 1530 sendIpDefaultRouterSecuredStatus, 1531 sendIpNetToPhysicalSecuredStatus, 1532 sendIgnoreUnsecuredDadFirstTentative } 1533 STATUS current 1534 DESCRIPTION 1535 "The group of objects to configure SEND operation to 1536 interact with non-SEND hosts and to show the security 1537 status of the resulting ND information." 1538 ::= { sendMIBGroups 6 } 1540 sendStatsGroup OBJECT-GROUP 1541 OBJECTS { 1542 sendStatsInNDMsgs, 1543 sendStatsInNDSecuredValidMsgs, 1544 sendStatsInNDSecuredInvalidMsgs, 1545 sendStatsInNDUnsecuredMsgs, 1546 sendStatsInNDSecuredWithErrors, 1547 sendStatsOutNDMsgs, 1548 sendStatsOutNDSecuredMsgs, 1549 sendStatsOutNDSecuredErrors, 1550 sendStatsInCertMsgs, 1551 sendStatsInCertVerifiedMsgs, 1552 sendStatsInCertInvalidMsgs, 1553 sendStatsInCertErrors 1554 } 1555 STATUS current 1556 DESCRIPTION 1557 "The group of statistics related to SEND operation." 1558 ::= { sendMIBGroups 7 } 1560 END 1562 5. Security Considerations 1564 There are a number of management objects defined in this MIB module 1565 with a MAX-ACCESS clause of read-write or read-create. Such objects 1566 may be considered sensitive or vulnerable in some network 1567 environments. In the following paragraphs we discuss the risks 1568 associated to improper SET access to the objects of the MIB module. 1569 o sendCgaVerificationMinbits. Reducing the value of this object may 1570 facilitate the impersonation of a legitimate CGA by an attacker: 1571 the time to generate a key pair can be shortened, so the time to 1572 perform a brute force attack to find a key pair with the same hash 1573 as the attacked CGA can be shortened. On the other hand, 1574 incrementing the value of sendCgaVerificationMinbits may result in 1575 a DOS attack when only secured ND messages are accepted by the 1576 node, since messages from other nodes could be unintendedly 1577 discarded if having a CGA with a key shorter than 1578 sendCgaVerificationMinbits. 1579 o sendCgaVerificationMaxbits. On one hand, low values of the 1580 sendCgaVerificationMaxbits object can result in discarding 1581 messages secured with a CGA larger than the limit established in 1582 this object, resulting in a DOS attack. On the other hand, an 1583 attacker could set high values to defeat the purpose of this 1584 configurable parameter, i.e. protect against the high resource 1585 consumption of resources in the receiver of a signed message. 1586 o sendRsaVerificationMethodNS, sendRsaVerificationMethodNA, 1587 sendRsaVerificationMethodRS, sendRsaVerificationMethodRA and 1588 sendRsaVerificationMethodRedirect. The modification of the 1589 authorization method used for validating any of the messages of 1590 the ND protocol by an attacker can result in a DOS attack. The 1591 DOS attack occurs when the node is configured to require a type of 1592 authorization that it is not compatible with the authorization 1593 being used by the party generating the message. 1594 o sendTimestampDelta, sendTimeFuzz and sendTimestampDrift. 1595 Incrementing the value of the objects sendTimestampDelta, 1596 sendTimeFuzz and sendTimestampDrift extends the vulnerability 1597 window for replay attacks. Section 9.2.5 of [RFC3971] discusses 1598 the impact of this action. On the other hand, setting too low 1599 values to these three objects may result in a DOS attack, since 1600 valid SEND messages could be discarded by too tight validation 1601 constraints. 1602 o sendTrustAnchorTable. The addition of an entry in the anchor 1603 table by an unauthorized party can be used to make the node trust 1604 (in SEND sense) in the information contained in Router 1605 Advertisements issued by a malicious node in the link. For 1606 example, this malicious node can become for the attacked node a 1607 default router (and perform MITM attacks for off-link 1608 destinations), it can alter the list of prefixes used for address 1609 autoconfiguration, and the list of prefixes considered to be on- 1610 link. The unauthorized disabling or deletion of an entry in the 1611 sendTrustAnchorTable can result in DOS for the attacked node, 1612 since the node will not consider validly secured information as 1613 legitimate. 1614 o sendAcceptUnsecured. Write access from an unauthorized party to 1615 unintendedly accept unsecured information can be used to enable an 1616 attacker to introduce unprotected information into the ND data 1617 structures. Note that the possible attacks are limited by the 1618 fact that in general secured information is preferred to 1619 unsecured, as described by [RFC3971] section 8. Conversely, if 1620 the value of the sendAcceptUnsecured object is unintendedly 1621 changed from acceptSecuredAndUnsecured to acceptOnlySecured, the 1622 node will lose the communication with non-SEND devices in the link 1623 considered, being this a DOS attack. 1624 o sendIgnoreUnsecuredDadFirstTentative. As [RFC3971], section 9.2.3 1625 states, if this object value is maliciously changed to ignore 1626 unsecured Neighbor Advertisements when DAD is being performed, a 1627 potential address collision between a SEND node and a non-SEND 1628 node may occur. The probability and effects of such an address 1629 collision are discussed in [RFC3972]. On the other side, if the 1630 node is maliciously changed to accept unsecured Neighbor 1631 Advertisements as response to DAD, a node controlled by an 1632 attacker can force the generation of a second CGA. Since the DAD 1633 procedure in a SEND node for the second CGA only considers secured 1634 responses, regardless the state of this object, this impact is 1635 low. 1637 The risk associated to unintended access to the readable objects in 1638 this MIB module (i.e., objects with a MAX-ACCESS other than not- 1639 accessible) are now discussed. 1640 o sendCgaVerificationMinbits. Read access to this object by an 1641 unauthorized node can provide information about the minimum key 1642 length to use in a brute force attack to impersonate the CGA of 1643 other node. If this value is not known by the attacker, the 1644 attacker could use in a brute force attack keys with a length 1645 shorter than the minimum acceptable, and so being unable to obtain 1646 valid values for the CGA Parameter Data Structure. Note that the 1647 attacker could blindly estimate a reasonable key length (such as 1648 the suggested default value, 1024 bits) to perform this attack 1649 with high probability of success without knowing this value. 1650 o sendCgaVerificationMaxbits. Read access to this object by an 1651 unauthorized node can provide information about the maximum key 1652 length that can be claimed to try to drain CPU resources forcing 1653 the managed system to compute useless key verifications. 1654 o sendTimestampDelta, sendTimeFuzz and sendTimestampDrift. Knowing 1655 these values can make an attacker aware of the anti-replay 1656 protection window. However, if the values are set appropriately, 1657 the risks are low, as described in Section 9.2.5 of [RFC3971]. 1658 o sendTrustAnchorTable. Having read access to the rows in the 1659 sendTrustAnchorTable allows a node to know which are the trust 1660 anchors in which the managed node rely on. An attacker could 1661 focus on breaking any of these keys to perform further attacks to 1662 the node. However, it is very likely that this information can 1663 also be inferred from the certificates being exchanged in the link 1664 to which the managed node is connected. The attacker can ask 1665 directly the router with a CPS message to obtain this information. 1666 o sendCertTable. Accessing to the sendCertTable does not reveal any 1667 information which could not be obtained by the attacker from a 1668 CPS/CPA message exchange. Therefore accessing to this information 1669 is not sensitive for the security of the managed node. 1670 o sendCgaLocalTable. Accessing to this information is not sensitive 1671 for the CGA configured in the link to which the attacker is also 1672 connected, since the attacker can obtain the same information by 1673 issuing a NS message to the managed node (or by capturing messages 1674 exchanged among the node and other nodes). The table can reveal 1675 CGAs configured in other links. Note that access to the IP- 1676 MIB:ipAddressTable also reveals other addresses configured in the 1677 same node (even though it cannot be determined if they are CGA or 1678 not). The risks of accessing to CGA-specific information 1679 contained in the CGA-MIB:cgaLocalTable are discussed in 1680 [I-D.garcia-martinez-cgamib]. 1681 o sendAcceptUnsecured. An attacker could know by accessing to this 1682 information if the managed node is willing to accept unsecured 1683 messages. It can also try to influence in the managed node ND 1684 database by issuing unsecured messages, even without knowing the 1685 value of this object. Note that the attacker could obtain the 1686 same information by exchanging unsecured ND information with the 1687 node to test if the node accepts it. 1688 o sendIpAddressPrefixSecuredTable, sendIpDefaultRouterSecuredTable, 1689 sendIpNetToPhysicalSecuredTable. An attacker could know, by 1690 reading this tables, which of the prefixes, default routers and 1691 neighbor information have been introduced securely in the managed 1692 node as a result of SEND operation. This can be used, for 1693 example, to try to modify the information acquired as a result of 1694 an unsecured ND exchange. This does not provide much advantage 1695 for the attacker over just trying to introduce this information by 1696 sending ND messages to the managed node, or by identifying by 1697 traffic inspection or solicitation messages which routers or other 1698 node present in the link use SEND and which use plain ND. 1699 o sendIgnoreUnsecuredDadFirstTentative. An attacker accessing to 1700 this value could know in advance if sending unsecured NA when the 1701 managed node performs DAD will result in the managed node 1702 discarding the first address tried. Note that the impact of this 1703 attack is low, as discussed in [RFC3972], and this attack could 1704 only be exercised the next time the managed node tries to 1705 configure a new CGA. 1706 o Objects collecting statistics about SEND operation. The 1707 disclosure of the information available in these objects affects 1708 mainly to privacy. 1710 SNMP versions prior to SNMPv3 did not include adequate security. 1711 Even if the network itself is secure (for example by using IPsec), 1712 even then, there is no control as to who on the secure network is 1713 allowed to access and GET/SET (read/change/create/delete) the objects 1714 in this MIB module. 1716 It is RECOMMENDED that implementers consider the security features as 1717 provided by the SNMPv3 framework (see [RFC3410], section 8), 1718 including full support for the SNMPv3 cryptographic mechanisms (for 1719 authentication and privacy). 1721 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1722 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1723 enable cryptographic security. It is then a customer/operator 1724 responsibility to ensure that the SNMP entity giving access to an 1725 instance of this MIB module is properly configured to give access to 1726 the objects only to those principals (users) that have legitimate 1727 rights to indeed GET or SET (change/create/delete) them. 1729 6. IANA Considerations 1731 The MIB module in this document uses the following IANA-assigned 1732 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1734 Descriptor OBJECT IDENTIFIER value 1735 ---------- ----------------------- 1737 send-MIB { mib-2 XXX } 1739 Editor's Note (to be removed prior to publication): the IANA is 1740 requested to assign a value for "XXX" under the 'mib-2' subtree and 1741 to record the assignment in the SMI Numbers registry. When the 1742 assignment has been made, the RFC Editor is asked to replace "XXX" 1743 (here and in the MIB module) with the assigned value and to remove 1744 this note. 1746 7. Acknowledgements 1748 The work of Alberto Garcia-Martinez was supported in part by T2C2 1749 project (TIN2008-06739-C04-01, granted by the Spanish Science and 1750 Innovation Ministry). 1752 The authors would like to thank Suresh Krishnan for reviewing the 1753 document. 1755 8. References 1757 8.1. Normative References 1759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1760 Requirement Levels", BCP 14, RFC 2119, March 1997. 1762 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1763 Schoenwaelder, Ed., "Structure of Management Information 1764 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1766 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1767 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1768 STD 58, RFC 2579, April 1999. 1770 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1771 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1772 April 1999. 1774 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1775 Identifiers for the Internet X.509 Public Key 1776 Infrastructure Certificate and Certificate Revocation List 1777 (CRL) Profile", RFC 3279, April 2002. 1779 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1780 Housley, R., and W. Polk, "Internet X.509 Public Key 1781 Infrastructure Certificate and Certificate Revocation List 1782 (CRL) Profile", RFC 5280, May 2008. 1784 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1785 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1787 [RFC4293] Routhier, S., "Management Information Base for the 1788 Internet Protocol (IP)", RFC 4293, April 2006. 1790 [CCITT.X690.2002] 1791 International International Telephone and Telegraph 1792 Consultative Committee, "ASN.1 encoding rules: 1793 Specification of basic encoding Rules (BER), Canonical 1794 encoding rules (CER) and Distinguished encoding rules 1795 (DER)", CCITT Recommendation X.690, July 2002. 1797 [I-D.garcia-martinez-cgamib] 1798 Garcia-Martinez, A. and M. Bagnulo, "Management 1799 Information Base for Cryptographically Generated Addresses 1800 (CGA)", draft-garcia-martinez-cgamib-05 (work in 1801 progress), September 2012. 1803 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1804 RFC 3972, March 2005. 1806 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1807 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1808 September 2007. 1810 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1811 Address Autoconfiguration", RFC 4862, September 2007. 1813 8.2. Informative References 1815 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1816 "Introduction and Applicability Statements for Internet- 1817 Standard Management Framework", RFC 3410, December 2002. 1819 Authors' Addresses 1821 Alberto Garcia-Martinez 1822 Universidad Carlos III de Madrid 1823 Av. Universidad 30 1824 Leganes, Madrid 28911 1825 SPAIN 1827 Phone: 34 91 6249500 1828 Email: alberto@it.uc3m.es 1829 URI: http://www.it.uc3m.es 1830 Marcelo Bagnulo 1831 U. Carlos III de Madrid 1832 Av. Universidad 30 1833 Leganes, Madrid 28911 1834 Spain 1836 Phone: +34 91 6248814 1837 Email: marcelo@it.uc3m.es 1838 URI: http://www.it.uc3m.es/