Mobile IPv6 Security while traversing a NAT

Transcription

1 Mobile Pv6 Security while traversing a NAT Geon-Woo Kim, Jong-Wook Han, Dong-1 Seo Electronics and Telecommunications Research nstitute 161 Gajeong-Dong Yuseong-Gu Daejeon, KOREA Abstract- The mobile Wv6 protocol allows a mobile node to move from one link to another without changing the mobile node s home address by using a care-of address. When a mobile node moves to a foreign link bebind a NAT, it uses a local-scope care-of address, which bas been allocated by a foreign router dominating the visited nehvork, as identification of itself. On the other hand, other nodes outside the NAT are going to identify the mobile node by a public care-of address translated into from the local-scope care-of address by the NAT. As each security mechanism running over mobile Pv6 relies on the P address information, it brings about many critical problems. Therefore, io this paper, we propose some modifications to the legacy mobility messages by just adding single flag to address incompatibilities caused by NAT-deployment. With the new proposed mechanism, we can provide secure and seamless Pv6 mobility services regardless of the mobile node s current point of attacbment to the nternet, even though it is located behind a NAT.. NTRODUCTON The mobile Pv6 protocol allows a mobile node to move from one link to another without changing the mobile node s home address. Packets may be routed to the mobile node using this address regardless of the mobile node s current point of attachment to the nternet. The movement of mobile node away from its home link is transparent to transport and higher-layer protocols and applications []. Mobile nodes are uniquely identifiable by a globally routable P address [2]. This assumption breaks down when a mobile node attempts to communicate from behind a Network Address Translation [3]. Since each binding update to home agent and correspondent nodes relies on the mobile node s home address and primary care-of address, which uniquely identifies the mobile node, care must be taken when moving into behind a NAT. Especially, mobile Pv6 route optimization can operate securely even Without pre-arranged security associations; it uses return routability procedure for correspondent nodes to authorize a mobile node On recognition of the NAT-deployment, the mobile node might suppose that it is identifiable by a local-scope care-of address allocated by the NAT. Nevertbeless, the home agent and the correspondent nodes still use a globally routable address translated into from the local-scope care-of address by the NAT as the mobile node s identification. After all, the mobile node isn t to be provided with seamless mobile network services, as authenticatiodauthorization processes during binding update and return routability procedure may not be completed due to inconsistency between both identifications of the mobile node. n this paper, we propose some modifications to the legacy Pv6 mobility messages to unify the identifications and make it possible to securely authorize the mobile node, even when traversing a NAT. 11. NCOMPATBLTES BY NAT-DEPLOYMENT Mobile Pv6 relies on exchanging traffic between home network and mobile node through Psec ESP transport/tunnel modes. A mobile node that communicates from behind a NAT is reachable only through a globally routable address used by the NAT, called a public care-of address. A mobile node that resides behind a NAT is going to continue communicating with correspondent nodes through a local-scope address, called private care-of address, configured by the NAT, not routable in public network outside the NAT. Anyway, the mobile pv6 employs the Psec ESP in tunnel mode instead of -in-p used by mobile P for tunneling packets between home agent and mobile node. ipsec ESP in tunnel mode doesn t need to care about legal access to address fields of P packets by the NAT, just decapsulates the packets and forwards to correspondent node or absorbs them. Also, we can employ Psec ESP in transport mode for exchanging traffic between home agent and mobile, e.g., home registration, prefix advertisementholicitation, etc. Generally, it is out of the question when one identifies the other by the outer P address. n some cases of exchanging control traffic, there may be another way for ensuring each other. For instance, home agent sends binding acknowledgement message in reply to bind update message to the address contained in the Altemate Care-of Address option, not the source address of the P packet translated by a NAT. Consequently, it leads to that the home agent uses private address in the nternet, which isn t routable. Besides, references to SAS are based on P address, so both end hosts may have different SAS for Psec enforcement from each other. n this paper, we d better concern about only how to handle the two care-of addresses (private, public) contained in the payload and Psec SAS, as well as extensions of binding update message, binding acknowledgement message and router advertisement message for NAT-awareness NAT DEPLOYMENT EN-KOWE TO MOBLE NODE Each mobile pv6 node is able to travel any foreign link and be provided with seamless communications regardless of its current point of attachment to the htemet. Also, sometimes it is likely to be located bebind a NAT, which permits only private care-of address for it. n this case, some special cares must be /03/$ EEE. 331

