Cost of deploying new technologies

Transcription

1 Cost of deploying new technologies Erkka Honkavaara Helsinki University of Technology Abstract The current Internet is very different from how it was originally designed. These changes have brought new challenges to its architecture for which different solutions have been devised. In this paper I go through some of these solutions, namely i3, HIP, NUTSS, NSIS and Mobile IP, and changes they require on current systems. I will evaluate their differences and similarities in respect to the cost of deploying them. Currently HIP looks promising due to its many features and legacy support(both IPv4 and IPv6), which lowers the cost of deployment radically. KEYWORDS: i3, HIP, NUTSS, NSIS, Mobile IP, Cost of deployment 1 Introduction The Internet has become very different from what it was in its early years. Advancements in technology have made small and mobile connected devices commonplace. Moreover, mobility is not limited only to single devices, but also to whole networks. However, these advancements present new challenges arising from the limitations of the early types of infrastructure. Different solutions have been proposed, but none have yet emerged as the definitive answer. This paper focuses on the cost of deployment for solutions i3, HIP, NUTSS, NSIS and Mobile IP. These are deployed on different layers, some require changes to applications or operating systems while others require changes to the Internet core routers. First I will go through why changes are needed. After I have established that, I will present some technologies which offer solutions to mobility and other issues. The chapter after that contains cost analysis of these problems. In the final chapter I present my conclusions about the costs and which of the technologies should be deployed. 2 Background Originally, the architecture to support the Internet was designed without any consideration for the need to support mobility. This worked for a while, but the limitations of this early architecture became more obvious as devices shrank in size and, moreover, became increasingly interconnected. That said, the original simple point-to-point architecture was critical to the early development of the Internet, as it contributed to its scalability and efficiency[14]. Because of the smaller size and therefore the improved movability of hosts combined with modern interconnectivity the need for mobility has surfaced. By mobility I mean the ability of hosts to move between networks without losing their current connections. Sometimes staying still or disconnecting isn t an option. An example of where mobility is needed can be a security guards communication device which uses VoIP. First the guard sits in his monitoring room and the device is connected the the WLAN present in his room. When he leaves for his rounds outside the building he leaves the range of the WLAN and his communication device automatically switches to an cellular network. When this switch happens the device must switch smoothly and retain its current connections. This is where mobility support is needed. 3 Solution previews Here I will list short previews of all the proposed solutions, the previews are only meant to scratch the surface of each solution and provide a general picture of the subject. 3.1 Mobile IP: MIP I will only focus on Mobile IPv6 as it is replacing MIPv4 and is meant to be included as a part of IPv6. MIP uses a home agent(ha) with a static address to sustain connections between the mobile node(mn) and the correspondent node(cn) as shown on Fig. 1. The correspondent node does not have to support MIP for the protocol to work, but it helps because it enables rerouting so that all the packets do not have to pass through the home agent[5]. MIP requires a trust relationship between the HA and MN, while no trust is required towards the CN. The trust between the HA and MN is formed with the use of IPSec with ESP when updating the MN information on the HA[5]. The information update is triggered when the MN moves and has to switch address[7]. The mobile host can acquire a new address by the use of IPv6 auto configuration. 3.2 Internet Indirection Infrastructure: i3 i3 aims to ease the development of services such as multicast, anycast and mobility. It offers a rendezvous-based solution which decouples the act of sending from the act of receiving. In an i3 network hosts associate themselves with identifiers, which are stored in the network as triggers. The hosts associated with the trigger receive all the traffic that is sent to the trigger. The i3 overlay network has servers called i3 nodes,

