Network Working Group E. Lear
Internet-Draft Cisco Systems GmbH
Expires: April 6, 2006 October 3, 2005
Simple Firewall Traversal Mechanisms and Their Pitfalls
draft-lear-callhome-description-01.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 April 6, 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 April 6, 2006 [Page 1]
Internet-Draft Call Home Functionality October 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 in SMTP [3] and were formalized in Blocks Extensible eXchange
Protocol (BEEP) [4] 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 [5] 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" refers simply to the notion of reversing the party that
traditionally initiates a communication. An early example of Call
Home is the SMTP "TURN" command where the SMTP server becomes the
client and the client becomes the server. Various system management
protocols such as Track [1][2] have offered similar functionality for
quite some time.
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
Lear Expires April 6, 2006 [Page 2]
Internet-Draft Call Home Functionality October 2005
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];
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?
Call Home already exists in those session-based unicast protocols
where the allowed operations and responses do not differ based on who
initiated the connection. An example in the routing world would be
BGP. Once the connection is established each side authenticates to
the other and the same protocol operations may be executed by either
end. In the application world, so-called "peer to peer" protocols
that are used for (often illicit) file transfer also fit this
description.
Often, however, protocols are designed with client and server roles.
Examples include SMTP, and NNTP. In these cases, some additional
support within the application is necessary. In SMTP's case the TURN
and ETRN capabilities provide a means for ends to switch roles of
client and server. In NNTP a separate mechanism to retrieve articles
- NEWNEWS - allows transfer agents to retrieve articles in a similar
(albeit not identitical) way the IHAVE operation and a queue of
messages.
The applicability of Call Home in circumstances other than those
above is extremely limited. For instance, protocols that are based
on atomic transactions, such as DNS queries, have no need to reverse
client and server roles. Indeed one would wonder of the intent of a
name server that attempted to require a client to make a query of it.
Similarly, the notion of Call Home in a multicast environment is
likely limited as well as it is not clear who would reverse roles.
Because TCP state is easily detected in the header via the ACK bit,
call home is also most easily implemented in TCP. 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. Hence the
usefulness of Call Home in a UDP environment may diminish.
Lear Expires April 6, 2006 [Page 3]
Internet-Draft Call Home Functionality October 2005
5. How does Call Home change the nature of the communication?
There are several differences 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.
A change of who is 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.
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 Call Home
Lear Expires April 6, 2006 [Page 4]
Internet-Draft Call Home Functionality October 2005
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. Example 1: NETCONF using SSH
NETCONF [6] is a fairly simple client/server protocol. NETCONF is
mapped to several protocols, including SSH.[7] In order for Netconf
agents to call home some protocol operation must be passed to the
manager for this purpose, and this operation can occur in the
protocol mapping layer. Thus, the simplest approach would be to have
a new SSH subsystem called "netconf-turn&qout;. When the SSH client
invokes this subsystem, the SSH server either will initiatiate the
the subsystem and proceed with NETCONF capabilities exchange from the
point of view of a manager or refuse to initiate the subsystem.
The nature of the NETCONF communication changes in that the manager
must wait for the agent to connect, as mentioned above. There are no
events explicitly defined in NETCONF at this time and so there are no
explicit functions that require deferral from a protocol standpoint.
However, the manager cannot configure the agent until it connects and
so completion of a configuration request may be deferred when a
manager is not in communication with an agent. The manager must
retain configuration requests and higher level application must be
able to deal with such deferrals.
From an authentication standpoint, the SSH server must determine
whether based on the credentials given the client has appropriate
access to be managed. Each NETCONF management operation on the SSH
server must be governed by those credentials.
On the client, it would be a misconfiguration for it to invoke the
netconf-turn subsystem on the manager and then not allow ANY
operations, but each operation must be authorized based on the server
identity passed up by the SSH subsystem.
8. Example 2: SNMP over SSH
Let us again first discuss the nature of the communication. In the
case of SNMP there are ostensibly two basic protocol operations -
request and response. While in theory either entity may make such
requests in practice only one end issues GET, SET, or GET-BULK
operations while the other end issues notifications.
SNMP does not specify when GET, SET, and GET-BULK are to be executed,
as these choices are left to the application or the user. Therefore,
Lear Expires April 6, 2006 [Page 5]
Internet-Draft Call Home Functionality October 2005
the analysis given for netconf regarding deferral is just as
applicable to SNMP. However, in the case of notifications, SNMP does
specify when these occur based on the MIB definitions. Had the
designers of SNMP version 3 not allowed for the SNMP-TARGET-MIB, a
change to the protocol base would have been required. But because
such a MIB exists, all that remains is how it should be configured.
There are two cases:
It is desired that no events be deferred and the agent connect to
the manager, just as wouldbe the case in RFC 3430. In this case,
the SNMP-TARGET-MIB is configured externally to use (presumably)
the SSHSM security model to contact the manager when a
notification is to be sent. The SSHSM will define initial
connection semantics.
It is desired that notifications be deferred until the manager
contacts the agent. Here once the SSHSM subsystem is invoked by
the manager, a policy is triggered to configure the SNMP-TARGET-
MIB to receive events appropriate to the manager.
The following is speculative as work on [8] is not complete. That
document specifies a means to extend the SNMP protocol to use SSH.
SSH establishes a session and will to SNMP via SSHSM a securityName
that may be used for purposes of authorization. Once established the
connection may be used for any purpose, no matter the original
purpose in a vein similar to that specified by RFC 3430 [9] provided
each end is properly authorized. Once again, it would be a
configuration error for a device to connect for the purposes of being
monitored or configured by a manager to not accept any operations.
It would similarly be a configuration error for a device to connect
for purposes of sending notifications but then not have any possibly
allowed.
9. 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.
10. Summary
Call Home is a useful - and in some circumstances necessary -
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.
Lear Expires April 6, 2006 [Page 6]
Internet-Draft Call Home Functionality October 2005
11. Informational References
[1] Nachbar, D., "When Network File Systems Aren't Enough: Automatic
Software Distribution Revisited", Proceedings of Usenix Summer
1986 , June 1986.
[2] Pleasant, M. and E. Lear, "Transcending Administrative domains
by Automating System Management Tasks in a Large Heterogeneous
Environment", Usenix Software Security Workshop , April 1989.
[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[4] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[5] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot,
"Address Allocation for Private Internets", RFC 1597,
March 1994.
[6] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-08 (work in progress), September 2005.
[7] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration
Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-04
(work in progress), April 2005.
[8] Harrington, D., "Secure Shell Security Model for SNMP",
draft-harrington-isms-secshell-01 (work in progress),
September 2005.
[9] Schoenwaelder, J., "Simple Network Management Protocol Over
Transmission Control Protocol Transport Mapping", RFC 3430,
December 2002.
Appendix A. Changes
From -00 to -01: provided more detail on Call Home applicability in
the cases of unicast session based versus other. Discussed the
difference between p2p protocols versus client server. Provided more
examples.
Lear Expires April 6, 2006 [Page 7]
Internet-Draft Call Home Functionality October 2005
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 April 6, 2006 [Page 8]
Internet-Draft Call Home Functionality October 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 April 6, 2006 [Page 9]