A survey paper on MOBILE IP SECURITY CS 685 002 Topics in Security in Mobile Computing Systems

Submitted By:

Mobile IP Security
Abstract The main motive behind the paper is to introduce the concept of mobile IP and the related security issues. The implementation of mobile IP on the global scale does introduce some problems related to security (the main goal to be established) with the implementation of the authentication being the foremost amongst them. As the mobile node keeps changing its location frequently the issue of authentication becomes more obvious. Though Mobile IP can be used for handling mobility on a global scale various micro mobility models can be implemented to reduce the number of security measures involved in the mobility of the nodes with a distinction brought between Intra Mobility and Inter Mobility. Several security parameters are seen by various authors in the deployment of Mobile IP and various approaches have been proposed to handle them. In this paper we present a review of some of them. 1. Introduction Mobile nodes unlike their counterparts, the static nodes, do have some problems in getting the services required. Despite being sophisticated this shortage of services does appear owing to various factors like low power availability as the mobile nodes on the move use battery power, low computation resources due to the compact nature of their shape and low bandwidth for the wireless medium. Apart from these limitations which can be upgraded at a certain future, they are faced from the most difficult problem of security as they roam from one domain into a different domain. Security in essence deals with providing services aimed at 1. Data Confidentiality: This ensures that the message is accessed by the communicating parties who are authorized for receiving that data. 2. Authentication: Ensures that the origin of the message is identified correctly with no unauthorized person being involved. 3. Data Integrity: This assumes that the information transmitted is received intact or that the changes in the data do not go unnoticed. 4. Non Repudiation: This service ensures that the person sending the message can not deny the origin of the message to be from him. It also ensures that the receiver can not deny the receipt of the message. 5. Access Control: By ensuring this service the visited network of the mobile node can set up the required resources for that node. However we see that once authenticated and a secure association set up it can be quite easy to ensure that the message reaches the intended recipient, ensures that no one else other than intended recipient receive the message and also see to it that the sender who is

sending the message is infact the real originator of the message. This is because of our requirement that the communicating parties alone know the security association which is supposed to be a shared secret as in the case of a secure key exchange between a home agent and a foreign agent or between a home agent and a mobile node. However we believe that the shared key exchange between a foreign agent and a mobile node is not required. As the mobile node and the foreign agent belong to different administrative domains setting up secure keys between them every time a mobile node moves to a different domain would be a tedious job on the part of the mobile node. So a better approach would be to implement a firewall with a trusted internal network or to have link level security. However to ensure this in static environment one time authentication is enough as the end nodes once after authenticating each other will not have to do it again during the life time of their communication. But on the contrary the mobile nodes, which keep changing their location, will have to authenticate themselves every time they enter a new domain both with the home agent and the foreign agent. In the former case, a mobile node authenticating itself with the home agent ensures that the packets intended for mobile node arriving at the home network are delivered to the correct node. In the later case, a mobile node authenticating itself to the foreign agent ensures that it is receiving the same quality of service as it has received in the home network. This is what is being dealt in the Mobile IP. In this paper we focus more on authentication schemes rather than secure data transfer. This is because authentication can itself be used to set up keys needed for secure data transfer. The organization of the paper deals about Mobile IP in the first section. As mobile IP involves authentication between home agent and the mobile node every time a mobile node changes location this may be a tedious job when the mobile node is making small movements between the subnets of a same network. So the concept of micro mobility is dealt in detail in the next section. Section 3 deals with various security aspects that are to be taken into consideration for the development of secure mobility system. The later sections deal authentication in general environments and mobile environments. Section 4 deals about authentication in static environments with emphasis on arbitrated authentication (authentication involving the inline participation of trusted third party) and direct authentication (authentication involving offline participation or no participation of the third party). Section 5 deals with the Mobile IP authentication schemes both with and without using the AAA (Authorization, Authentication and Accounting) Infrastructure. Section 6 deals with IPSec architecture and the two important protocols Authentication header protocol and Encapsulating Payload Protocol that will be handy for implementing the Mobile IP security. Section 7 deals with various approaches used for implementing the Mobile IP security like the Public Key infrastructure, Firewalls, IPSec etc. Section 8 deals with Location privacy and some architecture used and their use in Mobile IP.

2. Mobile IP The most fundamental issue in the working of the Internet Protocol is that the protocol connects the networks of today's Internet, routes packets to their destinations according to IP addresses. When the packet's destination is a mobile node, this means that each new point of attachment made by the node is associated with a new network number and, hence, a new IP address, making transparent mobility impossible. This is because every time the node changes its location and acquires a new IP address this IP address has to be reflected at all the Domain Name servers of the visited networks. To maintain existing transport-layer connections as the mobile node moves from place to place, it must keep its IP address the same. However in mobile nodes this is not possible as the IP addresses of the node reflects the location of the node. To solve these problems of mobility, Mobile IP uses two addresses. The first address called the home address is static and does not change as the mobile node moves. The second address called the care of address reflects the current location of the mobile node in the visited foreign domain. This way existing TCP connections can be maintained using the static home address to route the packets to the home network and then using the current care of address the packets can be directed to the mobile nodes current location. 2.1 How Mobile IP works Mobile IP requires the existence of agents, home agent and foreign agent. Home agent keeps track of all the mobile nodes currently residing in the home network as well as those mobile nodes that belong to its domain and have left for a foreign network. The foreign agent on the other hand takes care of those mobile nodes that have left their home domain and currently present in its network. Whenever the mobile node moves, it registers its new care-of address with its home agent. To get a packet to a mobile node received from a corresponding node, the home agent in the home network delivers the packet from the home network to the care-of address. The further delivery requires that the packet be modified so that the care-of address appears as the destination IP address. This modification can be understood as a packet transformation or, more specifically, a redirection. When the packet arrives at the care-of address, the reverse transformation is applied so that the packet once again appears to have the mobile node's home address as the destination IP address. When the packet arrives at the mobile node, addressed to the home address, it will be processed properly by TCP or whatever higher level protocol logically receives it from the mobile node's IP processing layer. In Mobile IP the home agent redirects packets from the home network to the care-of address by constructing a new IP header that contains the mobile node's care-of address as the destination IP address. This new header then shields or encapsulates the original packet, causing the mobile node's home address to have no effect on the encapsulated packet's routing until it arrives at the care-of address. Such encapsulation is also called tunneling. Tunneling ensures location transparency to all the sending nodes.

Whenever the mobile node enters a foreign domain it will have to identify itself with the foreign agent. Foreign agents typically broadcast agent advertisements at regular intervals If a mobile node needs to get a care-of address and does not wish to wait for the periodic advertisement, the mobile node can broadcast or multicast a solicitation that will be answered by any foreign agent that receives it. The mobile node informs its newly acquired care-of address to its Home agent with the help of the foreign agent by sending a registration request. The home agent updates its routing tables, approves the request and sends a registration reply back to the mobile node. The association between the home IP address and the care-of IP address is maintained until the registration lifetime expires. It is known as binding. Whenever a node sends a message to the mobile node, it reaches the home network of the mobile node and it is handled by the home agent. If the mobile node is within the home network, the home agent simply sends the message to the mobile node. If the mobile node is in a foreign domain, the home agent encapsulates the message in a new IP packet and sends it to the foreign agent , with source being itself and destination being the care-of IP address of the mobile node. The foreign agent decapsulates the received message and sends the original message to the mobile node. In the general Mobile IP model the corresponding node sends a packet intended for the mobile node to the home network. The home agent will send the packet to the foreign agent, which then routes the packet to the mobile node. However this will cause a problem when the mobile node moves far off from the home network. As this suboptimal triangle routing will cause the packet to go far off from the mobile node even when the mobile node is in the same domain as the corresponding node. To overcome this problem due to sub optimal triangle problem the route optimized mobile IP has been proposed. In this model the first time the Corresponding Node sends a packet to the mobile node, the packet is routed to the mobile node through the Home Agent. However the home agent provides the corresponding node with a binding that contains the current location of the mobile node and the time period through which this binding is valid. The corresponding node has to validate this binding from time to time to ensure that it has the correct information about the mobile node. General Mobile IP
HA

