Patent Application
20080095138
The accompanying drawings, which are included to provide a further understanding of the invention and constitute a part of this specification, illustrate embodiments of the invention and together with the description help to explain the principles of the invention. In the drawings:
Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.
Reference is now made to
In
Client 252 initiates TCP handshake by sending a TCP segment to server 254 as illustrated with arrow 203. The TCP segment comprises the SYN flag set to “1” and the Sequence Number (SN) set to initial value “531521”. The initial value of the sequence number is generated by an initial sequence number generator, which selects a new 32 bit initial sequence number. The generator may be bound to a 32 bit clock which is incremented roughly every 4 microseconds. The purpose of the initial sequence number is to avoid reusing same sequence numbers in subsequent SYN segments. The segment also comprises a “Migrate OK” option and a “Timestamp” option. These options are used to carry parts of the public key “K_A” of client 252. The public key is reassembled in client 252. The “Migrate OK” option also carries a curve name parameter if Elliptic Curve Diffie-Hellman (ECDH) key exchange is used. The public key is computed in client 252 by setting K_A=XA*P. The value XA is a random value between 1 and n-1, wherein n is the order of P.
Server 254 also computes its public key by setting K_B=XB*P. The value XB is a random value between 1 and n-1, wherein n is the order of P. By using the public keys K_A and K_B both hosts compute the same shared secret K=K_A*XB=K_B*XA since K=K_A*XB=XA*P*XB=XB*P*XA=K_B*XA. Thereupon, in response to TCP segment illustrated with arrow 203, server 254 sends a TCP segment to client 252, as illustrated with arrow 204. The TCP segment comprises the SYN and ACK flags set to value “1”, sequence number set to initial value “083521” and acknowledgement number “ACK” set to value “531522”, which indicates successful receiving of one byte representing the SYN segment. The segment also comprises a “Migrate OK” option and a “Timestamp” option. These options are used to carry parts of the public key “K_B” of server 254, which is reassembled in client 252. Client 252 completes the connection establishment phase by sending a TCP segment to server 254, as illustrated with arrow 205. The TCP segment comprises the ACK flag set to value “1” and acknowledgement number set to value “083522”. The acknowledgement number is incremented by 1 in order to acknowledge the receipt of the ACK+SYN TCP segment. Normally, a SYN or an ACK+SYN segment is acknowledged by incrementing the sequence number “SN” by one. Thereupon, a number of data TCP segments are exchanged between client 252 and server 254. The final TCP segment before a handover that occurs at time T1 is illustrated with arrow 206. The TCP segment comprises sequence number set to value “091861”, acknowledgement number set to value “545968” and 536 bytes of data. The TCP segment is successfully received by client 252.
At time T1 client 252 performs a handover to a new address. The new address is obtained, for example, from a Dynamic Host Configuration Protocol (DHCP) server in the new network to which client 252 has moved. Client 252 resumes the TCP connection by sending a SYN TCP segment to server 254, as illustrated with arrow 207. The TCP segment comprises the SYN flag set to value “1”, sequence number set to value “545967” and a “Migrate” option comprising a token “T” and a request “R”. The token T=SHA1(client-isn, server-isn, K) is computed using a secure hash function SHA1 from the initial sequence values of client 252 and server 254 and the shared secret key “K” that has been computed using the public key “K_A” of client 252. The request R=SHA1(client-isn, server-isn, K, S, I) is computed using a secure hash function SHA1 from the initial sequence values of client 252 and server 254, the shared secret key “K”, the entire SYN segment comprising the “migrate” option, and a sequence number I identifying the migrate request from other similar migrate requests. Generally, in a TCP segments indicating migration, the sequence number “SN” is set to a value which is equal to one less than the acknowledgement number “ACK” of the last TCP segment successfully received from the peer. This is performed in order to differentiate migrate requests from other TCP SYN segments. In response, server 254 sends a segment to client 252, as illustrated with arrow 208. The segment comprises the SYN and ACK flags set to value “1”, sequence number set to value “092397” and acknowledgement number set to value “545968”, as illustrated with arrow 208. The three-way-handshake associated with the migration is completed by client 252, which sends a TCP segment to server 254 with the ACK flag set to “1” and acknowledgement number set to “092398”, as illustrated with arrow 209.
Client 352 initiates TCP handshake by sending a TCP segment to server 354 as illustrated with arrow 303. The TCP segment comprises the SYN flag set to “1” and the Sequence Number (SN) set to initial value “531521”. The segment also comprises a “Migrate OK” option, which is also referred to as, a Migrate-Permitted option.
In one embodiment of the invention, the segment also comprises a “Timestamp” option. The “Migrate OK” option and the “Timestamp” option may be used to carry parts of the public key “K_A” of client 352. The public key is reassembled in client 352.
In one embodiment of the invention, the “Migrate OK” option also carries a curve name parameter whenever Elliptic Curve Diffie-Hellman (ECDH) key exchange is used between client 352 and server 354 to negotiate a shared secret K.
In one embodiment of the invention, the public key is computed in client 352 by setting K_A=XA*P. The value XA is a random value between 1 and n-1, wherein n is the order of P. Server 354 also computes its public key by setting K_B=XB*P. The value XB is a random value between 1 and n-1, wherein n is the order of P. By using the public keys K_A and K_B both hosts compute the same shared secret K=K_A*XB=K_B*XA since K=K_A*XB=XA*P*XB=XB*P*XA=K_B*XA.
Server 354 sends reverse name service query to ANS-A 350 comprising the IP address (IP-A) of client 352 in order to obtain the Fully Qualified Domain Name (FQDN) for it, as illustrated with arrow 304. The returning of FQDN-A from ANS-B 350 to server 354 is illustrated with arrow 305. In response to the SYN TCP segment illustrated with arrow 303, server 354 sends a TCP segment to client 352, as illustrated with arrow 306. The TCP segment comprises the SYN and ACK flags set to value “1”, sequence number set to initial value “083521” and acknowledgement number “ACK” set to value “531522”, which indicates successful receiving of one byte representing the SYN segment. The segment also comprises a “Migrate OK” option. This indicates that communication peer supports TCP Migrate functionality. If the option is missing, initiator interprets it to indicate that Migration cannot be used for this session and will continue the session as a legacy TCP session.
In one embodiment of the invention, the segment also comprises a “Timestamp” option. These options are used to carry parts of the public key “K_B” of server 354, which is reassembled in client 352.
Client 352 completes the connection establishment phase by sending the TCP segment illustrated with arrow 307. The TCP segment comprises the ACK flag set to value “1” and acknowledgement number set to value “083522”. The acknowledgement number is incremented by 1 in order to acknowledge the receipt of the ACK+SYN TCP segment. Normally, a SYN or an ACK+SYN segment is acknowledged by incrementing the sequence number “SN” by one.
Thereupon, a number of data TCP segments are exchanged between client 352 and server 354. The final TCP segment before handovers that occur at time T1 is illustrated with arrow 308. The TCP segment comprises sequence number set to value “091861”, acknowledgement number set to value “545968” and 536 bytes of data. The TCP segment is successfully received by client 352. At time T1 client 352 and server 354 both perform handovers to new addresses. The new addresses A′ and B′ are obtained (not shown), for example, from Dynamic Host Configuration Protocol (DHCP) servers in the new networks to which client 352 and server 354 have moved, respectively.
Client 352 sends an update message to ANS-A 350, which provides the FQDN-A and IP-A′, as illustrated with arrow 309. The acknowledgement to the update is not shown. Client 352 starts attempting to resume the TCP connection by sending a SYN TCP segment to server 354, as illustrated with arrow 310. The TCP segment comprises the SYN flag set to value “1”, sequence number set to value “545967” and a “Migrate” option comprising a token “T” and a request “R”. The token T=SHA1(client-isn, server-isn, K) is computed using a secure hash function SHA1 from the initial sequence values of client 252 and server 254 and the shared secret key “K” that has been computed using the public key “K_A” of client 252. The request R=SHA1(client-isn, server-isn, K, S, I) is computed using a secure hash function SHA1 from the initial sequence values of client 352 and server 354, the shared secret key “K”, the entire SYN segment comprising the “migrate” option, and a sequence number I identifying the migrate request from other similar migrate requests. Generally, in a TCP segments indicating migration, the sequence number “SN” is set to a value which is equal to one less than the acknowledgement number “ACK” of the last TCP segment successfully received from the peer. This is performed in order to differentiate migrate requests from other TCP SYN segments. The token “T” will be used by the receiving peer to identify the resumed TCP connection and the TCP control block information for the connection. However, the TCP segment is not received by server 354 due to the fact that it has performed handover and is no longer available at the old IP address. The TCP segment is lost.
Server 354 sends an update message to ANS-B 356, which provides the FQDN-B and IP-B′, as illustrated with arrow 311. The acknowledgement to the update is not shown. Server 354 starts attempting to resume the TCP connection by sending a SYN TCP segment to client 352, as illustrated with arrow 312. The TCP segment comprises the SYN flag set to value “1”, sequence number set to value “092397” and a “Migrate” option comprising the token “T” and the request “R”. The token and the request are computed as explained hereinbefore. However, the TCP segment is not received by client 352 due to the fact that it has performed handover and is no longer available at its old IP address. Thus, the TCP segment is lost.
In response to a timeout for a response to the TCP segment illustrated with arrow 312, server 354 sends a query to ANS-A 350, as illustrated with arrow 313. The query comprises the FQDN-A, which is used to obtain the current IP address for client 352, namely IP-A′. In response, ANS-A 350 provides the IP address IP-A′ to server 354, as illustrated with arrow 315. The timeout indicates a possible double handover and therefore the sending of the TCP segment with migrate option must be repeated.
In response to a timeout for a response to the TCP segment illustrated with arrow 310, client 352 sends a query to ANS-B 356, as illustrated with arrow 314. The query comprises the FQDN-B, which is used to obtain the current IP address for server 354, namely IP-B′. In response, ANS-B 356 provides the IP address IP-B′ to client 352, as illustrated with arrow 316.
Client 352 repeatedly sends the TCP segment with the migrate option comprising the “T” and “R” parameters, SYN flag set to “1” and sequence number to “545967” indicating the migration, as illustrated with arrow 317. Substantially simultaneously with client 352, server 354 repeatedly sends the TCP segment with the migrate option. The TCP segment comprises the “T” and “R” parameters, SYN flag set to “1” and sequence number set to “092397” indicating the migration, as illustrated with arrow 318.
In response to the receiving of the TCP segment illustrated with arrow 318, client 352 obtains the connection information with the token “T”. Client 352 searches through a list of connections and obtains connection information from the table for the connection identified with token “T”. Generally, client 352 maintains a table of connections, which are indexed using the tokens computed with the connection parameters explained hereinbefore. The client 352 sends a TCP with the SYN and ACK flags set to value “1”, sequence number set to value “545967” and acknowledgement number set to value “092398”, as illustrated with arrow 319. A second TCP process is started in client 352 in addition to the one started by sending the TCP segment illustrated with arrow 317. At a later point in time, client 352 must decide which TCP process to continue.
In response to the receiving of the TCP segment illustrated with arrow 317, server 354 obtains the connection information with the token “T”. Server 354 sends a TCP with the SYN and ACK flags set to value “1”, sequence number set to value “092397” and acknowledgement number set to value “545968”, as illustrated with arrow 320. A second TCP process is started also in server 354 in addition to the one started by sending the TCP segment illustrated with arrow 318. At a later point in time, server 354 must decide which TCP process to continue.
In response to the receiving of the TCP segment illustrated with arrow 319, server 354 sends a TCP with the ACK flags set to value “1”, sequence number set to value “092398”, the acknowledgement number set to value 545968 and 536 bytes of data.
In response to the receiving of the TCP segment illustrated with arrow 320, client 352 sends a TCP with the ACK flags set to value “1”, sequence number set to value “545968”, the acknowledgement number set to value “092398” and no bytes of data.
Due to the fact that server 354 is first in the sending of data, it is considered by client 352 that the TCP process initiated by server 354 with TCP segment 318 is the one to be continued. Therefore, the other TCP process initiated by client 352 is abandoned. Equivalently, server 354, upon receiving TCP segment 322 with no data, decides that the TCP process initiated by it should continue.
In one embodiment of the invention, additional heuristics may be used to decide which of the simultaneous processes are allowed to continue. For example, the node which originally initiated the TCP connection by sending SYN+ACK TCP segment may be considered the one which is allowed to establish the migrated connection. Similarly, the node acting initially as the TCP server may be considered the one which is allowed to establish the migrated connection. Other similar heuristics comprise the comparing of IP addresses and selecting the node with the highest IP address. In one embodiment of the invention, the IP addresses of both nodes are used as arguments in a hash function to compute a result value. The computation may be performed in both nodes. The node whose IP address yields the highest result value is considered the one which establishes the migrated connection.
At step 400 a public key is computed in a client by setting K_A=XA*P. The value XA is a random value between 1 and n-1, wherein n is the order of P. The client starts establishing a transport connection with a server. The transport connection may be a TCP connection. The transport layer connection may also be a media stream connection carried over an unreliable datagram service between the client and the server. The connection may be a Real-Time Protocol (RTP) stream carried over User Datagram Protocol (UDP). In association with the connection establishment the client provides the public key K_A to the server. The Server also computes its public key by setting K_B=XB*P. The value XB is a random value between 1 and n-1, wherein n is the order of P. By using the public keys K_A and K_B both hosts compute the same shared secret K=K_A*XB=K_B*XA. The server provides the public key K_B to the client in association with connection establishment acknowledgement.
At step 402 the server obtains the client name using the client address. If the client has established the connection using an address of the server, the client also obtains the name of the server using the server address. Thus, peer node names are obtained using peer addresses. The step of obtaining peer node names may also be performed during the course of the establishment of the transport connection.
At step 404 it is checked if the connection release is to be performed. If the connection must be released, for example, due to a release request from either party, the connection is released and the method is finished. If the connection is not to be released, the method continues at step 406.
At step 406 it is checked by the client or the server if there is a handover. If there is no handover, the method continues at step 404. If there is a handover condition, the method continues at step 408.
At step 408 the node performing the handover allocates a radio resource from the target radio network and establishes radio communication with a base transceiver station from the target radio network. The node performing the handover obtains a new address from a packet switched network connected to the target radio network. The node performing the handover may be the client or the server.
At step 410 the new address is updated to a name service, which is responsible for providing an address for the node using its name. The name service may be the Internet Domain Name System (DNS).
At step 412 a token is computed in the node performing the handover. The token is computed, for example, by setting T=SHA1(client-isn, server-isn, K), wherein client-isn and the server-isn are the initial sequence numbers associated with the client and the server, respectively. The parameter K is the shared secret K. Generally, the token identifies the connection securely to the peer node, which is informed of the handover. Further, a request value may be computed in addition to the token. The request R=SHA1(client-isn, server-isn, K, S, I) is computed using a secure hash function SHA1 from the initial sequence values of the client and the server, the shared secret key “K”, an entire connection re-establishment request comprising a migrate option, and a sequence number I identifying the migrate request from other similar migrate requests. The secure hash algorithm is not necessarily SHA1, but may be any other secure hash algorithm such as, for example, MD5 or SHA-256. The token T, optionally the request R and the new address of the node that performed the handover are sent to the peer node.
At step 414 the node that performed the handover waits for an acknowledgement to the migration request. For example, in the case of TCP, the node waits for a TCP segment with the SYN and ACK flags set to value “1”. If such an acknowledgement is received within a predefined time limit, the method continues at step 416. If such an acknowledgement is not received within the predefined time limit, the method continues at step 418.
At step 416 the acknowledgement to the migration request acknowledgement and the connection parameters received from the peer node are acknowledged by the node that performed the handover.
At step 418 the node that performed the handover requests the peer address using the peer node name from the name service. The purpose of the repeated request is to obtain the new address for the peer node in case also the peer node has performed a handover and changed its address.
At step 420 the node that performed the handover at step 406, repeats the sending of the token and its new address to the peer node. As mentioned before, the token may be accompanied by the request parameter R, which identifies the request from the previous requests.
At step 422 a reply or a timer expiry for receiving a response is waited. The reply may be received from the peer node or from the name service. If a reply is received from the peer node, the method continues at step 416. If a reply is received from the name service and the reply comprises a new address for the peer node, the method continues at step 412. If a reply is received from the name service and the reply still provides the old address for the peer node, the method continues at step 418. If the timer for a reply expires, the method continues at step 418.
In one embodiment of the invention, transport entity 534, IP entity 536 and layer-2 entity 538 are comprised in the operating system of network node 500. The entities within network node 500 in
It is obvious to a person skilled in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways. The invention and its embodiments are thus not limited to the examples described above; instead they may vary within the scope of the claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20060936 | Oct 2006 | FI | national |
