Independent Local Locator Substrate Indirection Transport ILLSIT

Transcription

1 Independent Local Locator Substrate Indirection Transport ILLSIT Supervisor Mats Björkman Mälardhalens University MAIL Javier Ubillos SICS MAIL Student Pablo Santibanez Jara Mikael Svensson

2 Abstract Interoperation between IPv4 and IPv6 on a global scale is largely an unsolved problem, and in principle a problem without a proper solution. The 32 bit IPv4 address can simply not express all possible IPv6 hosts. Today, IP plays a double role. It is both a topological locator as well as a host identity. By decoupling the two roles a communication could also span over incompatible locator domains (e.g. IPv4 and IPv6). The Host Identity Protocol (HIP) [RFC 5210] uses this decoupling by providing two discrete data structures, one for the host identity and one for the interfaces locator. By extending HIP to allow differently formatted locators, and with the help of an Identity Router, one could cross past differing locator domains without the individual hosts needing to be configured for any particular domain other than their own. The goal of this thesis is to investigate possible methods and architectures to allow this kind of locator domain interoperability and to implement a proof of concept gateway. The first part of the thesis consists of the exploration of the problem domain. Collecting the requirements of HIP enabled hosts, and to define a method for the interoperability of two HIP-hosts residing in two differing locator domains (IPv4/IPv6 will be assumed for scope limiting purposes). The output of this part will be a set of requirements, a suggested solution and a rationale for the chosen solution. The second part consists of the design and implementation of the required components for the interoperation. At the time of writing, the foreseen components will be: a parameter to HIP and a gateway, however, this is subject to change depending on the output of part one. The expected output of part two is a design specification, an implementation plan for the components and finally the implementation of the defined components.

3 Table of content Table of content... 3 Abbreviations... 5 Background and purpose... 6 Related work (relevant theory)... 6 *.1 Host Identity Protocol... 6 *.1.1 Current IPv4, IPv6 namespace and identifiers... 6 *.1.2 Base exchange... 7 *.2 Similiar protocols... 7 *.2.1 MobileIP... 7 *.2.1.1Mobile IP base... 8 * Home agents and foreign agents... 8 * Similarities... 9 * Current use... 9 *.3.1 i * i3 base * Mobility * Similarities * Differences * Current use *.4.1 Shim * Shim6 base * Mobility * Similarities *.0 Problem formulation *.1 Background problem *.1.1 SICS-ONE router *.2 Scope *.0 Analysis of problem *.1 Requirements *.1.1 Packages and IP header *.1.2 DNS, DHT, HOST *.1.3 Parameters *.0 Model/method... 17

4 *.1 Gateway concept *.2 Rendezvous server *.2.1 Relay service *.0 Solution *.1 Possible solutions *.1.1 Relay server * Build the gateway *.0 Results, analysis of results, recommendations, future work *.1 Chosen solution *.2 Gateway project *.3.0 Results *.3.1 Handshake and ESP with HIPL client and server *.3.2 Handshake and ESP with non-hipl client and server *.3.3 ESP and birthday problem *.3.4 HIP and mobility with the gateway *.4 Recommendations *.4.1 Security *4.1 Birthday problem *.5 Future work *.5.1 Development of a gateway *.5.2 Coding Summary and conclusions Summary Conclusion References Appendix Tips... 27

5 Abbreviations API Application Programming Interface DHT Distributed Hash Table DNS Domain Name System DoS Denial of Service ED Endpoint Descriptor FQDN Fully Qualified Domain Name HIP Host Identity Protocol HI Host Identifier HIPL HIP for Linux HIT Host Identity Tag IETF Internet Engineering Task Force Initiator Host that wants to start a association IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 IPSec Internet Protocol security I3 Internet Indirection Infrastructure LSI Local Scope Identifier Responder Host that responds to an association request RR Resource Record RVS Rendezvous server SSH Secure Shell TCP Transport Control Protocol UDP User Datagram Protocol UI User Interface WLAN Wireless Local Area Network

