Mobile IPv6 Support for Dual Stack Mobile Nodes and Routers

Transcription

1 Mobile IPv6 Support for Dual Stack Mobile Nodes and Routers Author David Masso Advisors: Pr. Dr. Jacques Calmet University of Karlsruhe (TH) Institute for Algorithms and Cognitive Systems 31. August 2006

2

3 Statement of originality Hereby, I declare this thesis to be the work of my own, written independently. All sources and references are correctly cited with complete references to their sources.

4 Abstract Internet protocol version 6 (IPv6) is not widely deployed; it is unlikely that mobile nodes will use IPv6 addresses for their connection. Mobile nodes could move to networks that might not support IPv6 addresses and therefore need an Internet Protocol version Four (IPv4) address in the foreign network and the capacity to continue established connections and to maintain them. In addition the building of new connections to other hosts is also needed. The current mobile internet protocol (MIPv6) and network mobile specifications do not allow mobile nodes to use an IPv4 home address or prefix. This document is specifies and gives an implementation of a simple, rapid, independent of any constraints and safe mechanism for dual stacked mobile nodes behind networks address translation (NAT) and firewall devices, in order to build connections while being in a foreign network, to communicate with it and to maintain this connection with a distant correspondent node. In order to authenticate the different hosts an IP Authentication Header mechanism will be used. This report is divided as follows: in the first section, we will give an introduction about the different Internet Protocols, in the second and the third section we will talk about the background needed in order to understand this work. The section four and five explain the specification and the implementation. In the sixth section we make a practical test to experiment the functionalities of this work and finally we will conclude and talk about further work.

5

6 Table of Contents 1. Introduction Internet Protocol Motivation NAT, Firewall, Connection Establishment and Maintenance of the Communication Network Address and Port Translation Firewalls Connection Establishment and Maintenance...12 of the Communication Background and Related works Mobile Internet Protocol Mobile IP Functional Entities Mobile IPv Mobile IPv6 Basic Operations Mobile IPv6 Messages Types and Destination Options Keyed-Hashing for Message Authentication (HMAC) IP Authentication Header Authentication Header Syntax Integrity Check Value Calculation Authentication Header: Tunnel Mode GPRS (General Packet Radio Service) Review GPRS: Definition and Advantages GPRS Technical Review Service GPRS Support Node Gateway GPRS Service Node Connectivity between GGSN and SGSN GPRS Network by the Provider Network Address Translator Drawbacks Protocols that are broken with NAT Device on the Route IPSec and IKE

7 Kerberos 4/ RSH/RLOGIN Applications that can be broken with NAT device on the Route Bundled session applications Peer-to-Peer applications IP Fragmentation with Network Address and Port Translation Applications requiring more public addresses than available Existing NAT traversal Mechanisms Simple Traversal of User Datagram through NAT (STUN) STUN Operations Drawbacks of STUN Mobile IP Traversal for Network Address Translation Architecture Observations Conclusions of the Analysis Design of the Solution Specification UDP Tunnel Construction and Maintenance UDP Tunnelling Message Formats UDP Tunnel Request UDP Tunnel Reply UDP Tunnel Close UDP Tunnel Keep-Alive Message UDP Tunnel Data Header Message Format Encapsulation and Decapsulation of Data Encapsulation of IP Data on UDP Decapsulation of IP Data on UDP UDP Tunnel Discovery Mechanism UDP Tunnelling Reconfiguration Mechanism NAT Detection and UDP Tunnel Construction Mobile Node has an IPv4 Public Address Mobile Node has an IPv4 Private Address Correspondent Node is behind a NAT Device

8 Mobile Node in an IPv6 Foreign Network NAT Keep Alive UDP Tunnelling: Security Considerations Implementation Experiment Conclusion and Future Works Table of FIGURES Bibliography

9 4

10 Chapter 1 Introduction This chapter starts firstly some reviews of the Internet Protocol, than goes on by giving the motivations of this work and the problems encounter by the dual stacked mobile nodes and these drawbacks, while mobile nodes move physically from a network (IPv6-only Network) to another (IPv4-only Network) behind Network Address Translation and Firewall devices. 1.1 Internet Protocol The Internet Protocol (IP) [1] was designed for use in interconnected systems of packet-switched computer communication networks. It is specially limited in scope to provide the functions necessary to deliver a package of bits from a source to destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other service commonly found in host-to-host protocol. The internet protocol implements two basics operations: addressing and fragmentation. By the addressing, a distinction is made between names, addresses and routes. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primary with addresses. It is the task of higher level protocols to make mapping from names to addresses. A fragmentation of an internet datagram is necessary when it originates in a local network that allows a large packet size and must traverse a local network that limits to smaller size to reach its destination. An identification field is used to distinguish fragments of one data those of another. There are two basic Internet Protocol versions, IPv4 and IPv6. They are demultiplexed at the media layer. For example IPv6 packets are carried over the Ethernet with the content type 0x86DD instead of IPv4 s 0x

11 The difference between the two versions is mainly in the length of the address field. IPv4 uses 32 bits address and IPv6 increases this address size to128 bits to support more levels of addressing hierarchy, a much greater number of addressable nodes and a simpler auto-configuration of addresses. In IPv6 packet Header also made changes in the way that IP header are encoded to allow more efficient forwarding, less stringent limits of the length of options and greater flexibility for introducing new options in the future. The following diagrams show the message header format of both versions of Internet Protocol Version IHL Type of Ser. Total Length Identification Flags Fragment Offset Time To Live Protocol Header Checksum Source Address Destination Address Options Padding Figure 1: IPv4 Header Format Version: 4 bits, indicates the format of internet header. IHL: 4bits, is the length of the internet header in 32 bits word, and thus points to the beginning of data. The minimum value is 5. Type of Service: These 8 bits provide an indication of the abstract parameters of the quality of service desired. The complete description is in [1]. Total Length: that is the length of the datagram measured in octets, including internet header and data. Identification: 16 bits are an identifying value assigned by the sender to aid in assembling the fragments of the datagram. 6

12 Flags: 3bits, there are various control flags. Fragment Offset (13 bits): This field indicates where in the datagram this fragment belongs. Time to Live (8 bits): This field indicates the maximum time the datagram is allowed to remain in the internet system. Protocol (8bits): This field indicates the next level protocol used in the data portion of the internet datagram. Header Checksum (16 bits): The checksum of the header only. Source and Destination Addresses are described in [1]. Options: They may appear or not in datagram. Padding: It is variable and used to ensure that the internet header ends on 32 bits boundary. The padding is zero. 7

