Abstract:
A process for establishing a session between a first node and a second node of a communications network, the process including receiving a first request addressed from the first node and addressed to the second node; sending, in response to receipt of the first request, a response addressed to the first node to cause the first node to send a second request addressed to the second node, the response including first validation data; receiving the second request sent by the first node, the second request including second validation data; and determining, on the basis of the second validation data, whether to establish the session.

Description:
FIELD 
       [0001]    The present invention relates to a session process and system for use in establishing a session in a communications network, such as establishing a voice-over-IP (VoIP) call using session initiation protocol (SIP). 
       BACKGROUND 
       [0002]    As described in RFC 3261, the Session Initiation Protocol (SIP) is an application-layer control protocol for creating and managing sessions with one or more participants. The sessions can include network-based telephone (i.e., voice) calls, instant video, messaging, online games, virtual reality, and/or other forms of multimedia. Unlike HTTP, the SIP standard requires that SIP implementations support transport using the transport layer protocol known as a User Datagram Protocol (UDP), and this is typically used by default. However, because UDP is a connectionless protocol, the source address in a UDP packet can be easily falsified, a strategy known as “spoofing”. It is therefore not difficult for a mischievous or malicious user to send spoofed UDP packets in order to establish prank or malicious sessions. For example, in the case of voice-over-IP (VoIP), a single spoofed UDP packet can cause a VoIP phone to ring, and there is no practical ability to trace the origin of the spoofed call attempt, a situation that is clearly unacceptable for most VoIP users. Although SIP provides an authentication challenge/response scheme, this requires a caller to have previously registered a username/password pair with a SIP proxy server, and is therefore an undesirable solution to this problem because it prevents users from making calls until they have registered with the service. 
         [0003]    It is desired, therefore, to provide a session process and a session system that alleviate one or more difficulties of the prior art, or at least to provide a useful alternative. 
       SUMMARY 
       [0004]    In accordance with the present invention, there is provided a process for establishing a session between a first node and a second node of a communications network, the process including:
       receiving a first request to initiate a session between said first node and said second node, said first request being addressed from said first node and addressed to said second node and being encapsulated with a connectionless transport layer protocol;   sending, in response to receipt of said first request, a response addressed to said first node to cause said first node to send a second request to initiate a session between said first node and said second node, said second request being addressed to said second node, said response including first validation data;   receiving said second request sent by said first node, said second request including second validation data; and   determining, on the basis of said second validation data, whether to establish said session.       
 
         [0009]    The present invention also provides a process for establishing a SIP session between a first node and a second node of a communications network, the process including:
       receiving a first SIP INVITE request addressed from said first node and addressed to said second node;   sending, in response to receipt of said first SIP  INVITE  request, a SIP REDIRECT response addressed to said first node to cause said first node to send a second SIP  INVITE  request addressed to said second node, said SIP REDIRECT response including first validation data;   receiving said second SIP  INVITE  request sent by said first node, said second SIP  INVITE  request including second validation data; and   determining, on the basis of said second validation data, whether to establish said session.       
 
         [0014]    The present invention also provides a node of a communications network, the node being adapted to:
       receive a first request addressed from said first node and addressed to said second node, said first request being encapsulated with a connectionless transport layer protocol;   send a response addressed to said first node to cause said first node to send a second request addressed to said second node, said response including first validation data;   receive said second request sent by said first node, said second request including second validation data; and   determine, on the basis of said second validation data, whether to establish said session.       
 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0019]    Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: 
           [0020]      FIG. 1  is a schematic diagram of a preferred embodiment of a proxy server disposed between caller and callee devices interconnected by a communications network; 
           [0021]      FIG. 2  is a flow diagram of a session process executed by the proxy server; 
           [0022]      FIG. 3  is a listing of a first SIP  INVITE  request received by the proxy server; 
           [0023]      FIG. 4  is a listing of a SIP REDIRECT response generated by the proxy server; 
           [0024]      FIG. 5  is a listing of a second SP  INVITE  request received by the proxy server; 
           [0025]      FIG. 6  is a schematic diagram of an alternate network topology for use with the proxy server; and 
           [0026]      FIG. 7  is a flow diagram of an alternative embodiment of a session process executed by the proxy server. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0027]    As shown in  FIG. 1 , a proxy server  102  is topologically connected between first and second caller VoIP telephones  104 ,  106 , and a callee&#39;s VoIP telephone  108  so that all VoIP traffic to the callee&#39;s telephone  108  first passes through the proxy server  102 . All three telephones  104 ,  106 ,  108  are interconnected by a communications network  110 , such as the Internet. One or more of the VoIP telephones  104 ,  106 ,  108  may be SIP-based VoIP softphones such as KPhone, available at http://sourceforge.net/projects/kphone, executing on standard computer systems or devices such as an Intel Architecture computer also executing a standard operating system, such as Microsoft Windows or Linux. One or more of the VoIP phones  104 ,  106 ,  108  may alternatively be hardware VoIP telephones, such as the IP-based handsets available from Linksys, D-Link, Polycom, and other manufacturers. It will be apparent to those skilled in the art that a wide variety of combinations of software-based VoIP phones and/or hardware-based VoIP phones can be used. It will also be apparent that the simplified schematic diagram of  FIG. 1  omits many standard network components, such as routers, modems, and the like. 
         [0028]    As described above, the SIP standard mandates that the VoIP phones  102 ,  104 ,  108 , whether software or hardware based, support the transport of SIP data within UDP packets, and indeed UDP is typically the default transport layer protocol used by VoIP phones. Also as described above, UDP packets are easily spoofed, whereby a sender falsifies the sender&#39;s address stored in the packet to hide the packet&#39;s true origin and make the packets appear to have come from another sender, who may or may not exist. 
         [0029]    The proxy server  102  executes a session process, as shown in  FIG. 2 , that prevents spoofed UDP packets from being used to establish SIP sessions with the callee&#39;s telephone  108 . In the described embodiment, the proxy server  102  is a standard computer system, such as an Intel Architecture computer system executing a standard operating system such as Microsoft Windows or Linux, and the session process is implemented as a software module stored on non-volatile (e.g., hard disk) storage associated with the computer system. However, it will be apparent to those skilled in the art that the various components of the proxy server  102  could alternatively be distributed over a variety of locations (including within the callee&#39;s telephone  108 ), and that at least part of the session process could alternatively be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field-programmable gate arrays (FPGAs), for example. 
         [0030]    In order for a user of the VoIP phone  104  to make a VoIP call to the callee&#39;s telephone  108 , the caller initiates a call in the standard manner. In the case of a hardware-based telephone, this involves lifting the handset, and dialling the callee&#39;s VoIP telephone number in the usual way. In the case of a software-based phone or ‘softphone’, this involves using a pointing device such as a computer mouse to execute the VoIP software application (e.g., Kphone), and then enter or select the caller&#39;s number or other form of address using the controls of a graphical user interface generated by the VoIP software application, again in the standard manner. In response, the VoIP phone  104  generates a standard SIP  INVITE  message, in accordance with RFC 3261. 
         [0031]    For example,  FIG. 3  shows a typical SIP  INVITE  message, consisting of a set of SIP header fields specifying various call parameters. SIP is a text-based protocol, and the SIP request can be easily viewed and understood. The various header fields are described in detail in RFC 3261, but for current purposes only the most relevant fields are described herein. The first line  302  identifies the SIP message as an  INVITE  request, and includes a Universal Resource Indicator (URI) identifying the callee&#39;s username, their IP address, the SIP port number, and the SIP protocol version being used. The second line  304  is a via header field that indicates the path taken by the request thus far, and indicates the path that should be followed in routing responses. A  BRANCH  parameter defines a transaction identifier used to detect loops. A To header field  306  identifies the recipient by their username, IP address, and port. A From field  308  identifies the sender of the message; the tag parameter is a random string used for identification purposes. Finally, a User-Agent field  310  identifies the caller&#39;s phone  104  itself. For example the string “Kphone/4.2” identifies the caller&#39;s phone  104  as a softphone, namely version 4.2 of the Kphone software application. 
         [0032]    As shown in  FIG. 2 , the session process begins at step  202  when the proxy server  102  receives a packet from the communications network  110 . At step  204 , the packet is inspected to determine (i) whether the packet is a UDP packet, and (ii) whether it contains a SIP  INVITE  message. If either (i) or (ii) or both of these conditions is/are not satisfied, then the UDP packet is simply forwarded at step  206 . Otherwise, the packet is a UDP packet encapsulating a SIP  INVITE  request, and at step  208  a test is performed to determine whether the  INVITE  message includes a signature, as described below. Because the SIP  INVITE  request is a standard SIP  INVITE  message generated by the caller&#39;s phone  102  in accordance with RFC 3261, the message will not include a signature, as described below, and consequently the process proceeds to steps  209  and  210 , where the proxy server  102  generates a signature, as described below, and then replies to the SIP INVITE message with a SIP temporary redirect message including the generated signature. 
         [0033]    As described in RFC 3261, SIP provides a Temporary Redirect feature allowing a session to be redirected to another URI. The session process uses this feature of SIP to reply to the initial SIP  REQUEST  with a redirect message. However, rather than redirect the caller&#39;s telephone  104  to a different address, the redirection address provided in the redirection message remains the same address of the callee, but with an additional parameter appended. For example,  FIG. 4  shows the redirect message generated by the proxy server  102 , and sent to the caller&#39;s telephone  104 . In SIP, the new address to which the caller is to be redirected is provided in a Contact header field, such as the contact field  402  shown in  FIG. 4 . Comparison with the To field  306  of the SIP  INVITE  message shown in  FIG. 3  indicates that the callee&#39;s address is identical but for the appended parameter “verify=6A64B24412CC134FD”. This additional parameter provides validation data that constitutes a signature of the proxy server  102 , and hence for convenience the validation data is also referred to herein as a “signature”. At minimum, the signature could be any arbitrary (and possibly even static) text generated or otherwise provided by the proxy server  102 . However, substantially stronger protection against spoofing will be provided if the signature is generated dynamically. Ideally, this signature (i) is unguessable (to avoid an attacker guessing the signature), (ii) depends on variable portions of the initial  INVITE  message (to avoid an attacker using the signature taken from a valid call and using it for unrelated spoofed call attempts), and (iii) is in a form that prevents it from being used in a replay attack (to avoid an attacker using fields taken from a packet of a valid call). 
         [0034]    To provide the above properties, the session process generates the validation data by applying a hash function to an input string formed by concatenating a timestamp and one or more non-constant header fields of the  INVITE  request, and the resulting hash value is used as the validation data. In the described embodiment, the To, From, and user-Agent header fields are used to generate the hash value; however, it will be apparent that one or more other non-constant header fields could alternatively or additionally be used, and that it is not necessary that the entirety of each header field be used, one or more non-constant portions of respective header fields being sufficient. 
         [0035]    In the described embodiment, the hash function is the standard cryptographic hash function SHA-1. However, it will be apparent to those skilled in the art that any one or more of a variety of alternative hash functions could alternatively be used, including lightweight hash functions, or cryptographic hash functions such as SHA-2, MD5, or WHIRLPOOL, for example. 
         [0036]    The validation data/signature is then included in the redirection response as the value of a verify parameter statement appended to the URI of the callee&#39;s telephone  108  and separated from it a semicolon character. (It should be understood that the parameter name “verify” is arbitrary and that a different parameter name could be used instead.) The redirection response is then sent to the caller&#39;s telephone  104 , the UDP packet is dropped at step  212 , and the session process terminates at step  214 . 
         [0037]    In accordance with RFC 3261, in response to receiving the SIP redirect message, the caller&#39;s phone  104  generates a second SIP  INVITE  request as shown in  FIG. 5 , that includes the value of the contact header field  402  in the redirect message as the value of the To header field  502 . 
         [0038]    Returning to  FIG. 2 , this second SIP  INVITE  request is addressed to the callee&#39;s phone  108  as before, and is received from the communications network  110  by the proxy server  102  at step  202 . As described above, the session process determines that the packet is a UDP packet containing a SIP  INVITE  request at step  204 , and at step  208 , the process examines the To header field  502  and determines that the callee&#39;s address has appended to it the signature parameter and value “verify=6A64B24412CC134FD”. At step  216 , the session process determines whether the signature is valid. This is determined by repeating the steps described above for generating the signature from the initial SIP  INVITE  request, but using the second SIP  INVITE  request as input (and using the same timestamp that was previously used to generate the signature, as described below), and then comparing the resulting second signature with the initial or first signature. If the two signatures are identical, then the signature and hence also the second SIP  INVITE  request are deemed to be valid at step  216 , and the UDP packet is then forwarded to the caller&#39;s telephone  108  at step  218 , and the process ends at step  214 . Otherwise, if the signatures are not identical, then the second SIP  INVITE  request is deemed invalid, the UDP packet is dropped at step  212 , and the process terminates at step  214 . 
         [0039]    Unfortunately, the wording of RFC 3261 is unclear as to whether it encompasses the process described above, whereby a parameter name and value are appended to the To field address of a redirected SIP INVITE request. Although the described process is believed to conform to RFC 3261, it remains possible that some SIP clients may be based on an alternative interpretation of RFC 3261 that requires the redirection address (URI) to be different from the original destination URI of the callee&#39;s telephone  108  and that the appending of a parameter name and value to the address is not sufficient for this purpose. If this was the case, then an alternative session process can be used wherein a “header field” is also appended to the To field URI of the redirection, taking the general form:
       sip:user@domain.com;verify=xxx?X-Verify=yyy
 