6 Background and purpose There is a lot of work done in this area when it comes to implementing and using gateways, but there is no real implementation that would suit the new protocol such as the host identity protocol. The company we are doing this thesis for (SICS) have done a similar solution with another company and that code is closed due to licensing and therefore cannot be used in commercial products such as a router. The goal of the work is to implement a solution that would show that there can be implemented open solutions for commercial use and in this specific case be used in a router that SICS have developed. Related work (relevant theory) In this chapter we are go through HIP and similar protocols to give the reader what the important parts in mobility and security that has to be kept in a solution. *.1 Host Identity Protocol *.1.1 Current IPv4, IPv6 namespace and identifiers In current internet with the use of IPv4 and IPv6 the IP address represent a route where the packets should go, how to get to their destination (routing) and who the receiver its(endpoint) as seen in Figure 1. This is used both in the network layer and later then in the transport layer, thus this limits the mobility of a connection as it only consist as long everything stays the same in every layer. Figure 1The role of IP The host identity protocol(hip) [ architecture separates the end-point identifier and locator from each other, it takes the role as end point identifier and uses the IP address as locator as seen in Figure 2. The host identities (HI) are not just names for the interface but it is also a public key. The HI is able to be reached and used by several interfaces at the same time as a machine using HIP can use several HI s and a HI can be moved between physical devices without breaking the transport association established with HI as HIP lies like a waist between the transport layer and IP addresses as seen in Figure 3. As HI is a public identifier and may vary in length HIP uses host identity tags (HIT) that is a 128-bit long hash of a HI to actual represent the HI, as a HIT has the same length as a IPv6 address it can be used in the same address fields that a IPv6 address can.

7 Figure 2 The new HIP namespace HIP also provides mobility, as when a connection is not bound to an IP but a HI thus the IP can change when needed by a mobile device, a HIP association can also be bound to several normal IP addresses if wanted. Figure 3 HIP as a waist between the transport layer and IP *.1.2 Base exchange HIP does not just introduce a decoupling but also introduces a four-way-handshake [ as shown in Figure 4. Figure 4 HIP handshake The handshake happens when a host (Host A) wants to connect to another host (Host B). The handshake has the following procedure simplified: 1. Host A sends an initiator I1 package. 2. Host B sends a reply package R1 with a puzzle that has to be solved by Host A. 3. Host A replies with the solved puzzle I2. 4. Host B acknowledges the solved puzzle and send a R2 packet. 5. A ESP connection is established for sending further data. *.2 Similiar protocols *.2.1 MobileIP In this section we take a look into the working of an internet protocol called Mobile IP Mobile IPv4 ( Mobile IPv6 ( and Mobile IPv4\IPv6 (

8 *.2.1.1Mobile IP base This protocol Mobile IP is similar to HIP, as it wants to resolve the issue with the end-to-end connectivity by having locators that does not change when traversing different subnets with mobile nodes (MN). A MN needs to be configured to have a home agent (HA) that is sets up an association with to communicate to correspondent nodes (NA) in the internet The protocol doesn t have HIT s as HIP have but instead keeps the original IP given by its HA as shown in Figure 5 when visiting other subnets, when visiting other subnets it connects to CN and HA through a foreign agent (FA). Figure 6 A mobile node moving from one subnet to another * Home agents and foreign agents The use of the FA and HA can be compared to HIP s use of RVS where MN s can keep connection with a correspondent node (CN) without tearing down existing links between them when changing subnets. It has as HIP a special way to update its change of subnet so CN always can reach the MN. In the case of Mobile IP a MN needs to always communicate with a CN through its HA, this means if a MN changes to another subnet with a FA it still goes through the HA when communicating with a CN. This can introduce to much delay and links can go down just because a node did not get packages within some timeslot. Therefore there is a route optimization extension for Mobile IPv4 to introduce triangular routing between the MN and CN, this means that instead of going through the HA a MN can communicate with a CN through the FA instead as shown in Figure 7. In Mobile IPv6 a MN can establish direct association with a CN instead of using a FA, when a MN is in the its home subnet it works similar as if it were using Mobile IPv4 and all communications is directed through its HA. Figure 7 A mobile node talking with a correspondent node through a foreign agent (Mobile IPv4) * Foreign agent and home agent tables HA and FA needs to keep track of who is a node belonging to the subnet using a mobility binding see Figure 8 and visiting nodes in a visitor list see Figure 9. Both lists are so that

9 packets are forward accordingly to the MN s. Each MN has a care-of address that can been seen as a routing address, in its home subnet the care-of address the MN s IP when being in a FA the MN updates it care-of address in the HA and replaces it with the FA s address. This happens while the FA puts the MN s HA and the care-of address of the MN in its visitor list. Mobile IP uses IPSec and the ESP to further send the data between the connected nodes as HIP. Mobile IP has the problem that with IPv4 and IPv6 it needs two protocols defined Mobile IPv4 and Mobile IPv6 to be able to take care of IPv4 or IPv6 packages, there is a suggestion to merge Mobile IPv4 and IPv6 to a single protocol [link to that rfc] but this is out of the scope of this document. Figure 8 Mobility binding in home agent Figure 9 Visitor list in a foreign agent * Similarities The Mobile IP protocol implements the following things that are similar to each other; Both have a locator that doesn t need to change when (passing through)/(switching) different subnets. Both use nonce s to protect itself from reply attacks, in the case of Mobile IP the nonce is done when doing registration requests on HA and FAs and in the case of HIP the nonce also called R1 generation counter is used to protect when handshaking, there is also a nonce when doing UPDATE: After a communication has been established both uses IPSec ESP for further communication. The HIP RVS can be seen as a HA or FA in Mobile IP against CN. * Differences One of the main differences is the initial handshake, there is no defined handshake for Mobile IP but we guess that a state is created as in normal TCP/IP handshake, there is a paper on the subject on introducing the HIP handshake for Mobile IP. [reference to paper] While a MN requires that it registers to a HA or a FA the HIP node can skip the RVS association if the MN knows where to connect to. * Current use The biggest use of Mobile IP right now is incorporated with Voice over Internet Protocol (VoIP) thou VoIP may use other technologies than Mobile IP. Usually the way of use requires signing up to a service and then users have to connect to the internet with their mobile phones or computers using WLAN/Wi-Fi. *.3.1 i3 I3 is deployed using indirection to get around the problem with end-to-end mobility. I3 is a simple but powerful technique that assumes physical or logical indirection point interposed between sender and receiver that relay traffic between them instead of sending a packet directly to its final destination. The packets are associated with an identifier that is utilized by the remote host to receive the packet. [

10 * i3 base Internet Indirection Infrastructure (i3) implements a rendezvous-based abstraction. i3 is an overlay network that uses Chord[ protocol to route data. The i3 network is a set of servers that store triggers and forward packets between endpoints. The address of an end-point consists of an IP address and a port number. Packet and trigger identifiers are represented by strings of 'n' bits. Triggers are comparable to routing entries. However there are a few differences, routing entries on the Internet are updated and maintained by special routing protocols, triggers are openly maintained by end hosts. This gives end-hosts more flexibility and control in choosing the identifiers and the paths where they want their packets to propagate. Assumptions are made that each end-host knows a list of servers, which is obtained via a bootstrapping mechanism when the end-host joins the i3 network. When a packet is sent by an end-host it is handed to an i3 server. When the i3 server receives a packet it will search for the trigger matching the packet. Triggers that are matched in this way tell the server to forward the packet to the end-point with the matching trigger and the correct address. [WX-i3] Shown here in the figure R inserts a trigger (id,r) to obtain all the packets that associates with id. [ i3 will not store packets in any way, it only forwards them. i3 is more of a best-effort implementation service. i3 includes neither reliability nor ordered delivery on top of the IP protocol. To keep the trigger tables up to date periodic updates are made by the end-hosts. When an end-host fails its triggers are automatically deleted from the i3 servers. However if there is a failure on the i3 server side and triggers are lost they will be reinserted next time the end-host refreshes it. To find triggers matching a given packet i3 use a lookup service that maps an identifier space to a set of servers. If you are given an id the lookup service will find the server that is responsible for that id and from that point able to localize the endhost. The format of a trigger that is stored on a responsible server is (id, addr) and this makes it really easy to match an id. A packet consists of (id, data) and will be forwarded based on its id on the overlay network to the same responsible server then to be matched to the trigger and forwarded to addr via IP. [WX-i3] * Mobility The form of mobility addressed here is when a host (e.g., a laptop) is assigned a new address when it moves from one location to another. A mobile host that changes its address from R1 to R2 as a result of moving from one subnet to another can maintain the end-to-end connectivity by simply updating each of its existing triggers from (id, R1) to (id, R2). The sending host does not need to know of the mobile host s current location or address. Furthermore, since each packet is routed based on its identifier to the server that stores its

11 trigger, no additional operation needs to be done when the sender moves. Thus, i3 can preserve end-to-end connectivity even when both end-points move simultaneously. [WX-i3] When the host moves around and changes its address from R1 to R2, the trigger is updated from (id, R1) to (id, R2). [ * Similarities Triggers can be compared with HIT s as it is a form of keeping track on end-hosts. Both have a locator that doesn t need to change when (passing through)/(switching) different subnets. Both offer mobility. The HIP RVS can be seen as an i3 server. * Differences One of the main differences is the initial handshake, as there is none for the i3. The fact that i3 gives it s end-hosts full control on routing it opens up for DDoS attacks. A malicious user can insert a new hierarchy of triggers where all the triggers point to the selected victim. No encryption is used. Since i3 allows end-hosts to just refresh the trigger list themselves they can just add new triggers and join the network. There is no strict registration needed. * Current use Areas of use including i3 are proxies; secure intranets and NAT where the routing flexibilites of i3 can be used. Some applications may require third parties to process the data before it reaches the destination. An example is a wireless application protocol (WAP) gateway translating HTML web pages to WML for wireless devices. WML is a lightweight version of HTML designed to run on wireless devices with small screens and limited capabilities. In this case, the server can forward the web page to a third-party server that implements the HTML-WML transcoding, which in turn processes the data and sends it to the destination via WAP. In general, data might need to be transformed by a series of third-party servers before it reaches the destination. In today s Internet, the application needs to know the set of servers that perform transcoding and then explicitly forward data packets via these servers. With i3, this functionality can be easily implemented by using a stack of identifiers.

12 *.4.1 Shim6 This protocol specifies a layer 3 shim approach and a protocol of its own to provide locator quickness under the transport protocol. It gives some extra features such as IPv6 failover, multihoming and load balancing properties. Failover using different locator pairs are very beneficial if the original one should stop working. [WX-shim] Shim6 protocol stack uses static endpoint identities. It refers both to itself and a remote protocol stack. The shim layer offers a set of associations between endpoint id pairs and locator sets. [ * Shim6 base When packets are passed from the IP endpoint sub-layer to the IP routing sub-layer an association is made to a current pair of locators. When receiving packets a reverse mapping is made on the packet to remove the locator pair then to associated endpoint identity pair with the packet, which is then passed to the IP endpoint sub-layer. The shim6 approach is that the endpoint id and the locators are both IP addresses. When communicating, the endpoint id is the primary address to be used between two hosts. The locators used are just a set of IP addresses that are being associated with the endpoint in order to keep track. This method increases the efficiency regarding changing dynamic locators in the protocol stack. This makes it easy for a host to initiate a session by using a regular DNS[ lookup on the remote hosts hostname using one of its addresses as the destination address. Packets can continue to be exchanged with the remote host during the session by simply continue to use the same destination address. If the local host later on starts a new session with the same remote host the same destination address can be used. The functionality offered with shim6 changes nothing to the use of addresses or endpoint identifiers in the regular IPv6 architecture. Shim6 does not initiate a new identifier name space; instead it uses the locator that is selected in the initial contact with a new remote peer. It preserves

13 upper-layer identifier (ULID). The upper-level protocol will continue to use upper-level identifiers even though there could be failures to the network-level locators. Thus eliminating excessive faults. [WX-shim2] * Mobility The protocol stack uses endpoint ids to refer the local and remote protocol stack and therefore the shim layer can provide a set of associations between the endpoint identity pairs and locator sets in order to keep track. * Similarities The similarities with HIPL protocol are that it uses a set of identifiers to refer to locator pairs to keep track on end-points. Uses locators that get updated. It offers mobility.

14 *.0 Problem formulation *.1 Background problem Due to the extensive use of old equipment and systems that relies on ipv4 fundamentals the legacy network and the new network needs a bridge to be done to reduce the impact of costs and work needed to upgrade to new equipment and systems. The bridge would provide interoperability between the legacy systems and new ones thus providing a platform that would not disturb the current dynamics of the internet. This bridge does exist for the current normal IPv4 and IPv6 protocols but as we are working with HIP a bridge that supports HIP doesn t exist as of yet. *.1.1 SICS-ONE router The general idea was to add this functionality to the SICS-ONE router developed at SICS. SICS-ONE router aims towards how to overcome the obstacle of different address schemes between the IPv4 and the IPv6 domains using a set of gateway servers. The gateway servers provide the necessary abstraction of network addresses by routing the traffic between the communicating nodes using a routing hint (HINT) [UA]. The gateways are reached using anycast and DNS, also providing redundancy. Gateway addresses and routing hints are provided by DNS together with the host identity. The solution builds on the ideas provided by the Node Identity architecture. Interoperation between the two namespaces IPv4 and IPv6 is largely an unsolved problem seen on a global scale perspective. Since IPv4 consist only of 32 bits it is not possible to express all the available IPv6 hosts. A global migration to IPv6 would seem unrealistic due to legacy hardware and software not to mention all the excessive work needed. To solve this problem with 'ease' the SICS-ONE router with this extra functionality would be most beneficial. *.2 Scope Our task is to implement a gateway (GW) [ that will act as a bridge needed for interoperability between a HIP host in an IPv4 only network and a HIP host in an IPv6 only network. This is going to be implemented into a router mentioned in chapter *.1.1. The test scenario will be that we will have two hosts, A and B, A wants to send something to B using HIP, but A is in an IPv4 network only and B is in an IPv6 network only, but it can go the other way around as well. Host A does not know the more about B than its hostname lets says piff.com. Host A needs to ask a DNS about the HIT or IP address of B, the DNS does a lookup and sees that B is in a different network than A. When the DNS return the query it needs to return the address of a gateway and the address of B (B s address is what we would call a HINT) and the additional HIP information like HIT. The name lookup sees that there is an additional address returned it puts the address as a HINT, the HINT is then added to the HIP packages as a parameter called RR_HINT. The package is sent to the gateway in the following way: IP header s FROM field is A s address. IP header s TO field is the GW s address. HIP parameter RR_HINT contains B s address

15 The gateway gets the packages reads it and sees that the parameter RR_HINT is included thus it does the following changes: IP header s FROM field is changed to the GW s address. IP header s TO field is the B s address. HIP parameter RR_HINT contains A s address. Then sends the package to B using the correct protocol (in this example IPv6) that is required to send it from the GW to B. B then processes it as an ordinary package with the exception it always append the RR_HINT parameter that it has received in from the gateway. Then B sends all the replays to A through the GW, see Figure X1 for info how the packages are sent. Figure X1 How the communication between a Host A, the DNS, the GW and Host B goes. After the HIP handshake has taken place an ESP association should be saved in the gateway so the esp traffic between the hosts are routed through the gateway i.e. that the gateway will now work like a SPI-NAT, meaning it matches the SPI s that is used to identify esp packets and are routed to a specific host.

16 *.0 Analysis of problem *.1 Requirements *.1.1 Packages and IP header The packages must use HIP, we have to be able to modify the packages sent between two hosts in the GW so they get the right TO and FROM fields in the IP headers as seen in Figure X2. Figure X2 How the to headers have in their fields, 1, 2 are packages going to host B and 3, 4 are packages going to host A. *.1.2 DNS, DHT, HOST When a host makes a query for a specific address it should get back the address of the gateway and the address of the host it is trying to reach as seen in Figure X3. Figure X3 Query about B and an answer to with IP to the gateway and IP of B as a HINT *.1.3 Parameters The packages have to carry information where it is headed, where it is from and the address to the gateway, as the HINT information cannot be put in an ordinary IPv4 or IPv6 header we have to add this information to the HIP section of the package as a parameter see Figure X3.1. This parameter is later processed by the gateway. Figure X3.1 How the HIP parameter can be in the HIP package.

17 *.0 Model/method There are several methods to solve this kind problem between two networks running different protocols and one of them is to have some kind of bridge that translates from one protocol to another. We call this method for a gateway that has as purpose to translate from one specific protocol to another. There is also a possible solution that is introduced with HIP, the solution is using a rendezvous server (RVS) [reference to forward packages as a gateway between two HIP enabled hosts. RVS as it is now only handles the handshake, a third solution would be using a relay server that is a experimental relay developed by a group of people. *.1 Gateway concept Gateways also called protocol converters are a software and/or hardware implementation made to interconnect different nodes or networks using different protocols. Usually it must convert one stack into another regarding the different use of protocols. It allows us to set up a bridge and communicate with IPv4 and IPv6 over HIP. The different devices included in the gateway may vary from protocol/fault/signal translators, impedance matching and rate converters. *.2 Rendezvous server The Host Identity Protocol (HIP) Architecture has introduced a rendezvous mechanism to allow contact from a HIP node and a moving mobile HIP node or a HIP node that wants other means to be contacted as. This mechanism includes a third party service, the RVS server to allow this transition. A RVS Server allows a HIP client to connect to the RVS s IP and from there match a HIT of the final destination where the information will be later sent. This allows multihoming and increased mobility when HIP nodes notify their peers when changes occur in the set of IP addresses used. This covers the initial part of a base exchange but as seen in the picture the rest of the communication is set between the hosts thus if the hosts are in different network types it won t work see Figure X4. Figure X4 The use of a RVS server. *.2.1 Relay service The relay service is a mechanic to address the issues that are brought up in RFC 5203[reference ] and RFC 5207[reference ], where HIP enabled hosts are behind NAT s but can be used as well for hosts that are in different networks for solving mapping issues. The Relay can be used in a RVS or implemented as a standalone service, implementing the

18 relay functionality will make the RVS a relay i.e. a gateway for HIP hosts to use see Figure X5. One difference to a gateway is that in a RVS or a Relay is that the responder has to register itself with the relay server, as it has to do with a RVS. [Reference later] Figure X5 Relay service Thus, the following steps have to be done: 1. Responder (B) has to register itself with the RVS. 2. Initiator (A) query s the DNS for B s information. 3. DNS sends back the IP of the relay but uses the HIT of B in the package. 4. The initiator connects to RVS with the provided IP and uses the HIT of B in the package sent. 5. The relay maps the package from the initiator using the HIT of B and sends the packages to B. 6. Packages from the responder are relayed through to A through the RVS. The main step that has to be avoided in the solution we have to provide is step 1 in the above section, i.e. that there is no association in the gateway until an initiator tries to a connection to a responder through the gateway, this is discussed in the next chapter. We can show one setup example here using the HIPL projects RVS and Relay service. Start HIPD in all the host that will act as a relay In host that will act as a relay issue command: hipconf add service relay At the host acting as a responder type: hipconf add server relay <RELAY-HIT> <RELAY-IP> <LIFETIME-IN-SECONDS> You will have to do additional configuration right now for it to work with the HIPL implementation.

19 *.0 Solution *.1 Possible solutions Two possible solutions were discussed with the supervisor, one is to make use of the relay server as it is already implemented and another is to build the gateway using the HIPL [reference och länk till HIPL] group s code as base. Compared with OpenHIP[ that is an alternative solution there was just not that much activity on their development team as HIPL when choosing the Base to build our project on. *.1.1 Relay server The first solution were the use of a relay server is used has the advantages that there is no requirement to implement anything, it would work with existing implementations of dht and dns services and no more mapping between hosts would be needed. The disadvantage of this is that there has to be a specific relay server to connect to, as the host who wants to initiate the connection has to connect to a relay server that has the wanted host registered to it. Thus, the connecting host cannot just initiate a connection to an arbitrary client, it has to know the relay server in advance that has the specific client who is registered on that server. * Build the gateway The second solution to build a gateway with the HIPL-projects code as base would take more time, but as time is no concern as there is enough time allocated for this thesis this solution is feasible within the time constraints. This would do as long the requirements being set by the supervisor are hold between realistic boundaries that can be completed by the time this thesis. The disadvantage with this method is that as the HIPL code is in current development, thus using the code from HIPL as base there is the need to choose a release from the HIPL group that is stable enough to use. This is to make the solutions developed under the time the thesis progresses not to be broken as new releases of the HIPL are released. As the HIPL code is going to change in the time we are doing this thesis, the solutions we implement are not going to have any support outside this thesis work. This requires also the use of a HINT parameter that has to be implemented from an already defined definition [reference som där länkas till javs arbete om HINT]. * SPI-NAT As a association for the traffic after the handshake should be established there has to be some database in the gateway that saves and can be used to map between the SPI and addresses from each host so that esp packets are routed correctly.

20 *.0 Results, analysis of results, recommendations, future work *.1 Chosen solution We picked Linux due to it is a widely used technology with extensive documentation and support. The chosen solution was to implement our own gateway with the HIPL code version release 42 that was released in June 2009 as base. Choosing the HIPL code as base was chosen so that if the results of this thesis are chosen to be continued by the HIPL team there is known code that they can work with. *.2 Gateway project By following the steps mentioned in the attachment 1 [Installing-hipl.doc] we created our own folder called gateway in the HIPL HIP source file package. All the perquisites needed and working operating system we have choose is explained in the attachment 1. We have all the needed code in the folder [source files]/gateway. How the computers used were setup is explained in the attachment 2 [System-setup.doc]. *.3.0 Results *.3.1 Handshake and ESP with HIPL client and server The result of the thesis work and working with the gateway code can be seen in the following see Figure X6 that is a cropped screenshot from a Wireshark capture on the host that is running the gateway. Figure X6 Wireshark capture This shows as the system setup document shows the attachment 2 [System-setup.doc] that the handshake is done through the gateway and then a ESP association continues between host A (Initiator) and host B (Responder) through the gateway. Figure X7 and Figure X8 show the Initiator and Responder after a successful send and receive of the package.

21 Figure X7 The client sending a message hai Figure X8 The server receiving the message hai and replying Due to the lag between Host A the gateway and then Host B there will be a lot of resends of packages in the handshake as it seem that the HIP daemon requires a reply in a short period of time. This we just encounter with the HIP handshake, the ESP traffic seems to be more tolerate when it comes to how it waits for a reply before a resend. *.3.2 Handshake and ESP with non-hipl client and server We tried doing some ping6 1 test between an Initiator and Responder and could not establish an association because somewhere in the program of ping6 it did not accept the address given to it by the hipl tool used. It seems the address resolve was stuck in a loop that it could not get out off, thus the handshake did not work so the test failed. We tested this with an already established association between the Initiator and Responder i.e. that a handshake had taken place, when we then tried ping6 the test was successful as no handshake needed to be done and the traffic was encrypted with ESP between the hosts. Due to time constraints, we could not fix this and all the debugging with different tools were not possible because the debugging tools crashed when trying to check for errors in the 1 ping6 is a program to perform ping test using the IPv6 protocol between hosts.

22 program, as the debugging tools worked without a problem with the other parts of the code we could not investigate this problem further as the time ran out. *.3.3 ESP and birthday problem As we have done the database of the gateway in such way that there is a unique SPI for all the associations between different hosts we will encounter something that is called the birthday problem/paradox [ In large networks, SPI collisions are quite probable, compared to collision in large end-point identifier namespaces. Therefore, we strongly suggest a limited amount of users/sessions per router. Allowing the ISP to segment their networks and distribute these gateway routers strategically to avoid collision rates above 1%. We have used MATLAB to calculate the risk of collision for 100, 1000, 10000, 25000, and concurrent sessions, the result and 100 and 1000 were eliminated due to the results of the calculations were 0% collision risk. The remaining results are presented below in Figure X8.1 (10000 sessions), Figure X8.2 (25000 sessions), Figure X8.3 (50000 sessions) and Figure X8.4 ( sessions) using the code shown in attachment 3. Our estimation is that each user has 100 concurrent sessions. Calculating the collision rate in a 32-bit environment, our results show us that concurrent sessions will have roughly 1% collision rate. From our previous assumptions that each user has 100 sessions this gives us the total amount of users per router limited to 100. To build a reliable and smooth network topology these routers need to be deployed at each apartment block/building. This is our own guess, as we have not found any real data about this. Searching for this kind of data was not in the scope of this project. We found our results reasonable and satisfying reading about LSI/SPI finding out the fault limitations. Figure X concurrent sessions, 1.14% collision risk Figure X concurrent sessions, 6.91% collision risk Figure X concurrent sessions, 25.35% collision risk Figure X concurrent sessions, 68.9% collision risk

23 *.3.4 HIP and mobility with the gateway The gateway cannot verify any packet it receives from a sender, there would be a security risk to just change association i.e. drop the current association and establish a new one between the hosts. HIP has some security parameters to verify packages it that are sent by having signatures and HMAC s as parameter whose calculation are based on the HIP-header and parameters, this means that there is no problem in changing the IP-header and route an update package as normal in the gateway. The behavior of our implemented gateway is now that when an update package come the gateway will relay the package and begin establishing a new association for the hosts. This only applies to update packages that are for establishing a new ESP-SPI association, but the old association will be kept and will be only dropped if it has not been used for 7200 seconds. There are some proposals to solve this security issues between hosts and middle boxes such a gateway, the security problem may be solved by introducing an additional nonce and challenges as discussed in End-Host Authentication for HIP Middleboxes [ * Changing IP and HIPL If a host changes its IP-address and it wants to tell the other host that it has changed IP, so for an ip-update package to reach the corresponding host it has to traverse the gateway. In the current implementation of HIPL is that even if a host initiates an IP change but have not changed the IP the update package is processed as an IP change by HIPL. Even if it seems strange, there is nothing in the HIP standard this will break against, so packages that are relayed through the gateway would have the IP header changed without the risk that the receiving host will drop those packages and the update procedure will be done as normal see Figure X9. Figure X9 A normal IP change, Host A changes IP sends a Update package and then update packages with ack s are sent and if all goes well a ESP association is set between the hosts. *.4 Recommendations *.4.1 Security Recommendations for future work with a middleware like a gateway would be that there is added security to the gateway, this could range from that the gateway verifies the sender with calculations of the signatures and HMAC s and response to update packages with some kind of challenge. *4.1 Birthday problem There should be some hash that can guarantee there will be a very small probability of collisions in the association database of the gateway, such that there is no birthday problem

24 that is needed to be considered and possible to move the gateway from the apartment building to the ISP s distribution layer. *.5 Future work *.5.1 Development of a gateway From a security perspective, the gateway SHOULD inspect packets received to verify that it is from a legitimate sender as it is now it cannot confirm any packets and just forward it, just forwarding could leads to vulnerability of DDoS or other malicious denial of service attacks. There are proposals that you introduce another 4-way handshake to verify packets received in the middle-box also known as gateway in this case [ The HIP-host could include the challenge request and response to solve the security issues involving UPDATE packages in HIP and the association between hosts going through a middle-box or gateway in our case. *.5.2 Coding If someone is going to work the code in the future and then the following things should be done that have not been done by the time this report was written. Divide the IPv4 and IPv6 thread that handles the handshake into two threads instead of being one as it is now, this will probably speed up things. As different threads manipulate the SPI database there is no critical section coordination between the different threads so information can right now be deleted or added into the database with no control and will probably result in consistency problem when handling too many hosts. Use the HIPL standard for coding, the HIPL groups uses a standard for coding HIPL and we have not used it so it should be advised to use it in the future. A better lookup system for the DNS, right now it uses three dig calls, a proper dns call should be done with a response that can be parsed that contains all the necessary information with just one lookup i.e. the lookup returns IP of Host A, IP of Host B and HINT.

25 Summary and conclusions Summary As the new IP header (IPv6) is being implemented worldwide there is a gap between the old solution (IPv4) and the new when it comes to support by hardware or software. To replace or update existing hardware/software may carry such a high cost in money and manpower that large organizations would rather still use of the existing hardware/software rather than to upgrade it. Middleboxes that would work as a bridge between the new and old are greatly needed to allow the organizations to upgrade at their own pace. HIP a new protocol that has been defined and currently is being implemented so that multihoming and security is used by the protocol by default, it rides along the IP header and uses IP to tell routers where it goes, it works both with IPv4 and IPv6 and as it is a new protocol no middleboxes exist that can connect IPv4 nets and IPv6 nets without the need of registration and that s the work of this thesis. As IP plays the double role of being locator and identifier for a host then when the IP changes the session is terminated, HIP splits this up with IP just being locator and a HIT being the identifier so that the session may be kept between the HIP enabled hosts when the IP changes. HIP also has by default a four-way-handshake and in the handshake keys is setup for an ESP association between the hosts so that data packages are sent encrypted. There are similar protocols to HIP like Mobile IP (that is used right now with mobile phones) and the split is nothing new for HIP as a lot of ground work was done when I3 was formulated. After choosing an implementation to use i.e. the work on HIPL we started looking into different solutions to solve the problem at hand, as the rendezvous server were just for the handshake part for host to find each other and a relay developed by the HIPL group required registration from the contacted host first we choose to implement our own middlebox as a simple gateway for the handshake and as a SPI-NAT for the ESP traffic. Conclusion How HIP and ESP are defined there is no hinder for implementing middleboxes that can shuffle packages between hosts as only the IP header is changed and a parameter that is not signed, there will be no security associations broken and the hosts connected to each other can still uphold a secure and private conversation as long the DNS does direct the host to a reliable gateway. There is still the question to change the current implementation of a host lookup in a DNS so that the DNS knows that a host lies in a different network than the one it tries to contact and returns a HINT parameter that can be processed by HIP. There is also the question on when an update packages comes that the correct association is kept, who is to verify that the update package comes from a correct host and when should the gateway drop the old association.

26 References Here references that are used in the thesis report are listed. The reference list is created like this: In alphabetical order sorted on the author's last name with all co-authors last names and initials. The year of publication in a parenthesis directly after the author names. The title of the book followed by the publishers name and address Bonczek, R H, Holsapple, C. W. och Whinston, A. B., (1981), Foundation of Decision Support Systems, Academic Press, New York o The title of the article followed by the name of the journal, the volume, the issue, the pages. Clancey, W. J., (1985), Heuristic classification, Artificial Intelligence, Vol. 27, No. 3, pp References to web-pages in to include the whole address and also the date when the page was visited. This since web pages are "living" documents. In the thesis report text, these references should be cited using the authors name and publishing year, e.g., Clancey, References with more than one author should be cited with the name of the first author followed by "et al." and year, e.g., Bonczek et al., Addresses to web-pages should be written out in the text. Use your Reference Managing Program or insert Endnotes, within Word, in the text to make the list of reference. Delete this text. [WX-shim2] G. Huston, Architectural Commentary on Site Multi-homing using a Level 3 Shim, Internet-Draft (work in progress), [WX] Birthday problem, accessed , [WX] DNS Doman Name System, accessed , [WX] End-Host Authentication for HIP Middleboxes, accessed , [WX] Gateway (telecommunications). accessed , [WX] HIPL HIP for Linux, accessed , [WX] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, S. SuranaInternet Internet Indirection Infrastructure, University of California, Berkeley [WX] Mobile IP, accessed , [WX] Mobile IP, accessed ,

27 [WX] Mobile IP - Mobility Support in IPv4/v6, accessed [WX] OpenHIP, accessed , [WX] RFC IP Mobility Support for IPv4, accessed , [WX] RFC Mobile IP Mobility Support in IPv6, accessed [WX] RFC Host Identity Protocol (HIP) Architecture, accessed , [WX] RFC HIP Basic, accessed , [WX] RFC Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP), accessed , [WX] RFC Registration Extension, accessed , [WX-shim] E. Nordmark, M. Bagnulo, Shim6: Level 3 Multihoming Shim Protocol for IPv6, [WX] RFC HIP Rendezvous Extension, accessed , [UA] J.Ubillos and B.Ahlgren, 2008, Global IPv4-IPv6 Interconnection with HIP Appendix Attachment 1. How to install HIPL [Installing-hipl.doc] Attachment 2. System setup [System-setup.doc] Attachment 3. Matlab code for birthday problem BD_problem.m As an appendix you can include material that should be in the thesis report but is not suitable to have directly in the chapter's text, e.g., source code, diagrams, raw data, or detailed explanations of something specific. Tips Save all results that you get during your thesis project, write down ideas. It is easy to forget Is the language used suitable for the intended reader of the thesis report? Use a language that is not too formal the report should be readable by, e.g., your classmates. Eliminate all unnecessary spelling errors. Ask a friend to read the thesis report and provide you with feedback. Also, your supervisor helps you here. Use word spell checker!

28 Check that there is a "red thread" through your report. Do you motivate your selections and choices? Do you explain your results? Is everything made clear? What about the title? It is important since it can be put in your diploma later. It is something that you want/will show to others. Figures, diagrams, tables, do they have correct numbering and are they relevant? Have they been explained enough? Are they readable? Do they have captions and crossreferences in the main text? Check that the text used is not too small.