Overview and Comparison Criteria for the Host Identity ... - CiteSeerX

Overview and Comparison Criteria for the Host Identity Protocol and Related Technologies InfraHIP Project Teemu Koponen Janne Lindqvist Niklas Karlsson Essi Vehmersalo Miika Komu Mika Kousa Dmitry Korzun Andrei Gurtov 22.11.2005

Helsinki Institute for Information Technology Helsinki University of Technology

Abstract The traditional IP address suffers from semantic overloading by representing both the topological location and also the identifier for a network interface. This is a legacy from much more restricted networking environment than what we face with the modern Internet nowadays. The shortcomings of the original IP architecture have been realized among researchers along with the development of various mobility and multihoming technologies. The purpose of this document is to present criteria for evaluating and comparing such proposals. We focus on the Host Identity Protocol and compare it with other prominent related technologies.

Contents 1

Introduction

2

Comparison Criteria 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Provided functionality . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Identity based connectivity . . . . . . . . . . . . . . . 2.2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Multi-homing and multi-access . . . . . . . . . . . . . 2.2.5 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Separation of signaling and payload traffic . . . . . . 2.3 Non-functional properties . . . . . . . . . . . . . . . . . . . . 2.3.1 Complexity . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Robustness / Resilience . . . . . . . . . . . . . . . . . . 2.3.5 Brittleness . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Deployment issues . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Economic aspects . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Basic OPEX/CAPEX analysis . . . . . . . . . . . . . . 2.5.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 Responsibilities/opportunities in any new infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.4 New business models and supply chains . . . . . . . 2.5.5 IPR issues . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Social and political issues . . . . . . . . . . . . . . . . . . . .

3 3 3 3 4 6 7 7 8 8 8 9 10 11 11 11 12 12 12

Overview of Host Identity Protocol 3.1 Provided functionality . . . . . . . . . . . . . . 3.1.1 Identity based connectivity . . . . . . . 3.1.2 Security . . . . . . . . . . . . . . . . . . 3.1.3 Mobility, multi-homing, and delegation 3.2 Deployment issues . . . . . . . . . . . . . . . .

15 15 15 16 16 17

3

1

i

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

13 13 13 13

CONTENTS

4

5

Identification of Related Technologies 4.1 Macro Mobility . . . . . . . . . . . . . . . . . . . 4.1.1 Mobile IPv6 . . . . . . . . . . . . . . . . . 4.1.2 Mobile IPv4 . . . . . . . . . . . . . . . . . 4.1.3 TCP Migrate . . . . . . . . . . . . . . . . . 4.1.4 SIP Mobility . . . . . . . . . . . . . . . . . 4.2 Seamoby . . . . . . . . . . . . . . . . . . . . . . . 4.3 NSIS . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Micro Mobility . . . . . . . . . . . . . . . . . . . . 4.5 Network Mobility . . . . . . . . . . . . . . . . . . 4.6 Multihoming . . . . . . . . . . . . . . . . . . . . . 4.6.1 SCTP . . . . . . . . . . . . . . . . . . . . . 4.6.2 Mobility Extensions to SCTP . . . . . . . 4.6.3 Multi6 . . . . . . . . . . . . . . . . . . . . 4.7 Identity / Locator Split . . . . . . . . . . . . . . . 4.7.1 Internet Indirection Infrastructure (i3) . . 4.7.2 Delegation-Oriented Architecture (DOA) 4.7.3 Semantic-Free Referencing (SFR) . . . . . 4.8 IKEv2 and Extensions . . . . . . . . . . . . . . . Conclusions

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

21 21 21 21 22 22 23 24 24 25 25 25 26 26 27 27 28 29 29 31

ii

Chapter 1

Introduction This document is produced by the InfraHIP project. The project members are the Helsinki Institute of Information Technology (HIIT) and the Helsinki University of Technology Telecommunications Software and Multimedia Laboratory (TKK/TML). In this document, we have defined comparison criteria for evaluating secure mobility and multihoming solutions. We also give an overview of HIP with the emphasis on the criteria and a survey of related technologies. Chapter 2 introduces and discusses the criteria. Current challenges of Internet architecture shape the foundations of the comparison criteria, that is, the functionalities provided by the technologies. The rest of the criteria, such as non-functional properties and socio-economic aspects, are more timeless. In a way, they measure the implications and price of the functionalities provided. Assessing a solution using the criteria should help one to form understanding how the solution meets the current requirements. The categories of the criteria are introduced as follows. Instead of providing a set of metrics for protocol assessment, we define the criteria by introducing matters one should focus to, while actually comparing different protocols. Moreover, in order to illustrate the criteria, we shall use examples whenever possible. Our understanding is that this approach helps us further to justify the validity of the whole criteria. After the criteria, we give an overview of HIP based on some of the criteria in Chapter 3. Chapter 4 covers the most important HIP-related technologies: micro and macro mobility management protocols, identifier/locator split solutions and IETF working groups on signaling and seamless mobility, among others. Finally, Chapter 5 concludes this report.

1

CHAPTER 1. INTRODUCTION

2

Chapter 2

Comparison Criteria 2.1

Overview

The chapter introduces and discusses the criteria for evaluating different solutions for secure mobility and multihoming. The criteria consists of five main categories: functionalities provided, non-functional properties, deployment issues, economical aspects, and finally, social and political issues. We understand that the space these categories open is vast. Therefore, the last mentioned categories receive less attention. Table 2.1 summarizes the chosen criteria at a very high level.

2.2 2.2.1

Provided functionality Identity based connectivity

Global reachability on Internet is no more a part of the reality, at least on the network layer of the protocol stack. Instead, today Internet consists of adjacent address spaces that are interconnected by address translators (NAT devices), or middle boxes in general [18]. Internet has no more coherent global address space spanning all networks. As a result, identifying and communicating with a host has become cumbersome. Moreover, while a host may establish connections itself, the others can not connect, or even identify the host.Thus, the connectivity of the host has become asymmetric. All this is obviously something that is very different from the early ages of Internet. In fact, this even risks the freedom of innovation in Internet that has been often cited as the main reason for its success [48]. Re-establishing the global reachability again is a research challenge that receives lots of attention [69]. A common factor for the proposals is the idea of creating a new name space spanning again over all the networks. With such a name space, hosts would regain their global identities, if they wish. While said this, it should be noted that the name space may be located at 3

CHAPTER 2. COMPARISON CRITERIA

Category Provided functionality

Non-functional properties

Deployment issues

Economic aspects Social and political issues

Overview Functionalities relevant to mobility/multihoming solutions, either providing the functionality or interfacing to other solutions that address the functionality. Implicit properties that have however great impact on the applicability, deployability and maintainability of the solution. The more immediate consequences, costs, motivators/de-motivators, benefits and drawbacks with deployment of the technology. Business models created, changed or otherwise affected by the technology. Effects by the technology regarding individuals, communities and societies and their relations.

Table 2.1: An overview of the comparison criteria. various different layers of the protocol stack. For example, from this point of view, one could consider SIP to offer global reachability for hosts due to its addressing based on domain names. Our conception is that it is important to understand how the problem of global reachability has been handled in a mobility and multi-homing solution to which this criteria is applied to. In fact, it is not a coincidence that identity based connectivity is the first introduced functionality criterion, as it is perhaps the most important one.

2.2.2

Security

Security is Achilles’ heel for many communication protocols and techniques used in Internet today. Since security is a multi-faceted matter, we claim that following, numerous, aspects should be considered while comparing mobility and multi-homing solutions. The level of authentication a solution provides for communication endpoints is a beginning for this category. The level of authentication may vary between weak and strong. An example of the first one is authentication based on IP addresses, while public key cryptography can be used for the latter. The type of identification a solution provides must be understood. While the model of identification may be based on X.500 style coupling with a physical identities, it may also be based on opaque identities re4

2.2. PROVIDED FUNCTIONALITY

