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 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, 92-61-12441-0/CFP0838E © 2008 ITU 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 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 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 Appliance VPN tunnel Enterprise Firewall VPN tunnel Enterprise Enterprise Network Network HGW （VPN GW) NGN NGN Mobile Terminal Home-LAN access 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 VPN GW Residence 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 Mobile Terminal Office-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 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 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 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 not encrypt transferred data In addition, DLNA guidelines 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 Microsoft’s 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 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 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 First ITU-T Kaleidoscope Academic Conference 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 and 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 VPN GW Mobile TE SIP UA IKE/ IPsec EN NGN SIP UA UDP-based media path set up by SIP signalling IKE,UDP-encapsulated ESP 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 Mobile TE NGN EN VPN GW 4.2 Network architecture The network architecture for the proposed method is shown in Figure 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 NGN Core NW CSCFServer IP NW ER NAPT IP NAPT IP IP IKE/ESP UDP IP stack for VPN data transport SIP UDP IP SIP UDP IP SIP UDP IP SIP UDP IP stack for path control Mobile TE: Mobile Terminal, EFW: Enterprise Firewall, EN: Enterprise Network Figure Protocol stacks of SIP Dial-Up ER ER R HGW VPN GW IP IKE/ESP UDP IP RACF Server Mobile TE Access NW (may be wireless) EFW IP NW ESIP home LAN VPN GW officeLAN Residence Enterprise 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 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 NAPT should re-write the c-line and m-line of SIP messages with the bound IP address and port number 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 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 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 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 ERs ERs RACF Server CSCF Server SIP INVITE parameters for media path EFW / ESIP VPN GW SIP INVITE SIP INVITE 1st phase admission control SIP response path set-up border control and QoS allocation SIP response parameters for media path firewall control SIP response 2nd phase admission control 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 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 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 caller’s SIP-URI 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 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 new IP address SAD update firewall update policy update (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 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 SIP INVITE SIP response path update 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 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 SIP response SIP INVITE 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 SIP response SIP response SAD 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 Source address = IP1 Mobile TE UDP packet Source address = IP2 NAPT UDP packet router UDP packet Destination address = IP1 NAPT UDP packet Destination address = IP2 IP1: IP address assigned to mobile TE, IP2: location-independent lP address bound to IP1 Figure 7: Use of NAPT as mobility anchor point Innovations in NGN – Future Network and Services 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 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 network’s CSCF server Furthermore, phase 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 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 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 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 First ITU-T Kaleidoscope Academic Conference 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 [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 [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 (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) [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 Release 7, TS 25.308 (2006) [7] ITU-T, IMS for Next Recommendation Y.2021 (2006) [8] 3GPP, IP Multimedia Subsystem (IMS) Stage Release 8, TS 23.228 (2007) [9] IETF, SIP: Session Initiation Protocol, RFC-3261(2002) Generation Network, [10] DLNA, DLNA Roadmap, http://www.dlna.org/en/consumer/learn/roadmap [28] IETF, EtherIP: Tunneling Ethernet Frames in IP Datagrams, RFC-3378 (2002) ... 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... Figures and 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 VPN. .. TE NGN EN VPN GW 4.2 Network architecture The network architecture for the proposed method is shown in Figure Mobile terminals (Mobile TE) have SIP UA, IKE initiator, and IPsec capabilities VPN