Network Working Group A. Garcia-Martinez Internet-Draft UC3M Intended status: Standards Track July 4, 2008 Expires: January 5, 2009 Management Information Base for the SEcure Neighbor Discovery (SEND) protocol draft-garcia-martinez-sendmib-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 5, 2009. Abstract This memo defines a portion of the Management Information Base (MIB) for managing the SEND (SEcure Neighbor Discovery) Protocol. Garcia-Martinez Expires January 5, 2009 [Page 1]
Internet-Draft SEND MIB July 2008 Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 44 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1. Normative References . . . . . . . . . . . . . . . . . . . 48 6.2. Informative References . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 50 Garcia-Martinez Expires January 5, 2009 [Page 2]
Internet-Draft SEND MIB July 2008 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This document defines the SEND-MIB, the portion of the Management Information Base (MIB) to be used for managing the SEcure Neighbor Discovery (SEND) [RFC3971] protocol. SEND specifies security mechanisms to protect the Neighbor Discovery (ND) Protocol [RFC4861], [RFC4862], so it is IPv6-specific. To protect the ND protocol, it relies on o Certification Paths, anchored on trusted parties, which can be used to certify the authority of the routers. Certification Paths are exchanged among routers and hosts by means of two new ICMP messages, the Certification Path Solicitation message and the Certification Path Advertisement message. o Cryptographically Generated Addresses (CGAs) [RFC3972], IPv6 addresses that can be used to prove address ownership o RSA Signature options, that protect ND messages by using keying material related to Certification Paths or CGAs. The SEND-MIB provides means to monitor and configure most of the elements related with SEND operation in hosts. In particular, it allows managing: o SEND operational status. The sendInterfaceOperTable indicates if there exists the configuration required by SEND to operate on each interface (trust anchors, local CGA). o Authority attestation and verification. The sendRsaWithCgaAuthorization object manages the inclusion of CGA in messages sent by the node to attest its authority. The following objets are related to authority verification management in the receiver. The sendCpaRequireIPAddressExt object manages if received Certification Path Advertisements must contain an 'addressesOrRanges' element to be processed. sendCgaVerificationMinbits and sendCgaVerificationMaxbits specify respectively the minimum and maximum number of bits that a key of a received CGA must have to be used by SEND. The Garcia-Martinez Expires January 5, 2009 [Page 3]
Internet-Draft SEND MIB July 2008 sendRsaVerificationMethod set of discrete objects indicate, for each ND message type, the method through which the authority of the remote node is determined (Certification Path and/or CGA). o Timestamp verification. The parameters that control the verification of the Timestamp option to provide anti-reply protection are managed through the discrete objects sendTimestampDelta, sendTimestampFuzz, sendTimestampDrift. o Cryptographic information repository. Two tables store the cryptographic information specifically required by SEND, after it has been validated. * The sendTrustAnchorTable stores the trust anchors configured in the node. Read-create access to the objects of this table enables the use of network management protocols to create and modify them. * The sendRemoteCertTable stores the certificates received in Certification Path Advertisement messages. A RowPointer column enables the implementation of a linked list in order to reflect the dependencies of the certificates forming a Certification Path. Additionally, the first entry of a Certification Path points to the anchor to which its valiation depends on. * Information about local and remote CGA addresses is available in a non-SEND specific table defined in the CGA-MIB [CGA-MIB]. o Compatibility with non-SEND devices. The sendCompatibilityStatus object allows disabling the protection of the ND messages generated in the node for compatibility purposes. The sendInterfaceNonSendCompatTable manages the acceptance of unsecured ND messages for each interface. Interfaces are identified using the IfIndex type defined in [RFC2863]. If unsecured ND messages are accepted, it should be useful to know which of the information received is secured. To do so, several tables show the Security status of ND related information. Three tables augment existing RFC 4282 tables to indicate whether the information related to an address prefix, a default router, or an association between an IP address and a physical address, has been secured by SEND. These tables are sendIpAddressPrefixSecuredTable, sendIpDefaultRouterSecuredTable, sendIpNetToPhysicalSecuredTable. An additional table is created, as an extension to the inetCidrRouteTable [RFC4292] to indicate if the addition or modification of entries of this table due to Redirect messages has been secured by SEND or not. Finally, sendIgnoreUnsecuredDadFirstTentative controls DAD operation in links with non-SEND devices. o SEND statistics. The statistics include accounting for ND discovery secured and unsecured messages, and the number of certification messages per each interface. Interfaces are identified using the IfIndex type defined in [RFC2863]. The SEND-MIB does not aim to manage SEND operation in routers, except Garcia-Martinez Expires January 5, 2009 [Page 4]
Internet-Draft SEND MIB July 2008 for configurations that may be common for both routers and hosts. In this sense, the approach taken for this document follows the one taken in the definition of the IP-MIB [RFC4293], that did not provide objects to manage the generation of Router Advertisement messages, and in particular, it did not provide means to manage prefix options. In a similar way, the SEND-MIB does not provide means to manage the generation of Certification Path Advertisement, or the securitye configuration of Router Advertisement messages, along with the certificate material in the routers. These configuration capabilities are left for future specifications. 3. Definitions SEND-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2, TimeTicks, Integer32, Counter32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TestAndIncr, RowStatus, StorageType, RowPointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB inetCidrRouteDestType, inetCidrRouteDest, inetCidrRoutePfxLen, inetCidrRoutePolicy, inetCidrRouteNextHopType, inetCidrRouteNextHop FROM IP-FORWARD-MIB ipAddressPrefixEntry, ipDefaultRouterEntry, ipNetToPhysicalEntry FROM IP-MIB; sendMIB MODULE-IDENTITY LAST-UPDATED "200807040000Z" ORGANIZATION "IETF CSI (Cga & Send Maintenance) Working Group" CONTACT-INFO "Editor: Alberto Garcia-Martinez U. Carlos III de Madrid Avenida Universidad, 30 Leganes, Madrid 28911 Spain Email: alberto.garcia@uc3m.es CSI Working Group: cga-ext@ietf.org" Garcia-Martinez Expires January 5, 2009 [Page 5]
Internet-Draft SEND MIB July 2008 DESCRIPTION "The MIB module for managing the SEND protocol. Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this -- note REVISION "200807040000Z" DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove -- this note ::= { mib-2 XXX } -- RFC Ed.: replace XXX with actual number assigned by IANA & -- remove this note -- -- The textual conventions we define and use in this MIB. -- SendRsaVerificationMethod ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Acceptable authorization methods to validate the RSA signature option of a received NDP message. In the trustAnchor(1) method, the option is verified according to the keying information resulting from a Certification Path rooted in a trust anchor known by both sender and receiver. The sender may claim additional authorization through the use of CGAs, but this is neither required nor verified. In the cga(2) method, the CGA property of the sender's address is verified. The sender may claim additional authority through a trust anchor, but this is neither required nor verified. In the trustAnchorAndCga(3) method, both the trust anchor and the CGA verification are required. Finally, with the trustAnchorOrCga(4) method, either the trust anchor or the CGA verification is required." Garcia-Martinez Expires January 5, 2009 [Page 6]
Internet-Draft SEND MIB July 2008 REFERENCE "RFC 3971 : section 5.2.3" SYNTAX INTEGER { trustAnchor(1), cga(2), trustAnchorAndCga(3), trustAnchorOrCga(4) } SendCertificateIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique value, greater than zero, for each certificate within a table containing anchor or certificates. The management station MUST select a pseudo-random number to use as the index. In the event that this index was already in use and an 'inconsistentValue' was returned in response to the management protocol set operation, the management station SHOULD select a new pseudo-random number and retry the operation. The value for each certificate must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." SYNTAX Unsigned32 (1..4294967295) SendX509ASN1DEREncodedRouterAuthCert ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A Router Authorization Certificate, i.e. an X.509v3 certificate as defined in RFC 3280 [RFC3280]. SHOULD contain at least one instance of the X.509 extension for IP addresses as defined in [RFC3279]. The certificate is encoded as an ASN.1 DER object." REFERENCE "RFC 3971: 6.3.1" SYNTAX OCTET STRING (SIZE (0..4096)) SendSecurityStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that specifies whether the information associated to the entry in which an object of this type is defined has been secured by SEND or not." SYNTAX INTEGER { sendSecured(1), sendNotSecured(2) } send OBJECT IDENTIFIER ::= { sendMIB 1 } Garcia-Martinez Expires January 5, 2009 [Page 7]
Internet-Draft SEND MIB July 2008 -- -- Operational status of SEND -- sendInterfaceOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SendInterfaceOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the operational status of SEND in a per-interface basis, indicating if there exists the configuration required by SEND to operate on each interface. The minimum configuration for a host is at least one valid anchor for the system in the sendTrustAnchorTable, and a CGA configured as a local address for each interface (appearing in the cgaLocalTable of the CGA-MIB [CGA-MIB]). When this configuration exists, SEND is considered to be operational on the considered interface, and the corresponding entry of the sendInterfaceOperTable is marked as sendOperational(1). Otherwise, the interface appears as configurationRequired(2), and SEND operation is not possible for that interface. Note that the particular behavior regarding SEND processing for sent and received messages for interfaces in an sendOperational(1) state is further refined by the objects controlling compatibility with non-SEND devices, i.e. sendCompatibilityStatus, sendInterfaceNonSendCompatTable and sendIgnoreUnsecuredDadFirstTentative. If this objects controlling compatibility are not implemented, full SEND operation is assumed (the interface always protects ND messages, and messages received that are unsecured are discarded. In the same way, the behavior of the interfaces marked as configurationRequires(2) also depends on the values of the objects of the compatibility group. In particular, if this group is not implemented, or if the sendCompatibilityStatus has the value of sendSecuredMsgs(1), or if the entry corresponding to this interface in the sendInterfaceNonSendCompatTable is set to acceptOnlySecured(2), then ND operation in the considered interface cannot proceed." ::= { send 1 } sendInterfaceOperEntry OBJECT-TYPE Garcia-Martinez Expires January 5, 2009 [Page 8]
Internet-Draft SEND MIB July 2008 SYNTAX SendInterfaceOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Operational status of SEND in a given interface." INDEX { sendInterfaceOperIfIndex } ::= { sendInterfaceOperTable 1 } SendInterfaceOperEntry ::= SEQUENCE { sendInterfaceOperIfIndex InterfaceIndex, sendInterfaceOperStatus INTEGER } sendInterfaceOperIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { sendInterfaceOperEntry 1 } sendInterfaceOperStatus OBJECT-TYPE SYNTAX INTEGER { sendOperational(1), configurationRequired(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the operational status of the SEND subsystem. If the value is sendOperational(1), the parameters required by SEND to operate are properly configures. If the value is configurationRequired(2), some configuration is missing for SEND to operate." ::= { sendInterfaceOperEntry 2 } -- -- Authority verification -- sendRsaWithCgaAuthorization OBJECT-TYPE SYNTAX INTEGER { used (1), cgaNotUsed (2) } Garcia-Martinez Expires January 5, 2009 [Page 9]
Internet-Draft SEND MIB July 2008 MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the sender includes a CGA option in ND messages containing RSA signature options. If SEND is enabled, hosts MUST have this object set to cgaUsed, so set commands writing a cgaNotUsed value in a host MUST fail. In SEND enabled routers it may contain either cgaUsed or cgaNotUsed. The object can only contain a cgaUsed value if a valid CGA associated to the interface exists." REFERENCE "RFC 3971 : section 5.2.3" ::= { send 2 } sendCpaRequireIPAddressExt OBJECT-TYPE SYNTAX INTEGER { requiredAddressOrRange (1), notRequiredAddressOrRange (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines whether the X.509 certificates received in a Certification Path Advertisement message are required to contain at least one addressesOrRanges element to be processed. If the value of sendRequireIPAddressExt is requiredAddressOrRange, certificates not containing this element are discarded. If the value of the object is notRequiredAddressOrRange, these certificates are accepted by the node for further processing. This object enables the use of limited certificate implementations." REFERENCE "RFC 3971 : section 6.3.1" DEFVAL { requiredAddressOrRange } ::= { send 3 } sendCgaVerificationMinbits OBJECT-TYPE SYNTAX Integer32 (384 .. 65536) MAX-ACCESS read-write STATUS current DESCRIPTION "Minimum acceptable key length for public keys used in the verification of remote CGA. The minimum RSA key length required for SEND is 384 bits [RFC3972]." REFERENCE "RFC 3971 : section 5.1.3" DEFVAL { 1024 } Garcia-Martinez Expires January 5, 2009 [Page 10]
Internet-Draft SEND MIB July 2008 ::= { send 4 } sendCgaVerificationMaxbits OBJECT-TYPE SYNTAX Integer32 (384 .. 65536) MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum acceptable key length for public keys used in the verification of remote CGA. The value of this object can limit the amount of computation needed when verifying packets. The minimum RSA key length required for SEND is 384 bits [RFC3972]." REFERENCE "RFC 3971 : section 5.1.3" DEFVAL { 2048 } ::= { send 5 } -- -- objects related with the authorization method used for verifying -- RSA signature options for each NDP message type -- sendRsaVerificationMethodNS OBJECT-TYPE SYNTAX SendRsaVerificationMethod MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the method through which the authority of the remote node is determined in the Neighbor Solicitation messages received. It affects to all interfaces of the node." REFERENCE "RFC 3971 : section 5.2.3" ::= { send 6 } sendRsaVerificationMethodNA OBJECT-TYPE SYNTAX SendRsaVerificationMethod MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the method through which the authority of the remote node is determined in the Neighbor Advertisement messages received. It affects to all interfaces of the node." REFERENCE "RFC 3971 : section 5.2.3" ::= { send 7 } sendRsaVerificationMethodRS OBJECT-TYPE Garcia-Martinez Expires January 5, 2009 [Page 11]
Internet-Draft SEND MIB July 2008 SYNTAX SendRsaVerificationMethod MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the method through which the authority of the remote node is determined in the Router Solicitation messages received. It affects to all interfaces of the node." REFERENCE "RFC 3971 : section 5.2.3" ::= { send 8 } sendRsaVerificationMethodRA OBJECT-TYPE SYNTAX SendRsaVerificationMethod MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the method through which the authority of the remote node is determined in the Router Advertisement messages received. It affects to all interfaces of the node." REFERENCE "RFC 3971 : section 5.2.3" ::= { send 9 } sendRsaVerificationMethodRedirect OBJECT-TYPE SYNTAX SendRsaVerificationMethod MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the method through which the authority of the remote node is determined in the Redirect messages received. It affects to all interfaces of the node." REFERENCE "RFC 3971 : section 5.2.3" ::= { send 10 } -- -- objects associated to timestamp verification management -- sendTimestampDelta OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum difference in absolute value between the timestamp included in a Neighbor Discovery message and the reception time of the message, measured in seconds with Garcia-Martinez Expires January 5, 2009 [Page 12]
Internet-Draft SEND MIB July 2008 the local clock. It corresponds to the variable TIMESTAMP_DELTA defined in RFC 3971." REFERENCE "RFC 3971 : section 5.3.4.2, RFC 3971 : section 10.2" DEFVAL { 300 } ::= { send 11 } sendTimestampFuzz OBJECT-TYPE SYNTAX TimeTicks UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Time in milliseconds, used to check each time a new SEND message is received that the following inequality holds: TSnew + sendTimestampFuzz > TSlast + (RDnew - RDlast) x (1 - sendTimestamDrift) - sendTimestampFuzz With TSnew: timestamp of the newly received SEND message TSlast: timestamp of the previously received SEND message RDnew: reception time of the newly received SEND message RDlast: reception time of the previously received SEND message. This object corresponds to the variable TIMESTAMP_FUZZ defined in RFC 3971." REFERENCE "RFC 3971 : 5.3.4.2, RFC 3971 : section 10.2" DEFVAL { 100 } ::= { send 12 } sendTimestampDrift OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "0.01 Percentage" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum clock drift allowed when validating the timestamp of a received Neighbor Discovery message, measured in parts per 10000 (or 0.01 percentage). It corresponds to the variable TIMESTAMP_DRIFT defined in RFC 3971." REFERENCE "RFC 3971 : 5.3.4.2, RFC 3971 : section 10.2" DEFVAL { 100 } ::= { send 13 } -- -- Cryptographic information repository -- Garcia-Martinez Expires January 5, 2009 [Page 13]
Internet-Draft SEND MIB July 2008 -- -- table of trust anchors known by a node -- sendTrustAnchorSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating SNMP managers to coordinate their use of the set operation in creating or modifying rows within the sendTrustAnchorTable table. In order to use this lock to coordinate the use of set operations, managers should first retrieve sendTrustAnchorSpinLock. They should then determine the appropriate row to create or modify, selecting a pseudo- random number for the sendTrustAnchorIndex. Finally, they should issue the appropriate set command including the retrieved value of sendTrustAnchorSpinLock. If another manager has altered the table in the meantime, then the value of sendTrustAnchorSpinLock will have changed and the creation will fail as it will be specifying an incorrect value for sendTrustAnchorSpinLock. It is suggested, but not required, that the sendTrustAnchorSpinLock be the first var bind for each set of objects representing a 'row' in a PDU." ::= { send 14 } sendTrustAnchorTable OBJECT-TYPE SYNTAX SEQUENCE OF SendTrustAnchorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The list of allowed trust anchors that are used for validating the authority of the Certification Path of a remote node. Entries can be created to configure new anchors. Anchor entries can also be deleted. Invalid certificates (with incorrect syntax) MUST NOT appear as an entry in the sendTrustAnchorTable. A managed element MUST check for the validity of the information provided for the creation of a new row, and if inconsistency is determined, the management protocol set operation MUST fail with an error of `inconsistentValue`. Note that the removal of entries in this table results in the deletion of all the certificates belonging to Certification Paths rooted in this anchor. Garcia-Martinez Expires January 5, 2009 [Page 14]
Internet-Draft SEND MIB July 2008 If SEND has been enabled in a host, it should have at least one anchor. Therefore, the last entry in the table can only be deleted if the sendEnableStatus object value is set to sendDisabled." REFERENCE "RFC 3971 : 6.5" ::= { send 15 } sendTrustAnchorEntry OBJECT-TYPE SYNTAX SendTrustAnchorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The certificate corresponding to an anchor." INDEX { sendTrustAnchorIndex } ::= { sendTrustAnchorTable 1 } SendTrustAnchorEntry ::= SEQUENCE { sendTrustAnchorIndex SendCertificateIndex, sendTrustAnchorCert SendX509ASN1DEREncodedRouterAuthCert, sendTrustAnchorAdminStatus INTEGER, sendTrustAnchorOperStatus INTEGER, sendTrustAnchorRowStatus RowStatus, sendTrustAnchorStorageType StorageType } sendTrustAnchorIndex OBJECT-TYPE SYNTAX SendCertificateIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each trust anchor. The management station MUST select a pseudo-random number to use as the index. In the event that this index was already in use and an 'inconsistentValue' was returned in response to the management protocol set operation, the management station SHOULD select a new pseudo-random number and retry the operation. The value of the sendTrustAnchorIndex for each trust anchor must remain constant at least from one re- initialization of the entity's network management system to the next re- initialization." ::= { sendTrustAnchorEntry 1 } sendTrustAnchorCert OBJECT-TYPE SYNTAX SendX509ASN1DEREncodedRouterAuthCert MAX-ACCESS read-create Garcia-Martinez Expires January 5, 2009 [Page 15]
Internet-Draft SEND MIB July 2008 STATUS current DESCRIPTION "Variable-length field containing the trust anchor certificate information." ::= { sendTrustAnchorEntry 2 } sendTrustAnchorAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the trust anchor of this entry. When set to enabled(1), the administrator requires the trust anchor to be available for validating the authority of Certification Paths. Conversely, when set to disabled, the administrator requires the anchor not to be available for validating the authority of Certification Paths." DEFVAL { disabled } ::= { sendTrustAnchorEntry 3 } sendTrustAnchorOperStatus OBJECT-TYPE SYNTAX INTEGER { validAndEnabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the anchor trust. The value validAndEnabled(1) indicates that this entry is both valid (i.e. with correct syntax for the trust anchor certificate) and operational (i.e. avaliable for validating the authority of a certificate). The value disabled(2) indicates that the entry is not operational (i.e. it is not available for validating the authority of a certificate)." ::= { sendTrustAnchorEntry 4} sendTrustAnchorRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The value of this object has no effect on whether other objects in this conceptual row can be modified. Garcia-Martinez Expires January 5, 2009 [Page 16]
Internet-Draft SEND MIB July 2008 A conceptual row can not be made active until the sendTrustAnchorIndex and sendTrustAnchorCert have been set to a valid value." ::= { sendTrustAnchorEntry 5 } sendTrustAnchorStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. If this object has a value of 'permanent', then no other objects are required to be able to be modified." DEFVAL { volatile } ::= { sendTrustAnchorEntry 6 } -- -- table of the certificates that constitute a Certification Path -- received from a remote router -- sendRemoteCertTable OBJECT-TYPE SYNTAX SEQUENCE OF SendRemoteCertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of standard Public Key Certificates (PKC, in the sense of [RFC3280]). Each certificate belongs to a Certification Path received from a remote router, i.e. either has been certified by a trust anchor or by a parent certificate. Certificates being certified by a trust anchor certificate contain a RowPointer element that points to the parent entry in the sendTrustAnchorTable (note that there MAY be multiple certificates issued by a single trust anchor). Certificates being signed by another certificate in the table contain a RowPointer element that points to the parent certificate in this table, to reflect the dependencies of the certificates forming a Certification Path. The agent populates the entries in this table with the information being received from Certification Path Advertisement messages. Only verified certificates, i.e. certificates verified to the trust anchor or to a certificate that has been verified earlier (i.e. that validly belongs to a Certification Path), are included in the table. Garcia-Martinez Expires January 5, 2009 [Page 17]
Internet-Draft SEND MIB July 2008 Entries in this table can be removed as a result of the normal operation of SEND. Additionally, the deletion of an anchor on which a Certification Path is rooted must result in the deletion of all the certificates of the Certification Path. In the period since the certificate has been verified to the time at which it is possible to check the information obtained from the Certificate Revocation List, the sendRemoteCertStatus object indicates that the certificate is provisional(1). The node can delete entries if the periodic Certificate Revocation List check fails (either in the provisional or in the valid states). In this case, all certificates depending on the revoked one MUST be deleted." REFERENCE "RFC 3971 : 6.4.2, RFC 3971 : 6.4.6" ::= { send 16 } sendRemoteCertEntry OBJECT-TYPE SYNTAX SendRemoteCertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information related with a particular certificate" INDEX { sendRemoteCertIndex } ::= { sendRemoteCertTable 1 } SendRemoteCertEntry ::= SEQUENCE { sendRemoteCertIndex SendCertificateIndex, sendRemoteCertCert SendX509ASN1DEREncodedRouterAuthCert, sendRemoteCertAnchor RowPointer, sendRemoteCertParentCertificate RowPointer, sendRemoteCertStatus INTEGER } sendRemoteCertIndex OBJECT-TYPE SYNTAX SendCertificateIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each certificate. The management station MUST select a pseudo-random number to use as the index. In the event that this index was already in use and an 'inconsistentValue' was returned in response to the management protocol set operation, the management station SHOULD select a new pseudo-random number and retry the operation. Garcia-Martinez Expires January 5, 2009 [Page 18]
Internet-Draft SEND MIB July 2008 The value of the sendTrustAnchorIndex for each certificate must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { sendRemoteCertEntry 1 } sendRemoteCertCert OBJECT-TYPE SYNTAX SendX509ASN1DEREncodedRouterAuthCert MAX-ACCESS read-only STATUS current DESCRIPTION "Variable-length field containing the certificate information." ::= { sendRemoteCertEntry 2 } sendRemoteCertAnchor OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "For the first certificate of a Certification Path, this object points to the row of the sendTrustAnchorTable of the anchor that certifies this certificate. For certificates other than the first of a Certification Path it contains a value of { 0 0 }." ::= { sendRemoteCertEntry 3 } sendRemoteCertParentCertificate OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "For the first certificate of a Certification Path, this object contains a value of { 0 0 } For certificates other than the first of a Certification Path, the object points to the parent certificate entry." ::= { sendRemoteCertEntry 4 } sendRemoteCertStatus OBJECT-TYPE SYNTAX INTEGER { provisional(1), valid(2) } MAX-ACCESS read-only STATUS current DESCRIPTION Garcia-Martinez Expires January 5, 2009 [Page 19]
Internet-Draft SEND MIB July 2008 "The status of the certificate. A certificate can be used in a provisional(1) state if a Certificate Revocation List check has not been performed due to the lack of connection to internet. After validating the certificate in the CRL, the certificate status is changed to valid(2). Note that if subsequent checks to the CRL result in invalidation of the certificate, the certificate is removed from the table, so no state is required for this case." REFERENCE "RFC 3971 : section 6.3.1" ::= { sendRemoteCertEntry 5 } -- -- compatibility with non-SEND devices -- sendCompatibilityStatus OBJECT-TYPE SYNTAX INTEGER { sendSecuredMsgs(1), sendAndReceiveUnsecuredMsgs(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object partially controls the security of ND messages send or accepted by a node, in a system-wide basis. The sendInterfaceNonSendCompatTable table complements the configuration capabilities for the SEND security behavior. If the value of the sendAdminStatus is set to sendSecuredMsgs(1), the administrator requires the system to protect all messaged sent with SEND. The behavior on the reception of unsecured messages for each interface is determined in the sendInterfaceNonSendCompatTable, in a configuration that is specific for each interface. If the value of the sendAdminStatus is set to sendAndReceiveUnsecuredMsgs, the administrator requires all interfaces of the system to send unsecured ND messages and accept unsecured messages from all nodes. In this case it is not relevant the value of the sendInterfaceNonSendCompatTable. This configuration can be used to ease transition from unsecured to secured environments Note that the behavior of SEND depends also on the value of the entry corresponding to the same interface in the sendInterfaceOperTable. If the interface does not have the configuration required by SEND to operate, setting the sendCompatibilityStatus object to sendSecuredMsgs(1) will result in the inability of the interface to process ND Garcia-Martinez Expires January 5, 2009 [Page 20]
Internet-Draft SEND MIB July 2008 messages. If this object is implemented in a MIB, the sendInterfaceNonSendCompatTable must also exist on it." REFERENCE "RFC 3971 : section 8, RFC 3971 : 6.5" DEFVAL { sendSecuredMsgs } ::= { send 17 } sendInterfaceNonSendCompatTable OBJECT-TYPE SYNTAX SEQUENCE OF SendInterfaceNonSendCompatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains per-interface specific SEND security configuration to manage the acceptance on each interface of unsecured messages." ::= { send 18 } sendInterfaceNonSendCompatEntry OBJECT-TYPE SYNTAX SendInterfaceNonSendCompatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration for accepting or not unsecured messages in a specific interface." INDEX { sendInterfaceNonSendCompatIfIndex } ::= { sendInterfaceNonSendCompatTable 1 } SendInterfaceNonSendCompatEntry ::= SEQUENCE { sendInterfaceNonSendCompatIfIndex InterfaceIndex, sendInterfaceNonSendCompatAcceptUnsecured INTEGER } sendInterfaceNonSendCompatIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { sendInterfaceNonSendCompatEntry 1 } sendInterfaceNonSendCompatAcceptUnsecured OBJECT-TYPE SYNTAX INTEGER { acceptSecuredAndUnsecured(1), Garcia-Martinez Expires January 5, 2009 [Page 21]
Internet-Draft SEND MIB July 2008 acceptOnlySecured(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This columnar object indicates whether the node accepts or not unsecured messages in a given link. When its value is acceptSecuredAndUnsecured(1), both secured and unsecured messages are processed, while when its value is acceptOnlySecured(2) unsecured messages are ignored. The acceptance of unsecured messages is allowed to ease transition from unsecured to secured links. Note that the behavior of SEND depends also on the value of the entry corresponding to the same interface in the sendInterfaceOperTable. If the interface does not have the configuration required by SEND to operate, setting the sendInterfaceNonSendCompatAcceptUnsecured object to acceptOnlySecured(2) will result in the inability of the interface to process ND messages." REFERENCE "RFC 3971 : section 8" DEFVAL { acceptOnlySecured } ::= { sendInterfaceNonSendCompatEntry 2 } -- -- Compatibility with non-SEND devices: security status of ND related -- information -- -- -- Augmentation of tables at RFC 4293 to indicate whether the -- information included in an entry in the -- ipAddressPrefixTable, ipDefaultRouterTable, ipNetToPhysicalTable and -- part of the information of inetCidrRouteTable has been secured or not -- -- augmentation of IP-MIB:ipAddressPrefixTable sendIpAddressPrefixSecuredTable OBJECT-TYPE SYNTAX SEQUENCE OF SendIpAddressPrefixSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains one column indicating if each entry in the ipAddressPrefixTable (RFC 4293) is secured or not. An entry in the ipAddressPrefixTable is secured if the last message of the Router Advertisement message that caused the creation or last update of the entry was Garcia-Martinez Expires January 5, 2009 [Page 22]
Internet-Draft SEND MIB July 2008 secured. An entry in ipAddressPrefixEntry is unsecured otherwise. This table contains one row for every address prefix entry on the node. This table augments the basic address prefix information of the ipAddressPrefixEntry in the IP-MIB. If an entry in the ipAddressPrefixTable is deleted, the corresponding entry in the sendIpAddressPrefixSecuredTable must be deleted. This table SHOULD only exist in the managed node if the value of the sendInterfaceNonSendCompatAcceptUnsecured columnar object is acceptSecuredAndUnsecured(1) for at least one of the interfaces. Otherwise, all the interfaces accept only secured ND messages." REFERENCE "RFC 3971: section 8, ipAddressPrefixEntry is defined in the IP-MIB [RFC4293]." ::= { send 20 } sendIpAddressPrefixSecuredEntry OBJECT-TYPE SYNTAX SendIpAddressPrefixSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of the sendIpAddressSecuredTable. Each row is for an address prefix. This table augments the ipAddressPrefixTable, i.e., every entry in this table has a one-to-one correspondence with an entry in the ipAddressPrefixTable." AUGMENTS { ipAddressPrefixEntry} ::= { sendIpAddressPrefixSecuredTable 1 } SendIpAddressPrefixSecuredEntry ::= SEQUENCE { sendIpAddressPrefixSecuredStatus SendSecurityStatus } sendIpAddressPrefixSecuredStatus OBJECT-TYPE SYNTAX SendSecurityStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates if its corresponding entry in the ipAddressPrefixTable is secured (if the last Router Advertisement message that caused the creation or last update of the entry was secured by SEND) or not." ::= { sendIpAddressPrefixSecuredEntry 1 } -- augmentation of IP-MIB:ipDefaulRouterTable Garcia-Martinez Expires January 5, 2009 [Page 23]
Internet-Draft SEND MIB July 2008 sendIpDefaultRouterSecuredTable OBJECT-TYPE SYNTAX SEQUENCE OF SendIpDefaultRouterSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains one column indicating if each entry in the ipDefaultRouterTable (RFC 4293) is secured or not. An entry in ipDefaultRouterTable is secured if the last message of the Router Advertisement message that caused the creation or last update of the entry was secured. An entry in ipDefaultRouterEntry is unsecured otherwise. This table contains one row for every address prefix entry on the node. This table augments the basic address prefix information of the ipDefaultRouterEntry in the IP-MIB. If an entry in the ipDefaultRouterTable is deleted, the corresponding entry in the sendIpDefaultRouterSecuredTable must be deleted. This table SHOULD only exist in the managed node if the value of the sendInterfaceNonSendCompatAcceptUnsecured columnar object is acceptSecuredAndUnsecured(1) for at least one of the interfaces. Otherwise, all the interfaces accept only secured ND messages." REFERENCE "RFC 3971 : section 8 ipDefaultRouterEntry is defined in the IP-MIB [RFC4293]." ::= { send 21 } sendIpDefaultRouterSecuredEntry OBJECT-TYPE SYNTAX SendIpDefaultRouterSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of the sendIpDefaultRouterSecuredTable. Each row is for a default router. This table augments the ipDefaultRouterTable, i.e., every entry in this table has a one-to-one correspondence with an entry in the ipDefaultRouterTable." AUGMENTS { ipDefaultRouterEntry} ::= { sendIpDefaultRouterSecuredTable 1} SendIpDefaultRouterSecuredEntry ::= SEQUENCE { sendIpDefaultRouterSecuredStatus SendSecurityStatus } sendIpDefaultRouterSecuredStatus OBJECT-TYPE SYNTAX SendSecurityStatus Garcia-Martinez Expires January 5, 2009 [Page 24]
Internet-Draft SEND MIB July 2008 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates if its corresponding entry in the ipDefaultRouterTable is secured (if the last Router Advertisement message that caused the creation or last update of the entry was secured by SEND) or not." ::= { sendIpDefaultRouterSecuredEntry 1 } -- augmentation of neighbor cache, i.e. IP-MIB:ipNetToPhysicalTable sendIpNetToPhysicalSecuredTable OBJECT-TYPE SYNTAX SEQUENCE OF SendIpNetToPhysicalSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains one column indicating if each entry in the ipNetToPhysicalTable (RFC 4293) is secured or not. An entry in ipNetToPhysicalTable is secured if the last Neighbor Advertisement message that caused the creation or last update of the entry was secured. An entry in ipNetToPhysicalEntry is unsecured otherwise. This table contains one row for every address prefix entry on the node. This table augments the basic address prefix information of the ipNetToPhysicalEntry in the IP-MIB. If an entry in the ipNetToPhysicalTable is deleted, the corresponding entry in the sendIpNetToPhysicalSecuredTable must be deleted. This table SHOULD only exist in the managed node if the value of the sendInterfaceNonSendCompatAcceptUnsecured columnar object is acceptSecuredAndUnsecured(1) for at least one of the interfaces. Otherwise, all the interfaces accept only secured ND messages." REFERENCE "RFC 3971 : section 8 ipNetToPhysicalEntry is defined in the IP-MIB [RFC4293]." ::= { send 22 } sendIpNetToPhysicalSecuredEntry OBJECT-TYPE SYNTAX SendIpNetToPhysicalSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of the sendIpNetToPhysicalSecuredTable. Each row is for a neighbor. This table augments the ipNetToPhysicalTable, i.e., every entry in this table has a one-to-one correspondence with an entry in the ipNetToPhysicalTable." Garcia-Martinez Expires January 5, 2009 [Page 25]
Internet-Draft SEND MIB July 2008 AUGMENTS { ipNetToPhysicalEntry } ::= { sendIpNetToPhysicalSecuredTable 1 } SendIpNetToPhysicalSecuredEntry ::= SEQUENCE { sendIpNetToPhysicalSecuredStatus SendSecurityStatus } sendIpNetToPhysicalSecuredStatus OBJECT-TYPE SYNTAX SendSecurityStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates if its corresponding entry in the ipNetToPhysicalTable is secured (if the last ND message that caused the creation or last update of the entry was secured by SEND)." ::= { sendIpNetToPhysicalSecuredEntry 1 } -- Extension of IP-FORWARDING-MIB:inetCidrRouteTable sendInetCidrRouteSecuredTable OBJECT-TYPE SYNTAX SEQUENCE OF SendInetCidrRouteSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains one column to indicate if an inetCidrRouteTable (RFC 4292) entry that has been created or modified due to a Redirect message is secured. Entries for sendInetCidrRouteSecuredTable are only populated for index values equal to the ones of the entries of the inetCidrRouteTable that has been created or last modified by the reception of a Redirect message. These entries in the inetCidrRouteTable must have a inetCidrRouteType value of local(4), indicating that the next hop is the final destination. Therefore, not all entries in the inetCidrRouteTable may have a corresponding entry in this table. If an entry in the inetCidrRouteTable is deleted, the corresponding entry in the sendInetCidrRouteSecuredTable must be deleted. This table SHOULD only exist in the managed node if the value of the sendInterfaceNonSendCompatAcceptUnsecured columnar object is acceptSecuredAndUnsecured(1) for at least one of the interfaces. Otherwise, all the interfaces accept only secured ND messages." Garcia-Martinez Expires January 5, 2009 [Page 26]
Internet-Draft SEND MIB July 2008 REFERENCE "ipNetToPhysicalEntry is defined in the IP-FORWARD-MIB [RFC4292]." ::= { send 23 } sendInetCidrRouteSecuredEntry OBJECT-TYPE SYNTAX SendInetCidrRouteSecuredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of the sendInetCidrRouteSecuredTable. This table extends the inetCidrRouteTable, i.e., every entry in this table has a one-to-one correspondence with an entry in the inetCidrRouteTable." INDEX { inetCidrRouteDestType, inetCidrRouteDest, inetCidrRoutePfxLen, inetCidrRoutePolicy, inetCidrRouteNextHopType, inetCidrRouteNextHop } ::= { sendInetCidrRouteSecuredTable 1 } SendInetCidrRouteSecuredEntry ::= SEQUENCE { sendInetCidrRouteSecuredStatus SendSecurityStatus } sendInetCidrRouteSecuredStatus OBJECT-TYPE SYNTAX SendSecurityStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates if its corresponding entry in the inetCidrRouteTable is secured (if the last Redirect message that caused the creation or last update of the entry was secured by SEND)." ::= { sendInetCidrRouteSecuredEntry 1 } sendIgnoreUnsecuredDadFirstTentative OBJECT-TYPE SYNTAX INTEGER { acceptUnsecuredDadFirstTentative(1), ignoreUnsecuredDadFirstTentative(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "For all the interfaces of the node for which secure operation is required, this object specifies whether the node accepts or ignores unsecured advertisements received when performing Duplicate Address Detection for the first CGA tentative address. sendIgnoreUnsecuredDadFirstTentative can be configured to ignoreUnsecuredDadFirstTentative(2) as a recovery Garcia-Martinez Expires January 5, 2009 [Page 27]
Internet-Draft SEND MIB July 2008 mechanisms for cases in which attacks against the first address become common. Note that for the second and third tentative addresses, only secured advertisements are considered." REFERENCE "RFC 3971 : section 8" DEFVAL { acceptUnsecuredDadFirstTentative } ::= { send 24 } -- -- SEND statistics -- sendStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SendStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics related to Neighbor Discovery and SEND operation. Statistics are provided in a per-interface basis to allow better insight about in which links attacks are occurring." ::= { send 25 } sendStatsEntry OBJECT-TYPE SYNTAX SendStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the sendStatsTable." INDEX { sendStatsIfIndex } ::= { sendStatsTable 1 } SendStatsEntry ::= SEQUENCE { sendStatsIfIndex InterfaceIndex, sendStatsInNDMsgs Counter32, sendStatsInNDSecuredValidMsgs Counter32, sendStatsInNDSecuredInvalidMsgs Counter32, sendStatsInNDUnsecuredMsgs Counter32, sendStatsInNDErrors Counter32, sendStatsInCertMsgs Counter32, sendStatsInCertVerifiedMsgs Counter32, sendStatsInCertFailedMsgs Counter32, sendStatsInCertErrors Counter32, sendStatsOutNDMsgs Counter32, sendStatsOutNDSecuredMsgs Counter32, Garcia-Martinez Expires January 5, 2009 [Page 28]
Internet-Draft SEND MIB July 2008 sendStatsOutNDSecuredErrors Counter32, sendStatsOutCertMsgs Counter32, sendStatsOutCertErrors Counter32 } sendStatsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { sendStatsEntry 1 } sendStatsInNDMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ND messages (Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisements and Redirects) that the entity received. Note that this counter includes all the messages counted by sendStatsInNDErrors." ::= { sendStatsEntry 2 } sendStatsInNDSecuredValidMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ND messages that were both secured and successfully validated according to the rules specified in RFC 3971. Note that many requirements are involved: the messages included the SEND security information appropriate to its type, the receiver must have SEND enabled in the link (with the required configuration), the authorization method must fit to the type of options received so that the minimum options required to be considered as secure are validated, the receiver must have the appropriate keying information to validate the options, and finally, the verification is successful. To be considered as secured, Neighbor Solicitation and Advertisement messages must include at least a valid CGA option. Neighbor Solicitation, Neighbor Advertisement, Garcia-Martinez Expires January 5, 2009 [Page 29]
Internet-Draft SEND MIB July 2008 Router Advertisement, Redirect and Router Solicitation with source addresses different to the unspecified address, must include at least a valid RSA Signature option. Supersets of these combinations (e.g. a Router Advertisement containing both a RSA Signature option and a CGA option) are considered secured if the processing performed by the node, according to the authorization methods configured, is successful for all the authorization options." REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2" ::= { sendStatsEntry 3 } sendStatsInNDSecuredInvalidMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ND messages that contained any kind of SEND security information, but were not successfully validated according to the rules specified in RFC 3971. Note that these messages may be further processed by the node as unsecured messages, depending on the configuration of the node." REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2" ::= { sendStatsEntry 4 } sendStatsInNDUnsecuredMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ND messages received that did not contain any security information defined in SEND." ::= { sendStatsEntry 5 } sendStatsInNDErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ND messages received that the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, bad format, etc.). Note that it does not include the messages counted by sendStatsInNDUnsecuredMsgs." ::= { sendStatsEntry 6 } sendStatsInCertMsgs OBJECT-TYPE Garcia-Martinez Expires January 5, 2009 [Page 30]
Internet-Draft SEND MIB July 2008 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Certification Path Solicitation and Certification Path Advertisement messages received by the entity." ::= { sendStatsEntry 7 } sendStatsInCertVerifiedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Certification Path Advertisement messages received by a host that it could verify according to the verification procedure defined in section 6.3 of RFC 3971." ::= { sendStatsEntry 8 } sendStatsInCertFailedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Certification Path Advertisement messages received by a host that it could not verify successfully, according to the verification procedure defined in section 6.3 of RFC 3971. It does not include messages counted by sendStatsInCertErrors." REFERENCE "RFC 3971 : section 6.3" ::= { sendStatsEntry 9 } sendStatsInCertErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of of Certification Path Solicitation and Certification Path Advertisement messages that the entity received but were determined as having ICMP-specific errors (bad ICMP checksums, bad length, bad format, etc.). Note that it does not include the messages counted by sendStatsInCertFailedMessages." ::= { sendStatsEntry 10 } sendStatsOutNDMsgs OBJECT-TYPE Garcia-Martinez Expires January 5, 2009 [Page 31]
Internet-Draft SEND MIB July 2008 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ND messages that the entity attempted to send. Note that this counter includes all those counted by sendStatsOutNDSecuredErrors." ::= { sendStatsEntry 11 } sendStatsOutNDSecuredMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ND messages attempted to send by the entity that were secured. To be considered as secured, Neighbor Solicitation and Advertisement messages must include at least a valid CGA option. Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, Redirect and Router Solicitation with source addresses different to the unspecified address, must include at least a valid RSA Signature option." REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2" ::= { sendStatsEntry 12 } sendStatsOutNDSecuredErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ND messages attempted to send by the entity, that were secured, that this entity did not send due to problems discovered within ICMP, such as a lack of buffers. This value should not include errors discovered outside the ICMP layer, such as the inability of IP to route the resultant datagram. In some implementations, there may be no types of error that contribute to this counter's value." ::= { sendStatsEntry 13 } sendStatsOutCertMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Certification Path Solicitation and Certification Path Advertisement messages attempted to send by the entity. Note that this counter includes Garcia-Martinez Expires January 5, 2009 [Page 32]
Internet-Draft SEND MIB July 2008 all those counted by sendStatsOutCertErrors" ::= { sendStatsEntry 14 } sendStatsOutCertErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Certification Path Solicitation and Certification Path Advertisement messages attempted to send by the entity that it did not send due to problems discovered within ICMP, such as a lack of buffers. This value should not include errors discovered outside the ICMP layer, such as the inability of IP to route the resultant datagram. In some implementations, there may be no types of error that contribute to this counter's value." ::= { sendStatsEntry 15 } -- -- conformance information -- sendMIBConformance OBJECT IDENTIFIER ::= { sendMIB 2 } sendMIBCompliances OBJECT IDENTIFIER ::= { sendMIBConformance 1 } sendMIBGroups OBJECT IDENTIFIER ::= { sendMIBConformance 2 } -- compliance statement #1 sendMIBCompatibleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for an agent that supports compatible operation with non-SEND devices, and it is fully configurable (read-create access for the sendTrustAnchorGroup, and read-write access for all writable objects)." MODULE -- this module MANDATORY-GROUPS { sendInterfaceOperStatusGroup, sendAuthorityGroup, sendTimestampGroup, sendTrustAnchorGroup, sendRemoteCertGroup, sendCompatibilityStatusGroup, sendInterfaceNonSendCompatGroup, Garcia-Martinez Expires January 5, 2009 [Page 33]
Internet-Draft SEND MIB July 2008 sendIgnoreUnsecuredDadFirstTentativeGroup, sendIpAddressPrefixSecuredGroup, sendIpDefaultRouterSecuredGroup, sendIpNetToPhysicalSecuredGroup, sendInetCidrRouteSecuredGroup, sendStatsGroup } OBJECT sendTrustAnchorRowStatus SYNTAX RowStatus { active(1), notInService (2) } WRITE-SYNTAX RowStatus { active(1), notInService (2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait is not required." ::= { sendMIBCompliances 1 } -- compliance statement #2 sendMIBOnlySendCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for an agent that does not support compatible operation with non-SEND devices and it is fully configurable (read-create access for the sendTrustAnchorGroup, and read-write access for all writable objects)." MODULE -- this module MANDATORY-GROUPS { sendInterfaceOperStatusGroup, sendAuthorityGroup, sendTimestampGroup, sendTrustAnchorGroup, sendRemoteCertGroup, sendStatsGroup } OBJECT sendTrustAnchorRowStatus SYNTAX RowStatus { active(1), notInService (2) } WRITE-SYNTAX RowStatus { active(1), notInService (2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait is not required." ::= { sendMIBCompliances 2 } -- compliance statement #3 sendMIBCompatibleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for an agent that supports compatible operation with non-SEND devices, but it is implemented without support for the creation of rows in the sendTrustAnchorGroup, and with read-only access for Garcia-Martinez Expires January 5, 2009 [Page 34]
Internet-Draft SEND MIB July 2008 the remaining writable objects." MODULE -- this module MANDATORY-GROUPS { sendInterfaceOperStatusGroup, sendAuthorityGroup, sendTimestampGroup, sendTrustAnchorReadOnlyGroup, sendRemoteCertGroup, sendCompatibilityStatusGroup, sendInterfaceNonSendCompatGroup, sendIgnoreUnsecuredDadFirstTentativeGroup, sendIpAddressPrefixSecuredGroup, sendIpDefaultRouterSecuredGroup, sendIpNetToPhysicalSecuredGroup, sendInetCidrRouteSecuredGroup, sendStatsGroup } OBJECT sendRsaWithCgaAuthorization MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendCpaRequireIPAddressExt MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendCgaVerificationMinbits MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendCgaVerificationMaxbits MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodNS MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." Garcia-Martinez Expires January 5, 2009 [Page 35]
Internet-Draft SEND MIB July 2008 OBJECT sendRsaVerificationMethodNA MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodRS MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodRA MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodRedirect MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTimestampDelta MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTimestampFuzz MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTimestampDrift MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTrustAnchorSpinLock MIN-ACCESS not-accessible DESCRIPTION Garcia-Martinez Expires January 5, 2009 [Page 36]
Internet-Draft SEND MIB July 2008 "An agent is not required to provide write access to this object. However, if an agent provides write access to any of the other objects in the sendTrustAnchorGroup, it SHOULD provide write access to this object as well." OBJECT sendTrustAnchorCert MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTrustAnchorAdminStatus MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT sendTrustAnchorRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object. In this case, the only value permitted is active(1)." OBJECT sendTrustAnchorStorageType MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object. If an agent allows this object to be written or created, it is not required to allow this object to be set to readOnly, permanent, or nonVolatile." OBJECT sendCompatibilityStatus MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendInterfaceNonSendCompatAcceptUnsecured MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendIgnoreUnsecuredDadFirstTentative Garcia-Martinez Expires January 5, 2009 [Page 37]
Internet-Draft SEND MIB July 2008 MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." ::= { sendMIBCompliances 3 } -- compliance statement #4 sendMIBOnlySendReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for an agent that supports compatible operation with non-SEND devices, but it is implemented without support for read-create (i.e., in read-only mode)." MODULE -- this module MANDATORY-GROUPS { sendInterfaceOperStatusGroup, sendAuthorityGroup, sendTimestampGroup, sendTrustAnchorReadOnlyGroup, sendRemoteCertGroup, sendStatsGroup } OBJECT sendRsaWithCgaAuthorization MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendCpaRequireIPAddressExt MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendCgaVerificationMinbits MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendCgaVerificationMaxbits MIN-ACCESS read-only DESCRIPTION Garcia-Martinez Expires January 5, 2009 [Page 38]
Internet-Draft SEND MIB July 2008 "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodNS MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodNA MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodRS MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodRA MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendRsaVerificationMethodRedirect MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTimestampDelta MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTimestampFuzz MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTimestampDrift Garcia-Martinez Expires January 5, 2009 [Page 39]
Internet-Draft SEND MIB July 2008 MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTrustAnchorSpinLock MIN-ACCESS not-accessible DESCRIPTION "An agent is not required to provide write access to this object. However, if an agent provides write access to any of the other objects in the sendTrustAnchorGroup, it SHOULD provide write access to this object as well." OBJECT sendTrustAnchorCert MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT sendTrustAnchorRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT sendTrustAnchorStorageType MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object. If an agent allows this object to be written or created, it is not required to allow this object to be set to readOnly, permanent, or nonVolatile." ::= { sendMIBCompliances 4 } -- Units of conformance sendInterfaceOperStatusGroup OBJECT-GROUP OBJECTS { sendInterfaceOperStatus } STATUS current DESCRIPTION "The group of objects that indicates if sufficient configuration exists to make SEND operational for each interface." ::= { sendMIBGroups 1 } sendAuthorityGroup OBJECT-GROUP Garcia-Martinez Expires January 5, 2009 [Page 40]
Internet-Draft SEND MIB July 2008 OBJECTS { sendRsaWithCgaAuthorization, sendCpaRequireIPAddressExt, sendCgaVerificationMinbits, sendCgaVerificationMaxbits, sendRsaVerificationMethodNS, sendRsaVerificationMethodNA, sendRsaVerificationMethodRS, sendRsaVerificationMethodRA, sendRsaVerificationMethodRedirect } STATUS current DESCRIPTION "Objects controlling SEND authority attestation and verification processes. These objects manage the authority information that is included in SENDpackets being sent, and the checks that are applied to incoming SENDauthority information." ::= { sendMIBGroups 2 } sendTimestampGroup OBJECT-GROUP OBJECTS { sendTimestampDelta, sendTimestampFuzz, sendTimestampDrift } STATUS current DESCRIPTION "The objects that control the verification of the Timestamp option to provide anti-reply protection" ::= { sendMIBGroups 3 } sendTrustAnchorGroup OBJECT-GROUP OBJECTS { sendTrustAnchorSpinLock, sendTrustAnchorCert, sendTrustAnchorAdminStatus, sendTrustAnchorOperStatus, sendTrustAnchorRowStatus, sendTrustAnchorStorageType } STATUS current DESCRIPTION "The group of objects for managing the anchors that are used for validating the authority of the Certification Path of a remote node." ::= { sendMIBGroups 4 } sendTrustAnchorReadOnlyGroup OBJECT-GROUP Garcia-Martinez Expires January 5, 2009 [Page 41]
Internet-Draft SEND MIB July 2008 OBJECTS { sendTrustAnchorSpinLock, sendTrustAnchorCert, sendTrustAnchorAdminStatus, sendTrustAnchorOperStatus, sendTrustAnchorRowStatus, sendTrustAnchorStorageType } STATUS current DESCRIPTION "The group of objects for managing the anchors that are used for validating the authority of the Certification Path of a remote node." ::= { sendMIBGroups 5 } sendRemoteCertGroup OBJECT-GROUP OBJECTS { sendRemoteCertCert, sendRemoteCertAnchor, sendRemoteCertParentCertificate, sendRemoteCertStatus } STATUS current DESCRIPTION "The group of objects for storing the certificates that belong to a Certification Path received from a remote router." ::= { sendMIBGroups 6 } sendCompatibilityStatusGroup OBJECT-GROUP OBJECTS { sendCompatibilityStatus } STATUS current DESCRIPTION "The group of objects to enable or disable SEND operation." ::= { sendMIBGroups 7 } sendInterfaceNonSendCompatGroup OBJECT-GROUP OBJECTS { sendInterfaceNonSendCompatAcceptUnsecured } STATUS current DESCRIPTION "The group of objects to configure the acceptance of unsecured messages in a per-interface basis. When this group is not deplyed, full SEND operation is assumed for the system (i.e. all the interfaces generate ND secured messages and only process ND secured messages." Garcia-Martinez Expires January 5, 2009 [Page 42]
Internet-Draft SEND MIB July 2008 ::= { sendMIBGroups 8 } sendIgnoreUnsecuredDadFirstTentativeGroup OBJECT-GROUP OBJECTS { sendIgnoreUnsecuredDadFirstTentative } STATUS current DESCRIPTION "The group of objects to configure the acceptance of unsecured advertisements received when performing Duplicate Address Detection for the first CGA tentative address." ::= { sendMIBGroups 9 } sendIpAddressPrefixSecuredGroup OBJECT-GROUP OBJECTS { sendIpAddressPrefixSecuredStatus } STATUS current DESCRIPTION "The group of objects that indicate if each entry in the ipAddressPrefixEntry (RFC 4293) is secured or not." ::= { sendMIBGroups 10 } sendIpDefaultRouterSecuredGroup OBJECT-GROUP OBJECTS { sendIpDefaultRouterSecuredStatus } STATUS current DESCRIPTION "The group of objects that indicate if each entry in the ipDefaultRouterEntry (RFC 4293) is secured or not." ::= { sendMIBGroups 11 } sendIpNetToPhysicalSecuredGroup OBJECT-GROUP OBJECTS { sendIpNetToPhysicalSecuredStatus } STATUS current DESCRIPTION "The group of objects that indicate if each entry in the ipNetToPhysicalTable (RFC 4293) is secured or not." ::= { sendMIBGroups 12 } sendInetCidrRouteSecuredGroup OBJECT-GROUP OBJECTS { sendInetCidrRouteSecuredStatus } STATUS current DESCRIPTION "The group of objects that indicate if each entry in the inetCidrRouteTable (RFC 4292) entry that has been created or modified due to a Redirect message is secured or not." ::= { sendMIBGroups 13 } sendStatsGroup OBJECT-GROUP Garcia-Martinez Expires January 5, 2009 [Page 43]
Internet-Draft SEND MIB July 2008 OBJECTS { sendStatsInNDMsgs, sendStatsInNDSecuredValidMsgs, sendStatsInNDSecuredInvalidMsgs, sendStatsInNDUnsecuredMsgs, sendStatsInNDErrors, sendStatsInCertMsgs, sendStatsInCertVerifiedMsgs, sendStatsInCertFailedMsgs, sendStatsInCertErrors, sendStatsOutNDMsgs, sendStatsOutNDSecuredMsgs, sendStatsOutNDSecuredErrors, sendStatsOutCertMsgs, sendStatsOutCertErrors } STATUS current DESCRIPTION "The group of statistics related to Neighbor Discovery and SEND operation." ::= { sendMIBGroups 14 } END 4. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in an unsecure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Improper configuration of SEND can result in the complete inability to process ND messages (either protected or not). If there is not trust anchor or a host does not have a CGA configured on each interface, in a way that the sendInterfaceOperTable is set to 'configurationRequired' for some interfaces, some combinations of values of the sendCompatibilityStatus or sendInterfaceNonSendCompatAcceptUnsecured can make ND operation impossible, even if unsecured messages are used. This occurs if the configuration requires the use of SEND either in sending (sendCompatibilityStatus has the value of sendSecuredMsgs(1)) or receving (sendInterfaceNonSendCompatEntry for this interface is set to acceptOnlySecured(2)), but the node has not the configuration required to operate in this way. Although this improper Garcia-Martinez Expires January 5, 2009 [Page 44]
Internet-Draft SEND MIB July 2008 configuration is not a security hazard on itself, security concerns may be raised by an attacker that both deletes relevant configuration of the node, so that it set the status of different interfaces to configurationRequired, and then it modifies the values of either the sendCompatibilityStatus object or sendInterfaceNonSendCompatEntry corresponding to the interface attacked in a way that it disables not only SEND operation, but also the exchange of unsecured ND messages in a way that was not intended by the administrator. sendRSAWithCgaAuthorization. Changing the value of the object sendRSAWithCgaAuthorization in a router from cgaNotUsed to cgaUsed may result in a lower protection for the node if the CGA authorization method is weakest than the protection provided by the Certification Path. Note that a valid CGA for the considered interface must exist. sendCpaRequireIPAddressExt. When X.509 certificates that do not contain 'addressesOrRanges' elements are allowed to be processed in the node receiving the certificate, by setting the sendCpaRequireIPAddressExt object to 'notRequiredAddressOrRange', it enables the propagation of unauthorized prefixes by the legitimate administrator of a site to which a public/private key pair has been delegated by a Certification Path method. sendCgaVerificationMinbits. Incrementing the value of the sendCgaVerificationMinbits object may result in a DOS attack, since some remote CGA would be unintendedly discarded because of being too short, if only secured ND messages are accepted by the node. Additionally, reducing the value of the sendCgaVerificationMinbits object may facilitate the key generation process for an attacker trying to impersonate a legitimate CGA of a third party by brute force. Short key length can also make the host to consider as secure communications that were established with hosts with keys so short that could be factorized. sendCgaVerificationMaxbits. On one hand, low values of the sendCgaVerificationMaxbits object can result in discarding messages secured with a CGA larger than the limit established in this object, resulting in a DOS attack. On the other hand, an attacker could set high values to defeat the purpose of this configurable parameter, i.e. protect against the high resource consumption of resources in the receiver of a signed message. sendRsaVerificationMethodNS, sendRsaVerificationMethodNA, sendRsaVerificationMethodRS, sendRsaVerificationMethodRA and sendRsaVerificationMethodRedirect. The modification of the authorization method used for validating any of the messages of the ND protocol by an attacker, through illegitimate modification of the Garcia-Martinez Expires January 5, 2009 [Page 45]
Internet-Draft SEND MIB July 2008 sendRsaVerificationMethodNS, sendRsaVerificationMethodNA, sendRsaVerificationMethodRS, sendRsaVerificationMethodRA, and sendRsaVerificationMethodRedirect can result in a DOS attack. The DOS attack occurs when the node is configured to require a type of authorization that it is not being used by the party generating the message. Additionally, variation of any of these objects may result in a lower protection if the method is changed from trustAnchorAndCga to the weakest authorization method, although any of the methods used by the generator of the message should provide enough protection. sendTimestampDelta, sendTimeFuzz and sendTimestampDrift. Incrementing the value of the objects sendTimestampDelta, sendTimeFuzz and sendTimestampDrift extends the vulnerability window for reply attacks. Section 9.2.5 of [RFC3971] discusses the impact of this action. On the other hand, setting low values to these three objects may result in a DOS attack, since valid SEND messages could be discarded by too tight validation constraints. sendTrustAnchorTable. The addition of an entry in the anchor table by an unauthorized party can be used to enable all kind of attacks for which SEND provides protection, with the aggravating circumstance that the node may consider that the information is secured. The deletion of a valid entry in the anchor table by an attacker can result in DOS, since the node does not consider validly secured information as legitimate. Read-only access should be implemented in nodes willing to prevent these attacks. sendCompatibilityStatus. Write access from an unauthorized party to disable SEND operation can be used to enable all kind of attacks for which SEND provides protection. Note that some of the attacks can also be performed by creating new entries in the RFC4292:: ipNetToPhysicalTable, in which the information relating remote IP addresses and link-layer addresses is stored. On the other hand, the RFC4292::ipAddressPrefixTable and RFC4292::defaultRouterTable were not exposed to these attacks due to the restriction of read-only access. In addition, changing the value of the object to sendAndReceiveUnsecuredMsgs may results in DOS in a SEND-only deployment scenario, since the node could not communicate with other nodes in the link that only accept secured ND messages. sendInterfaceNonSendCompatTable. Write access from an unauthorized party to disable SEND validation in a per-link basis can be used to enable all kind of attacks for which SEND provides protection. Additionally, if the value of the object is unintendedly changed from acceptSecuredAndUnsecured to acceptOnlySecured, the node will loose the communication with non-SEND devices in the link considered. sendIgnoreUnsecuredDadFirstTentative. As RFC 3971, section 9.2.3 Garcia-Martinez Expires January 5, 2009 [Page 46]
Internet-Draft SEND MIB July 2008 states, if the node state is maliciously changed to ignore unsecured Neighbor Advertisements when DAD is being performed, a potential address collision between a SEND node and a non-SEND node may occur. The probability and effects of such an address collision are discussed in [RFC3972]. On the other side, if the node is maliciously changed to accept unsecured Neighbor Advertisements as response to DAD, a node controlled by an attacker can force the generation of a second CGA even if no real collision occurred in the network. Since DAD for the second CGA generated will only process secured responses, regardless the state of this object, this change only impacts in performance. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: sendCgaVerificationMinbits. Read access to this object by an unauthorized node can provide information about the minimum key length to use in a brute force attack to a CGA. Read access to objects that specify the authorization policy of the node could provide information to an attacker, although the attacker could gain the same information by directly performing the attacks enabled by the actual configuration of the system (for example, sending unsecured messages without knowing if the node accepts them or not in a given interface. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate Garcia-Martinez Expires January 5, 2009 [Page 47]
Internet-Draft SEND MIB July 2008 rights to indeed GET or SET (change/create/delete) them. 5. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- send-MIB { mib-2 XXX } Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXX" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "XXX" (here and in the MIB module) with the assigned value and to remove this note. 6. References 6.1. Normative References [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet Garcia-Martinez Expires January 5, 2009 [Page 48]
Internet-Draft SEND MIB July 2008 X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006. [RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. 6.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [CGA-MIB] "Management Information Base for Cryptographically Generated Addresses (CGA)", July 2008. Author's Address Alberto Garcia-Martinez Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: alberto@it.uc3m.es URI: http://www.it.uc3m.es Garcia-Martinez Expires January 5, 2009 [Page 49]
Internet-Draft SEND MIB July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Garcia-Martinez Expires January 5, 2009 [Page 50]