vealing no more than an identifier about the authenticated entity. While understanding the type of authentication is important, it is also important to understand what is really being authenticated. The authentication may be host centric, user centric, or something between these. Authentication and identification of an entity are only tools for the actual authorization of an event within a system. Modifying the systems properties is only authorized if the modifier has privileges for the modification. A simple example is the user accounts in a UNIX system. The root account has more access by default compared to a normal user account. Successful authentication, identification, and, finally, authorization result in a context shared between communication peers, and possibly with entities between them too. The temporal span of this context, or a session, is something that should considered too. In addition to the temporal span, the end-to-end security properties of a session must be assessed too; is the security provided hop-by-hop or truly end-to-end. Additionally, a communication protocol may provide other security properties such as privacy. Privacy can be further divided to communication privacy, location privacy and confidentiality. Communication privacy is established in order to prevent eavesdroppers of identifying who are the communication participants. Additionally, this can be done so that the communication participants do not identify themselves or identity themselves after anonymous contact [76]. Location privacy involves hiding the present and future locations from eavesdroppers or communication participants. Confidentiality ensures that only the communication participants can view the content of the communication. To establish a possibility of auditing the integrity of messages have to be ensured. This involves protecting that the headers or the payload is not changed. Accordingly, auditing requires also the authentication and identifying properties. The above classic aspects of security do not consider explicitly a class of attacks called denial of service attacks. Protecting from such attacks requires comprehensive measures, often affecting the whole infrastructure. Thus, the design of a mobility and multi-homing solution should clearly consider such attacks. Finally, integration of the solution to existing infrastructure must be considered too. This means at least two different aspects: integration of the legacy user authentication domains to the protocol and support to the security devices that are deployed to networks. In practice, the security devices mostly refer to firewalls and intrusion detection systems. As with sessions, the temporal span of entities of a solution should be considered. That is, how the integration is handled during the life cycle of an entity, beginning from bootstrapping and ending to the disposal of the entity. 5


2.2.3

Mobility

Mobility and multi-homing protocols aim to enhance the almost nonexisting support for mobility in the current Internet infrastructure. However, while mobility often refers to a physical host roaming between access points and access networks, the forms of mobility are more versatile. When assessing a protocol, the assessment begins from identifying the supported types of mobility. In that way one should be able to understand how the protocol fits to the bigger picture of mobility. We do not claim the following list of the forms of mobility is comprehensive, on the contrary. When a host moves within the area of an access point, the movement is called access mobility or micro mobility. In contrast, where micro mobility is localized, macro mobility establishes global connectivity. An example of macro mobility is roaming between different mobile phone networks. Host mobility refers to the above classic interpretation of the mobility. However, even that should be re-considered, as the definition of the host itself is becoming less apparent. In the current Internet a host should not be considered to equal to a physical host anymore. For example, a host may be a virtual one that runs within a virtual machine. Thus, a physical host may host multiple virtual hosts. Moreover, while a physical host may change its point of network attachment, a virtual one may change even physical hosts. For example, the latter can be established with VMware Virtual Center [68]. Host mobility can be done on different layers: link-layer, network, transport and application layer. Also, host mobility can be micro mobility or macro mobility. Network mobility is about changing the network attachment point of a whole network. Such a mobility is about to become more common as Internet connectivity becomes ubiquitous. An explicit support for network mobility may be a necessity in order to keep the performance penalty of the mobility reasonable. Application mobility roughly equals mobility due to administrative aspects. Strict availability requirements combined to cost-efficiency requirements set for hardware render moving of services more and more attractive. For example, in order to maintain the level of service intact over a maintenance period, administrators can move services from a physical host to another. Clearly, the infrastructure should support such an operation so that the movement remains invisible for both current and new remote communication peers. In extreme case, the movement may occur even while the applications run. User mobility is about users moving between hosts. There are two different aspects here. First, the user may move and sessions do not. Second, the user may move her sessions with her. An example of user mobility with out session mobility is changing the SIM card from a mobile phone to another. Session mobility combined with user mobility can be established 6

2.2. PROVIDED FUNCTIONALITY

with SIP, for example. When considering mobility functionalities of a protocol, one should remember the temporal aspect of communications, i.e., how mobility is handled in different phases of communication. For example, how the protocol guarantees the reachability of a host (or a service) after a movement, or how the protocol implements measures to tackle the problem of both peers moving simultaneously.

2.2.4

Multi-homing and multi-access

While Internet connectivity is becoming ubiquitous, there is a side-effect: the connectivity comes in many forms. Future devices are likely to have more than a single interface to connect to networks; the selection of an interface depends on the context of the device and its user. Occasionally there can be even multiple interfaces in use simultaneously. Multi-homing may also consider a whole network, i.e., the network may be connected to multiple Internet Service Providers. If expanded to multiple networks, the whole site may be multi-homed. This is called site-multihoming.

2.2.5

Delegation

Intermediate network devices, such as NAT boxes, are nowadays a commonplace. Even though the market demands such devices for various reasons, the devices are not in harmony with the Internet architecture [14]. Many NAT traversal proposals the IETF has produced are convincing evidence. It has been proposed the devices should be explicitly incorporated into the architecture by means of delegation primitive [69]. Delegation primitive enables a host to transfer responsibilities to another hosts. The host may introduce a new host to be a part of the path a packet travels from and to the old host. In a way, if support for mobility enables a host to inform its current and future peers about its location, delegation is a controlled mechanism for the host to alter the actual path its packets travel. An architecture that supports the delegation primitive also elegantly supports middle boxes. Hosts simply include NAT devices to the paths of packets they send and receive. While assessing delegation functionalities of a protocol, the close relationship of identity based connectivity and delegation must kept in mind. Clearly, reaching an end-point in a delegation-capable architecture requires separation of locators and identities. 7


2.2.6

Separation of signaling and payload traffic

In traditional telecom networks signaling and payload traffic are separated. Internet is different, since there is no separation of the signaling and payload traffic; end users have an access to both. While this freedom has most likely facilitated development of new applications, restricting control traffic from end users may sometimes be desirable. One can consider the usage of SIP in UMTS IMS as an example of such need for traffic control; by controlling the signaling traffic with IMS the operator may control very efficiently the user’s connections. Such separation of signaling and payload traffic can be beneficial for the users too, even though such a control would not be a goal as such. This is simply because these two categories of traffic have often very different requirements. For example, for signaling one could use a more robust route and for payload a more efficient route.

2.3 2.3.1

Non-functional properties Complexity

The complexity of a protocol has a big impact to the total cost of the protocol. In addition to direct product development costs, complexity can introduce negative side-effects that generate indirect costs. Therefore, a protocol assessment should consider the following points of view to the complexity. Having an architectural point of view means that the complexity a protocol introduces to an architecture is under inspection. Typical examples of architectural complexity are problems related to impure interfaces between its components. For example, in a protocol stack so called layering violations refer to situations where a layer must implement functionalities of another layer. Clearly, such unnecessary dependencies integrate logically independent components to each other. While protocol layers may have to have extra cross-layer communication in place (besides the usual packet processing), the amount of communication should be evaluated. Again, plentiful communication may be a sign of improper distribution of functionalities to components. The above considered the protocol stack within a host, i.e., the complexity related (mostly) to the vertical communication occurring within the host. However, the horizontal complexity must be considered too. In other words, what are the implications for the entities between the communication end-points. In practice, this leads us to inspect states that the communication requires to be present in network. Both, creation and maintenance, of such states should be understood when comparing mobility and multi-homing protocols. 8

2.3. NON-FUNCTIONAL PROPERTIES

Type of delay Initial rendezvous Hard handovers Soft handovers Recovery from double jump

Limit < 2s < 50ms < 1ms < 200ms

Table 2.2: Typical delays to be considered while assessing a protocol and their desirable limits to minimize its negative effects to overall usability. A more traditional understanding of the complexity considers only the implementation complexity. The ultimate criterion is the number of code lines a protocol requires. Another viewpoint to this category of complexity is the number of different entity types it introduces to networks. For example, does the protocol require several new types of services to be deployed to the networks. The number of required entity instances not necessarily results in increased complexity. However, increased variety of entity types usually does. The final aspect to consider is management complexity, which increases the cost of deployment and operations of the infrastructure that a protocol needs. Whenever a protocol introduces, for example, a new name space, it requires management. Thus, understanding the management of the introduced new concepts is essential. Moreover, the effects of the protocol to the existing management tasks should be considered. For example, does the protocol complicate a process of introducing new nodes to a server farm?

2.3.2

Efficiency

