Secure voice and data transmission via IP telephones

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. provisional application No. 60/346,648, filed on Jan. 8, 2002, the content of which is incorporated herein by reference.

FIELD OF THE INVENTION

[0002] This invention relates generally to internet telephony, and more particularly, to providing security for internet telephony communication.

BACKGROUND OF THE INVENTION

[0003] In general terms, Virtual Private Networks (VPNs) are secure communication channels that provide data protection using encryption and authentication techniques. VPNs can be implemented, for example, according to an IPSec protocol described in Internet Engineering Task Force Request for Comment 2401 entitled “Security Architecture for the Internet Protocol,” November 1998 (hereinafter referred to as RFC 2401), which is incorporated herein by reference. VPNs have become an important element in enterprise networking for securely interconnecting multiple corporate sites, remote offices, and remote workers. VPN technology helps ensure that only authorized users can access corporate network resources, and that data traffic flowing between two sites cannot be intercepted, decoded, or spoofed.

[0004] Current VPN technology allows secure voice communications over the internet via one of several methods, including security gateways, personal computers with IPSec stacks, or personal computers with dedicated secure phone software.

[0005]FIG. 1 is a schematic block diagram of a network including conventional IP telephones <b>10</b>, <b>12</b> and PCs <b>11</b>, <b>13</b> transmitting and receiving voice-over-IP (VoIP) packets via security gateways <b>14</b>, <b>16</b>. According to this architecture, the security gateways <b>14</b>, <b>16</b> provide secure voice communication over an untrusted wide area network <b>18</b> by encoding and decoding VoIP packets. The security gateways also provide other network services such as firewall control and network address translation (NAT). The use of security gateways for IPSec is sometimes referred to as a bump-in-the-wire (BITW), or network-to-network VPN, architecture.

[0006] A deficiency with the BITW architecture is that a separate security gateway device having its own hardware and software needs to be purchased in addition to the IP telephone if secure communication is desired. Security gateway devices may be expensive. In addition, having a separate security gateway device implies increase in power consumption and setup complexity.

[0007]FIG. 2 is a schematic block diagram of a network providing secure voice communication via a PC <b>20</b> without a security gateway device. Instead, the PC <b>20</b> includes an IP telephony software application <b>22</b> and an IPSec stack <b>24</b>. The IP telephony software application provides the basic VoIP communication over the Internet. The encoding and decoding of VoIP packets is done via the IPSec stack <b>24</b> resident within the PC. Thus, no costs need to be incurred in purchasing and maintaining a separate security gateway.

[0008] The use of the IPSec stack may be referred to as a bump-in-the-stack (BITS), or VPN client, implementation. Such an implementation, however, generally provides security only for the PC within which the IPSec stack resides. The IPSec stack may not be shared to provide secure voice communication to other IP telephony devices and/or appliances with which it may be associated.

[0009]FIG. 3 is a schematic block diagram of an alternative network configured to provide secure voice communication via a PC <b>30</b>. The secure voice communication is provided via dedicated secure phone software <b>32</b> (or hardware) installed in the PC <b>30</b>. The software encrypts VoIP packets using encryption techniques, such as based on the Pretty Good Privacy (PGP) technique. Such an architecture may be referred to as a bump-in-the-code (BITC) implementation.

[0010] A PC with dedicated secure phone software is susceptible to the same deficiencies as a PC with an IPSec stack. That is, security services cannot be provided to applications other than the PC within which this software resides. In addition, although the secure phone software may provide security for voice transmissions, it does not provide security for data transmission as is provided by security gateways or IPSec stacks. Instead, PCs with secure phone software transmit data in an unsecured manner using a standard IP stack <b>34</b> resident in the PC. Furthermore, the dedicated secure phone software is generally not IPSec compliant and therefore generally not interoperable with other VPN devices.

[0011] Accordingly, there is a need for a simplified, cost-efficient, all-in-one secure IP telephony device for a remote office worker or application, that provides both secure voice communication and data transmission, both for itself and for additional IP devices and applications associated with it.

SUMMARY OF THE INVENTION

[0012] The present invention is directed to an IP telephone appliance, referred to as a Virtual Private Phone (VPP), in a communications network. The IP telephone appliance includes a voice input, a voice output, a first processor, and a second processor. The voice input receives voice signals from a user, the first processor converts the voice signals into outgoing IP voice packets, and the second processor encodes and transmits the outgoing IP voice packets to a destination device, allowing for secure voice communication over the internet between the telephone appliance and the destination device. The second processor also receives incoming IP voice packets encoded by a source device, decodes the incoming IP voice packets, and if the decoded packets are destined for another device in the communications network, forwards the decoded packets to the other device. Otherwise, if the decoded packets are destined for the IP telephone appliance, the second processor invokes the first processor to convert the decoded packets into voice signals which are transmitted to the user via the voice output.

