ARCHITECTURE FOR BROADBAND AND MOBILE VPN OVER NGN Masahisa 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 crossindustry 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 knowledge from 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 nextgeneration 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 realtime 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

92-61-12441-0/CFP0838E 2008 ITU

Kaleidoscope

First ITU-T Kaleidoscope Academic Conference

enterprise 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.
Enterprise PC VPN GW

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 requirement that 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 requirement that 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 crossindustry 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

Residence Appliance

VPN tunnel

Enterprise Firewall

NGN NGN
Mobile Terminal Office-LAN access

Mobile Terminal Home-LAN access

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

VPN tunnel

HGW VPN GW)

Enterprise Enterprise Network Network

Innovations in NGN Future Network and Services

requiring 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 widearea 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 that QoS 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. Microsofts remote desktop implementation has several functional features for execution over the Internet. For example, low end-to-end throughput can be ameliorated by enabling the 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 a VPN 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. 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 careof 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 packetfiltering 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.

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.

First ITU-T Kaleidoscope Academic Conference

4. 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-homeLAN 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. 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 SIP UA IKE/ IPsec NGN EN

VPN GW SIP UA IKE/ IPsec

UDP-based media path set up by SIP signalling IKE,UDP-encapsulated ESP

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.
Mobile TE NGN EN VPN GW

NGN Core NW

CSCFServer IP NW

RACF Server

ER R Mobile TE Access NW (may be wireless)

ER HGW VPN GW

ER EFW IP NW ESIP

IP IKE/ESP UDP IP

NAPT IP

NAPT IP

IP IKE/ESP UDP IP

home LAN Residence

VPN GW officeLAN Enterprise

stack for VPN data transport

SIP UDP IP SIP UDP IP SIP UDP IP SIP UDP IP

Mobile TE: Mobile Terminal, R: Router, ER: Edge Router, EFW: Enterprise Firewall, ESIP: Enterprise SIP Proxy

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 ESIP from the callee ID, i.e., To

stack for path control

Mobile TE: Mobile Terminal, EFW: Enterprise Firewall, EN: Enterprise Network

Figure 3 Protocol stacks of SIP Dial-Up

Innovations in NGN Future Network and Services

URI, 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.
Mobile TE RACF Server CSCF Server EFW / ESIP VPN GW

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 fivetuple 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 wellknown 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-sharedkey-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 callers SIP-URI.

ERs ERs

SIP INVITE parameters for media path

SIP INVITE SIP INVITE 1st phase admission control SIP response

path set-up border control and QoS allocation

parameters for media path firewall control SIP response 2nd phase admission control

SIP response

IKE over established media path IPsec ESP over established media path

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 bline[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

First ITU-T Kaleidoscope Academic Conference

A 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. 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 about the 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 has a 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.

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.

Mobile TE

ERs ERs

RACF Server

CSCF Server

EFW / ESIP

VPN GW

obtains new IP address SIP REGISTER subscriber authentication SIP response SIP INVITE new IP address path update policy update SIP response SAD update SIP INVITE SAD update SIP response firewall update SIP response

Source address = IP1 Mobile TE UDP packet UDP packet Destination address = IP1

Source address = IP2

NAPT
router

UDP packet UDP packet

NAPT

Destination address = IP2

IP1: IP address assigned to mobile TE, IP2: location-independent lP address bound to IP1

Figure 6: Hand-over of VPN session

Figure 7: Use of NAPT as mobility anchor point

The CSCF server recognizes the address change of the mobile terminal from these SIP messages and prompts the

Innovations in NGN Future Network and Services

5. EVALUATION We evaluate advantages of the proposed method from the viewpoint of the requirements. 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 1: Protection of VPN gateways from malicious traffic The proposed method complements IKE, which is an endto-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 networks 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 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 sessionoriented 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 using typical 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.

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 SIP enables 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

First ITU-T Kaleidoscope Academic Conference

6. 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 method protects 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] [2] [3] [4] [5] [6] [7] [8] [9] Digital Living Network Alliance, http://www.dlna.org Microsoft, Remote Desktop Protocol, Microsoft Developer Network ITU-T, Multipoint application sharing, Recommendation T.128 (1998) ITU-T, Functional requirements and architecture of the NGN release 1, Recommendation Y.2012 (2006) IEEE 802.11 Working Group, http://www.ieee802.org/11/ 3GPP, High Speed Downlink Packet Access (HSDPA); Overall Description; Stage 2 Release 7, TS 25.308 (2006) ITU-T, IMS for Next Recommendation Y.2021 (2006) Generation Network, [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 , RFC4301 (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) [23] ITU-T, Session/border control (S/BC) Recommendation Y.2021 Supplement 1 (2006) functions,

[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)

3GPP, IP Multimedia Subsystem (IMS) Stage 2 Release 8, TS 23.228 (2007) IETF, SIP: Session Initiation Protocol, RFC-3261(2002)

[10] DLNA, DLNA Roadmap, http://www.dlna.org/en/consumer/learn/roadmap