INTERNET DRAFT EXPIRES JUNE 1999 INTERNET DRAFT Network Area S. Mercer Internet Draft Storage Technology Corp. A. Molitor Storage Technology Corp. M. Hurry Siemens ICN T. Ngo Sun Microsystems, Inc. H.323 Firewall Control Interface (HFCI) Status of This Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Introduction It is becoming clear that next generation telephony networks will be built on top of IP-based networks, as opposed to the traditional voice technology. There are several reasons for this, among them lower cost and greater flexibility. While there are several Voice on IP (VoIP) solutions, the H.323 [2] standard from the ITU seems to be a major player. Other solutions will probably resemble H.323, even if they do not comply with the standard. This memo proposes an Application Interface to permit H.323 devices to open 'pinholes' in an otherwise opaque firewall, to permit the traffic necessary for H.323 through, and nothing else. Since other VoIP solutions resemble H.323, at least approximately, the same Application Interface may well be useful for them. In particular, Real-Time Protocol (RTP), defined in RFC1889 [3], is likely to be the underlying voice transport for any VoIP solution. Motivation There are several reasons why it is difficult to get H.323 packets through a firewall. See [1]. Among the reasons are: 1. Most of the control information is encoded in ASN.1, which is a complex encoding scheme and does not end up with fixed byte Mercer, Molitor, Hurry, Ngo [Page 1] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 offsets for address information. 2. An H.323 call is made of several different simultaneous connections. Q.931 and H.245 use TCP connections, and for an audio-only conference, there may be up to 4 different UDP 'connections' made. 3. The addresses and ports numbers are exchanged within the data stream of the 'next higher' connection. Q.931 uses well-known TCP port 1720. Within the Q.931 data stream, dynamic TCP ports for H.245 connections are negotiated. Within the H.245 data stream, it also has commands that open dynamic UDP 'connections' for RTP and RTCP. This makes it particularly difficult for firewalls that perform network address translation, because they need to modify the addresses inside these data streams. The firewall not only has to monitor data streams and disassemble the packets on the control streams, it must also be able to recompose valid data in the control streams as is traverses the firewall. For these reasons, many firewalls either do not support H.323 or all UDP ports have to be opened on the firewall to allow H.323 packets to go through, which introduces substantial security risk. Since the H.323 devices already have the complicated H.323 logic, it would be beneficial to have a protocol between H.323 devices and firewalls to permit H.323 devices to temporarily open 'pinholes' in a firewall to allow H.323 traffic through, and an application programming interface for H.323 devices to send commands to the firewall through the protocol. There are several advantages to this approach: 1. Firewalls do not have to implement the complicated H.323 logic to detect setup or teardown of communication sessions 2. Better performance on the firewall since it does not incur the processing overhead to monitor data streams nor does it parse ASN.1 in H.323 packets. Scope This memo is intended to define an interface for communications between two specific components of an H.323 solution. The details of implementing and securing the communications channel are outside the Mercer, Molitor, Hurry, Ngo [Page 2] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 scope of this memo. The nature of the underlying channel may be wildly different between implementations of H.323 solutions, so no protocol will fit all architectures. However, it is the intent of the authors to introduce a follow-up memo with a protocol suitable for implementing the interface specified in this memo. While the protocol may not be as widely applicable as the interface specified in this memo, it will have some degree of generality. This protocol will, of course, address the relevant security issues. We wish to begin by introducing the functionality, and to improve it through feedback, before proceeding to commit it to a protocol. For these reasons, no protocol suitable for implementing this interface is defined herein. Since no protocol is defined, we present only a sketch of the security requirements for such a protocol. Definitions The word 'Gateway', in an H.323 context, is a device which translates some non-H.323 communications service (e.g. Plain Old Telephone Service, H.320, etc.) into H.323. service word 'Gatekeeper', in an H.323 context, is a device which contains the call control intelligence to establish and terminate H.323 compliant communications sessions. Note that a Gateway may, or may not, include the Gatekeeper functions. If a Gateway does not, it must rely on a remote Gatekeeper to handle these necessary functions. The word 'Proxy', in an H.323 context, means a Gateway which translates from H.323 to H.323. This device is very much like a proxy firewall, but for H.323 applications. Indeed, it may be integrated with a traditional proxy firewall for IP applications, and provide H.323 connectivity through that firewall. Herein, 'signaling' is used in the telephony sense, to describe control traffic used to set up a telephone call. For H.323, signaling is carried out using the Q.931 and H.245 recommendations of the ITU. The word 'session' is used to refer to all the connections and state information associated with a telephone call. This includes TCP connections used to pass signaling traffic, as well as UDP based connections passing the actual voice traffic. Relation with the H.323 standards Mercer, Molitor, Hurry, Ngo [Page 3] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 Since RTP is a dominant standard for the transport portion of VoIP solutions, the means to dynamically open and close ports for this class of UDP traffic on a firewall has to be addressed. The HFCI is designed as an interface between the H.323 compliant gateway or gatekeeper and a designated firewall to open and close permissions for the ephemeral ports negotiated to complete the H.323 session, including the RTP transport portion. The HFCI provides the gateway or gatekeeper the ability to manage the firewall, opening specific TCP permissions for well-known or registered ports, in support of VoIP services and applications, and opening only the negotiated TCP and UDP port permissions necessary to allow the H.245 session to transmit the voice and control traffic, for each call. General Considerations The bulk of H.323 negotiation, as well as the voice traffic itself, is carried over connections between ephemeral ports. Each level of negotiation will select, more or less at random, ports for the next level. This makes "firewalling" H.323 very difficult, without being one of the players in the negotiations. The most reasonable model seems to be to provide the H.323 Proxy, as simply as possible, with mechanisms to manage a firewalling device with the pinpoint accuracy required. The H.323 signaling traffic is carried over TCP streams, and is not very latency sensitive. Of course, the end-user would like calls to be set up in a timely fashion, but certainly the usual application- space proxy is a suitable model here. However, the voice traffic itself is carried in small UDP datagrams, passed between ephemeral ports, and is very latency sensitive. This traffic is ideally suited for management by a packet filtering device. Luckily, the H.323 Proxy model (see [1]) permits the voice traffic to pass in parallel to the signaling traffic. Thus, signaling traffic may be firewalled by a proxy firewall of the usual architecture, while the voice traffic passes through a high-speed, low-latency packet filter. In order to be effective, this packet filtering device must be under the control of the Proxy. For convenience, we assume that the packet filtering may also be filtering the signaling traffic (though, of course, it need not). This memo outlines an interface suitable for an H.323 Gateway or Gatekeeper to control a filtering device, to provide the precise controls needed to manage the several layers of signaling, and the voice traffic itself. This permits the use of H.323 over public IP networks, with the smallest possible risk exposure. Control Interface Mercer, Molitor, Hurry, Ngo [Page 4] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 This memo proposes a simple set of methods, suitable for implementation as a functional interface, or through RPC or RPC-like mechanisms. The goal is to define the exact functionality required to manage a filtering device, for controlling H.323 traffic. The protocol definition is given as a set of procedures with arguments and results, in the style of RFC1094, the specification for NFS. Init returnCode = Init() This initializes the implementation of the API, and may or may not do anything important. It exists as a placeholder, to permit an implementation the opportunity to set up any internal data structures. This should be invoked only once. FirewallInit returnCode = FirewallInit( firewallIpAddress, firewallType, userId, authenticationType, authenticationData, subDeviceId, h323GatewayAddress, h323GatewayPort, returnedFirewallId) This initializes an abstract "control channel" to a filtering device. Any initialization required to access the filtering device (key exchange, connect socket, etc.) may be performed by the underlying implementation at this point. This may be invoked as many times as necessary to establish control connections to specific filtering devices, and sub-devices within them. firewallIpAddress The administrative IP address of the filtering device. If the filtering device is internal, or otherwise implicitly addressed, the Mercer, Molitor, Hurry, Ngo [Page 5] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 parameter may be ignored. firewallIpAddress is either a 32 bit IPv4 address or a 128 bit IPv6 address. firewallType An appropriate member of an enumeration identifying the filtering device type. This may be used by the underlying implementation to support multiple filtering device types. firewallType is an unsigned 32 bit integer. Currently defined firewallType values include: FIREWALL_TYPE_NETSENTRY 0xa1880001 userId, authenticationType, authenticationData In the event that the filtering device requires some login procedure, these arguments are intended to provide material to perform that login. Some or all of them may be ignored by an underlying implementation. For the purposes of this memo, these are abstract, opaque, data, agreed upon by the application and the underlying implementation. The userId is a numeric identifier, intended (naturally) to identify which user profile to login as. The authenticationType is an appropriate member of an enumeration, which determines the structure of the authenticationData. The authenticationData is the actual material used to authenticate. For example, the authenticationType might specify "MD5", or "Password"; in the former case, the authentication data would probably contain a 128 bit secret, in the latter, a secret text string. userId is an unsigned 32 bit integer. authenticationType is an unsigned 32 bit integer. Currently defined authenticationType values include: AUTH_TYPE_NONE 1 AUTH_TYPE_MD5 2 AUTH_TYPE_PASSWORD 3 AUTH_TYPE_SHA1 4 authenticationData is the address of a data structure appropriate for the authentication type. subDeviceId A numeric identifier specifying which abstract filtering device Mercer, Molitor, Hurry, Ngo [Page 6] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 within the larger device specified by the firewallIpAddress, with which we intend to communicate. A given implementation may ignore this, if the filtering device in question has no notion of sub- devices. subDeviceId is an unsigned 32 bit integer. h323GatewayAddress, h323GatewayPort These specify the IP address and TCP port number of the H.323 Gateway device to which Q.931 connections are to be made as the initial component of call setup. This is usually the well-known port 1720, and is the only fixed port in the entire H.323 call-setup scheme. h323GatewayAddress is either a 32 bit IPv4 address or a 128 bit IPv6 address. h323GatewayPort is an unsigned 16 bit integer. returnedFirewallId This is an opaque numeric identifier returned by the underlying implementation, which is used by the application to uniquely identify the desired filtering device in subsequent API calls. returnedFirewallId is an address for an unsigned 32 bit integer. FirewallShutdown returnCode = FirewallShutdown( firewallId) This method performs the inverse of the FirewallInit method, and tears down any underlying state implementing the control channel. This may include closing a socket, invalidating key material, or possibly nothing at all, depending on the underlying implementation. firewallId This is the opaque numeric identifier returned by the FirewallInit method. firewallId is an unsigned 32 bit integer. OpenPermission returnCode = OpenPermission( Mercer, Molitor, Hurry, Ngo [Page 7] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 firewallId, ipAddress1, port1, ipAddress2, port2, protocol, sessionId, returnedPermissionId) This opens a single "pinhole" in the firewall implemented by the filtering device. It may allow a single TCP connection to proceed for some H.323 control traffic, or it may open a pair of adjacent UDP ports, to permit voice traffic between a pair of endpoints to pass. The permission opened is tagged with a session identifier, which uniquely identifies (within the scope of the underlying implementation) the "phone call" that the permission is for. firewallId This is the opaque numeric identifier returned by the FirewallInit method. firewallId is an unsigned 32 bit integer ipAddress1, port1, ipAddress2, port2. These are the IP addresses and port numbers of the two endpoints of communication, for which permission for communication should be opened. This may be a set of addresses and ports for a specific stage of H.323 signaling, or for the actual voice traffic. If the protocol (see below) specifies that this is a UDP connection, the port numbers are constrained to be even numbered, and the actual connection permissions will apply to the specified port numbers, as well as the next port numbers in sequence. This is because the UDP traffic passed by an H.323 call actually uses two adjacent UDP port pairs, which are always evenly aligned. See RFC1889 on RTP [3], for the details. Thus, if the protocol specified is UDP, and (for example) port1 is 1764 and port2 is 20562, then UDP traffic would be permitted between the two specified IP addresses, and ports 1764,1765 on ipAddress1, and ports 20562,20563 on ipAddress2. ipAddress1 and ipAddress2 are either 32 bit IPv4 addresses or 128 bit IPv6 addresses. Mercer, Molitor, Hurry, Ngo [Page 8] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 port1 and port2 are unsigned 16 bit integers. protocol One of an enumeration specifying either TCP or UDP. This determines whether the port numbers are TCP port numbers (for signaling traffic) or UDP port numbers (for data traffic). protocol is an unsigned 8 bit integer. Currently defined protocol values include: TCP 6 UDP 17 sessionId This is an identifier passed to the underlying implementation which uniquely identifies the "phone call" to which this permission is to belong. It may also be unused, if the calling application has no need to bundle permissions together into a session. This identifier may be used with the CloseSession method (described below) to revoke all permissions that have been granted for a single phone call session. sessionId is an unsigned 32 bit integer. returnedPermissionId This is an opaque numeric identifier returned by the underlying implementation, which uniquely identifies the permission opened by this invocation. This identifier may be used with the ClosePermission method (described below) to revoke this specific permission. returnedPermissionId is an address for an unsigned 32 bit integer. ClosePermission returnCode = ClosePermission( firewallId, permissionId) This performs the inverse operation of the OpenPermission method. firewallId This is the opaque numeric identifier returned by the FirewallInit method. Mercer, Molitor, Hurry, Ngo [Page 9] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 firewallId is an unsigned 32 bit integer permissionId This is the opaque numeric identifier returned by the OpenPermission method, which uniquely identifies the permission to be closed down. permissionId is an unsigned 32 bit integer. CloseSession returnCode = CloseSession( firewallId, sessionId) This performs a ClosePermission operation for all the permissions with a specified session identifier. This effectively closes all the (possibly several) "pinholes" opened up for a given "phone call" session. firewallId This is the opaque numeric identifier returned by the FirewallInit method. firewallId is an unsigned 32 bit integer sessionId This is the session identifier provided by the calling application to one or more OpenPermission invocations, which identifies the bundle of permissions making up the phone call session. sessionId is an unsigned 32 bit integer. Return Codes Return codes for all procedures are unsigned 32 bit integers. General Codes SUCCESS 0xa1881017 Indicates that the method invocation was successful. Bad Parameter Codes Each of these codes indicates that the indicated parameter of the Mercer, Molitor, Hurry, Ngo [Page 10] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 method invocation was, in some way, 'bad'. If multiple parameters are bad, the underlying implementation may return any appropriate bad parameter code. BAD_ADDRESS1 0xa1881002 BAD_ADDRESS2 0xa1881003 BAD_AUTH_DATA 0xa1881004 BAD_AUTH_TYPE 0xa1881005 BAD_DEVICE_ID 0xa1881006 BAD_FIREWALL_ADDRESS 0xa1881007 BAD_FIREWALL_ID 0xa1881008 BAD_FIREWALL_TYPE 0xa1881009 BAD_GATEWAY_ADDRESS 0xa188100a BAD_GATEWAY_PORT 0xa188100b BAD_PERMISSION_ID 0xa188100c BAD_PORT1 0xa188100d BAD_PORT2 0xa188100e BAD_PROTOCOL 0xa188100f BAD_SESSION_ID 0xa1881010 BAD_USER_ID 0xa1881011 Incorrect State Codes NOT_INITIALIZED 0xa1881015 This indicates that some method was invoked which must be preceded by a suitable invocation of an initialization method. Normally, this indicates that the Init method was not invoked. ALREADY_INITIALIZED 0xa1881001 This may be returned by an invocation of Init or FirewallInit, to indicate that a suitable invocation has already be performed. Mercer, Molitor, Hurry, Ngo [Page 11] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 If this is returned, the internal state of the underlying implementation should be unchanged by the method invocation. Internal Errors COMMUNICATION_ERROR 0xa1881012 If the filtering device is remotely addressed in some fashion, and communications with it fail (possibly because of incorrect authentication data), this code should be returned. MEMORY_ALLOCATION_ERROR 0xa1881013 Returned when a memory exhaustion condition has been encountered. MEMORY_CORRUPTION_ERROR 0xa1881014 Returned when a memory corruption problem has been detected. The underlying implementation should use structure tagging, especially if it is a library to be linked against an H.323 Gateway or Proxy application. This may indicate that the surrounding application has some problem. PROVISIONING_ERROR 0xa1881016 A generic error returned if some problem managing the filtering device was encountered. HFCI Usage General Description The HFCI implements this set of commands to facilitate the administrative communication flow between the gateway and firewall. Each command is invoked by the gateway or gatekeeper to control the firewall. Init FirewallInit OpenPermission ClosePermission CloseSession FirewallShutdown The first two commands are invoked to initiate the control communication and create permissions for an initial set of well-known or registered ports. OpenPermission is used to grant permissions on specific ports to support the H.323 connections. The next two Mercer, Molitor, Hurry, Ngo [Page 12] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 commands revoke individual permissions or the set of all permissions granted for a specific H.323 session. The final command revokes all permissions granted and terminates communication with the firewall. To simplify the explanation, the term "gateway" will be used below instead of the terms "gateway or gatekeeper". Initialization Prior to initialization, the firewall must be configured with a userId and proper authentication information to grant appropriate administrative access for the gateway. When the gateway is placed in service, the gateway will initialize the HFCI with the Init command, and will then initiate the control communication with the firewall by invoking the HFCI FirewallInit command. The firewall will use the provided userId and authentication information to verify that the gateway has authorization to manage the firewall. During the initialization process, the firewall will be instructed to grant permissions for an initial set of well-known or registered ports to permit initial Q.931 connections destined for the gateway. Opening Ports With the control communication established and the firewall and gateway ready for service, the gateway may use the HFCI to tell the firewall to open permissions for specific TCP ports to allow various application communications to be established with the gateway. This is accomplished by invoking the OpenPermission command, possibly several times. When an H.323 session is established, the gateway will use the HFCI OpenPermission command to tell the firewall to grant permissions for specific TCP and UDP ports to support the voice and control traffic. The permissions opened for each session are marked with a unique session identifier, provided by the gateway, to facilitate revoking those permissions when the session is terminated. Closing Ports After the gateway receives an acknowledgment that a specific session is terminated, the gateway uses the HFCI CloseSession and/or ClosePermission commands to tell the firewall to revoke the TCP and UDP permissions that were granted for that session. Call Setup Flow Scenario To accurately describe the way the HFCI will be used, a possible call flow between two gateways with HFCI implemented, separated by a Mercer, Molitor, Hurry, Ngo [Page 13] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 firewall, is described. When implemented in a network, each gateway would be protected behind a firewall. A single firewall is used here to simplify the concept. This diagram is meant to exhibit the behavior of the HFCI with respect to typical Q.931 and H.245 messages required to setup and establish an H.323 compliant session. For clarity purposes, Gateway A is considered external to the firewall and not protected by it. Gateway B is considered internal to and protected by the firewall. Gateway B is authorized to use the HFCI to manage the firewall. Gateway A (External) Firewall Gateway B (Internal) 1. Q.931 TCP port 1720 --> (fixed pinhole) --> Setup 2. <-- (fixed pinhole) <-- Call Proceeding 3. <-- (fixed pinhole) <-- Alerting 4. <-- HFCI Open TCP port for H.245 "pinhole A" 5. <-- (pinhole A) <-- Gateway B Connect (H.245) 6. H.245 Messages <--> (pinhole A) <--> H.245 Messages 7. Open RTP Channel --> (pinhole A) --> 8. <-- HFCI Open UDP ports for RTP "pinhole B" 9. <-- (pinhole A) <-- Open RTP channel ACK 10. <-- (pinhole A) <-- Open RTCP Channel 11. Open RTCP Channel ACK --> (pinhole A) --> 12. RTP/RTCP Messages <--> (pinhole B) <--> RTP/RTCP Messages Call Disconnect Flow Scenario This diagram is meant to exhibit the behavior of the HFCI with Mercer, Molitor, Hurry, Ngo [Page 14] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 respect to typical H.225 and H.245 messages required to terminate an H.323 compliant session. For clarity purposes, Gateway A is considered external to the firewall and not protected by it. Gateway B is considered internal to and protected by the firewall. Gateway B is authorized to use the HFCI to manage the firewall. Gateway A (External) Firewall Gateway B (Internal) 1. Disconnect --> (pinhole A) --> 2. <-- (pinhole A) <-- Disconnect ACK 3. Close RTP/RTCP ports --> (pinhole A) --> 4. <-- HFCI, close pinhole B 5. <-- (pinhole A) <-- Close ports ACK 6. <-- HFCI, close pinhole A Security Considerations The goal of this memo is to lay out procedures for securing the call setup and call traffic components of the H.323 protocol. The meta- issue of securing the management traffic implementing this is outside the scope of this document. However, it is useful to sketch some minimum requirements. Minimum Control Channel Security Requirements If the control channel resides entirely inside a Gatekeeper device, there are no particular security requirements. The HFCI may be a purely functional interface to a built-in packet filtering device, for example. At this point, security must be focused on protecting the Gatekeeper device (which, of course, must always be well protected). If the packet filtering component resides on a private network with the gatekeeper function, some security is required. At a minimum, strong authentication, and the usual suite of security properties (replay prevention, session-hijack-proofing and so on) are required. The fact that the underlying transactions open access through the firewall require some degree of protection, even in the context of a Mercer, Molitor, Hurry, Ngo [Page 15] Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998 private network. If the packet filtering device is connected to the Gatekeeper function through an open network, strong authentication as indicated above, together with strong encryption, is indicated. References [1] Chouinard, D., Richardson, J., Khare, M., "H.323 and Firewalls", Intel Corporation Whitepaper, November 1997. [2] ITU-T Recommendation H.323, "Visual Telephone Systems and Equipment for Local Area Networks Which Provide A Non-Guaranteed Quality of Service" [3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson., "RTP: A Transport Protocol for Real-Time Applications", RFC1889, January 1996. Authors' Addresses Andrew Molitor Storage Technology Corp. MS 602 7625 Boone Ave. N Brooklyn Park, MN, 55428 Steve Mercer Storage Technology Corp. MS 030 7600 Boone Ave. N Brooklyn Park, MN, 55428 Maurice Hurry Siemens Information and Communication Networks Inc. 900 Broken Sound Pkwy. Boca Raton, FL 33487 Teodora Ngo Sun Microsystems, Inc. 901 San Antonio Road, MS: MTV21-237 Palo Alto, CA 94303 INTERNET DRAFT EXPIRES JUNE 1999 INTERNET DRAFT