FA

CN

MN

Route Optimized Mobile IP

HA

FA

CN

MN

2. Micro Mobility Models Though mobile IP appears to be plausible for the implementation of mobility it is not that well suited for mobility involving the movement of nodes from one subnet to other subnet in the same network domain. So models supporting Micro Mobility (mobility within the same network) have appeared in the literature. Though these models do need the support of the mobile IP in the issues when there is a movement of the mobile Node from one network to another network they do not require the implementation of Mobile IP when the node moves with in the network. Various models have been proposed to deal with Micro Mobility like the Cellular IP, Hawaii Model, Hierarchical model, FATIMA (Firewall Aware Transparent Internet Mobility Architecture) and so on. The first few models namely the Cellular IP model, Hawaii model and Hierarchical model do not speak about any security aspects and that is the reason we found a need to separate these models from the FATIMA model where security aspects have been dealt with. 2.1. Cellular IP The inherent disadvantage of involving the mobile node in the authentication process everytime it moves in a very small region can be countered with the help of Cellular IP model. In this micro mobility architecture the geographical area is divided into small regions called cells. Each cell has a number of base stations with each base station governing the nodes in its radio frequency range. Each cell communicates with the Internet backbone through a gateway. Whenever a mobile node moves into the serving area of a cellular IP network it will let the address of the Gateway to be its current care of address. In essence each mobile node falls under the direct authority of one of the base stations which will route the packets from the mobile node to the Gateway router by hop-by-hop shortest path routing regardless of their destination address. All the base stations as well as the gateway router keep track of all the mobile nodes in its domain. Whenever a mobile node moves to a new location it will transmit a route update packet to the new base station. This packet will be forwarded to the gateway through intermediate base stations creating new cache entries or updating cache entries in all the nodes along the path. However when a mobile node moves to a new cell for which the gateway router is not having an entry a new

update message has to be sent to the home agent so that all the packets intended for the mobile node from then upon will be routed to the new gateway router. As long as the mobile node remains in the area covered by the cellular IP network no update messages are sent to the home agent, hence significantly reducing the overhead and the time for handoff. But mobile IP is still needed to handle the movement between cellular networks as the mobile nodes care of address is changing. 2.2. Hawaii Model Hawaii model also deals with micro mobility issues while the macro mobility is still dealt with the mobile IP. The architecture consists of cells with each cell containing a crossover router and a few base stations. Unlike the cellular IP model where the mobile node acquires the gateway routers IP address as the care of address, the mobile node acquires a dynamic IP address from the DHCP server of the foreign network. Whenever a mobile node moves into a new domain in the same cell it will register itself with the new base station and sends an update to the crossover router. However when the mobile node moves to a different cell it will acquire a new IP address from the DHCP server of that network and sends an update to the home agent. The only difference we notice here in comparison to the cellular IP model is that the mobile node acquires an IP address from the DHCP server of the new network. 2.3. Hierarchical Model In the above two models of micro mobility whenever the mobile node moves in the same cell a route update has to take place in all the base stations involved in the hierarchy till the gateway router in the case of cellular IP model and crossover router in the case of Hawaii model. However in the case of Hierarchical model mobile node informs only those mobility agents till the point where the hierarchy is affected. In this model the mobile node whenever it moves into a new cell obtains a hierarchy of virtual care of addresses. By hierarchical virtual care of addresses we mean that the mobile node obtains a care of address with all the base stations involved in the hierarchy. This way the mobile node registers itself with the leaf node base station and the binding is then passed on to the next level node and to the top level mobility agent during the initial phase when the mobile node moves into the cell for the first time. However for the subsequent movements in the same cell the modifications are passed on till the lowest base station in the intersection of the set of base stations in the new path and the old path. Again only when the mobile node moves into a

3. Security issues in designing a Mobile IP system

The following issues were some of the most common intimidating factors causing a threat for a security system in the implementation of mobility. So a good mobile system must be able to trace these problems and provides means to reduce them to a maximum extent. Ingress Filtering: The mobile node uses its home address in the packets it is sending to a corresponding node. However a border router may discard the packet assuming that some node is trying to masquerade the nodes from an external network. In order to account for such issues provisions must be provided in the security protocol. Minimise the number of required trusted entities: Security may be enhanced, if the number of the required trusted entities, i.e., Home Agent, Foreign Agent, in a Mobile IP scenario is decreased. Authentication: It is the process of verifying a claimed identity of a node as the originator of a message (message authentication) or the identity of a node as the end point of a channel (entity authentication). Authorization: An organization that owns or operates a network would need to decide who may attach to this network and what network resources may be used by the attaching node. Non-repudiation: In the future wireless Internet, a recipient of a message should have the opportunity, to prove that a message has been originated by a sender. In other words, the sender of a message should not be able to falsely deny that it originated a message at a later time. Encryption key distribution: The authentication, integrity and non-repudiation can only be accurately provided (in forced) by using some form of cryptography which requires the distribution/exchange of encryption key information amongst message senders and receivers. Two methods can be used for this purpose. One method for distributing the key information is to manually load it into each node. For a small number of nodes this is possible but it runs into administrative problems. Another method to distribute the key information is dynamical, using basic IETF security protocols. Location privacy: A sender of a message should able to control which, if any, receivers know the location of the senders current physical attachment to the network. Location privacy is concerned with hiding the location of a Mobile Node from Correspondent Hosts. Firewall support in Mobile IP: If a Mobile Node has to enter a private Internet network (Intranet) that is securely protected by a firewall, then Mobile IP aware support at this firewall is required. In Mobile IP this support is not provided. 4. Authentication in General

It is the process of verifying a claimed identity of a node as the originator of a message (message authentication) or the identity of a node as the end point of a channel (entity authentication). In the former case we are trying to verify if the sender of the message is indeed the real sender or if some one else has altered the message. This is also called Data Origination Authentication or Data Integrity. The later case ensures that the message is received by some one who claims to be the real recipient of the message. This is achieved by enabling the communicating ends to verify the identity of the peer entities. Algorithms for encrypting the messages can be divided into two groups, Symmetric algorithms and asymmetric algorithms. In the Symmetric algorithms both the communicating parties share a common secret key that has to be kept secret during the tenure of communication. However asymmetric algorithms have two keys for each entity. One is known as the public key while the other is known as the private key. The public key is known to all the nodes and the private key is only known to the owner node. The communication between the communicating parties in the symmetric algorithms happens by using the secret key to encrypt the message. While in the asymmetric algorithms communication happens by encoding the message using the public key of the receiving node. Once encrypted with a public key the message can be decrypted using only its corresponding private key. This however ensures that the message reaches the intended recipient but do not check for the authenticity of the sender node. To overcome this problem of authenticating the sending node the message can first be encrypted with the private key of the sending node and then using the public key of receiving node. This ensures non repudiation of the message. By non repudiation we mean that the sending node can not deny that it has not sent the message as the sending node alone knows its private key and a message encrypted with the private key of a node can be decrypted with the corresponding public key of the node, thus ensuring the non repudiation property. Thus we have two types of algorithms for encrypting the messages. How can one choose a particular type of encryption algorithm be it a symmetric or asymmetric algorithm. Asymmetric algorithms are costly in terms of the processing power required for calculation. On the contrary symmetric algorithms are less costly in terms of processing power. However the symmetric key algorithms do require a trusted third party to ensure the validity of the other communicating parties. This element of trusting a third party is absent in asymmetric key algorithms. Thus using which algorithm becomes application specific. However a good choice would be to use a blend of both the algorithms in an application. Asymmetric algorithms can be used in the initial setup of the long term communication during which both the end parties agree upon a shared secret key. This key can be used from then upon to encrypt the messages. Thus reducing the processing burden on the mobile node involved in asymmetric algorithms as well as reducing the dependability on a third party (where there are fair chances of it being compromised) in the symmetric algorithms. Integrity Check Values can be divided into Modification Detection Codes and Message Authentication Codes. These two classes of check values do not protect the message. They provide means to ensure that the message reached at the other end is indeed the