In the end an efficient protocol enhances the user experience. While good scalability of a protocol (and its implementations) may retrieve a lot, a fundamentally poor performance drives again the total cost up. We consider the efficiency from the three different viewpoints: user, host, and network. From the user point of view, the most visible signs of inefficiency are transient delays that are due to the operations of the protocol. Table 2.2 lists typical delays and desirable limits for them (from user’s point of view). Again, the whole life cycle of communications is covered: from the initial rendezvous to different hand-overs occurring while communication has been already established. A class of protocol interactions is not included to the table, but clearly, it has an impact to the user experience. For example, how does the network layer inform (or help) the transport layer to overcome the changes in conditions that mobility causes? In particular, TCP is extremely sensitive for such changes [7]. From the host point of view, the CPU load and bandwidth consumption are important. They have an effect to the consumption of the power, and thus, to the lifetime of a battery. A simple measurement of size of code may 9


not be sufficient. For example, cryptographic operations may be very CPU intensive even though they may require only a small amount of code. Thus, computational complexity should be measured, for example, by means of required machine language operations per a protocol interaction. When considering the bandwidth and resource consumption, the signaling efficiency and payload overhead must be included to the discussion too. For example, how many packets a handover process requires and what are the sizes of the sent packets? Moreover, how much does the protocol increase the size of sent payload packets? Finally, from the network point of view, the efficiency of possible middle box functionalities should be checked. In other words, is it difficult to implement middle boxes in a performance wise manner due to deficiencies of a protocol? Moreover, are rarely needed middle boxes included to the communication path just due to a few rare special cases? This is subject to increase both round trip times and even relative length of the communication path as it is not the optimal in terms of network topology.

2.3.3

Scalability

Scalability should be understood to measure the applicability of a protocol to different performance requirements. The low-end consists of sensor networks and the high-end globally distributed server farms [10]. While comparing protocols, one should identify possible bottlenecks that are due to the design itself. Mobile IP home agents are an example of such a design decision [67]. The implications of design decisions should be understood and whether the bottlenecks are also single points of failure that have a negative impact to availability properties of the protocol. To understand overall scalability limitations, the design should be inspected from the network point of view, too. For example, introducing new states to the network may cause scalability limitations to existing services. This is closely coupled to the scalability properties of the new infrastructure services themselves. What are the scalability requirements and assumptions a protocol sets for a new infrastructure service? Scalability of the possibly introduced new name spaces should be inspected too. Are the foundations of the name space within statistically unique names or are the names truly unique? In addition to considering the purely technical aspects of scalability, one should also consider the scalability aspects of managing the protocol and its infrastructure. How much human effort is needed and how heavy are the required additions to management processes? 10

2.4. DEPLOYMENT ISSUES

2.3.4

Robustness / Resilience

An aspect greatly affecting the practical usability of a protocol is its resilience against failures occurring in networks. The resilience consists of the following categories. Single points of failure are an obvious source of reduced availability. If the functionalities of a protocol depend on a single entity, the availability requirements for this single entity can become simply unrealistic. As availability of whole networks may vary, the ability to support alternative routes helps to maintain the quality level of the communications. The level of stability different protocols require from the communication path vary. The more flexible the protocol is regarding the path, the more freedom the underlying network has for implementing fast re-routing mechanism. While the counter-measures are important as such, the protocol should also be able to perform network failure detection. The faster and more accurate the protocol is in detection, the less impact is caused for overall availability. One should also inspect the time and effort for recovering from partial network failures. While the result may be excellent in terms of availability, the price might be too high. The complexity of introduced counter-measures and detection mechanisms should be evaluated both in communication end-points and network.

2.3.5

Brittleness

The final non-functional property to consider is architectural brittleness. It is perhaps the most difficult property to measure of the all above represented properties. While the complexity itself is an important measure, the practical implications might not be obvious. In a way, even if a protocol requires complex infrastructure or implementation, it does not yet tell us how it behaves in case of component failures. An architecture that is solid sustains component failures better than a more brittle architecture. To be specific, an architecture with a hundred different components may sustain malfunctioning of fifteen component types, while another architecture with ten different components may sustain only breaking of a single component type. Even though the first architecture is more complex, its architecture is less brittle.

2.4

Deployment issues

Deployment issues can roughly be categorized to four main themes: compatibility with existing infrastructure, needed new infrastructure, standardization and implementation status. 11


Compatibility with existing technology involves many details. For example, has the technology NAT traversal possibility? How other middleboxes such as firewalls work with the new technology? Is it possible to use legacy devices or are modifications to routers and end hosts needed? Do the modifications bring any new benefits or are they only needed to support the new technology in the existing infrastructure? Compatibility with existing technology also means backward compatibility. How well do the Application Programming Interfaces (API) support existing applications? After the new technology has been introduced, is it possible to fallback to existing operations? Also, forward compatibility must be considered. For example, introducing upper layer identifiers to the architecture can be a forward compatibility issue. The other side to above is the required new infrastructure. What are the main necessary network components to enable the new technology? Can the technology be incrementally deployed with proxies, for example. Infrastructure issues aside, the deployment of a new technology can be affected by the standardization status. Depending on the standardization organization, the standardization can take considerable time. Also, the standardization process can be closed. Unlike Internet standards, not all standards are available for free. When evaluating the protocol, we should also identify the current standardization status of the technology. What organizations are involved in the standardization? Is the protocol being standardized at all? Deployment costs can depend on availability of implementations. Is the technology only proprietary or are open source implementations available? Are the implementations updated on a regular basis or have they been abandoned by their authors?

2.5 2.5.1

Economic aspects Basic OPEX/CAPEX analysis

The criteria in this section can be used to make estimates about the cost of needed infrastructure and administration. The cost analysis can be divided to CAPEX - capital expense and OPEX - operational expense. CAPEX includes the cost of software upgrades to devices and introducing new nodes to the network. OPEX issues are initial deployment and the costs of maintenance that can be regarded as administrative overhead.

2.5.2

Benefits

What are the potential economical benefits of the solution? The benefits could include the reduction of labor, for example, the time needed for net12

2.6. SOCIAL AND POLITICAL ISSUES

work management. However, it should be identified what are the tradeoffs. Does reduced labor introduce the need for more expertise. Thus, benefits may vary from better efficiency and increased demand of expertise. In addition to more direct benefits, the solution can have by-products. For example, the solution could introduce new services and new products.

2.5.3

Responsibilities/opportunities in any new infrastructures

A key question in the new infrastructure is the division of responsibility. Are new authorities needed or do old authorities suffice? Is there a need for a single authority or should administration be distributed. The authority issue also reflects the possibility for new service providers and new monopolies. For example, domain names can be considered as a distributed monopoly. Countries allocate their own upper level domain names and a few companies have been given the authority to allocate other (e.g. .com, .biz). One possible approach for evaluating the economical aspects is a game theoretic analysis. In game theory, we assume that the players of the new infrastructure act rationally. The question is then: what are the potential benefits of cooperation?

2.5.4

New business models and supply chains

This subsection does not actually describe evaluation criteria, but these issues are useful to keep in mind considering the overview of HIP. An example of a new business model could be a certificate authority. On the other hand, what are the possible killer applications of the new technology or infrastructure? Why should someone or an organization begin to use the new technology?

2.5.5

IPR issues

Intellectual property rights are becoming more significant in today’s society. When evaluating IPR issues, at least the following questions should be answered. Is some crucial part of the technology patented? Who owns the patents? Are open source implementations license free? What are the the other possible intellectual property right issues?

2.6

Social and political issues

Every relevant technology has impact on societies that use the technology. Also, the technology can indirectly affect societies that do not use it. The use of many technologies is also regulated. Thus, technology has impact on politics and government, too. 13


Any network technology can have impact on a person’s privacy. Privacy issues were discussed already in security section. However, an important social issue is the feel of privacy. Few centuries ago, you could go to a field with a friend and be sure of the privacy of your conversation. This is not any more possible in a world with modern surveillance equipments and telecommunications. Therefore, the question is, does the technology enable or deprive privacy? The other side of the coin is auditability. Does the technology prevent gathering an audit trail? Also, cryptography can hinder governmental intelligence operations and have benefits and drawbacks for investigation and forensics. Consequently, it must be taken to account that in some countries the use of cryptography is forbidden. One often forgotten issue in security is the change of target. When a new security mechanism is introduced to a system, it is likely that criminals change their targets or methods. A classical example is the introduction of car alarms and other car theft countermeasures. Today, criminals in certain countries hijack cars instead of trying to steal them. Thus, the risk of getting a car stolen has been changed to a risk for a car owner’s health. The final criterion is the potential for new networks of trust. A web of trust is a concept that can be related at least to Pretty Good Privacy (PGP). In contrast to typical public key infrastructure (PKI) systems with a central certification authority (CA), a web of trust leaves trust decisions on the hands of individual users. In practice, an user certificate can be signed by other users who endorse that specific association of a public key with a person.

