Accounting in NETCONF and
RESTCONFCisco Systems, Inc170 West Tasman DriveSan JoseCA95070USAmjethanandani@gmail.comThis document defines an accounting record for NETCONF and
RESTCONF.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.NETCONF and RESTCONF protocol operations are authenticated
and authorized as part of the Authentication, Authorization and
Accounting (AAA) framework. An accounting record is generated as part of
the same framework for each of these operations to satisfy the
accounting part of AAA, but there has been no effort to define such a
record. Having an accounting record that is consistent across vendors
allows for the operator to compare operations across devices from
different vendors. This document defines such a record and a
corresponding YANG data model (ietf-netconf-am.yang).The rest of this document will use NETCONF to imply both NETCONF and
RESTCONF, but where applicable will call out each protocol
specifically.This document does not cover how the server interacts with remote
AAA servers and any interaction is out of scope of this document. A
particular implementation can make the records available as part of
<get> request, send a notification every time a accounting
record is generated or use any existing protocol to update the remote
AAA server.The following terms are defined in NETCONF and are not redefined here:client<get>notificationserversessionuserAnd the following terms are defined in NACM and are not redefined here.data-nodeactionruleAn accounting record for NETCONF consists of the following fields.
Note, there is no accounting record for reading or notification of an
accounting record.message-idsession-idsrc-ipdate-timeusergroupsruledata-nodevalueactionstatuswhere:message-id: This is the id within a given NETCONF session assigned to
each RPC. RESTCONF has no concept of a session, so this field would be
left blank.session-id: The session-id in case of NETCONF and would be blank in
case of RESTCONF. If the accounting record needs to be fragmented for
any reason, it is suggested that this field not be repeated in
subsequent packets. Instead a combination of start and end record
marker, and the message-id should be used to reassemble fragmented
records.src-ip: The source IP address that was used to request the operation.
If the accounting record needs to be fragmented for any reason, it is
suggested that this field not be repeated in subsequent packets. Instead
a combination of start and end record marker, and the message-id should
be used to reassemble fragmented records.date-time: The date and time when the operation was performed (UTC
Timezone). If the accounting record needs to be fragmented for any
reason, it is suggested that this field not be repeated in subsequent
packets. Instead a combination of start and end record marker, and the
message-id should be used to reassemble fragmented records.user: The NETCONF user that requesed this operation. If the
accounting record needs to be fragmented for any reason, it is suggested
that this field not be repeated in subsequent packets. Instead a
combination of start and end record marker, and the message-id should be
used to reassemble fragmented records.groups: The group the user belongs to. If the accounting record needs
to be fragmented for any reason, it is suggested that this field not be
repeated in subsequent packets. Instead a combination of start and end
record marker, and the message-id should be used to reassemble
fragmented records.data-node: The data-node in the NACM
rule on which the operations is being performedvalue: The value that was set for any of the attributes in the
requestaction: The action in the NACM rulerule: The rule in the NACM that was
matched to authorize the action.status: Whether the operations was permitted or denied.The model uses the NACM extension statement of default-deny-all to
protect accounting records. Explicit rules have to be defined to be
enable access to the accounting records.The following diagram highlights the contents and structure of the
Accounting YANG module. For information on annotations, please refer
to YANG Tree
Diagrams.The following YANG module specifies the normative NETCONF content
that MUST be supported by the server.The "ietf-netconf-am" YANG module imports typedefs from YANG-TYPES, from NETCONF and from NACM.This document makes two requests of IANA.The first request is to register one URI in "The IETF XML Registry".
Following the format in The IETF XML
Registry, the following needs to be registered.URI: urn:ietf:params:xml:ns:yang:ietf-netconf-amRegistrant Contact: The IESGXML: N/A, the requested URI is an XML namespaceThe second request is to register one module in the "YANG Module
Names" registry. Following the format in YANG, the following needs to be registered.Name: ietf-netconf-amNamespace: urn:ietf:params:xml:ns:yang:ietf-netconf-amPrefix: namReference: RFC XXXXNote to RFC Editor - Please replace XXXX here and in the rest of the
draft with the RFC id assigned to this draft.The YANG module defined in this document is designed to be accessed
via network management protocol such as NETCONF or RESTCONF. The lowest NETCONF layer is the secure
transport layer, and the mandatory-to-implement secure transport is
Secure Shell (SSH). The lowest RESTCONF
layers is HTTPS, and the mandatory-to-implement secure transport is
TLS.The NETCONF Access Control Model (NACM)
provides the means to restrict access for particular NETCONF or RESTCONF
users to a pre-configured subset of all available NETCONF or RESTCONF
protocol operations and content.Most of the data nodes defined in this YANG module are readonly, i.e.
config false, and are therefore not vulnerable to manipulation in
network environments. However, they might contain data that might be
sensitive and should be protected with the right NACM rules.This example demonstrates how the configuration could be updated to
enable accounting. The attribute in the model that enables accounting
is enable-nam. This example demonsrates what a <get> request and response
might look like.This example demonstrates how NACM could be configured to permit
access to accounting records. Note, the model has default-deny-all set
to prevent access to accounting records by default, and expects
explicit rules to be configured to permit access.