Definitions of Managed Objects for the
Resource Public Key Infrastructure (RPKI) to Router ProtocolInternet Initiative Japan5147 Crystal SpringsBainbridge IslandWA98110USrandy@psg.comRIPE NCC Schagen 333461 GL LinschotenNetherlandsbertietf@bwijnen.netCisco Systems170 W. Tasman DriveSan JoseCA95134USAkeyupate@cisco.comSPARTAP.O. Box 72682DavisCA95617USAbaerm@tislabs.comThis document defines a portion of the Management Information
Base (MIB) for use with network management protocols in the
Internet community. In particular, it describes objects used for
monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.This document defines a portion of the Management
Information Base (MIB) for use with network management protocols
in the Internet community. In particular, it defines objects
used for monitoring the RPKI-Router Protocol
.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in
RFC 2119.For a detailed overview of the documents that describe the
current Internet-Standard Management Framework, please refer to
section 7 of RFC 3410 .
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
, STD 58, RFC 2579 ,
and STD 58, RFC 2580 .The objects defined in this document are used to monitor the
RPKI-Router Protocol .
The MIB module defined here is broken into these tables:
the RPKI-Router Cache Server (Connection) Table,
the RPKI-Router Cache Server Errors Table, and
the RPKI-Router Prefix Origin Table.The RPKI-Router Cache Server Table contains information about the
state and current activity of connections with the RPKI-router
cache servers. It also contains counters for the number of
messages received and sent, plus the number of announcements,
withdrawals, and active records.
The RPKI-Router Cache Server Errors Table contains counters of
occurrences of errors on the connections (if any).
The RPKI-Router Prefix Origin Table contains IP prefixes with
their minimum and maximum prefix lengths and the Origin Autonomous System
(AS).
This data is the collective set of information received from
all RPKI cache servers that the router is connected with.
The cache servers are running the RPKI-Router Protocol.Two notifications have been defined to inform a Network Management
Station (NMS) or operators about changes in the connection state
of the connections listed in the RPKI-Router Cache Server (Connection)
Table.The following MIB module imports definitions from
,
, ,
, and
. That means we have a normative reference to each
of those documents.The MIB module also has a normative reference to the
RPKI-Router Protocol .
Furthermore, for background and informative information, the MIB module
refers to , ,
, and .IANA has assigned the MIB module in this document
the following OBJECT IDENTIFIER within the SMI Numbers registry.
There are no management objects defined in this MIB module that
have a MAX-ACCESS clause of read-write and/or read-create. So, if
this MIB module is implemented correctly, then there is no risk that
an intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.Most 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. They are vulnerable in the
sense that when an intruder sees the information in this MIB module,
then it might help him/her to set up an attack on the router or
cache server. 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.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
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.Implementations MUST provide the security features described by
the SNMPv3 framework (see ),
including full support for authentication and privacy via the
User-based Security Model (USM)
with the AES cipher algorithm .
Implementations MAY also provide support for the Transport
Security Model (TSM) in combination
with a secure transport such as SSH
or TLS/DTLS .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.