14

Chapter 3

Overview of Host Identity Protocol In this chapter, we give an overview of the Host Identity Protocol. The emphasis is on the provided functionality and deployment issues. Nonfunctional properties, economic aspects, social and political issues are not covered.

3.1 3.1.1

Provided functionality Identity based connectivity

HIP decouples IP addresses from higher layer applications. In the HIP architecture the locators and end-point identifiers are separated from each other. HIP introduces a new namespace: Host Identity. Host Identities act as the end-point identifiers, while IP addresses retain the locator role. Host Identity is an asymmetric key pair. The public key part is called the Host Identifier and it represents the Host Identity in the Host Identity namespace [42]. The Host Identities can be either published or unpublished. The current HIP architecture Internet Draft states that the public Host Identifiers should be stored in DNS [42]. Another alternatives would be Public Key Infrastructure, LDAP directory or a distributed hash table. The new HIP namespace can be made to span over internetworks despite of the various middleboxes. Each host can be assigned a Host Identity that uniquely identifies it. The cryptographic nature of public host identifiers makes possible globally distinct identities. Therefore, introducing HIP in the Internet Protocol stack should re-establish global reachability. Additionally, HIP is an enabler for mobility and multihoming because it decouples the network and transport layers. 15

CHAPTER 3. OVERVIEW OF HOST IDENTITY PROTOCOL

3.1.2

Security

When comparing HIP to the current Internet where hosts are identified according to their IP addresses, the true advantage we get from HIP is a strong identification based on the cryptographical Host Identities. HIP enabled hosts can prove their identity by owning the private key part of their asymmetric Host Identity and signing data with it. With cryptographical identities, HIP enables authentication between end-points. Also, HIP protects the integrity and confidentiality of payload data as well as integrity of control packets. HIP control packets can also be used to carry cryptographic certificates. Certificates can be used for authentication or authorization purposes by the peer host or possibly by intermediate entities [43]. Initialization of a HIP association is designed to protect the responder from Denial of Service (DoS) attacks. The base exchange procedure includes a puzzle, that the initiator must solve [43]. Thus, the puzzle imposes a cost on the initiator. The puzzles can be precalculated by the responder. Precalculation enables the responder to postpone processing and state creation until initiator has solved the puzzle. Furthermore, HIP takes into account many other possibilities for DoS attacks, such as handling of malformed messages. We do not cover all the details in this document. In the Mobility section, we give an example of mitigating certain DoS attacks with address verification. Communication confidentiality with HIP is established by encrypting the payload data. Currently, the specified [43] encryption mechanism is Encapsulated Security Payload (ESP) [32]. Communication and location privacy can be established using unpublished (anonymous) identities. Additionally, the BLIND protocol can be used with HIP. The BLIND establishes communication and location privacy, while the communication peers can identify each other [76].

3.1.3

Mobility, multi-homing, and delegation

HIP supports host mobility and multi-homing by allowing a host to specify a set of IP addresses to its communicating peer. HIP protocol UPDATE packets are used to convey the information about available addresses. HIP is primarily an end-to-end protocol between two communicating hosts, although it does allow middleboxes to view and inspect protocol packet information. Therefore, also mobility and multi-homing in HIP are host oriented. However, HIP does not rule out other forms of multiaddressing, such as network mobility (as proposed in [74]) or site multihoming. HIP allows host to decide which interfaces it exposes to a certain communicating peer. Control data authentication also extends to mobility and 16


multi-homing UPDATEs as the messages are signed by the sender. Reachability of a new available IP address, should be verified to avoid flooding attacks against a third party. HIP includes echo parameters that can be used to test that a host is indeed reachable at a new address. Reachability may also be determined implicitly, for example when rekeying. [45] For initial rendezvous of mobile nodes HIP proposes static rendezvous servers. Rendezvous servers forward traffic for mobile nodes to their current location. Mobility may also cause a so called double-jump situation: communicating hosts move simultaneously and location updates sent to old addresses are missed by both endpoints. HIP addresses the problem with Forwarding Agent functionality. An entity in the old network intercepts traffic intended for the mobile node and forwards it to the new location [46]. Different middlebox functionalities required in HIP are further discussed in the deployment section. The decoupling of identities and locators in HIP enables application mobility in an elegant way, too [35]. To summarize, the idea is to move Host Identifier Tags together with applications from a host to another during the execution of the applications. By means of delegation certificates it is possible to avoid movement of private key material. For example, a private key of a host may be used to sign a certificate for another host to use its Host Identifier Tag. As the transport layer on top of the HIP layer binds itself to tags, it does not detect the movement as the tags move together with the applications. Delegation certificates also enable the delegation primitive in the architecture.

3.2

Deployment issues

Currently the only proposed API for HIP aware applications is the native API [34]. The HIP native API is implemented using C programming language and at the moment the HIPL (HIP for Linux) [13] implementation supports it. The API requires modifications in the application code and introduces a new socket family, PF_HIP. The API is based on the BSD sockets API and it allows applications to control HIP connection attributes. For example, applications can provide their own Host Identities for the connections. Additionally, the API is backward compatible allowing fallback to the plain TCP/IP if the peer host does not support HIP. HIP can be deployed even if the applications are not HIP aware. The HIP enabled operating system could decide whether to use HIP based on a security policy. This would be transparent to the applications and no changes would be needed in them. An Internet Draft by Henderson [21] discusses HIP support for legacy applications. Identity based routing and HIP API also establishes the possibility to roam between IPv4 and IPv6 networks. Naturally, this requires dual stack 17


support from the roaming host. However, with HIP, the roaming can be done without tunneling. The procedure is the same when changing the location from IPv6 network to a IPv6 network or IPv4 network to a IPv6 network. [24] As such, HIP does not require new infrastructure to the Internet. Only the two communicating peers need HIP. However, the new intrastructure is needed to enable certain features. A rendezvous server (RVS) is needed for enabling sub-second handover latencies. Additionally, RVS provides the possibility for mobile terminated connections without the need to modify DNS records. HIP proxy can be used for legacy hosts that do not support HIP. Proxies can also be used for load balancing traffic to servers. The IETF HIP working group is trying to publish Experimental, not Standard-track, RFCs. There are 5 independent publicly known implementations of Host Identity protocol. Ericsson Research is developing HIP for BSD [16], Helsinki Institute for Information Technology and Helsinki University of Technology work on HIP for Linux (HIPL) [13], Boeing has implementations for both Linux and Windows, Julien Laganier (Sun Research Grenoble) works for Solaris implementation and Andrew McGregor has an implementation developed in Python programming language [57]. HIPL, Ericsson’s and Boeing’s implementations are also open source. Middleboxes Deployment issues related to middleboxes concern on whether the protocol works with existing middleboxes. On the other hand, the protocol may need new middlebox functionalities. The existing widely deployed middleboxes include NATs and firewalls. Legacy NATs generally use transport level port information to multiplex several data connections from one public IP address to multiple private IP addresses. HIP has incompatibilities with legacy NATs, since port numbers are in some cases fixed or not available. Changing IP address at NATs is not problematic as HIP binds security associations to HITs instead of IP addresses [63]. With firewalls, the compatibility with HIP depends largely on the particular policy. For example, unknown extension headers, such as HIP header with IPv6, may be blocked by legacy firewalls. One solution for middlebox traversal is encapsulating traffic into UDP packets, as proposed for IPsec traffic. For supporting HIP at stateful middleboxes, such as NATs and stateful firewalls, the source and destination HITs can be used to identify flow between two endpoints. For payload traffic the source and destination IP addresses and SPIs, learned from HIP control packets, can be used as a flow identifier. For NAT functionality the SPI value can also be used to multiplex several connections into one public IP address. 18


