idnits 2.17.1 draft-ietf-netconf-call-home-03.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 draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 1997-03-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2015) is 3390 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Updates: 4253 (if approved) January 13, 2015 5 Intended status: Standards Track 6 Expires: July 17, 2015 8 NETCONF Call Home and RESTCONF Call Home 9 draft-ietf-netconf-call-home-03 11 Abstract 13 This document presents NETCONF Call Home and RESTCONF Call Home, 14 which respectively enable a NETCONF/RESTCONF server to initiate a 15 secure connection to a NETCONF/RESTCONF client. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains many placeholder values that need to be replaced 20 with finalized values at the time of publication. This note 21 summarizes all of the substitutions that are needed. Please note 22 that no other RFC Editor instructions are specified anywhere else in 23 this document. 25 Artwork in this document contains placeholder references for this 26 draft. Please apply the following replacement: 28 o "XXXX" --> the assigned RFC value for this draft 30 This document contains references to other drafts in progress, both 31 in the Normative References section, as well as in body text 32 throughout. Please update the following references to reflect their 33 final RFC assignments: 35 o draft-ietf-netconf-restconf 37 o draft-ietf-netconf-server-model 39 Artwork in this document contains placeholder values for ports 40 pending IANA assignment from "draft-ietf-netconf-call-home". Please 41 apply the following replacements: 43 o "PORT-X" --> the assigned port value for "netconf-ch-ssh" 45 o "PORT-Y" --> the assigned port value for "netconf-ch-tls" 47 o "PORT-Z" --> the assigned port value for "restconf-ch-tls" 48 The following two Appendix sections are to be removed prior to 49 publication: 51 o Appendix A. Change Log 53 o Appendix B. Open Issues 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at http://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on July 17, 2015. 72 Copyright Notice 74 Copyright (c) 2015 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (http://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 91 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4 92 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 93 1.4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 5 94 2. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 5 95 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5 96 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 6 97 3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 6 98 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 99 3.2. Server Identification and Verification . . . . . . . . . 7 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 102 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 103 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 104 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 105 7.2. Informative References . . . . . . . . . . . . . . . . . 11 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 107 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 108 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 109 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 12 110 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 12 112 1. Introduction 114 This document presents NETCONF Call Home and RESTCONF Call Home, 115 which respectively enable a NETCONF/RESTCONF server to initiate a 116 secure connection to a NETCONF/RESTCONF client. The NETCONF protocol 117 is described in [RFC6241] and the RESTCONF is described in 118 [draft-ietf-netconf-restconf]. 120 Both NETCONF Call Home and RESTCONF Call Home preserve the client/ 121 server roles of underlying transport, as when compared to standard 122 NETCONF and RESTCONF connections. Specifically, regardless if call 123 home is used or not, the SSH and TLS client/server roles are the 124 same. The SSH protocol is defined in [RFC4253] and the TLS protocol 125 is defined in [RFC5246]. 127 Ensuring consistency in the SSH and TLS roles is both necessary and 128 desirable. Ensuring consistency is necessary for the SSH protocol, 129 as SSH channels and subsystems can only be opened on the SSH server, 130 which thus must always be the NETCONF server, in order to support 131 NETCONF over SSH [RFC6242]. Ensuring consistency is desirable, for 132 both the SSH and TLS protocols, as it conveniently leverages 133 infrastructure that may be deployed for host-key or certificate 134 verification and user authentication. 136 1.1. Motivation 138 Call home is generally useful for both the initial deployment and on- 139 going management of networking elements. Here are some scenarios 140 enabled by call home: 142 o The network element may proactively call home after being powered 143 on for the first time in order to register itself with its 144 management system. 146 o The network element may access the network in a way that 147 dynamically assigns it an IP address and it doesn't register its 148 assigned IP addressed to a mapping service, thus complicating the 149 ability for a management system to connect to it. 151 o The network element may be deployed behind a firewall that 152 implements network address translation (NAT) for all internal 153 network IP addresses, thus complicating the ability for a 154 management system to connect to it. 156 o The network element may be deployed behind a firewall that doesn't 157 allow any management access to the internal network. 159 o The network element may be configured in "stealth mode" and thus 160 doesn't have any open ports for the management system to connect 161 to. 163 o The operator may prefer to have network elements initiate 164 management connections, believing it is easier to secure one open- 165 port in the data center than to have an open port on each network 166 element in the network. 168 As the NETCONF and RESTCONF protocols become increasingly popular for 169 programatic management of networking elements, having call home 170 support for these two protocols is particularly desirable. 172 1.2. Requirements Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 1.3. Applicability Statement 180 The techniques described in this document are suitable for network 181 management scenarios such as the ones described in Section 1.1. 182 However, these techniques SHOULD only be used for NETCONF Call Home 183 and RESTCONF Call Home, as described in this document. 185 The reason for this restriction is that different protocols have 186 different security assumptions. The NETCONF and RESTCONF protocols 187 require clients and servers to verify the identity of the other party 188 before starting the NETCONF/RESTCONF protocol (section 2.2 of 189 [RFC6241] and sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 191 This contrasts with the base SSH and TLS protocols, which do not 192 require programmatic verification of the other party (section 9.3.4 193 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 194 In such circumstances, allowing the SSH/TLS server to contact the 195 SSH/TLS client would open new vulnerabilities. Any use of call home 196 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 197 thorough, contextual security analysis. 199 1.4. Update to RFC 4253 201 This document updates the SSH Transport Layer Protocol [RFC4253] only 202 in removing the "The client initiates the connection" statement made 203 in Section 4 (Connection Setup). This document assumes that the 204 reference to "connection" refers to the underlying transport 205 connection (e.g., TCP), which the NETCONF server would initiate in a 206 call home connection using the SSH protocol, even though it will not 207 take on the role of the SSH client. Security implications related to 208 this change are discussed in Security Considerations (Section 4). 210 2. The NETCONF or RESTCONF Server 212 2.1. Protocol Operation 214 o The NETCONF/RESTCONF server initiates a TCP connection request 215 (SYN) to the NETCONF/RESTCONF client. The server SHOULD default 216 to connecting to one of the IANA-assigned ports defined in section 217 Section 5, but MAY be configured to use a non-default port. 219 o The TCP connection request is accepted and a TCP connection is 220 established. 222 o Using this TCP connection, the NETCONF/RESTCONF server MUST 223 immediately start using either the SSH-server [RFC4253] or the 224 TLS-server [RFC5246] protocol, depending on how it is configured. 225 For example, assuming the use of the IANA-assigned ports, the SSH- 226 server protocol is used for PORT-X and the TLS-server protocol is 227 used for either port PORT-Y or PORT-Z. 229 o Once the SSH or TLS connection is established, the NETCONF/ 230 RESTCONF server MUST immediately start using either the NETCONF- 231 server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] 232 protocol, depending on how it is configured. Assuming the use of 233 the IANA-assigned ports, the NETCONF-server protocol is used for 234 PORT-X or PORT-Y and the RESTCONF-server protocol is used for 235 PORT-Z. 237 o The NETCONF protocol's binding to SSH and TLS is defined in 238 [RFC6242] and [RFC5539] respectively. The RESTCONF protocol's 239 binding to TLS is is defined in [RFC7230]. 241 2.2. Configuration Data Model 243 How to configure a NETCONF or RESTCONF server to initiate a call home 244 connection is outside the scope of this document, as implementations 245 can support this protocol using proprietary configuration data 246 models. That said, a YANG [RFC6020] model for configuring both 247 NETCONF Call Home and RESTCONF Call Home is provided in 248 [draft-ietf-netconf-server-model]. 250 3. The NETCONF or RESTCONF Client 252 3.1. Protocol Operation 254 o The NETCONF/RESTCONF client listens for TCP connections from 255 NETCONF/RESTCONF servers. The client SHOULD default to listening 256 for connections on the IANA-assigned ports defined in section 257 Section 5, but MAY be configured to use a non-default port. 259 o The NETCONF/RESTCONF client accepts an incoming TCP connection 260 request and a TCP connection is established. 262 o Using this TCP connection, the NETCONF/RESTCONF client MUST 263 immediately start using either the SSH-client [RFC4253] or the 264 TLS-client [RFC5246] protocol, depending on how it is configured. 265 For example, assuming the use of the IANA-assigned ports, the SSH- 266 client protocol is used for PORT-X and the TLS-client protocol is 267 used for either port PORT-Y or PORT-Z. 269 o Once the SSH or TLS connection is established, the NETCONF/ 270 RESTCONF client MUST immediately start using either the NETCONF- 271 client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] 272 protocol, depending on how it is configured. Assuming the use of 273 the IANA-assigned ports, the NETCONF-client protocol is used for 274 PORT-X or PORT-Y and the RESTCONF-client protocol is used for 275 PORT-Z. 277 o The NETCONF protocol's binding to SSH and TLS is defined in 278 [RFC6242] and [RFC5539] respectively. The RESTCONF protocol's 279 binding to TLS is is defined in [RFC7230]. 281 3.2. Server Identification and Verification 283 Under normal circumstances, a NETCONF/RESTCONF client initiates the 284 connection to the NETCONF/RESTCONF server. This action provides 285 essential input used to verify the NETCONF/RESTCONF server's 286 identity. For instance, when using TLS, the input can be compared to 287 the domain names and IP addresses encoded in X.509 certificates. 288 Similarly, when using SSH, the input can be compared to information 289 persisted previously. 291 However, when receiving a call home connection, the NETCONF/RESTCONF 292 client does not have any context leading it to know the connection is 293 from a particular NETCONF/RESTCONF server. Thus the NETCONF/RESTCONF 294 client must derive the NETCONF/RESTCONF server's identity using 295 information provided by the network and the NETCONF/RESTCONF server 296 itself. This section describes strategies a NETCONF/RESTCONF client 297 can use to identify a NETCONF/RESTCONF server. 299 In addition to identifying a NETCONF/RESTCONF server, a NETCONF/ 300 RESTCONF client must also be able to verify the NETCONF/RESTCONF 301 server's credentials. Verifying a NETCONF/RESTCONF server's 302 credentials is necessary under normal circumstances but, due to call 303 home being commonly used for newly deployed NETCONF/RESTCONF servers, 304 how to verify its credentials the very first time becomes a prominent 305 concern. Therefore, this section also describes strategies a 306 NETCONF/RESTCONF client can use to verify a NETCONF/RESTCONF server's 307 credentials. 309 The first information a NETCONF/RESTCONF client learns from a call 310 home connection is the IP address of the NETCONF/RESTCONF server, as 311 provided by the source address of the TCP connection. This IP 312 address could be used as an identifier directly, but doing so would 313 only work in networks that use known static addresses, in which case 314 a standard NETCONF/RESTCONF connection would have worked just as 315 well. Due to this limited use, it is not recommended to identify a 316 NETCONF/RESTCONF server based on its source IP address. 318 The next information a NETCONF/RESTCONF client learns is provided by 319 the NETCONF/RESTCONF server in the form of a host-key or a 320 certificate, for the SSH and TLS protocols respectively. Without 321 examining the contents of the host-key or certificate, it is possible 322 to form an identity for the NETCONF/RESTCONF server using it directly 323 (e.g., a fingerprint), since each NETCONF/RESTCONF server is assumed 324 to have a statistically unique public key, even in virtualized 325 environments. This strategy also provides a mechanism to verify the 326 NETCONF/RESTCONF server, in that a secure connection can only be 327 established with the NETCONF/RESTCONF server having the matching 328 private key. This strategy is commonly implemented by SSH clients, 329 and could be used equally well by TLS-based clients, such as may be 330 required when the NETCONF/RESTCONF servers have self-signed 331 certificates. This strategy is viable and useful when the NETCONF/ 332 RESTCONF servers call home using either SSH with standard RSA/DSA 333 host-keys, or using TLS with self-signed certificates. 335 Yet another option for identifying a NETCONF/RESTCONF server is for 336 its host key or certificate to encode its identity directly (e.g., 337 within the "Subject" field). However, in order to trust the content 338 encoded within a host-key or certificate, it must be signed by a 339 certificate authority trusted by the NETCONF/RESTCONF client. This 340 strategy's use of PKI enables a NETCONF/RESTCONF client to 341 transparently authenticate NETCONF/RESTCONF servers, thus eliminating 342 the need for manual authentication, as required by the previously 343 discussed strategies. Elimination of manual steps is needed to 344 achieve scalable solutions, however one can claim that this merely 345 pushes equivalent work to provisioning the NETCONF/RESTCONF servers 346 with signed credentials. This assessment is accurate in general, but 347 not in the case where the manufacturer itself provisions the 348 credentials, such as is described by [Std-802.1AR-2009]. When 349 NETCONF/RESTCONF servers are pre-provisioned this way, NETCONF/ 350 RESTCONF clients can transparently authenticate NETCONF/RESTCONF 351 servers using just the manufacturer's trust anchor and a list of 352 expected NETCONF/RESTCONF server identifiers, which could be provided 353 along with shipping information. This strategy is recommended for 354 all deployment scenarios. 356 In discussing the use of certificates, it is worth noting that TLS 357 uses X.509 certificates by default. However, to use X.509 358 certificates with SSH, both the NETCONF client and server must 359 support [RFC6187]. 361 4. Security Considerations 363 The security considerations described throughout [RFC6242] and 364 [RFC5539], and by extension [RFC4253], [RFC5246], and 365 [draft-ietf-netconf-restconf] apply here as well. 367 This RFC deviates from standard SSH and TLS usage by having the SSH/ 368 TLS server initiate the underlying TCP connection. For SSH, 369 [RFC4253] says "the client initiates the connection", whereas for 370 TLS, [RFC5246] says it is layered on top of "some reliable transport 371 protocol" without further attribution. 373 Not having the SSH/TLS client initiate the TCP connection means that 374 it does not have a preconceived notion of the SSH/TLS server's 375 identity, and therefore must dynamically derive one from information 376 provided by the network or the SSH/TLS server itself. Security 377 Considerations for strategies for this are described in Section 3.2. 379 An attacker could DoS the NETCONF/RESTCONF client by having it 380 perform computationally expensive operations, before deducing that 381 the attacker doesn't posses a valid key. This is no different than 382 any secured service and all common precautions apply (e.g., 383 blacklisting the source address after a set number of unsuccessful 384 login attempts). 386 5. IANA Considerations 388 This document requests that IANA assigns three TCP port numbers in 389 the "Registered Port Numbers" range with the service names "netconf- 390 ch-ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will 391 be the default ports for NETCONF Call Home and RESTCONF Call Home 392 protocols. Below is the registration template following the rules in 393 [RFC6335]. 395 Service Name: netconf-ch-ssh 396 Transport Protocol(s): TCP 397 Assignee: IESG 398 Contact: IETF Chair 399 Description: NETCONF Call Home (SSH) 400 Reference: RFC XXXX 401 Port Number: PORT-X 403 Service Name: netconf-ch-tls 404 Transport Protocol(s): TCP 405 Assignee: IESG 406 Contact: IETF Chair 407 Description: NETCONF Call Home (TLS) 408 Reference: RFC XXXX 409 Port Number: PORT-Y 411 Service Name: restconf-ch-tls 412 Transport Protocol(s): TCP 413 Assignee: IESG 414 Contact: IETF Chair 415 Description: RESTCONF Call Home (TLS) 416 Reference: RFC XXXX 417 Port Number: PORT-Z 419 6. Acknowledgements 421 The author would like to thank for following for lively discussions 422 on list and in the halls (ordered by last name): Andy Bierman, Martin 423 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 424 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 425 Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Hannes Tschofenig, 426 Sean Turner, Bert Wijnen. 428 7. References 430 7.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 436 Protocol Architecture", RFC 4251, January 2006. 438 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 439 Authentication Protocol", RFC 4252, January 2006. 441 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 442 Transport Layer Protocol", RFC 4253, January 2006. 444 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 445 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 447 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 448 RFC 5539, May 2009. 450 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 451 Network Configuration Protocol (NETCONF)", RFC 6020, 452 October 2010. 454 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 455 Shell Authentication", RFC 6187, March 2011. 457 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 458 Bierman, "Network Configuration Protocol (NETCONF)", RFC 459 6241, June 2011. 461 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 462 Shell (SSH)", RFC 6242, June 2011. 464 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 465 Cheshire, "Internet Assigned Numbers Authority (IANA) 466 Procedures for the Management of the Service Name and 467 Transport Protocol Port Number Registry", BCP 165, RFC 468 6335, August 2011. 470 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 471 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 472 2014. 474 [draft-ietf-netconf-restconf] 475 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 476 Protocol", draft-ieft-netconf-restconf-04 (work in 477 progress), 2014. 479 7.2. Informative References 481 [Std-802.1AR-2009] 482 IEEE SA-Standards Board, "IEEE Standard for Local and 483 metropolitan area networks - Secure Device Identity", 484 December 2009, . 487 [draft-ietf-netconf-server-model] 488 Watsen, K. and J. Schoenwaelder, "NETCONF Server 489 Configuration Model", 2014, . 492 Appendix A. Change Log 494 A.1. 00 to 01 496 o The term "TCP connection" is now used throughout. 498 o The terms "network element" and "management system" are now only 499 used in the Motivation section. 501 o Restructured doc a little to create an Introduction section. 503 o Fixed reference in Applicability Statement so it would work 504 equally well for SSH and TLS. 506 o Fixed reported odd wording and three references. 508 A.2. 01 to 02 510 o Added call home support for the RESTCONF protocol. 512 o Fixed paragraph 3 of Security Considerations to equally apply to 513 the TLS protocol. 515 A.3. 02 to 03 517 o Tried to improve readability (issue #6) 519 o Removed "FIXME" in section 1.3 (issue #7) 521 o Added RFC Editor notes (issue #8) 523 o Removed "TCP session" term (issue #9) 525 o Improved language for usage of IANA-assigned ports (issue #10) 527 Appendix B. Open Issues 529 All issues with this draft are tracked using GitHub issues. Please 530 see: https://github.com/netconf-wg/call-home/issues to see currently 531 opened issues. 533 Author's Address 535 Kent Watsen 536 Juniper Networks 538 EMail: kwatsen@juniper.net