same as the one originated at the sending node. Common algorithms used for calculating the Modification Detection Codes are Message Digest 5 and Secure Hash Algorithm. Commonly used algorithm to calculate the Message Authentication code is HMAC. However the fundamental difference in the two approaches is that one does not require a secure key association (as in the case of MDC) while the other asks for a secure key association (as in the case of MAC). The best way to use these two would again be application specific. However using them together would be a better approach. Authentication protocols can be divided into two categories namely Arbitrated Authentication and Direct Authentication. In the Arbitrated Authentication approach two entities that want to communicate with each other verify each others authenticity using a trusted third party. In the Direct Authentication approach the authentication process takes place without the direct involvement of the third party. 4.1. Arbitrated Authentication: In this model the two communicating parties require the inline participation of the trusted third party. By inline we mean that every time the two communicating parties involve in an authentication procedure, trusted third party involvement is a must having an impact on the authentication process. One such protocol is described below. 4.1.1. Needham-Shroeder Protocol This protocol allows two entities A and B to authenticate each other by the help of a trusted third party (CA). This protocol uses symmetric encryption algorithm. The trusted third party contains a database having entries with all the users trying to use it. This database also contains a secret key association between each user and the trusted third party let us call it ShK(user, CA). The main purpose of the protocol is to ensure that both the communicating parties A and B establish a shared secret key between themselves for further communications. Assuming A wants to start communication with B. To do this A first sends a message in plain text to CA stating its desire to communicate with B. The message contains As id, Bs id and a random number (rndnumA) to ensure that there is no replay attack. CA generates a session key S(A,B) and sends it A in the following way (rndnumA, B, S(A,B),{S(A,B),A} encrypted with the secret key shared between CA and B) encrypted with the shared key between CA and A. A then sends that part of the message encrypted with the shared key shared between CA and B to B. Upon receiving this message from A, B generates a random number (rndnumB) and encrypts that with S(A,B) and sends it to A. A upon receiving this decrypts it using the shared key S(A,B) and sends back rndnumB-1 encrypted with S(A,B) to B. The author says that the last two messages of sending back and forth of rndnumB and rndnumB-1 proves the authenticity of A to B as these messages proves that A knows

S(A,B) to B and this can happen only when A can share a proper shared key between A and CA. We feel that this involves an unnecessary message transfer between A and B as the first message from A (who is the initiator of the communication) encrypted with S(A,B) can do the job. Though this extra communication proves to be of little effect in the case of static environment this proves to be highly costly in the case of mobile environments. In the case of Mobile IP this involves extraneous computations and message transfers between the Foreign Agent and Mobile Node as well as between Home Agent and Foreign Agent. The protocol does face some problems of attacks. The shared key S(A,B) being used for huge data transfer does provide an attacker say C with some hints on calculating the key S(A,B). If this key is being used for long periods then there is a chance that the attacker may be successful in decrypting the messages and will be able to understand them. But this is not practical. However one more flaw of the same type would arise provided the same key is used for communication between A and B everytime they communicate. So the authors made the following modification to the protocol Assuming A again wants to start communication with B. This time instead of A sending the message directly to CA, it sends a message to B indicating its desire to communicate with B. The message is partly plain text and partly encrypted. The message includes an index number i(A) ,A, B , {rndnumA, i(A), A, B}encrypted with the secret key between A and CA. Now B generates the following message to CA Index number i(A) ,A, B, {rndnumA,A,B}encrypted with the secret key between A and CA , {rndnumB, A, B}encrypted with the secret key between B and CA. CA on receiving this message generates the shared key between A and B and sends them using appropriate secret key associations between itself and the communicating nodes. It also includes the index number and the random numbers that ensure no replay attacks. This way the author has reduced the problem of using the same key over and over time involving communications between the same parties and involving huge time gaps. 4.2. Direct Authentication In direct authentication the communicating parties use asymmetric authentication algorithms. In these algorithms the communicating parties have a public key and a private key. The public key is made publicly available and the owner node maintains a corresponding secret key. However the problem would be whom to believe and whom not to believe. There are chances that a node will publicize its public key with some one elses identification. In order to avoid this situation the direct authentication also uses a third party called a certification authority to sign the public key certificate of a certain node. This public key certificate contains both the subject name (namely the id of the node) and the public key of the node. For a huge network like the Internet involving many nodes one certification authority will not do. So certification authorities form a hierarchy. In this model a certification authority

signs the public key certificate stating that the public key contained in the certificate belongs to the subject name stated in the certificate. So if the communicating parties know for sure the public key of the issuing Certification Authority they will be able to check the validity of the certificates issued by this Certification Authority. To understand the working of the certification authority let us assume that there are four nodes A, B, C, D.
CA1 CA2 A B C CA3 D

If a node A wants to certify the key of a node D then it will have to follow a certificate chain with CA2 validating CA1 and CA1 validating CA3 and CA3 validating D. Similarly if D wants to verify the certificate of A it will follow a certificate chain in the reverse order of the one stated above. The certificate authorities CA2 and CA3 will provide the nodes A, B, C, D with the self signed certificates of themselves. The nodes will use these certificates to validate the other nodes in the certificate chain. If the private key of an entity is ever compromised then the corresponding pubic key should be publicly invalidated as soon as the compromise is discovered. Revoking the public key certificate does this. If the certificate would not be revoked then one node would impersonate the other node till the end of the certificates validity period. An even worse situation would occur when the private key of a certification authority is compromised as this involves the revocation of many keys. Certificate revocation is realized by maintaining certificate revocation lists(CRL). CRLs are stored in a directory and when checking an entity also has to check that the certificate has not yet been revoked which is realized by searching for the certificate in the CRL. This is relatively a slow process as the revocation has to be distributed with a public directory. Even in the Direct Authentication model we are using a middle party to help in the authentication process. So where lies the difference between Direct Authentication and Arbitrated Authentication. In the later model we have the trusted third party to involve in all the authentication processes. Whenever a node wants to communicate with another node it will have to involve the trusted third party. However in the Direct Authentication model this will not happen everytime a node wants to communicate with another node. It first gets the public key certificate of the node it wants to communicate with. From the next time when ever it wants to communicate with the same node it will have to check the certification revocation lists to ensure that the public key certificate is not revoked. If not revoked it can use the same public key it has in its cache. This way in the Direct

