Patent Publication Number: US-7594259-B1

Title: Method and system for enabling firewall traversal

Description:
FIELD OF THE APPLICATION 
     This invention relates to firewall traversal and, in particular, to enabling firewall traversal for IP media communications. 
     BACKGROUND OF THE INVENTION 
     Carriers, equipment manufacturers, and enterprises are embracing IP telephony and other IP-based media communications with increasing regularity. These IP-based communication networks present a difficulty in that their openness makes them vulnerable to security issues. As a result, most IP networks contain firewalls at various points. 
     Firewalls present a particular difficulty for peer-to-peer or multimedia communications, which are typically transmitted using UDP (User Datagram Protocol) packets. This poses difficulties for applications such as IP telephony, sometimes called voice-over-IP (VoIP), and for other peer-to-peer or multimedia applications, such as IP fax, video phones, interactive gaming, and other UDP-based media. Typically firewalls only permit incoming communications that meet certain firewall rules. Accordingly, UDP packets may be blocked by a firewall. 
     As more carriers begin to offer interactive gaming, VoIP and other IP telephony services, and as more enterprises offer VoIP to remote employees connecting to an enterprise network through a VPN (Virtual Private Network) connection, there needs to be a solution to the problem of traversing a firewall without eliminating the firewall altogether. 
     One solution that has been attempted in the past is the establishment of application level gateways (ALGs) within the firewall itself. The limitations of this solution include the fact that ALGs are protocol-specific, which presents a problem since the ALG must inspect, parse and understand the various protocols that may be used. Any changes to the protocol may render the ALG ineffective. The ALG solution also imposes a significant cost on firewall resources in terms of memory and processing. It would be preferable to have a protocol independent solution for firewall traversal 
     SUMMARY OF THE APPLICATION 
     The present application describes a method and system for enabling firewall traversal. The firewall relies upon an apparent or inferred trust between a device controller known to the firewall and a client device communicating through the firewall to determine whether the client device is authorized, i.e. validated. If it appears that the known device controller trusts the client device based upon the frequency and duration of its communications with the client device, then the firewall permits the client device to transmit data traffic. Alternatively, if the known device controller exhibits trust in the client device through the establishment of a session or a security association, i.e. by engaging in communications that imply a certain level of trust, then the firewall permits the client device to transmit data traffic. 
     In one aspect, the present application provides a method for enabling packet communications through a firewall between a client device and a remote location, the firewall being located between the client device and a known device controller. The method includes steps of monitoring communications from the device controller to the client device to determine whether the client device is authorized, and allowing the transmission of data packets from the client device to the remote location if the client device is authorized. 
     In another aspect, the present application provides a system for enabling packet communications through a firewall, the firewall being located between a client device and a device controller. The system includes a monitoring component for monitoring packets received from the device controller and addressed to the client device and for determining if the client device is authorized based upon the received packets, and a firewall update component responsive to the monitoring component for setting a firewall rule, the firewall rule permitting passage of data packets from the client device. 
     Other aspects and features of the present application will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Reference will now be made, by way of example, to the accompanying drawings which show an embodiment of the present application, and in which: 
         FIG. 1  diagrammatically shows an embodiment of a communication network; 
         FIG. 2  shows the communication network of  FIG. 1  including a network address translator (NAT); 
         FIG. 3 , diagrammatically shows another embodiment of the communication network; and 
         FIG. 4  shows, in flowchart form, a method of enabling firewall traversal for UDP packets from a client device. 
     
    
    
     Similar reference numerals are used in the figures to denote similar components. 
     DESCRIPTION OF SPECIFIC EMBODIMENTS 
     It will be understood by those of ordinary skill in the art that although the following description provides example embodiments that may have a particular context, such as a VoIP implementation, the present application is not limited to VoIP applications and is not protocol-specific. 
     Reference is first made to  FIG. 1 , which diagrammatically shows a communication network  10 . The communication network includes an IP network  14 . In some embodiments, the IP network  14  comprises a private network; in other embodiments, the IP network  14  is a public network. The IP network  14  may be an enterprise-specific local area network (LAN) or wide area network (WAN). In other embodiments, the IP network  14  may be a carrier network. 
     The IP network  14  may include one or more gateways  22  connecting the IP network  14  to other networks, such as a remote IP network  26  or the public switched telephone network (PSTN)  24 . In one embodiment, the IP network  14  comprises an enterprise-specific network and the remote IP network  26  comprises a related enterprise-specific network, such as for a branch office. In one embodiment, one of the IP networks  14  or  26  comprises the Internet. 
     The communication network  10  includes a number of IP-based client devices  12  (only one is shown). The IP network  4  includes a number of device controllers  20  (shown as  20   a ,  20   b ,  20   c , . . . ,  20   n ). The communication network  10  also includes a firewall  18  between the client device  12  and the device controller  20 . The firewall  18  has a protected side and an unprotected side. The client device  12  is on the unprotected side and the device controller  20  is on the protected side. The firewall  18  is for protecting the device controller  20  and other elements or devices within the IP network  14  from malicious or harmful communications originating from the unprotected side. 
     In one embodiment, the client device  12  comprises a VoIP phone and the device controller  20  comprises a gateway or, specifically, a media gateway controller or similar controller. In another embodiment, described below in connection with  FIG. 3 , the device controller  20  comprises a port discovery server, such as a STUN (Simple Traversal of UDP through NATs) server, as described in IETF RFC 3489. It will be understood by those of ordinary skill in the art that the following description is not necessarily limited to VoIP, but may be applied other IP-based media communications, including interactive gaming, video conferencing, and other applications. In other embodiments, the client device  20  may comprise a video phone, a gaming console, an IP fax, or other devices. 
     In one embodiment, the device controller  20  performs signaling and control communications with the client device  12  to set-up and tear-down media connections between the client device  12  and remote devices  34  (shown as  34   a  and  34   b ) elsewhere in the communication network  10 . The client device  12  and its device controller  20  communicate based upon a predefined device control protocol. The protocol may be a standard open protocol or a proprietary protocol. For example, in some embodiments the protocol may include proprietary device control, MGCP (media gateway control protocol), H.248, or SIP (Session Initiation Protocol). In a case where the device controller comprises a port discovery server, the protocol may comprise a port discovery or echo protocol, such as the STUN protocol. 
     Each device controller  20  has a static IP address and a specified UDP port for signaling/control packet reception in accordance with the predefined protocol. The firewall  18  maintains a catalog or list of known device controllers  20  and their associated IP addresses and control ports. Accordingly, packets originating from or destined to the device controller  20  may be recognized by the firewall  18  based upon the source or destination IP address:port. 
     The client device  12  has a dynamic IP address. The client device  12  includes an IP protocol component and a media component. The two components share a single IP address. The client device  12  may be unknown to the firewall  18 . 
     The client device  12  has a connection  16  to the IP network  14 , although communications from the client device  12  to the IP network  14  must traverse the firewall  18 . In other words, the client device  12  is on the unprotected side of the firewall  18  and the IP network  14  is on the protected side of the firewall  18 . The connection  16  may comprise a VPN connection. The connection  16  enables the transmission of signaling/control packets over a signaling path  30  and data packets over a media path  32 . 
     Because the client device  12  is unknown to the firewall  18 , the firewall  18  may not permit the client device  12  to send UDP data packets to a destination address. The firewall  18  is configured to permit the passage of signaling/control packets to the device controller  20  on the basis that it knows the device controller  20 , or more specifically, that it knows the address and specified UDP port for signaling/control packet reception at each of the device controllers  20 . Based upon the destination address in the packets, it provides a pinhole in the firewall  18  for the known device controller  20  address:port combination. 
     The firewall  18  may decide to enable the traversal of UDP data packets from the client device  12 , like a VoIP phone, to a destination address. The firewall  18  bases its decision on whether or not to allow data packets from the client device  12  upon whether or not the known device controller  20  appears to trust the client device  12 . If the device controller  20  and the client device  12  are engaged in an active dialogue or if the device controller  20 , at least, is exhibiting trust for or a relationship with the client device  12 , then the firewall  18  relies upon the apparent relationship with device controller  20  and considers the client device  12  to be a “valid” or “authorized” device. A client device  12  that appears to be known to or trusted by one of the device controllers  20  is considered to have a “validated” or “authorized” status by the firewall  18 . 
     In one embodiment, to establish whether the client device  12  is known to or trusted by the device controller  20 , the firewall  18  monitors packets sent by the device controller&#39;s  20  UDP address:port for signaling and records the destination IP address and its binding to the device controller  20 . In other words, the firewall  18  watches outgoing control traffic from the known device controllers  20  and associates the destination address:port of the client device  12  with the address:port of the known device controller  20 . 
     Based upon the binding between the device controller  20  address and the destination address, the firewall  18  is aware that the device controller  20  has, at least, acknowledged the client device  12 . To determine whether or not the device controller  20  exhibits an ongoing relationship with the client device  12 , the firewall  18  may monitor communications associated with the binding between the device controller  20  and the client device  12  to ensure they meet predetermined minimum thresholds. These thresholds may relate to the frequency or duration of communications. In other embodiments, described below, the thresholds may relate to the type or nature of communications. 
     In one embodiment, the firewall  18  considers the client device  12  to be validated if the device controller  20  sends packets to the client device  12  with sufficient frequency to be considered ‘continuous’. The firewall  18  may also require that the minimum frequency of packet transmission be maintained for a minimum period of time. In one embodiment, the firewall  18  considers the client device  12  to be validated if the device controller  20  sends packets to it for at least X minutes with an interval of no more than Y seconds between packets. In one embodiment, X has a value of about a few minutes and Y has a value of about a few seconds. In at least one embodiment, X has a value of about five minutes and Y has a value approximately equal to the firewall&#39;s  18  predefined timeout value. For a device controller  20  to keep a client device  12  validated, it may be configured to send keep-alive packets to the client device  12  with a frequency sufficient to meet the validation requirements. 
     The firewall  18  may be configured to ignore certain types of communications in assessing whether or not a client device  12  is validated. For example, a simple “ping” or Internet Control Message Protocol (ICMP) message may be deemed insufficient to count as communication from the device controller  20  to the client device  12 . Otherwise, a malicious client device  12  could become validated by “pinging” the device controller  20  on a continuous basis. 
     Provided that the binding between the client device  12  and the device controller  20  is maintained as validated, the firewall  18  considers the client device  12  to be an authorized source of packets and allows UDP packets having a source address corresponding to the address of the client device  12  to traverse the firewall  18 . Accordingly, any data packets for a media session with a destination elsewhere in the communication network  10  will be allowed to traverse the firewall  18  provided they originate from the address associated with the validated binding. It will be appreciated that such an embodiment relies upon a condition that the UDP data over the media paths and the signaling communications with the device controller  20  use the same address at the client device  12 . If the media packets from the client device  12  originated at a different address than the address used for communications with the device controller  20 , the firewall  18  would be unable to associate the media packets with the validated client device  12  and would not let them through. In other embodiments, the firewall  18  may extend the “validated” status to a range or subnet of source addresses or to a list of addresses so as to permit UDP data from a different address that the address of from which the signaling communications came. Such an embodiment may be particularly relevant in the context of IPv6 wherein IP addresses may have variable lengths. 
     In some embodiments, the firewall  18  may place restrictions upon the destination associated with any data packet from the client device  12 . For example, the destination may be restricted to allowed configured gateway IP addresses/ports and any IP phone ports. 
     The potential for abuse may also be constrained by limiting the number of media sessions the client device  12  establishes simultaneously. For example, the firewall  18  may limit the client device  12  to one RTP (real-time transport protocol) and RTCP (real-time transport control protocol) flow simultaneously per signaling link. In the case of multimedia client devices  12 , the maximum number may be increased to allow for video channels, data channels, etc. Reference is made to  FIG. 2 , which shows the communication network  10  of  FIG. 1  with a network address translator (NAT)  40 . 
     If a device controller  20  ceases to communicate with a client device  12  with a sufficient frequency, then the firewall  18  will consider the client device  12  to have lost its authorized status and will begin blocking UDP packets from the client device  12 . 
     It will be appreciated that the firewall  18  need not understand the protocol used by the client device  12  and the device controller  20 . Accordingly, the communications between the client device  12  and the device controller  20  may be based upon proprietary protocols, of which the firewall  18  is completely unaware. It will also be understood that the communications between the client device  12  and the device controller  20  may be encrypted without impacting the ability of the firewall  18  to “validate” a client device  12 . 
     Reference is now made to  FIG. 3 , which shows the communications network  10  according to another embodiment. The device controller  20  shown in  FIG. 3  comprises a port discovery server. The port discovery server is an echo server for receiving binding inquiry messages over UDP from the client device  12  and responding with IP address information. The port discovery server may, for example, comprise a STUN server as described by IETF RFC 3489. Other port discovery servers conforming to other standard or proprietary protocols may also be used. 
     The port discovery server differs from, for example, a media gateway controller, in that it receives and sends port discovery messages with the client device  12  using a media path  42  instead of separate signaling or control paths. Accordingly, in such an embodiment there is no restriction that the client device  12  have the same address for its media and signaling. 
     In the embodiment shown in  FIG. 3 , the firewall  18  monitors packets from the port discovery server to the client device  12  and creates a binding based upon the source and destination addresses. It then applies any frequency, type, and/or duration conditions upon the communication between the client device  12  and the port discovery server to assess whether the client device  12  is authorized. Once authorized, the client device  12  is permitted to transmit UDP packets to other destinations from its IP address. 
     Reference is now made to  FIG. 4 , which shows, in flowchart form, a method  200  of enabling firewall traversal for UDP packets from a client device. 
     The method  200  begins in step  202 , wherein the firewall monitors packets. In particular, in step  204 , the firewall assesses whether it has received any packets that are directed to the known device controller address. The firewall maintains a list or other data structure containing known device controller addresses. It may compare the destination addresses of any incoming packets with the addresses in its list to determine if any packets are directed to a known device controller. 
     Additionally or alternatively, in step  206 , the firewall may monitor whether any outgoing packets are from destination addresses in the list of known device controller addresses. In other words, in step  206  the firewall assesses whether the device controller is sending a packet to a client device. 
     If a packet is either directed to a device controller or originating from a device controller, then in step  208  the firewall stores an association (binding) between the device controller address and the address from which the packet came or to which it is directed. If it is an outgoing packet from the device controller, then the firewall stores the destination address for the packet. If it is an incoming packet to the device controller, then the firewall stores the source address for the packet. If the association or binding between the two addresses is already known to the firewall—i.e. already contained in its data structure of bindings—then it need not store it again. 
     Having identified a potential relationship between the device controller and the address with which it is communicating, the firewall then monitors packets between the two addresses in step  210 . In particular, the firewall monitors outgoing packets from the device controller address to the client device address. In step  212 , the firewall assesses whether or not the interval between outgoing packets to the client device exceeds a threshold value Y. This may be implemented as a timeout counter for triggering a timeout if a period of time Y passes without the firewall receiving an outgoing packet from the device controller directed to the client device address. 
     If the interval between packets exceeds the threshold value Y, then in step  214  the firewall removes the association or binding and cancels any firewall rules that may have been established in step  218 , described below. 
     If the interval between packets does not exceed the maximum threshold value Y, then in step  216  the firewall determines whether the device controller has been communicating with the client device address for more than a minimum period of time X. If not, then it continues at step  210  to monitor outgoing packets. If the minimum period of time X has been met with “continuous” communication from the device controller to the client device address, then the firewall may deem the client device to be “validated” or “authorized” in step  218 . In step  218 , based upon the validation of the client device, the firewall dynamically establishes a firewall rule permitting the traversal of UDP packets from the client device address that was stored in step  208 . The firewall rule may incorporate certain restrictions, such as restrictions on permitted destination addresses. Other restrictions may also be incorporated, such as restrictions upon the number of concurrent media session per link. 
     Once the firewall rule is established in step  218 , then the firewall continues to monitor outgoing packets from the device controller to ensure that it continues to communicate with the client device with sufficient frequency. 
     It will be appreciated that the present method and system for enabling firewall traversal bases the firewall decision upon the apparent trust between a device controller and a client device. In one embodiment, this trust is inferred from the fact that the device controller is communicating with the client device on a sufficiently frequent basis. It will be understood that to be effective this communication by the device controller must be voluntary and cannot simply constitute acknowledgement of requests. Otherwise illegitimate devices could send periodic requests or “ping” messages to a device controller so as to trigger near-continuous acknowledgement responses and thereby trick the firewall into deeming the device to be authorized. It will be appreciated that many existing device controllers having a minimal degree of sophistication will already be designed to ignore these types of tactics so as to avoid denial-of-service attacks. 
     In another embodiment, the firewall  18  bases its “authorization” of the client device  12  on the nature or type of communication established between the device controller  20  and the client device  12 . Certain types of communication will imply a certain level of trust between the device controller  20  and the client device  12 . Accordingly, if the firewall  18  recognizes this type of communication, then it may rely upon that implicit trust to permit the client device  12  to send data packets to other destinations. 
     In one embodiment, the client device  12  and the device controller  20  establish secure communications with each other. For example, they may use IPSec (Secure Internet Protocol), SSL (secure sockets layer), or TLS (Transport Layer Security). IPSec is a protocol that implies a security association. SSL and TLS are session-based protocols that run over TCP (transport control protocol). Accordingly, the firewall  18  may rely upon the fact that the device controller  20  has entered into a security association or a secure session with the client device  12  in choosing to “authorize” the client device. 
     In another embodiment, the client device  12  and the device controller  20  establish a session, whether secure or unsecured. For example, the device controller  20  and the client device  12  may establish a session using TCP signaling. The establishment of a session implies a certain level of trust or acknowledgement that the firewall  18  may be configured to rely upon in deeming the client device  12  to be “authorized”. 
     The present application may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Certain adaptations and modifications of the above described embodiments will be obvious to those skilled in the art. Therefore, the above discussed embodiments are considered to be illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.