Internet DRAFT - draft-garcia-martinez-sendmib
draft-garcia-martinez-sendmib
Individual Submission A. Garcia-Martinez
Internet-Draft M. Bagnulo
Intended status: Standards Track UC3M
Expires: March 15, 2013 September 11, 2012
Management Information Base for the SEcure Neighbor Discovery (SEND)
protocol
draft-garcia-martinez-sendmib-05
Abstract
This memo defines a portion of the Management Information Base (MIB)
for managing the SEND (SEcure Neighbor Discovery) Protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 15, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 1]
Internet-Draft SEND MIB September 2012
Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Normative References . . . . . . . . . . . . . . . . . . . 39
8.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 2]
Internet-Draft SEND MIB September 2012
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 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 the following elements
o Certification Path, anchored on trusted parties, which can be used
to certify the authority of the routers. A Certification Path can
be exchanged among routers and hosts by means of two ICMP
messages, the Certification Path Solicitation message and the
Certification Path Advertisement message.
o Cryptographically Generated Address (CGA) [RFC3972], an IPv6
address which can be used to prove address ownership
o RSA Signature option, which protects ND messages by using keying
material related to a Certification Path or a CGA.
SEND-MIB provides means to monitor and configure most of the elements
related with SEND operation in hosts. In particular, it allows
managing:
o Authority attestation and verification. The following objects are
related to authority verification management in the receiver:
* sendCgaVerificationMinbits and sendCgaVerificationMaxbits
objects specify respectively the minimum and maximum number of
bits that a key of a received CGA must have to be usable by
SEND.
* For each ND message type, a specific sendRsaVerificationMethod
object indicates 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-replay
protection for unsolicited advertisements and redirects are
managed through the discrete objects sendTimestampDelta,
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 3]
Internet-Draft SEND MIB September 2012
sendTimestampFuzz and sendTimestampDrift.
o Cryptographic information repository. Two tables store, after
proper validation, the cryptographic information required by SEND:
* 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 them.
* The sendCertTable stores the certificates received in
Certification Path Advertisement messages. This information is
stored as a linked list in order to reflect the dependencies of
the certificates to a trust anchor or to other certificates of
a Certification Path.
* The sendCgaLocalTable indicates which of the CGA addresses
available in the node (shown in a non-SEND specific table
defined in the CGA-MIB [I-D.garcia-martinez-cgamib]) can be
used for SEND operation.
o Compatibility with non-SEND devices. The sendAcceptUnsecured
object manages the acceptance of unsecured ND messages in a
system-wide basis. If unsecured ND messages are accepted, it is
useful to know which of the information received is secured. To
do so, three tables augment existing tables containing ND
information [RFC4293] 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 and
sendIpNetToPhysicalSecuredTable. Finally,
sendIgnoreUnsecuredDadFirstTentative controls DAD operation in
links shared with non-SEND devices.
o SEND statistics. System-wide objects show statistics accounting
for secured and unsecured messages, and messages with validation
errors, for both ND and Certification Path Advertisement messages.
Note that SEND-MIB depends on the implementation of the CGA-MIB
[I-D.garcia-martinez-cgamib] for some of its objects, so it requires
the CGA-MIB to exist in the managed system in which SEND-MIB is
implemented. SEND-MIB also complements the information of IP-MIB
tables[RFC4293].
SEND-MIB does not aim to manage SEND operation in routers, except for
configurations common to both routers and hosts. The approach taken
in this document is similar to that of IP-MIB [RFC4293], which does
not provide objects to manage the generation of Router Advertisement
messages, and in particular it does not provide means to manage
prefix options. In a similar way, SEND-MIB does not provide means to
manage the generation of Certification Path Advertisement, the
security configuration of Router Advertisement messages, or the
configuration of certification material in the routers. These
configuration capabilities are left for future specifications.
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 4]
Internet-Draft SEND MIB September 2012
3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. 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
ipAddressPrefixEntry, ipDefaultRouterEntry,
ipNetToPhysicalEntry FROM IP-MIB
cgaLocalEntry FROM CGA-MIB;
sendMIB MODULE-IDENTITY
LAST-UPDATED "201209100000Z"
ORGANIZATION "IETF"
CONTACT-INFO
"Editor:
Alberto Garcia-Martinez
U. Carlos III de Madrid
Avenida Universidad, 30
Leganes, Madrid 28911
Spain
Email: alberto.garcia@uc3m.es"
DESCRIPTION
"The MIB module for managing the SEND protocol.
Copyright (c) 2012 IETF Trust and the persons identified
as the document authors.
All rights reserved. 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
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 5]
Internet-Draft SEND MIB September 2012
REVISION "201209100000Z"
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 method 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 obtained 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 in this case it
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 in this case it 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."
REFERENCE "RFC 3971 : section 5.2.3"
SYNTAX INTEGER {
trustAnchor(1),
cga(2),
trustAnchorAndCga(3),
trustAnchorOrCga(4)
}
SendCertificateIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 6]
Internet-Draft SEND MIB September 2012
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each certificate
within a table.
The management station MUST select a pseudo-random number,
so that this value could be used as an index. If this
index was already in use, SO 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
DISPLAY-HINT "4096x"
STATUS current
DESCRIPTION
"A Router Authorization Certificate, i.e. an X.509v3
certificate as defined in [RFC5280]. It 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 [CCITT.X690.2002] object."
REFERENCE "RFC 3971: 6.3.1, RFC 5280, ITU-T Recommendation X.690"
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 }
--
-- Operational status of SEND
--
--
-- Authority verification
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 7]
Internet-Draft SEND MIB September 2012
--
sendCgaVerificationMinbits OBJECT-TYPE
SYNTAX Integer32 (384 .. 2147483647)
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 a CGA is 384 bits [RFC3972]."
REFERENCE "RFC 3971 : section 5.1.3"
DEFVAL { 1024 }
::= { send 1 }
sendCgaVerificationMaxbits OBJECT-TYPE
SYNTAX Integer32 (384 .. 2147483647)
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 SEND
messages.
When set to 2147483647, it indicates that the node does
not check for any maximum key length.
This value MUST be equal or greater than
sendCgaVerificationMinbits, and SHOULD be at least 2048
bits [RFC3971]."
REFERENCE "RFC 3971 : section 5.1.3"
::= { send 2 }
--
-- 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 all interfaces of the node."
REFERENCE "RFC 3971 : section 5.2.3"
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 8]
Internet-Draft SEND MIB September 2012
::= { send 3 }
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 all interfaces of the node."
REFERENCE "RFC 3971 : section 5.2.3"
::= { send 4 }
sendRsaVerificationMethodRS 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
Solicitation messages received.
It affects all interfaces of the node."
REFERENCE "RFC 3971 : section 5.2.3"
::= { send 5 }
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 all interfaces of the node."
REFERENCE "RFC 3971 : section 5.2.3"
::= { send 6 }
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.
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 9]
Internet-Draft SEND MIB September 2012
It affects all interfaces of the node."
REFERENCE "RFC 3971 : section 5.2.3"
::= { send 7 }
--
-- 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
the local clock.
It corresponds to the variable TIMESTAMP_DELTA defined in
[RFC3971]."
REFERENCE "RFC 3971 : section 5.3.4.2, RFC 3971 : section 10.2"
DEFVAL { 300 }
::= { send 8 }
sendTimestampFuzz OBJECT-TYPE
SYNTAX TimeTicks
UNITS "milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Time in milliseconds, used to check upon the reception of
a new SEND message if 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 [RFC3971]."
REFERENCE "RFC 3971 : 5.3.4.2, RFC 3971 : section 10.2"
DEFVAL { 100 }
::= { send 9 }
sendTimestampDrift OBJECT-TYPE
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 10]
Internet-Draft SEND MIB September 2012
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
[RFC3971]."
REFERENCE "RFC 3971 : 5.3.4.2, RFC 3971 : section 10.2"
DEFVAL { 100 }
::= { send 10 }
--
-- Cryptographic information repository
--
--
-- 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."
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 11]
Internet-Draft SEND MIB September 2012
::= { send 11 }
sendTrustAnchorTable OBJECT-TYPE
SYNTAX SEQUENCE OF SendTrustAnchorEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The list of 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.
Note that the removal of entries in this table SHOULD
result in the deletion of the certificates belonging to
Certification Paths rooted in this anchor.
Note that if SEND has been enabled in a host, there SHOULD
be at least one anchor."
REFERENCE "RFC 3971 : 6.5"
::= { send 12 }
sendTrustAnchorEntry OBJECT-TYPE
SYNTAX SendTrustAnchorEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A trust anchor provided in the form of a self-signed
certificate.
When the value of the sendTrustAnchorStatus of an entry
has been set once to enabled(2), the sendTrustAnchorCert
MUST remain unmodified."
INDEX { sendTrustAnchorIndex }
::= { sendTrustAnchorTable 1 }
SendTrustAnchorEntry ::= SEQUENCE {
sendTrustAnchorIndex SendCertificateIndex,
sendTrustAnchorCert SendX509ASN1DEREncodedRouterAuthCert,
sendTrustAnchorStatus 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 it as the index. If this index was already in use,
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 12]
Internet-Draft SEND MIB September 2012
so 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
STATUS current
DESCRIPTION
"Variable-length field containing the trust anchor in the
form of a self-signed certificate.
Upon a set operation, an 'inconsistentValue' error MUST be
returned if the value is not a valid DER-encoded ASN.1
certificate.
This object MUST NOT be modified once the
cgaLocalRowStatus object has been set to enabled(2)."
::= { sendTrustAnchorEntry 2 }
sendTrustAnchorStatus OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
enabled(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This columnar object indicates whether the row can be
used as a Trust Anchor in the managed system or not.
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(2), the administrator requires the anchor not to
be available for validating the authority of Certification
Paths."
DEFVAL { disabled }
::= { sendTrustAnchorEntry 3 }
sendTrustAnchorRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 13]
Internet-Draft SEND MIB September 2012
DESCRIPTION
"The status of this conceptual row.
Once set to enabled, the value of sendTrustAnchorCert
cannot be changed."
::= { sendTrustAnchorEntry 4 }
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(4), then no other objects are
required to be able to be modified."
DEFVAL { volatile }
::= { sendTrustAnchorEntry 5 }
--
-- table of the certificates part of a Certification Path
-- received from a remote router
--
sendCertTable OBJECT-TYPE
SYNTAX SEQUENCE OF SendCertEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of standard Public Key Certificates (PKC, in the
sense of [RFC5280]) which can be used by the SEND node.
The managed element 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 before (i.e. which
validly belongs to a Certification Path), are included in
the table.Certificates being certified by a trust anchor
contain a RowPointer element that points to the parent
entry in the sendTrustAnchorTable (note that there MAY be
many certificates rooted to the same 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.
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
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 14]
Internet-Draft SEND MIB September 2012
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
sendCertStatus object indicates that the certificate is
provisional(1).
The managed element 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 13 }
sendCertEntry OBJECT-TYPE
SYNTAX SendCertEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information related with a particular certificate."
INDEX { sendCertIndex }
::= { sendCertTable 1 }
SendCertEntry ::= SEQUENCE {
sendCertIndex SendCertificateIndex,
sendCertCert SendX509ASN1DEREncodedRouterAuthCert,
sendCertParentCertificate RowPointer,
sendCertStatus INTEGER
}
sendCertIndex 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 it as index. If this index was already in use, so
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 certificate
MUST remain constant at least from one re-initialization
of the entity's network management system to the next re-
initialization."
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 15]
Internet-Draft SEND MIB September 2012
::= { sendCertEntry 1 }
sendCertCert OBJECT-TYPE
SYNTAX SendX509ASN1DEREncodedRouterAuthCert
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Variable-length field containing the certificate
information."
::= { sendCertEntry 2 }
sendCertParentCertificate 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,
the object points to the parent certificate entry in this
table."
::= { sendCertEntry 3 }
sendCertStatus OBJECT-TYPE
SYNTAX INTEGER {
provisional(1),
valid(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the certificate.
A certificate has a sendCertStatus value of
provisional(1)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,
sendCertStatus 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"
::= { sendCertEntry 4 }
--
-- CGA addresses configured in this node
--
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 16]
Internet-Draft SEND MIB September 2012
sendCgaLocalTable OBJECT-TYPE
SYNTAX SEQUENCE OF SendCgaLocalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing one column which indicates if each
entry of CGA-MIB:cgaLocalTable can be used by SEND or not.
An entry in the CGA-MIB:cgaLocalTable may not be used by
SEND if, for example, it does not comply with the minimum
key length specified by SEND. Note that other policies
MAY be used to filter out configured CGA for SEND use."
REFERENCE "[I-D.garcia-martinez-cgamib]"
::= { send 14 }
sendCgaLocalEntry OBJECT-TYPE
SYNTAX SendCgaLocalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry of the sendCgaLocalTable.
This table augments the CGA-MIB:cgaLocalTable, i.e. every
entry in this table has a one-to-one correspondence with
an entry in the CGA-MIB:cgaLocalTable."
AUGMENTS { cgaLocalEntry }
::= { sendCgaLocalTable 1 }
SendCgaLocalEntry ::= SEQUENCE {
sendCgaLocalStatus INTEGER
}
sendCgaLocalStatus OBJECT-TYPE
SYNTAX INTEGER {
validForSend(1),
notValidForSend(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object indicates if its corresponding
entry in CGA-MIB:cgaLocalTable can be used by SEND or not
when properly configured as an IP address."
::= { sendCgaLocalEntry 1 }
--
-- compatibility with non-SEND devices
--
sendAcceptUnsecured OBJECT-TYPE
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 17]
Internet-Draft SEND MIB September 2012
SYNTAX INTEGER {
acceptSecuredAndUnsecured(1),
acceptOnlySecured(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates whether the node accepts or not
unsecured messages. 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."
REFERENCE "RFC 3971 : section 8"
DEFVAL { acceptOnlySecured }
::= { send 15 }
--
-- Compatibility with non-SEND devices: security status of ND related
-- information
--
--
-- Augmentation of tables of [RFC4293] to indicate whether the
-- information included in an entry in the
-- IP-MIB:ipAddressPrefixTable, IP-MIB:ipDefaultRouterTable and
-- IP-MIB ipNetToPhysicalTable 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 IP-MIB:ipAddressPrefixTable is secured or not. An
entry in the IP-MIB:ipAddressPrefixTable 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 IP-MIB:ipAddressPrefixTable 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 IP-
MIB:ipAddressPrefixEntry.
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 18]
Internet-Draft SEND MIB September 2012
If an entry in the ipAddressPrefixTable is deleted, the
corresponding entry in the sendIpAddressPrefixSecuredTable
MUST be deleted."
REFERENCE "RFC 3971: section 8, ipAddressPrefixEntry is defined
in the IP-MIB [RFC4293]."
::= { send 16 }
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 IP-MIB:ipAddressPrefixTable, i.e.,
every entry in this table has a one-to-one correspondence
with an entry in the IP-MIBipAddressPrefixTable."
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 whether its
corresponding entry in the IP-MIB: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.
If the value of the object sendAcceptUnsecured is set to
acceptOnlySecured(2), then the value of this object MUST
contain sendSecured(1)."
::= { sendIpAddressPrefixSecuredEntry 1 }
-- augmentation of IP-MIB:ipDefaulRouterTable
sendIpDefaultRouterSecuredTable OBJECT-TYPE
SYNTAX SEQUENCE OF SendIpDefaultRouterSecuredEntry
MAX-ACCESS not-accessible
STATUS current
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 19]
Internet-Draft SEND MIB September 2012
DESCRIPTION
"A table that contains one column indicating whether each
entry in the IP-MIB:ipDefaultRouterTable is secured or
not. An entry in IP-MIB: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 IP-MIB:ipDefaultRouterTable 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 IP-
MIB:ipDefaultRouterEntry.
If an entry in the ipDefaultRouterTable is deleted, the
corresponding entry in the sendIpDefaultRouterSecuredTable
MUST be deleted."
REFERENCE "RFC 3971 : section 8
ipDefaultRouterEntry is defined in the IP-MIB [RFC4293]."
::= { send 17 }
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 IP-MIB:ipDefaultRouterTable, i.e.,
every entry in this table has a one-to-one correspondence
with an entry in the IP-MIB:ipDefaultRouterTable."
AUGMENTS { ipDefaultRouterEntry }
::= { sendIpDefaultRouterSecuredTable 1}
SendIpDefaultRouterSecuredEntry ::= SEQUENCE {
sendIpDefaultRouterSecuredStatus SendSecurityStatus
}
sendIpDefaultRouterSecuredStatus OBJECT-TYPE
SYNTAX SendSecurityStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object indicates whether its
corresponding entry in the IP-MIB: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.
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 20]
Internet-Draft SEND MIB September 2012
If the value of the object sendAcceptUnsecured is set to
acceptOnlySecured(2), then the value of this object MUST
contain sendSecured(1)."
::= { sendIpDefaultRouterSecuredEntry 1 }
-- augmentation of 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 IP-MIB:ipNetToPhysicalTable is secured or not. An
entry in IP-MIB:ipNetToPhysicalTable is secured if the
last ND message that caused the creation or last update of
the entry was secured. An entry in IP-
MIB: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 IP-MIB:ipNetToPhysicalEntry.
If an entry in the IP-MIB:ipNetToPhysicalTable is deleted,
the corresponding entry in the
sendIpNetToPhysicalSecuredTable MUST be deleted."
REFERENCE "RFC 3971 : section 8
ipNetToPhysicalEntry is defined in the IP-MIB [RFC4293]."
::= { send 18 }
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 IP-MIB:ipNetToPhysicalTable, i.e.,
every entry in this table has a one-to-one correspondence
with an entry in the IP-MIB:ipNetToPhysicalTable.
If the value of sendIpNetToPhysicalSecuredStatus for an
entry is sendSecured(1), and the CGA has been used for
validating this information, an entry in CGA-
MIB:cgaRemoteTable MUST exist containing the CGA parameter
data structure of the CGA of the neighbor node."
AUGMENTS { ipNetToPhysicalEntry }
::= { sendIpNetToPhysicalSecuredTable 1 }
SendIpNetToPhysicalSecuredEntry ::= SEQUENCE {
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 21]
Internet-Draft SEND MIB September 2012
sendIpNetToPhysicalSecuredStatus SendSecurityStatus
}
sendIpNetToPhysicalSecuredStatus OBJECT-TYPE
SYNTAX SendSecurityStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object indicates whether its
corresponding entry in the IP-MIB:ipNetToPhysicalTable is
secured (if the last ND message that caused the creation
or last update of the entry was secured by SEND).
If the value of the object sendAcceptUnsecured is set to
acceptOnlySecured(2), then the value of this object MUST
contain sendSecured(1)."
::= { sendIpNetToPhysicalSecuredEntry 1 }
sendIgnoreUnsecuredDadFirstTentative OBJECT-TYPE
SYNTAX INTEGER {
acceptUnsecuredDadFirstTentative(1),
ignoreUnsecuredDadFirstTentative(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"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 mechanism 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 19 }
--
-- SEND statistics
--
sendStatsInNDMsgs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 22]
Internet-Draft SEND MIB September 2012
STATUS current
DESCRIPTION
"The total number of ND messages (Neighbor Solicitation,
Neighbor Advertisement, Router Solicitation, Router
Advertisements and Redirects) that the node received.
Note that this counter includes all the messages counted
by sendStatsInNDSecuredWithErrors."
::= { send 20 }
sendStatsInNDSecuredValidMsgs 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 were both secured and
successfully validated according to the rules specified in
[RFC3971]."
REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2"
::= { send 21 }
sendStatsInNDSecuredInvalidMsgs 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 contained any kind of
SEND security information, but were not successfully
validated according to the rules specified in [RFC3971].
Note that these messages MAY be further processed by the
node as unsecured messages (and counted in
sendStatsInNDUnsecuredMsgs), depending on the
configuration of the node."
REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2"
::= { send 22 }
sendStatsInNDUnsecuredMsgs 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) processed as unsecured. It
includes messages that did not contain any security
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 23]
Internet-Draft SEND MIB September 2012
information defined in SEND, and messages containing
security information for which validation failed and were
finally processed as unsecured."
::= { send 23 }
sendStatsInNDSecuredWithErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of ND messages (Neighbor Solicitation,
Neighbor Advertisement, Router Solicitation, Router
Advertisements and Redirects) received by the node which
were validated as secured but had ICMP-specific errors
(bad ICMP checksums, bad length, bad format, etc.). Note
that it does not include the messages counted by
sendStatsInNDUnsecuredMsgs."
::= { send 24 }
sendStatsOutNDMsgs 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 node attempted to
send. This counter includes all messages counted by
sendStatsOutNDSecuredErrors."
::= { send 25 }
sendStatsOutNDSecuredMsgs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of secured ND messages (Neighbor Solicitation,
Neighbor Advertisement, Router Solicitation, Router
Advertisements and Redirects) attempted to be sent by the
node."
REFERENCE "RFC 3971 : 5.1.2, RFC 3971 : 5.2.2"
::= { send 26 }
sendStatsOutNDSecuredErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 24]
Internet-Draft SEND MIB September 2012
STATUS current
DESCRIPTION
"The number of secured ND messages (Neighbor Solicitation,
Neighbor Advertisement, Router Solicitation, Router
Advertisements and Redirects) attempted to be sent by the
node that was not sent 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."
::= { send 27 }
sendStatsInCertMsgs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Certification Path Advertisement messages
received by the node."
::= { send 28 }
sendStatsInCertVerifiedMsgs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Certification Path Advertisement messages
received by a node which could be verified according to
the verification procedure defined in section 6.3 of
[RFC3971]."
REFERENCE "RFC 3971 : section 6.3"
::= { send 29 }
sendStatsInCertInvalidMsgs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Certification Path Advertisement messages
received by a host which it could not verify successfully,
according to the verification procedure defined in section
6.3 of [RFC3971]. It does not include messages counted by
sendStatsInCertErrors."
REFERENCE "RFC 3971 : section 6.3"
::= { send 30 }
sendStatsInCertErrors OBJECT-TYPE
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 25]
Internet-Draft SEND MIB September 2012
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Certification Path Advertisement messages
received that had ICMP-specific errors (bad ICMP
checksums, bad length, bad format, etc.). Note that it
does not include the messages counted by
sendStatsInCertFailedMessages."
::= { send 31 }
--
-- 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 a managed element 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 {
sendAuthorityGroup, sendTimestampGroup,
sendTrustAnchorGroup, sendCertGroup,
sendCgaLocalGroup, sendCompatibilityGroup,
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."
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 26]
Internet-Draft SEND MIB September 2012
OBJECT sendCgaVerificationMaxbits
MIN-ACCESS read-only
DESCRIPTION
"An agent is not required to provide write access to this
object, since this object MAY not be configurable."
::= { sendMIBCompliances 1 }
-- compliance statement #2
sendMIBSendOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for an managed element 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 {
sendAuthorityGroup, sendTimestampGroup,
sendTrustAnchorGroup, sendCertGroup,
sendCgaLocalGroup, 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."
OBJECT sendCgaVerificationMaxbits
MIN-ACCESS read-only
DESCRIPTION
"An agent is not required to provide write access to this
object, since this object MAY not be configurable."
::= { sendMIBCompliances 2 }
-- compliance statement #3
sendMIBCompatibleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for a managed element that supports
compatible operation with non-SEND devices, but it is
implemented without support for the creation of rows in
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 27]
Internet-Draft SEND MIB September 2012
the sendTrustAnchorGroup, and with read-only access for
the remaining writable objects."
MODULE -- this module
MANDATORY-GROUPS {
sendAuthorityGroup, sendTimestampGroup,
sendTrustAnchorGroup, sendCertGroup,
sendCgaLocalGroup, sendCompatibilityGroup,
sendStatsGroup }
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."
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."
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 28]
Internet-Draft SEND MIB September 2012
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
"An agent is not required to implement 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 sendTrustAnchorStatus
MIN-ACCESS read-only
DESCRIPTION
"An agent is not required to provide write or create
access to this object."
OBJECT sendTrustAnchorRowStatus
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 29]
Internet-Draft SEND MIB September 2012
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 nonVolatile(3), permanent(4) or
readOnly(5)."
OBJECT sendAcceptUnsecured
MIN-ACCESS read-only
DESCRIPTION
"An agent is not required to provide write access to this
object."
OBJECT sendIgnoreUnsecuredDadFirstTentative
MIN-ACCESS read-only
DESCRIPTION
"An agent is not required to provide write access to this
object."
::= { sendMIBCompliances 3 }
-- compliance statement #4
sendMIBSendOnlyReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for an agent that does not support
compatible operation with non-SEND devices and it is
implemented without support for read-create (i.e., in
read-only mode)."
MODULE -- this module
MANDATORY-GROUPS { sendAuthorityGroup, sendTimestampGroup,
sendTrustAnchorGroup, sendCertGroup,
sendCgaLocalGroup, sendStatsGroup }
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 30]
Internet-Draft SEND MIB September 2012
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."
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."
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 31]
Internet-Draft SEND MIB September 2012
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
"An agent is not required to implement 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 nonVolatile(3), permanent(4) or
readOnly(5)."
::= { sendMIBCompliances 4 }
-- Units of conformance
sendAuthorityGroup OBJECT-GROUP
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 32]
Internet-Draft SEND MIB September 2012
OBJECTS {
sendCgaVerificationMinbits,
sendCgaVerificationMaxbits,
sendRsaVerificationMethodNS,
sendRsaVerificationMethodNA,
sendRsaVerificationMethodRS,
sendRsaVerificationMethodRA,
sendRsaVerificationMethodRedirect
}
STATUS current
DESCRIPTION
"The group of objects that control SEND authority
attestation and verification processes. These objects
manage the acceptable size of the CGAs being used and the
checks that are applied to incoming SEND authority
information."
::= { sendMIBGroups 1 }
sendTimestampGroup OBJECT-GROUP
OBJECTS {
sendTimestampDelta, sendTimestampFuzz, sendTimestampDrift
}
STATUS current
DESCRIPTION
"The group of objects that control the verification of the
Timestamp option to provide anti-replay protection"
::= { sendMIBGroups 2 }
sendTrustAnchorGroup OBJECT-GROUP
OBJECTS {
sendTrustAnchorSpinLock,
sendTrustAnchorCert,
sendTrustAnchorStatus,
sendTrustAnchorRowStatus,
sendTrustAnchorStorageType
}
STATUS current
DESCRIPTION
"The group of objects for managing the anchors used for
validating the authority of the Certification Path of a
remote node."
::= { sendMIBGroups 3 }
sendCertGroup OBJECT-GROUP
OBJECTS {
sendCertCert,
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 33]
Internet-Draft SEND MIB September 2012
sendCertParentCertificate,
sendCertStatus
}
STATUS current
DESCRIPTION
"The group of objects for storing the certificates that
belong to a Certification Path received from a remote
router."
::= { sendMIBGroups 4 }
sendCgaLocalGroup OBJECT-GROUP
OBJECTS {
sendCgaLocalStatus
}
STATUS current
DESCRIPTION
"The group for the object pointing to the CGA which can be
used by SEND as local addresses."
::= { sendMIBGroups 5 }
sendCompatibilityGroup OBJECT-GROUP
OBJECTS { sendAcceptUnsecured, sendIpAddressPrefixSecuredStatus,
sendIpDefaultRouterSecuredStatus,
sendIpNetToPhysicalSecuredStatus,
sendIgnoreUnsecuredDadFirstTentative }
STATUS current
DESCRIPTION
"The group of objects to configure SEND operation to
interact with non-SEND hosts and to show the security
status of the resulting ND information."
::= { sendMIBGroups 6 }
sendStatsGroup OBJECT-GROUP
OBJECTS {
sendStatsInNDMsgs,
sendStatsInNDSecuredValidMsgs,
sendStatsInNDSecuredInvalidMsgs,
sendStatsInNDUnsecuredMsgs,
sendStatsInNDSecuredWithErrors,
sendStatsOutNDMsgs,
sendStatsOutNDSecuredMsgs,
sendStatsOutNDSecuredErrors,
sendStatsInCertMsgs,
sendStatsInCertVerifiedMsgs,
sendStatsInCertInvalidMsgs,
sendStatsInCertErrors
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 34]
Internet-Draft SEND MIB September 2012
}
STATUS current
DESCRIPTION
"The group of statistics related to SEND operation."
::= { sendMIBGroups 7 }
END
5. Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write or read-create. Such objects
may be considered sensitive or vulnerable in some network
environments. In the following paragraphs we discuss the risks
associated to improper SET access to the objects of the MIB module.
o sendCgaVerificationMinbits. Reducing the value of this object may
facilitate the impersonation of a legitimate CGA by an attacker:
the time to generate a key pair can be shortened, so the time to
perform a brute force attack to find a key pair with the same hash
as the attacked CGA can be shortened. On the other hand,
incrementing the value of sendCgaVerificationMinbits may result in
a DOS attack when only secured ND messages are accepted by the
node, since messages from other nodes could be unintendedly
discarded if having a CGA with a key shorter than
sendCgaVerificationMinbits.
o 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.
o 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 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 compatible with the authorization
being used by the party generating the message.
o sendTimestampDelta, sendTimeFuzz and sendTimestampDrift.
Incrementing the value of the objects sendTimestampDelta,
sendTimeFuzz and sendTimestampDrift extends the vulnerability
window for replay attacks. Section 9.2.5 of [RFC3971] discusses
the impact of this action. On the other hand, setting too low
values to these three objects may result in a DOS attack, since
valid SEND messages could be discarded by too tight validation
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 35]
Internet-Draft SEND MIB September 2012
constraints.
o sendTrustAnchorTable. The addition of an entry in the anchor
table by an unauthorized party can be used to make the node trust
(in SEND sense) in the information contained in Router
Advertisements issued by a malicious node in the link. For
example, this malicious node can become for the attacked node a
default router (and perform MITM attacks for off-link
destinations), it can alter the list of prefixes used for address
autoconfiguration, and the list of prefixes considered to be on-
link. The unauthorized disabling or deletion of an entry in the
sendTrustAnchorTable can result in DOS for the attacked node,
since the node will not consider validly secured information as
legitimate.
o sendAcceptUnsecured. Write access from an unauthorized party to
unintendedly accept unsecured information can be used to enable an
attacker to introduce unprotected information into the ND data
structures. Note that the possible attacks are limited by the
fact that in general secured information is preferred to
unsecured, as described by [RFC3971] section 8. Conversely, if
the value of the sendAcceptUnsecured object is unintendedly
changed from acceptSecuredAndUnsecured to acceptOnlySecured, the
node will lose the communication with non-SEND devices in the link
considered, being this a DOS attack.
o sendIgnoreUnsecuredDadFirstTentative. As [RFC3971], section 9.2.3
states, if this object value 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. Since the DAD
procedure in a SEND node for the second CGA only considers secured
responses, regardless the state of this object, this impact is
low.
The risk associated to unintended access to the readable objects in
this MIB module (i.e., objects with a MAX-ACCESS other than not-
accessible) are now discussed.
o 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 impersonate the CGA of
other node. If this value is not known by the attacker, the
attacker could use in a brute force attack keys with a length
shorter than the minimum acceptable, and so being unable to obtain
valid values for the CGA Parameter Data Structure. Note that the
attacker could blindly estimate a reasonable key length (such as
the suggested default value, 1024 bits) to perform this attack
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 36]
Internet-Draft SEND MIB September 2012
with high probability of success without knowing this value.
o sendCgaVerificationMaxbits. Read access to this object by an
unauthorized node can provide information about the maximum key
length that can be claimed to try to drain CPU resources forcing
the managed system to compute useless key verifications.
o sendTimestampDelta, sendTimeFuzz and sendTimestampDrift. Knowing
these values can make an attacker aware of the anti-replay
protection window. However, if the values are set appropriately,
the risks are low, as described in Section 9.2.5 of [RFC3971].
o sendTrustAnchorTable. Having read access to the rows in the
sendTrustAnchorTable allows a node to know which are the trust
anchors in which the managed node rely on. An attacker could
focus on breaking any of these keys to perform further attacks to
the node. However, it is very likely that this information can
also be inferred from the certificates being exchanged in the link
to which the managed node is connected. The attacker can ask
directly the router with a CPS message to obtain this information.
o sendCertTable. Accessing to the sendCertTable does not reveal any
information which could not be obtained by the attacker from a
CPS/CPA message exchange. Therefore accessing to this information
is not sensitive for the security of the managed node.
o sendCgaLocalTable. Accessing to this information is not sensitive
for the CGA configured in the link to which the attacker is also
connected, since the attacker can obtain the same information by
issuing a NS message to the managed node (or by capturing messages
exchanged among the node and other nodes). The table can reveal
CGAs configured in other links. Note that access to the IP-
MIB:ipAddressTable also reveals other addresses configured in the
same node (even though it cannot be determined if they are CGA or
not). The risks of accessing to CGA-specific information
contained in the CGA-MIB:cgaLocalTable are discussed in
[I-D.garcia-martinez-cgamib].
o sendAcceptUnsecured. An attacker could know by accessing to this
information if the managed node is willing to accept unsecured
messages. It can also try to influence in the managed node ND
database by issuing unsecured messages, even without knowing the
value of this object. Note that the attacker could obtain the
same information by exchanging unsecured ND information with the
node to test if the node accepts it.
o sendIpAddressPrefixSecuredTable, sendIpDefaultRouterSecuredTable,
sendIpNetToPhysicalSecuredTable. An attacker could know, by
reading this tables, which of the prefixes, default routers and
neighbor information have been introduced securely in the managed
node as a result of SEND operation. This can be used, for
example, to try to modify the information acquired as a result of
an unsecured ND exchange. This does not provide much advantage
for the attacker over just trying to introduce this information by
sending ND messages to the managed node, or by identifying by
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 37]
Internet-Draft SEND MIB September 2012
traffic inspection or solicitation messages which routers or other
node present in the link use SEND and which use plain ND.
o sendIgnoreUnsecuredDadFirstTentative. An attacker accessing to
this value could know in advance if sending unsecured NA when the
managed node performs DAD will result in the managed node
discarding the first address tried. Note that the impact of this
attack is low, as discussed in [RFC3972], and this attack could
only be exercised the next time the managed node tries to
configure a new CGA.
o Objects collecting statistics about SEND operation. The
disclosure of the information available in these objects affects
mainly to privacy.
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
rights to indeed GET or SET (change/create/delete) them.
6. 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
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 38]
Internet-Draft SEND MIB September 2012
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.
7. Acknowledgements
The work of Alberto Garcia-Martinez was supported in part by T2C2
project (TIN2008-06739-C04-01, granted by the Spanish Science and
Innovation Ministry).
The authors would like to thank Suresh Krishnan for reviewing the
document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4293] Routhier, S., "Management Information Base for the
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 39]
Internet-Draft SEND MIB September 2012
Internet Protocol (IP)", RFC 4293, April 2006.
[CCITT.X690.2002]
International International Telephone and Telegraph
Consultative Committee, "ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002.
[I-D.garcia-martinez-cgamib]
Garcia-Martinez, A. and M. Bagnulo, "Management
Information Base for Cryptographically Generated Addresses
(CGA)", draft-garcia-martinez-cgamib-05 (work in
progress), September 2012.
[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.
8.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.
Authors' Addresses
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 & Bagnulo Expires March 15, 2013 [Page 40]
Internet-Draft SEND MIB September 2012
Marcelo Bagnulo
U. Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34 91 6248814
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/
Garcia-Martinez & Bagnulo Expires March 15, 2013 [Page 41]
