idnits 2.17.1 draft-lear-callhome-description-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 480. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 17, 2005) is 6763 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 informational reference (is this intentional?): RFC 821 (ref. '2') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 1597 (ref. '4') (Obsoleted by RFC 1918) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '8') (Obsoleted by RFC 6275) == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-08 == Outdated reference: A later version (-06) exists of draft-ietf-netconf-ssh-04 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Expires: April 20, 2006 October 17, 2005 6 Simple Firewall Traversal Mechanisms and Their Pitfalls 7 draft-lear-callhome-description-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 20, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Many devices make use of so-called "Call Home" functionality in order 41 to be managed or updated, or to otherwise establish outbound 42 communication in the face of NATs, firewalls, and mobility. This 43 memo defines call home functionality, discusses the requirement for 44 firewall traversal, some mechanisms used, and security considerations 45 of those mechanisms. Several existing examples will be shown. This 46 memo also contains examples of how one would make SNMP over SSH, 47 NETCONF over SSH, and interactive terminal access call-home 48 protocols. 50 1. Introduction 52 In the early days of the networking it was recognized that some 53 devices would be intermittently reachable. Mechanisms such as UUCP 54 [1] were based on this notion, and support for systems requesting 55 that the server act as the client showed up in the Internet no later 56 than 1982 in SMTP [2] and were formalized in Blocks Extensible 57 eXchange Protocol (BEEP) [3] in 2001. 59 However, in the early days of the Internet it also largely didn't 60 matter from a network security or transparency standpoint which 61 device initiated communication, because there was little if any 62 network security and everyone used public address space. With the 63 introduction of private address space [4] and firewalls the world 64 changed. Today a firewall with network address translator (NAT) 65 functionality is a consumer device, not to mention an 66 interdepartmental device. 68 In addition, the complexity of IT relationships and the number of 69 vendors that support enterprises has changed the underlying 70 assumption that the enterprise actually manages its own network and 71 support devices, such as power distribution units. Often for small 72 businesses, today, the situation is reversed and it is the small 73 business that has limited access to even the network layer of their 74 data center service provider. 76 All of this leads us to the conclusion that a flexible means for 77 management applications to traverse firewalls is a useful approach in 78 the face of devices that intercept unacknowledged SYNs or keep 79 translation tables based on connection state. 81 2. What is Call Home and what is it good for? 83 "Call Home" refers simply to the notion of reversing the party that 84 traditionally initiates a communication. An early example of Call 85 Home includes the SMTP "TURN" command where the SMTP server becomes 86 the client and the client becomes the server Various system 87 management protocols such as Track [5][6] have offered similar 88 functionality for quite some time. Most PCs have some means to 89 update their operating systems and virus definitions via a similar 90 mechanism. 92 Call Home is useful for devices that do not retain a stable 93 accessible point within a network. For instance, a lap top or a 94 wireless phone may move from one location to another, and yet it 95 still is be desirable for that device to be managed when it is 96 online. Imagine what would be necessary in order to manage such a 97 device by having the manager contact it: 98 1. Either the DNS would have to be updated with the mobile devices 99 new address or the device would have to make use of MOBILE-IP 100 [8]; 101 2. The device would have to remain in either the global address 102 space or within the same address space as the manager; 103 3. Because firewalls often only allow communications one way without 104 prior arrangement (if they have the capability at all), they 105 would have to be informed of the device's new location and that 106 the device is authorized to receive requests. 108 Call Home also allows for more complex management relationships 109 without the need of complex VPNs and access lists. If an enterprise 110 wished to make use of a contract service for printer maintenance, 111 that service could monitor printers via the MIB defined in [7]. The 112 same scenario could be envisioned for management of uninterrupted 113 power supplies (UPS) via [9]. In either case the vendor has little 114 need of general remote network access, and the enterprise has a 115 desire to limit such access. 117 3. How is Call Home achieved? 119 Call Home already exists in those session-based unicast protocols 120 where the allowed operations and responses do not differ based on who 121 initiated the connection. An example in the routing world would be 122 BGP. Once the connection is established each side authenticates to 123 the other and the same protocol operations may be executed by either 124 end. In the application world, so-called "peer to peer" protocols 125 that are used for (often illicit) file transfer also fit this 126 description. 128 Often, however, protocols are designed with client and server roles. 129 Examples include SMTP, and NNTP. In these cases, some additional 130 support within the application is necessary. In SMTP's case the TURN 131 and ETRN capabilities provide a means for ends to switch roles of 132 client and server. In NNTP a separate mechanism to retrieve articles 133 - NEWNEWS - allows transfer agents to retrieve articles in a similar 134 (albeit not identical) way the IHAVE operation and a queue of 135 messages. 137 The applicability of Call Home in circumstances other than those 138 above is extremely limited. For instance, protocols that are based 139 on atomic transactions, such as DNS queries, have no need to reverse 140 client and server roles. Indeed one would wonder of the intent of a 141 name server that attempted to require a client to make a query of it. 142 Similarly, the notion of Call Home in a multicast environment is 143 likely limited as well as it is not clear who would reverse roles. 145 Because TCP state is easily detected in the header via the ACK bit, 146 call home is also most easily implemented in TCP. Because connection 147 state is not as easily discerned for protocols based on UDP as 148 specifics of each protocol would need to be known and the 149 communication unencrypted, firewalls may be more reticent to pass UDP 150 traffic and simple NAT mapping timeouts may require contrived or 151 dummy transactions to retain the mapping, but the same principle 152 would apply. Hence the usefulness of Call Home in a UDP environment 153 may be limited. 155 4. How does Call Home change the nature of the communication? 157 There are several differences between the traditional connection 158 approach and Call Home. In the traditional case of a manager and an 159 agent, the manager would make a request of the agent at any point 160 when the manager wishes. In the case of Call Home, the manager must 161 wait at least until the agent has established a transport connection. 162 This also means that control of connection frequency passes from the 163 manager to the agent. If frequency is important either the behavior 164 must be codified somehow or the manager must pass these parameters to 165 the agent and the agent must use them. 167 A change of who is listening for new connections in the cases of TCP 168 or SCTP further means that a potential DDOS target passes from the 169 agent to the manager. 171 In the traditional case, a manager may use any local TCP or UDP port 172 to initiate a connection but must connect to the agent on a well 173 known (or at least prearranged) port. In the call home case, again 174 the roles are reversed, and it is the manager that must service 175 requests on a well known port. 177 In the traditional case, each agent has a stable well known address, 178 just as it has a well known port. In the case of Call Home, the 179 manager must maintain a stable well known address. 181 5. Naming Issues 183 One reason to make use of Call Home is that traditional names, such 184 as domain names may not be useful to contact a device, particularly 185 if its IP address changes, either because the device has moved or 186 because it leases addresses from a pool. While it is possible to 187 make use of DNS in such circumstances through mechanisms such as 188 dynamic update [10], such use requires that tight coupling between 189 the subsystem invoked via Call Home and the DNS, and is not 190 particularly meaningful when the connecting device resides behind a 191 NAT or a firewall. 193 When implementing Call Home there are several possibilities for 194 choice of naming system. In some cases, no naming system may be 195 needed. In others, as may be the case with a consumer DSL or cable 196 deployment, the customer username may be sufficient. In other cases, 197 domain names may be suitable. In all cases where names are used the 198 security of the binding between the name and the device or 199 application must be considered. 201 6. Security Considerations 203 The nature of security of the communication is likely to change. 204 While there are many aspects of this problem, the common traditional 205 case requires that the agent somehow authenticate its host address or 206 domain name (either via X.509 [11] certificate or SSH host key) and 207 the manager authenticates via public key or username and password. 208 Once again, with Call Home these roles are reversed: the manager 209 authenticates its host address or domain name and the agent 210 authenticates via public key or username and password. 212 Some applications might require some additional configuration, 213 therefore, in order to accommodate Call Home. For instance, SNMP 214 requires that the command generator be associated with a 215 SecurityName. If the agent initiates the connection, either it must 216 derive the security name from something like the host key or subject 217 in the certificate of a manager, or it must be pre-configured with a 218 username to associate the connection. 220 6.1. Threat / Trust Model Changes 222 In a more traditional client server relationship, the client connects 223 to request some service of the server (thus the terminology). In a 224 way, that does not change with Call Home, because in this case the 225 client is requesting to be managed or is requesting that roles be 226 reversed. The server must still authorize this request. 228 However, there are changes from the traditional model. For instance, 229 if the client is asking to be managed, the nature of attacks change 230 to that of mechanisms such as dictionary attacks on a request port to 231 approaches that trick the client into connecting to a bogus 232 management server where bogus requests could be generated. This can 233 actually have some benefits to security by limiting dictionary and 234 buffer overflow attacks, to centralized well protected points, 235 provided that the communication initiated by the client is well 236 protected with such mechanisms as SSL, TLS, and the like; and the 237 client itself does not listen for requests. 239 Finally, the underlying application that makes use of Call Home will 240 have to consider the sort of information that is being made available 241 as a service. Each application will have different sorts of threats 242 and mitigations. For instance, the author knows of no SMTP agent 243 that implements TURN because while most SMTP users are comfortable 244 with the risks of Man in the Middle attacks associated with 245 masquerading as SMTP servers, the risk of someone masquerading as a 246 client are considered unacceptable. 248 In all cases, strong authentication of either end of the 249 communication is recommended for exchange of sensitive information, 250 regardless of who started it. 252 6.2. Firewall Administration 254 As we discuss elsewhere in this document Call Home reverses use of 255 well known ports and services. It is important for Call Home 256 protocols to make use of well known ports in order to respect the 257 legitimate wishes of firewall administrators. Such use makes more 258 reasonable the assumption that a port is blocked for a reason. A 259 firewall administrator may wish to allow certain communications in a 260 single direction. Use of additional well known ports may be advised 261 in certain circumstances. However, the ability of devices and 262 protocols to call home exists today through SSL connections, to give 263 but one example. Excessive barriers to inclusion of call home 264 functionality in protocols risks inappropriate use of existing 265 substrates. 267 7. Example 1: NETCONF using SSH 269 NETCONF [12] is a fairly simple client/server protocol. NETCONF is 270 mapped to several protocols, including SSH.[13] In order for NETCONF 271 agents to call home some protocol operation must be passed to the 272 manager for this purpose, and this operation can occur in the 273 protocol mapping layer. Thus, the simplest approach would be to have 274 a new SSH subsystem called "netconf-turn". When the SSH client 275 invokes this subsystem, the SSH server either will initiate the the 276 subsystem and proceed with NETCONF capabilities exchange from the 277 point of view of a manager or refuse to initiate the subsystem. 279 The nature of the NETCONF communication changes in that the manager 280 must wait for the agent to connect, as mentioned above. There are no 281 events explicitly defined in NETCONF at this time and so there are no 282 explicit functions that require deferral from a protocol standpoint. 283 However, the manager cannot configure the agent until it connects and 284 so completion of a configuration request may be deferred when a 285 manager is not in communication with an agent. The manager must 286 retain configuration requests and higher level application must be 287 able to deal with such deferrals. 289 From an authentication standpoint, the SSH server must determine 290 whether based on the credentials given the client has appropriate 291 access to be managed. Each NETCONF management operation on the SSH 292 server must be governed by those credentials. 294 On the client, it would be a configuration error for it to invoke the 295 netconf-turn subsystem on the manager and then not allow ANY 296 operations, but each operation must be authorized based on the server 297 identity passed up by the SSH subsystem. 299 8. Example 2: SNMP over SSH 301 Let us again first discuss the nature of the communication. In the 302 case of SNMP there are ostensibly two basic protocol operations - 303 request and response. While in theory either entity may make such 304 requests in practice only one end issues GET, SET, or GET-BULK 305 operations while the other end issues notifications. 307 SNMP does not specify when GET, SET, and GET-BULK are to be executed, 308 as these choices are left to the application or the user. Therefore, 309 the analysis given for NETCONF regarding deferral is just as 310 applicable to SNMP. However, in the case of notifications, SNMP does 311 specify when these occur based on the MIB definitions. Had the 312 designers of SNMP version 3 not allowed for the SNMP-TARGET-MIB, a 313 change to the protocol base would have been required. But because 314 such a MIB exists, all that remains is how it should be configured. 315 There are two cases: 316 o It is desired that no events be deferred and the agent connect to 317 the manager, just as would be the case in RFC 3430. In this case, 318 the SNMP-TARGET-MIB is configured externally to use (presumably) 319 the SSHSM security model to contact the manager when a 320 notification is to be sent. The SSHSM will define initial 321 connection semantics. 322 o It is desired that notifications be deferred until the manager 323 contacts the agent. Here once the SSHSM subsystem is invoked by 324 the manager, a policy is triggered to configure the SNMP-TARGET- 325 MIB to receive events appropriate to the manager. 327 The following is speculative as work on [14] is not complete. That 328 document specifies a means to extend the SNMP protocol to use SSH. 329 SSH establishes a session and will to SNMP via SSHSM a securityName 330 that may be used for purposes of authorization. Once established the 331 connection may be used for any purpose, no matter the original 332 purpose in a vein similar to that specified by RFC 3430 [15] provided 333 each end is properly authorized. Once again, it would be a 334 configuration error for a device to connect for the purposes of being 335 monitored or configured by a manager to not accept any operations. 336 It would similarly be a configuration error for a device to connect 337 for purposes of sending notifications but then not have any possibly 338 allowed. 340 9. Example 3: Remote terminal access via Call Home SSH 342 Consider the case of a device that is managed by administration that 343 resides on the other (public, if you will) side of a firewall. When 344 the device starts it initiates an SSH connection, perhaps with the 345 intent of starting a netconf or SSHSM session. When a problem 346 arises, however, the administrator may want interactive access to the 347 device to debug the problem. The administrator makes use of a tool 348 on the network management station that causes the NMS to request a 349 "session"connection, thus allowing the administrator interactive 350 command line access even through the device initiated the connection. 352 Section 6.1 of [16] rightly encourages client implementations to 353 reject such requests. However, if they are prepared to trust the 354 device they are connecting to for maintenance and debugging purposes, 355 the benefit may outweigh the risks. In all cases, the session should 356 be properly authorized, meaning that the agent should be configured 357 to allow appropriate access to those who have appropriate access to 358 the NMS, and the NMS should properly authenticate and authorize that 359 access. 361 In this example, a naming method must be employed at the very least 362 by the NMS in order to properly identify the correct device to 363 connect to. 365 10. IANA Considerations 367 While much of this is protocol specific it is within the realm of 368 possibilities that with client/server protocols either a new port or 369 an SSH service name or a BEEP URN will be needed to indicate the 370 intent of the initiator of communication to "turn" it. 372 11. Summary 374 Call Home is a useful - and in some circumstances necessary - 375 firewall and NAT traversal approach applications can use to augment 376 their existing approach in order to establish communications with 377 devices that sit behind NATs or firewalls, or otherwise have 378 intermittent connectivity. 380 12. Informational References 382 [1] Nowitz, D., Lesk, M., and G. Chesson, "A Dial-8p Network of 383 UNIX Systems", UNIX System 7 , August 1978. 385 [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 386 August 1982. 388 [3] Rose, M., "The Blocks Extensible Exchange Protocol Core", 389 RFC 3080, March 2001. 391 [4] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, 392 "Address Allocation for Private Internets", RFC 1597, 393 March 1994. 395 [5] Nachbar, D., "When Network File Systems Aren't Enough: 396 Automatic Software Distribution Revisited", Proceedings of 397 Usenix Summer 1986 , June 1986. 399 [6] Pleasant, M. and E. Lear, "Transcending Administrative domains 400 by Automating System Management Tasks in a Large Heterogeneous 401 Environment", Usenix Software Security Workshop , April 1989. 403 [7] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2", 404 RFC 3805, June 2004. 406 [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 407 IPv6", RFC 3775, June 2004. 409 [9] Case, J., "UPS Management Information Base", RFC 1628, 410 May 1994. 412 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 413 Update", RFC 3007, November 2000. 415 [11] International International Telephone and Telegraph 416 Consultative Committee, "Information Technology - Open Systems 417 Interconnection - The Directory: Authentication Framework", 418 CCITT Recommendation X.509, November 1988. 420 [12] Enns, R., "NETCONF Configuration Protocol", 421 draft-ietf-netconf-prot-08 (work in progress), September 2005. 423 [13] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration 424 Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-04 425 (work in progress), April 2005. 427 [14] Harrington, D., "Secure Shell Security Model for SNMP", 428 draft-harrington-isms-secshell-01 (work in progress), 429 September 2005. 431 [15] Schoenwaelder, J., "Simple Network Management Protocol Over 432 Transmission Control Protocol Transport Mapping", RFC 3430, 433 December 2002. 435 [16] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", 436 draft-ietf-secsh-connect-25 (work in progress), March 2005. 438 Appendix A. Changes 439 o From -02 to -03: Added naming and interactive terminal sections. 440 o From -01 to -02: reworded limitations of UDP and call home. 441 Expanded security considerations. Spell-checked. 442 o From -00 to -01: provided more detail on Call Home applicability 443 in the cases of unicast session based versus other. Discussed the 444 difference between p2p protocols versus client server. Provided 445 more examples. 447 Author's Address 449 Eliot Lear 450 Cisco Systems GmbH 451 Glatt-com 452 Glattzentrum, ZH CH-8301 453 Switzerland 455 Phone: +41 1 878 7525 456 Email: lear@cisco.com 458 Intellectual Property Statement 460 The IETF takes no position regarding the validity or scope of any 461 Intellectual Property Rights or other rights that might be claimed to 462 pertain to the implementation or use of the technology described in 463 this document or the extent to which any license under such rights 464 might or might not be available; nor does it represent that it has 465 made any independent effort to identify any such rights. Information 466 on the procedures with respect to rights in RFC documents can be 467 found in BCP 78 and BCP 79. 469 Copies of IPR disclosures made to the IETF Secretariat and any 470 assurances of licenses to be made available, or the result of an 471 attempt made to obtain a general license or permission for the use of 472 such proprietary rights by implementers or users of this 473 specification can be obtained from the IETF on-line IPR repository at 474 http://www.ietf.org/ipr. 476 The IETF invites any interested party to bring to its attention any 477 copyrights, patents or patent applications, or other proprietary 478 rights that may cover technology that may be required to implement 479 this standard. Please address the information to the IETF at 480 ietf-ipr@ietf.org. 482 Disclaimer of Validity 484 This document and the information contained herein are provided on an 485 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 486 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 487 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 488 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 489 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 490 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 492 Copyright Statement 494 Copyright (C) The Internet Society (2005). This document is subject 495 to the rights, licenses and restrictions contained in BCP 78, and 496 except as set forth therein, the authors retain all their rights. 498 Acknowledgment 500 Funding for the RFC Editor function is currently provided by the 501 Internet Society.