[0013] In one embodiment, the IP telephone appliance is configured to receive and decode IP data packets in addition to VoIP packets. The IP telephone appliance receives encoded data packets and decodes them. If the decoded data packets are destined for another device in the communications network, the IP telephone appliance forwards the decoded data packets to the other device. Otherwise, it invokes the first processor to convert the decoded data packets into telephony signals for voice transmission to the user.

[0014] In one embodiment, the IP telephone appliance provides secure communication for other devices on the communications network. The second processor is configured to receive from a source device IP voice or data packets destined for a destination device, and further configured to encode the IP voice or data packets and transmit the encoded packets to the destination device.

[0015] In one embodiment, the IP telephone appliance employs different encoding mechanisms based on the address of the destination device. Based on such destination address, the second processor may decide to encrypt only a payload portion or both a header and payload portion of a particular packet.

[0016] In one embodiment, the IP telephone appliance encodes and decodes packets according to an IP security protocol.

[0017] It should be appreciated, therefore, that the IP telephone appliance according to the invention provides secure voice communication and data transmission not only for itself, but also for other devices and applications associated with the appliance. According to the invention, conventional devices and applications that would otherwise not be entitled to secure communication may communicate in a secure manner via the IP telephone appliance. In addition, the IP telephone appliance itself may communicate securely without additional security gateways or other types of external security devices, allowing it to be more cost-effective and efficient than other prior art devices.

DESCRIPTION OF THE DRAWINGS

[0018] These and other features, aspects and advantages of the present invention will be more fully understood when considered with respect to the following detailed description, appended claims, and accompanying drawings where:

[0019]FIG. 1 is a schematic block diagram of a network including conventional IP telephones and PCs transmitting and receiving voice-over-IP (VoIP) packets via security gateways;

[0020]FIG. 2 is a schematic block diagram of a network providing secure voice communication via a PC without a security gateway;

[0021]FIG. 3 is a schematic block diagram of an alternative network providing secure voice communication via a PC;

[0022]FIG. 4 is a schematic block diagram of a communications network supporting secure IP telephony and other types of secure communication according to one embodiment of the invention;

[0023]FIG. 5 is a schematic block diagram of an IP telephone appliance according to one embodiment of the invention;

[0024]FIG. 6 is a flow diagram illustrating the processing of an outgoing call initiated by a user of the IP telephone appliance of FIG. 5 according to one embodiment of the invention;

[0025]FIG. 7A is a flow diagram of the processing of inbound packets received by the IP telephone appliance of FIG. 5 over a LAN interface according to one embodiment of the invention; and

[0026]FIG. 7B is a flow diagram of the processing of inbound packets received by the telephone appliance of FIG. 5 over a WAN interface according to one embodiment of the invention; and

[0027]FIG. 8 is a block diagram of an alternate communications network supporting secure IP telephony and other types of secure communication according to one embodiment of the invention.

DETAILED DESCRIPTION

[0028]FIG. 4 is a schematic block diagram of a communications network supporting secure IP telephony and other types of secure communication according to one embodiment of the invention. In the illustrated embodiment, the network includes an IP telephone appliance <b>40</b> coupled to a wide area network (WAN) <b>50</b> and a local area network (LAN) <b>48</b> over cables and/or other transmission media such as a wireless medium. The WAN <b>50</b> may be a private WAN or a public WAN such as a public internet.

[0029] The IP telephone appliance <b>40</b> communicates with IP telephones <b>42</b>, PCs <b>44</b>, and other network devices <b>46</b> on the LAN using a LAN communication medium, such as Ethernet or Token Ring. Ethernet LAN communication media are not limited to 10 megabit Ethernet, but include other variants, such as Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet and 802.11b wireless Ethernet. The IP telephone appliance <b>40</b> also communicates with a host <b>54</b> on a host site <b>52</b> over the WAN <b>50</b> using a communication protocol such as, for example, a TCP/IP protocol.

[0030] According to one embodiment, the IP telephone appliance <b>40</b> is an IP telephone that incorporates the look and feel of a traditional telephone with a keypad, function buttons, handset, and display. Unlike a traditional telephone, however, the IP telephone appliance is enhanced with the capability of providing secure IP telephony and data communication over the WAN for itself as well as for one or more of the network devices <b>42</b>, <b>44</b>, <b>46</b> on the LAN <b>48</b>. This architecture may be referred to as a bump-in-the-phone (BITP) architecture.