2 solve mobility and other problems by adding new signaling to IP connections[3]. By means of URI it provides a locator identifier split which enables host mobility. The URIs can refer to applications, users and flows in addition to just devices. These URIs are similar to addresses, which in fact are URIs, which makes them more human readable. An example of an URI could be erkka@home.honkavaara.org;type=client;app=skype, that identifies the user, the endpoint type and the application, meaning Erkka s skype client at the domain home.honkavaara.org[11]. These URIs allow more spesific identification of connections. These references and dataflows are setup by the use of SIP and STUNT. SIP is used because of its maturity and already wide deployment[2]. Figure 1: MIP connection which store these triggers and handle all of the traffic[14] forwarding. When a host inserts a trigger to the network, it send it to the hosts gateway i3 node, which then forwards the trigger to the correct i3 node to store the trigger. The triggers are spread throughout the network according to an algorithm, some redundancy is used to make sure a single host failing doesn t bring the whole network down. 3.3 Host Identity Protocol: HIP HIP approaches the mobility problem by adding a new layer, namely the Host Identity Protocol, to the OSI model in between the internetworking and transport layers[8]. The protocol provides an identifier and locator split, which allows hosts to change locations while retaining their identifier(host identity(hi)). The identifier may also have multiple locations assigned to it enabling multihoming[9]. These identifiers have to be stored somewhere and the current approach is to use distributed hash tables(dht) in an secure-i3 overlay network[10], which I presented earlier. This HIP infrastructure is called Hi 3. It makes the handling of HIs more dynamic than using normal DNS based infrastructure at the same time retaining redundancy and security. 3.4 NAT, URI, Tunnel, SIP and STUNT: NUTSS The name NUTSS, a bit different in origin from the other solution names, is derived from the words NAT, URI, tunnel, SIP and STUNT, which are the technologies it relies on. NUTSS challenges the original end-to-end architecture of the Internet and substitutes it with its own end-middle-end version. It is a signaling based IP architecture which tries to 3.5 Next Step In Signaling: NSIS NSIS aims to solve the current problems with the Internet by introducing a suite of protocols for signaling between NEs (NSIS Entities) which are considered peers. These NEs include the end hosts and NSIS enabled nodes along the signaling path. NSIS can configure routes through NSIS enabled firewalls and NATs, negotiate quality of service guarantees and detect congestion along the data path[4]. NSIS capable middleboxes enable NAT- and firewalltraversal by using NAT/FW NSIS Signalling Layer Protocols(NSLPs). The NAT/FW NSLP is used to dynamically install policy rules on supporting middleboxes along the path[13]. Unlike the other solutions NSIS itself does not provide mobility, it just supports it by preparing a route for the connection by manipulating NSIS aware middleboxes on the route. NSIS itself mostly focuses on handling the QoS aspects of the mobile connection[12]. 4 Costs of solutions In this section I will go through changes which are needed to deploy the different solutions and evaluate the weight of the changes required by them. By cost I refer real costs caused by the need to change the existing systems. These changes include but are not limited to changes to routing infrastructure, operating systems, applications and middleboxes. While I do not dare to make a guess for the numerical size of these costs, they are substantial and have to be taken into account. Changes to operating systems are easily deployed because of the modern automatic updates supported by Windows, Mac and Linux. The real problem is legacy support for applications, the solution may render old applications inoperable until they have been updated. This is a serious problem with unsupported applications. Another cost arises from already deployed application solutions. Companies have configured applications and networks function on the old IPv4. When this changes not only the application has to be updated, but configurations have to be redeployed to with the new architecture. Changes to hardware, routers and middleboxes, take time and effort to implement. Big suppliers, Cisco and others,

