--- 1/draft-ietf-i2rs-yang-network-topo-15.txt 2017-09-19 12:13:23.799649231 -0700 +++ 2/draft-ietf-i2rs-yang-network-topo-16.txt 2017-09-19 12:13:23.891651433 -0700 @@ -1,27 +1,27 @@ Network Working Group A. Clemm Internet-Draft Huawei Intended status: Standards Track J. Medved -Expires: March 9, 2018 Cisco +Expires: March 23, 2018 Cisco R. Varga Pantheon Technologies SRO N. Bahadur Bracket Computing H. Ananthakrishnan Packet Design X. Liu Jabil - September 5, 2017 + September 19, 2017 A Data Model for Network Topologies - draft-ietf-i2rs-yang-network-topo-15.txt + draft-ietf-i2rs-yang-network-topo-16.txt Abstract This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The data model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory data models. Status of This Memo @@ -31,21 +31,21 @@ 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 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 March 9, 2018. + This Internet-Draft will expire on March 23, 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -77,36 +77,36 @@ 4.4.10. Supporting client-configured and system-controlled network topology . . . . . . . . . . . . . . . . . . 16 4.4.11. Identifiers of string or URI type . . . . . . . . . . 17 5. Interactions with Other YANG Modules . . . . . . . . . . . . 18 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Defining the Abstract Network: ietf-network.yang . . . . 18 6.2. Creating Abstract Network Topology: ietf-network- topology.yang . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 33 - Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 34 - A.1. Fetching Topology from a Network Element . . . . . . . . 34 - A.2. Modifying TE Topology Imported from an Optical Controller 34 - A.3. Annotating Topology for Local Computation . . . . . . . . 35 + Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 35 + A.1. Fetching Topology from a Network Element . . . . . . . . 35 + A.2. Modifying TE Topology Imported from an Optical Controller 35 + A.3. Annotating Topology for Local Computation . . . . . . . . 36 A.4. SDN Controller-Based Configuration of Overlays on Top of - Underlays . . . . . . . . . . . . . . . . . . . . . . . . 35 + Underlays . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. Appendix: Companion YANG models for non-NMDA - compliant implementations . . . . . . . . . . . . . 35 - B.1. YANG Model for Network State . . . . . . . . . . . . . . 36 - B.2. YANG Data Model for Network Topology State . . . . . . . 40 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 + compliant implementations . . . . . . . . . . . . . 36 + B.1. YANG Model for Network State . . . . . . . . . . . . . . 37 + B.2. YANG Data Model for Network Topology State . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction This document introduces an abstract (base) YANG [RFC7950] data model to represent networks and topologies. The data model is divided into two parts. The first part of the data model defines a network data model that enables the definition of network hierarchies (i.e. network stacks) and to maintain an inventory of nodes contained in a network. The second part of the data model augments the basic network data model with information to describe topology information. @@ -825,21 +825,21 @@ routing process (such as OSPF) into the without relying on a configuration datastore. 6. YANG Modules 6.1. Defining the Abstract Network: ietf-network.yang NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of publication when published. - file "ietf-network@2017-09-05.yang" + file "ietf-network@2017-09-19.yang" module ietf-network { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nd; import ietf-inet-types { prefix inet; reference "RFC 6991"; } @@ -877,38 +877,38 @@ 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 - draft-ietf-i2rs-yang-network-topo-15; + draft-ietf-i2rs-yang-network-topo-16; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-09-05 { + revision 2017-09-19 { description "Initial revision. NOTE TO RFC EDITOR: (1) Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-15 with + to draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of publication when published. "; reference - "draft-ietf-i2rs-yang-network-topo-15"; + "draft-ietf-i2rs-yang-network-topo-16"; } typedef node-id { type inet:uri; description "Identifier for a node. The precise structure of the node-id will be up to the implementation. Some implementations MAY for example, pick a uri that includes the network-id as part of the path. The identifier SHOULD be chosen such that the same node in a real network topology will always be @@ -1036,38 +1036,38 @@ } } 6.2. Creating Abstract Network Topology: ietf-network-topology.yang NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of publication when published. - file "ietf-network-topology@2017-09-05.yang" + file "ietf-network-topology@2017-09-19.yang" module ietf-network-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; prefix lnk; import ietf-inet-types { prefix inet; reference "RFC 6991"; } import ietf-network { prefix nd; reference - "draft-ietf-i2rs-yang-network-topo-15 + "draft-ietf-i2rs-yang-network-topo-16 NOTE TO RFC EDITOR: (1) Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of publication when published."; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: @@ -1100,35 +1100,35 @@ 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 - draft-ietf-i2rs-yang-network-topo-15; + draft-ietf-i2rs-yang-network-topo-16; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-09-05 { + revision 2017-09-19 { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-15 with + to draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; reference - "draft-ietf-i2rs-yang-network-topo-15"; + "draft-ietf-i2rs-yang-network-topo-16"; } typedef link-id { type inet:uri; description "An identifier for a link in a topology. The precise structure of the link-id will be up to the implementation. The identifier SHOULD be chosen such that the same link in a real network topology will always be identified through the @@ -1370,92 +1370,121 @@ XML: N/A; the requested URI is an XML namespace. URI:urn:ietf:params:xml:ns:yang:ietf-network-topology-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]: NOTE TO THE RFC EDITOR: In the list below, please replace references - to "draft-ietf-i2rs-yang-network-topo-15 (RFC form)" with RFC number + to "draft-ietf-i2rs-yang-network-topo-16 (RFC form)" with RFC number when published (i.e. RFC xxxx). Name: ietf-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network Prefix: nd - Reference: draft-ietf-i2rs-yang-network-topo-15.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-16.txt (RFC form) Name: ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Prefix: lnk - Reference: draft-ietf-i2rs-yang-network-topo-15.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-16.txt (RFC form) Name: ietf-network-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state Prefix: nd-s - Reference: draft-ietf-i2rs-yang-network-topo-15.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-16.txt (RFC form) Name: ietf-network-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Prefix: lnk-s - Reference: draft-ietf-i2rs-yang-network-topo-15.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-16.txt (RFC form) 8. Security Considerations - The YANG module defined in this document is designed to be accessed + The YANG modules defined in this document are 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 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. - Rules expressed in NACM can be applied analogously also to other - protocols that attempt access to YANG-defined data. In fact, it - needs to be applied in the same way and should, like YANG, thus be - considered independent of any particular protocol that is used to - access YANG-defined data. Otherwise, access control rules defined by - NACM could be very easily circumvented simply by using another access - mechanism which does not enforce NACM. The alternative of mandating - the introduction of mechanisms parallel to NACM that specify the same - access control rules for other transports is clearly undesirable, as - this would not only inhibit ease-of-use of systems that implement - multiple protocols to access YANG data, but also open the specter of - security holes due to inconsistencies in articulation and enforcement - of rules across mechanisms that are essentially redundant. - - The YANG module defines information that can be configurable in + The YANG modules define information that can be configurable in certain instances, for example in the case of overlay topologies that can be created by client applications. In such cases, a malicious client could introduce topologies that are undesired. Specifically, a malicious client could attempt to remove or add a node, a link, a termination point, by creating or deleting corresponding elements in the node, link, and termination point lists, respectively. In the case of a topology that is learned, the server will automatically prohibit such misconfiguration attempts. In the case of a topology that is configured, i.e. whose origin is "intended", the undesired configuration could become effective and be reflected in the operational datastore, leading to disruption of services provided via this topology might be disrupted. For example, the topology could be "cut" or be configured in a suboptimal way, leading to increased consumption of resources in the underlay network due to resulting routing and bandwidth utilization inefficiencies. Likewise, it could lead to 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 topology misconfiguration by unauthorized clients. + Specifically, there are a number of data nodes defined in these 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-network + module: + + o network: A malicious client could attempt to remove or add a + network in an attempt to remove an overlay topology, or create an + unauthorized overlay. + + o supporting-network: A malicious client could attempt to disrupt + the logical structure of the model, resulting in lack of overall + data integrity and making it more difficult to, for example, + troubleshoot problems rooted in the layering of network + topologies. + + o node: A malicious client could attempt to remove or add a node + from network, for example in order to sabotage the topology of a + network overlay. + + o supporting-node: A malicious client could attempt to change the + supporting-node in order to sabotage the layering of an overlay. + + These are the subtrees and data nodes and their sensitivity/ + vulnerability in the ietf-network-topology module: + + o link: A malicious client could attempt to remove a link from a + topology, or add a new link, or manipulate the way the link is + layered over supporting links, or modify the source or destination + of the link. Either way, the structure of the topology would be + sabotaged, which could, for example, result in an overlay topology + that is less than optimal. + + o termination-point: A malicious client could attempt to remove + termination points from a node, or add "phantom" termination + points to a node, or change the layering dependencies of + termination points, again in an attempt to sabotage the integrity + of a topology and potentially disrupt orderly operations of an + overlay. + 9. Contributors The data model presented in this paper was contributed to by more people than can be listed on the author list. Additional contributors include: o Vishnu Pavan Beeram, Juniper o Ken Gray, Cisco @@ -1530,21 +1559,21 @@ [I-D.draft-ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 03, November 2016. [I-D.draft-ietf-i2rs-yang-l3-topology] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", I-D draft-ietf-i2rs-yang-l3- - topology-10, July 2017. + topology-11, September 2017. [I-D.draft-ietf-netconf-yang-push] Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to YANG datastore push updates", I-D draft- ietf-netconf-yang-push-08, August 2017. [I-D.draft-ietf-netmod-yang-tree-diagrams] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", I-D draft-ietf-netmod-yang-tree-diagrams, June 2017. @@ -1672,32 +1701,32 @@ defined in an appendix. As the structure of both modules mirrors that of their underlying modules, the YANG tree is not depicted separately. B.1. YANG Model for Network State NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of the publication when published. - file "ietf-network-state@2017-09-05.yang" + file "ietf-network-state@2017-09-19.yang" module ietf-network-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-state"; prefix nd-s; import ietf-network { prefix nd; reference - "draft-ietf-i2rs-yang-network-topo-15 + "draft-ietf-i2rs-yang-network-topo-16 NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: WG List: @@ -1737,38 +1766,38 @@ 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 - draft-ietf-i2rs-yang-network-topo-15; + draft-ietf-i2rs-yang-network-topo-16; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-09-05 { + revision 2017-09-19 { description "Initial revision. NOTE TO RFC EDITOR: (1) Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-15 with + to draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of the publication when published."; reference - "draft-ietf-i2rs-yang-network-topo-15"; + "draft-ietf-i2rs-yang-network-topo-16"; } grouping network-ref { description "Contains the information necessary to reference a network, for example an underlay network."; leaf network-ref { type leafref { path "/nd-s:networks/nd-s:network/nd-s:network-id"; require-instance false; @@ -1873,40 +1902,40 @@ } } } B.2. YANG Data Model for Network Topology State NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of the publication when published. - file "ietf-network-topology-state@2017-09-05.yang" + file "ietf-network-topology-state@2017-09-19.yang" module ietf-network-topology-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state"; prefix lnk-s; import ietf-network-state { prefix nd-s; reference - "draft-ietf-i2rs-yang-network-topo-15 + "draft-ietf-i2rs-yang-network-topo-16 NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; } import ietf-network-topology { prefix lnk; reference - "draft-ietf-i2rs-yang-network-topo-15 + "draft-ietf-i2rs-yang-network-topo-16 NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: WG List: Editor: Alexander Clemm @@ -1944,38 +1973,38 @@ Copyright (c) 2017 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 - draft-ietf-i2rs-yang-network-topo-15; + draft-ietf-i2rs-yang-network-topo-16; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-15 with RFC + draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-09-05 { + revision 2017-09-19 { description "Initial revision. NOTE TO RFC EDITOR: (1) Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-15 with + to draft-ietf-i2rs-yang-network-topo-16 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of publication when published."; reference - "draft-ietf-i2rs-yang-network-topo-15"; + "draft-ietf-i2rs-yang-network-topo-16"; } grouping link-ref { description "References a link in a specific network."; leaf link-ref { type leafref { path "/nd-s:networks/nd-s:network[nd-s:network-id=current()"+ "/../network-ref]/lnk-s:link/lnk-s:link-id"; require-instance false;