Authentication model a third party is involved just one time when the public key certificate is not revoked. 5. Authentication in Mobile IP The design issues in developing an authentication infrastructure and protocol for Mobile IP should include the following: 1. Authentication between the mobile node and its home network to disallow a malicious node from obtaining access to the IP packets destined for a valid mobile node. 2. Authentication between the visited network and the mobile node to ensure control access to network resources. 3. Authentication between the visited network and the home network to ensure secure accounting of network resource usage. 5.1 Standard Mobile IP Authentication The authentication process involves a cryptographic hash value to be appended to the registration messages in the form of an extension field. The extension includes type field, which indicates what are the two nodes involved in the authentication process. The extension also includes a length field, which specifies the payload length of the extension. A security parameter index (SPI) field is included in the extension which specifies the security context like the authentication algorithm to be used, its mode and the key used. The last part of the extension is an authenticator field which is computed over the entire Mobile IP registration message. A mobile node that wants to register at a foreign network listens to the agent advertisements in that network. After having received the advertisement, the registration is carried out in the following steps: The mobile node sends the registration message to the foreign agent which includes flags, describing the protocol to be used, the requested lifetime for the registration, home address of the mobile node, address of mobile nodes home agent, the care of address, an identifier of this request, mobile nodes network access identifier(NAI), an authentication extension to be checked by home agent and optionally an authentication extension checked by foreign agent. 2. Upon reception of this message, the foreign agent checks for mobile node/foreign agent authentication extension, if present, it computes a foreign agnet/ home agent authentication extension and sends the message to the home agent. This message includes the same message sent by the mobile node with an addition of an authentication extension of the foreign agent to be checked by the home agent. 3. The home agent checks the authenticity of the received message by checking the authentication extensions in the message. The home agent then creates a
1.

registration reply message which includes the mobile IP specific result, lifetime of the registration, address of the mobile node, address of the home agent, an identifier of the reply, network access identifier of the mobile node, the home agent/ mobile node authentication extension and optionally home agent/foreign agent authentication extension. 4. The foreign agent eventually computes the optional foreign agent/ mobile node authentication extension and sends the message to the mobile node. 5. Upon reception of this message, the mobile node checks the authentication extensions included in the message and assumes that it has successfully registered. This procedure has to be repeated after expiration of registration life time. However, obtaining a shared secret key between a mobile node and foreign agent before the registration has been successfully completed, is not possible as the mobile node has not yet obtained a valid IP address in the foreign network. In the normal infrastructure, the mobile node as well as the mobility agent obtain their secret keys using the Internet Key Exchange (IKE) protocol. This protocol is a very general purpose protocol and requires more effort than a dedicated protocol for Mobile IP might need. This motivates integration with the Authentication, Authorization and Accounting infrastructure when symmetric authentication algorithms are to be used. 5.2. Mobile IP Authentication with AAA infrastructure The AAA architecture involves one or more local AAA server in every administrative domain with multiple foreign agents. The AAA servers interact either directly or indirectly with the help of AAA brokers. The home domain of the mobile node contains one or more AAA servers as well as one or more home agents.
Broker

Broker

Broker

AAAL

AAAL

AAAH

FA

FA

FA

FA

HA

The following static trust relationships are pre-established. Entities involved in AAA infrastructure 1. Mobile nodes and their home AAA servers. 2. Foreign agents and their local AAA servers.

3. 4. 5. 6.

Home agents and their home AAA servers. AAA servers and one or more AAA brokers. Various AAA brokers. AAAL and AAAH servers.

The following dynamic trust relationships are also established using the static trust relationships. 1. Mobile nodes and their home agents. 2. Mobile nodes and their foreign agents. 3. Foreign agents and home agents which are currently involved. The dynamic relationships between foreign agents and home agents as well as between mobile nodes and foreign agents can be clearly understood. However, the dynamic relationship between mobile nodes and their home agents remains a bit ambiguous which can be explained in scenarios where the load on a particular home agent is high which makes the AAAH server to distribute the load evenly on all the home agents. The protocol involving AAA servers can be explained as follows: 1. All foreign agents periodically send out Mobile IP advertisements containing the Network Access Identifier (NAI) extension of the foreign agent and a random number to counter replay attacks. 2. The mobile node stores the received NAI from the foreign agent and creates a Mobile IP registration message containing the foreign agents random number, the mobile nodes NAI and a signature that can be checked by its home AAA server. 3. The foreign agent creates a AAA mobile registration request message, which contains the mobile nodes request message and sends it to the local AAA server. 4. The local AAA server either indirectly forwards the message by the use of AAA brokers or directly sends this message to the home AAA server of the mobile node by evaluating the contained NAI. 5. The home AAA server checks the signature of the mobile node in the mobile IP registration message. Upon successful validation of this signature, it creates a home agent registration message containing the mobile nodes original mobile IP registration message, a session key for use between mobile node and home agent, as well as a session key for use between the foreign agent and the home agent. It also includes the session key to be used between the mobile nodes and foreign agent. The home agent then appends its signature to the resulting message and sends it to the home agent. 6. Upon reception of this message , the home agent checks the signature of AAAH, registers the mobile node with the care of address included in the message and stores the two session keys, one to be used with mobile node and the other to be used with foreign agent. It then creates a reply message to the AAAH server which is digital signed with the static trust relatioinship between HA and AAAH.

7. The AAAH server then creates a answer message which includes the reply message sent by the home agent. The resulting message is signed and sent to the AAA server of the visited network. 8. The AAA server of the visited network checks the signature of the message, decrypts, stores, and re-encrypts the session keys using the trust relationship between the foreign agent and the local AAA server. It then sends this message to the foreign agent. 9. Upon reception and successful validation of the signature in the message, the foreign agent concludes that the mobile node is authentic. The foreign agent then decrypts and stores the two session keys to be used with mobile node and the home agent. It then forwards the registration reply message to the mobile node. 10. The mobile node first decrypts the session keys and checks the signature of the home agent. If the check is positive, the mobile node assumes that it has successfully registered at the foreign domain. After the registration lifetime expiration, if the mobile node wants to re-register, no involvement of AAA infrastructure is required, as the session keys have already been obtained. In case of handover to another foreign agent, the mobile node will try to perform authentication using the obtained session keys. For this, it signs the new foreign agents random number with the key it shares with the old foreign agent and indicates the identity of the old foreign agent by including the appropriate NAI extension into its request. The foreign agent then creates an AAA mobile registration request message which contains the mobile nodes request message and sends it to the local AAA server. The local AAA server then performs a look-up and provides the new foreign agent with the session keys the old foreign agent is holding to communicate with the mobile node and the home agent of the mobile node. Upon reception of this message, the new foreign agent can proceed with the normal Mobile IP registration without the involvement of the AAA infrastructure in case of intra-domain handover. However, this entire procedure involving the AAA infrastructure has to be performed in case of inter-domain handover. Some security remarks that has to be stated are: 1. The authentication procedure involves quite a few entities which make security analysis difficult. 2. The challenge/response verification is distributed. 3. The NAI extension of the mobile node is sent in clear text in the fixed network.

6. IP Security