Upgrading middleboxes to support HIP also provides additional benefits, because security provided by HIP can also extend to middleboxes. HIP control packets carry some unencrypted information, such as responder HI, HITs and signatures. The information can be used for verifying the sender signatures. This way HIP enables authentication of the control packets that change state also at the middlebox. Therefore, the security policies established by firewalls can be defined on reliable and secure identities. This can not be established with only IP address based policies. To summarize the chapter, HIP provides the functionality for identitity based connectivity and secure mobility and multihoming. Deployment issues, such as Application Programming Interfaces and needed middlebox functionalities are being researched.

19


20

Chapter 4

Identification of Related Technologies 4.1 4.1.1

Macro Mobility Mobile IPv6

Mobile IPv6 (MIPv6) protocol allows an IPv6 capable host to move in different networks in the IPv6 Internet while still keeping its home address the same. Active transport layer connections such as TCP are maintained transparently to the user. A mobile host is identified by its home address even when the host is connected to an other network than its home network. This is similar to the HITs used in HIP, which are stable in nature. When connected to an other network, the host has also a so called care-of address, which tells the current address of the host. Packets going to the home address are routed transparently to the care-of address. This done by the home agent located in the home network of the mobile host. The specification [23] defines methods for caching the bindings between the home and care-of addresses. Thus, a host may send packets directly to the care-of address of the mobile host instead of routing them through the home address. Additional specifications define and clarify how IPsec can be used with Mobile IPv6. RFC 3776 [3] defines using IPsec to protect signaling between the home agent and the mobile node.

4.1.2

Mobile IPv4

Similar to Mobile IPv6, Mobile IPv4 (MIPv4) enables an IPv4 capable host to move across different networks. MIPv4 has also the same concepts and benefits as MIPv6, use of home address and transparency to the transport layer. 21

CHAPTER 4. IDENTIFICATION OF RELATED TECHNOLOGIES

One example of Mobile IPv4 commercial deployment is CDMA2000 networks. HIP might benefit from the current main focus of the MIPv4 Working Group, which include deployment issues and pinpointing the problematic areas which are found during the deployment process. The MIPv4 WG also researches the use of MIPv4 in enterprise environments with IPsec VPNs [66]. HIP The other interesting work areas of the MIPv4 WG are finishing of the base draft [51] to reach the standard status, using AAA infrastructures for key exchange defined in RFC 3344 [50], and the finishing of low-latency handover Internet Draft [39].

4.1.3

TCP Migrate

TCP migrate [58] is a proposal where the TCP stacks of end-hosts are modified to support mobility. The modifications include a new state, “MIGRATE_WAIT”, and new TCP options. The purpose of the modifications is to make a single mobile host’s active TCP connections survive when it changes its location. When the mobile host moves, the state machine of the host goes to the new “MIGRATE_WAIT” state and starts a new TCP handshake with the peer. However, the initial SYN datagram in the handshake includes an TCP option that the peer recognizes not to be a new connection attempt, but rather a readdressing message. The peer uses a similar TCP option when sending the response SYN datagram and TCP connection can be rebound a different IP address. In the proposal, mobile end-hosts use dynamic DNS [71, 53] to guarantee initial reachability to them. During the initial TCP handshake, the mobile hosts negotiate a “token” in the TCP options. The token is used for tracking the connection and to prevent connection hijacking. There are two versions of the token: one without any cryptographic properties and one based on elliptic curves [22].

4.1.4

SIP Mobility

Session Initiation Protocol (SIP) is an application layer signaling protocol for establishing multimedia sessions [55]. It has been specified as the call control protocol for 3G mobile phones by 3GPP. SIP was designed for personal mobility. A user can REGISTER his location to a SIP server. When the user changes location, he can re-REGISTER to the server. When someone wants to contact the user, the server knows the location and can signal the user’s terminal. The current SIP specification does not describe session mobility. Session mobility to SIP has been proposed in 1999 [70]. However, SIP session mobility supports only UDP, it does not support TCP. On the other hand, 22

4.2. SEAMOBY

SIP mobility can be seen as a complementary solution for network mobility. Wong, et al., have implemented a multi-layered mobility management solution that uses SIP for real-time traffic mobility and Mobile IPv4 with Location Registers for non-real-time traffic [72]. SIP security can be divided to two cases: hop-by-hop security and endto-end security. Hop-by-hop security is used between SIP entities, every entity pair can use a different security mechanism. The security mechanisms are authentication and data encryption. SIP user agents use a shared secret based challenge-response protocol to authenticate to SIP servers. Between SIP servers, TLS or IPsec can be used for hop-by-hop data encryption. [56] End-to-end data encryption is specified to be established with S/MIME [55]. For header privacy and integrity, RFC 3261 specifies SIP tunneling. A SIP message is encrypted in the body of another SIP message with S/MIME.

4.2

Seamoby

During the development process of the Mobile IP Working Group, it was seen that there is a need for exchanging state information between edge mobility devices in fast handoff situations. Such state information are, for example, AAA information, security context, and QoS. Also, some standardization organizations, mostly related to wireless technology such as 3GPP, would have use for protocols that provide real-time services over IP infrastructure. These issues combined with the use of Mobile IP caused forming of the Seamoby Working Group in the IETF. An important aim of Seamoby is to provide minimal disruption across heterogeneous wireless and wired technologies for real-time services. Seamoby WG is based on the macro mobility work of The Mobile IP Working Group. Seamoby WG analyzes the requirements and tradeoffs for transferring the context. Other research areas are Handoff Candidate Discovery and Dormant Mode Host Alerting (DMHA). Seamoby considers multiple handoff candidates and then selects the most suitable scheme for the context transfer. In DMHA, mobile hosts may be in dormant mode and move to another location while in that state. The other hosts will still need to reach the new location of the moved mobile host. Seamoby defines requirements for DMHA at the IP layer networks. The work of the Seamoby Working Group ended in 2004 when it finished its tasks. The result was a set of Request for Comments ([28], [31], [29], [40]) and Internet-Drafts ([37], [38], [30]). 23


4.3

NSIS

The IETF Next Steps in Signaling (NSIS) working group develops a signaling framework for transport level signaling. NSIS does not provide an alternative technology for mobility or multihoming but relates to them by considering them in the design. The framework is based on a general signaling message transport layer (NSIS Transport Layer Protocol, NTLP) and different customized signaling applications (NSIS Signaling Layer Protocol, NSLP) on top of that. The first use case is an RSVP based QoS signaling model but variety of different signaling applications, such as NAT/firewall traversal, can be developed on top of the NTLP [19]. As mobility has implications to signaling protocols, NSIS considers mobility in general. Additionally, NSIS attempts to provide signaling compatible with the existing IETF mobility solutions, initially focusing on Mobile IP. Mobile environments may include frequent change of IP address. This requires efficient signaling protocol mechanisms to re-establish state in the new path and tear it down in the old. Also as IP address is usually included in the flow identifier, the session state should be independent of changes in the flow identifier [36]. From mobility management point of view signaling applications may aid deployment and applicability. With some mobility solutions packets logically belonging to same association, may include different IP addresses (such as MN or HA addresses in MIP) and use different protocols (IPin-IP tunneling, IPSec, etc.). This makes them problematic for stateful firewalls and NAT boxes that need to recognize packets of a certain flow. NSIS addresses this by proposing a signaling protocol that enables traversal of stateful firewalls for Mobile IPv6 [65]. In the signaling approach, the middleboxes would partly operate based the signaling received from end hosts, instead of tracking the actual workings of the mobility protocol used. As pointed out by Fessi [17], this is security sensitive and requires reliable mechanisms for identification, authentication and authorization.

4.4

Micro Mobility

The idea in micro mobility is to localize the needed signaling for mobility management. The goal can be to reduce the amount of macro mobile signaling when using a protocol such as Mobile IP. On the other hand, the goal may be limited to enabling base station to base station handovers without macro mobility. A generic model for micro mobility has been developed by Campbell et al. in their comparison article [11]. Examples of micro mobility protocols that are developed on the macro mobile signaling reduction paradigm are Cellular IP [12], Hawaii [52] and Hierarchical Mobile IP [59]. MageIP is 24

4.5. NETWORK MOBILITY