13 Version Traffic Class Flow Label Payload Length Next Header Source Address Destination Address Figure 2: IPv6 Header Format Version: 4-bit Internet Protocol version number is 6. Traffic Class: 8-bit traffic class field. Flow Label: 20-bit flow label. See the complete description in [2]. Payload Length: 16 bits are the length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets. Next Header identifies the type of the header immediately following the IPv6 header. Hop Limit is decremented by one by each node which forwards the packet. The packet is discarded if Hop Limit is decremented to 0. Source Address (128 bits) is the address of the originator of the packet [2]. 8

14 Destination Address (128 bits) is the address of the intended recipient of the packet [2]. 1.2 Motivation With the actual technology progress, mobile nodes found in the market have many capabilities. Most of them support as well Wireless Fidelity (WiFi), Ethernet and Bluetooth network access technologies. The protocols supported by these devices are in most time different. They depend of the infrastructure where they are implemented. Another challenge is added with the mobility. In this heterogeneous infrastructure, the following scenario shows for example, the difficulties for application to maintain an established connection in the case where a mobile nodes change physically the network (IPv6 to IPv4). A mobile for a reason or another left its primary network or home network which supports only an IPv6 protocol with an Wireless Fidelity (WiFi) access, to move in a different network. While the mobile node stays in his primary network, there are no problems. But now that the mobile node is moving in a different network and the user of the mobile node wants to use its General Packet Radio Service (GPRS) connection, which supports an Internet protocol other than the IPv6. A mobile will be confronted to many difficulties: How to switch from an IPv6 to an IPv4 network without to loss the established connections? In the framework of a General Packet Radio Service where mainly IPv4 private addresses are supported behind Network Address Translation and Firewall devices: How to traverse and to determine the characteristics of these devices used by the Internet Service Provider (ISP)? Two mechanisms are used here: The filtering mechanism of the firewall is a mechanism by which the firewall device filters some packets by using rules defined by the machine administrator. 9

15 The second mechanism is the address translation mechanism used by the NAT device. In spite of often that the mobile has successfully established a connection channel to its correspondent node, how to maintain it? The behaviours of these devices (NAT and Firewall) depend on the infrastructure implementations of the Internet Access Service Provider. To solve these drawbacks due to the infrastructure heterogeneity, many solutions have been proposed amongst other; The Mobile Internet Protocol Traversal of Network Address Translation (MIPNAT) devices and Simple Traversal of User Datagram Protocol (STUN). Both solutions have some limitations: STUN first needs a STUN Server and doesn t work for some kind of NAT devices and brings with him some brittleness. In addition STUN assumes a classification of devices based on their UDP (Use Datagram Protocol) treatment. To use Mobile Internet Protocol of network address Traversal, some assumptions are needed to be made about the devices between the mobile node and its correspondent node in order to build a communication channel. With the sight of these limitations, it proves necessary to develop and specify a simple, robust and secure mechanism. 1.3 NAT, Firewall, Connection Establishment and Maintenance of the Communication Network Address and Port Translation Network Address and Port Translation [16] is a method by which many network addresses and their ports are mapped from one group to another transparent to end users. 10

16 Referred to traditional NAT [17], this mechanism helps to connect a host with a private address to an external host with globally unique registered address. It has been observed that NAT treatment of UDP varies among implementations. The four treatments observed in implementations are: Full Cone NAT: That is one where all requests from the same internal IP address are mapped to the same external IP address and port. Furthermore any external host can send a packet to the internal host by sending a packet to the mapped external address. Restricted Cone NAT: That is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to an internal host only if the internal host had previously sent a packet to IP address X. Port restricted Cone NAT: A port restricted cone NAT is like a restricted NAT, but the restriction includes the port numbers. Specially, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P. Symmetric NAT: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific IP address and port, are mapped to the same external IP address and port. If the same host sends a packet to the same source address and port, to different destination, a different mapping is used Firewalls A firewall is a security gateway that controls access between a private administrative domain (an intranet) and the public internet. A firewall can act in two different ways: As a protocol end point, in this case no internal node (other than the firewall) is directly accessible from the external Internet, and no external node (other than the firewall) is directly accessible from within the intranet. Such firewalls are also known as application level gateways. A mail gateway for example, can be set up to examine each message going in or coming out. For each one, the gateway decides whether to transmit or discards the message based on header fields, message size, or even the content. 11

17 As a packet filter, in this case internal and external nodes are visible to each other at the Internet protocol level, but the firewall out (i.e., blocks passage of) certain packets, based of their header or contents. Packet filters are typically driven by tables configured by the system administrator. These tables list sources and destinations that are acceptable, source and destinations that are blocked, and default rules about what to do with packets coming from or going to other machines. Firewalls either act as a protocol endpoint and relay, as a packet filter, or some combination of both. A firewall, which acts as a protocol endpoint may implement a safe subset of a protocol, performs extensive validity checks, uses an implementation of designed to minimize the likelihood of bugs, run in an insulted; safe environment, or uses some combination of these techniques in tandem. As a packet filter, the firewall examines each packet and then passes the packet through the other side unchanged, drops the packets entirely, or handles the packet itself in some way. Typically, firewalls base their decision on IP source and destinations addresses. For example, firewalls may block packets from the Internet side that claim the source address of a system on the internal network, block RLOGIN or TELNET connections from the Internet to the internal network, block SMTP and FTP connections to the Internet from internal systems not authorized to send s or move files, act as intermediate server in handling SMTP and HTTP connections in either directions, or require the use of an access negotiation and encapsulation protocol to gain access to the Internet, to the Internal network, or both Connection Establishment and Maintenance of the Communication Different solutions have been proposed in order to resolve problems confronted by the dual stack mobile nodes which roam from an IPv6 only network to an IPv4-only private network behind NAT and Firewall devices. Mainly the process for solving these drawbacks can be divided in three stages: 12

18 First the mobile node has to discover the path, in order to reach its correspondent node. The difficulty here is to traverse NAT, Firewall and hidden routers in the framework of GPRS. Secondly, the mobile node must establish the communication with safe means, by using a well-known and defined protocol. Finally, the correspondent node has to maintain the established connection. Communication maintenance is essential, because like we will see later, the behaviour of some NAT and Firewall devices is not predictable. Establishing a connection appears to be easy, but it is actually surprisingly tricky. A first glance, it seems sufficient for one transport entity to just send a CONNECTION REQUEST Protocol Data Unit and wait a CONECTION ACCEPTED reply. The problem occurs when network can loose, modifies, drops or duplicates packets. A possibility is to give each connection a connection identifier chosen by the initiating party and put in each Protocol Data Unit, including the one requesting the connection. After each connection is released, each host could update a table listing obsolete connections. Whenever a connection request comes in, it could be checked against the table, to see if it belonged to a previously-released connection. Network with NAT device can modify Protocol Data Unit header. This has an effect of connection loss. To remediate to this state, mobile node should find means to note the modification in the header of Protocol Data Unit, to find the causes and dynamically to reconfigure it. Chapter 2 13

