SESSION PROCESS AND SYSTEM

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

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

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.

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

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.

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.

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

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

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;

FIG. 2 is a flow diagram of a session process executed by the proxy server;

FIG. 3 is a listing of a first SIP INVITE request received by the proxy server;

FIG. 4 is a listing of a SIP REDIRECT response generated by the proxy server;

FIG. 5 is a listing of a second SP INVITE request received by the proxy server;

FIG. 6 is a schematic diagram of an alternate network topology for use with the proxy server; and

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

As shown in FIG. 1, a proxy server 102 is topologically connected between first and second caller VoIP telephones 104, 106, and a callee's VoIP telephone 108 so that all VoIP traffic to the callee'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.

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's address stored in the packet to hide the packet's true origin and make the packets appear to have come from another sender, who may or may not exist.

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'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'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.

In order for a user of the VoIP phone 104 to make a VoIP call to the callee'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'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'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.

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'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's phone 104 itself. For example the string “Kphone/4.2” identifies the caller's phone 104 as a softphone, namely version 4.2 of the Kphone software application.

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'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.

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'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'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'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).

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.

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.

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'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's telephone 104, the UDP packet is dropped at step 212, and the session process terminates at step 214.

In accordance with RFC 3261, in response to receiving the SIP redirect message, the caller'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.

Returning to FIG. 2, this second SIP INVITE request is addressed to the callee'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'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'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.

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'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'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.

The session process and proxy server 102 thus ensure that spoofed SIP requests sent to the callee'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'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'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'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.

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.

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.

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.

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'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.

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'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.

The Temporary Redirect response can include an “expires” header field that specifies the validity period of the redirection. The caller's telephone 104 should use the redirected SIP address during the validity period because any additional requests sent to the callee'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's telephone 108. The number of active counter values can be minimized by setting the “expires” header value to the counter value'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.

It will be apparent based on the above that the session process requires all SIP INVITE requests addressed to the callee'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'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'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.

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'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.

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.

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.

Claims

1. 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.

2. 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.

3. The process of claim 1, wherein said determining includes determining whether to establish said session on the basis of a comparison of said first validation data and said second validation data.

4. The process of claim 1, including processing said first request to generate said first validation data.

5. The process of claim 4, wherein said first validation data is generated from at least one of an address of said first node and an address of said second node.

6. The process of claim 4, wherein said validation data is based on a time of receipt of said first request.

7. The process of claim 4, wherein said processing includes applying a hash function to one or more header fields of said first request.

8. The process of claim 4, wherein said processing includes applying a hash function to a timestamp.

9. The process of any one of claim 1, wherein said first validation data includes a cryptographic signature.

10. The process of any one of claim 1, wherein said first request includes a TO header field including an address of said first node, and said response includes a header field including said address of said first node and said first validation data.

11. The process of any one of claim 1, wherein said step of determining includes generating third validation data from one or more header fields of said second request, and determining whether to establish said session on the basis of a comparison of said third validation data with validation data generated from one or more corresponding header fields of said first request.

12. The process of claim 11, wherein said step of determining includes establishing said session only if the first validation data generated for the first request is the same as the third validation data generated from the second request.

13. The process of claim 1, wherein said step of determining includes forwarding said second request to said second node only if the validation data generated for the first request is the same as the validation data generated from the second request.

14. The process of claim 1, wherein said first request is encapsulated using a connectionless transport layer protocol.

15. The process of claim 14, wherein said first request is encapsulated in a UDP packet.

16. The process of claim 1, wherein the process is executed by a third node of said communications network.

17. The process of claim 16, wherein said communications network is configured so that all packets sent to said second node are received by said third node for forwarding to said second node.

18. A system or device having one or more components for executing the steps of claim 1.

19. A proxy server having one or more components for executing the steps of claim 1.

20. A VoIP telephone having one or more components for executing the steps of claim 1.

21. A computer-readable storage medium having stored thereon program code for executing the steps of claim 1.

22. 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.

23. The node of claim 22, wherein said requests are SIP INVITE messages and said response is a SIP REDIRECT message.

24. The node of claim 22, wherein said node is adapted to generate said first validation data from said first request.

25. The node of claim 22, wherein said node is adapted to determine whether to establish said session on the basis of a comparison of said first validation data and said second validation data.