--- 1/draft-ietf-i2rs-rib-data-model-08.txt 2017-12-07 20:13:10.105425002 -0800 +++ 2/draft-ietf-i2rs-rib-data-model-09.txt 2017-12-07 20:13:10.217427629 -0800 @@ -1,63 +1,64 @@ Network Working Group L. Wang Internet-Draft Individual Intended status: Standards Track H. Ananthakrishnan -Expires: January 4, 2018 Packet Design +Expires: June 9, 2018 Packet Design M. Chen Huawei A. Dass - S. Kini Ericsson + S. Kini + Individual N. Bahadur Bracket Computing - July 3, 2017 + December 6, 2017 A YANG Data Model for Routing Information Base (RIB) - draft-ietf-i2rs-rib-data-model-08 + draft-ietf-i2rs-rib-data-model-09 Abstract This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. Requirements Language 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 [RFC2119]. Status of This Memo 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/. + Drafts is at https://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 January 4, 2018. + This Internet-Draft will expire on June 9, 2018. Copyright Notice 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 + (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 @@ -67,37 +68,37 @@ 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 7 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 8 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 65 - 8.2. Informative References . . . . . . . . . . . . . . . . . 65 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 66 + 8.2. Informative References . . . . . . . . . . . . . . . . . 67 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 1. Introduction - The Interface to the Routing System (I2RS) - [I-D.ietf-i2rs-architecture] provides read and write access to the - information and state within the routing process that exists inside - the routing elements, this is achieved via protocol message exchange - between I2RS clients and I2RS agents associated with the routing - system. One of the functions of I2RS is to read and write data of - Routing Information Base (RIB). [I-D.ietf-i2rs-usecase-reqs-summary] - introduces a set of RIB use cases. The RIB information model is - defined in [I-D.ietf-i2rs-rib-info-model]. + The Interface to the Routing System (I2RS) [RFC7921] provides read + and write access to the information and state within the routing + process that exists inside the routing elements, this is achieved via + protocol message exchange between I2RS clients and I2RS agents + associated with the routing system. One of the functions of I2RS is + to read and write data of Routing Information Base (RIB). + [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use + cases. The RIB information model is defined in + [I-D.ietf-i2rs-rib-info-model]. This document defines a YANG [RFC6020][RFC6991] data model for the RIB that satisfies the RIB use cases and aligns with the RIB information model. 1.1. Definitions and Acronyms RIB: Routing Information Base Information Model (IM): An abstract model of a conceptual domain, @@ -892,21 +893,21 @@ | +--:(interface-route) | ... +--ro route-installed-state route-installed-state-def +--ro route-state route-state-def +--ro route-change-reason route-change-reason-def Figure 7: Notifications Structure 3. YANG Modules - file "ietf-i2rs-rib@2016-07-04.yang" + file "ietf-i2rs-rib@2017-12-05.yang" module ietf-i2rs-rib { namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-rib"; // replace with iana namespace when assigned prefix "iir"; import ietf-inet-types { prefix inet; //rfc6991 } @@ -945,23 +946,23 @@ Editor: Sriganesh Kini Editor: Nitin Bahadur "; description "This module defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model."; - revision "2016-07-04" { + revision "2017-12-05" { description "initial revision"; - reference "draft-ietf-i2rs-data-model-06"; + reference "draft-ietf-i2rs-data-model-09"; } //Features feature nexthop-tunnel { description "This feature means that a node supports tunnel nexthop capability."; } feature nexthop-chain { @@ -3045,32 +3046,68 @@ -------------------------------------------------------------------- name: ietf-i2rs-rib namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib prefix: iir reference: RFC XXXX -------------------------------------------------------------------- 5. Security Considerations - I2RS protocol provides read and write access to the information and - state (e.g., RIB) within the routing process that exists inside the - routing elements. These information and state are normally - considered sensitive or vulnerable. Improper write operations to - these information and state can have negative effects on the network. + The YANG module defined in this document is designed to be accessed + via network management protocols such as NETCONF [RFC6241] or + RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport + layer, and the mandatory-to-implement secure transport is Secure + Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the + mandatory-to-implement secure transport is TLS [RFC5246]. - The I2RS protocol will provide security mechanisms as required in - [I-D.ietf-i2rs-security-environment-reqs] and - [I-D.ietf-i2rs-protocol-security-requirements]. + The NETCONF access control model [RFC6536] provides the means to + restrict access for particular NETCONF or RESTCONF users to a + preconfigured subset of all available NETCONF or RESTCONF protocol + operations and content. - The YANG data model defined in this document itself does not - introduce extra security issues. + The YANG modules define information that can be configurable in + certain instances, for example, a rib, a route, a nexthop can be + created or deleted by client applications, the YANG modules also + define RPCs that can be used by client applications to add/delete + ribs, routes and nexthops. In such cases, a malicious client could + attempt to remove, add or update a rib, a route, a nexthop, by + creating or deleting corresponding elements in the rib, route and + nexthop lists, respectively. Removing a rib or a route could lead to + disruption or impact in performance of a service, updating a route + may lead to suboptimal path and degradation of service levels as well + as possibly disruption of service. For those reasons, it is + important that the NETCONF access control model is vigorously applied + to prevent misconfiguration by unauthorized clients. + + Specifically, there are a number of data nodes defined in the YANG + module that are writable/creatable/deletable (i.e., config true, + which is the default). These data nodes may be considered sensitive + or vulnerable in some network environments. Write operations (e.g., + edit-config) to these data nodes without proper protection can have a + negative effect on network operations. These are the subtrees and + data nodes and their sensitivity/vulnerability in the ietf-i2rs-rib + module: + + o rib: A malicious client could attempt to remove a rib from a + routing instance, for example in order to sabotage the services + provided by the rib, or to add a rib to a routing instance, hence + to inject unauthorized traffic into the nexthop. + + o route:A malicious client could attempt to remove or add a route + from/to a rib, for example in order to sabotage the services + provided by the rib. + + o nexthop: A malicious client could attempt to remove or add a + nexthop from/to rib, which may lead to suboptimal path and + degradation of service levels as well as possibly disruption of + service. 6. Contributors The following individuals also contribute to this document. o Zekun He, Tencent Holdings Ltd o Sujian Lu, Tencent Holdings Ltd o Jeffery Zhang, Juniper Networks @@ -3080,86 +3117,95 @@ The authors would like to thank Chris Bowers and John Scudder for his review, suggestion and comments to this document. 8. References 8.1. Normative References [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, + . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, - . + . + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "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., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, - . - -8.2. Informative References + . - [I-D.ietf-i2rs-architecture] - Atlas, A., Halpern, J., Hares, S., Ward, D., and T. - Nadeau, "An Architecture for the Interface to the Routing - System", draft-ietf-i2rs-architecture-15 (work in - progress), April 2016. + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . - [I-D.ietf-i2rs-protocol-security-requirements] - Hares, S., Migault, D., and J. Halpern, "I2RS Security - Related Requirements", draft-ietf-i2rs-protocol-security- - requirements-17 (work in progress), September 2016. +8.2. Informative References [I-D.ietf-i2rs-rib-info-model] Bahadur, N., Kini, S., and J. Medved, "Routing Information - Base Info Model", draft-ietf-i2rs-rib-info-model-11 (work - in progress), June 2017. - - [I-D.ietf-i2rs-security-environment-reqs] - Migault, D., Halpern, J., and S. Hares, "I2RS Environment - Security Requirements", draft-ietf-i2rs-security- - environment-reqs-05 (work in progress), March 2017. + Base Info Model", draft-ietf-i2rs-rib-info-model-12 (work + in progress), November 2017. [I-D.ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 (work in progress), November 2016. + [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. + Nadeau, "An Architecture for the Interface to the Routing + System", RFC 7921, DOI 10.17487/RFC7921, June 2016, + . + Authors' Addresses Lixing Wang Individual Email: wang_little_star@sina.com Hariharan Ananthakrishnan Packet Design Email: hari@packetdesign.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Amit Dass Ericsson - Torshamnsgatan 48. - Stockholm 16480 - Sweden Email: amit.dass@ericsson.com Sriganesh Kini - Ericsson + Individual - Email: sriganesh.kini@ericsson.com + Email: sriganeshkini@gmail.com Nitin Bahadur Bracket Computing Email: nitin_bahadur@yahoo.com