an example of a protocol that is designed for establishing handovers in a WLAN subnetwork [41]. Currently, HIP does not support micro mobility as such. One publication has been made on the subject by Ylitalo et al. [75].

4.5

Network Mobility

In network mobility the attachment point of a whole network changes. Instead of a mobile node, a router becomes mobile. Such a router connecting a mobile network to Internet is usually referred as mobile router. Mobile router is responsible for maintaining the connectivity for hosts within the mobile network. Besides maintaining the connectivity, the optimization of routes and signaling traffic are challenging, i.e., how to avoid triangular routing and how to aggregate node specific signaling messages [44]. The NEMO working group of IETF is specifying a Mobile IPv6 based approach for the problem. Currently, only the basic support for network mobility [15] has been specified. In the basic support, a Mobile IPv6 mobile router connects to a Home Agent and tunnels all traffic from and to the mobile network via the home agent. The problem statement of route optimization is being defined at the moment. Besides a Mobile IPv6 based approach, an approach based on HIP has been suggested [74]. The founding idea is to let hosts within a mobile network to delegate signaling rights to a mobile router. The mobile router may further delegate responsibility to perform binding updates to a host connected to the fixed Internet. The delegation occurs in a secure manner due to the cryptographic nature of HIP. The idea as such is an instantiation of the early ideas presented in [44].

4.6 4.6.1

Multihoming SCTP

Stream Control Transmission Protocol (SCTP) [61, 49] provides a reliable end-to-end message transportation service over IP-based networks [62]. It provides many enhancements over TCP, such as support for multihomed hosts and multiple streams in a single SCTP association [62]. These and many other enhancements make SCTP superior to TCP for real-time multimedia and telephony applications. SCTP provides a means for each SCTP endpoint to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. 25


The association spans transfers over all of the possible source/destination combinations which may be generated from each endpoint’s lists [61]. The security aspects have not been overlooked in SCTP. Connection setup with SCTP is similar to Host Identity Protocol (HIP): a cookie exchange mechanism is also used during the connection setup procedure. SCTP uses cryptographic hash functions for data integrity checks. In addition, it is possible to combine SCTP with Internet Key Exchange (IKE) and Internet Protocol security (IPsec) [9], or even Secure Sockets Layer (SSL) [25].

4.6.2

Mobility Extensions to SCTP

Basically, a SCTP transport layer association is based on a static set of addresses. The static nature of address sets makes SCTP unsuitable for more dynamic mobility scenarios. To remedy the situation, there is a proposal [54] in the Internet Engineering Task Force (IETF) to support dynamic addition and deletion of addresses to a SCTP association. The addition to the actual protocol mechanism [60] is relatively simple. A mobile host signals its peer about changes in its addresses and the peer acknowledges this. After this, the related address is removed from or added to the existing SCTP association. The proposal has been evaluated at least in two articles [4, 73]. The former concentrates on analyzing the benefits of the mobility extensions in a non-geostationary use scenario. The latter is a more practically biased as it includes some performance measurements.

4.6.3

Multi6

IETF multi6 working group has produced a layer 3 shim proposal [47] to map between location and identity for IPv6 addresses. The proposal adopts ideas from earlier proposals to solve the multi-homing problem. Together with Hash Based Addresses (HBA) [5] and failure detection [2] the proposal forms the current understanding of the multi6 working group. The layer 3 shim approach creates a new sub-layer to hosts that support multi-homing. The layer is responsible for mapping between upper layer identifiers and a changing set of locators. While the approach of creating a new layer into the TCP/IP stack is similar to HIP, the semantics of the upper layer identifiers differs. Unlike HIP, the layer 3 shim approach uses plain IPv6 addresses as upper layer identifiers. To be precise, a destination IPv6 address, that is used to contact a remote host initially, serves as a stable destination upper layer identifier for all communications with that specific destination host. If the locator of the destination host changes, the shim layer performs mapping between the current locator and the upper layer identifier. 26

4.7. IDENTITY / LOCATOR SPLIT

The approach is invisible for IPsec and transport layers, as the locator to upper layer identifier mapping is performed as it were an IPv6 header processing. Therefore, applications may use callbacks and referrals as they do nowadays. For example, FTP is not broken due to the shim layer. The actual mechanism to exchange information between communication peers about changed locators, or about the multi-homing capabilities in general, is still an open issue within the working group. As a protection from redirection attacks, HBA provides a mechanism to create a secure binding between multiple addresses available to a host. The idea is to bind a hash to all available address prefixes and public key/secret key. The hash is stored to an interface identifier part of all IP addresses of a multi-homing host. Thus, when a remote peer proposes a new IP address, its peers may verify that the prefix of the proposed address belongs to the group of allowed prefixes. The shim layer and HBA are complementary: while the shim layer approach does not introduce semantics to the IP addresses as such, it does not prevent one using HBA below it.

4.7

Identity / Locator Split

Recent identity / locator split based architectures can be divided into two categories: architectures that implement a packet forwarding infrastructure in order to overcome the limitations of the current Internet router infrastructure, and second, architectures that only implement additional reference resolution mechanisms. In the first category, hosts do not resolve identities to addresses but instead they directly send packets to the identities; an infrastructure exists to route the packets directed to identities. On the other hand, in the second category hosts resolve an identity (a reference) to an IP address and send packets to the address. In this section we consider three proposals. Internet Indirection Infrastructure (i3) [64] is an example of the first category, i.e., it introduces an overlay network that is capable of forwarding packets to hosts based on the identities. Delegation-Oriented Architecture (DOA) [69] and Semantic-Free Referencing (SFR) [8] are examples of the second category; they merely introduce a resolution infrastructure that hosts use to resolve identities to IP address(es).

4.7.1

Internet Indirection Infrastructure (i3)

Internet Indirection Infrastructure (i3) [64] introduces an overlay network and rendezvous-based communication abstraction. Hosts connected to the infrastructure rely on the forwarding capabilities of the infrastructure; they inject packets that contain a destination identifier and the infrastructure forwards the packets to hosts according to the identifiers. Identifiers them27


selves are opaque bitstrings from the i3 point of view, but in practice an identifier is a hash of an identifier that is more understandable for users. For example, one could use a host name as a source of hash. To receive packets, a host must register a trigger for an identifier to the infrastructure; after that the host becomes responsible for updating its current IP address to the trigger. As a result, the communication model is highly fault-tolerant. A new communication model opens a whole new set of security problems too, but with careful instrumentation the infrastructure is able to overcome most of the problems [1]. I3 effectively separates clients and services and replaces the current limited Internet routing infrastructure with its own forwarding infrastructure. The presence of a flexible forwarding infrastructure enables support for mobility, multicasting, and anycasting in a clean manner. Unfortunately, the trade-off is that all packets must travel through the infrastructure; the original i3 does not support direct communication between hosts. Recently, so called shortcuts have been implemented to support direct communication and to avoid extra hops in the communication path. However, the shortcuts are only an optimization; the default is the fault-tolerant rendezvous based communication model. For example, the current i3 implementation does not support smooth switching between shortcut and infrastructure based communication model. As a result, support for multi-homing and mobility with shortcut-based communication is rather inefficient. A native i3 support requires rather drastic changes to applications because the interface i3 provides for applications is different from the de-facto Berkeley socket API. Therefore, supporting applications by means of deploying proxies (both within hosts and networks) [26] seems a more viable option.

4.7.2

Delegation-Oriented Architecture (DOA)

Delegation-Oriented Architecture (DOA) [69] is an attempt to introduce middleboxes to the Internet architecture in an explicit manner. It builds on two principles: persistent host identifiers and routing of packets using the identifiers. However, unlike in i3, DOA does not introduce a forwarding infrastructure. Instead, each packet contains a stack of endpoint identifiers (host identifiers, that is) to define the route the packet must take. Each endpoint identifier resolves either to an IP address or to another endpoint identifier (or a series of endpoint identifiers). While packet travels through its route, each hop resolves the identifier of a next hop to an IP address. It should be noted that resolving may require multiple resolving transactions, as the resolving may not result in an IP address but other endpoint identifiers. DOA is based on ideas presented by Balakrishnan et al. [6]. The possibility to map endpoint identifiers to new endpoint identifiers is the key in facilitating middleboxes. For example, if a host is behind a NAT 28

4.8. IKEV2 AND EXTENSIONS

