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 needs to be created as
part of the same framework for each of these operations to satisfy the
accounting part of AAA. 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.The following terms are defined in NETCONF and are not redefined here:clientserversessionuserAn accounting record for NETCONF consists of the following
fields.acct-codedate-timesrc-ipsession-idtask-idusergroupspathactionrulestatuswhere:acct-code: START indicates a start of a new record, NONE a
continuation, and STOP the end of the record.date-time: The date and time when the operation was performed (UTC
Timezone)src-ip: The source IP address that was used to request the
operationsession-id: The session-id in case of NETCONF and would be blank in
case of RESTCONFtask-id: Used to track a accounting record in case it needs to split
for uploading or storing. The id is a monotonically increasing number
assigned by the server.user: The NETCONF user that requesed this operation.groups: The group the user belongs to.path: The path in the NACM rule on which the operations is being
performedaction: The action in the NACM rulerule: The rule in the NACM that was used to authorize the action.status: Whether the operations was permitted or denied.The following diagram highlights the contents and structure of the
Accounting YANG module.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. file ietf-netconf-am@2017-03-13.yang
module ietf-netconf-am {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-am";
prefix "nam";
import ietf-inet-types {
prefix inet;
//reference
// "RFC 6991: Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
//reference
// "RFC 6991: Common YANG Data Types";
}
import ietf-netconf {
prefix nc;
//reference
// "RFC 6241: NETCONF Protocol";
}
import ietf-netconf-acm {
prefix nacm;
//reference
// "RFC 6536: NACM";
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web:
WG List:
WG Chair: Mehmet Ersue
WG Chair: Mahesh Jethanandani
Editor: Mahesh Jethanandani
";
description
"This module defines an accounting record for NETCONF operations
performed on the server. If these operations are authorized
using rules defined by NACM [RFC6536], then that information is
also captured by this module.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision "2017-03-13" {
description
"Initial version";
reference
"RFC XXXX: NETCONF and RESTCONF Accounting";
}
/*
* Data definition statements.
*/
container nam {
config false;
description
"Parameters for NETCONF Accounting Model.";
list accounting-record {
key "task-id";
description
"A list of accounting records generated by the server";
leaf task-id {
type uint32;
description
"The task-id is a monotonically increasing number
assigned by the server to capture a single
transaction.";
}
leaf session-id {
type nc:session-id-type;
description
"If this operation happened over NETCONF, this
field captures the NETCONF session-id. In case
of RESTCONF this field can be left blank.";
}
leaf acct-code {
type enumeration {
enum start {
description
"Start of an accounting record";
}
enum stop {
description
"Indicates the end of an accounting
record";
}
enum none {
description
"Indicates a single payload or a
continuation of an accounting record.";
}
}
mandatory true;
description
"Some of the AAA server place a limit on the size
of the payload that can be transmitted at any
particular time.
This field indicates what constitues a complete
accounting record by setting up the boundaries. If
the accounting record fits within the payload
boundary the field should be set to none.";
}
leaf date-time {
type yang:date-and-time;
mandatory true;
description
"The date and time when the operation was
requested.";
}
leaf src-ip {
type inet:ip-address;
mandatory true;
description
"The source IP address where the request was made
from.";
}
leaf group {
type nacm:group-name-type;
mandatory true;
description
"The name of the group that the user who requested
the operation belongs to.";
}
leaf user {
type nacm:user-name-type;
description
"The user within the group that is requesting this
operation.";
}
leaf path {
type nacm:node-instance-identifier;
mandatory true;
description
"Data Node Instance Identifier associated with the
data node that the request is being made on.
Instance identifiers start with the top-level
data node, and a complete identifier is required
for this value.";
}
leaf action {
type nacm:access-operations-type;
mandatory true;
description
"The type of NETCONF operation being requested.";
}
leaf rule {
type string {
length "1..max";
}
description
"The name assigned to the rule that was used to
authorize the action, if authorization was
enabled.";
}
leaf status {
type nacm:action-type;
description
"Action taken by the server when the above
mentioned rule matched, if authorization was
enable.";
}
}
}
}
]]>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 with the RFC id assigned to
this draft.The YANG module defined in this memo is designed to be accessed using
the NETCONF protocol. The lowest NETCONF layer is the secure transport
layer and the mandatory-to-implement secure transport is SSH.Most of the data nodes defined in this YANG module are readonly, i.e.
config false, and are therefore not vulnerable in network environments.
However, they might contain data that might be sensitive and should be
protected with the right NACM rules.