19 Background and Related works 2.1 Mobile Internet Protocol Internet protocol assumes that a node s IP address uniquely identifies the node s point of attachment to a network (Internet or Intranet). Therefore, a node must be located on the network indicated by its IP address in order to receive data destined to it; otherwise, data destined would be undeliverable. Mobile Internet Protocol is intended to enable nodes to move from one IP subnet to another. It is just a suitable for mobility across heterogeneous media. Mobile IP facilitates node movement from one Ethernet segment to another. It accommodates node movement from an Ethernet to a wireless LAN Mobile IP Functional Entities Mobile Internet protocol introduces the following new functional entities: Mobile Node: A host or a Route that changes its point of attachment from one network or sub network to another. A mobile node may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its IP address, assuming that link-layer connectivity to a point of attachment is available. Home Agent: A router on a mobile node home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintain currents current location information for the mobile node. Foreign Agent: A router on a mobile node s visited network which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were tunnelled by the mobile node home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. 14

20 2.1.2 Mobile IPv Mobile IPv6 Basic Operations A mobile node is always expected to be addressable to its home address; whether it is currently attached to its home link or is away from home. While a mobile node is at home, packets addressed to its home address are routed to the mobile home s link, using conventional internet routing mechanisms. While a mobile node is attached to some foreign link away from home, it has also to one or more care-of addresses. The mobile node can acquire its care-of address through conventional IPv6 mechanisms such as stateless or stateful autoconfiguration. As long as the mobile stays in this location, packets addressed to his care-of address will be routed to the mobile node. The mobile node may accept packets from several care-of addresses, such as when it is moving but still reachable at the previous link. The association between mobile node s home address and care-of address is known as a binding for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the home agent for the mobile node. The mobile node performs this binding registration by sending a binding update message to the home agent. The home agent replies by returning a Binding acknowledgement message. There are two possible modes for communications between the mobile node and a correspondent node. The first mode, bidirectional tunnelling does not require mobile IPv6 support from the correspondent node and is available even if the mobile node has not registered its current binding with the correspondent node. Packets from the correspondent node are routed to the home agent and then tunnelled to the mobile node. Packets to the correspondent mode are tunnelled from the mobile to the home agent and then routed normally to the home network to the correspondent node. In this mode, the home agent uses proxy neighbour Discovery to intercept any IPv6 packets addressed to the mobile node s home address on the home link. Each intercepted packet is tunnelled to the mobile node s primary care-of address. This tunnelling is performed using IPv6 encapsulation [8]. 15

21 The second mode, route optimization, requires the mobile node to register its current binding at the correspondent node. Packets from the correspondent node can be routed directly routed to the care-of address of the mobile node. When sending a packet to any IPv6 destination, the correspondent checks its cached bindings for an entry for the packet s destination address. If a cached binding for this destination address is found, the node uses a new type of IPv6 routing header to route the packet to the mobile node by way of the care-of address indicated in this binding. When routing packets directly to the mobile node, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. A new type of IPv6 routing header is also added to the packet to carry the desired home address. Similarly the mobile node sets the source address in the packet s IPv6 to its current care-of address of the mobile node. The mobile node adds a new home address destination option to carry its home address. The inclusion of the home addresses option in these packets makes the use of the care-of address transparent above the network layer Mobile IPv6 Messages Types and Destination Options Mobility Header The mobility header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. The mobility header is identified by the next header value of 135 in the immediately preceding header, and has the following format: Payload Proto Header Len MH Type Reserved 16

22 Checksum Message Data Figure 3: IPv6 Mobility Header Payload Proto: 8 bit selector identifies the type of header immediately following the Mobility Header. This field is intended to be used for a future extension. Header Len: 8 bit I, unsigned integer, representing the length of the Mobility Header, in units of 8 octets, excluding the first 8 octets. MH type: 8 bit selector identifies the particular mobility message in question. An unrecognized MH type field causes an error indication to be sent. Reserved: The 8 bits are reserved for future use. The value must be initialized by zero by the sender, and must be received by the receiver. Checksum: 16 bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is calculated from the octet string consisting of a pseudo header followed by the entire Mobility Header starting with the Payload Proto. Message Data: A variable length field containing the data specific to the indicated Mobility Header type Others Messages Types The Mobility Header is used to carry the following messages: 17

23 Home Test Init, Home Test, care-of Test Init and care-of Test are used to perform the return routability procedure from the mobile node to the correspondent node. Binding Update is used by a mobile node to notify a correspondent node or the mobile node s home agent its current binding. The Binding Update sent to the mobile s node home agent to register its primary care-of address is marked as a home registration. Binding Acknowledgement is used to acknowledge receipt of a Binding Update, if an acknowledgement was requested in the Binding Update, the binding update was sent to the home agent, or an error occurred. Binding Request Refresh is used by a correspondent node to request a mobile node to re-establish its binding with the correspondent node Binding Error is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the home the Home Address destination option without an existing binding. Home Agent Address Discovery Request is used by the mobile node to initiate the dynamic home agent address discovery mechanism. Home Agent Address Discovery Reply is used by a home agent to respond to a mobile that uses the dynamic home agent address discovery. Mobile Prefix Solicitation: The ICMP Mobile Prefix solicitation Message is sent by the mobile node to its home while it is away from home. The purpose of this message is to solicit a Mobile Prefix Advertisement from home agent, which allows the mobile node to gather prefix information about its home network. Mobile Prefix Advertisement is sent to a mobile node to distribute prefix information about the home link while the mobile node is travelling away from the home network. 18

24 2.2 Keyed-Hashing for Message Authentication (HMAC) To establish connection, the host will need a mechanism to secure exchanged data; this mechanism must be secure, scalable and simple. To assure integrity of the information is a prime necessary in the world of open computing and communications. Mechanisms that provide such integrity check based on a secret key are usually called messages authentication codes [6]. Typically messages integrity codes are used between two parties that share two keys in order to validate information transmitted between these parties. HMAC can be used in combination with any iterated cryptographic hash function. Sha256 is an example of such hash function. HMAC uses a secret key for calculation and verification of the message authentication values. The goals behind this construction are: To use without modifications, available hash functions. In particular, hash functions that perform well in software. To preserve the original performance of the hash function without incurring a significant degradation. To use and handle keys in a simple way. To have a well understood cryptographic analysis of the strength of the authentication mechanism based on reasonable assumptions on the underlying hash function. The security of the message authentication mechanism presented above depends on cryptographic properties of the hash function H: the resistance of finding collisions and the message authentication property of the compression function H when messages applied in singles blocks. It is important to observe the following two properties of the HMAC construction and its secure use for message authentication: The construction must be independent of the details of the particular hash function H in use and then the latter can be replaced by any other secure cryptographic has function. 19