[0031] In alternative embodiments, the IP telephone appliance <b>40</b> may be implemented as a portable telephone, portable digital assistant (PDA), personal computer, or any other wired or wireless end user device that is conventional in the art.

[0032] A user may use the IP telephone appliance <b>40</b> to initiate and receive secure telephone calls with the host <b>54</b> on the host site <b>52</b> over the WAN <b>50</b> using any WAN interface that is conventional in the art. The host site <b>52</b> may include a device for providing the secure communication for the host <b>54</b>, such as, for example, a security gateway <b>55</b> coupled to the host.

[0033] In addition, the IP telephone appliance <b>40</b> receives voice and data packets from the devices <b>42</b>, <b>44</b>, <b>46</b> on the LAN <b>48</b>, secures the packets, and transmits the secured packets to either the host <b>54</b> or to another remote destination device. The IP telephone appliance <b>40</b> also receives secured inbound voice and data packets, decodes these packets, and either provides them to the user of the appliance or forwards them to one of the destination devices on the LAN.

[0034] In addition to the above, the IP telephone appliance <b>40</b> includes firewall and NAT capability to prevent unauthorized access. In this regard, the IP telephone appliance <b>40</b> secures voice for itself and on behalf of its clients, and also provides firewall protection for its telephone and on behalf of its LAN clients.

[0035]FIG. 5 is a more detailed schematic block diagram of the IP telephone appliance <b>40</b> according to one embodiment of the invention. In the illustrated embodiment, the appliance <b>40</b> includes a digital telephone set <b>60</b> coupled to a digital signal processor (DSP) <b>62</b> and central processor <b>64</b>. The central processor is further coupled to two network interfaces <b>70</b>, <b>72</b>. According to one embodiment, the first network interface <b>70</b> is used to communicate with the devices <b>42</b>, <b>44</b>, <b>46</b> on the LAN <b>48</b> and the second network interface <b>72</b> is used to communicate with the host <b>54</b> over the WAN <b>50</b>.

[0036] The central processor <b>64</b> includes a security stack <b>68</b> and a network protocol stack <b>66</b>. The security and network protocol stacks <b>68</b>, <b>66</b> may be implemented in software, hardware, firmware (e.g. via an application-specific integration circuit), or in any combination thereof. For example, the security and network protocol stacks may be separate processors implementing security and VoIP algorithms. Alternatively, the security and network protocol stacks may be software routines executed on a single processor.

[0037] According to one embodiment of the invention, the security stack <b>68</b> is an IPSec stack as set forth in RFC 2401. The network protocol stack may be a conventional transport protocol stack such as, for example, a H.323 stack, Session Initiation Protocol. (SIP) stack, media gateway control protocol (MGCP) stack, or the like. A person skilled in the art should recognize that other types of conventional transport protocols and security mechanisms and may be utilized as is known in the art without being limited to the disclosed protocols and security mechanisms.

[0038]FIG. 6 is a flow diagram illustrating the processing of an outgoing call initiated by a user of the IP telephone appliance. <b>40</b> according to one embodiment of the invention. The process starts as a user of the IP telephone appliance <b>40</b> utilizes the digital telephone set <b>60</b> to initiate the outgoing call according to conventional mechanisms. In step <b>80</b>, the central processor <b>64</b> receives a request to initiate the call from the digital set, and in step <b>81</b>, attempts to establish a security association (SA) with the callee device as set forth in RFC 2401.

[0039] Voice signals initiated by the user are provided to the digital telephone set <b>60</b> which digitizes and forwards the signals to the DSP <b>62</b> in step <b>82</b>. In step <b>83</b>, the DSP <b>62</b> segments, compresses, and packetizes the voice signals in a manner that is conventional in the art. If the SA negotiation of step <b>81</b> was unsuccessful, as determined in step <b>84</b>, the central processor <b>64</b> transmits the voice packets to the callee device via its WAN network interface <b>72</b> without encrypting the packets. Alternatively, with a different IP telephone management/configuration setup, the central processor <b>64</b> does not transmit the voice packet at all.

