On-Demand VPN Service between Home Networks for NGN Users

Transcription

1 On-Demand VPN Service between Networks for NGN Users Tsuyoshi Abe, Shintaro Mizuno, Takahiro Haruyama, Hitomi Chiba, and Osamu Mizuno NTT Information Sharing Platform Laboratories, Nippon Telegraph and Corp Midori-cho, Musashino-shi, Tokyo , Japan Abstract We propose an on-demand VPN service for home NGN users. This service enables users to connect home s without setting up complex network configurations. Users can specify a destination by dialing a telephone number on an ordinary telephone terminal. We developed prototype residential gateways to provide the on-demand VPN service. The gateways find the IP es of peer gateways and suitable port numbers for VPN establishment from telephone numbers by. We also implemented a remote consumer electronics cooperation on the gateways so users can show videos on their video recorders to people at other locations. We conducted a usability test of our on-demand VPN system and obtained positive feedback from the users. 1 Introduction Several bearer services such as high-quality audio-video communications, IP television, and fixed-mobile convergence (FMC) are considered as Next-Generation Network (NGN) [1] services. However, end-to-end data services for the NGN have not been discussed very much. Increasing numbers of digital devices are connected on home s and office s. Therefore, we consider that a data transfer service over different s for NGN users is needed. We also think easy-to-use operation is very important for home NGN users. In this paper, we propose a new on-demand virtual private network (VPN) service for home NGN users. Users can connect their home s by simply dialing a telephone number on an ordinary telephone terminal. Users do not have to set up complex network configurations, which are usually required to establish VPNs. To provide this VPN service, we have developed residential gateways, which can establish an IPsec tunnel over a network (Figure 1). We tested the gateways at NTT's NGN field trials in the fall of 2007, and they worked well. We have also conducted a usability test. In the next section, we will present applications of on-demand VPN for the home. In section 3, we will describe the details of the method of our proposed service. In section 4, we will show our prototype system and results of the usability test. 2 Applications 2.1 Remote Consumer Electronics Cooperation Many consumer electronic devices are connected to home s. For example, Digital Living Network Alliance (DLNA)-capable consumer electronics devices enable home users to enjoy video programs recorded on a digital video recorder from a television located in another room [2]. Our on-demand VPN system enhances this electronics cooperation to apply over different home s. For example, by using our system, a grandmother can watch on her own television her grandchildren's video played on the video recorder at her son s home through on-demand VPN by simply dialing her son s home telephone number. 2.2 Digital Photo Frames Recently, digital photo frames (DPFs) have become popular devices among home users. Some models have network connectivity and can download photos from PCs or web sites and display those photos on its screen. Users may be able to display their photos on a remote friend s DPF by using our on-demand VPN system. 2.3 Remote Offices Our on-demand VPN system, like ordinary VPN systems, is also suitable for office use. In particular, our system can support telework by connecting teleworkers home s and office s. The office gateway can store a list of employees' telephone numbers to allow VPN connection from authorized users only. Hard disk recorder PC Connect home s NGN Remote access to office Office Office TV Digital Photo Frame Servers Figure 1: Usage scenes

2 Using telephone terminal as a user interface terminal Residential Telephony engine UA VPN WAN server network Peer Consumer electronics device PC Application Peer Office Figure 2: Components of proposed VPN system 3 Proposed Method of Service 3.1 Components Components of our proposed method are shown in Figure 2. On-demand VPN is established by a residential gateway. The gateway has two network interfaces and one telephone interface. (1) interface One network interface is connected to a home. The gateway has a DHCP and allocates private IP es to devices on the home. (2) WAN interface The other network interface is connected to a public network such as the NGN. A global IP is allocated to this interface by a public network. messages are sent to and received from a server through this interface. (3) interface The gateway also has a telephone terminal interface, so telephones and ordinary analog telephone terminals can be used as user interfaces. The gateway consists of the following four principal components. (1) Telephony engine When users talk on telephones connected to the gateway, the users can establish VPN connection with a peer by inputting a special code using their telephone terminals. Users can also start a VPN connection by using their telephone terminal to dial a peer s telephone number with a special prefix. (2) user agent (UA) Ordinary telephone calls and VPN requests are notified to a peer s gateway via a server by. (3) VPN After a session for VPN has been established between gateways by, a is established by IPsec using Internet Key Exchange version 2 (IKEv2) [3]. (4) Application When s are connected by a, the applications described in section 2 can be used. However, DLNA protocol is restricted to one, so a DLNA proxy is needed to enable remote consumer electronics devices to cooperate. 3.2 Features Our method uses to establish a VPN connection. By using, we can obtain the following three features. (1) number-based ing and authorization Users do not have to know the IP of a peer's gateway. A caller can enter a peer's telephone number as if he or she were making a telephone call. The caller's telephone number is sent to the callee, who can decide to accept or reject the connection after seeing the number. Users can also store a telephone number white list on the gateway to automatically authorize specific requested VPN connections. (2) Suitable for on-demand connection network services Using the capability, users can request bandwidth from a network and/or QoS classes, which are needed for each on-demand VPN connection. Network

