The proposed method creates a channel for VPN communication using SIP signaling, allowing the public network and enterprise networks to perform session-based border control and QoS ma
Trang 1Masahisa Kawashima, Shintaro Mizuno, and Junya Kato
NTT Information Sharing Platform Laboratories
ABSTRACT
We propose a method for broadband mobile VPN over
NGN, which is suitable for office-LAN access by business
users and home-LAN access by consumers The proposed
method creates a channel for VPN communication using
SIP signaling, allowing the public network and enterprise
networks to perform session-based border control and QoS
management In addition, the proposed method achieves
the hand-over of a VPN session using the SIP mobility
approach These features lead to the following advantages
First, the network can protect users' home gateways from
malicious traffic Second, enterprises can separate VPN
gateways from enterprise firewalls and distribute many
VPN gateways for each small segment Third, the network
can perform session-based QoS management Last, the
proposed method enables the mobile terminal to continue a
VPN session while switching access networks These
advantages are valuable when we make emerging high
-speed LAN applications executable over a public wide-area
network
Keywords— NGN, mobility, QoS, VPN
1 INTRODUCTION
The evolution of digital technologies and the market
penetration of high-speed LANs have created new rich
applications in LAN environments One example is the
sharing of digital content among devices on a home LAN
DLNA (Digital Living Network Alliance)[1], a
cross-industry consortium, has been vigorously working to
develop protocols for such purposes The consortium has
already specified the first protocol suite, which enables a
consumer to build a content-sharing environment on his or
her home LAN easily on a plug-and-play basis Another
example of emerging LAN applications is the sharing of a
PC desktop environment, also known as remote desktop,
where the desktop environment of a PC is transferred to
another remote PC over a TCP/IP network For this purpose,
Microsoft has developed remote desktop protocol (RDP)[2],
which is an extension of the ITU-T T.128 protocol[3] As a
possible solution to prevent the leakage of business
knowledgefrom lost PCs, remote desktop has recently been
drawing the attention of many businesses
Users will naturally desire to execute the above LAN
applications over a public wide-area network However,
existing Internet VPN methods have difficulties in fulfilling these demands for the following reasons First, maintaining
a VPN gateway exposed to malicious traffic on the Internet requires a great amount of IT skills and cannot be recommended for ordinary consumers Second, obtaining sufficient end-to-end throughput for bandwidth-consuming applications such as media streaming is sometimes difficult Third, the VPN gateway function cannot be separated from the firewall router at the edge of the enterprise network due
to the lack of a standard hole-punching method This constraint is undesirable, particularly when packets of an application session traverse a large enterprise network, because there may be attacks from inside the enterprise network
In addition, the telecom industry has been developing next-generation networks (NGNs)[4] The NGN has the following features First, the NGN uses the IP (Internet protocol) as its standardized data-transport method and builds a seamless transport network making good use of a variety of access network technologies such as optical fiber, Wi-Fi[5], and 3.x-G mobile[6] Second, the NGN complements the IP transport network with resource and admission control functions (RACF), which control IP transport resources to create an end-to-end data path with the desired QoS Such control includes QoS reservation, NAPT (Network Address Port Translation) binding, and firewall hole punching Typical NGN implementations will build an IP multimedia subsystem (IMS) [7][8], which provides a SIP-based[9] multimedia communication service, making use of RACF These NGN features lead to several advantages in making ubiquitous network services for real-time applications, such as VoIP, more safe and reliable
We consider that the above NGN features are valuable for real-time communication and VPN communication Hence, this paper proposes a mobile VPN communication method, which takes advantage of the above NGN features We show that the proposed method effectively achieves remote VPN communication that can be used to make the emerging LAN applications executable over a public wide-area network
Although remote VPN methods have already been commonly used, our proposed method will increase the variety of prospective applications for the following reasons First, the proposed method makes ordinary consumers prospective users of VPN Second, the proposed method enables a mobile terminal to access a specific segment of an
Trang 2enterprise network as opposed to the whole enterprise
network Third, the proposed method achieves on-demand
QoS reservation and thus improves the applicability of VPN
to applications that require a stable QoS Last, the proposed
method makes use of a variety of network-access
technologies and thus increases the number of occasions
where remote VPN is executable
This paper is organized as follows In section 2, we describe
the usage models of mobile VPN over NGN and derive
requirements In section 3, we summarize related work In
section 4, we describe the proposed method in detail In
section 5, we evaluate the proposed method from the
viewpoint of requirements, comparing the proposed method
with possible alternatives We conclude this paper in
section 6
2 USAGE MODELS AND REQUIREMENTS
2.1 Usage models
As shown in Figure 1, we assume two usage models, which
are home LAN access and office LAN access
NGN
Residence
Appliance
HGW
（VPN GW)
PC VPN GW
Mobile
Enterprise Firewall
Enterprise Network
Enterprise Network Enterprise
NGN
Residence
Appliance
HGW
（VPN GW)
PC VPN GW
Mobile
Enterprise Firewall
Enterprise Network
Enterprise Network Enterprise
Figure 1: Usage models
In home LAN access, a mobile user establishes a VPN
session using the home gateway of his or her home The
VPN session provides the mobile terminal with a logical IP
interface on the IP subnet of the home LAN, enabling the
mobile terminal to interoperate with other devices on the
home LAN An example application is remote access to
digital content stored in a digital VCR on a home LAN
Such an application will typically require relatively high
throughput on the order of Mbps Prospective users of home
LAN access are ordinary consumers
For office LAN access, we assume that VPN gateways are
separated from a firewall router at the edge of an enterprise
network and distributed in the proximity of users This
feature is particularly desirable for a large enterprise network, where the possibility of attacks from inside the enterprise network is not negligible Remote desktop is an office-LAN access application, where a mobile user accesses the desktop environment of his or her PC in the office
In both cases, mobile users make use of a variety of access networks, selecting the best access network depending on his or her current location A mobile terminal may switch between access networks as it moves from one location to another
2.2 Requirements
From the above usage models, we derive the following four requirements:
Requirement 1: Protection of VPN gateways from malicious traffic
The network should provide a safe environment where users can connect their VPN gateways without worrying about malicious traffic because prospective users of home LAN access include ordinary consumers This suggests border control in the network, in which the network restricts packet flows, eliminating malicious traffic
Requirement 2: Separation of VPN gateways from the edge firewall router
There is a requirementthat VPN gateways can be separated from a firewall router at the edge of enterprise networks and distributed in the proximity of users because protection against attacks from inside enterprise networks is also important for office LAN access This suggests the need for firewall traversal of VPN packets
Requirement 3: Reservation of QoS
A mobile terminal should be able to reserve QoS required for an application when a VPN session is set up for a bandwidth-consuming application, such as media streaming and remote desktop
Requirement 4: Hand-over of a VPN session
From the viewpoint of usability, there is a requirementthat
a mobile user can continue an application even when his or her mobile terminal moves between access networks Hence, the hand-over of a VPN session should be supported
3 REVIEW OF EXISTING PROTOCOLS 3.1 Application protocols
Digital Living Network Alliance (DLNA) Guidelines
The Digital Living Network Alliance (DLNA)[1], a cross-industry consortium, published its first guidelines for the sharing of digital content among digital devices on home LANs in 2004 The guidelines intend to allow ordinary consumers to build a content-sharing environment without
Trang 3requiring high-level IT skills For this purpose, the
guidelines specify a service-discovery mechanism that
enables devices to discover services provided by other
devices without requiring a DNS server or a directory
server The guidelines also specify baseline media formats
and media streaming protocols to achieve interoperability
The baseline media format for audio-visual content is
MPEG-2 and its baseline streaming protocol is based on
HTTP
DLNA also published guidelines for complementary
functions in 2006[10] The guidelines add support for QoS
management, which improves robustness and reliability of
media streaming
DLNA is not intended to achieve content sharing across a
wide-area network, so typical DLNA implementations do
not encrypt transferred data In addition, DLNA guidelines
do not specify methods for firewall traversal.Hence, DLNA
should be complemented with methods for security
enhancement and firewall traversal for use across a
wide-area network Furthermore, as exemplified by the addition
of a QoS management option in 2006, QoS management is
desired to maintain robustness and reliability of applications
Hence, there is a requirement thatQoS management across
a wide-area network should be supported for use across a
wide-area network
RDP
ITU-T issued T.120 recommendations[11] as a protocol
suite for multimedia conferencing Among them, the
T.128[3] recommendation described a protocol for
application sharing Microsoft developed RDP[2] 4.0 based
on the T.128 recommendation and later introduced its
upgraded versions Microsoft’s remote desktop
implementation has several functional features for execution
over the Internet For example, low end-to-end throughput
can be amelioratedby enablingthe user to adjust bandwidth
consumption Transferred data can also be encrypted RDP
6.0, which is the most current version, provides a capability
of using an IIS server as an application-level gateway for
firewall traversal However, protecting an RDP session
using aVPN can provide better security because some RDP
implementations are vulnerable to man-in-the-middle
attacks [12] In addition, complementing RDP with QoS
reservation will provide better usability
3.2 IP-VPN protocols
IETF has specified IKE (Internet Key Exchange)[13] and
IPsec[14] for use with IP-VPN IKE is a protocol used
between VPN peers, e.g the VPN client and the VPN
gateway, for security negotiation such as key agreement
IPsec specifies methods of protecting IP packets
cryptographically
IKE is an end-to-end protocol recognized only by VPN
peers, so the network cannot recognize the state change, e.g
start and end, of VPN sessions Hence, implementing session-based border control in the network to protect VPN gateways from malicious traffic is difficult In addition, although IETF also specifies methods for firewall traversal[15][16], the UDP port number of the IKE responder is assumed to be a well-known value, e.g 500 or
4500 Hence, placing many VPN gateways inside an enterprise network and making them addressable from a public network in IPv4 implementations is difficult because each VPN gateway needs a public IP address Furthermore, IKE is an end-to-end negotiation protocol, so extending IKE for use with QoS reservation for a VPN session is difficult If necessary, IKE and IPsec should be complemented with a QoS-reservation mechanism
3.3 Protocols for mobility
IETF has published specifications for mobility support known as mobile IP[17][18] Mobile IP assigns two IP addresses to a mobile terminal One is an ordinary IP address, which is assigned from the subnet where the terminal is currently located This address is called the
care-of address The other address is a virtual address, which is invariant regardless of the current location of the terminal This address is called the home address By establishing an application session with a home address, a mobile terminal can maintain the session without being influenced by a change in the care-of address IP packets destined for a home address are forwarded by a device called a home agent to the associated care-of address Alternatively, a mobile terminal can make a cut-through path with its communication peer by notifying the peer of its current care-of address This is called route optimization
There are some difficulties in combining mobile IP with firewall and QoS management For example, the packet-filtering specification of firewalls should be dynamically updated with the new care-of address in accordance with route optimization Similarly, QoS policies of routers should be updated with the new care-of address However, there is no standard method for these controls
Besides mobile IP, SIP can be used to provide mobility for session-oriented applications [19][20] In this approach, a mobile terminal notifies the peer entity about the change of its IP address by sending a SIP reINVITE request containing its new IP address Then, the peer entity updates the destination address of media flows Typically, SIP messages are exchanged via a SIP proxy in the network Hence, this signaling enables the network to update its packet filter and QoS settings with the new address of the mobile terminal
Trang 44 PROPOSED METHOD: SIP DIAL-UP
4.1 Basic concept
To meet the requirements in section 2, we propose a remote
VPN method called SIP dial-up (We originally presented
the abstract concept of SIP dial-up in [21] for
inter-home-LAN communication.) The basic concept and protocol
stack of SIP dial-up are shown in Figures 2 and 3 SIP
complements IKE and IPsec for session-based border
control and QoS reservation by the network Furthermore,
SIP also facilitates firewall traversal and hand-over of a
VPN session
EN
Mobile
TE
VPN GW NGN
UDP-based media path
set up by SIP signalling
IKE,UDP-encapsulated ESP
SIP UA
SIP
UA
IKE/
IPsec
IKE/
IPsec
Mobile TE: Mobile Terminal, EN: Enterprise Network
EN
Mobile
TE
VPN GW NGN
UDP-based media path
set up by SIP signalling
IKE,UDP-encapsulated ESP
SIP UA
SIP
UA
IKE/
IPsec
IKE/
IPsec
Mobile TE: Mobile Terminal, EN: Enterprise Network
Figure 2: Basic concept of SIP Dial-Up
VPN peers, i.e., a VPN client and a VPN gateway, first
have a UDP-based media path established by the network
with a SIP request Then, they start exchanging IKE and
IPsec ESP data over the UDP-based media path For this
purpose, IPsec ESP is encapsulated into UDP packets, as
specified in [16]
To achieve firewall traversal, SIP proxy servers of
enterprises reside at the edge of enterprise networks and
dynamically update the filtering policy of firewalls based on
the state change, e.g., start and end, of SIP sessions In other
words, SIP proxy servers of enterprises combined with
firewall routers act as session border controllers (SBC)[23]
at the edge of enterprise networks
IP
UDP
IKE/ESP
IP
Mobile
NAPT
IP UDP
IP
UDP
SIP
IP UDP SIP
IP UDP SIP
IP UDP SIP
stack for path control stack for VPN data transport
Mobile TE: Mobile Terminal,
EFW: Enterprise Firewall, EN: Enterprise Network
NAPT IP
UDP
IKE/ESP
IP
IP
UDP
IKE/ESP
IP
Mobile
NAPT
IP UDP
IP
UDP
SIP
IP UDP SIP
IP UDP SIP IP UDP SIP
IP UDP SIP
stack for path control stack for VPN data transport
Mobile TE: Mobile Terminal,
EFW: Enterprise Firewall, EN: Enterprise Network
NAPT
Figure 3 Protocol stacks of SIP Dial-Up
4.2 Network architecture
The network architecture for the proposed method is shown
in Figure 4
Mobile terminals (Mobile TE) have SIP UA, IKE initiator, and IPsec capabilities VPN gateways (VPN GW) have SIP
UA, IKE responder, and IPsec capabilities For home LAN access, a VPN gateway is integrated with a home gateway For office LAN access, VPN gateways are separated from a firewall router at the edge of an enterprise network, and they may be distributed in the proximity of users
An enterprise SIP proxy (ESIP) mediates SIP messages between the CSCF (call/session control function) server and VPN gateways and updates the packet filtering spec of the enterprise firewall so that media paths belonging to SIP sessions can pass the firewall
Edge routers (ER), which correspond to ABG-FE (Access Border Gateway Functional Entity) in the NGN FRA (Functional Requirements and Architecture) model [4], should have a packet-filtering function To protect user devices from malicious traffic, they are configured not to forward packets between users by default
The CSCF server, which corresponds to P-CSC-FE (Proxy Call Session Control Functional Entity) and S-CSC-FE (Serving Call Session Control Functional Entity) in the NGN FRA model, mediates SIP messages between user devices, which may be mobile terminals, home gateways, or ESIP servers, as a SIP proxy and prompts RACF to create media paths for established sessions
The RACF server updates the packet-forwarding policy of edge routers to create media paths with the desired QoS
Mobile TE: Mobile Terminal, R: Router, ER: Edge Router, EFW: Enterprise Firewall, ESIP: Enterprise SIP Proxy
NGN Core NW CSCFServer
Residence
HGW
home LAN
Enterprise
ESIP
IP NW
officeLAN
R
Access NW (may be wireless)
ER
Mobile
VPN GW
ER
IP NW
ER EFW RACF Server
Mobile TE: Mobile Terminal, R: Router, ER: Edge Router, EFW: Enterprise Firewall, ESIP: Enterprise SIP Proxy
NGN Core NW CSCFServer
Residence
HGW
home LAN
Enterprise
ESIP
IP NW
officeLAN
R
Access NW (may be wireless)
ER
Mobile
VPN GW
ER
IP NW
ER EFW RACF Server
Figure 4: Network architecture
A unique SIP-URI is assigned to each mobile terminal or VPN gateway The CSCF server should be capable of authenticating SIP-URIs of mobile terminals in SIP messages and resolving an ESIPfrom the callee ID, i.e., To
Trang 5URI, in a SIP INVITE request An ESIP server should be
capable of authenticating SIP-URIs of VPN gateways
In this paper, we assume that the data transport network is
based on IPv6 However, it may be based on IPv4 because
SIP signaling can be used to dynamically create NAPT
bindings to alleviate the shortage of IPv4 addresses
4.3 System Dynamics
4.3.1 Establishment of VPN session
The message sequence for the establishment of a VPN
session is shown in Figure 5 The following are
preconditions for this message sequence The mobile
terminal and the ESIP server should have registered
themselves with the CSCF server, and the VPN gateway
should have registered itself with the ESIP server In home
LAN access, a home gateway acts as the equivalent for the
enterprise firewall, ESIP, and VPN gateway
SIP response
SIP response
parameters for
media path
parameters for media path
IKE over established media path
IPsec ESP over established media path
1st phase admission control
firewall control
2nd phase admission control
border control
and QoS allocation
SIP response
path
set-up
Mobile
ERs
EFW / ESIP
VPN GW
RACF Server
SIP response
SIP response
parameters for
media path
parameters for media path
IKE over established media path
IPsec ESP over established media path
1st phase admission control
firewall control
2nd phase admission control
border control
and QoS allocation
SIP response
path
set-up
Mobile
ERs
EFW / ESIP
VPN GW
RACF Server
Figure 5: Establishment of VPN session
The mobile terminal and the VPN gateway first set up a SIP
session with a UDP media path by exchanging SIP
messages by way of the CSCF server and the ESIP server
This is performed using an ordinary SIP INVITE message
sequence with the following features The m-line[22] of the
INVITE request should include the IP address and UDP
port number that the mobile terminal uses for IKE and
UDP-encapsulated IPsec ESP communication The
b-line[22] of the request should include QoS parameters The
response to the INVITE request should include the IP
address and UDP port number that the VPN gateway uses
NAPT may optionally be inserted in the middle of the
media path In that case, the SIP proxy that decides to insert
NAPT should re-write the c-line and m-line of SIP messages with the bound IP address and port number The CSCF server and the RACF server handle the requested session in the same manner as they handle real-time communication sessions They perform session-based border control [23] and QoS reservation for the requested session To elaborate, the CSCF server obtains the five-tuple key (the IP address and port number of each of the two end-points and the protocol type) and QoS parameters from the SIP INVITE messages and prompts the RACF server to update the packet forwarding policy of edge routers so that packets with the five-tuple key are forwarded with the declared QoS In this way, the network performs session-based border control to protect home gateways from malicious traffic and QoS management to improve the stability of applications
Similarly, enterprise networks perform session-based border control for firewall traversal To elaborate, the ESIP server obtains the five-tuple key from the SIP INVITE messages and updates the filter spec of the enterprise firewall so that the enterprise firewall forwards packets with the five-tuple key In this way, a media path traversing an enterprise firewall is established for VPN communication
It is worth noting that the network and enterprise networks
do not have to recognize VPN-specific parameters used for the mechanisms mentioned above Hence, the CSCF and RACF functions for other SIP-based communications such
as VoIP, can also be used for the proposed VPN method The VPN gateway performs admission control in two phases The first admission control is performed on the basis of the caller's SIP-URI, when the VPN gateway receives the SIP INVITE request The second admission control is IKE authentication, which is executed after session set-up This two-phase approach enables VPN peers
to detect an attack compromising identities in SIP signaling Once the session is set up, the mobile terminal and the VPN gateway start exchanging IKE and UDP-encapsulated IPsec ESP (Encapsulating Security Payload) data over the established media path Although the IKE standard specifies that the UDP port number of the IKE responder is a well-known value, the proposed method requires the mobile terminal to send IKE messages to the UDP port number specified in the SIP INVITE response message
In IKE authentication, the VPN peers should use identifiers other than the IP address because IP addresses of mobile terminals are not static Another reason is that an IP address cannot identify a VPN entity when NAPT is used by the network or enterprise firewalls A method for IKE authentication may be either X.509-based or pre-shared-key-based In case authentications are based on pre-shared keys, a mobile terminal or a VPN gateway may have a different key for each peer, and the key to be used is determined on the basis of the caller’s SIP-URI
Trang 6A method for the distribution of IKE authentication
credentials, such as X.509 certificates and pre-shared keys,
is outside the scope of this paper but is an issue for further
study That method should be sufficiently easy to
accommodate unskillful users At the same time, that
method should not be dependent on SIP signaling to
maintain the benefit of the two-phase admission control
Alternatively, if we were to sacrifice two-phase admission
control for the sake of usability, a possible approach would
be to embed a key-exchange protocol in SIP SDP [24] to
generate a pre-shared key for IKE authentication This
approach would provide better usability because users are
not required to install IKE credentials
4.3.2 Hand-over of VPN session
(a) Basic Procedure
VPN peers can accomplish the hand-over of a VPN session
using SIP re-INVITE messages As shown in Figure 6, this
is an ordinary sequence for SIP mobility[19] with the
following feature: the VPN gateway recognizes the address
change of the mobile terminal from the re-INVITE message
and updates its security association database (SAD) with the
new address
EFW / ESIP
Mobile
SIP response
SIP response
SIP response
new IP address
SAD update
firewall update policy update
SIP REGISTER
SIP response
obtains new IP
address
SAD update
ERs
RACF Server
subscriber authentication
path
update
EFW / ESIP
Mobile
SIP response
SIP response
SIP response
new IP address
SAD update
firewall update policy update
SIP REGISTER
SIP response
obtains new IP
address
SAD update
ERs
RACF Server
subscriber authentication
path
update
Figure 6: Hand-over of VPN session
The CSCF server recognizes the address change of the
mobile terminal from these SIP messages and prompts the
RACF server to update the filter specs and QoS policies of routers with the new address The enterprise firewall similarly updates the UDP hole with the new address In this manner, the mechanisms for border control, QoS management, and firewall traversal, can remain updated aboutthe address change of the mobile terminal
When NAPT is inserted in the middle of the media path, the SIP proxy that manages the NAPT should update its binding with the new address
(b) Micromobility with NAPT as mobility anchor point
When a VPN session has a long round-trip delay, inserting
a NAPT between the end-points of the media path is advantageous Such a NAPT should be performed by routers in the core network The inserted NAPT functions as
a mobility anchor point (MAP) This idea was originally presented by Schulzrinne and Wedlund in [20]
As shown in Figure 7, the NAPT binds the IP address and UDP port number that the mobile terminal uses with another pair of IP address and UDP port number The bound IP address and UDP port number should be stable, in the sense that they do not change even when the mobile terminal changes its address The CSCF server replaces the
IP address and port number in the SIP INVITE request with the bound IP address and port number
The NAPT binding is updated by the CSCF server and the RACF server in accordance with the address change of the mobile terminal This update process hasa message transfer delay from the mobile node and the CSCF server, so implementing the CSCF server with a cloud of distributed CSCF servers could shorten the hand-over delay
This method achieves fast hand-over for a long-haul VPN session Furthermore, another advantage is that this method achieves hand-over without involving the enterprise firewall and VPN gateways
Mobile TE
IP1: IP address assigned to mobile TE, IP2: location-independent lP address bound to IP1
router NAPT
UDP packet
UDP
UDP packet
Source address = IP1
NAPT Destination address = IP1
Source address = IP2
Destination address = IP2
Mobile TE
IP1: IP address assigned to mobile TE, IP2: location-independent lP address bound to IP1
router NAPT
UDP packet
UDP
UDP packet
Source address = IP1
NAPT Destination address = IP1
Source address = IP2
Destination address = IP2
Figure 7: Use of NAPT as mobility anchor point
Trang 75 EVALUATION
We evaluate advantages of the proposed method from the
viewpoint of the requirements
Requirement 1: Protection of VPN gateways from
malicious traffic
The proposed method complements IKE, which is an
end-to-end protocol, with SIP implemented as a user-to-network
protocol to enable session-based border control by the
network Hence, the network provides users with a safe
environment where only packets for admitted sessions
arrive besides SIP signaling packets A user is protected
from malicious SIP signaling because SIP messages are
delivered by way of the network’s CSCF server
Furthermore, phase 1 admission control effectively reduces
attacks on IKE/IPsec functions However, this depends on
the authenticity of caller ID in SIP signaling Therefore,
there is a requirement that NGN assure the authenticity of
caller ID
Some may argue that this session-oriented approach
sacrifices the advantages of the IP, a connectionless
protocol We admit that five-tuple-based packet-flow
control is a burden on routers and degrades the scalability
of a network However, we consider that the advantage of
network safety outweighs the burden because it creates
opportunities to increase the number of ordinary users of a
VPN Furthermore, when the network does not perform
session-based border control, the proposed method enables
home gateways and ESIP servers to perform session-based
border control and thus helps users eliminate malicious
traffic Hence, the proposed method is still valid even when
we take a design approach to favor connectionless network
control
Requirement 2: Separation of VPN gateways from an edge
firewall router
In the proposed method, the introduction of SIP yields the
following advantages that allow VPN gateways to be
separated from enterprise firewalls
First, the introduction of SIPenables an enterprise firewall
to open and close pinholes dynamically, recognizing the
state change of VPN sessions Second, the indication of
destination, i.e., VPN gateway, is first carried out using a
SIP-URI in a SIP request, so a VPN gateway does not need
a global IP address This is advantageous in an IPv4
implementation Third, a two-phase admission control is
achieved, enabling VPN gateways to restrict incoming
sessions at SIP signaling before receiving IKE messages
By contrast, if we were to separate VPN gateways from an
enterprise firewall using the conventional IKE/IPsec
method, a global IP address should be assigned to each
VPN gateway and mapped to its local IP address at the
firewall Hence, in an IPv4 implementation, placing many VPN gateways is difficult
Another feature of the proposed method is that it performs
an end-to-end authentication and protection using IKE and IPsec Therefore, even if SIP messages are compromised in
an enterprise network, the VPN peers can detect such attacks using the end-to-end authentication
Requirement 3: Reservation of QoS
The proposed method enables the network to perform session-based QoS management by recognizing the requested QoS from SIP messages
There may be an alternative approach such as the introduction of RSVP to complement IKE and IPsec for QoS reservation However, we would like to argue that if the NGN were to implement SIP-based QoS management for VoIP and other real-time communication, naturally, we may want to apply the same mechanism to other session-oriented communication including remote VPN
Requirement 4: Hand-over of VPN session
The proposed method achieves the hand-over of IPsec security association (SA) by enabling a mobile terminal to notify its peer entity about its address change using SIP messages The basic hand-over procedure achieves route optimization by avoiding triangular routing The scheme using a NAPT as a MAP achieves fast hand-over, which is effective for a long-haul VPN session
One alternative is to adopt the mobile IP In mobile IPv6, VPN peers continue security associations without being affected by the change of IP address[25] Hence, both approaches are valid, and they share some similarities For example, route optimization in mobile IP is equivalent to the address update procedure using SIP reINVITE messages Binding update to the home agent in mobile IP is similar to the address registration procedure using SIP REGISTER messages However, the SIP REGISTER procedure does not affect media flows In addition, both approaches introduce MAPs
In terms of hand-over delay, mobile IP may be advantageous because binding update to home agent does not need re-authentication of a mobile terminal in mobile IPv6, while the SIP REGISTER procedure involves authentication In addition, as reported in [26], the mobile IPv6 function can be implemented in the kernel, so mobile IPv6 is likely to outperform SIP mobility when usingtypical implementations However, we consider that further investigation including experiments should be conducted to evaluate the significance of this difference If both approaches could satisfy a tolerance of hand-over delay, the difference is negligible
Trang 86 CONCLUSION
We have presented a mobile VPN method that makes use of
the NGN CSCF and RACF capabilities and yields the
following advantages First, the proposed mobile VPN
methodprotects consumers' home gateways from malicious
traffic by enabling the network to perform session-based
dynamic packet filtering Second, VPN gateways are
allowed to be separated from an enterprise firewall router
by enabling enterprise networks to create a channel that
traverses a firewall dynamically Third, QoS reservation for
applications that require stable QoS is achieved Last, VPN
peers are enabled to continue a VPN session without being
affected by the change of IP address
The above advantages of the proposed method enable
innovation in the variety of applications that use VPN
communication by increasing the number of ordinary VPN
users and giving more freedom to the location of VPN
gateways
A performance evaluation of the proposed method remains
as future work
Standardization work that intends to make the proposed
method work with the global inter-operability of NGN
carriers will be beneficial Such work includes the definition
of SDP m-line and a MIME type[22] that represents the
proposed method We should also define a supported subset
of IKE/IPsec parameters and a method for the distribution
of IKE authentication credentials
In addition, although the proposed method uses IPsec as a
protocol between the VPN peer entities, we may also use
UDP-encapsulating version of other protocols such as
PPP[27] and EtherIP[28] In order to avoid unnecessary
variation of protocols and secure interoperability, we need
standardization work that defines a set of end-to-end
protocols for mandatory support
REFERENCES
[1] Digital Living Network Alliance, http://www.dlna.org
[2] Microsoft, Remote Desktop Protocol, Microsoft Developer
Network
[3] ITU-T, Multipoint application sharing, Recommendation
T.128 (1998)
[4] ITU-T, Functional requirements and architecture of the
NGN release 1, Recommendation Y.2012 (2006)
[5] IEEE 802.11 Working Group, http://www.ieee802.org/11/
[6] 3GPP, High Speed Downlink Packet Access (HSDPA);
Overall Description; Stage 2 Release 7, TS 25.308 (2006)
Recommendation Y.2021 (2006)
[8] 3GPP, IP Multimedia Subsystem (IMS) Stage 2 Release 8,
TS 23.228 (2007)
[9] IETF, SIP: Session Initiation Protocol, RFC-3261(2002)
http://www.dlna.org/en/consumer/learn/roadmap
[11] ITU-T, Data protocols for multimedia conferencing, Recommendation T.120 (1997)
[12] SecuriTeam, Microsoft RDP Man in the Middle Vulnerability,
http://www.securiteam.com/windowsntfocus/5EP010KG0G html (2005)
[13] IETF, Internet Key Exchange (IKEv2) Protocol, RFC-4306 (2005)
[14] IETF, Security Architecture for the Internet Protocol ,
RFC-4301 (2005) [15] IETF, Negotiation of NAT Traversal in the IKE, RFC-3947 (2005)
[16] IETF, UDP Encapsulation of IPsec ESP Packets, RFC-3948 (2005)
[17] IETF, IP Mobility Support for IPv4, RFC-3344 (2002) [18] IETF, Mobility Support in IPv6, RFC-3775 (2004) [19] E Wedlund and H Schulzrinne, Mobility Support using SIP, WOWMOM 1999 (1999)
[20] H Schulzrinne and E Wedlund, Application-Layer Mobility Using SIP, Mobile Computing and Communications Review, Volume 4, No 3
[21] T Haruyama, S Mizuno, M Kawashima, and O Mizuno, Dial-to-Connect VPN System for Remote DLNA Communication, Proc of CCNC 2008 (to appear)
[22] IETF, SDP: Session Description Protocol, RFC-4566 (2006)
Recommendation Y.2021 Supplement 1 (2006) [24] J Arkko, F Lindholm, M Naslund, K Norman, E Carrara, Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol, IETF RFC-4567 (2006)
[25] IETF, Using IPsec to Protect Mobile IPv6 Signalling Between Mobile Nodes and Home Agents, RFC-3776 (2004)
[26] N Nakajima, A Dutta, S Das, and H Schulzrinne, Handoff Delay Analysis and Measurement for SIP based mobility in IPv6, Proc of International Parallel and Distributed Process Symposium(2003)
[27] IETF, The Point-to-Point Protocol (PPP), RFC-1661 (1994) [28] IETF, EtherIP: Tunneling Ethernet Frames in IP Datagrams, RFC-3378 (2002)