idnits 2.17.1 draft-mahesh-netconf-accounting-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft Cisco Systems, Inc 4 Intended status: Standards Track March 13, 2017 5 Expires: September 14, 2017 7 Accounting in NETCONF and RESTCONF 8 draft-mahesh-netconf-accounting-01 10 Abstract 12 This document defines an accounting record for NETCONF and RESTCONF. 14 Requirements Language 16 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 17 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 18 document are to be interpreted as described in RFC 2119 [RFC2119]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 14, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Accounting Record . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Data Model Definitions . . . . . . . . . . . . . . . . . . . 3 58 3.1. Data Organization . . . . . . . . . . . . . . . . . . . . 3 59 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 NETCONF [RFC6241] and RESTCONF [RFC8040] protocol operations are 69 authenticated and authorized as part of the Authentication, 70 Authorization and Accounting (AAA) framework. An accounting record 71 needs to be created as part of the same framework for each of these 72 operations to satisfy the accounting part of AAA. Having an 73 accounting record that is consistent across vendors allows for the 74 operator to compare operations across devices from different vendors. 75 This document defines such a record and a corresponding YANG data 76 model (ietf-netconf-am.yang). 78 The rest of this document will use NETCONF to imply both NETCONF and 79 RESTCONF, but where applicable will call out each protocol 80 specifically. 82 1.1. Terminology 84 The following terms are defined in NETCONF [RFC6241] and are not 85 redefined here: 87 o client 89 o server 91 o session 93 o user 95 2. Accounting Record 97 An accounting record for NETCONF consists of the following fields. 99 +------+------+----+------+-----+-----+-----+-----+-----+-----+-----+ 100 | acct | date | sr | sess | tas | use | gro | pat | act | rul | sta | 101 | - | - | c- | ion- | k- | r | ups | h | ion | e | tus | 102 | code | time | ip | id | id | | | | | | | 103 +------+------+----+------+-----+-----+-----+-----+-----+-----+-----+ 104 +------+------+----+------+-----+-----+-----+-----+-----+-----+-----+ 106 where: 108 acct-code: START indicates a start of a new record, NONE a 109 continuation, and STOP the end of the record. 111 date-time: The date and time when the operation was performed (UTC 112 Timezone) 114 src-ip: The source IP address that was used to request the operation 116 session-id: The session-id in case of NETCONF and would be blank in 117 case of RESTCONF 119 task-id: Used to track a accounting record in case it needs to split 120 for uploading or storing. The id is a monotonically increasing 121 number assigned by the server. 123 user: The NETCONF user that requesed this operation. 125 groups: The group the user belongs to. 127 path: The path in the NACM rule on which the operations is being 128 performed 130 action: The action in the NACM rule 132 rule: The rule in the NACM that was used to authorize the action. 134 status: Whether the operations was permitted or denied. 136 3. Data Model Definitions 138 3.1. Data Organization 140 The following diagram highlights the contents and structure of the 141 Accounting YANG module. 143 module: ietf-netconf-am 144 +--ro nam 145 +--ro accounting-record* [task-id] 146 +--ro task-id uint32 147 +--ro session-id? nc:session-id-type 148 +--ro acct-code enumeration 149 +--ro date-time yang:date-and-time 150 +--ro src-ip inet:ip-address 151 +--ro group nacm:group-name-type 152 +--ro user? nacm:user-name-type 153 +--ro path nacm:node-instance-identifier 154 +--ro action nacm:access-operations-type 155 +--ro rule? string 156 +--ro status? nacm:action-type 158 3.2. YANG Module 160 The following YANG module specifies the normative NETCONF content 161 that MUST be supported by the server. 163 The "ietf-netconf-am" YANG module imports typedefs from YANG-TYPES 164 [RFC6991], from NETCONF [RFC6241] and from NACM [RFC6536]. 166 file "ietf-netconf-am@2017-03-13.yang" 168 module ietf-netconf-am { 169 yang-version 1.1; 170 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-am"; 171 prefix "nam"; 173 import ietf-inet-types { 174 prefix inet; 175 //reference 176 // "RFC 6991: Common YANG Data Types"; 177 } 179 import ietf-yang-types { 180 prefix yang; 181 //reference 182 // "RFC 6991: Common YANG Data Types"; 183 } 185 import ietf-netconf { 186 prefix nc; 187 //reference 188 // "RFC 6241: NETCONF Protocol"; 189 } 190 import ietf-netconf-acm { 191 prefix nacm; 192 //reference 193 // "RFC 6536: NACM"; 194 } 196 organization 197 "IETF NETCONF (Network Configuration) Working Group"; 199 contact 200 "WG Web: 201 WG List: 203 WG Chair: Mehmet Ersue 204 206 WG Chair: Mahesh Jethanandani 207 209 Editor: Mahesh Jethanandani 210 "; 212 description 213 "This module defines an accounting record for NETCONF operations 214 performed on the server. If these operations are authorized 215 using rules defined by NACM [RFC6536], then that information is 216 also captured by this module. 218 Copyright (c) 2014 IETF Trust and the persons identified as 219 authors of the code. All rights reserved. 221 Redistribution and use in source and binary forms, with or 222 without modification, is permitted pursuant to, and subject 223 to the license terms contained in, the Simplified BSD 224 License set forth in Section 4.c of the IETF Trust's 225 Legal Provisions Relating to IETF Documents 226 (http://trustee.ietf.org/license-info). 228 This version of this YANG module is part of RFC XXXX; see 229 the RFC itself for full legal notices."; 231 revision "2017-03-13" { 232 description 233 "Initial version"; 234 reference 235 "RFC XXXX: NETCONF and RESTCONF Accounting"; 236 } 237 /* 238 * Data definition statements. 239 */ 241 container nam { 242 config false; 243 description 244 "Parameters for NETCONF Accounting Model."; 246 list accounting-record { 247 key "task-id"; 248 description 249 "A list of accounting records generated by the server"; 251 leaf task-id { 252 type uint32; 253 description 254 "The task-id is a monotonically increasing number 255 assigned by the server to capture a single 256 transaction."; 257 } 259 leaf session-id { 260 type nc:session-id-type; 261 description 262 "If this operation happened over NETCONF, this 263 field captures the NETCONF session-id. In case 264 of RESTCONF this field can be left blank."; 265 } 267 leaf acct-code { 268 type enumeration { 269 enum start { 270 description 271 "Start of an accounting record"; 272 } 273 enum stop { 274 description 275 "Indicates the end of an accounting 276 record"; 277 } 278 enum none { 279 description 280 "Indicates a single payload or a 281 continuation of an accounting record."; 282 } 283 } 284 mandatory true; 285 description 286 "Some of the AAA server place a limit on the size 287 of the payload that can be transmitted at any 288 particular time. 290 This field indicates what constitues a complete 291 accounting record by setting up the boundaries. If 292 the accounting record fits within the payload 293 boundary the field should be set to none."; 294 } 296 leaf date-time { 297 type yang:date-and-time; 298 mandatory true; 299 description 300 "The date and time when the operation was 301 requested."; 302 } 304 leaf src-ip { 305 type inet:ip-address; 306 mandatory true; 307 description 308 "The source IP address where the request was made 309 from."; 310 } 312 leaf group { 313 type nacm:group-name-type; 314 mandatory true; 315 description 316 "The name of the group that the user who requested 317 the operation belongs to."; 318 } 320 leaf user { 321 type nacm:user-name-type; 322 description 323 "The user within the group that is requesting this 324 operation."; 325 } 327 leaf path { 328 type nacm:node-instance-identifier; 329 mandatory true; 330 description 331 "Data Node Instance Identifier associated with the 332 data node that the request is being made on. 334 Instance identifiers start with the top-level 335 data node, and a complete identifier is required 336 for this value."; 337 } 339 leaf action { 340 type nacm:access-operations-type; 341 mandatory true; 342 description 343 "The type of NETCONF operation being requested."; 344 } 346 leaf rule { 347 type string { 348 length "1..max"; 349 } 350 description 351 "The name assigned to the rule that was used to 352 authorize the action, if authorization was 353 enabled."; 354 } 356 leaf status { 357 type nacm:action-type; 358 description 359 "Action taken by the server when the above 360 mentioned rule matched, if authorization was 361 enable."; 362 } 363 } 364 } 365 } 367 369 4. IANA Considerations 371 This document makes two requests of IANA. 373 The first request is to register one URI in "The IETF XML Registry". 374 Following the format in The IETF XML Registry [RFC3688], the 375 following needs to be registered. 377 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-am 379 Registrant Contact: The IESG 380 XML: N/A, the requested URI is an XML namespace 382 The second request is to register one module in the "YANG Module 383 Names" registry. Following the format in YANG [RFC7950], the 384 following needs to be registered. 386 Name: ietf-netconf-am 388 Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-am 390 Prefix: nam 392 Reference: RFC XXXX 394 Note to RFC Editor - Please replace XXXX with the RFC id assigned to 395 this draft. 397 5. Security Considerations 399 The YANG module defined in this memo is designed to be accessed using 400 the NETCONF protocol. The lowest NETCONF layer is the secure 401 transport layer and the mandatory-to-implement secure transport is 402 SSH. 404 Most of the data nodes defined in this YANG module are readonly, i.e. 405 config false, and are therefore not vulnerable in network 406 environments. However, they might contain data that might be 407 sensitive and should be protected with the right NACM [RFC6536] 408 rules. 410 6. Acknowledgements 412 7. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, 416 DOI 10.17487/RFC2119, March 1997, 417 . 419 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 420 DOI 10.17487/RFC3688, January 2004, 421 . 423 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 424 and A. Bierman, Ed., "Network Configuration Protocol 425 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 426 . 428 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 429 Protocol (NETCONF) Access Control Model", RFC 6536, 430 DOI 10.17487/RFC6536, March 2012, 431 . 433 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 434 RFC 6991, DOI 10.17487/RFC6991, July 2013, 435 . 437 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 438 RFC 7950, DOI 10.17487/RFC7950, August 2016, 439 . 441 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 442 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 443 . 445 Author's Address 447 Mahesh Jethanandani 448 Cisco Systems, Inc 449 170 West Tasman Drive 450 San Jose, CA 95070 451 USA 453 Email: mjethanandani@gmail.com