idnits 2.17.1 draft-ietf-netconf-call-home-05.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 (May 12, 2015) is 3272 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 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) 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) May 12, 2015 5 Intended status: Standards Track 6 Expires: November 13, 2015 8 NETCONF Call Home and RESTCONF Call Home 9 draft-ietf-netconf-call-home-05 11 Abstract 13 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 14 enable a NETCONF or RESTCONF server to initiate a secure connection 15 to a NETCONF or RESTCONF client respectively. 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-rfc5539bis 39 o draft-ietf-netconf-server-model 41 Artwork in this document contains placeholder values for ports 42 pending IANA assignment from "draft-ietf-netconf-call-home". Please 43 apply the following replacements: 45 o "PORT-X" --> the assigned port value for "netconf-ch-ssh" 47 o "PORT-Y" --> the assigned port value for "netconf-ch-tls" 48 o "PORT-Z" --> the assigned port value for "restconf-ch-tls" 50 The following two Appendix sections are to be removed prior to 51 publication: 53 o Appendix A. Change Log 55 o Appendix B. Open Issues 57 Status of This Memo 59 This Internet-Draft is submitted in full conformance with the 60 provisions of BCP 78 and BCP 79. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF). Note that other groups may also distribute 64 working documents as Internet-Drafts. The list of current Internet- 65 Drafts is at http://datatracker.ietf.org/drafts/current/. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 This Internet-Draft will expire on November 13, 2015. 74 Copyright Notice 76 Copyright (c) 2015 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents 81 (http://trustee.ietf.org/license-info) in effect on the date of 82 publication of this document. Please review these documents 83 carefully, as they describe your rights and restrictions with respect 84 to this document. Code Components extracted from this document must 85 include Simplified BSD License text as described in Section 4.e of 86 the Trust Legal Provisions and are provided without warranty as 87 described in the Simplified BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 92 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 93 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 5 94 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 5 95 1.4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 5 96 2. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 5 97 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5 98 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 6 99 3. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 7 100 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 7 101 3.2. Configuration Data Model . . . . . . . . . . . . . . . . 7 102 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 103 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 104 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 105 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 106 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 107 7.2. Informative References . . . . . . . . . . . . . . . . . 11 108 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 109 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 110 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 111 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 12 112 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 12 113 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 12 114 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 13 116 1. Introduction 118 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 119 enable a NETCONF or RESTCONF server to initiate a secure connection 120 to a NETCONF or RESTCONF client respectively. 122 NETCONF Call Home supports both of the secure transports used by the 123 NETCONF protocol [RFC6241], SSH and TLS. The NETCONF protocol's 124 binding to SSH is defined in [RFC6242]. The NETCONF protocol's 125 binding to TLS is defined in [draft-ietf-netconf-rfc5539bis]. 127 RESTCONF Call Home only supports TLS, same as the RESTCONF protocol 128 [draft-ietf-netconf-restconf]. The RESTCONF protocol's binding to 129 TLS is defined in [draft-ietf-netconf-restconf]. 131 The SSH protocol is defined in [RFC4253]. The TLS protocol is 132 defined in [RFC5246]. Both the SSH and TLS protocols are layered on 133 top of the TCP protocol, which is defined in [RFC793]. 135 Both NETCONF Call Home and RESTCONF Call Home preserve all but one of 136 the client/server roles in their respective protocol stacks, as when 137 compared to standard NETCONF and RESTCONF connections. The one and 138 only role reversal that occurs is at the TCP layer; that is, in which 139 peer is the TCP-client and which is the TCP-server. 141 For example, a network element is traditionally the TCP-server 142 however, when calling home, the network element becomes the TCP- 143 client. The network element's secure transport layer roles (SSH- 144 server, TLS-server) and its application layer roles (NETCONF-server, 145 RESTCONF-server) both remain the same. 147 Having consistency in both the secure transport layer (SSH, TLS) and 148 application layer (NETCONF, RESTCONF) roles conveniently enables 149 deployed network management infrastructure to also support call home. 150 For instance, existing certificate chains and user authentication 151 mechanisms are unaffected by call home. 153 1.1. Motivation 155 Call home is generally useful for both the initial deployment and on- 156 going management of networking elements. Here are some scenarios 157 enabled by call home: 159 o The network element may proactively call home after being powered 160 on for the first time in order to register itself with its 161 management system. 163 o The network element may access the network in a way that 164 dynamically assigns it an IP address, but does not register its 165 assigned IP address to a mapping service. 167 o The network element may be deployed behind a firewall that 168 implements network address translation (NAT) for all internal 169 network IP addresses. 171 o The network element may be deployed behind a firewall that doesn't 172 allow any management access to the internal network. 174 o The network element may be configured in "stealth mode" and thus 175 doesn't have any open ports for the management system to connect 176 to. 178 o The operator may prefer to have network elements initiate 179 management connections, believing it is easier to secure one open- 180 port in the data center than to have an open port on each network 181 element in the network. 183 1.2. Requirements Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [RFC2119]. 189 1.3. Applicability Statement 191 The techniques described in this document are suitable for network 192 management scenarios such as the ones described in Section 1.1. 193 However, these techniques are only defined for NETCONF Call Home and 194 RESTCONF Call Home, as described in this document. 196 The reason for this restriction is that different protocols have 197 different security assumptions. The NETCONF and RESTCONF protocols 198 require clients and servers to verify the identity of the other party 199 before starting the NETCONF/RESTCONF protocol (section 2.2 of 200 [RFC6241] and sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 202 This contrasts with the base SSH and TLS protocols, which do not 203 require programmatic verification of the other party (section 9.3.4 204 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 205 In such circumstances, allowing the SSH/TLS server to contact the 206 SSH/TLS client would open new vulnerabilities. Any use of call home 207 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 208 thorough, contextual security analysis. 210 1.4. Update to RFC 4253 212 This document updates the SSH Transport Layer Protocol [RFC4253] only 213 in removing the statement "The client initiates the connection" made 214 in Section 4 (Connection Setup). Assuming the reference to client 215 means "SSH client" and the reference to connection means "TCP 216 connection", this statement doesn't hold true in call home, where the 217 network element is the SSH server and yet still initiates the TCP 218 connection. Security implications related to this change are 219 discussed in Security Considerations (Section 4). 221 2. The NETCONF or RESTCONF Client 223 2.1. Protocol Operation 225 C1 The NETCONF/RESTCONF client listens for TCP connection requests 226 from NETCONF/RESTCONF servers. The client SHOULD listen for 227 connections on the IANA-assigned ports defined in section 228 Section 5, but MAY be configured to use a non-default port. 230 C2 The NETCONF/RESTCONF client accepts an incoming TCP connection 231 request and a TCP connection is established. 233 C3 Using this TCP connection, the NETCONF/RESTCONF client MUST 234 immediately start either the SSH-client [RFC4253] or the TLS- 235 client [RFC5246] protocol. For example, assuming the use of the 236 IANA-assigned ports, the SSH-client protocol is started when the 237 connection is accepted on port PORT-X and the TLS-client protocol 238 is started when the connection is accepted on either port PORT-Y 239 or PORT-Z. 241 C4 If using TLS, the NETCONF/RESTCONF client MUST advertise 242 "peer_allowed_to_send", as defined by [RFC6520]. This is 243 required so NETCONF/RESTCONF servers can depend on it being there 244 for call home connections, when keep-alives are needed the most. 246 C5 As part of establishing an SSH or TLS connection, the NETCONF/ 247 RESTCONF client MUST validate both the server's credentials and 248 identity (e.g., SSH host key, TLS certificate). The client first 249 validates the server's credentials, either via previously trusted 250 validation data (e.g., pinning, using the entire host key or 251 certificate as the lookup key) or via certificate path validation 252 to a preconfigured trust anchor. The identity MAY then be 253 derived from the pinned data or extracted from the server's 254 certificate (e.g., SubjectAltName). Finally, the client MUST 255 validate the server's identity is one that it was expecting to 256 connect to it. 258 C6 Once the SSH or TLS connection is established, the NETCONF/ 259 RESTCONF client MUST immediately start using either the NETCONF- 260 client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] 261 protocol. Assuming the use of the IANA-assigned ports, the 262 NETCONF-client protocol is started when the connection is 263 accepted on either port PORT-X or PORT-Y and the RESTCONF-client 264 protocol is started when the connection is accepted on port PORT- 265 Z. 267 2.2. Configuration Data Model 269 How to configure a NETCONF or RESTCONF client is outside the scope of 270 this document. This includes configuration that might be used to 271 enable listening for call home connections, configuring trust 272 anchors, and/or pinning the identities for expected connections. 274 3. The NETCONF or RESTCONF Server 276 3.1. Protocol Operation 278 S1 The NETCONF/RESTCONF server initiates a TCP connection request to 279 the NETCONF/RESTCONF client. The server SHOULD connect to one of 280 the IANA-assigned ports defined in section Section 5, but MAY be 281 configured to use a non-default port. Using the IANA-assigned 282 ports, the server connects to port PORT-X for NETCONF over SSH, 283 port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF 284 over TLS. 286 S2 The TCP connection request is accepted and a TCP connection is 287 established. 289 S3 Using this TCP connection, the NETCONF/RESTCONF server MUST 290 immediately start using either the SSH-server [RFC4253] or the 291 TLS-server [RFC5246] protocol, depending on how it is configured. 292 For example, assuming the use of the IANA-assigned ports, the 293 SSH-server protocol is used after connecting to the remote port 294 PORT-X and the TLS-server protocol is used after connecting to 295 one of the remote ports PORT-Y or PORT-Z. 297 S4 Once the SSH or TLS connection is established, the NETCONF/ 298 RESTCONF server MUST immediately start using either the NETCONF- 299 server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] 300 protocol, depending on how it is configured. Assuming the use of 301 the IANA-assigned ports, the NETCONF-server protocol is used 302 after connecting to remote port PORT-X or PORT-Y, and the 303 RESTCONF-server protocol is used after connecting to remote port 304 PORT-Z. 306 S5 If a persistent connection is desired, the NETCONF/RESTCONF 307 server, as the connection initiator, SHOULD actively test the 308 aliveness of the connection using a keep-alive mechanism. For 309 TLS based connections, the NETCONF/RESTCONF server SHOULD send 310 HeartbeatRequest messages, as defined by [RFC6520]. For SSH 311 based connections, per section 4 of [RFC4254], the NETCONF/ 312 RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with 313 the purposely nonexistent "request name" value 314 "keepalive@ietf.org" and the "want reply" value set to '1'. 316 3.2. Configuration Data Model 318 How to configure a NETCONF or RESTCONF server is outside the scope of 319 this document. This includes configuration that might be used to 320 specify hostnames, IP addresses, ports, algorithms, or other relevant 321 parameters. 323 A YANG [RFC6020] model for configuring both NETCONF and RESTCONF 324 servers, including call home, is provided in 325 [draft-ietf-netconf-server-model]. 327 4. Security Considerations 329 The security considerations described in [RFC6242] and 330 [draft-ietf-netconf-rfc5539bis], and by extension [RFC4253], 331 [RFC5246], and [draft-ietf-netconf-restconf] apply here as well. 333 This RFC deviates from standard SSH and TLS usage by having the SSH/ 334 TLS server initiate the underlying TCP connection. This reversal is 335 incongruous with [RFC4253], which says "the client initiates the 336 connection" and also [RFC6125], which says "the client MUST construct 337 a list of acceptable reference identifiers, and MUST do so 338 independently of the identifiers presented by the service." To 339 account for these variances, this RFC requires that the NETCONF/ 340 RESTCONF client be able to 1) validate the SSH host key via pinning 341 and/or PKI, 2) extract an identity from the server's SSH host-key or 342 TLS certificate, and 3) validate that the identity is one that the 343 client was expecting to connect to it. 345 An attacker could launch a denial of service (DoS) attack on the 346 NETCONF/RESTCONF client by having it perform computationally 347 expensive operations, before deducing that the attacker doesn't 348 posses a valid key. This is no different than any secured service 349 and all common precautions apply (e.g., blacklisting the source 350 address after a set number of unsuccessful login attempts). 352 5. IANA Considerations 354 This RFC requests that IANA assigns three TCP port numbers in the 355 "Registered Port Numbers" range with the service names "netconf-ch- 356 ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be 357 the default ports for NETCONF Call Home and RESTCONF Call Home 358 protocols. Below is the registration template following the rules in 359 [RFC6335]. 361 Service Name: netconf-ch-ssh 362 Transport Protocol(s): TCP 363 Assignee: IESG 364 Contact: IETF Chair 365 Description: NETCONF Call Home (SSH) 366 Reference: RFC XXXX 367 Port Number: PORT-X 369 Service Name: netconf-ch-tls 370 Transport Protocol(s): TCP 371 Assignee: IESG 372 Contact: IETF Chair 373 Description: NETCONF Call Home (TLS) 374 Reference: RFC XXXX 375 Port Number: PORT-Y 377 Service Name: restconf-ch-tls 378 Transport Protocol(s): TCP 379 Assignee: IESG 380 Contact: IETF Chair 381 Description: RESTCONF Call Home (TLS) 382 Reference: RFC XXXX 383 Port Number: PORT-Z 385 6. Acknowledgements 387 The author would like to thank the following for lively discussions 388 on list and in the halls (ordered by last name): Andy Bierman, Martin 389 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 390 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 391 Mundy, Tom Petch, Juergen Schoenwaelder, Peter Saint-Andre, Joe 392 Touch, Hannes Tschofenig, Sean Turner, and Bert Wijnen. 394 7. References 396 7.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 402 Protocol Architecture", RFC 4251, January 2006. 404 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 405 Authentication Protocol", RFC 4252, January 2006. 407 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 408 Transport Layer Protocol", RFC 4253, January 2006. 410 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 411 Connection Protocol", RFC 4254, January 2006. 413 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 414 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 416 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 417 Network Configuration Protocol (NETCONF)", RFC 6020, 418 October 2010. 420 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 421 Verification of Domain-Based Application Service Identity 422 within Internet Public Key Infrastructure Using X.509 423 (PKIX) Certificates in the Context of Transport Layer 424 Security (TLS)", RFC 6125, March 2011. 426 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 427 Bierman, "Network Configuration Protocol (NETCONF)", RFC 428 6241, June 2011. 430 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 431 Shell (SSH)", RFC 6242, June 2011. 433 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 434 Cheshire, "Internet Assigned Numbers Authority (IANA) 435 Procedures for the Management of the Service Name and 436 Transport Protocol Port Number Registry", BCP 165, RFC 437 6335, August 2011. 439 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 440 Layer Security (TLS) and Datagram Transport Layer Security 441 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 443 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 444 September 1981, . 446 [draft-ietf-netconf-restconf] 447 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 448 Protocol", draft-ieft-netconf-restconf-04 (work in 449 progress), 2014, . 452 [draft-ietf-netconf-rfc5539bis] 453 Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 454 NETCONF Protocol over Transport Layer Security (TLS) with 455 Mutual X.509 Authentication", draft-ietf-netconf- 456 rfc5539bis-10 (work in progress), April 2015, 457 . 460 7.2. Informative References 462 [draft-ietf-netconf-server-model] 463 Watsen, K. and J. Schoenwaelder, "NETCONF Server 464 Configuration Model", 2014, . 467 Appendix A. Change Log 469 A.1. 00 to 01 471 o The term "TCP connection" is now used throughout. 473 o The terms "network element" and "management system" are now only 474 used in the Motivation section. 476 o Restructured doc a little to create an Introduction section. 478 o Fixed reference in Applicability Statement so it would work 479 equally well for SSH and TLS. 481 o Fixed reported odd wording and three references. 483 A.2. 01 to 02 485 o Added call home support for the RESTCONF protocol. 487 o Fixed paragraph 3 of Security Considerations to equally apply to 488 the TLS protocol. 490 A.3. 02 to 03 492 o Tried to improve readability (issue #6) 494 o Removed "FIXME" in section 1.3 (issue #7) 496 o Added RFC Editor notes (issue #8) 498 o Removed "TCP session" term (issue #9) 500 o Improved language for usage of IANA-assigned ports (issue #10) 502 A.4. 03 to 04 504 o Replaced "verify credentials" with "verify identity" (issue #11) 506 A.5. 04 to 05 508 o Applied many suggestions from WGLC 510 o Removed essay like "Server Identification and Verification" 511 section 513 o Added text about keep-alives 514 o Added Configuration Data Model section for client protocol 516 o Improved Security Considerations section 518 Appendix B. Open Issues 520 All issues with this draft are tracked using GitHub issues. Please 521 see: https://github.com/netconf-wg/call-home/issues to see currently 522 opened issues. 524 Author's Address 526 Kent Watsen 527 Juniper Networks 529 EMail: kwatsen@juniper.net