25 Message authentication as opposed to encryption, has a transient effect. A published breaking of a message authentication scheme would lead to the replacement of that scheme, but would have not adversarial effect in the information authenticated in the past. This is in sharp contrast with encryption, where information encrypted today may suffer from exposure in the future if, and when, the encryption algorithm is broken. 2.3 IP Authentication Header The IP Authentication Header is designed to provide integrity and authentication without confidentiality to IP datagrams. The Authentication Header supports security between two or more hosts implementing AH, between two or more gateways implementing AH, and between a host or gateway implementing AH and a set of hosts or gateways. The Authentication Header provides much stronger security than exists in most of the current Internet and should not affect exportability or significantly increase implementation cost Authentication Header Syntax The IP Authentication Header has the following syntax: Next Header Payload Len Reserved Security Parameters Index Sequence Number Field Integrity Check Value ICV (Variable) Figure 4: Authentication Header Format Next Header: 8 bit identifies the next payload after the Authentication Payload. The values in this field are the set of the IP Protocol Numbers as defined by the Internet Assigned Numbers Authority (IANA). For example the value 4 indicates IPv4, a value 46 indicates IPv6 and a value 6 indicates TCP. 20

26 Payload Length: 8 bit wide identifies the length of the Authentication Data field in 32 bit words. Minimum value is 0 words, which is only used in the degenerate case of a null authentication algorithm. Reserved: These 16 bit are reserved for the future use. They must be set to 0 when sent. The value is included in the ICV calculation, but is otherwise ignored by the recipients. Security Parameters Index (SPI): A 32 bit pseudo-random value identifying the security association for this datagram. The set of security parameters Index value in the range 1 through 255 are reserved to the Internet Assigned Numbers Authorities. Sequence Number is a 32 bits field contains a counter value that increases by one for each packet sent. Authentication Header provides of synchronizing packet counters among multiple senders or managing a receiver packet counter and window in the context of multiple senders. The sender and receiver counters are initialized to 0 when a SA is established. If anti replayed is enabled, the transmitted sequence number must never allow to cycle. Thus, the sender and the receiver s counter must be reset prior to the transmission of 2 32 packets. Integrity Check Value is the variable length that contains the Integrity Check Value for this packet. This field must be an integral multiple of 32 bits in length Integrity Check Value Calculation The Authentication Header ICV is calculated over: IP or extension header fields before the AH header that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the Authentication Header Security Association. 21

27 The AH Header (Next Header, Payload Len, Reserved, SPI, Sequence Number (low-order 32 bits), and the ICV (which is set to 0 for this computation) and explicit padding bytes. Everything after AH is assumed to be immutable in transit The IP Authentication Header holds for its IP datagram. It does this by computing a cryptographic function the IP datagram and using the secret authentication key in the computation. The sender computes the Authentication data prior to sending the authenticated IP packet. The receiver verifies the correctness of the authentication upon reception. When processing the outgoing IP packet for authentication, the first step is for the sending system to locate the appropriate Security Association. All security association are unidirectional. The selection of the appropriate Security Association for an outgoing IP packet is based at least upon the sending userid and the destination address. When host oriented keying is in use, all sending userids will share the same security association to a given destination. The security association indicate which algorithm, algorithm mode, key or other security properties apply to the outgoing packet. The sender must compute the authentication over the packet as that packet will appear at the receiver. The sender places the calculated message digest algorithm output into the authentication data field within the Authentication Header Authentication Header: Tunnel Mode In tunnel Mode, the inner IP header carries the ultimate (IP) Source and Destination addresses, while an outer IP contains the addresses of peers. In tunnel Mode AH protects the entire inner IP packets, including the entire inner IP header. The following diagram shows Authentication Header Tunnel mode positioning for typical IPv4 and IPv6 packets. New IP header Authentication Header Original IP header UDP/TCP Data Figure 5: IPv4 Packet in Tunnel mode 22

28 New IP header Authentication Header Original IP header UDP/TCP Data Figure 6: IPv6 Packet in Tunnel mode 2.4 GPRS (General Packet Radio Service) Review GPRS: Definition and Advantages GPRS (General Packet Radio Service) is a packet based communication service for mobile devices that allow data to be sent address and received across a mobile telephone network. GPRS is a step towards 3G and is often referred to as 2.5G. Speed, permanent connectivity, better application support and low costs are some benefit of GPRS. Higher connection speeds are attainable at around kbps, a vast improvement on circuit switched networks of 9kbps. GPRS is packet switched. However in the very short term, speeds of kbps are more realistic. There is no need to dial up like you have to on a home PC for example. This feature is not unique for GPRS, but it is important standard that will no doubt be a key feature for migration to 3G. It makes services instantaneously available to a device. The high speed connection and always-on connectivity GPRS enables full Internet applications and services such as video conferencing straight to your desktop or mobile device. Users are able to explore the Internet or their own corporate networks more efficiently than they could when using GSM. There is no need to redevelop existing applications. GSM network providers do not have to start from scratch to deploy GPRS. GPRS is an upgrade to the existing network that sits along side the GSM network. This make easier to deploy, there is little or no downtime of the existing GSM network whilst implementation takes place. 23

29 2.4.2 GPRS Technical Review There are in practice two different networks working in parallel, GSM and GPRS. In any GSM networks, there are many BSC (Base Station Controllers). When implementing GPRS, software and hardware upgrade of this unit is required. The hardware upgrade consists of adding Packet Control Unit (PCU). This extra piece of hardware differentiates data destined for the standard GSM network or Circuit Switched Data and data destined for the GPRS network or Packet Switched Data. In some cases a PCU can be a separate entity. There are however two new functional elements which play a major role in how GPRS works: The Service GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). From the upgraded BSC there is a fast frame relay connection that connects directly to the newly introduced SGSN. Figure 6: GPRS Network Architecture Service GPRS Support Node The Serving GPRS Support Node takes care of some important tasks, including routing, handover and IP address assignment. The SGSN has a logical connection the GPRS device. As an example, if you are in a car travelling up the M1 on a long journey and browsing the Internet on a GPRS device, you will pass through many different cells. One job of the SGSN is to make sure the connection is not interrupted as you make your journey passing from cell to cell. The SGSN works out which BSC to route your connection 24

