One document matched: draft-garcia-martinez-sendmib-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 11:27:04 |