Though the internet community has developed application specific mechanisms, in a number of application areas, users still have some security concerns that cut across protocol layers. By implementing security at IP layer, an organization can ensure secure networking not only for applications having security mechanisms but also for many security ignorant applications. IP layer security encompasses three functional areas: authentication, confidentiality and key management. The authentication mechanism ensures that the packet received was in fact transmitted by an authenticated sender. In addition to this, it also ensures that the packet has not been altered in transit. The confidentiality facility enables communicating nodes to encrypt messages to prevent eavesdropping by unauthorized users. The key management facility is concerned with secure exchange of keys. The documents related to IP Sec are divided into seven groups: 1. Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPSec technology. 2. Encapsulating Security Payload: Covers the packet format and general issues related to the use of ESP for packet encryption and optionally authentication. 3. Authentication Header: Covers the packet format and general issues related to the use of AH for packet authentication. 4. Encryption Algorithms: A set of documents that describe how various encryption algorithms are used for ESP. 5. Authentication Algorithms: A set of documents that describe how various authentication algorithms are used for AH and for authentication option of ESP. 6. Key Management: Documents that describe key management schemes. 7. Domain of Interpretation: Contains values needed for the other documents to relate to each other. These include identifiers for approved encryption and authentication algorithms. 6.1. IPSec Service Protocols IPSec provides security services by using two security protocols, namely Authentication Header protocol and Encapsulating Security Payload protocol. The services provided are Access Control, Connectionless Integrity, Data Origin Authentication, Rejection of replayed packets, Confidentiality and Limited Traffic Flow confidentiality. A key concept that appears in both authentication and confidentiality mechanism is the security association. An association is a one way relationship between sender and receiver that provides security services to the traffic being conducted on that channel. However, if peer-to-peer relation is needed, then two security associations are required. A security association is uniquely defined by the following three parameters 1. Security Parameter Index (SPI): A sender A assigns a bit string to the Security Association(SA) which bears only local significance. The receiving system B will understand what algorithms are to be used to process the received packet by looking at this bit string.

2. IP destination address: This is the address of the destination end-point of the security association. 3. Security Protocol Identifier: This indicates whether the association is an AH or ESP security association. Both AH and ESP support two modes of use: Transport and Tunnel mode. Transport mode provides protection primarily for upper layer protocols. The payload in this mode is the data that normally follows the IP header. Tunnel mode provides protection to the entire IP packet. To achieve this, the entire packet plus the security fields that are in the AH or ESP headers are treated as the payload of the new outer IP packet. As this outer packet may have a totally different source and destination addresses it appears to travel through a tunnel. With Tunnel mode, a number of hosts on networks behind firewalls can engage in secure communication without implementing IPSec. 6.1.1 Authentication Header: The authentication provides support for data integrity and authentication of IP packets. The data integrity feature ensures that undetected modification to a packets content in transit is not possible. The authentication feature enables the end-system to authenticate the user and filter traffic accordingly. It also prevents address spoofing attacks and guard against replay attacks. The authentication header consists of the following fields. 1. Next Header(8 bits): Identifies the type of header immediately following this header. 2. Payload Length(8 bits): Length of authentication in words with each word having 32 bits minus 2 words. 3. Reserved(16 bits): For future use. 4. Security Parameter Index(32 bits): Identifies an SA. 5. Sequence Number(32 bits): A monotonously increasing value. 6. Authentication Data(Variable): This contains the integrity check value or MAC value. It must be an integral multiple of 32 bit words. The sequence number field is designed to hinder replay attacks. The authentication data field consists of an integrity check value that is a calculated HMAC value and then truncated to get the first 96 bits which is the default length of authentication data field. The MAC value is calculated over the IP header fields that do not change in transit or that are predictable in value at the end point, the authentication header other than authentication data field and the entire upper level protocol data. The authentication header is used in transport mode when both the communicating ends share a protected secret and the authentication process is secure. However, if the communicating parties are behind the firewalls, or when the communicating parties rely on some other third party at both the ends to provide security owing to the lack of support for authentication feature, they choose the tunnel mode. In tunnel mode, the middle parties authenticate each other and provide reliable data to the communicating parties behind them.

In the case of transport mode AH using IPv4, the AH is inserted after the original IP header and before the IP payload. However, in the case of tunnel mode AH for IPv4 the entire original IP packet is authenticated and the AH is inserted between the original IP header and a new outer IP header. The inner IP header carries the ultimate source and destination address, the outer IP header may contain different IP addresses. 6.1.2 Encapsulating Security Payload: The encapsulating security payload provides confidentiality services including confidentiality of message contents and limited traffic flow confidentiality. As an optional feature, ESP can also provide the same authentication services as AH. The encapsulation security payload packet consists of the following fields: 1. Security Parameters Index(32 bits): Identifies security associations. 2. Sequence Number(32 bits): A monotonously increasing value. 3. Payload Data(variable): This is a transport level segment or IP packet that is protected by encryption. 4. Padding(0 to 255 bits): Appended to the payload data to make it an integral multiple of 32. 5. Pad Length(8 bits): Indicates the number of padding bytes immediately preceding this field. 6. Next Header(8 bits): Identifies the type of content in the payload data field by identifying the first header in the payload. 7. Authentication data (variable): This contains the integrity check value or MAC value. It must be an integral multiple of 32 bit words. This value is computed over the ESP packet minus the authentication data field. ESP uses 3-key triple DES, RC 5, IDEA, 3-key triple IDEA, CAST, Blowfish encryption algorithms. As with AH, ESP supports the use of MAC with a default length of 96 bits. It also provides HMAC-MD5, HMAC-SHA-1 authentication algorithms. The padding field serves the following purposes: 1. If an encryption algorithm acquires the plain text to be a multiple of certain number of bytes, the padding field is used to expand the plain text to the required length. 2. The ESP format requires that the Pad Length and the Next Header fields be rightaligned within the 32 bit word. The padding field is used to assure this alignment. 3. Additional padding may be added to provide partial traffic flow confidentiality by concealing the actual length of the payload. Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP. For this mode using IPv4, the ESP header is inserted into the IP packet immediately prior to the transport layer header and an ESP trailer is placed after the IP packet. If authentication is selected, the ESP authentication data field is added after the ESP trailer.

The entire transport level segment plus the ESP trailer are encrypted. Authentication covers all the cipher text and the ESP header. Transport mode operation can be summarized as follows: 1. At the source, the block of data consisting the ESP trailer plus the entire transport layer segment is encrypted and the plain text is replaced by its corresponding cipher text to form the IP packet for transmission. Authentication is added if this option is selected. 2. The packet is then routed to the destination. Each intermediate router needs to examine and process the IP header plus any plain text IP extension headers but does not need to examine the cipher text. 3. The destination node examines and processes the IP header plus any plain text IP extension headers. Then on the basis of the SPI in the ESP header, the destination node decrypts the message. Transport mode operation provides confidentiality for any application that uses it and is also reasonably efficient adding little to the total length of the IP packet. However, the drawback of this mode is that it is possible to do traffic analysis. Tunnel mode ESP is used to encrypt an entire IP packet. For this mode, the ESP header is prefixed to the packet and then the packet plus the ESP trailer is encrypted. This method can be used to counter traffic analysis. A new IP header is then appended to the entire packet carrying different addresses. Tunnel mode operation can be explained as follows: 1. The source prepares an inner IP packet with a destination address of the target host. This packet is then prefixed by an ESP header and post fixed with an ESP trailer. Then the packet along with the ESP trailer is encrypted and authentication data may be added. The resulting block is encapsulated with a new IP header. 2. Each intermediate router needs to examine and process the outer IP header plus any IP extension headers. 3. The destination then examines and processes the outer IP header plus any outer IP extensions. Then on the basis of the SPI in the ESP header, the destination node decrypts the message. It then transmits the packet in the internal network. 7. Various Architectures for Secure Mobile IP 7.1 Secure Mobile IP using AAA infrastructure In this proposed protocol, the following assumptions have been made: 1. No security association between MN and AAAF ( Authentication, Authorization, Accounting of the Foreign Agent). 2. MN and AAAH share a secret-key based security association. The following are the registration processes with regard to the protocol, named as MinPKA protocol.