30 through. If the user moves into a segment of the network that is managed by a different SGSN it will perform a handoff of the new SGSN, this is done extremely quickly and generally the user will not notice that this has happened. Any packets that are lost during this process are retransmitted. The SGSN converts mobile data into IP and is connected to the GGSN via a tunnelling protocol Gateway GPRS Service Node The Gateway GPRS Support Node is the last port of call in the GPRS network before a connection between an ISP or corporate network s router occurs. The GGSN is basically a gateway, router and firewall rolled into one. It also confirms user details with radius servers for security, which are usually situated in the IP network and outside of the GPRS network Connectivity between GGSN and SGSN The connection between two GPRS Support Nodes is made with a protocol called GPRS Tunnelling Protocol (GTP). GTP sits on top of TCP/IP and is also responsible for the collection of mediation and billing information GPRS Network by the Provider Observation of the traffic that traverses the GPRS network implemented by the Internet Service Provider is quit different from the traditional GPRS networks that we know. These private networks are mostly complicated. In addition to the GSM network, the SGSN and GGSN which are the core of a GPRS network, we have many routers, firewall devices and NAT devices. 25

31 Figure 7: GRPS Network by the ISP 2.3 Network Address Translator Drawbacks Many protocols and applications break with by traversing the NAT devices. In the following sections, we will give some kinds of these protocols and applications Protocols that are broken with NAT Device on the Route IPSec and IKE NAT fundamentally changes end nodes addresses (within the IP Header) on route. The IPSec AH standard on the other hand is explicitly specified to detect the alterations in the IP Header. So when NAT device alters the address information on route in IP header, the destination host receiving the destined packet will invalidate the packet since the contents of the headers have been altered. The IPSec AH secure packet will simply not reach the target application. IPSec ESP encrypted packets may be altered by NAT device on route. In the case of TCP/UDP packets, NAT would need to update the checksum in 26

32 TCP/UDP headers, when an address in IP Header is changed. However, as TCP/UDP header is encrypted by the ESP, NAT device would not be able to make this update. TCP/UDP encrypted in transport mode ESP, traversing the NAT device will fail the TCP/UDP checksum validation on the receiving end. End to end IPSec is impossible to accomplish with NAT on route Kerberos 4/5 Kerberos uses tickets. They are tied to the IP address that requested the ticket and the service with which to use the ticket. In Kerberos 5, the client specifies a list of IP addresses which the ticket should be valid for, or it can ask for a ticket valid for all IP addresses. By asking for an all-ip-addresses ticket or a ticket containing the NAPT address, you can get Kerberos 5 to work with an NAPT device, it isn t very transparent. The K5 ticket contains IP addresses as requested by the client node, form which to be considered to be valid. If the services being accessed with Kerberos authentication are on the public side of the NAT, then the Kerberos authentication will fail because the IP address used by the NAT is not on the list of acceptable addresses RSH/RLOGIN RSH uses multiple sessions to separate streams for stdout and stderr. A random port number is transmitted inline from the client to the server for use as stderr port. The stderr socket is a connection back from server to the client. And unlike FTP, there is no equivalent PASV mode. For traditional NAT, this is a problem as traditional NAT would not permit incoming sessions. RLOGIN does not use multiple sessions. But the Kerberos protected versions of RSH and RLOGIN will not work a NAT environment due to the ticket problems and the use of multiple sessions. 27

33 2.3.1 Applications that can be broken with NAT device on the Route Bundled session applications Bundled session applications such as FTP which use a control connection to establish a data flow are also broken by NAT devices on route. This is because these applications exchange address and port parameters within control session to establish data sessions and session orientations. NAT cannot know the interdependency of the bundled sessions and would treat each session to be unrelated to one other. For example control session can permit data session to originate in a direction that NAT might not permit Peer-to-Peer applications P2P applications more than client client-sever based applications are likely to break with NAT en-route. P2P applications can be originated by any of the peer. External peers will be able to locate their peers in private networks only when they know the externally assigned IP address IP Fragmentation with Network Address and Port Translation Briefly the problem goes as follow; say two private hosts originated fragmented TCP/UDP packets to the same destination host. And they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned home address, the target host is unable to determine which of the two sessions the datagram belongs to. Consequently, both sessions will be corrupted Applications requiring more public addresses than available We take for example the rlogin service clients use well known port 512 as their TCP port ID. No more than one host in private network can initiate the service. This is a case of trying to use a service that fundamentally requires more public 28

34 addresses than are available. NAT devices can conserve addresses, they can create more addresses. 2.4 Existing NAT traversal Mechanisms In order to resolve the problems presented above generally and particularly these confronted by the dual stack mobile hosts, which roams from an IPv6 only network to an IPv4 network behind NAT and Firewall devices, many solutions have been proposed: The first named STUN (Simple Traversal of User Datagram through NAT) would provide the ability for applications to determine the public Internet Address allocated to them by the NAT; it allows a wide variety of applications to work through existing NAT infrastructures. The second Mobile IP Traversal for Network Address Translation provides extensions for the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address network which are separated from the public Internet by NAT devices Simple Traversal of User Datagram through NAT (STUN) Simple Traversal of User Datagram Protocol through Network Address Translator is a lightweight protocol that allows applications to discover the presence and types of NAT and firewall between them and the public Internet. It also provides the ability for applications to determine the public internet addresses allocated to them by the NAT STUN Operations STUN is a simple client-server protocol. A client sends a request to a server, and the server returns the response. There are two types of requests; Bindings Requests, sent over UDP, Shared Secret Request, sent over TLS over TCP. The client sends a Binding Request to the server, over UDP. When Binding Request arrives at the server, it may be passed through one or more NAT between 29

35 the STUN client and the STUN sever. As a result, the source address of the request received by the server will be the mapped address created by the by the NAT closest to the server. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client. There are some parameters in the request that allow the client to ask the server to send the response elsewhere, or the server sends the response from a different address or port. There are attributes for providing message integrity and authentication. Shared Secret Requests ask the server to return a temporary username and password. This username and password are used in a subsequent Binding Request and Binding Response, for the purposes of authentication and message integrity. If the server receives the Shared Request it must verify that the request arrives on TLS connection. If it did not receive the request over TLS, it must generate a Shared Secret Error Response and it must include an ERROR-CODE attribute. The destination for the error depends on the transport on which the request was received. If the Shared Secret has been received over TCP, the Shared Secret Error is sent over the same connection the request was received from. If the Shared Secret Request was received over UDP, the Shared Secret Error Response is sent to the source IP address and port that the request came from STUN Message Type Message Length Transaction ID Figure 8: STUN Message Header The Message Types can take on the following values: 0x0001: Binding Request 0x0101: Binding Response 30