device, the host simply updates its endpoint identifier (in DHT) to map into endpoint identifier list consisting of the NAT’s endpoint identifier followed by its own identifier. In a way, the host delegates some of the responsibility to transmit its packets to other host. In this manner, packets that have the host as their destination travel via the NAT device. In addition to the bypassing of NAT devices, a host may also let another host to actually process its packets and their content. For example, the host could use a remote host as its firewall with a similar update to DHT as in NAT traversal’s case. The host itself would not accept any traffic besides the one coming from the remote firewall host.

4.7.3

Semantic-Free Referencing (SFR)

Semantic-Free Referencing (SFR) [8] architecture introduces a semantically free identifiers for objects (Web content, that is). In a way, it’s DOA on a different layer of the protocol stack; instead of resolving network layer addresses, a DHT is used to resolve identifiers of objects to a tuple of an IP address, port, and directive describing the content type. The underlying DHT as such is application-independent reference resolution infrastructure, i.e., it does not restrict how the identifiers are derived from user level descriptors: the identifiers are completely unstructured and semantic-free. As a result, the identifiers may become persistent pointers to objects as they do not contain any information, e.g., about the location of the object or how it is replicated.

4.8

IKEv2 and Extensions

IKEv2 [27] is the planned replacement for the IKEv1 [20] protocol. Basically, it is a secure key negotiation protocol for setting up IPsec security associations between two hosts. The use scenarios include using end-to-end IPsec and using a secure gateway. However, the basic IKEv2 protocol does not support host mobility. Mobile IKE (MobIKE) protocol [33] tries to enhance IKEv2 with mobility support. The main scenario concerns a Virtual Private Network (VPN) client moving from address to another without re-establishing Security Associations (SAs).

29


30

Chapter 5

Conclusions This report presented the overview and comparison criteria for the Host Identity Protocol. Furthermore, it identified the main related technologies to HIP, although the detailed comparison is left for future study. The comparison criteria were composed into groups on provided functionality, non-functional properties, deployment issues, economic aspects, and social issues. Each group included 2-7 specific points of comparison, such as security or scalability. An overview of HIP was given in the report, providing a brief summary of protocol’s capabilities with the emphasis on provided functionality and deployment issues. The related technologies were presented in the area of macro mobility, multihoming, architectural issues, signaling, security, and micro mobility. Overall, the report provided an overview of the HIP development space and should help the industrial partners with positioning of HIP in their technology roadmaps.

31

CHAPTER 5. CONCLUSIONS

32

Bibliography [1] D. Adkins, K. Lakshminarayanan, A. Perrig, and I. Stoica. Towards a more functional and secure network infrastructure. Technical Report UCB/CSD-03-1242, University of California at Berkeley, 2003. [2] J. Arkko. Failure detection and locator selection in Multi6: draft-arkkomulti6dt-failure-detection-00, Oct. 2004. Work in progress. Expires in April 18, 2005. [3] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to protect mobile IPv6 signaling between mobile nodes and home agents. RFC 3776, IETF, June 2004. [4] M. Atiquzzaman and S. Fu. TraSH-SN: A transport layer seamless handoff scheme for space networks. In Proceedings of the fourth annual Earth Science Technology Conference (ESTC), Palo Alto, CA, June 2004. [5] M. Bagnulo. Hash Based Addresses (HBA): draft-ietf-multi6-hba-00, Dec. 2004. Work in progress. Expires in June 22, 2005. [6] H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, I. Stoica, and M. Walfish. A layered naming architecture for the Internet. In Proc. of ACM SIGCOMM’04, pages 343–352, Aug. 2004. [7] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, and R. H. Katz. A comparison of mechanisms for improving TCP performance over wireless links. IEEE/ACM Trans. on Networking, 5(6):756–769, 1997. [8] H. Balakrishnan, S. Shenker, and M. Walfish. Semantic-free referencing in linked distributed systems. In Proc. of the 2nd International Workshop on Peer-to-Peer Systems (IPTPS ’03), Berkeley, CA, USA, Feb. 2003. Springer-Verlag. [9] S. M. Bellovin, J. Ioannidis, A. D. Keromytis, and R. R. Stewart. On the use of stream control transmission protocol (SCTP) with IPsec. RFC 3554, IETF, July 2003. 33

BIBLIOGRAPHY

[10] S. Brin and L. Page. The anatomy of a large-scale hypertextual web search engine. Computer Networks and ISDN Systems, 30(1–7):107–117, 1998. [11] A. Campbell, J. Gomez, S. Kim, and C.-Y. Wan. Comparison of IP micromobility protocols. IEEE Wireless Communications, Feb. 2002. [12] A. T. Campbell, J. Gomez, S. Kim, A. G. Valkó, and C.-Y. Wan. Design, implementation, and evaluation of cellular IP. IEEE Personal Communications Magazine, Aug. 2000. [13] C. Candolin, M. Komu, M. Kousa, and J. Lundberg. An implementation of HIP for Linux. In Proc. of the Linux Symposium 2003, Ottawa, Canada, July 2003. [14] B. E. Carpenter and S. W. Brim. Middleboxes: Taxonomy and issues. RFC 3234, IETF, Feb. 2002. [15] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Network mobility (NEMO) basic support protocol. RFC 3963, IETF, Jan. 2005. [16] Ericsson Research. HIP for BSD project, 2005. [17] A. Fessi, M. Stiemerling, S. Thiruvengadam, H. Tschofenig, and C. Aoun. Security threats for the NATFW NSLP: draft-fessi-nsis-natfwthreats-02. IETF Internet Draft, July 2004. [18] P. Francis. IPNL: A NAT-extended Internet architecture. In Proc. of ACM SIGCOMM’01, San Diego, CA, USA, Aug. 2001. [19] R. Hancock, G. Karagiannis, J. Loughney, and S. van den Bosch. Next steps in signaling: Framework: draft-ietf-nsis-fw-07.txt, November 2004. Work in progress. Expires in May 2, 2005. [20] D. Harkins and D. Carrel. RFC 2409: The Internet Key Exchange (IKE), Nov. 1998. [21] T. R. Henderson. Using HIP with legacy applications: draft-hendersonhip-applications-00, Feb. 2005. Work in progress. Expires in August 14, 2005. [22] Public key cryptography for the financial service industry: The elliptic curve digital signature algorithm (ANSI X9.62), Jan. 1999. [23] D. B. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6. RFC 3775, IETF, June 2004. 34

BIBLIOGRAPHY

[24] P. Jokela, P. Nikander, J. Melen, J. Ylitalo, and J. Wall. Host identity protocol: Achieving IPv4 - IPv6 handovers without tunneling. In Proc. of Evolute workshop 2003: “Beyond 3G Evolution of Systems and Services”, Nov. 2003. [25] A. Jungmaier, E. Rescorla, and M. Tuexen. Transport Layer Security over Stream Control Transmission Protocol. RFC 3436, IETF, Dec. 2002. [26] J. Kannan, A. Kubota, K. Lakshminarayanan, I. Stoica, and K. Wehrle. Supporting legacy applications over i3. Technical Report UCB/CSD04-1342, University of California at Berkeley, May 2004. [27] C. Kaufman. Internet key exchange (IKEv2) protocol, Sept. 2004. Work in progress. Expires in March 2005. [28] J. Kempf. Dormant mode host alerting ("IP paging") problem statement. RFC 3132, IETF, June 2001. [29] J. Kempf. Problem description: Reasons for performing context transfers between nodes in an IP access network. RFC 3374, IETF, Sept. 2002. [30] J. Kempf. Instructions for seamoby and experimental mobility protocol IANA allocations: draft-ietf-seamoby-iana-02.txt, June 2004. Work in progress. Expired in December, 2004. [31] J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, and X. Xu. Requirements and functional architecture for an IP host alerting protocol. RFC 3154, IETF, Aug. 2001. [32] S. Kent and R. Atkinson. IP encapsulating security payload (ESP). RFC 2406, IETF, Nov. 1998. [33] T. Kivinen and H. Tschofenig. Design of the mobike protocol, Feb. 2005. Work in progress. Expires in August 24, 2005. [34] M. Komu. Application programming interfaces for the host identity protocol. Master’s thesis, Helsinki University of Technology, Telecommunications Software and Multimedia Laboratory, 2004. [35] T. Koponen, A. Gurtov, and P. Nikander. Application mobility with Host Identity Protocol. In Proc. of NDSS Wireless and Security Workshop, San Diego, CA, USA, Feb. 2005. Internet Society. [36] S.-H. Lee, S.-H. Jeong, H. Tschofenig, X. Fu, and J. Manner. Applicability statement of NSIS protocols in mobile environments: draft-ietf-nsisapplicability-mobility-signaling-00.txt, Oct. 2004. Work in progress. Expires in April 18, 2005. 35