Foreign Agent discovery: The mobile node upon entering a foreign network has to associate itself with a foreign agent. For this to happen, the foreign agent has to be identified. To facilitate this process of locating the foreign agent, the foreign agent delivers beacons, also called as Foreign Agent Advertisements, at regular intervals in its domain. The foreign agent includes FA authentication protocol list and the identity extension of the AAAF, if present. Mobile Node Registration Request Generation: The mobile node upon receiving the foreign agent advertisement, generates a registration request. In addition to the fixed portion of the registration request, the mobile node also includes mobile nodes Network Access Identifier (NAI), MN API extension with API field set to 3 for Min PKA protocol, AAAH identity extension, encapsulated foreign agent advertisement and a MAC value generated using the shared key between MN and AAAH. Registration Request Processing by FA: Upon receiving the registration request generated by the mobile node and encrypted with the Public key of FA, the FA decrypts the message with its private key. No authentication steps are required to be done by FA however, it looks at the encapsulated foreign agent advertisement (EFAA) to ensure that the registration request is in response to the recently issued advertisement. Upon successful validation of EFAA, the foreign agent relays mobile nodes request to AAAF. Registration Request Processing by AAAF: On receiving the mobile nodes request AAAF processes the request by appending Foreign-Home authentication information at the end of the request message. This authentication information message includes a nonce, that is generated by AAAF to be sent as a challenge to AAAH. It also includes a copy of its certificate and generates a digital signature spanning all the request message fields. AAAF then relays this request message to AAAH. Registration Request verification by AAAH: The AAAH decrypts the message using the public key in the certificate of the AAAF . Though this proves that a node having a pair of public key private key has generated this message, it cannot trust this to be generated by AAAF. The certificate ensures this. Using its secret shared key with mobile node, AAAH validates MAC value placed in the mobile nodes request. This way the AAAH has authenticated both the AAAF and the mobile node. AAAH then relays the necessary request information to HA in order to update the mobile nodes mobility binding. AAAH generation of registration reply: AAAH generates a reply message and includes the mobile nodes NAI, mobile-home AIM extension which carries the MAC value generated using the shared key between AAAH and mobile node, nonce generated by AAAF, certificate of AAAH. It then places its digital signature spanning all the reply message fields. Registration reply authentication processing by AAAF: AAAF on receiving the reply message from AAAH decrypts the message using the public key of AAAH included in the certificate of AAAH. It then verifies that AAAH echoes a correct nonce value. If the

nonce value is correct, the validation is completed successfully. AAAF then relays the reply message to FA through its secure link. FA receipt of registration reply: FA upon the receiving the reply message from AAAF relays the reply message to MN. MN receipt of registration reply: Upon receiving the reply message from FA, mobile node validates the MAC value inside the mobile home authentication object. Based on the trust relationships in mobile IP, the protocol assumes that AAAHs approval is sufficient to assure that the registration comes from the legitimate MN. MN also relies on AAAHs approval for assurance that AAAF is indeed genuine and that the visited network would provide qualified services. The assurance that AAAH itself is genuine is achieved through AAAHs ability to produce a valid digital signature of the reply. AAAH can be sure that the request is issued by a legitimate mobile node with the presence of the MAC value. AAAH can also authenticate AAAF by checking the validity of AAAFs digital signature in the relayed request. Mobile node can be convinced that the reply really comes from AAAH because of the presence of valid MAC value in the reply. In order to ensure anti replay service, the protocol mandates the presence of AAAFs nonce both in AAAFs request and AAAHs reply and the inclusion of encapsulated foreign agent advertisement extension in mobile nodes request. Although the presence of AAAF and AAAH can be seen through out the protocol, the protocol can still work without their existence. In the absence of AAAF and AAAH, no AAAF identity extension is included in the foreint agents advertisement. And also, the role of AAAF and AAAH are carried out by FA and HA in the absence of AAAF and AAAH. 7.2. A Public Key Based Secure Mobile IP In this paper the authors present a design overview of a public key management system called the Mobile IP security (MoIPS). The MoIPS provides authentication of Mobile IP control messages for location update, access control of Mobile Nodes to resources in foreign networks and secure tunneling of redirected IP datagrams. To provide these services the authors have come up with a public key based architecture. The registration messages in Basic Mobile IP and the location bindings in route optimized mobile IP carry location bindings. By altering these location bindings or by creating bogus messages or replaying prerecorded messages an adversary could redirect the traffic generated for one node to another node. In order to circumvent such problems registration and binding update messages must be protected with data integrity, origin authentication and anti replay services. Hence the authors proposes the use of a 64 bit identification tag for detecting replays and one or more authentication tags to provide message integrity and originator authentication.

In order to obtain access control in foreign networks the mobile nodes must complete their registration and attain an attachment point on the visiting subnets. In order to do this the identity and the current status of the mobile node must be verified. In this protocol the identity and network affiliation can be verified by exchanging the public key certificates and demonstrating the possession of private keys corresponding to the public keys in the certificates. On the other hand the status of the Mobile Node can be conducted implicitly by exchanging authenticated registration requests and replies between Foreign Agents and Home agents. In order for the home network to have the same amount of trust and hence provide the same amount of connectivity to a mobile node when it roams away from its home domain, the home network will require secure traffic tunneling to and from the mobile node. Similarly in order for the foreign agent to pass traffic for the mobile node the foreign network will require the traffic to be redirected by an authenticated and trusted entity such as the home agent. These secure tunnels can be implemented by using IP security protocols in tunneling mode. Public key based architecture proposed by the authors contain the following three kinds of security support 1. a scalable key management infrastructure capable of generating and dispatching long term key parameters among any pairs of nodes. 2. a rapid short term key generation algorithm for supplying short term keys needed for authenticating the mobile IP and binding update messages. 3. co-operation of mobile IP and IPsec protocols.

Mobile IP

Key Mgmt Protocols Cert Verifier

DNS Public Key Dir

Cert Mgmt System

IPSec

Crypto Engine

Direct Cert Xchg

MoIPS System block Diagram

The authors decided to develop a public key infrastructure for managing public key certificate and certificate revoking list that are issued to internet nodes. They also chose to use internet domain systems (DNS) as the primary certificate repository. They chose to

use DNS because the internet nodes are identified by domain names or IP addresses, both of which are carried by DNS. Hence, DNS certificate fetches can easily be piggy-backed to regular exchanges of communication among network entities as this communication is established with DNS lookups. The main advantage of using the PKI technology is its scalability. A DNS-based PKI has a clear advantage over a distributed system of KDCs. This is because DNS solves the potentially complicated server discovery problem and the use of certified long term public keys eliminates the need for real-time key dispatches, as the public keys are issued offline by a certification authority, while in KDCs inline involvement of a trusted third party makes scalability a bottle neck. In the MoIPS system, both Mobile IP and IP Sec modules make use of a key management module and a cryptographic engine. The key management module generates the short term keys needed by security services while the crypto engine performs the actual cryptographic processing. Keys and other security parameters are kept in a protected database are passed only to crypto-engine. In order to obtain certified public key certificates and verify the public key signatures on this electronic documents following the trust hierarchies of CAs, the cert-verifier has been implemented. The cert-verifier also maintains a cache of received and verified certificates to minimize the number of fetches and signature verification operations. MoIPS does not include an implementation of CAs in order to facilitate the integration of various certificate management systems developed by various vendors. Some of the important fields in X.509 certificates are IssuerALTName, which enable the establishment of CA hierarchy, CertPolicy , which allows the inclusion of policy specific information indicating whether a node is a mobile or static node, whether a node is home agent or foreign agent or both, KeyUsage specifying the intended use of key parameters. To generate a short-term key used for authentication services, the authors use DiffieHelman algorithm. The main design goal in the development of this short-term key are 1. 2. 3. 4. 5. Usable by all mobile nodes and agents. No modification of mobile IP message and extension formats. No use of encryption operations. Strong protection of master keys. Low correlation with other Diffie-Helman based key generation.