36 0x0111: Binding Error Response 0x0002: Shared Secret Request 0x0102: Shared Secret Response 0x0112: Shared Secret Error Response Drawbacks of STUN The tight dependency on the specific type of NAT makes the protocol brittle. STUN assumes that the server exists on the public Internet. If the server is located in another private network, the user may or may not be able to use its discovered to communicate with other users. The bindings allocated from the NAT need to be continuously refreshed. Since the timeout of these bindings is very implementation specific, the refresh interval cannot be easily determined. The use of STUN server as an additional network element introduces a point of failure. If the client cannot locate a STUN server, or the server should be unavailable due to the failure, the application cannot function. That is also another point of security attack. The bindings allocated from the NAT need to be continuously refreshed. Since the timeouts of these bindings is very implementation specific, the refresh interval cannot be easily determined. And the binding acquisition of STUN does not work for all NAT. And the use of STUN to discover address bindings will result in an increase in latency for applications Mobile IP Traversal for Network Address Translation Mobile IP is incompatible with NAT traversal; also it has been defined new for Mobile IP in order to traverse NAT and to build tunnels. In Mobile IP tunnelling, the mobile node may use an extension in its registration request that it is able to use Mobile IP UDP tunnelling instead of standard Mobile IP tunnelling if the home agent sees that the registration seems to have passed 31

37 through the NAT. The home agent may then send a registration reply with an extension indicating acceptance. After assent from the home agent, MIP UDP tunnelling will be available for use both forward and reverse tunnelling. The destination port is always 434. The message sequence diagram below exemplifies the setting and the setting of a Mobile IP UDP tunnel. Mobile IP NAT uses for the sending of Request and Reply messages the port 434. An assumption is made that this port is always opened. And that is the mainly inconvenient, because by the implementing of GPRS Network by the Internet Provider, it can arrive these doesn t open this port. In addition MIP Traversal for NAT has been made specifically for mobility protocol. Mobile IP NAT suffers also from vulnerabilities. An attacker on the route between the mobile node and the Home Agent may redirect mobility bindings to a desired address simply by modifying the IP and the UDP headers of the registration request message. Having modified the binding the attack no longer needs to manipulate the traffic. Chapter 3 32

38 GPRS Network Behaviour 3.1 Architecture In order to analyse the influence of the GPRS networks on the frame and to see how many time the binding created by the NAT devices takes to change. The change concerns mainly the source port number used by the NAT. The following architecture has been used: Figure 9: Test Bed Architecture The mobile node sends the packets to a correspondent node configured with a public Internet address, which is physically to a same room, through a Bluetooth connection to a mobile phone. The phone is connected to the public Internet through a GPRS network. Then the observations can be made with a network tool snuffer. 33

39 3.2 Observations Scenario 1: A mobile node sends a request packet every second to the correspondent node. The following table shows the results observed on two different ports; The NAT changes the source IP address and the source port of outgoing UDP packet. The time noticed here is a time where the binding parameters changes on NAT device. Time Old Source Port New Source Port 16:48: :52: :56: :00: :04: :08: :12: :16: :21: Figure 10: Result of scenario 1 Conclusion: The source port of packets which outgoing from NAT change about every 4 to 5 minutes. The same observation has been made on another opened port on the GPRS network test. Scenario 2: In this scenario the mobile node sends every 6 minutes a request packet to its correspondent node. The following table shows the observations made by the binding on the NAT device. 34

40 Time Old Source Port New Source Port 10:24: :30: :36: :42: :48: :54: :06: Figure 11: Result of scenario 2 Conclusion: For every packet sent from the mobile node to the correspondent node, a new binding is created. Man can presume that the binding time is not than 6 minutes. Scenario 3: This scenario is the same that which was made in the scenario 1. The following table shows the results. Time Old Source Port New Source Port 10:10: :18: :45: :53: :02: :14: :18: Figure 12: Results of scenario 3 Conclusion We cannot make the same conclusions like in the scenario 1. In this example the results are different. 35

41 3.3 Conclusions of the Analysis The results obtained above, show that one cannot exactly determine the time binding duration by a Nat device. In addition, these analyses have been made with a GPRS private network of one particular internet service provider. However there are many with different implementations of GPRS network. Another problem is that the opened ports found by this GPRS network, might not be opened by another. In order to communicate without interruption due to the binding lifetime by the NAT device or the blocked port by the firewall device, we need a mechanism that automatically determines the opened ports independently of the GPRS network. This mechanism will be secure. The security concerns here as the integrity of the data sent by the different host well the authenticity of the sender in order to avoid deny of service. 36

42 Chapter 4 Design of the Solution 4.1 Specification Following scenarios are considered in the specification of the solution. And all these scenarios are mutually exclusive. And we assume that the correspondent node is always reachable through a globally unique IPv4 address. It is also reasonable to assume that mobile nodes need an IPv4 home address that can be used by upper layers. Both, the mobile node and the correspondent node allow the use of the UDP tunnelling. For all these scenarios, we need a robust tunnel that will use the mobile node and the correspondent node for the communication. In addition, we have to find an opened port. Because the presence of the firewall devices on the connection path, we can some ports closed due to the rule of the firewalls. Than a path discovery mechanism is necessary to traverse the firewall. Scenario 1: IPv4-only foreign network In this scenario, a mobile node is connected to an IPv4 only public foreign network. The mobile node can only configure the IPv4 care of address Scenario 2: Mobile Node behind a NAT In this scenario, the mobile node is in a private network IPv4 private foreign network that has a NAT device connecting it to the Internet. If the correspondent node is located outside the NAT device, the mobile node will need a NAT traversal mechanism to communicate with the correspondent node. Scenario 4: Correspondent node behind a NAT. In this scenario, the communication between a mobile node and the correspondent node is further complicated with the fact, that the correspondent node is located within a private network. However in this scenario, we assume that the home 37

43 agent is allocated a globally unique IPv4 address. Such address might not be physically configured on the correspondent node interface. Instead, it is associated with the correspondent node on the NAT device, which allows the correspondent node to be reachable through or port mapping. 4.2 UDP Tunnel Construction and Maintenance In order to communicate the mobile node needs to build a connection and to maintain this connection. To build a tunnel between a mobile node and a correspondent node we need to define new message formats UDP Tunnelling Message Formats UDP Tunnel Request By using this message format, the sender signifies that it is capable of handling MIP UDP tunnelling, and that a particular encapsulation format is requested in MIP UDP Tunnel. The Format of this message is as shown below. It adheres to the message format described in [4] Type Length Subtype Reserved 1 F R Reserved 1 Encapsulation Reserved 3 IP Address Tunnel IP Address Message Authentication Code (128 bits) Figure 13: UDP Tunnel Request Message Format 38