2 taken for secure mobile service. t can be summarized as follows; A. Psec ESP Transpori SA Establishment between home agent and mobile node SAS with Psec ESP in transport mode contain secnrity mechanisms for the traffic between a mobile node and a home agent, where each operates as an end-node. f this traffic is not protected, mobile nodes and correspondent nodes are vulnerable to Man-in-the-Middle, Hijacking, Confidentiality, mpersonation, and Denial-of-Service attacks. Any third parties are also vulnerable to Denial-of-Service attacks. n order to avoid these attacks, the base specification uses Psec to protect traffic between the home agent and the mobile node. t consists of various messages camed by the Mobility Header protocol in Pv6. The traffic takes the following forms: 0 Binding update and acknowledgement messages exchanged between the mobile node and the home agent. 0 CMPv6 messages exchanged between the mobile node and the home agent for the purposes of prefix discovery. 0 All payloads exchanged between the mobile node and the home agent as end nodes. 0 f multicast group membership cootrol protocols or stateful address auto-configuration protocols are supported, payload data protection support is required. When the control traffic between the mobile node and the home agent requires message authentication, integrity, correct ordering and replay protection, both the mobile node and the home agent should use the ESP header in transport mode and must use a non-null payload authentication algorithm. The mobile node and the home agent must have a security association to protect the traffic. Furthermore, great cares need to be taken when using ME for establishing secnrity associations to the mobile mv6 home agent. The right kind of addresses must be used for transporting KE. This is necessary to avoid circular dependencies in which the use of a binding update triggers the need for an KE exchange that cannot complete prior to the binding update having been completed ~41. f there is no existing secnrity association to protect the binding update, KE is initiated. The phase 1 identity used for the mobile node may be a FQDN. During the negotiation, the mobile node is identifiable by its new private care-of address and the home agent identifies it by public care-of address translated into from the private care-of address by a NAT. But each node negotiating Psec SAS through KE protocol identifies each other by the dentification Payload in phase 1 and phase 2. The phase 2 identity used for the mobile node is the mobile node s home address. Consequently, the negotiated new SAS are based on both the mobile node s home address and home agent s address, and we can employ them for traffic between home agent and mobile node as they are. Since mobile F v6 uses Home Address Destination Option and Type 2 Routing header for notifying the mobile node s home address, we can apply Psec based on the home address regardless of its current location. NAT traversal can t disturb SA deployments for traffic between home agent and mobile node. B. ome Regishation through a NAT When a mobile node moves into foreign link away from home, it can realize that it is attached to foreign link on the receipt of a router advertisement message from the foreign router. With it, the mobile node can perform network renumbering and mobile configuration. Furthermore, if a NAT is deployed, we need to inform the mobile of the existence of NAT. n order to make the mobile node NAT-aware, it is reasonable to extend the existing router advertisement message by adding single N flag, which indicates that they are behind a NAT. Receiving the router advertisement message with N flag set, the mobile node send a binding update message to its home agent in order to register the primary care-of address, A following example depicts the proposed home registration flow. M.*N* Binding Ae owledgemen1 _de* Fig. 1 Home Registration Procedure through a NAT According to the standard procedure specified in the ETF document, a home registration needs only single BUBA pair. But, where a NAT is deployed, due to the intermediate access to outer P header, home registration may not be performed correctly. That is to say, the mobile node should use Psec ESP in transport mode to ensure the security of the binding information, especially the primary care-of address. On the other hand, the primary care-of address is not to be protected, because it is contained in the source address field of the P header, where Psec ESP in transport mode can t guarantee the security. n order to fix up it, the binding update message has been configured to contain an Alternate Care-of Address option to make the primary care-of address be protected. As the NAT translates the private care-of address into the public care-of address, the source address of P header differs from the care-of address contained in the Alternate Care-of Address option. Then, the home agent deduces that someone has modified the P header and it is not correct any more, so uses the care-of address contained in the Alternate Care-of Address option as a primary care-of address ofthe mobile node, 332