[0040] Otherwise, if the SA negotiation was successful, the central processor <b>64</b> invokes the security stack <b>68</b> for encoding the voice packets in step <b>86</b> in a manner well known in the art. According to one embodiment, the security stack encodes the voice packets in the same manner regardless of the destination of the packets. According to another embodiment, the security stack employs different encoding mechanisms depending on the source, destination, port, or other selectors as identified in RFC 2401. For example, a transport mode of encryption may be utilized for encoding voice packets transmitted to one device on the LAN <b>48</b>, causing only the payload data to be encoded, while a tunnel mode of encryption may be utilized for encoding voice packets transmitted to another device outside the LAN, causing both the header and payload data to be encoded.

[0041] Once the voice packets are encoded, the processor <b>64</b> invokes, in step <b>87</b>, the network protocol stack <b>66</b> for transmitting the encoded voice packets to their destinations on the LAN <b>48</b> or over the WAN <b>50</b> via the respective network interfaces <b>72</b>, <b>70</b>.

[0042]FIG. 7A is a flow diagram of the processing of inbound voice or data packets received by the IP telephone appliance <b>40</b> over its LAN interface according to one embodiment of the invention. In step <b>90</b>, the IP telephone appliance <b>40</b> receives an inbound packet communicated by one of the network devices <b>42</b>, <b>44</b>, <b>46</b> on the LAN <b>48</b>, via the first network interface <b>70</b>. The packet is forwarded to the central processor <b>64</b> which, in step <b>92</b>, examines the packet's header data to determine if the IP telephone appliance <b>92</b> is the ultimate destination. If the answer is NO, the central processor <b>64</b> determines if the security stack <b>68</b> is to be invoked for encoding the packet prior to forwarding to its destination. If the answer is NO, the central processor <b>64</b> determines if the security stack <b>68</b> is to be invoked for encoding the packet prior to forwarding to its destination.

[0043] Several factors may determine whether to encode the packet, and if so, the type of encoding to be performed. For example, if the packet received has already been encoded by the transmitting device itself, no encoding may be performed. Alternatively, the IP telephone appliance may decide to encode the packet even if already encoded, but using an encryption mode different than the one employed by the encoding device.

[0044] In another example, the IP telephone appliance <b>40</b> may not encode the packet if it is to be forwarded to another device on the LAN <b>48</b>, or if encoding is to be done, only the payload data may be encoded via the transport encryption mechanism. However, if the packet is to be forwarded to a device outside the LAN, both the header and payload data may be encoded via the tunnel encryption mechanism.

[0045] In yet another example, the encoding determination may be based on whether a successful SA was negotiated with the ultimate destination. The packet is encoded if a successful SA negotiation was made.

[0046] If the security stack <b>68</b> determines that the packet should be encoded, the packet is encoded in step <b>96</b>, and the encoded packet transmitted to its destination in step <b>98</b>. Otherwise, if no encoding is to be done, the packet is transmitted to the destination without encoding.

[0047] Referring again to step <b>92</b>, if the IP telephone appliance <b>40</b> is the ultimate destination, a determination is made as to whether the received packet is an encoded packet that needs to be decoded, as is determined in step <b>100</b>. In step <b>102</b>, the security stack <b>68</b> proceeds to decode the packet, and transmits the decoded packet to the DSP <b>62</b>.

[0048] If the packet is a VoIP packet, the DSP <b>62</b>, in step <b>104</b>, converts the packet to a voice signal. In step <b>106</b>, the converted signal or data is transmitted to the telephone set <b>60</b>.

[0049]FIG. 7B is a flow diagram of the processing of inbound voice or data packets received by the IP telephone appliance <b>40</b> over a WAN interface according to one embodiment of the invention. In step <b>110</b>, the IP telephone appliance <b>40</b> receives an inbound voice or data packet communicated by the host <b>54</b> over the WAN <b>50</b> via the second network interface <b>72</b>. The packet is forwarded to the central processor <b>64</b> which, in step <b>111</b>, determines according to conventional mechanisms whether the packet has been encoded. If the packet has been encoded, the security stack <b>68</b> proceeds to decode the packet in step <b>112</b>.

[0050] In step <b>113</b>, the central processor <b>64</b> examines the decoded packet's header data for determining if the IP telephone appliance <b>92</b> is the ultimate destination. If the answer is NO, the decoded packet is forwarded to its ultimate destination in step <b>114</b>.

[0051] Otherwise, if the packet's ultimate destination is the IP telephone device <b>40</b>, the packet is transmitted to the DSP <b>62</b>. If the packet is a VoIP packet, the DSP <b>62</b>, in step <b>115</b>, converts the packet to a voice signal. In step <b>116</b>, the converted signal is transmitted to the telephone set <b>60</b>.