To reduce communication over head during the selection of IP Sec tunnels, all exchanges will be conducted with Mobile IP authentication control messages as extensions. The sequence of message exchanges for conducting the tunnel selections are 1. A mobile node chooses the IP Sec tunnel between itself and FA based on Agent Solicitation and Agent Advertisement. It also chooses MN-HA tunnels by referring to its security policy.

2. A mobile node records its choice in a tunnel selection extension and sends it along with the registration request. Upon reception, FA inspects the extension and passes the message to HA. 3. After receiving the registration request, HA checks the tunnel selection choices and sends a registration reply. This way the authors describe a design and first implementation of a Public-key management structure which satisfies the security requirements of Mobile IP for authenticated Mobile node location updates and IP Sec protected packet re direction. 7.3. Secure Mobile IP In this paper the author proposes a model to provide mobile users secure access to their companys firewall protected virtual network. The architecture for this protocol consists of an interior network and a de-militarized zone. The firewall between the interior network and the de-militarized one is the only point of entry into the organizations private network. This simplifies the security management. In this model the author plans to put all the mobile nodes those belonging to its network as well as those coming from other networks in the de-militarized zone. Since the mobile nodes belonging to the corporation have to traverse the firewall to access the private network, they have to authenticate themselves to the firewall using IPSec. Since there is a real end-to-end authentication between the corporations own mobile nodes and the firewall, they can easily be configured with secret or public keys. Thus there is one time authentication between the firewall of the home network and the mobile node in the demilitarized zone. After entering the new network area the mobile node listens for the foreign agent advertisements which are regularly broadcasted into the demilitarized zone. In certain situations the mobile node can also send an agent solicitation trigger for an agent advertisement. On getting the new advertisement the mobile node learns that it has entered a new domain and hence it will tear down any old IPSec tunnels which it has established in a different network. The node now acquires a new IP address either from a DHCP server in the new domain or from the foreign agent. The author does not speak about any authentication process happening between the mobile node and the foreign agent. If assumed that there is no authentication between the foreign agent and a mobile node then there is a possibility that a malicious node can acquire an IP address. Though node can not successfully masquerade another node and get the packets intended for it (because of the authentication with the firewall after getting the new IP address) it will lead to the exhaustion of the IP address at the DHCP server of the foreign network when the number malicious nodes are more. As the data packets are supposed to pass though the insecure public network, a logical approach would be to establish an IPSec tunnel between the mobile nodes care-ofaddress and the home firewall before any mobile IP messages are exchanged between the mobile node and the home network. The IPSec tunnel provides authentication, integrity

and privacy of each IP packet sent during the mobile IP registration procedure. The next step would be to register the mobile nodes care-of-address at the home agent. Since all mobile IP negotiation between the home agent and the mobile node pass the IPSec tunnel of the home firewall no additional authentication and encryption is required. Until the next movement the mobile node can communicate with any other correspondent node independent whether this is inside or outside the private network. Any data transfer between the mobile node and the correspondent node takes place via the home agent owing to security reasons. It is also possible to communicate with the correspondent nodes directly provided no security is needed. The encrypted and authenticated mobile IP packets are decrypted and decapsulated by the home firewall and delivered to the home agent. The home agent finally decapsulates these Mobile IP packets and delivers them to the appropriate receivers, the correspondent nodes. The presented approach allows mobile nodes to access firewall protected virtual private networks. This protocol is based on available standards and required minor modifications to the communication stack in the end systems. 7.4. IPSec Protection of Packet Redirection: When implemented on selected packet tunnels, the IPSec data authentication and data confidentiality services enable the mobile node to enjoy the same network connectivity and communication privacy as they were attached to the home network. In this model, the author proposes the use of ESP in tunnel mode. The following assumption are made on the architecture: 1. FAs and HAs providing encryption/decryption and packet filtering based on authentication should be used for the best utilization of this architecture. 2. Firewall protected subnets must enable firewalls nearest to the mobile nodes to function as FAs and all other firewalls in the network should permit the IPSec packet to pass through them. 3. Firewall protected subnets must enable firewalls nearest to the mobile nodes to function as HAs and all other firewalls in the network should permit the IPSec packet to pass through them. MN-CN, MN-HA, HA-FA and MN-FA are the possible choices of IPSec tunnels. Among these possible IPSec tunnels, MN-CN pair are end-to-end tunnels that may exist regardless of Mobile IP. However, these tunnels are to be established frequently as the mobile node changes it location. Among the other three pairs of tunnels, MN-HA tunnels are most useful while MN-FA ones are the least. FA-HA tunnel: The MIP-IPSec tunnel between HA and FA are the easiest to establish as IPSec protection can be easily added to existing Mobile IP tunnels. When they are used to support data authentication and confidentiality, these tunnels provide a virtual private network connection between home network and foreign network which will see to it that mobile node enjoys the same connectivity even in the foreign network.

MN-HA tunnel: These IPSec tunnels supporting data origin authentication and confidentiality will be the most useful tunnels as they provide a secure communication path between mobile node and home network. The data authentication prevents spoofing and confidentiality frustrates eavesdropping. The MN-HA tunnels are costly to establish as they are not part of the packet redirection mechanism and always involve a foreign agents intervention. Thus causing a bottleneck at the foreign agent and also increasing the number of trusted entities. MN-FA tunnel: This tunnel is used if no link-layer protection has already been provided. These tunnels provide data confidentiality for mobile node over the foreign network and data origin authentication for MN-HA exchange. These tunnels exist only if mobile node chooses to use a foreign agent care-of address. Hence, they are expensive and hence must be replaced whenever possible.

Type

Length = 2

reserved

HA

FA

HA

|<-------- MN TUNNEL ------>|< ----FA TUNNEL------>| Fig: Tunnel selection extension of Mobile IP registration request.

Outer IP Header

IPSec Header

Inner IP Header

Payload TCP/UDP

Fig: ESP tunnel mode encapsulated IPv4 packet.

The establishment of secure channels involves protocols such as IPSec and IKE. Although the average delay has a direct relationship with the overhead due to the cryptographic functions used for encryption and authentication, IPSec protocols over wireless links do not impose a significant penalty. This is because the main factor in the reduction of the performance is due to the erratic behavior of the channel. 7.5. Firewall Aware Transparent Internet Mobility Architecture (FATIMA) The aim in introducing the architecture of FATIMA is to integrate the various advantages of micro mobility architectures and to provide a base for more useful features like QoS and Dynamic address allocation. The basic design features of FATIMA are