3 operators can obtain session statements and logs of each VPN connection for accounting purposes. (3) Usable for managed networks There are some commercially managed networks such as the NGN where end users cannot connect to each other directly without using. In our proposed method, first, end users negotiate IP es, ports, and the protocol (5-tuple) through a server, so a managed network controls edge routers to transfer VPN packets. 3.3 User Experience In this subsection, we will describe the behavior of our on-demand VPN system from a user s point of view. First, the user (caller) makes a telephone call to another user (callee) from a telephone terminal connected to a residential gateway. The callee answers the call, and they talk about the caller s vacation trip. The callee would like to watch a video recorded by the caller during the trip. At that point, the caller enters a special code by pushing buttons on his/her telephone terminal to make a VPN request to the peer to whom he/she is currently talking. The callee enters a special code by pushing buttons on his/her telephone terminal to permit the VPN request. As a result, their home s are connected. After that, the caller plays a video of his/her vacation trip for the callee and the callee can watch the video on his/her television through the network. 3.4 Typical Sequence Flow The typical sequence flow of our proposed method, consisting of three phases, is shown in Figure 3. (1) Phase 1: call establishment This sequence flow is the same as an ordinary IP phone sequence using. Users can authenticate each other during a conversation. (2) Phase 2: VPN establishment by During the conversation in phase 1, users can request a VPN connection by entering a special sequence of numbers by pushing a telephone terminal's buttons. Then, the gateway makes another call to establish a VPN connection to the same IP as that of the voice connection in phase 1. If the callee permits the request by entering a special code, the VPN connection is established. (3) Phase 3: Application start up After the VPN establishment, the application phase starts. For example, DLNA proxies are started at each gateway to transfer DLNA protocols over the two s. This three-phase sequence flow is only an example. Phase 1 can be skipped, and users can immediately start at phase 2. In that case, users enter a peer's telephone number with a special prefix code so that the gateway can recognize that the call is a VPN request and not a voice call. Phase 1: call establishment server terminal Gateway Gateway Dial oooo m=audio RTP/AVP Voice connection establishment m=audio RTP/AVP Ring Off-hook terminal Phase 2: VPN establishment Phase 3: Application start up VPNrequest (enter special code) m=application udp Start IKE with the information from SDP IKEv2 negotiation Start DLNA proxy with peer s IP Mutual authentication DLNA proxy start up L3 tunnel DLNAprotocol transfer m=application udp Remote consumer electronics cooperation example Start IKE with the information from SDP Mutual authentication DLNA proxy start up Enter special code to permit the request Start DLNA proxy with peer s IP Figure 3: Typical sequence flow

