Mobile TCP socket for secure applications

Vu Truong Thanh, Yoshiyori Urano

Graduate School of Global Information and Telecommunication Studies, Waseda University, Japan
[email protected], [email protected]

CH the TCP session is not disturbed. The problems of these

Abstract— A TCP session uses IP addresses (+ IP port) of both approaches are non- transparent end-to-end operation of TCP
end points as identifiers. Therefore when a mobile handover to session, as well as the requirement of new infrastructure
a new AP that belong to a different subnet/domain, the IP entities (the middle agent) and triangle overhead.
address will changes and ongoing TCP connections are reset. The other approach modify the TCP stack so that when the
Several approaches have been proposed to solve this problem, mobile host changes the connection to the internet, the TCP
and one of which was to modified the TCP/IP stack to update stacks at both ends preserver the TCP connection and update
the changes of the IP address for the ongoing connections [5] the TCBs with the new IP address at both ends accordingly.
[6]. However, these proposals causes unnecessary processing In [5], when the MH changes its location, the proposal in [5]
introduced new states to the TCP specification. When the
when TCP is used in applications which have already employed
address of MH changes, MH and CN will exchange
some kinds of security measures, such as SIP. This paper
information and update the new IP address accordingly. Both
proposes the Mobi Socket, which specifically supports TCP sides will prepare in advance a share-secret, and use this share-
mobility for intrinsic secure applications without unnecessary secret to authenticate each other during the update process.
overhead. The proposal in [6] employs a similar concept, but instead of
changing the TCP stack, it uses kernel extensions and a user-
Keywords— TCP mobility, secure applications
level redirect daemon process (this was the design of the
prototype in BSD). The daemon process will monitor the
I. INTRODUCTION
wireless network interface for changes of IP address, and if one
TCP/IP was developed when all network nodes were is detected, the daemon at the MH will inform the counterpart
stationary, and connection to a network is through cable, at the CH to update the new IP address together. To secure the
therefore it is unthinkable that a node will move to another update process from malicious acts, MH and CH also need a
subnet while accessing to the Internet, and the IP address of share-secret in advance.
an end host is assumed to stay unchanged while a computer The problem with [5] is that both sides has to perform
is running. As a result, IP address (together with IP port) is additional works to exchange a share-secret in advance,
used as identifiers for TCP session, and the TCP layer at the regardless of whether the MH will actually performs the
end host maintains TCP control blocks (TCBs), which hold handover to a new Access Point (AP) or not, or whether the
the IP addresses and IP ports of both ends for each TCP TCP session lives long enough to experience a handover. The
connection to find the right socket for each datagram it proposal in [6] relieves this matter by initiating the preparation
receives from the IP layer. process only if the TCP connection exists longer than a
But with the introduction of wireless access technologies threshold. However, if the MH does not perform a handover,
such as Wi-Fi, it is possible for a mobile node to handover to then all of the preparations for the long-live connections are
a new AP that belong to a different subnet/domain while wasted.
actively connecting to the Internet. This causes an IP address One more problems with [5] and [6] is that processing the
change, and for current implementation of TCP/IP stack, all share-secret for authentication will requires a lot of processing,
ongoing TCP connections are reset. This will cause problem which in turn consumes battery power at the MH. If many TCP
for long-live TCP sessions. connections are used (such as if the user constantly browsing
There are two general approaches to solve the problem of the Internet) then battery life will be shortened considerably.
changing host IP address for TCP session. The first one uses Moreover, both [5] and [6] are not applicable in the case where
the split-connection approach, which introduces a fix middle both ends perform handover simultaneously.
agent between the mobile host (MH) and correspondent host In the next parts of this paper, we propose a new type of
(CH) [4]. The connection between CH and MH is broken socket called the TCP MobiSocket, that remains connected
into two parts, the fixed part between the CH and the agent even if the concerned IP address changes. It works like normal
remains unchanged regardless of the position of the MH, and TCP socket, but does not get reset when the IP address at either
the TCP connection between the agent and the MH will be end changes, and with an additional updateTCB() member
re-established whenever the MH handovers to a new address. function to update the TCBs with the new address. All of the
In this sense only the TCP at the MH is affected, while at the security issues that are required to secure the update of the new

ISBN 978-89-5519-146-2 - 971 - Feb. 7-10, 2010 ICACT 2010

