idnits 2.17.1 draft-haas-i2rs-netmod-netconf-requirements-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '...f the SSH server MUST be verified and ...' RFC 2119 keyword, line 208: '.... The identity of the SSH client MUST...' RFC 2119 keyword, line 238: '...condary identity SHOULD be included fo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2015) is 3309 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-05 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-00 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-traceability-02 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-call-home-00 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Haas, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Informational March 8, 2015 5 Expires: September 9, 2015 7 I2RS requirements for netmod/netconf 8 draft-haas-i2rs-netmod-netconf-requirements-01 10 Abstract 12 This document covers requests to the netmod and netconf Working 13 Groups for functionality to support requirements to implement the 14 I2RS architecture. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 9, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. I2RS Requirements . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Data Store Requirements . . . . . . . . . . . . . . . . . 3 53 2.1.1. A Separate Ephemeral Datastore . . . . . . . . . . . 3 54 2.1.2. Tagged Ephemeral Modules in the Running Datastore . . 4 55 2.1.3. Permitting Existing Configuration State to be Made 56 Optionally Ephemeral . . . . . . . . . . . . . . . . 4 57 2.2. Mutual Authentication Requirements . . . . . . . . . . . 5 58 2.2.1. NETCONF over SSH . . . . . . . . . . . . . . . . . . 5 59 2.2.2. NETCONF/RESTCONF over TLS . . . . . . . . . . . . . . 5 60 2.3. Identity, Secondary-Identity Requirements; Priority 61 Requirements; Implications . . . . . . . . . . . . . . . 5 62 2.3.1. Identity Requirements . . . . . . . . . . . . . . . . 5 63 2.3.2. Priority Requirements . . . . . . . . . . . . . . . . 6 64 2.3.3. Implications of Idenities and Priorities on Internal 65 State . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Access Control Model Requirements . . . . . . . . . . . . 6 67 2.4.1. Data Store Implications . . . . . . . . . . . . . . . 6 68 2.4.2. I2RS Priority . . . . . . . . . . . . . . . . . . . . 6 69 2.5. Connectivity Requirements . . . . . . . . . . . . . . . . 6 70 2.6. Notification and Subscription Requirements . . . . . . . 7 71 2.7. Transaction Requirements . . . . . . . . . . . . . . . . 7 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The Interface to the Routing System (I2RS) Working Group is chartered 81 with providing architecture and mechanisms to inject into and 82 retrieve information from the routing system. The I2RS Architecture 83 document [I-D.ietf-i2rs-architecture] abstractly documents a number 84 of requirements for implementing the I2RS requirements. 86 The I2RS Working Group has chosen to use the YANG data modeling 87 language [RFC6020] as the basis to implement its mechanisms. 89 Additionally, the I2RS Working group has chosen to use the NETCONF 90 [RFC6241] and its similar but lighter-weight relative RESTCONF 91 [I-D.bierman-netconf-restconf] as the protocols for carrying I2RS. 93 While YANG, NETCONF and RESTCONF are a good starting basis for I2RS, 94 there are some things needed from each of them in order for I2RS to 95 be implemented. 97 Note that this draft does not attempt to address specific 98 implementation of I2RS requirements that the existing YANG, RESTCONF 99 and NETCONF mechanisms are expected to cover. A separate draft will 100 be issued for the consumption of the I2RS Working Group for such 101 cases. 103 2. I2RS Requirements 105 2.1. Data Store Requirements 107 One of the key mechanisms in I2RS is the ability to inject 108 configuration state into a network element on an ephemeral basis. 109 While at first glance this may seem equivalent to the writable- 110 running datastore in NETCONF, running-config can be copied to a 111 persistant data store, like startup config. The author wishes to 112 prevent any action that would lead to preserving any configuration 113 state entered via the I2RS agent across reboots. If state has to be 114 restored, it should be solely by replay actions from I2RS client via 115 I2RS agent. 117 A few options for implementing such ephemeral configuration suggest 118 themselves, as do some possible problems with such an implementation: 120 1. A separate ephemeral datastore. The semantics of this datastore 121 is that all configuration state is known ahead of time to not 122 survive reboot and is not to be copied into persistent storage. 123 Such a datastore could be referenced by NETCONF and RESTCONF 124 using existing semantics, such as "target" and "source". 126 2. Configuration state in the existing running datastore where the 127 module is "tagged ephemeral". 129 3. Permitting existing configuration to be optionally configured as 130 ephemeral. As an example, the NETCONF server advertises in its 131 message if it supports the specified YANG module 132 persistently and/or ephemerally. 134 2.1.1. A Separate Ephemeral Datastore 136 The primary advantage of a fully separate datastore is that the 137 semantics of its contents are always clearly ephemeral. It also 138 provides strong segregation of I2RS configuration and operational 139 state from the rest of the system within the network element. 141 The most obvious disadvantage of such a fully separate datastore is 142 that interaction with the network element's operational or 143 configuration state becomes significantly more difficult. As an 144 example, a BGP I2RS use case would be the dynamic instantiation of a 145 BGP peer. While it is readily possible to re-use any defined 146 groupings from an IETF-standardized BGP module in such an I2RS 147 ephemeral datastore's modules, one cannot currently reference state 148 from one datastore to another. 150 For example, XPath queries are done in the context document of the 151 datastore in question and thus it is impossible for an I2RS model to 152 fulfil a "must" or "when" requirement in the BGP module in the 153 standard data stores. To implement such a mechanism would require 154 appropriate semantics for XPath. 156 2.1.2. Tagged Ephemeral Modules in the Running Datastore 158 Presume a YANG keyword that flagged an entire module as being 159 ephemeral. In such a case, entire modules could be crafted for I2RS 160 (and other) purposes wherein the configuration state in the module 161 had ephemeral properties. The primary property is that copy 162 operations would not be able to cause the I2RS state to persist. 164 An obvious issue with this is the muddying of the semantics of 165 existing NETCONF/RESTCONF operations. For example, get-config is 166 expected to return the configuration state for the network element, 167 but the knowledge that the configuration state may not persist is 168 important. This may require alterations to get-config (and similar 169 commands) along with the ambiguity of copy-config not picking up the 170 ephemeral modules. 172 Providing additional parameters to the various configuration related 173 operations in NETCONF/RESTCONF would likely be required. 175 2.1.3. Permitting Existing Configuration State to be Made Optionally 176 Ephemeral 178 In YANG, configuration state is distinguished from operational state 179 using "config true" vs. "config false". One way to implement I2RS 180 state would be to introduce a third option, "config ephemeral", to 181 configuration. 183 A form of this option was previously discussed in 184 [I-D.rfernando-i2rs-yang-mods]. The suggestion of "config ephemeral" 185 is made instead due to potential non-I2RS interest in this feature at 186 the microphone during the IETF-90 session of netmod in Toronto, 187 Canada. 189 2.2. Mutual Authentication Requirements 191 "Mutual authentication between the I2RS Client and I2RS Agent is 192 required. An I2RS Client must be able to trust that the I2RS 193 Agent is attached to the relevant Routing Element so that write/ 194 modify operations are correctly applied and so that information 195 received from the I2RS Agent can be trusted by the I2RS Client." 197 Implementing the mutual authentication requirements for I2RS in each 198 of the underlying protocols and their transports have some 199 implications to be discussed. 201 2.2.1. NETCONF over SSH 203 The NETCONF service over SSH is believed to provide the necessary 204 mutual authentication services required by I2RS. Per [RFC6242]: "The 205 identity of the SSH server MUST be verified and authenticated by the 206 SSH client according to local policy before password-based 207 authentication data or any configuration or state data is sent to or 208 received from the SSH server. The identity of the SSH client MUST 209 also be verified and authenticated by the SSH server according to 210 local policy to ensure that the incoming SSH client request is 211 legitimate before any configuration or state data is sent to or 212 received from the SSH client. Neither side should establish a 213 NETCONF over SSH connection with an unknown, unexpected, or incorrect 214 identity on the opposite side." 216 2.2.2. NETCONF/RESTCONF over TLS 218 Agent validation of the I2RS client is mandated over TLS in an I2RS 219 context. The client shall also validate the Agent using its server 220 certificate. 222 2.3. Identity, Secondary-Identity Requirements; Priority Requirements; 223 Implications 225 2.3.1. Identity Requirements 227 I2RS requires clients to have an identity. This identity will be 228 used by the Agent authentication mechanism over the appropriate 229 protocol. 231 I2RS also permits clients to have a secondary identity which may be 232 used for troubleshooting. This secondary identity is an opaque 233 value. [I-D.ietf-i2rs-traceability] provides an example of how the 234 secondary identity can be used for traceability. 236 If in support of the I2RS prioririty requirements if it is determined 237 to be necessary to annotate state with the client that added it, the 238 secondary identity SHOULD be included for troubleshooting. 240 2.3.2. Priority Requirements 242 To support Multi-Headed Control, I2RS requires that there be a 243 decidable means of arbitrating the correct state of data when 244 multiple clients attempt to manipulate the same piece of data. This 245 is done via a priority mechanism with the highest priority winning. 246 This priority may vary on a per-node or subtree basis based for a 247 given identity. 249 2.3.3. Implications of Idenities and Priorities on Internal State 251 Given the requirements for I2RS identities and priority arbitration, 252 I2RS configured state must have "meta-data" that includes the 253 identity that caused it to come into being. Agents must also be able 254 to map priority on a particular piece of configuration state vs. the 255 identity provisioning it for arbitration purposes. Such mapping 256 might be represented as part of the "meta-data" or potentially a 257 distinct mapping database of identity vs. priority vs. configuration 258 state. Such a mapping may be implemented using an extension to the 259 NETCONF Access Control Model [RFC6536]. 261 2.4. Access Control Model Requirements 263 2.4.1. Data Store Implications 265 As noted above, one of the possible options for implementing the I2RS 266 ephemeral behavior is a separate data store. However, this clashes 267 with Section 3.2 of [RFC6536] which limits itself to the well- known 268 data stores. 270 2.4.2. I2RS Priority 272 A likely implementation of priority arbitration would be to extend 273 the NACM model to also contain criteria for I2RS priority. 275 2.5. Connectivity Requirements 277 I2RS does not require clients to maintain active communication 278 channels with their agents. Agents thus require the ability to open 279 communication channels back to clients to satisfy previously 280 requested information. 282 [I-D.ietf-netconf-call-home] describes a mechanism by which NETCONF 283 may "phone home" using SSH and TLS. 285 While NETCONF notifications currently permit a different client to 286 establish a session to an agent specifically for notification 287 purposes, the I2RS use case typically expects that provisioning of 288 notifications is centrally managed and that systems receiving the 289 notifications should not need to be individually to be provisioned. 291 2.6. Notification and Subscription Requirements 293 [I-D.ietf-i2rs-pub-sub-requirements] has been published and contains 294 the requirements for I2RS for publication and subscription services. 296 2.7. Transaction Requirements 298 Each transaction should be treated as atomic and providing full 299 functionality. If the configuration change is not functionally 300 complete, then the transaction should fail and be rolled back 301 (rollback 0). Example, I2RS agents wants to configure BGP: 303 routing-options { 304 autonomous-system autonomous-system; 305 } 306 protocols { 307 bgp { 308 group group-name { 309 peer-as autonomous-system; 310 type type; 311 neighbor address; 312 } 313 } 314 } 316 If a statement like neighbor address is missing or is mis-formatted, 317 like 300.127.5.23, configuration is not functional, transaction 318 should fail and rollback 0 should be performed by the I2RS agent on 319 the ephemeral config store. If the neighbor address is in the 320 transaction, but the address is not reachable or similar, transaction 321 is accepted, but notification will be sent that BGP peering can't be 322 established. 324 3. IANA Considerations 326 This document introduces no new considerations to IANA. 328 4. Security Considerations 330 TBD 332 5. Acknowledgements 334 This document is an attempt to distill length conversations on the 335 I2RS mailing list for an architecture that was for a long period of 336 time a moving target. Some individuals in particular warrant 337 speicfic mention for their extensive help in providing the basis for 338 this document: 340 o Alia Atlas 342 o Andy Bierman 344 o Martin Bjorklund 346 o Dean Bogdanavich 348 o Rex Fernando 350 o Joel Halpern 352 o Susan Hares 354 o Thomas Nadeau 356 o Juergen Schoenwaelder 358 o Kent Watsen 360 6. Normative References 362 [I-D.bierman-netconf-restconf] 363 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 364 "RESTCONF Protocol", draft-bierman-netconf-restconf-04 365 (work in progress), February 2014. 367 [I-D.ietf-i2rs-architecture] 368 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 369 Nadeau, "An Architecture for the Interface to the Routing 370 System", draft-ietf-i2rs-architecture-05 (work in 371 progress), July 2014. 373 [I-D.ietf-i2rs-pub-sub-requirements] 374 Voit, E., Clemm, A., and A. Prieto, "Requirements for 375 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 376 requirements-00 (work in progress), March 2015. 378 [I-D.ietf-i2rs-traceability] 379 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 380 the Routing System (I2RS) Traceability: Framework and 381 Information Model", draft-ietf-i2rs-traceability-02 (work 382 in progress), March 2015. 384 [I-D.ietf-netconf-call-home] 385 Watsen, K., "NETCONF Call Home", draft-ietf-netconf-call- 386 home-00 (work in progress), September 2014. 388 [I-D.rfernando-i2rs-yang-mods] 389 Fernando, R., pals, p., Madhayyan, M., and A. Clemm, "YANG 390 modifications for I2RS", draft-rfernando-i2rs-yang-mods-00 391 (work in progress), February 2013. 393 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 394 Network Configuration Protocol (NETCONF)", RFC 6020, 395 October 2010. 397 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 398 Bierman, "Network Configuration Protocol (NETCONF)", RFC 399 6241, June 2011. 401 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 402 Shell (SSH)", RFC 6242, June 2011. 404 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 405 Protocol (NETCONF) Access Control Model", RFC 6536, March 406 2012. 408 Author's Address 410 Jeffrey Haas (editor) 411 Juniper Networks 413 Email: jhaas@juniper.net