Independent Local Locator Substrate Indirection Transport
Mats Björkman – Mälardalens University – firstname.lastname@example.org Javier Ubillos – SICS – email@example.com
Pablo Santibanez Jara – firstname.lastname@example.org Mikael Svensson – email@example.com
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) [W16] 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.
Table of content
Background and purpose ...6
Related work (relevant theory) ...6
1.1 Host Identity Protocol ...6
1.1.1 Current IPv4, IPv6 namespace and identifiers...6
1.1.2 Base exchange ...7
1.2 Similar protocols...7
1.2.1 MobileIP ...7
126.96.36.199 Mobile IP base ...8
188.8.131.52 Home agents and foreign agents...8
184.108.40.206 Foreign agent and home agent tables...9
220.127.116.11 Similarities ...9 18.104.22.168 Differences ...9 22.214.171.124 Current use ...9 1.3.1 i3...10 126.96.36.199 i3 base...10 188.8.131.52 Mobility ...11 184.108.40.206 Similarities ...11 220.127.116.11 Differences ...11 18.104.22.168 Current use ...11 1.4.1 Shim6...12 22.214.171.124 Shim6 base ...12 126.96.36.199 Mobility ...13 188.8.131.52 Similarities ...13 2.0 Problem formulation ...14 2.1 Background problem ...14 2.1.1 SICS-‐ONE router...14 2.2 Scope ...14
3.0 Analysis of the problem...16
3.1 Requirements ...16
3.1.1 Packets and IP header ...16
3.1.2 DNS, DHT, HOST...16 3.1.3 Parameters ...16 4.0 Model/method ...17 4.1 Gateway concept...17 4.2 Rendezvous server...17 4.2.1 Relay service ...17 5.0 Solution ...19 5.1 Possible solutions ...19 5.1.1 Relay server ...19
184.108.40.206 Build the gateway...19
6.0 Results, analysis of results, recommendations, future work...20
6.1 Chosen solution ...20
6.2 Gateway project ...20
6.3.0 Results ...20
6.3.1 Handshake and ESP with HIPL client and server...20
6.3.2 Handshake and ESP with non-‐HIPL client and server ...21
6.3.3 ESP and birthday problem ...22
6.3.4 HIP and mobility with the gateway ...23
6.4.1 Birthday problem...24
6.5 Future work ...24
6.5.1 Development of a gateway...24
Summary and conclusions...25
Summary ...25 Conclusion ...25 References...26 Appendix...27
API Application Programming Interface DHT Distributed Hash Table
DNS Domain Name System
DoS Denial of Service
DDoS Distributed 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
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.1 Host Identity Protocol
1.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 is
(endpoint) as seen in Figure 1.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 [W17].
Figure 1.1 The role of IP
The host identity protocol (HIP) [W16] 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 1.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 1.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.
Figure 1.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 1.3 HIP as a waist between the transport layer and IP
1.1.2 Base exchange
HIP does not just introduce a decoupling but also introduces a four-‐way-‐handshake [W16] as shown in Figure 1.4.
Figure 1.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 packet.
2. Host B sends a reply packet 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. An ESP connection is established for sending further data.
1.2 Similar protocols
In this section we take a look into the working of an Internet protocol called Mobile IP Mobile IPv4 [W14] Mobile IPv6 [W15] and Mobile IPv4\IPv6 [W12].
220.127.116.11 Mobile IP base
The protocol MobileIP [W10] 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 1.5 when visiting other subnets, when visiting other subnets it connects to CN and HA through a foreign agent (FA).
Figure 1.5 A mobile node moving from one subnet to another
18.104.22.168 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 packets 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 1.6.
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 1.6 A mobile node talking with a correspondent node through a
foreign agent (Mobile IPv4)
22.214.171.124 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 1.7 and visiting nodes in a visitor list see Figure 1.8. Both lists are so that packets are forward accordingly to the MN’s [W11].
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 packets, there is a suggestion to merge Mobile IPv4 and IPv6 to a single protocol but this is out of the scope of this
Figure 1.7 Mobility binding in home agent Figure 1.8 Visitor list in a foreign agent
• 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.
• 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 [SJYWJ].
• 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.
126.96.36.199 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.
I3 [W9] 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.
188.8.131.52 i3 base
Internet Indirection Infrastructure (i3) implements a rendezvous-‐based abstraction. I3 is an overlay network that uses Chord [W2] protocol to route data. The i3 network is a set of servers that store triggers and forward packets between end-‐points. 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 as seen in Figure 1.9.
Figure 1.9 Shown here in, the I3 network 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 end-‐ host. 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.
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 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 as seen in Figure 1.10.
Figure 1.10 When the host moves around and changes its address from R1 to R2, the trigger is updated from (id, R1) to (id, R2).
When the host moves around and changes its address from R1 to R2, the trigger is updated from (id, R1) to (id, R2).
• 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.
• 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.
184.108.40.206 Current use
Areas of use including i3 are proxies; secure intranets and NAT where the routing flexibilities 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 [W6]. 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.
This protocol specifies a layer 3 shim approach [W22] 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.
Figure 1.11 The shim6 architecture, picture taken from www.shim6.org
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 as seen in Figure 1.11.
220.127.116.11 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 [W3] 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 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 that may occur.
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.
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.
2.0 Problem formulation
2.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.
2.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.
Our task is to implement a gateway (GW) [W5] 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 that is developed in SICS.
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 packets as a parameter called RR_HINT.
The packet is sent to the gateway in the following way: • IP header FROM field is A’s address.
• IP header TO field is the GW address.
• HIP parameter RR_HINT contains B’s address
The gateway gets the packets reads it and sees that the parameter RR_HINT is included thus it does the following changes:
• IP header FROM field is changed to the GW address. • IP header TO field is B’s address.
• HIP parameter RR_HINT contains A’s address.
Then sends the packet 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 packet 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 2.1 for info how the packets are sent.
Figure 2.1 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 that is used to identify ESP packets and are routed to a specific host.
3.0 Analysis of the problem
3.1.1 Packets and IP header
The packets must use HIP, we have to be able to modify the packets sent between two hosts in the GW so they get the right TO and FROM fields in the IP headers as seen in Figure 3.1.
Figure 3.1 How the to headers have in their fields, 1, 2 are packets going to host B and 3, 4 are packets going to
3.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 3.2.
Figure 3.2 Query about B and an answer to with IP to the gateway and IP of B as a HINT 3.1.3 Parameters
The packets 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 packet as a parameter see Figure 3.3. This parameter is later processed by the gateway.
Figure 3.3 How the HIP parameter can be in the HIP packet.
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, using a rendezvous server (RVS) [W20] to forward packets 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 an experimental relay developed by a group of people.
4.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.
4.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 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 4.1.
Figure 4.1 The use of a RVS server.
4.2.1 Relay service
The relay service is a mechanic to address the issues that are brought up in RFC 5203 [W19] and RFC 5207 [W21] where HIP enabled hosts are behind NAT 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
relay functionality will make the RVS a relay [W7] i.e. a gateway for HIP hosts to use see Figure 4.2.
One difference to a gateway is that in a RVS or Relay the responder has to register itself with the relay server, as it has to do with a RVS.
Figure 4.2 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 packet.
4. The initiator connects to RVS with the provided IP and uses the HIT of B in the packet sent.
5. The relay maps the packet from the initiator using the HIT of B and sends the packets to B.
6. Packets 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>
You will have to do additional configuration right now for it to work with the HIPL implementation.
5.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 [W8] group’s code as base.
Compared with OpenHIP [W13] 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.
5.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.
18.104.22.168 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 [UA].
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 [W18] and addresses from each host so that ESP packets are routed correctly.
6.0 Results, analysis of results, recommendations, future work
6.1 Chosen solution
We picked Linux due to it is a widely used technology with extensive documentation and support.
The preferred solution was to implement our own gateway with the HIPL code version 1.0.4 release 42 that was released in June 2009 as base. Using the HIPL code as base was selected so that if the results of this thesis are to be continued by the HIPL team there is known code that they can work with.
6.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 packet. 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].
6.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 6.1 that is a cropped screenshot from a Wireshark capture on the host that is running the gateway.
Figure 6.1 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 6.2 and Figure 6.3 show the Initiator and Responder after a successful send and receive of the packet.
Figure 6.2 The client sending a message hai
Figure 6.3 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 packets 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.
6.3.2 Handshake and ESP with non-HIPL client and server
We tried doing some ping61 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.
1 ping6 is a program to perform ping test using the IPv6 protocol between 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 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.
6.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 [W1].
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, 50000 and 100000 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 6.4 (10000 sessions), Figure 6.5 (25000 sessions), Figure 6.6 (50000 sessions) and Figure 6.7 (100000 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 10000 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.
6.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 packets it that are sent by having signatures and HMAC 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 packet as normal in the gateway.
The behavior of our implemented gateway is now that when an update packet comes, the gateway will relay the packet and begin to establish a new association for the host. This only applies to update packets 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 Middle-‐boxes [W4]. .
22.214.171.124 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 packet to reach the corresponding host it has to traverse the gateway. The current implementation of HIPL is that even if a host initiates an IP change but has not changed the IP, the update packet is processed as an IP change by HIPL. Even if it seems strange, this wont breach anything declared in the HIP standard, so packets that are relayed through the gateway would have the IP header changed without the risk that the receiving host will drop those packets and the update procedure will be done as normal see Figure 6.8.
Figure 6.8 A normal IP change, Host A changes IP sends a Update packet and then update packets with ACK are sent and if all goes well a ESP association is set between the hosts.
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 and response to update packets with some kind of challenge.
6.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 that is needed to be considered and possible to move the gateway from the apartment building to the ISP’s distribution layer.
6.5 Future work
6.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 [W4].
The HIP-‐host could include the challenge request and response to solve the security issues involving UPDATE packets in HIP and the association between hosts going through a middle-‐ box or gateway in our case.
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.