1. Transparency to Mobile nodes and correspondent nodes: Any new extensions to the mobile IP must be hidden from these nodes. 2. Centralization of Security Critical Functionality: This property is the main benefit of using a firewall. 3. Mutual authentication of all instances involved: This authentication is required to prevent forged messages. 4. Efficient Micro Mobility support: Handovers between subnets in the same network can be efficiently handled than the handovers between different networks. The entities used in this architecture involve FATIMA Gateway, Home/Foreign agent proxies and Routing Agents. The FATIMA gateway is the central mobility supporting agent that is located on the bastion host inside the de-militarized zone of the networks firewall. All foreign agents are replaced by their corresponding proxies which are relatively simpler elements. These elements do not process any of the registration requests from mobile nodes, however they just pass on the messages to the FATIMA gateway. Similarly, all home agents are replaced by their proxies which are just involved for re-directing the packets, while all the registration request processing is done by the home network FATIMA gateway router. In a big network with large number of subnets involving large number of foreign agent and home agent proxies, Routing Agents are used to create a hierarchy between the FATIMA gateway router and the proxies. All of the above elements implement IPSec ESP in tunnel mode to route packets received from the parent node to the child node and vice versa. Routing of data packet in FATIMA model: In this model, data packets destined for any absent mobile node are first intercepted by the home agent proxy and then routed to the foreign network FATIMA gateway router. However, when a mobile node in a foreign network is sending a packet to any other mobile node in the same foreign network, an intermediate routing agent having an entry for both the mobile nodes can directly send the packet to the destination mobile node. This significantly improves the efficiency as the packet does not have to traverse all the way to the home agent and back to the mobile node. In cases where a mobile node is sending a packet to a fixed host in the same foreign network and a fixed host sending a packet to the mobile node the same foreign network, the packets traverse all the way to the FATIMA gateway router and are then routed to the destination hosts. Even in this case, the efficiency is improved as the packets do not traverse all the way to the home agent. The packets are routed till the FATIMA gateway router as no other routing agent contains an entry for both the hosts. Security aspects: Authentication is needed between all the entities namely between FATIMA gateway router, routing agents, foreign agent proxy, home agent proxy and mobile nodes. In FATIMA, the following authentication instances have been identified:

1. Mutual authentication between network infrastructure elements: This is mainly between the FATIMA gateway router, the routing agents, foreign agent and home agent proxies that belong to the same network. This is achieved by using IPSec ESP in tunnel mode. 2. Mutual authentication of mobile nodes and home network infrastructure: To achieve this authentication between the mobile node and home network FATIMA gateway router, MN-HA authentication extension is carried in the registration request. This authentication extension can easily be established between the mobile node and the home network FATIMA gateway router as both the elements belong to the same administrative domain. 3. Mutual authentication of home and foreign network infrastructure: This mutual authentication is established by using HA-FA authentication extension. This extension can easily be achieved in the presence of public-key infrastructure. However, even in the absence of PKI, this considerably reduces the secret key associations between the foreign network and home network entities as the number of entities per network is just one (FATIMA gateway router)as opposed to many foreign agents and home agents. Assuming there are N networks and S subnets per network, the number of secure association is considerably reduced from O(N*N*S*S) to O(N*N). 4. Mutual authentication of mobile nodes and foreign network infrastructure: this is achieved by the authentication provided by the home network FATIMA gateway router. If the home network FATIMA gateway router approves of the foreign network router, an implicit authentication has been provided to the mobile node regarding the foreign network. Similarly, if the home network FATIMA gateway router approves the mobile node, an implicit authentication has been provided to the foreign network router in regards to the mobile node. This model does not provide means for authentication between the correspondent node and the mobile node because of the authors belief that end-to-end authentication must be provided with out the involvement of any middle parties. 8. Location Privacy in Mobile IP Location privacy is very important in cases where the knowledge of the location is as useful as the contents of the transmitted messages themselves. This is considerably important in networks involving military and police. However user anonymity is also becoming increasingly important in business and private environments. Various methods have been described in the architecture and the draft for Mobile IP recommends that if absolute protection from traffic analysis is required then the mobile node must establish a bi-directional tunnel to its HA. 8.1. Security Architectures for location Privacy: 8.1.1. The Mix Method:

This method is mainly based on public key technology. In this model the sender making the message encrypts the entire message with the public key of the receiving node and then appends his address to the encrypted message. The sending node then encrypts the entire message using the public key of the mix and sends it to the mix. The mix is a trusted third party that collects all the messages from various mobile nodes as a batch and then forwards these messages in a lexicographical sequence. The reliability of the system can be enhanced using a cascade of mixes. All messages are padded with random bit strings to show uniform size. Protection from replay attacks is provided by ensuring that no message is processed more than once. Though this model provides security from traffic analysis it introduces unacceptable delay as considerable amounts of messages from various nodes have to be collected from various nodes to form a batch. Also the mix is responsible for encrypting the messages to the destination node. This also involves delay. Hence this method is restricted in its applicability to non real-time critical messaging applications. Also the use of a centralized entity causes leads to performance bottle necks and also reduces scalability. 8.1.2. The Non Disclosure Method: The non disclosure method uses the source routing approach. In this method the sending node encrypts the message using the public keys of various nodes ensuring that the packet passes through all of them. This way the source node can also ensure that none other than the first node to receive the packet from the sender knows the identity of the sender. And also none other than the last router and the sender knows about the receiver node. This way location transparency is achieved. In the mix method the route is static and any attacker can always find the route if he is able to trap all the mixes. However in the non disclosure method the attacker has no chance to find the route. So traffic analysis becomes really hard in this issue. Though the hacker is successful in compromising a single node he can just get hold of the previous sender and the immediate receiver. However there is no chance for him to locate the next nodes in the path. And to achieve complete location transparency the source will have to change the path from time to time with out sticking to the same one always. Another improvement to this would be using redundancy bits. This reduces the risk of allowing the attacker to easily compute the security association. The method used in this case is that the sender first encrypts a message using the public key and then appends this message with the redundancy bits. Then he uses this entire message to compute the new message. The new message which is the combination of the old message and the padded text is again encrypted using the public key of the receiving node. The encrypted message M sent from the sender S to receiver R in the case where no padding is used is MsgSent = K1(SA2, K2(SA3,K3(SA4(R,M))).))

In this the MsgSent is the message to be sent from the sender S to the first security agent. The security agent then decrypts the message using his private key and finds a message addressed to SA2. It then sends the remaining message to the other nodes. This way the message finally reaches the receiver. In the second case where the message is appended with redundant data would be of the form MsgSent = K1(K1(SA2,..,Kn(R,M).), Redundant Data) Similar explanation as the previous case holds. However in this model each security agent has to decrypt the message twice unlike the previous case where each security agent has to decrypt the message just once. However in this model of Non Disclosure method the amount of information stored at the node will be tremendously high and this might be a very stringent alternative in the case of mobile applications as the storage capacity at the mobile node is very low in comparison to its static counterpart. 8.2. Application of NDM in Mobile IP: In the normal Mobile IP the packets originating from the correspondent node reaches the Home Agent which then tunnels the packet to the home agent using either the Foreign Agent care of address or the co-located care-of-address. This way the tunnel in this direction is location transparent in the sense no one other than the home agent knows the real identity of the node receiving this packet. However in the other direction packets originating from the mobile node always contains the source address as the home address of the mobile Node. So this facilitates the attacker to know the network in which the mobile node is currently located. In order to achieve the location transparency of the mobile node within a network all the registration message as well as the packets sent between MN and HA sent over unsecured networks can be tunneled using NDM. This process can be conducted either by the mobile node itself or a foreign agent to which it is connected or some other node to which the mobile node is securely connected to. This way the attacker can never get to know the location of the node as the packet is encapsulated in various layers and the packet is no different from the other packets that originate from that particular network. However a potential problem arises when any one of the node in the entire route is unreachable. In this situation an ICMP message is generated. However this ICMP message can never reach the source as the ICMP message contains the first 8 bytes of data. So the best a node can do is to transmit the error message to its parent node. In order to counter this problem the author proposes to use Virtual agent identification extension. The sender generates unique VAID value for each SA and encapsulates them as a part of the data field. Using these values the ICMP message can be traced to the source.