where the “X-Verify=yyy” component specifies a header field named X-Verify which has a value of yyy. The header field will be included in the corresponding INVITE request generated by the caller&#39;s telephone  104 , but the inclusion of the appended parameter name-value pair “verify=xxx” nevertheless allow the process described above to be used to verify the reissued INVITE request. This alternative session process will work correctly with all SIP clients that conform to RFC 3261.
       
 
         [0041]    The session process and proxy server  102  thus ensure that spoofed SIP requests sent to the callee&#39;s phone  108  are only able to establish sessions if the caller is verified. Thus if a second VoIP phone  106  sends a spoofed UDP containing a spoofed SIP  INVITE  request with a falsified From header field falsely indicating the first phone  104 , and addresses this request to the callee&#39;s phone  108 , the session process will drop the UDP packet containing this request, and send a redirect message back to the first telephone  104 , and not to the attacker&#39;s phone  106 . Because the first telephone  104  did not originate the request, the first telephone  104  will ignore the redirect and drop the redirect packet. Additionally, the attacker cannot practically fake the second SIP  INVITE  request, because, in order to successfully establish a SIP session, the second request would need to include the proxy server&#39;s signature included in the redirect request, which is generated from at least portions of one or more respective selected non-constant header fields in the initial request and a timestamp (and/or secret, as described below). Thus attempts to spoof SIP  INVITE  calls should fail. 
         [0042]    It will be apparent to those skilled in the art that the signature generated by the proxy server  102  and included in the redirection can be included in alternative locations of the redirection message and can be generated in a wide variety of alternative ways. However, a number of recommendations can be stated. 
         [0043]    For example, the signature can be made unguessable for practical purposes by ensuring that the signature is relatively long (e.g., at least 64 to 128 bits), and/or by including a secret seed known only to the proxy server  102 , which should make the signature unguessable even if all other signature inputs are known or can be guessed. 
         [0044]    Also, as described above, the signature is preferably generated from non-constant header fields, or at least parts of those fields. However, the headers used should be those that are guaranteed to be the same after a temporary redirect has been made so that the same signature value can be regenerated for validation purposes. Accordingly, one or more of the To, From, User-Agent, and the last via header fields should be used as inputs to the signature generation (preferably cryptographic hash) function. The inclusion of a timestamp in the input to the hash function protects the signature against replay attacks. However, it would alternatively be possible to use another form of monotonically increasing counter (or a value derived from the counter) as an input to the hash function, rather than a timer. However, such a counter will only be truly monotonic if the counter survives system restarts or resets. Additionally, the use of such a counter complicates the subsequent validation of the hash value, because the counter may by then have changed its value. 
         [0045]    Two methods of basing the signature on a counter value are described below. In the first, a counter value is included as cleartext as part of the signature. However, it is preferred that a rapidly changing random secret is included in the input to the function used to generate the signature, in order to make the signature less susceptible to being cracked. When the proxy server  102  receives the second SIP INVITE request from the caller&#39;s telephone  104 , the cleartext timestamp determines whether the packet is in the valid time window by comparing the difference between the current time and the timestamp with a configurable window size value. To validate packets in the valid time window, a (hash or B-tree) lookup table is used to find the appropriate secret associated with the counter value in order to re-generate the signature. 
         [0046]    The second method uses values of the counter to associate a lifetime with each new SIP INVITE request so that a corresponding validation can only be made within that lifetime, although the lifetime is extended to its maximum value on each successful validation.  FIG. 7  is a flow diagram of an alternative embodiment of a session process, being a modification of the session process shown in  FIG. 2 . Each time a new SIP INVITE request is received without a signature, the counter is incremented at step  702  and the resulting counter value is associated with that request, preferably by using as one of the inputs to generate the signature, at step  705 . Independent lifetimes are associated with each counter value, and at step  704  the lifetime is set to its (configurable administration) maximum value. Received  INVITE  requests with a signature can only be validated during the lifetime of the corresponding counter value. The used counter value&#39;s lifetime is reset to its maximum value each time a response is successfully validated (step  716 ). If the lifetime of a counter value expires before receipt of an  INVITE  request using that counter value, then the counter value is discarded and any responses using that counter value at a later time will not be validated. Where there are several active counter values, the process attempts to validate every received response by generating a hash value for each counter value that has not yet expired until the signature is validated, as shown in steps  706  to  714  of  FIG. 8 . Alternatively, if the counter value associated with an  INVITE  request is included as cleartext with that request, then the hash value need only be generated once, albeit at the expense of reduced security. 
         [0047]    The Temporary Redirect response can include an “expires” header field that specifies the validity period of the redirection. The caller&#39;s telephone  104  should use the redirected SIP address during the validity period because any additional requests sent to the callee&#39;s telephone  108  during this period will result in an identical Temporary Redirect. An “expires” value of zero indicates that the redirect is only valid for this particular request sent to the callee&#39;s telephone  108 . The number of active counter values can be minimized by setting the “expires” header value to the counter value&#39;s life-time, and by re-using an existing active counter value (instead of always incrementing the counter). Counters can be prevented from surviving excessively by assigning an overall life-time of a counter value and having a cut-off threshold after which that counter value is used only in validating  INVITE  requests, not in generating new signatures for further redirections. 
         [0048]    It will be apparent based on the above that the session process requires all SIP  INVITE  requests addressed to the callee&#39;s phone  108  to first be received by the proxy server  102 . This is most simply achieved by providing the proxy server  102  in an “in-line” arrangement or topology whereby all network traffic to the callee&#39;s phone  108  passes through the proxy server  102 . Alternatively, as shown in  FIG. 6 , the proxy server  102  need not receive all traffic passing to the caller&#39;s telephone  108  if a router or switch  602  selectively routes SIP or SIP  INVITE  requests, or even only UDP SIP  INVITE  requests, to the proxy server  102 . 
         [0049]    Although the session process has been described as being implemented in the proxy server  102 , it will be apparent that the session process could alternatively be implemented within the callee&#39;s telephone  108  (or other SIP device, as the case may be) to provide an enhanced SIP device, such as the enhanced VoIP phone  112 , represented schematically in  FIG. 1 , which is immune to UDP spoof attacks. 
         [0050]    Additionally, although the session process has been described in terms of SIP-based VoIP telephones, it will be apparent that the process is applicable to other OSI layer 5 to 7 protocols encapsulated using connectionless transport protocols, to other forms of communications device, and is not restricted to voice traffic. 
         [0051]    Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as hereinbefore described with reference to the accompanying drawings.