idnits 2.17.1 draft-ietf-netconf-call-home-07.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 (June 3, 2015) is 3248 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) June 3, 2015 5 Intended status: Standards Track 6 Expires: December 5, 2015 8 NETCONF Call Home and RESTCONF Call Home 9 draft-ietf-netconf-call-home-07 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 December 5, 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 1.5. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 5 97 2. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 6 98 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 99 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 7 100 3. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 7 101 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 7 102 3.2. Configuration Data Model . . . . . . . . . . . . . . . . 8 103 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 105 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 106 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 107 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 108 7.2. Informative References . . . . . . . . . . . . . . . . . 11 109 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 110 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 111 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 112 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 12 113 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 12 114 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 12 115 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 13 116 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 13 117 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 13 119 1. Introduction 121 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 122 enable a NETCONF or RESTCONF server to initiate a secure connection 123 to a NETCONF or RESTCONF client respectively. 125 NETCONF Call Home supports both of the secure transports used by the 126 NETCONF protocol [RFC6241], SSH and TLS. The NETCONF protocol's 127 binding to SSH is defined in [RFC6242]. The NETCONF protocol's 128 binding to TLS is defined in [draft-ietf-netconf-rfc5539bis]. 130 RESTCONF Call Home only supports TLS, the same as the RESTCONF 131 protocol [draft-ietf-netconf-restconf]. The RESTCONF protocol's 132 binding to TLS is defined in [draft-ietf-netconf-restconf]. 134 The SSH protocol is defined in [RFC4253]. The TLS protocol is 135 defined in [RFC5246]. Both the SSH and TLS protocols are layered on 136 top of the TCP protocol, which is defined in [RFC793]. 138 Both NETCONF Call Home and RESTCONF Call Home preserve all but one of 139 the client/server roles in their respective protocol stacks, as 140 compared to standard NETCONF and RESTCONF connections. The one and 141 only role reversal that occurs is at the TCP layer; that is, which 142 peer is the TCP-client and which is the TCP-server. 144 For example, a network element is traditionally the TCP-server. 145 However, when calling home, the network element becomes the TCP- 146 client. The network element's secure transport layer roles (SSH- 147 server, TLS-server) and its application layer roles (NETCONF-server, 148 RESTCONF-server) both remain the same. 150 Having consistency in both the secure transport layer (SSH, TLS) and 151 application layer (NETCONF, RESTCONF) roles conveniently enables 152 deployed network management infrastructure to support call home also. 153 For instance, existing certificate chains and user authentication 154 mechanisms are unaffected by call home. 156 1.1. Motivation 158 Call home is generally useful for both the initial deployment and on- 159 going management of networking elements. Here are some scenarios 160 enabled by call home: 162 o The network element may proactively call home after being powered 163 on for the first time in order to register itself with its 164 management system. 166 o The network element may access the network in a way that 167 dynamically assigns it an IP address, but does not register its 168 assigned IP address to a mapping service. 170 o The network element may be deployed behind a firewall that 171 implements network address translation (NAT) for all internal 172 network IP addresses. 174 o The network element may be deployed behind a firewall that doesn't 175 allow any management access to the internal network. 177 o The network element may be configured in "stealth mode" and thus 178 doesn't have any open ports for the management system to connect 179 to. 181 o The operator may prefer to have network elements initiate 182 management connections, believing it is easier to secure one open- 183 port in the data center than to have an open port on each network 184 element in the network. 186 1.2. Requirements Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 1.3. Applicability Statement 194 The techniques described in this document are suitable for network 195 management scenarios such as the ones described in Section 1.1. 196 However, these techniques are only defined for NETCONF Call Home and 197 RESTCONF Call Home, as described in this document. 199 The reason for this restriction is that different protocols have 200 different security assumptions. The NETCONF and RESTCONF protocols 201 require clients and servers to verify the identity of the other 202 party. This requirement is specified for the NETCONF protocol in 203 Section 2.2 of [RFC6241], and is specified for the RESTCONF protocol 204 in Sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 206 This contrasts with the base SSH and TLS protocols, which do not 207 require programmatic verification of the other party (section 9.3.4 208 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 209 In such circumstances, allowing the SSH/TLS server to contact the 210 SSH/TLS client would open new vulnerabilities. Any use of call home 211 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 212 thorough, contextual security analysis. 214 1.4. Update to RFC 4253 216 This document updates the SSH Transport Layer Protocol [RFC4253] only 217 in removing the statement "The client initiates the connection" made 218 in Section 4 (Connection Setup). Assuming the reference to client 219 means "SSH client" and the reference to connection means "TCP 220 connection", this statement doesn't hold true in call home, where the 221 network element is the SSH server and yet still initiates the TCP 222 connection. Security implications related to this change are 223 discussed in Security Considerations (Section 4). 225 1.5. The NETCONF/RESTCONF Convention 227 Throughout the remainder of this document, the term "NETCONF/ 228 RESTCONF" is used as an abbreviation in place of the text "the 229 NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not 230 intended to require or to imply that a client or server must 231 implement both the NETCONF standard and the RESTCONF standard. 233 2. The NETCONF or RESTCONF Client 235 2.1. Protocol Operation 237 C1 The NETCONF/RESTCONF client listens for TCP connection requests 238 from NETCONF/RESTCONF servers. The client SHOULD listen for 239 connections on the IANA-assigned ports defined in section 240 Section 5, but MAY be configured to use a non-standard port. 242 C2 The NETCONF/RESTCONF client accepts an incoming TCP connection 243 request and a TCP connection is established. 245 C3 Using this TCP connection, the NETCONF/RESTCONF client MUST 246 immediately start either the SSH-client [RFC4253] or the TLS- 247 client [RFC5246] protocol. For example, assuming the use of the 248 IANA-assigned ports, the SSH-client protocol is started when the 249 connection is accepted on port PORT-X and the TLS-client protocol 250 is started when the connection is accepted on either port PORT-Y 251 or PORT-Z. 253 C4 If using TLS, the NETCONF/RESTCONF client MUST advertise 254 "peer_allowed_to_send", as defined by [RFC6520]. This is 255 required so NETCONF/RESTCONF servers can depend on it being there 256 for call home connections, when keep-alives are needed the most. 258 C5 As part of establishing an SSH or TLS connection, the NETCONF/ 259 RESTCONF client MUST validate the server's presented host key or 260 certificate. This validation MAY be accomplished by certificate 261 path validation or by comparing the host key or certificate to a 262 previously trusted or "pinned" value. 264 C6 If certificate path validation is used, the NETCONF/RESTCONF 265 client MUST ensure that the certificate has a valid chain of 266 trust to a preconfigured trust anchor and that the certificate 267 encodes an "identifier" [RFC6125] that the client had awareness 268 of prior to the connection attempt. How identifiers are encoded 269 in certificates MAY be determined by a policy associated with the 270 certificate's trust anchor. For instance, a given trust anchor 271 may be known to only sign IDevID certificates [Std-802.1AR-2009] 272 having a unique identifier (e.g., serial number) in the X.509 273 certificate's "CommonName" field. 275 C7 After the server's host key or certificate is validated, the SSH 276 or TLS protocol proceeds as normal to establish a SSH or TLS 277 connection. 279 C8 Once the SSH or TLS connection is established, the NETCONF/ 280 RESTCONF client MUST immediately start using either the NETCONF- 281 client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] 282 protocol. Assuming the use of the IANA-assigned ports, the 283 NETCONF-client protocol is started when the connection is 284 accepted on either port PORT-X or PORT-Y and the RESTCONF-client 285 protocol is started when the connection is accepted on port PORT- 286 Z. 288 2.2. Configuration Data Model 290 How a NETCONF or RESTCONF client is configured is outside the scope 291 of this document. This includes configuration that might be used to 292 enable listening for call home connections, configuring trust 293 anchors, or configuring identifiers for expected connections. 295 3. The NETCONF or RESTCONF Server 297 3.1. Protocol Operation 299 S1 The NETCONF/RESTCONF server initiates a TCP connection request to 300 the NETCONF/RESTCONF client. The server SHOULD connect to one of 301 the IANA-assigned ports defined in section Section 5, but MAY be 302 configured to use a non-standard port. Using the IANA-assigned 303 ports, the server connects to port PORT-X for NETCONF over SSH, 304 port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF 305 over TLS. 307 S2 The TCP connection request is accepted and a TCP connection is 308 established. 310 S3 Using this TCP connection, the NETCONF/RESTCONF server MUST 311 immediately start using either the SSH-server [RFC4253] or the 312 TLS-server [RFC5246] protocol, depending on how it is configured. 313 For example, assuming the use of the IANA-assigned ports, the 314 SSH-server protocol is used after connecting to the remote port 315 PORT-X and the TLS-server protocol is used after connecting to 316 one of the remote ports PORT-Y or PORT-Z. 318 S4 As part of establishing the SSH or TLS connection, the NETCONF/ 319 RESTCONF server will send its host key or certificate to the 320 client. If a certificate is sent, the server MUST also send any 321 intermediate certificates leading up to the trust anchor the 322 clients are expected use to authenticate it. How to send a list 323 of certificates is defined for SSH in [RFC6187] Section 2.1, and 324 for TLS in [RFC5246] Section 7.4.2. 326 S5 Once the SSH or TLS connection is established, the NETCONF/ 327 RESTCONF server MUST immediately start using either the NETCONF- 328 server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] 329 protocol, depending on how it is configured. Assuming the use of 330 the IANA-assigned ports, the NETCONF-server protocol is used 331 after connecting to remote port PORT-X or PORT-Y, and the 332 RESTCONF-server protocol is used after connecting to remote port 333 PORT-Z. 335 S6 If a persistent connection is desired, the NETCONF/RESTCONF 336 server, as the connection initiator, SHOULD actively test the 337 aliveness of the connection using a keep-alive mechanism. For 338 TLS based connections, the NETCONF/RESTCONF server SHOULD send 339 HeartbeatRequest messages, as defined by [RFC6520]. For SSH 340 based connections, per section 4 of [RFC4254], the NETCONF/ 341 RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with 342 the purposely nonexistent "request name" value 343 "keepalive@ietf.org" and the "want reply" value set to '1'. 345 3.2. Configuration Data Model 347 How a NETCONF or RESTCONF server is configured is outside the scope 348 of this document. This includes configuration that might be used to 349 specify hostnames, IP addresses, ports, algorithms, or other relevant 350 parameters. That said, a YANG [RFC6020] model for configuring 351 NETCONF and RESTCONF servers, including call home, is provided in 352 [draft-ietf-netconf-server-model]. 354 4. Security Considerations 356 The security considerations described in [RFC6242] and 357 [draft-ietf-netconf-rfc5539bis], and by extension [RFC4253], 358 [RFC5246], and [draft-ietf-netconf-restconf] apply here as well. 360 This RFC deviates from standard SSH and TLS usage by having the SSH/ 361 TLS server initiate the underlying TCP connection. This reversal is 362 incongruous with [RFC4253], which says "the client initiates the 363 connection" and also [RFC6125], which says "the client MUST construct 364 a list of acceptable reference identifiers, and MUST do so 365 independently of the identifiers presented by the service." To 366 account for these variances, this RFC requires that the NETCONF/ 367 RESTCONF client validate the SSH host key or certificate via 368 certificate path validation to a preconfigured trust anchor or by 369 comparing the host key or certificate to a previously trusted or 370 "pinned" value. Furthermore, if certificate path validation is used, 371 this RFC requires that the client be able to match a presented 372 identifier encoded in the certificate with an identifier the client 373 was preconfigured to expect. 375 An attacker could launch a denial of service (DoS) attack on the 376 NETCONF/RESTCONF client by having it perform computationally 377 expensive operations, before deducing that the attacker doesn't 378 posses a valid key. This is no different than any secured service 379 and all common precautions apply (e.g., blacklisting the source 380 address after a set number of unsuccessful login attempts). 382 5. IANA Considerations 384 This RFC requests that IANA assigns three TCP port numbers in the 385 "Registered Port Numbers" range with the service names "netconf-ch- 386 ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be 387 the default ports for NETCONF Call Home and RESTCONF Call Home 388 protocols. Below is the registration template following the rules in 389 [RFC6335]. 391 Service Name: netconf-ch-ssh 392 Transport Protocol(s): TCP 393 Assignee: IESG 394 Contact: IETF Chair 395 Description: NETCONF Call Home (SSH) 396 Reference: RFC XXXX 397 Port Number: PORT-X 399 Service Name: netconf-ch-tls 400 Transport Protocol(s): TCP 401 Assignee: IESG 402 Contact: IETF Chair 403 Description: NETCONF Call Home (TLS) 404 Reference: RFC XXXX 405 Port Number: PORT-Y 407 Service Name: restconf-ch-tls 408 Transport Protocol(s): TCP 409 Assignee: IESG 410 Contact: IETF Chair 411 Description: RESTCONF Call Home (TLS) 412 Reference: RFC XXXX 413 Port Number: PORT-Z 415 6. Acknowledgements 417 The author would like to thank the following for lively discussions 418 on list and in the halls (ordered by last name): Andy Bierman, Martin 419 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 420 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 421 Mundy, Tom Petch, Juergen Schoenwaelder, Peter Saint-Andre, Joe 422 Touch, Hannes Tschofenig, Sean Turner, and Bert Wijnen. 424 7. References 426 7.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 432 Protocol Architecture", RFC 4251, January 2006. 434 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 435 Authentication Protocol", RFC 4252, January 2006. 437 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 438 Transport Layer Protocol", RFC 4253, January 2006. 440 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 441 Connection Protocol", RFC 4254, January 2006. 443 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 444 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 446 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 447 Verification of Domain-Based Application Service Identity 448 within Internet Public Key Infrastructure Using X.509 449 (PKIX) Certificates in the Context of Transport Layer 450 Security (TLS)", RFC 6125, March 2011. 452 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 453 Shell Authentication", RFC 6187, March 2011. 455 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 456 Bierman, "Network Configuration Protocol (NETCONF)", RFC 457 6241, June 2011. 459 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 460 Shell (SSH)", RFC 6242, June 2011. 462 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 463 Cheshire, "Internet Assigned Numbers Authority (IANA) 464 Procedures for the Management of the Service Name and 465 Transport Protocol Port Number Registry", BCP 165, RFC 466 6335, August 2011. 468 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 469 Layer Security (TLS) and Datagram Transport Layer Security 470 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 472 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 473 September 1981, . 475 [draft-ietf-netconf-restconf] 476 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 477 Protocol", draft-ieft-netconf-restconf-04 (work in 478 progress), 2014, . 481 [draft-ietf-netconf-rfc5539bis] 482 Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 483 NETCONF Protocol over Transport Layer Security (TLS) with 484 Mutual X.509 Authentication", draft-ietf-netconf- 485 rfc5539bis-10 (work in progress), April 2015, 486 . 489 7.2. Informative References 491 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 492 Network Configuration Protocol (NETCONF)", RFC 6020, 493 October 2010. 495 [Std-802.1AR-2009] 496 IEEE SA-Standards Board, "IEEE Standard for Local and 497 metropolitan area networks - Secure Device Identity", 498 December 2009, . 501 [draft-ietf-netconf-server-model] 502 Watsen, K. and J. Schoenwaelder, "NETCONF Server 503 Configuration Model", 2014, . 506 Appendix A. Change Log 508 A.1. 00 to 01 510 o The term "TCP connection" is now used throughout. 512 o The terms "network element" and "management system" are now only 513 used in the Motivation section. 515 o Restructured doc a little to create an Introduction section. 517 o Fixed reference in Applicability Statement so it would work 518 equally well for SSH and TLS. 520 o Fixed reported odd wording and three references. 522 A.2. 01 to 02 524 o Added call home support for the RESTCONF protocol. 526 o Fixed paragraph 3 of Security Considerations to equally apply to 527 the TLS protocol. 529 A.3. 02 to 03 531 o Tried to improve readability (issue #6) 533 o Removed "FIXME" in section 1.3 (issue #7) 535 o Added RFC Editor notes (issue #8) 537 o Removed "TCP session" term (issue #9) 539 o Improved language for usage of IANA-assigned ports (issue #10) 541 A.4. 03 to 04 543 o Replaced "verify credentials" with "verify identity" (issue #11) 545 A.5. 04 to 05 547 o Applied many suggestions from WGLC 549 o Removed essay like "Server Identification and Verification" 550 section 552 o Added text about keep-alives 553 o Added Configuration Data Model section for client protocol 555 o Improved Security Considerations section 557 A.6. 05 to 06 559 o Addressed comments raised by Alan Luchuk. 561 A.7. 06 to 07 563 o replaced "reference identifier" with "identifier" 565 o added reference to RFC6125 567 o moved reference to 6020 to Informative section 569 Appendix B. Open Issues 571 All issues with this draft are tracked using GitHub issues. Please 572 see: https://github.com/netconf-wg/call-home/issues to see currently 573 opened issues. 575 Author's Address 577 Kent Watsen 578 Juniper Networks 580 EMail: kwatsen@juniper.net