3 which is a private care-of address of the mobile node. Accordingly, it leads to a result that packets destined to the mobile node are forwarded with the private care-of address by the home agent. But those packets can t be delivered to its destination in that the destination address is local-scope and invalid in public network. Consequently, we can conclude that the home agent must know the public care-of address of the mobile node. To make it possible, we extends the binding update message and the binding acknowledgement message by adding single N flag to indicate that NAT is running over the path and has a permission to access messages passing through. C. Establishment of Tunneling nterface Psec ESP in tunnel mode must be supported and should be used for the protection of packets belonging to the retum routability procedure. A non-null encryption transform and authentication algorithm must he applied. Mobile node establishes a pair of security associations in tunnel mode for protecting retum routability packets. This step uses the phase connection established in A, and multiple phase 1 connections are also possible. M.U BU c Home Network Private care4 Address Fig. 2 Messages exchanged between mobile node and home agent while registering a binding The home agent receiving the binding update message with the N flag set deduces that the message bas traversed a NAT and its source address of 1P header has been translated from the private care-of address into the public care-of address. According to the specification of mobile F v6, a home agent can recognize a mobile node s primary care-of address by inspecting a care-of address field contained in the Alternate Care-of Address option. But in this case, the address from the Alternate Care-of Address option is a private care-of address, which the home agent doesn t want to know. Therefore, the home agent would better use the source address ofthe p heade as a primary care-of address of the mobile node. t is applicable only when N flag is set. The home agent processes the binding update and replies with binding acknowledgement whose N flag is set. Here, how the home agent can ensure that the source address of the P header bas not been illegally modified by someone en-route? n order to guarantee the legality of the translations, we employ an additional binding update message, which gives a conviction that the binding acknowledgement message destined to the public care-of address has been delivered to the correct mobile node. Receiving the second binding update message means that the fmt binding update message deserves to be trusted. Mer the home agent receives the second binding update message, the home registration is completed. When the mobile node issues the second binding update message, its sequence number must he incremented by 1. Fig. 3 Tunnel Mode between the home agent and mobile node f the mobile node and the home agent have the capability to change the ME endpoints, they would better change the address. Strictly speaking, the mobile node changes the source address into its own private care-of address and the home agent into the public care-of address respectively. f they don t have the capability, both nodes remove their phase 1 connections created on top of the previous care-of address and establish a new KE phase 1 on top of the care-of addresses. This capability to change the ME phase 1 endpoints is indicated through setting the Key Management Mobility Capability (K) flag in the binding update message and binding achowledgement message [4]. Consequently, the home agent and the mobile node maintain their own SAS different from each other. D. Return Routability Procedure Protection of binding updates sent to correspondent nodes does not require the configuration of security associations or existence of authentication infrastructure between the mobile nodes and the correspondent nodes. nstead, a method called the rehun routability procedure is used to assure that the right mobile node is sending the binding update message. This procedure is not secure against attackers who are on the path between the home network and the correspondent node. However, attackers in such a location are capable of performing the same attacks even without mobile lpv6. The main advantage of the return routability procedure is that it limits the potential attackers to those having an access to one specific path in the nternet, and avoids forged binding updates from anywhere else in the nternet. 333