44 Type: 144 Length: Length in bytes of this message not including the Type and Length bytes. Subtype: 0. Reserved 1: Reserved for future use. It must set on 0 on sending and ignored on reception. F: F (Force) flag indicates that the sender wants to force MIP UDP tunnelling to be established. This is useful if the route between the mobile node and the correspondent node works for IP signalling packets, but not for generic packets. If the correspondent node supports this protocol; it should either accept the traversal, and replies with UDP Tunnel Reply message or rejects the UDP Tunnel Request message. In case of the request failing, the correspondent node sends a UDP Tunnel Reply message with the code field sets to 129. If the correspondent node does not understand the UDP Tunnel Request Message, it will silently discard it, and if everything else is fine, it will reply with the UDP Tunnel Reply message with reply code 0, but without any UDP Tunnel Reply message. In this case, the mobile node must not use MIP UDP tunnelling. R: not used. Reserved 2: Reserved for future use. It must be set to 0 on sending, must be ignored on reception. Encapsulation: Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol (4 for IP Header as described in [5], 55 as described in [6] and 47 GRE Header as described in [7]). Reserved 3: Reserved for future use, it must be to 0 on sending and must be verified IP Address: 32 IP address on the communication interface Tunnel IP Address: 32 IP address on the pseudo tunnel interface. It is a private address that the user sets to configure its tunnel. Message Authentication Code providing the way to check the integrity of information transmitted. HMAC-256 is used here to calculate the hash code. The 39

45 mobile node and the destination node share a secret key in order to validate this information. The details of the calculation are explained in section UDP Tunnel Reply This message is sent in reply to a UDP Tunnel Request message, and indicates whether or not the correspondent node will use the MIP UDP Tunnelling for the connection. The format of the message is shown below: Type Length Subtype Reply Code F Reserved Keep Alive Interval IP Address Tunnel IP Address Tunnel Connection Identity Message Authentication Code (128 bits) Type has the value 44. Figure 14: UDP Tunnel Reply Message Format Length is the length in bytes of this message, not including the Type and the Length bytes. Subtype has the value 0. Reply Code indicates whether the correspondent node assents or declines to use UDP Tunnelling for the establishing connection. The values in the range of

46 indicate assent, i.e., that tunnelling will be done, while the values in the range of indicate that tunnelling should not be done. The codes are used as described in [8]. 0 signifies that tunnelling will be done, and 64 that tunnelling will be declined with the raison unspecified. Keep-alive specifies the NAT keep-alive interval, that can be set to value or not. The default value is 0. A keep-alive packet should be sent if Keep-alive Interval seconds have been elapsed without any signalling or data traffic being sent. If this field is set to 0, the mobile node must it default configured Keep-Alive Interval. IP Address is the IP address of the replier. Tunnel IP Address: is the address used by the host on the tunnel interface Reserved is defined for the future use. It must be set to 0 on sending and it must be ignored on reception. Tunnel Connection Identifier (TCI) is a 32 bits connection identity set by the correspondent node if the UDP Tunnel Request has been accepted. This value is set to 0 if the UDP Tunnelling will be not done. This must be unique. The utility of this message parameter will be explained later below UDP Tunnel Close When a problem occurs, one of the hosts can need to close the connection established. This is done on sending a UDP Tunnel Close message. The following figure shows the format of this message. 41

47 Type Code Tunnel Connection Identity Message Authentication Code (128 bits) Figure 15: UDP Tunnel Close Message Format Type has the value 1. This value is set on sending. Code: The code values are defined between 0 and 255. Tunnel Connection Identity is defined while the tunnel is building. This value is set by the correspondent node by successful UDP Tunnel Request. The value is generated by the receiver on reception of the request. To differentiate the traffic that will be tunnelled after tunnel establishment, to which is used during the UDP tunnel construction mechanism, the following message format has been defined UDP Tunnel Keep-Alive Message If the NAT is detected, the mobile will need to refresh the binding port used by the correspondent node, in order to be reachable. This is also necessary when the mobile is not active, it will need to send periodically an update message. There is no way for the mobile node to known the exact of NAT device binding. The default time is suggested. 42

48 Tunnel Connection Identity Type Message Authentication Code (128 bits) Figure 16: UDP Tunnel Close Keep Alive Message UDP Tunnel Data Header Message Format The UDP Tunnel Data Header differentiates the traffic tunnelled trough the discovered port to the traffic during the discovering phase (UDP Tunnel Request, UDP Tunnel Reply and UDP Tunnel Close messages). The format of the UDP Tunnel Data Message Header is described below: Type Next Header Reserved Tunnel Connection Identifier Figure 17: UDP Tunnel Data Header Message Format Type is set to 4 for all packets sending on the established tunnel. Next Header indicates the type of tunnelled data. The Next Header uses the values as in the IP header Protocol field. The receiver of a tunnelled packet must check that the Next Header value matches for the tunnelling mode establishing. If a discrepancy is detected, the packet must be ignored. 43

49 Reserved, this field is reserved for future use. It must be set on 0 on sending and must be ignored on reception. Tunnel Connection Identifier is the same as described in section The connection initiator sets its value that he is received the UDP Tunnel Reply with the code field sets to 0. It remains the same during until one of the hosts decides to terminate the communication by closing the established tunnel connection Encapsulation and Decapsulation of Data Because there are not UDP port available, IP in IP tunnelling does not works and cannot pass through NAT Encapsulation of IP Data on UDP UDP Tunnelling is done in a manner analogous to that described in [5], with the exception of UDP header and UDP Tunnel Data Header between the outer and the inner IP header. UDP Tunnel Request and UDP Tunnel reply are already in the form of UDP messages, and shall not be tunnelled even if UDP Tunnelling is in force. To encapsulate an IP datagram using UDP Tunnelling encapsulation, an outer IP header, UDP header and UDP Tunnel Data Header is inserted before the datagram existing IP header as follows: IP Header IP Payload Outer IP Header UDP Header UDP Tunnel Data Message Header IP Header IP Payload Figure 18: Encapsulation and Decapsulation Operations 44

50 The outer IP header Source Address and Destination Address, together with the UDP header Source and Destination Port identify the endpoints of the tunnel. The inner IP header Source Address and Destination Address identify the original sender and the recipient of the datagram respectively. The inner IP header is not changed by the encapsulator, except to decrement the TTL by one if the tunnelling is being done as part of forwarding the datagram as described in [5], and remains unchanged during it is delivering to the tunnel exit points There are no change to IP options occurring in the inner header during delivery of the encapsulated datagram through the tunnel Decapsulation of IP Data on UDP Before the Decapsulation is done, the receiver node must verify that the outer IP addresses and UDP Port numbers exactly match the values used for the tunnel. UDP tunnelling encapsulated traffic is simply Decapsulated by stripping off the outer IP header, UDP and UDP Tunnel Data Header, which leaves the original IP packet which is forwarded to the upper layers. This is processed by the receiver as follows: First, the UDP header and the outer IP Header are removed from the packet, and the protocol field of the IP Header is replaced with the Next Header field in the UDP Tunnel Data Header UDP Tunnel Discovery Mechanism To traverse the firewall device, we need a need discovery mechanism. The fact is that some ports can be blocked by the firewall. It returns to the UDP Tunnelling mechanism to find a method to traverse the firewall. An assumption is made that they are always some opened ports that an application can use. To find an opened port, the mechanism has only to send Request through a destination port. The time to wait a response depends on a type of network (Normally the TTL can be used). If there is no response the node can use a different potentially opened port, this can be done. If there is a response, then the node can use this port for a destination port. It can also arrive that the port is not accepted for the use by the destination node. 45