3 can release software updates to existing systems, but these changes have to be thoroughly tested and configured by trained professionals which is very costly. 4.1 MIP IPv6 has been coming for the last ten years, although it has only recently started to pick up speed. One of the biggest steps toward deploying IPv6 has been made by China, which has adopted a five year plan to full reach deployment. IPv6 is gaining more and more exposure and I believe that it will be deployed in the next five years. As IPv6 get more and more deployed, MIP will become more and more viable as a solution as it enables mobility with IPv6. The deployment of other solutions discussed in this paper will most probably not slow the IPv6s spread, on the contrary, they may speed it up. This means that the router, application and API changes needed by MIP(IPv6) will be most probably implemented regardless of the use of MIP. Because of this the only need for supporting mobility is the Home Agent, which can be the user s computer at home or at work. 4.2 i3 i3 requires a lot of bandwidth to be fully deployed as a solution because of the need to route all the traffic through the overlay network and its servers. This in addition to the need to add changes to applications and APIs makes it quite costly to deploy[14]. Because of the high cost related to its deployment, it seems more effective to use it only for control data as in the case of HIP. This way only lightweight control data is transferred through the overlay network and the real payload moves along a more traditional route. Without i3 supporting applications a proxy server is needed. The proxy server can be hosted as a remote client or on the user s system. The connection is then handled trough DNS-names, ie. my.homecomputer.i3. There is at least one proxy solution ready, it goes by the name of OCALA[6], Overlay Convergence Architecture for Legacy Applications, and it can be run on Windows, Linux and Mac. i3 can have some security issues such as eavesdropping, trigger hijacking and DoS attacks. Eavesdropping is possible by inserting a trigger to the network with the same id as the victim. This adds the eavesdropper as a recipient of all the messages sent to the victims id. The real threat however is the DoS attacks, these can be caused by attacking either the infrastructure or end-hosts. The attacker can chain triggers in a way that they loop or replicate packets, overwhelming the target. 4.3 HIP Currently, HIP can be used both in user and kernel space. This makes installation easier as changes to the operating system are slower to deploy. However running HIP in user space does create the drawback of reduced performance. This doesn t cause much concern because kernel support can be added later as the usage of HIP grows[1]. Because HIP will be most probably deployed with the Hi 3 infrastructure, it will require servers to host the i3 overlay network. Luckily, as the overlay network will only be used for control data, mainly HITs, the bandwidth and processing requirements of the network are lessened[10]. The deployment of HIP doesn t require much from the average users, as long as they remember to update their operating systems or download the userspace support for HIP. HIP is already implemented in Linux and can most probably be added to new Windows systems with an automatic update. Because of Local Scope Identifiers, LSIs, the users can use their old programs with HIP. An LSI is a localized 32-bit representation for an HI[9], which looks like an IPv4 address. A driving force behind the deployment of HIP could be the fact that it can serve as a bridge between IPv4 and IPv6 as it provides interoperability for them on application level. This would make the transition from IPv4 to IPv6 a lot more streamlined. Also the added security sounds very promising. 4.4 NUTSS While NUTSS benefits greatly from middleboxes supporting it, it can operate in legacy mode to allow NAT-traversal endpoints. This optionality allows NUTSS to be deployed incrementally in three phases. At first it will only offer the traversal and end-to-end access control[2]. In the second phase policy-boxes, called P-boxes, are added to the network allowing some control over the network traffic. The endpoints are configured to use these P-boxes, this can be done through an auto configuration protocol, ie. DHCP[2]. In the final phase, NUTSS-aware middleboxes, called M- boxes, are introduced into the borders of the network. They enforce the P-box defined rules and remove the need of individual endpoint configuration. Also NAT-traversal is made obsolete with the M-boxes[2]. This incremental deployment makes NUTSS more appealing as it offers the highly coveted NAT-traversal in the first phase. The endpoint deployment of NUTSS can be made in userspace and, according to Saikat Guha and Paul Francis, with minimal or no changes to user applications[2]. I m skeptical on this because of the URI-addressing which would need changes to existing applications. NUTSS deployment should be straightforward for an average user, it initially requires only a operating system update or installing a software component. Configuring NUTSS policies in phase 1 requires a bit more insight and may cause not so technically savvy people to use less secure options for added comfort. If NUTSS aware applications are used, automatic configuration should be possible. I believe that one of the problems NUTSS would have is that it most probably will have to deployed mostly on operator side because the average users will not understand P- boxes and may even be confused with the legacy and NUTSS capable NATs. Also there might be problems with implementing the M- and P-boxes because of differences in manufacturers implementations.