address will be handled by the calling applications. This new activate the mobile feature of the socket
socket is dedicated to support mobile TCP session for
If this function is not called, then the MobiSocket
intrinsically secure application, without all the above
will work like normal TCP socket
mentions problems of [5] and [6].
When this function is called, the TCP connection
II. DESIGN OF THE MOBISOCKET will not be abolished if the concerned wireless
Logically, there are two phases when mobile device interface changes to a new IP address
handover. First, the Network interface/card disconnects from updateTCB(socket_id, direction, newIPaddress,
the old AP. Then it connects to the new AP. In traditional newPort)
TCP stack, the network stack at the MH will close all TCP
socket_id: handler of the socket
connections in cleaning-up activities, as well as reset the
TCBs during these phases. direction: update the source or the
destination address
On the other hand, all of the ongoing MobiSocket will
remain in ESTABLISHED state, when the IP address newIPaddress, newPort: the new IP address
changes, waiting to be updated by the application. and new port to update to TCB/PCB (TCP
Control Block/Protocol Control Block). If
We design a new socket that allows the application to the port is 0 then keep the existing port
update the change of PoA at both end hosts. The socket is value
designed based on the following assumptions/requirements: The application will call this function to update the
- There are cases when the TCP connection needs explicit TCB/PCB (TCP Control Block/Protocol Control
handling before communicating using the new IP Block) with the new source/destination address and
address (Re-establishment/update of Security port
Association for VPN, sending the PATH message of The MobiSocket will start a new congestion control
RSVP for QoS, etc…) algorithm called the mobile congestion control
- The application takes care of security activities copyTCB(new_socket_id, old_socket_id)
regarding the update of the new address. The reasons for
this are (1) if the connection needs to be secure, the old_socket_id: handler of the old socket
applications have already shared some kind of security, new_socket_id: handler of the new socket
and (2) if the connection is not important to the extend
that it requires a shared security association between The application will call this function to update the
both end host, then it might not important enough to be TCB/PCB (TCP Control Block/Protocol Control
hacked by others. Block) of the newly created socket with the
information of the old socket. This is used when the
- Compatibility with applications using legacy TCP/IP application want to handover from old interface to
stack is desired to promote deployment. It means that in new interface.
the case the other end does not support the features of
mobile socket, connection will work according to that of This function will copy all information of the old
legacy TCP specification. socket (include current states, CWND, AWND,
RTO etc…, except the source IP address and source
- Being able to provide handover of TCP session between Port) to that of the new socket, and then delete the
different network interfaces of the same mobile device. old socket without sending FIN to the other end (i.e.,
The requirement is that not only IP address but change application at the CH).
of TCP port also must be supported, because the same
port of the other network interface might be in used by a Apart from the above two new APIs/member functions, the
different application at the time of the request for MobiSocket also introduces two new message, the AddChange
handover. and AddConfirm.

The application which uses the MobiSocket will call the The AddChange contains (1) A shared token between Mobile
MobiSocket’s updateTCB()member function to update Host (MH) and Correspondent Host (CH), (2) the old IP
the TCB with the new destination address. address and the new IP address encrypted by the private key of
the MH, (3) the new port address and (4) The old IP address of
To satisfy the above requirements, the mobile socket will the MH in plain-text
provide the following APIs to the applications:
The AddConfirm contains (1) the shared token between MH
acvMobi(socket_id) and CH, (2) the new IP address encrypted by the private key of
socket_id: the handler of the socket the CH

The application will call this function to explicitly If the two messages above are implemented as TCP header
options, then these header options must be sent to the

ISBN 978-89-5519-146-2 - 972 - Feb. 7-10, 2010 ICACT 2010