4 Correspondent Node private care-of address. With N flag in binding update message, the correspondent node can he aware of the deployment of NAT and uses a source address field as a primary care-of address, whicb is the private care-of address. n order to ensure the source address field, they exchange an additional binding update message from the mobile node to the correspondent node. After receiving the binding update message, then the correspondent node can be convinced that the translated source address has been pure en-route. The exchanged messages are as follows; Fig. 4 Retum Routability Procedure through a NAT Every HoT and HOT messages are processed based on the mobile node's home address, so not affected by the mobility. Especially, NAT deployment doesn't have an effect on the Home Test in return mutability procedure. But it is likely to bring about some considerations in processing the CoT and COT messages, whicb are performed based on the primary care-of address. The care-of keygen token has been generated based on the public care-of address by the correspondent node, and mobile node is not aware of the public care-of address resulting from translating its own private care-of address into. However, since the mobile node is going to use the care-of keygen token from the correspondent node as it is, without generating a new care-of keygen token for itself, the deployment of NAT can't be an obstacle to processing the return routability procedure. E. Correspondent Binding Procedure A correspondent node is able to authorize a mobile node which is supposed to originate correspondent binding procedure according to the Kbm created during rem routability procedure, where the Kbm is a key used for authorizing a binding cache management message. A way to enhance compatibilities between return routability procedure and NAT is similar to that of home registration, so we are able to settle problems that are occurred during a correspondent binding procedure with the same way used during the home registration through a NAT. A correspondent binding procedure is different from a home registration in that it uses a binding authorization data option for authorizing binding update message and binding acknowledgement message instead of using Psec. f a correspondent binding procedure is capable of using Psec, there is no need to perform a return routability procedure, which is just a substitution for Psec for simplicity. To speak honestly, Psec is so heavy that it is not desirable to employ it in every connection between mobile node and correspondent node. A binding management key, Kbm is created as follows; MAC mn MAC S A(Kbm. (core-ofaddress CNoddress BlJj MAC cn MAC S Al(Kbm, (care-ofaddress CNaddmSs BA) The same care-of address that are used in calculating the MAC values as input parameters must be used and may be the Fig. 5 Correspondent Binding Procedure through a NAT V. CONCLUSON n order to continue communication in spite of its movement, a mobile node could change its F' address each time it moves to a new link. But the mobile node would then not be able to maintain transport and higher-layer connections when it changes location. The mobile Pv6 allows a mobile node to move from one link to another without changing the mobile node's home address. Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the nternet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications. However, if a mobile node moves to foreign link behind a NAT, then it brings about many critical problems. As the mobile node uses a private care-of address allocated by a foreign router behind the NAT as its own new primary care-of address, it may attempts to register the private care-of address to its home agent and correspondent nodes, but which is local-scope and can not be routed in public network. n order to fix up these issues, we need some modifications to the router advertisement message, the binding update message, and binding acknowledgement just by adding single N flag in the resewed field to indicate that NAT is running en-route and F' header may change while traversing it. With the flag in the router advertisement message, the mobile node can recognize that it is currently located behind a NAT. Binding update messages and binding acknowledgement message use the flag to inform that p address in each message has been translated by the NAT. 334

5 As a result, it is possible to make binding update and return routability procedure recognize the relationship among the mobile node home address, public care-of address and the private care-of address. t is clear that all security mechanisms deployed in mobile Pv6 depend on P address used mobile node. n order to make some network devices against Psec security paradigms such as NAT device work well, it is mandatoty to enhance compatibilities between mobile F v6 and NAT By adding single flag to binding update messages and binding achowledgement messages for notifying that NAT is deployed en-route and the visible address outside the NAT is not a real care-of address from the mobile node s point of view, we can fix up many incompatibilities occurred during movement behind a NAT. As well, in order to trust the source address field of binding update message, which might not be protected by Psec, we are encouraged to append an additional binding update message from the mobile node to both the home agent and the correspondent nodes. Consequently, we can provide the security in mobile Pv6 regardless of mobile node s current point of attachment to the nternet, including foreign link behind a NAT, by adding single flag in each binding message, which burdens legacy network with little overheads. [] [2] [3] [4] REFERENCES D. Johnson, C. Perkins,. Arkko, Mobility Support in Pv6. ETF Mobile P Workies roup lnrernel-drofr Perkins, C., 1P Mobility Support for Pv4, RFC 3344, August H. Levkowetz, S. Vaarala, Mobile P NATiNAF T Travenal using UDP Tunneling, ETF Mobile P Working Group nternet-draa, November4, Arkko, V. devarapalli, F.Dupant, Using Psec to Protect Mobile 1Pv6 Signaling between Mobile Nodes and Home Agents, ETF Mobile P Working Group nternet-draft, Febuary 18,