| Network Working Group | M. Jethanandani |
| Internet-Draft | Cisco Systems, Inc |
| Intended status: Standards Track | June 29, 2017 |
| Expires: December 31, 2017 |
Accounting in NETCONF and RESTCONF
draft-mahesh-netconf-accounting-02
This 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
The following terms are defined in NETCONF and are not redefined here:
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.
An accounting record for NETCONF consists of the following fields. Note, there is no accounting record for reading or notification of an accounting record.
| message-id | session-id | src-ip | date-time | user | groups | path | value | action | rule | status |
|---|---|---|---|---|---|---|---|---|---|---|
where:
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.
path: The path in the NACM rule on which the operations is being performed
value: The value that was set for any of the attributes in the request
action: The action in the NACM rule
rule: The rule in the NACM that was used 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.
module: ietf-netconf-am
+--rw nam
+--rw enable-nam? boolean
+--rw read-default? nacm:action-type
+--ro accounting-record* [session-id message-id]
+--ro session-id nc:session-id-type
+--ro message-id uint32
+--ro date-time yang:date-and-time
+--ro src-ip inet:ip-address
+--ro group nacm:group-name-type
+--ro user? nacm:user-name-type
+--ro path nacm:node-instance-identifier
+--ro value?
+--ro action nacm:access-operations-type
+--ro rule? string
+--ro status? nacm:action-type
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.
<CODE BEGINS> file "ietf-netconf-am@2017-06-29.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;
}
import ietf-yang-types {
prefix yang;
}
import ietf-netconf {
prefix nc;
}
import ietf-netconf-acm {
prefix nacm;
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>";
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-06-29" {
description
"Initial version";
reference
"RFC XXXX: NETCONF and RESTCONF Accounting";
}
/*
* Data definition statements.
*/
container nam {
nacm:default-deny-all;
description
"Parameters for NETCONF Accounting Model.";
leaf enable-nam {
type boolean;
default true;
description
"Enable or disable generation of NETCONF
accounting records. If 'true', accounting
records will be generated. If set to 'false'
no accounting records will be generated.";
}
leaf read-default {
type nacm:action-type;
default "permit";
description
"Controls whether read access is granted if
no particular rule is found for a read
request.";
}
list accounting-record {
key "session-id message-id";
config false;
description
"A list of accounting records generated by the server";
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 message-id {
type uint32;
description
"Id that is assigned to each RPC within a given
NETCONF session. Should be blank in case of
RESTCONF.";
}
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.";
}
anydata value {
description
"An optional field, it contains the value of any
of the attribute that form the record.
It could be as simple as the filter value
'http' specified that the user requested as part
of the authorization request such as in this
example:
<filter>
<name>http</name>
</filter>
or it could be value being set for a ssh port
in this example:
<ssh>
<port>2022</port>
</ssh>";
}
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.";
}
}
}
}
<CODE ENDS>
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-am
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace
The 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-am
Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-am
Prefix: nam
Reference: RFC XXXX
Note 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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3688] | Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011. |
| [RFC6242] | Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011. |
| [RFC6536] | Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012. |
| [RFC6991] | Schoenwaelder, J., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013. |
| [RFC7950] | Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016. |
| [RFC8040] | Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017. |
| [I-D.ietf-netmod-yang-tree-diagrams] | Bjorklund, M. and L. Berger, "YANG Tree Diagrams", Internet-Draft draft-ietf-netmod-yang-tree-diagrams-00, June 2017. |