applications, but currently there is no mechanism to perform More suitable for application with strict security
such action. Therefore, it might be better to send this as OOB requirements
(out-of-band) data using the TCP Urgent Pointer. Still work when both ends handover simultaneously
Reach-ability through SIP Registration
III. WORKING PROCEDURE OF THE MOBISOCKET functionality
Let’s consider the use of MobiSocket for a SIP application. We can further optimize the operation of the MobiSocket as
Suppose that a TCP connection is established between MH follows:
and CH (the thick, solid line), which have established a SIP - When the MN receives the INFO message from CN, both
session through the SIP server. The MobiSocket will work as ends might already time out (due to handover, NOT due to
follows (see figure 1): congestion), so even if the TCB is updated, no data
- First the application creates the TCP socket for the exchange is possible until the time out is over (can be very
SIP session, and calls the acvMobi() to activate the long). We can provide a new function to reset the timer
mobile feature for the socket after the updateTCB() function, which is the
- In step ○1 , the MH moves from Subnet 1 to Subnet resetTimer(socket_id). This function will reset the TCP
2, and in the process its address change from IPaddress1 socket to the state as if it has just received a data/ACK
to IPaddress2 packet from the other machine
2 , the SIP application at the will call the - Furthermore, if SIP proxy is used, then normally the MN
- In step ○
has to finish re-Registration with the SIP proxy first before
updateTCB() function to replace IPaddress1 with
it can send SIP INFO message to the other end. This
IPaddress2 at the TCB table. Then it issues a SIP INFO
creates further delay for the TCP session. To solve this, we
message to ask CH update the new IP address of the MH.
note that the MN and CN can share public key with each
- Upon receiving this INFO message in step ○ 3 , the other during the initial INVITE process, therefore after the
SIP application at the CH will authenticate the message MN handover to a new IP address, it can use the public
using SIP security associations, and all the key of the CN to send the SIP INFO message to the CN
updateTCB() function to replace IPaddress1 with right away. However, this solution cannot be used if both
IPaddress2 at the TCB table. ends handover simultaneously (therefore they do not know
- Then in step ○ 4 the SIP application at the CH will the IP address of each other), in this case they must contact
send back the INFO message back the the MH to through SIP proxy server (after the re-Registration
confirm the change of address. Note that both INFO process)
messages may contain other parameters of the concerned
TCP session, such as new window size, MSS etc… V. CONCLUSION
- CH and MH will start sending data using the TCP In this paper we propose the MobiSocket to support TCP
connection when they receives the INFO message from mobility for secure application such as SIP. This socket causes
the other end, and they will start receiving data after no overhead if handover does not take place like previous
they send the INFO message to the other end. proposal, and moreover it still works when both side handover
simultaneously.
In this socket, there is no need for per-TCP connection
authentication, because the authentication is left to application.
Depending on the real situation, the application can also control
whether to keep the TCP session or not, which is more
appropriate for application which is applied with other
application level constrains such as security and QoS policy …
In the future, we would like to carry out the implementation
of the MobiSocket to confirm the design of the system, as well
as to measure the delay and throughput parameter when the
resetTimer() function is (1) called and (2) not called, and
compare the results with that of [5] and [6]. We also would like
Figure 1. Working procedure of the MobiSocket to measure the delay in the case of SIP application, when we
send the INFO message before and after re-Registration, as
IV. DISCUSSION AND OPTIMIZATION well as when two end hosts handoff together
The merits of the MobiSocket are: We also plan to update the proposal in [1] with this new
Inherit intrinsic security feature of SIP MobiSocket.
Less processing overhead for security issues
(conserve power) REFERENCES
Depending on the security requirements, the [1] Vu Truong Thanh, Yoshiyori Urano, “Agent based LLMA handover scheme
for SIP communication – The case for UDP traffic", The 11th International
application can decide whether to allow the Conference on Advanced Communication Technology (ICACT), Feb. 2009
handover of TCP connection

ISBN 978-89-5519-146-2 - 973 - Feb. 7-10, 2010 ICACT 2010

[2] C. Perkins, “IP Mobility Support for IPv4”, Request for Comments: [5] FUNATO D., “TCP-R: TCP mobility support for continuous operation”,
3344, IETF, August 2002 Proc. IEEE International Conference on Network Protocols, pp. 229 -236
[3] Huei-Wen Ferng et. al, “A SIP-Based Mobility Management ,Oct. 1997
Architecture Supporting TCP with Handover Optimization”, Proc. of [6] Vassilis Prevelakis and Sotiris Ioannidis, “Preserving TCP Connections
Vehicular Technology Conference, pp. 1224-1228, Apr. 2007 Across Host Address Changes”, Lecture Notes in Computer Science,
[4] Milind Buddhikot et. al, “MobileNAT: a new technique for mobility Springer Berlin / Heidelberg, pp. 299-310 Oct., 2006
across heterogeneous address spaces”, Proc. the 1st ACM international [7] Rosenberg, et. al., “Session Initiation Protocol”, Request for Comments:
workshop on Wireless mobile applications and services on WLAN 3261, IETF June 2002
hotspot, pp. 75-84, Sept., 2003 [8] D. Yon et. al, “TCP-Based Media Transport in the Session Description
Protocol (SDP)”, Request for Comments: 4145, IETF, September 2005

ISBN 978-89-5519-146-2 - 974 - Feb. 7-10, 2010 ICACT 2010