BIBLIOGRAPHY

[37] M. Liebsch, A. Singh, H. Chaskar, D. Funato, and E. Shim. Candidate access router discovery: draft-ietf-seamoby-card-protocol-08.txt, Sept. 2004. Work in progress. Expires in March, 2005. [38] J. Loughney, M. F. Nakhjiri, C. E. Perkins, and R. Koodli. Context transfer protocol: draft-ietf-seamoby-ctp-11.txt, Aug. 2004. Work in progress. Expires in February, 2005. [39] K. Malki, P. Calhoun, T. Hiller, J. Kempf, P. McCann, A. Singh, H. Soliman, and S. Thalanany. Low latency handoffs in mobile IPv4: draft-ietfmobileip-lowlatency-handoffs-v4-09.txt, June 2004. Work in progress. Expires in December, 2004. [40] J. Manner and M. Kojo. Mobility related terminology. RFC 3753, IETF, June 2004. [41] A. J. Maunuksela and M. Nieminen. Micromobility supported WLAN networks: an empirical study of new IP protocol to support mobility and connection handovers. International Journal on Mobile Communications, 3(2), 2005. [42] R. Moskowitz and P. Nikander. Host identity protocol architecture: draft-ietf-hip-arch-02.txt, Jan. 2005. Work in progress. Expires in August, 2005. [43] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson. Host identity protocol: draft-ietf-hip-base-02, Feb. 2005. Work in progress. Expires in August, 2005. [44] P. Nikander and J. Arkko. Delegation of signalling rights. In Proc. of the 10th International Workshop on Security Protocols, pages 203–212, Cambridge, UK, Apr. 2002. Springer. [45] P. Nikander, J. Arkko, and T. Henderson. End-host mobility and multihoming with host identity protocol: draft-ietf-hip-mm-01, Feb. 2005. Work in progress. [46] P. Nikander, J. Ylitalo, and J. Wall. Integrating security, mobility, and multi-homing in a HIP way. In Proc. of Network and Distributed Systems Security Symposium (NDSS’03), San Diego, CA, USA, Feb. 2003. Internet Society. [47] E. Nordmark and M. Bagnulo. Multihoming L3 shim approach: draftietf-multi6-l3shim-00, Jan. 2005. Work in progress. Expires in June 10, 2005. [48] A. M. Odlyzko. Smart and stupid networks: Why the Internet is like Microsoft. ACM netWorker, 2(5):38–46, Dec. 1998. 36

BIBLIOGRAPHY

[49] L. Ong and J. Yoakum. An introduction to the stream control transmission protocol (SCTP). RFC 3286, IETF, May 2002. [50] C. Perkins. IP mobility support for IPv4. RFC 3334, IETF, Aug. 2002. [51] C. Perkins. IP mobility support for IPv4, revised: draft-ietf-mip4rfc3344bis-01.txt, June 2004. Work in progress. Expires in November 11, 2005. [52] R. Ramjee, K. Varadhan, L. Salgarelli, S. R. Thuel, S.-Y. Wang, and T. L. Porta. HAWAII: A domain-based approach for supporting mobility in wide-area wireless networks. IEEE/ACM Trans. on Networking, 10:396– 410, June 2002. [53] Y. Rekhter and S. Thomson. Dynamic updates in the domain name system (DNS UPDATE). RFC 2136, IETF, Apr. 1997. [54] M. Riegel and M. Tuexen. Mobile SCTP, Oct. 2004. Work in progress. Expires in April 15, 2005. [55] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, and E. Schooler. SIP: Session initiation protocol. RFC 3261, IETF, June 2002. [56] S. Salsano, L. Veltri, and D. Papalilo. SIP security issues: The SIP authentication procedure and its processing load. IEEE Network, 16(6):38– 44, Nov. 2002. [57] M. Sarela and P. Nikander. Applying host identity protocol to tactical networks. In Proceedings of IEEE Military Communications Conference (MILCOM2004), Oct. 2004. [58] A. Snoeren and H. Balakrishnan. An end-to-end approach to host mobility. In Proc. of ACM MOBICOM’00, Boston, MA, USA, Aug. 2000. ACM Press. [59] H. Soliman, C. Catelluccia, K. E. Malki, and L. Bellier. Hierarchical mobile IPv6 mobility management (HMIPv6): draft-ietf-mipshophmipv6-04. Internet draft, IETF, Dec. 2004. Work in progress. Expires in June 2005. [60] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, and P. Conrad. Stream control transmission protocol (SCTP) dynamic address reconfiguration, Jan. 2005. Work in progress. Expires in July 31, 2005. [61] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream control transmission protocol. RFC 2960, IETF, Oct. 2000. 37

BIBLIOGRAPHY

[62] R. Stewart and X. Xie. Stream Control Transmission Protocol (SCTP). Addison-Wesley, Nov. 2001. [63] M. Stiemerling and J. Quittek. Problem statement: HIP operation over network address translators: draft-stiemerling-hip-nat-02.txt, Oct. 2004. Work in progress. Expires in April 2005. [64] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana. Internet indirection infrastructure. In Proc. of ACM SIGCOMM’02, Pittsburgh, PA, USA, Aug. 2002. [65] S. Thiruvengadam, H. Tschofenig, and F. Le. Mobile IPv6 - NSIS interaction for firewall traversal: draft-thiruvengadam-nsis-mip6-fw01, Oct. 2004. Work in Progress. Expires in April 23, 2005. [66] S. Vaarala and E. Klovning. Mobile IPv4 traversal across IPsec-based VPN gateways, Jan. 2005. Work in progress. Expires in June, 2005. [67] A. Vasilache, J. Li, and H. Kameda. Threshold-based load balancing for multiple home agents in mobile IP networks. Telecommunication Systems, 22(1–4):11–31, 2003. [68] VMware Inc. VMware VirtualCenter product datasheet, 2005. [69] M. Walfish, J. Stribling, M. Krohn, H. Balakrishnan, R. Morris, and S. Shenker. Middleboxes no longer considered harmful. In Proc. of the 7th USENIX Symposium on Operating System Design and Implementation (OSDI 2004), San Fransisco, CA, USA, Dec. 2004. ACM Press. [70] E. Wedlund and H. Schulzrinne. Mobility support using SIP. In Proc. of the 2nd ACM international workshop on Wireless mobile multimedia (WoWMoM’99), Aug. 1999. [71] B. Wellington. Secure domain name system (DNS) dynamic update. RFC 3007, IETF, Nov. 2000. [72] K. D. Wong, A. Dutta, J. Burns, R. Jain, and K. Young. A multilayered mobility management scheme for auto-configured wireless IP networks. IEEE Wireless Communications, 10(5):62–69, Oct. 2003. [73] W. Xing, H. Karl, and A. Wolisz. M-SCTP: Design and prototypical implementation of an end-to-end mobility concept. In Proc. of the 5th Workshop on the Internet Challenge: Technology and Applications, Berlin, Germany, Oct. 2002. [74] J. Ylitalo. Re-thinking security in network mobility. In Proc. of NDSS Wireless and Security Workshop, San Diego, CA, USA, Feb. 2005. Internet Society. 38

BIBLIOGRAPHY

[75] J. Ylitalo, J. Melen, P. Nikander, and V. Torvinen. Re-thinking security in IP based micro-mobility. In Proc. of 7th Information Security Conference (ISC04), Sept. 2004. [76] J. Ylitalo and P. Nikander. BLIND: A complete identity protection framework for end-points. In Proc. of the Twelfth International Workshop on Security Protocols, Apr. 2004.

39

Overview and Comparison Criteria for the Host Identity ... - CiteSeerX

Overview and Comparison Criteria for the Host Identity ... - CiteSeerX

Suggest Documents