Network Working Group E. Lear Internet-Draft Cisco Systems GmbH Expires: March 20, 2006 September 16, 2005 Simple Firewall Traversal Mechanisms and Their Pitfalls draft-lear-callhome-description-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Many devices make use of so-called "Call Home" functionality in order to be managed or updated, or to otherwise establish outbound communication in the face of NATs, firewalls, and mobility. This memo defines call home functionality, discusses the requirement for firewall traversal, some mechanisms used, and security considerations of those mechanisms. Several existing examples will be shown. This memo also contains a proposal for making SNMP and ISMs a call-home protocol. Lear Expires March 20, 2006 [Page 1] Internet-Draft Call Home Functionality September 2005 1. Introduction In the early days of the networking it was recognized that some devices would be intermittantly reachable. Mechanisms such as UUCP were based on this notion, and support for systems requesting that the server act as the client showed up in the Internet no later than 1982 inSMTP [2] and were formalized in Blocks Extensible eXchange Protocol(BEEP) [3] in 2001. However, in the early days of the Internet it also largely didn't matter from a network security or transparency standpoint which device initiated communication, because there was little if any network security and everyone used public address space. With the introduction of private address space [4]and firewalls the world changed. Today a firewall with NAT functionality is a consumer device, not to mention an interdepartmental device. In addition, the complexity of IT relationships and the number of vendors that support enterprises has changed the underlying assumption that the enterprise actually manages its own network and support devices, such as power distribution units. Often for small businesses, today, the situation is reversed and it is the small business that has limited access to even the network layer of their data center service provider. All of this leads us to the conclusion that a flexible means for management applications to traverse firewalls is a useful approach in the face of devices that intercept unacknowledged SYNS or keep translation tables based on connection state. 2. What is Call Home? "Call Home" (CH) refers simply to the notion of reversing the party that traditionally initiates a communication. An early example of CH is the SMTP "TURN" command where the SMTP server becomes the client and the client becomes the server. 3. What is Call Home good for? Call Home is useful for devices that do not retain a stable accessible point within a network. For instance, a lap top or a wireless phone may move from one location to another, and yet it still is be desirable for that device to be managed when it is online. Imagine what would be necessary in order to manage such a device by having the manager contact it: 1. Either the DNS would have to be updated with the mobile devices new address or the device would have to make use of MOBILE-IP [ref]; Lear Expires March 20, 2006 [Page 2] Internet-Draft Call Home Functionality September 2005 2. The device would have to remain in either the global address space or within the same address space as the manager; 3. Because firewalls often only allow communications one way without prior arrangement (if they have the capability at all), they would have to be informed of the device's new location and that the device is authorized to receive requests. 4. How is Call Home achieved? Because TCP state is easily detected in the header via the ACK bit, the most basic form of CH involves the device wishing to be managed contacting the manager via TCP. This simple approach traverses nearly all consumer and commercial firewalls by default. Because connection state is not as easily discerned for protocols based on UDP, firewalls may be more retiscent to pass UDP traffic and simple NAT mapping timeouts may require contrived or dummy transactions to retain the mapping, but the same principle would apply. 5. How does CH change the nature of the communication? There are several difference between the traditional connection approach and Call Home. In the traditional case of a manager and an agent, the manager would make a request of the agent at any point when the manager wishes. In the case of Call Home, the manager must wait at least until the agent has established a transport connection. This also means that control of connection frequency passes from the manager to the agent. If frequency is important either the behavior must be codified somehow or the manager must pass these parameters to the agent and the agent must use them. Change of whose listening for new connections in the cases of TCP or SCTP further means that a potential DDOS target passes from the agent to the manager. In the traditional case, a manager may use any local TCP or UDP port to initiate a connection but must connect to the agent on a well known (or at least prearranged) port. In the call home case, again the roles are reversed, and it is the manager that must service requests on a well known port. In the traditional case, each agent has a stable well known address, just as it has a well known port. In the case of Call Home, the manager must maintain a stable well known address. Lear Expires March 20, 2006 [Page 3] Internet-Draft Call Home Functionality September 2005 6. Security Considerations The nature of security of the communication is likely to change. While there are many aspects of this problem, the common traditional case requires that the agent somehow authenticate its host address (either via X.509 certificate or SSH host key) and the manager authenticates via public key or username and password. Once again, with Call Home these roles are reversed: the manager authenticates its host address and the agent authenticates via public key or username and password. Some applications might require some additional configuration, therefore, in order to accomodate Call Home. For instance, SNMP requires that the command generator be associated with a SecurityName. If the agent initiates the connection, either it must derive the security name from something like the host key or subject in the certificate of a manager, or it must be preconfigured with a username to associate the connection. As we discuss elsewhere in this document Call Home reverses use of well known ports and services. It is important for CH protocols to make use of well known ports in order to respect the legitimate wishes of firewall administrators. Such use makes (more) reasonable the assumption that a port is blocked for a reason. 7. IANA Considerations While much of this is protocol specific it is within the realm of possibilities that with client/server protocols either a new port or an SSH service name or a BEEP URN will be needed to indicate the intent of the initiator of communication to "turn" it. 8. Summary Call Home is a useful firewall and NAT traversal approach applications can use to augment their existing approach in order to establish communications with devices that sit behind NATs or firewalls, or otherwise have intermittant connectivity. 9. Informational References [1] Pleasant, M. and E. Lear, "Transcending Administrative domains by Automating System Management Tasks in a Large Heterogeneous Environment", Usenix Software Security Workshop , April 1989. [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. Lear Expires March 20, 2006 [Page 4] Internet-Draft Call Home Functionality September 2005 [3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [4] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, March 1994. [5] Lear, E. and K. Crozier, "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)", draft-ietf-netconf-beep-05 (work in progress), April 2005. [6] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000. [7] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. Author's Address Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland Phone: +41 1 878 7525 Email: lear@cisco.com Lear Expires March 20, 2006 [Page 5] Internet-Draft Call Home Functionality September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lear Expires March 20, 2006 [Page 6]