4 4.5 NSIS NSIS supports incremental deployment by supporting networks with both NSIS-capable and incapable nodes. Nodes which do not support NSIS are just passed through because common protocols, ie TCP, are used for transport. This way NSIS traffic can move through entire networks without the need of additional support[4]. However if the amount of nodes without NSIS-capabilities is high, the benefits reduce, because of the reduced amount of QoS reservations. NSIS is one of the more costly ones to implement because of the need to make changes to routers. While it may or may not be possible to implement these changes with some software updates the added computing load would force operators to upgrade their routers incurring costs. As operators are mostly after profit, without clear business possibilities NSIS may not seem enough financially justified. On the other hand, the router market is dominated by a few large companies which can push technologies to the core. I believe that if Cisco would implement NSIS support on its core routers, others would follow. This wouldn t be a fast process because the routers would have to be updated and reconfigured. Requires changes to Needs Kernel Apps Routers Solution Phase servers &API i3 In dev YES NO YES* NO HIP Test** YES YES NO NO NUTSS In dev YES NO NO NO NSIS In dev YES YES NO YES Mobile Home IP Ready Agent Done NO NO *Legacy support with proxies **HIP has been deployed in the Linux kernel patched with linux hip.patch but is still being developed. HIP supports old applications and APIs through LSIs which act as bridges between IPv4-based protocols and API. MIPv6 included in IPv6 5 Conclusions Table 2: Solutions 4.6 Summary As we can see from tables 2 and 1 some of the solutions have similar features and requirements, while others take on a totally different approach. i3, HIP and NUTSS approach the mobility problem with a new address space which in the case of i3 and NUTSS requires changes to applications, while HIP can operate with legacy applications. i3 can however function with legacy through the use of a proxy. The cost of these changes is substantial because of the sheer amount of deployed legacy applications. MIP works differently by using the HA for relaying information or data. Because of the way MIP works, it is totally transparent to existing applications and does not require any changes to the network making it a cheap but limited solution. NSIS on the other hand has a totally different approach. It requires the route to be aware of the needs of the connection. This requires changes to the routers, which takes time and effort. Solution DoS protection Id/loc split NAT support i3 YES** YES NO HIP YES* YES YES NUTSS NO YES YES NSIS NO NO YES MIP NO NO NO By NAT support I m referring to NAT traversal *By means of processing challenges **By means of managing triggers Table 1: Some solution features Currently, Mobile IP and HIP are the most mature of and closest to being fully deployed. HIP has been added to the Linux kernel and is being tested with currently. But MIP has the advantage because it is bundled with IPv6 which is currently supported in all major operating systems. Although it has not yet reached IPv4 s popularity, it has been gaining ground and public acceptance. While MIP does solve mobility issues, the other solutions have other benefits that should be taken into account. These benefits include NAT-traversal, DoS-protection, etc... as shown in table 1. Although all of the solutions have important features, in my opinion the best benefit-cost ratio is with HIP. It implements scalable security, mobility and multihoming with minimal changes to existing infrastructure. Although solutions like NUTSS and HIP offer support for legacy applications I fear that there will be some programs that stop working. This is a major problem because some of these applications may be mission critical components for firms. If these applications are not being supported anymore, they cannot be easily fixed to work with the new solutions. Because of this completely legacy hosts may be left on the network. It will be interesting to follow the development of the current situation and see which technologies take flight, and which crash and burn. As time has shown, it is very hard to predict which technologies will make it, good design and features do not always help. I believe that the most critical time for these solutions will be when IPv6 starts being deployed on the large scale, because the most logical time to deploy them is at the same with IPv6 or a bit before. After IPv6 I don t believe there will as much interest in doing more work to deploy the latecomers.

5 6 Future work I believe that a numerical analysis on this subject would be interesting and rewarding. The amount of legacy applications and hosts is huge, the volume of the changes needed to implement these changes brings along a cost. Also the possible need for upgrading core routers for possible future technologies such as NSIS would have to be looked into as well. 7 Acknowledgements I would like to thank Timo Kiravuo for providing direction and guidance for this paper and Roger Munn for help with the correct use of the English language. I would also like to extend my gratitude to my opponent Lu Yang for comments and improvement suggestions on this paper. References [10] P. Nikander, J. Arkko, and B. Ohlman. Host identity indirection infrastructure (hi3). Internet Draft, june Internet Draft, Expired in December 26, [11] P. F. Saikat Guha. Towards a secure internet architecture through signaling. Technical report, July cul.cis/tr [12] T. Sanda, X. Fu, S. Jeong, J. Manner, and H. Tschofenig. Applicability statement of nsis protocols in mobile environments. Internet Draft, february Internet Draft, Expires in August 25, [13] N. Steinleitner, H. Peters, and X. Fu. Implementation and performance study of a new nat/firewall signaling protocol. In ICDCSW 06: Proceedings of the 26th IEEE International ConferenceWorkshops on Distributed Computing Systems, page 8, Washington, DC, USA, IEEE Computer Society. [14] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana. Internet indirection infrastructure, [1] J. Ahrenholz. OpenHip webpage - Overview, October Visited [2] S. Guha and P. Francis. An end-middle-end approach to connection establishment. In SIGCOMM 07: Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM. [3] S. Guha, Y. Takeda, and P. Francis. Nutss: a sipbased approach to udp and tcp network connectivity. In FDNA 04: Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, pages 43 48, New York, NY, USA, ACM. [4] R. Hancock, G. Karagiannis, J. Loughney, and S. V. den Bosch. Next Steps in Signaling (NSIS): Framework. RFC 4080 (Informational), June [5] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775 (Proposed Standard), June [6] D. A. Joseph. Ocala: Overlay convergence architecture for legacy applications. Web page, november url( ): [7] M. Merger. Mobility management with mobile ip version 6. Master s thesis, [8] R. Moskowitz and P. Nikander. Host Identity Protocol (HIP) Architecture. RFC 4423 (Informational), May [9] P. Nikander. Applying host identity protocol to the internet addressing architecture. Applications and the Internet, Proceedings International Symposium on, pages 5, 2004.