51 To resume an opened in this sense is a port that a node can use to traverse a firewall device and that the destination node not declines to use for the service UDP Tunnelling Reconfiguration Mechanism The reconfiguration is the action initiated by the correspondent node when the ports are changed by the NAT device. The reconfiguration is caused when the port source of the received UDP header changes to maintain the tunnel. This can be done by using the normal message. The consequence here is the lost of this message. Or this can be done by using an UDP Tunnelling Keep Alive message. The Keep Alive message must be send by the mobile node behind the NAT device after a certain interval. The consequence here is that the communication will not be done between the change of the source port by the NAT device and the time that the Keep Alive message arrives NAT Detection and UDP Tunnel Construction The initial UDP Tunnel Request is sent from the mobile node to the correspondent node. Like seen in section , this is a normal UDP packet. The source address of the IPv4 packet is the IP Address of the mobile node and the Destination Address is the IP public Address of the correspondent node. The following scenarios can arise: Mobile Node has an IPv4 Public Address In this scenario, we make the assumption that the mobile node is not neither behind a NAT device or a Firewall device. The correspondent node which receives the UDP Tunnel Request must check only the F bit. If this bit is set, the mobile node wants to force the use of the UDP Tunnelling. If the correspondent node supports and has the possibility to use the UDP Tunnelling, it will accept. 46

52 The Correspondent node will set the tunnel by using the Source Address and The Destination Address found on outer IP Header packet. For the ports, the correspondent node will configure the tunnel by using the Source and Destination port in UDP packet header. For the Tunnel Interface, the correspondent node will use the Tunnel Address proposed by the mobile node to configure the interface. In the Message Reply, the correspondent node will propose also its Tunnel Address. The Tunnel Connection Identity will be set to 0 and must be ignored by the mobile node. Because There is no need of reconfiguration. If a problem occurs, while the mobile node making its configuration. It will send an UDP Tunnel Close Message, by indicating on the code, the probably cause of the problem. The mobile can restart the tunnel construction mechanism, if it can Mobile Node has an IPv4 Private Address In this Scenario, we make the assumption that the correspondent node is behind a firewall and NAT Device. When the mobile move in this network, it needs first a discovery mechanism described in section With this mechanism the mobile node is able to find the destination to use. If this port is also accepted by the destination host. The correspondent node will compare the source address on the UDP Header with the IP address on the UDP Tunnel Request Message. If there are different, there is a NAT device on the path. The correspondent node will reply with UDP Tunnel Reply by accepting or declining the request. If the correspondent node accepts the request, it configures its tunnel using the parameters on the request message. The correspondent node will make the following operations: Decapsulation the UDP packet Check the integrity of the message Configure the tunnel interface Send the UDP Tunnel Reply Message The reply message will contain as describe in section , the IP address will be a public IPv4 address of the correspondent node, the Tunnel IP Address is the 47

53 tunnel source address and the Tunnel Connection Identity (TCI) is an identifier which will be sent to the mobile node. The TCI is unique and necessary to make a difference between the tunnels on the same host Correspondent Node is behind a NAT Device The communication between the mobile node and the correspondent node is complicated by the fact that the correspondent node is behind a private network. However it is assumed that the correspondent node is allocated a globally unique IPv4 address. The Address might not be physically configured on the correspondent node interface. Instead it is associated with the correspondent node on the NAT device, which allows the correspondent to be reachable through address or port mapping Mobile Node in an IPv6 Foreign Network In this case, the mobile node is able to configure a globally unique IPv6 address. The mobile node will send a binding update as defined in [MIPv6]. After receiving the binding update, the home Agent creates two binding cache entries, one for the node s IPv4 home address, and another for the mobile node s IPv6 home address. Both entries will point to the mobile IPv6 care-of address. Hence, whenever a packet is addressed to the mobile node s IPv4 or IPv6 home address. It will be tunnelled in IPv6 to the mobile node s IPv6 care-of address. After accepting the binding update and creating the corresponding cache entries, the home agent must send a binding acknowledgment to the mobile as defined in [MIPv6] NAT Keep Alive If the NAT is detected, the mobile node will need to refresh the NAT bindings in order to be reachable from the correspondent node. Keep Alive messages (see section ) are sent and received through traffic encapsulated in UDP. If the 48

54 mobile node is not active, it sends periodically a message to the correspondent node in order to refresh the NAT binding. There is no way for the mobile node to know the exact time of the NAT binding. A default time is suggested, if the correspondent node suggests a different refresh period in UDP Tunnel Reply message, the mobile must use this value UDP Tunnelling: Security Considerations The UDP Tunnelling mechanism use IP security for NAT traversal. The mechanism requires that the correspondent node trust unauthenticated address and port fields possibly modified by the NAT device. In essence the attacker may do, what NAT do, i.e. modifying address and port and thus causes traffic to be redirected to a chosen address. Without a NAT the address in the UDP Tunnel Request will be directly used by the correspondent node to send traffic to the mobile node. When the attacker on the route between the mobile node and the correspondent modifies the IP and UDP Header of The UDP Tunnel Request Message, the attacker may not to need longer to listen to the traffic. The redirection will be in force until the NAT binding expire. This vulnerability may be used by an attacker to read the traffic destined to the mobile node, and to send the traffic impersonating the mobile node. The vulnerability may also used to redirect the traffic to a victim host in order to cause denial of service on the victim. The only defence against is to have the short time of the Keep Alive message, which limit the duration of the redirection attack after the attacker has stopped modifying the Request message. Having observed a UDP Tunnel Request and Reply exchange, an attacker may a bogus keep-alive message. This opens up the similar redirection attack as described before. This means that the host does not accept the keep-alive message from different IP. 49

55 Chapter 5 Implementation The main purpose of this chapter is to show how the traversal mechanism has been implemented. The following diagram the application structure of the UDP Tunnelling mechanism: Figure 19: Implementation Architecture The implementation of the UDP Tunnelling has been made in different modules: UDPTUN_DAEMON ensures the communication when the tunnel is established between two hosts. That is done by ensuring the sending and receiving of UDP packet. 50