Secure Network Mobility (SeNEMO)for Real-Time
ApplicationsTuan-Che Chen, Student Member, IEEE, Jyh-Cheng Chen,
Senior Member, IEEE, andZong-Hua Liu, Student Member,
IEEEAbstractThe IETF NEtwork MObility (NEMO) working group has
considered how to enable an entire network to move from onelocation
to another. Mobile Virtual Private Network (VPN) has been developed
to secure mobile users communication betweenuntrusted external
networks and the protected private internal network. However, the
IETFs mobile VPN does not address how tosupport NEMO. In addition,
it is not suitable for real-time applications. In this paper, we
propose architecture and protocols to supportVPN in NEMO, which is
called Secure NEMO (SeNEMO). The proposed SeNEMO, based on Session
Initiation Protocol (SIP), isspecifically designed for real-time
applications over VPN. It allows an entire network to move and
still maintains session continuity. Inaddition to analyzing the
security vulnerabilities, we also propose analytical models to
evaluate the performance of the proposedSeNEMO. The analysis is
validated by extensive simulations. The results show that the
proposed SeNEMO can reduce signaling costsignificantly.Index
TermsNetwork mobility (NEMO), mobile virtual private network (VPN),
security, session initiation protocol (SIP), performanceanalysis.1
INTRODUCTIONAS more and more electronic devices are equipped
withwireless communication interfaces, wireless Internetaccess is
not limited to a single device but also a group ofdevices moving
altogether. For instance, a person carrying alaptop and other
devices with different radio interfacessuch as 3G/4G, WiFi, or
Bluetooth may constitute a simplemobile network. The laptop can be
a mobile router connect-ing to the Internet. All other devices can
obtain Internetaccess through the laptop. Therefore, Personal Area
Networks(PANs) can be an example of mobile network. Otherexamples
of mobile networks include wireless networkeddevices and sensors
deployed inside vehicles such as buses,cars, and trains (e.g.,
FIFTH project [1]). In addition,spacecrafts and airlines (e.g.,
WirelessCabin project [2])are deploying mobile networks for
Internet access andcontrol systems.The IETF NEtwork MObility (NEMO)
working grouphas completed several RFCs to enable a network to
movefrom one location to another location while still
maintainingits local nodes ongoing sessions. In the NEMO
basicsupport protocol [3], a mobile network may contain
severalnodes which are connected by one or more Mobile
Routers(MRs). An MR, which connects to the IP backbone, is incharge
of the mobility management of the entire network.Mobile Network
Nodes (MNNs) in NEMO are classified as:Local Fixed Nodes (LFNs) and
Visiting Mobile Node(VMNs). An LFN always connects to the same
mobilenetwork, while a VMN can change its point of
attachment.Similar to that in Mobile IP (MIP) [4], every mobile
network isassigned Mobile Network Prefixes (MNPs) by the
homenetwork. The Home Agent (HA) needs to maintain abinding between
the MNPs and the MRs current Care ofAddress (CoA). Therefore, when
the mobile network movesaway from its home network, packets from
CorrespondentNodes (CNs) are redirected by HA to the MR.
Theacronyms used in this paper is listed in Table 1.In this paper,
we consider how to provide Virtual PrivateNetwork (VPN) services in
NEMO. Security has become acritical issue for todays Internet. VPN
has been developedto secure users communication between untrusted
externalnetworks (internet) and the protected private
internalnetwork (intranet). VPN services over NEMO can be usedin a
variety of applications so a mobile network can access toits
intranet in a secure way. For example, a NEMO VPN canbe used in
public safety, where wireless devices in a policepatrol car can
access to the criminal databases, driver licenseand vehicle
registration databases, or other services in thedispatch center as
the car travels between different subnets.Similar type of services
can also be used in ambulance ormobile medical car, where various
wireless devices orsensors are deployed inside the car. In
addition, NEMOVPNs can also be adopted by enterprise mobile users
whocarry several wireless devices and are required to
maintainsecure sessions to their companys intranet. However,
theIETF NEMO working group has been concluded in June2008. How to
provide VPN services were not solved in IETFNEMO working group.
Although IETF has proposed a VPNarchitecture to support mobility
[5], the solution is for asingle node only. In addition, it is
based on MIP, which is notsuitable for real-time applications. As
discussed in [6], [7],the IETFs mobile VPN employs one IPsec [8]
tunnel andtwo MIP tunnels. The three tunnels cause large overhead
fortransmitting real-time packets. In this paper, we proposeIEEE
TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 8, AUGUST 2011 1113.
T.-C. Chen and Z.-H. Liu are with the Department of Computer
Science,National Tsing Hua University, Hsinchu, Taiwan 300.E-mail:
{brad.tcchen, horselui}@gmail.com.. J.-C. Chen is with the
Department of Computer Science, National ChiaoTung University,
Hsinchu, Taiwan 300. E-mail: [email protected] received 9
July 2009; revised 23 Jan. 2010; accepted 12 Aug. 2010;published
online 15 Nov. 2010.For information on obtaining reprints of this
article, please send e-mail to:[email protected], and reference
IEEECS Log Number TMC-2009-07-0279.Digital Object Identifier no.
10.1109/TMC.2010.219.1536-1233/11/$26.00 2011 IEEE Published by the
IEEE CS, CASS, ComSoc, IES, & SPSarchitecture and protocols to
support VPN in NEMO, whichis called Secure NEMO (SeNEMO). The
proposed SeNEMO,based on Session Initiation Protocol (SIP) [9], is
specificallydesigned for real-time applications over mobile VPN
forgroup mobility. The contribution of this paper is
two-fold.First, we propose a new architecture and protocols
tosupport VPN in NEMO. We demonstrate that by integratingSIP-based
mobile VPN with NEMO, we can provide secureand efficient group
mobility for real-time services. Second,we develop an intricate
analytic model to evaluate theperformance of the proposed SeNEMO.
The mathematicalmodel quantifies the performance of the proposed
SeNEMOand IETFs mobile VPN. Extensive simulations have alsobeen
conducted to validate the analysis.The rest of this paper is
organized as follows: Section 2provides an overview of related
work. The proposedSeNEMO is presented in Section 3. The analytical
modelandnumerical results are
presentedinSection4andSection5,respectively. Section 6 summarizes
this paper.2 RELATED WORKAs aforementioned discussion, IETF has
defined architec-ture and protocols for mobile VPN [5]. Fig. 1
illustrates theIETF Mobile VPN (MVPN). There are two HAs, internal
HA(i-HA) and external HA (x-HA), located in intranet andinternet,
respectively. When the Mobile Node (MN) movesout of the intranet,
it first acquires a new CoA from DHCP1114 IEEE TRANSACTIONS ON
MOBILE COMPUTING, VOL. 10, NO. 8, AUGUST 2011TABLE 1List of
AcronymsFig. 1. MVPN proposed by IETF.server or Foreign Agent (FA)
and registers the CoA with thex-HA. The MN then establishes an
IPsec tunnel with theVPN gateway by using its external Home Address
(x-HoA).The IPsec tunnel is built by using Internet Key
Exchange(IKE) [10]. A VPN Tunnel Inner Address (VPN-TIA) will
beassigned to the MNas the MNs internal CoAduring the
IKEnegotiation. After that, the internal MIP (i-MIP) registrationis
performed by registering VPN-TIAwith its i-HA. With theexternal MIP
tunnel, the IPsec tunnel will not break whenthe MN roams in
internet because only the external MIP (x-MIP) registration is
required. The three tunnels (x-MIP,IPsec, i-MIP) is shown in the
bottom of Fig. 1.The IETF MVPN cannot be applied to NEMO because
itdoes not consider the mobility of a group of mobile
devices.Besides, the IETF solution, which is based on IPsec
andMIPv4 [4], will incur long handoff latency and end-to-endlatency
[11], [12]. The three tunnels (one IPsec tunnel andtwoMIP tunnels)
increase around 100 bytes for the packet length,which is relatively
five times of the length of a G.7291real-time packet [13]. The
tunnels increase massive overhead interms of packets length and
processing time. This maydegrade the performance of real-time
applications, which aresensitive to bandwidth and delay. In
addition, where to putthe x-HA and how to trust the x-HA are
critical issues. Tobetter support real-time applications, a
SIP-based mobileVPN has also been proposed [6], [7]. However, it
considersthe VPN for the movement of a single node only.Although
security in NEMO has been investigated insome IETF documents and
other literatures [14], [15], all ofthem are based on MIP and IPsec
which inherit theproblems discussed earlier for real-time services.
Besides,they are not designed specifically to support mobile VPN.On
the other hand, SIP has been proposed to provide hostmobility and
session continuity [16], [17]. It has also beenshown that SIP-based
mobility can be easily deployed andreduce the data transmission
delay in NEMO [18], [19].However, by adopting SIP into NEMO, it may
increasesignaling cost during handoff due to sending many re-INVITE
messages for ongoing sessions. In addition, securityand VPN are not
addressed specifically in the studies.In this paper, we integrate
SIP-based mobile VPN withNEMO and evaluate its performance. To the
best of ourknowledge, among the literatures available in
publicdomain, this paper is the first considering how to
supportmobile VPN in NEMO. Our design is particularly suitablefor
real-time applications.3 PROPOSED SECURE NEMO (SENEMO)The proposed
SeNEMO comprises SIP, Secure Real-timeTransport Protocol (SRTP)
[20], Multimedia Internet KEY-ing (MIKEY) [21], and Diameter [22]
to provide VPNservices in NEMO.Fig. 2 depicts the architecture of
the proposed SeNEMO. Itshows a mobile network in a Foreign Network
(internet)connecting to the CN in the Home Network (intranet).
TheSIP NEMO VPN Gateway (SIP-NVG) shown in the MobileNetwork
residing in Foreign Network 1 is the gateway of themobile network
to other networks. It follows the SIPstandards and manages the
traffic between the mobilenetwork and outside world. The VPN
Gateway (VPN GW)consists of SIP Proxy 1 and Application Level
Gateway(ALG). There is a firewall between internet and intranet
toprevent external users from getting direct access to theintranet.
The SIP Proxy 1 is a SIP proxy server, whichCHEN ET AL.: SECURE
NETWORK MOBILITY (SENEMO) FOR REAL-TIME APPLICATIONS 11151. There
are many different voice codecs used in IP networks,
includingG.711, G.723.1, G.726, G.728, and G.729. The payload
lengths of these codecsare in the range of 20 bytes to 160 bytes.
G.729 with payload length of20 bytes is the most commonly used
codec for VoIP applications due to itslow bandwidth
requirement.Fig. 2. System architecture.authenticates the incoming
SIP messages through theDiameter server. It also routes messages to
SIP Proxy 2 whichis essentially a SIP Registrar. Meanwhile, MIKEY
is used askey management protocol to provide security keys for
theALG, which then oversees all data traffic.The main advantages of
the proposed SeNEMO are:. All SIP clients are able to directly
communicate witheach other without going through a mobility
agentsuch as the HA in MIP. Therefore, the routes areoptimized.
This is particularly beneficial for real-time applications such as
Voice over IP (VoIP) andvideo streaming. In addition, tunnels such
as IPsectunnel or MIP tunnel are not required.. When a mobile
network changes its point ofattachment, a registration request can
represent theentire mobile network. This can reduce the
signalingoverhead significantly.. The proposed SeNEMO reuses
existing protocols. Itis compatible with existing standards and is
easy toimplement. The proposed SeNEMO has been im-plemented in a
testbed [23].Section 3.1 first describes the protocols used in
ourproposed architecture. The proposed SeNEMO architectureis then
presented in Section 3.2. Section 3.3 discusses theoperations of
the proposed SeNEMO. Specifically, how tosupport handoff and
maintain session continuity arediscussed. In Section 3.4, we
analyze the security vulner-abilities of the proposed SeNEMO.3.1
ProtocolsIn this section, we discuss the corresponding protocols
forsignaling, secure transport, key management, and
Authentica-tion, Authorization, and Accounting (AAA). Figs. 3 and
4illustrate the protocol stacks for control plane and user planein
SeNEMO, respectively. For control plane, SIP is the mainprotocol to
manage the session between MN, SIP-NVG, SIPProxy 1, SIP Proxy 2,
and CN. Diameter SIP Application[24], which is based on the
Diameter base protocol [22], isused to authenticate and authorize a
user in Diameter Serverwhile the resource allocation in ALG is
achieved by usingMiddlebox Communication (MIDCOM) [25]. In
addition,MIKEY messages are embedded inside the messages ofDiameter
base protocol and Session Description Protocol(SDP) [26] to carry
the security information. For user plane,when the mobile network
resides in internet, SRTP is usedto secure the data transmission
between MN and ALG.3.1.1 SignalingSIP is an application-layer
signaling protocol. It is used tocreate, modify, and terminate
sessions in the proposedSeNEMO. SIP has defined its own security
and authentica-tion schemes. In our proposed SeNEMO, we use them
toauthenticate and identify the mobile users.SIP also supports user
mobility and terminal mobility [16],[27]. The terminal mobility is
achieved by sending newINVITE (re-INVITE) to the CN by using the
same call ID asthat in the original session. The new INVITE
contains thenew contact address the MN has acquired in the
newlocation. After receiving the re-INVITE, the CN will
redirectfuture traffic to the MNs new location.3.1.2 Secure
TransportSRTP defines a framework to provide encryption
andintegrity for Real-time Transport Protocol (RTP) [28] andRTP
Control Protocol (RTCP) [28] streams. SRTP alsoprovides replay
protection based on the RTP sequencenumber and the index number of
RTCP. The predefinedcryptographic transformations provide low
computationalcost and limited packet expansion so bandwidth can
beused more economically than IPsec [29]. It is alsoindependent of
the underlying transport networks.3.1.3 Key ManagementMIKEY is a
key management protocol developed formultimedia real-time
applications running over RTP/SRTP. Comparing with IKE which is
widely used as keymanagement protocol for unicast, MIKEY is
designed for1116 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10,
NO. 8, AUGUST 2011Fig. 3. SeNEMO protocol stacks for control plane
when the mobile network is in internet and CN is within
intranet.Fig. 4. SeNEMO protocol stacks for user plane when the
mobile network is in internet and CN is within
intranet.peer-to-peer or small interactive groups. MIKEY can
fulfillthe requirements of different environments. For
example,MIKEY message can be embedded inside SDP message. Anew type
/ has been defined in SDP to carry MIKEYmessage.The main purpose of
MIKEY is to transport the TEK2Generation Key (TGK) and other
related security parametersor policies which are used in security
transport protocols.TGK is an upper-level key, which is shared
within aninteractive group. It is used to derive TEK for
eachcryptographic session. TEK along with the exchangedsecurity
parameters are denoted as the Data SecurityAssociation (SA). The
Data SA is used as input of securitytransport protocol, such as
SRTP.3.1.4 AAABased on the Diameter base protocol, Diameter
SIPApplication allows a client of a SIP server to be
authenticatedand authorized by a Diameter server. There are six
Diametercommands in the Diameter SIP application. In the
proposedSeNEMO, we use User-Authorization-Request
(UAR)/User-Authorization-Answer (UAA) and Multimedia-Auth-Re-quest
(MAR)/Multimedia-Auth-Answer (MAA) to processSIP REGISTER and
INVITE messages. The authenticationis done by Diameter server
rather than by delegating to aSIP server.3.2 ArchitectureAs
aforementioned discussion, the SIP-NVG is the gatewayof the mobile
network to other networks. When a mobilenetwork roams between
different IP subnets, the SIP-NVGnot only keeps ongoing sessions
unbroken, but alsotransmits data in a secure manner. Besides, the
SIP-NVGensures that all the MNs attaching to the mobile networkare
globally reachable at any time.There are two types of interfaces
owned by SIP-NVG:egress interface and ingress interface.
ASIP-NVGattaches tointernet through egress interface. Once a mobile
networkmoves to a new IP subnet, the egress interface of the
SIP-NVG will get a new IP address. On the other hand, when anMN
wants to join a mobile network, it attaches to the ingressinterface
of the SIP-NVG. In our design, each mobile networkhas only one
SIP-NVG which essentially is an MR with SIPcapability. The proposed
SIP-NVG is able to route SIPmessages and data traffic between its
egress interface andingress interface by translating the
corresponding headers.Fig. 5 depicts the flows for registration
when the mobilenetwork is in a foreign network. When an MN enters
amobile network, the MN will get a new IP address andregister the
new IP address with the SIP-NVG. As shown inFig. 5, the MN will
update its current location with the SIPregistrar residing in the
home network by sending theREGISTER with the newly obtained contact
address. In thisexample, we assume the mobile network resides in
aforeign network and the new address assign for the MN
[email protected]. In our proposed architecture, theSIP Proxy 2
not only handles the signaling messages butalso acts as the SIP
registrar. The registration is based onthat specified in Diameter
SIP application. As illustrated inFig. 5, the SIP-NVG translates
the Contact field in theREGISTER from the MNs address into the
SIP-NVGs URIaddress, which is [email protected]. Besides, the
SIP-NVG establishes a Mapping Table to record the
registrationinformation for the MN. Hence, each request targeted to
theMN will be redirected to the SIP-NVG. The SIP-NVG thencan
forward the request to the MN according to theMapping Table.The
proposed architecture depicted in Fig. 2 adopts anALG which follows
MIDCOM architecture. In our proposedarchitecture, the ALG only
accepts commands from the SIPProxy 2 and provides responses for the
correspondingcommands. As the data protocol stacks shown in Fig.
4,when the ALG receives a special incoming RTP stream fromthe home
network to an MN in internet, it replaces thewhole IP/UDP/RTP
headers with a new one, transformsthe new RTP packet into SRTP
format, and deliveries theSRTP stream to the destination. In
reverse direction, theALG receives the SRTP stream from internet.
The ALGdecrypts it and verifies it to decide whether the SRTP
packetis valid or not. If the SRTP packet is decrypted and
verifiedsuccessfully, the RTP payload will be carried by a new
RTPheader. The new RTP packet is then transmitted to the
homenetwork. The symmetric RTP streams are represented as asession
in the ALG.Each session in the ALG requires enough external
andinternal resources. For example, the external resourceincludes
external listening address, external listening port,external
destination address, and external destination port.Destination
addresses and ports are provided by the SIPProxy 2. On the other
hand, the internal resource includesinternal listening address,
internal listening port, internaldestination address, and internal
destination port. Onlywhen all resources are ready, the session in
the ALG willstart. Wheneither the external or internal resource is
reservedsuccessfully, the ALG will reply the reserved
listeningaddress and port to the SIP Proxy 2. The SIP Proxy 2
willreplace the original parameters in SDP. Data SA is also
aresource which is the input of SRTP. The Diameter serverprovides
the Data SA. The SIP Proxy 2 transmits it with TGKto the ALG in the
resource reservation command.3.3 OperationsIn the architecture
shown in Fig. 2, the entire mobilenetwork may move altogether from
an IP subnet to another.This is referred to as network handoff. It
is also possible thatan MN moves into or moves out of the mobile
network.This is referred to as node handoff. This section
discusseshow the proposed SeNEMO maintains a secure sessionsduring
network handoff and node handoff.3.3.1 Node HandoffFig. 6 depicts
the flows when an MN moves into a mobilenetwork which is located
inside home network. First, theMN registers with the SIP-NVG and
the SIP registrar as thatdiscussed in Section 3.2. After the
registration, the MNneeds to re-invite the CN, if there are active
sessionsbetween them. For the INVITE request, in addition
totranslating the CONTACT field from the MNs address intothe
SIP-NVGs URI address, the SIP-NVG also adds theRECORD-ROUTE field
where the SIP-NVGs URI addressis inserted. Therefore, the
subsequent messages of theexisting sessions will be routed by the
SIP-NVG. Besides,the SIP-NVG maintains a Session Table to record
theinformation of each session, i.e., whether the session isCHEN ET
AL.: SECURE NETWORK MOBILITY (SENEMO) FOR REAL-TIME APPLICATIONS
11172. TEK stands for Traffic Encryption Key.active and the contact
address of the CN. Therefore, the SIP-NVG can determine the ongoing
session during handoff.Fig. 7 depicts the flows when an MN moves
into a mobilenetwork which is located inside a foreign network. In
thiscase, the signaling messages will need to go through SIPProxy
Server 1 and be authenticated by the Diameter Serverbefore they
reach SIP Proxy Server 2. The first few flows aresimilar to those
in Fig. 6. Rest of them are similar to those inFig. 8, which will
be discussed in next session.3.3.2 Network HandoffWhen the mobile
network and the CN are both locatedinside the same realm, for
example, the same intranet or thesame network domain in internet,
the data traffic betweenthe MNs attaching to the mobile network and
the CN doesnot need to pass through the ALG. Therefore, the SIP
Proxyservers in Fig. 2 does not need to intercept SIP
signalingmessages between the mobile network and the CN. The
datatraffic is transmitted directly between the mobile networkand
CN. As that in other studies of mobile VPN, we mainlyconsider the
security issues when a mobile network movesout of the intranet and
wants to access to the resources insidethe intranet. Thus, we
assume that CN is inside intranet andmobile network moves between
intranet and internet. UsingFig. 2 as an example, we consider the
cases when the mobilenetwork moves from Home Network to Foreign
Network 1,from Foreign Network 1 to Foreign Network 2, then
fromForeign Network 2 back to the Home Network.Fig. 8 illustrates
the flows when the mobile networkmoves from intranet to internet.
This may be the case whenthe mobile network moves from Home Network
to ForeignNetwork 1 as shown in Fig. 2. When a SIP-NVG moves to
aforeign network, it must register with the SIP registrar usingits
newIPaddress. The registration is similar to that shown inFig. 5
except that there is no need for SIP header translation.The
SIP-NVGthen checks whether there are MNs with activesessions inside
the mobile network according to the SessionTable. The SIP-NVG needs
to re-INVITE all CNs to recover1118 IEEE TRANSACTIONS ON MOBILE
COMPUTING, VOL. 10, NO. 8, AUGUST 2011Fig. 5. Message flows and
translation of REGISTER when mobile network resides in foreign
network.all of the ongoing sessions. However, this process may
causesubstantial signaling messages in wireless links. In order
toreduce the signaling overhead, the SIP-NVG combines allcontact
addresses of CNs into a URI list. The URI list is thenconveyed by
the SDP embedded in one INVITE message.Fig. 9 shows an example of a
URI list in SDP. The re-INVITEcontains the newcontact address of
the SIP-NVG. It is sent tothe SIP Proxy 1, which routes the message
to the SIP Proxy 2,assuming that SIPProxy 1 has beeninformedthat
SIPProxy 2is responsible for the verification of the ongoing
sessions.The proposedSeNEMOuses a protocol
basedonchallenge-response to authenticate each active session.
Username andpassword are used for verification. When an MN attaches
tothe mobile network, its SIP-NVG stores such securityinformation
to represent the MN. The Diameter command,MAR/MAA, in the Diameter
SIP application is used toprocess authentication messages. To
reduce the signalingoverhead, the security information for each
session isaggregated to one MAR/MAA message. This can be doneeasily
by setting the reserved bit to M in Command Flagswithin the
MAR/MAAs Diameter header to indicate thatthere are multiple
sessions requiredto process. Therefore, theSIP Proxy 2 first sends
the MAR to request that the Diameterserver authenticates and
authorizes the sessions. TheDiameter server then responses with MAA
which containschallenges to the SIP Proxy 2. The SIP Proxy 2 uses
them toresponse with 407 Proxy Authenticate to the SIP-NVG.
Afterthe SIP-NVG receives the 407 Proxy Authenticate, it
sendsagainthe re-INVITEcontainingauthorizationwhichincludesusername
and password for different sessions. The Diameterserver verifies
the authorization data and informs the SIPProxy 2 the verification
result of each session. If a session isverified successfully, the
Diameter Server will generate onepair of TGK and MIKEY for this
session. Thereafter, theMAA will have all the verification result
codes for eachsession. To establish TGK and MIKEY message,
presharedkey, which is one of the most efficient ways to handle
keytransport, is used. The pairs of the TGKandMIKEYmessagesCHEN ET
AL.: SECURE NETWORK MOBILITY (SENEMO) FOR REAL-TIME APPLICATIONS
1119Fig. 6. Message flows and translation of INVITE when MN moves
to a mobile network which is located inside home network.are
transmitted to the SIP Proxy 2 by MAA. We extend theMAA with two
more Attribute Value Pairs (AVPs): MIKEY-TGK and MIKEY-MSG. Fig. 10
shows an example of MAAwith multiple session information. The
extended AVPs areused in MAA only after the session has been
authorized byDiameter server and when the communication between
MNand CN needs to pass through the ALG.If the SIP-NVG is granted to
access the intranet, the SIPProxy 2 needs to allocate enough
resources to guarantee thatthe sessions will be protected. First,
the SIP Proxy 2 ordersthe ALG to reserve the internal receiving
address andreceiving port for each ongoing session. The command
fromthe SIP Proxy 2 may include the Data SA and the TGK forSRTP
protection, and the CNs original listening addressesand listening
ports. The ALG responds with the reservedaddresses and ports. The
SIP Proxy 2 inserts the listeningaddresses and listening ports in
the SDP to reproduceINVITE requests based on the URI list. It then
routes them toeach CN individually. Each CN sends back a 200 OK if
itagrees on the SDP of the re-INVITE. After receiving the 200OK
from each CN, the SIP Proxy 2 orders again the ALG toreserve the
external receiving addresses and receiving ports.The ALG also
responds with the reserved external receivingaddresses and
receiving ports. If all allocated resources areready, the SIP Proxy
2 replaces the listening addresses andlistening ports in the SDP of
each 200 OK. It also inserts theMIKEY Initiator message into the
SDP to transport TGK.When the modification is done, the SIP Proxy 2
sends each200 OK with the new SDP to the SIP-NVG. Once the SIP-NVG
receives each 200 OK, it will forward the message tothe MN. The ALG
then will start to function when bothinternal and external
resources have been acquired.When each MN attaching to the mobile
network receivesthe 200 OK with the MIKEY Initiator message, it
needs toprocess the MIKEY Initiator message and extract the
sharedTGK. The MN is then required to send an ACK with SDPwhich
includes the MIKEY responder message. After theMN sends the ACK, it
will start all transport sessions.Because the SIP-NVG now is in a
foreign network, thesession between the MN and the ALG must be
reestablishedin order to be protected by SRTP. The SIP Proxy
2exchanges the TGK with the MN on behalf of the CN.
Asaforementioned discussion, the SIP Proxy 2 transmits theTGK to
the ALG which is responsible for converting theprotected data
streams outside the intranet into unprotecteddata streams inside
the intranet.Fig. 11 illustrates the flows when the mobile
networkmoves again to another external network. This may be thecase
when the SIP-NVG moves from Foreign Network 1 toForeign Network 2
as shown in Fig. 2. The SIP-NVG alsoneeds to update its new
location with the Registrar and sendre-INVITE to the CNs with
active sessions. However, the SIPProxy 2 will function on behalf of
CNs to respond with the200 OK. The SIP Proxy 2 only orders the ALG
to modify the1120 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10,
NO. 8, AUGUST 2011Fig. 7. Message flows when MN moves to a mobile
network which is located inside a foreign network.external
listening addresses and ports. If necessary, the SIPProxy 2 can
also re-assign the TGKto the ALG. Therefore, theoriginal data
stream will be redirected to the new location ofthe SIP-NVG. Rest
of the discussion is similar to that in Fig. 8.Fig. 12 depicts the
flows when the mobile network movesback to the home network.
Because the data traffic is secureinside intranet, the ALG is
requested to deallocate both theinternal and external
resources.Because the proposed architecture is based on SIP,
theproblems inherited from MIP, such as overhead of threetunnels
and potential long end-to-end latency, are notproblems in our
design. Besides, by using SRTP, MIKEY,Diameter SIP Application, and
ALG, the proposed archi-tecture can provide VPN services for mobile
userseffectively. The proposed SeNEMO is particularly usefulfor
real-time applications. However, there might be somesecurity issues
in SIP. The following section discusses thesecurity vulnerabilities
in SeNEMO.3.4 Security Vulnerabilities in SeNEMOBecause the
proposed SeNEMO is designed based on SIP,the security problems in
SeNEMO might be inherited fromSIP. The security problems in SIP
have been widely studiedrecently [30], [31], [32], [33], [34]. This
section presents thequalitative analysis of security
vulnerabilities in theproposed SeNEMO.CHEN ET AL.: SECURE NETWORK
MOBILITY (SENEMO) FOR REAL-TIME APPLICATIONS 1121Fig. 8. Message
flows when mobile network roams from home network to foreign
network.Fig. 9. Example of a URI list with two CNs in SDP..
SIPauthentication: Like other commondeployment ofSIP, the proposed
SeNEMO uses a challenge-responsebased protocol to verify users.
Integrity andconfidentiality of SIP authentication messages arenot
protected. Therefore, malicious users may snifftraffic to get the
plaintext or place a spam call.However, in the proposed SeNEMO, the
transportof SIP messages can be easily extended toincorporate
Transport Layer Security (TLS) [35] sothe transmission of SIP
messages can be protected.. Denial of service (DoS): Protecting
against DoSattacks is inherently difficult on IP
networks,especially for mobile networks such as MIP [36].Similarly,
the open architecture of the Internet mayexpose any SIP network
element, such as Registrarserver or Proxy server, to DoS attacks.
However, inthe proposed SeNEMO, SIP Proxy2/Registrar andDiameter
server are located inside the intranet.Therefore, they are much
less vulnerable to DoSattacks. Besides, the ALG can block all the
messagescoming from unknown nodes unless the resourcesare reserved
for legitimate users by SIP Proxy 2.Although SIP Proxy 1 which is
on the border maybe subject to DoS attacks, a large portion of
theeffects can be reduced by proper server design andefficient
implementation by adequate hardware [31].. SIP parser attack: The
free text format of SIPmessage could make parsing difficult.
Attackerssending a very large messages with unnecessaryheaders and
bodies can exhaust the resource of SIPserver. The SeNEMO may suffer
from such attack1122 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL.
10, NO. 8, AUGUST 2011Fig. 10. The extended AVPs of MIKEY-TGK and
MIKEY-MSG in MAA.Fig. 11. Message flows when mobile network roams
from a foreign network to another foreign network.too. To solve
this problem, the parser in theSeNEMO can be designed to check
message sizeand discard the one which exceeds the size limit.Also,
a practical implementation provided by [33],[34], [37] can be
adopted.. SIP application-level attack: An attacker may sendfake
BYE, CANCEL, or re-INVITE to terminate asession, cancel an
invitation, or redirect a call [30]. Inthe SeNEMO, such attacks can
be prevented by theproposed SIP authentication mechanism and
Dia-meter SIPApplication (e.g., FlowAinFig. 5 andFlowBin Fig. 8)..
Media security: As mentioned in Section 3.1, theproposed SeNEMO
uses MIKEY to transport DataSA and SRTP to secure real-time
streaming. There-fore, MNs can securely communicate with CNs evenif
staying outside the intranet. Please note SRTPprovides
confidentiality, integrity, and replay pro-tection only for the
application data. The UDP and IPheaders are not protected as that
in IPsec.The comparison of security vulnerabilities in SeNEMOand
IETF MVPN is summarized in Table 2.4 PERFORMANCE ANALYSISIn order
to support secure communication in VPN,signaling messages carrying
security information are sentin the proposed SeNEMO. In addition,
signaling messagesare sent to maintain session continuity during
handoff. Toevaluate the performance of the proposed SeNEMO, it
isimportant to quantify the signaling cost. In this section,
weanalyze the signaling cost of the proposed SeNEMO.Similar to that
in [38], [39], [40], [41], the signaling costfunction comprises
transmission cost and processing cost.The transmission cost is
proportional to the distancebetween the two network nodes. The
processing costincludes the cost to process messages, verify
messages,and so on. The proposed SeNEMO has also been imple-mented.
Details can be found in [23].It is generally agreed that it is
difficult to analyze anetwork mathematically with randomly
connected topol-ogy. Hence, without loss of generality, we develop
an one-dimensional mobility model for handoff. In our
proposedSeNEMO, the Inter-Realm Roaming of a mobile networkincludes
three types of handoff: 1) handoff from intranet(home network) to a
foreign network, 2) handoff from aforeign network to another
foreign network, and 3) handofffrom a foreign network back to the
intranet. They arerepresented as H/), H)), and H)/, respectively.
We assumethat the network topology is configured as that shown
inFig. 13 in which the mobile network returns to the intranet(home
network) after it moves across ` 1 foreign net-works. Hence, when `
is larger, the mobile network travelsfarther away from its home
network before it returns to itshome network. For example, the
handoff sequence can beshown as H/)H))H)) . . . H))H)/. Table 3
lists the para-meters used in the analysis.CHEN ET AL.: SECURE
NETWORK MOBILITY (SENEMO) FOR REAL-TIME APPLICATIONS 1123Fig. 12.
Message flows when mobile network roams from a foreign network back
to home network.For a mobile network, let )it be a general
densityfunction for the network residence time t` in a subnet.
Let1t` 1,. Its Laplace transform is written as:)i: Z 1t0c:t)itdt.We
assume that the arrival of SIP sessions to the mobilenetwork
follows Poisson process with arrival rate `. Theservice time of a
session is exponentially distributed withmean 1,j. Considering the
diagram in Fig. 13, similar tothat in [42], we define ci/ as the
probability when amobile network moves across / subnets between two
eventswhile there are i ongoing sessions in the mobile network.The
event here refers to that a new session arrives or anongoing
session departs from the mobile network. Wedenote toi as the
interval between two consecutive events.During toi there are i
ongoing sessions in the mobilenetwork. Based on the property of
sums of two independentPoisson process, toi can be considered as
the inter arrivaltime of a new Poisson process. Therefore,1toi 1i1`
ij. 0 i < c1ij. i c.8