4 Source Destination Source translation Destination translation Gateway In Source: Destination: Gateway Send packets from to Figure 4: Bi-directional NAT Receive packets from at Technical Aspects In this subsection, we will explain our efforts to solve some technical issues. (1) Media channel for Two media channels are established between gateways during typical usage such as that described in section 3.4. The first channel is an audio channel for telephone conversation, and the second one is a channel for a. A receiving side gateway can distinguish the media type by recognizing an m= line in a session description protocol (SDP) message. (2) UDP encapsulation for IPsec to pass through NGN Edge routers in the NGN determine whether to pass or block IP packets by the source and destination IP es, ports, and the protocol (5-tuple), all of which are negotiated by. Therefore, edge routers cannot control IPsec packets as normal because IPsec hides the transport layer. We decided to encapsulate IPsec packets by UDP so that an edge router can control IPsec packets as it does other TCP or UDP packets. The method of UDP encapsulation for IPsec that we use was originally specified for the purpose of NAT traversal [4]. (3) Bi-directional NAT to avoid duplicate private IP If gateways connect private s, there is a possibility that the same private es are used in each. We solved this problem by using bi-directional NAT () [5]. In Figure 4, the source and destination s use the same network ( /24). When those s are connected by our on-demand VPN system, the source s network is translated to /24 for the, and the destination s network is translated to /24 for the source. 4 Implementation and Evaluation 4.1 Prototype Gateway We have developed prototype gateways to achieve our method described above. We implemented the gateways on Linux PCs (Figure 5, and Figure 6). The correspondence relationship between software modules and the sequence phases described in subsection 3.4 is shown in Figure 5. Phase 1 Phase 2 Phase 3 manager Telephony engine (Asterisk [6]) Legend: UA for VPN VPN Linux Ethernet for WAN Our developed software Open source software Interface External application invoker IKEv2 (Racoon2 [7]) IPsec Figure 5: Gateway architecture DLNA proxy Java VM Ethernet for Related phase Figure 6: Prototype gateway

5 Table 1: Attributes of subjects Sex Age IT skill Number of people Family composition Group 1 Female 30s-50s Able to use PC for 8 Each group includes a basic purpose one-person household. Group 2 Male 20s-40s Able to set up 4 Others are nuclear home network households. Group 3 Have knowledge 4 2/3 people live far about VPN from the households of their parents or children. Consumer electronics (CE) skill All the people often use the CEs below Fixed telephone Television Hard disk recorder Digital camera We used an open source telephony engine for phase 1. This is already implemented in VoIP gateways on the market. The UA for VPN is our developed software module for phase 2 and is the main component in the prototype gateway. When a user enters a special sequence of numbers for a VPN call, the UA for VPN detects this user operation through a telephony engine and a telephone manager. Then the UA makes a call for VPN by issuing a INVITE request. If the call is accepted by the peer, a VPN is invoked to exchange keys for IPsec by IKEv2 protocol. When the gateway receives an incoming call for VPN, the UA analyzes the message, responds to the peer, and invokes a VPN. We also implemented a DLNA proxy for an example of a phase 3 application. The DLNA proxy is invoked by the UA for VPN through an external application invoker. A detailed description of our DLNA proxy is in Ref.[8]. 4.2 Usability Test We conducted a usability test of our VPN system. Sixteen people aged in their 20s to 50s were surveyed (Table 1). They used our prototype system and experienced a remote consumer electronics cooperation service. Then we interviewed them about the operability of our system and acceptability of the service. All of them stated that using a telephone terminal to connect remote s is user-friendly. Furthermore, all the people who knew about VPN (group 3) preferred our system to the traditional way of setting up gateways. Regarding the acceptability of the service, around 90% of the subjects wanted to use this service for communicating with remote family. Around 50% wanted to use this service for communicating with friends. There was no remarkable difference in the responses among the three groups. 5 Conclusion In this paper, we proposed an on-demand VPN service for NGN users. This service enables users to connect home s without setting up complex network configuration. Users can specify a destination by dialing a telephone number on an ordinary telephone terminal. Users can enjoy remote consumer electronics cooperation across the NGN by our on-demand VPN service. We developed prototype gateways to provide this VPN service by establishing an IPsec tunnel using. Sixteen people tested the operability and acceptability of our service. All of them said that this system is easy to use, and 90% want to use this service for communicating with remote family. Thus, we experimentally showed that our proposed service has easy operation and many applications for home users. References [1] ITU-T, Functional requirements and architecture of the NGN release 1, ITU-T Recommendation Y.2012, [2] Digital Living Network Alliance, DLNA Overview and Vision Whitepaper, 2006, [3] IETF, Internet Key Exchange (IKEv2) Protocol, RFC4306, 2005, [4] IETF, UDP Encapsulation of IPsec ESP Packets, RFC3948, 2005, [5] IETF, IP Network Address Translator (NAT) Terminology and Considerations, RFC2663, 1999, [6] Digium, Inc, Asterisk : The Open Source PBX & Telephony Platform, [7] The Racoon2 Project, [8] T. Haruyama, S. Mizuno, M. Kawashima, and O. Mizuno, Dial-to-Connect VPN System for Remote DLNA Communication, in the proceedings of CCNC 2008.