[0052]FIG. 8 is a block diagram of an alternate communications network supporting secure IP telephony and other types of secure communication according to one embodiment of the invention. The network includes IP telephone appliances <b>120</b>, <b>122</b>, coupled to a LAN <b>140</b> over a first network interface <b>132</b>, <b>134</b>, and to a host <b>126</b>, <b>128</b> over a second network interface <b>136</b>, <b>138</b>. The LAN <b>140</b> is in turn coupled to a gateway <b>124</b> that provides access to a WAN <b>130</b> in a manner that is conventional in the art. The LAN <b>140</b> may also support other devices such as a PC <b>142</b>, a PC with an internal IPSec stack <b>144</b>, an IP PBX <b>146</b>, and a corporate server <b>148</b>.

[0053] The IP telephone appliances <b>120</b>, <b>122</b> are similar to the IP telephone appliance <b>40</b> of FIGS. 4 and 5. One difference, however, is the use of one of the network interfaces for connecting to the host <b>126</b>, <b>128</b>.

[0054] The hosts <b>126</b>, <b>128</b> may be wired or wireless end user devices such as PCs, conventional IP telephones, PDAs, or the like. Although FIG. 8 depicts only one host attached to each IP telephone appliance <b>120</b>, <b>122</b> a person skilled in the art should recognize that multiple hosts could also be attached.

[0055] The gateway <b>124</b> may be a conventional gateway providing access to the WAN <b>130</b>, and may provide other types of network services such as NAT, and firewall, and/or IPSec services. In the embodiment where the gateway <b>124</b> provides IPSec services, the gateway may implemented as a security gateway similar to the security gateway <b>14</b>, <b>16</b> of FIG. 1.

[0056] According to the embodiment illustrated in FIG. 8, a host <b>126</b> or <b>128</b> transmits a packet, such as an instant message packet, to its respective IP telephone appliance <b>120</b>, <b>122</b>. The IP telephone appliance attempts to establish an IPSec SA with a destination device. If the SA negotiation between a host and the destination is not successful, the packet is transmitted to the destination in an unprotected manner without encoding. In an alternative embodiment, the packet is not transmitted at all.

[0057] However, if the destination device has an internal IPSec stack, such as is the case with PC <b>144</b>, or is attached to one of the IP telephone appliances <b>120</b>, <b>122</b>, such as host <b>126</b> or <b>128</b>, the SA negotiation is successful. The packet is then encoded by the IP telephone appliance and transmitted to the destination in a secure manner.

[0058] According to one embodiment, the IP telephone appliance <b>120</b>, <b>122</b> determines the type of encoding based on the destination information. According to one embodiment, a table of IP addresses (not shown) indicates whether a connection to the indicated address is to be based on a transport mode of encryption or a tunnel mode of encryption. If the transport mode of encryption is indicated, only a payload portion of the packet is encrypted as provided by IPSec. If the tunnel mode of encryption is indicated, both an address and payload portion of the packet are encrypted as also provided by IPSec. The address of the security gateway may also be encrypted in the tunnel mode of encryption. VoIP packets may also be encoded in the above-described manner.

[0059] For example, the table of IP addresses may indicate the transport mode of encryption for addresses of destination devices that reside on the LAN <b>140</b>. However, if the destination resides on the LAN <b>140</b> behind the gateway <b>124</b>, or on the WAN <b>130</b>, an inherently untrustworthy network, the table of IP addresses may indicate the tunnel mode of encryption.

[0060] According to another embodiment, if the gateway <b>124</b> is a security gateway that implements the tunnel mode of encryption, the IP telephone appliance <b>120</b>, <b>122</b> encrypts packets according to the transport mode of encryption for all packets regardless of their destination. In this manner, packets to be transmitted over the LAN are encrypted only in the payload area by the IP telephone appliance <b>120</b>, <b>122</b> whereas packets to be transmitted to devices behind the gateway <b>124</b>, such as, for example, to devices on the WAN <b>130</b>, are encrypted in the payload area by the IP telephone appliance <b>120</b>, <b>122</b> and in both the payload and header areas by the security gateway <b>124</b>, providing double security for the packet.

[0061] Although this invention has been described in certain specific embodiments, those skilled in the art will have no difficulty devising variations which in no way depart from the scope and spirit of the present invention. It is therefore to be understood that this invention may be practiced otherwise than is specifically described. Thus, the present embodiments of the invention should be considered in all respects as illustrative and not restrictive, the scope of the invention to be indicated by the appended claims and their equivalents rather than the foregoing description.