MIPv6 Work Group Internet Draft Document: draft-sun-mipv6-dhaadsecurity-00.txt Qian Sun UNSW Lei Mu UNSW Mahbub Hassan UNSW and NICTA Henrik Petander Helsinki University of Technology Expires: May 2005 November 2004 Security Issues in Dynamic Home Agent Address Discovery draft-sun-mipv6-dhaadsecurity-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Qian, Lei Expires - May 2005 [Page 1] The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004) Copyright. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abstract This document describes potential security issues relevant to the Dynamic Home Agent Address Discovery (DHAAD) procedure in Mobile IPv6. In particular, we illustrate a Denial of Service (DoS) attack scenario and propose three possible solutions to improve the security of DHAAD in MIPv6. Qian, Lei Expires - May 2005 [Page 2] Table of Contents 1. Introduction.....................................................4 2. Terminology......................................................4 2.1 General Terms...............................................4 2.2 Mobile IPv6 Terms...........................................4 2.3 Encryption Algorithm Terms..................................5 2.4 Network Access Identifier Terms.............................5 3. Security Issues in DHAAD ........................................5 3.1 DHAAD Operation.............................................5 3.2 DoS Attack..................................................6 3.3 Disclosing Home Agent Addresses to Attackers................8 4. Proposed Solutions...............................................8 4.1 Threats Analysis............................................8 4.2 IPSec Solution..............................................9 4.3 DHAAD Request Authentication Solution Overview..............9 4.4 DHAAD Reply Authentication Solution Overview................11 5. Message Format for DHAAD Request Authentication Solution.........12 5.1 DHAAD Request Message.......................................12 5.2 DHAAD Reply Message.........................................14 6. Message Processing for DHAAD Request Authentication Solution.....14 6.1 Mobile Node Message Processing..............................14 6.2 Home Agent Message Processing...............................14 7. Message Format for DHAAD Reply Authentication Solution...........15 7.1 DHAAD Request Message.......................................15 7.2 DHAAD Reply Message.........................................16 8. Message Processing for DHAAD Reply Authentication Solution.......17 8.1 Mobile Node Message Processing..............................17 8.2 Home Agent Message Processing...............................18 9. IANA Considerations..............................................19 10. Summary.........................................................19 11. References......................................................19 Qian, Lei Expires - May 2005 [Page 3] 12. Acknowledgments.................................................20 Author's Addresses..................................................20 1. Introduction The current Mobile IPv6 specification [1] stipulates that a mobile node can dynamically discover the addresses of the home agent if it loses the address of home agent due to situations such as home agent crash or reconfiguration. The mechanism defined in [1] describes the Dynamic Home Agent Address Discovery procedure as follows. Mobile node sends ICMP Home Agent Address Discovery Request to its Home Agents Anycast Address [5]. One of the home agents on home link responds with ICMP Home Agent Address Discovery Reply that contains an ordered list of home agents. According to [1], these two ICMP messages are not required to be protected. However, unprotected messages may introduce serious security threats. For example, the mobile node may be exposed to DoS attack that prevents it from registering with home agent. If a mobile node cannot register with its home agent, no packets can be delivered to it. In addition, malicious nodes may use Dynamic Home Agent Address Discovery as a tool to get home agent addresses in home link, which makes attacks easier [1]. In this document, we describe the DoS attack scenario and three possible solutions are proposed. 2. Terminology 2.1 General Terms "|" (concatenation) Some formulas in this draft use the symbol "|" to indicate byte- wise concatenation, as in A|B. This concatenation requires that all of the octets of the datum A appear first in the result, followed by all of the octets of the datum B. 2.2 Mobile IPv6 Terms This document uses the mobility related terminology defined in [1]. The following terms are used as defined in [1]. - home address - home link - foreign link - mobile node (MN) - care-of address - home agent (HA) Qian, Lei Expires - May 2005 [Page 4] - home registration - dynamic home agent address discovery (DHAAD) - binding update (BU) 2.3 Encryption Algorithm Terms The following term is used as defined in [2], [6] and [7]. - Internet Key Exchange (IKE) - HMAC - SHA-1 2.4 Network Access Identifier Terms The following term is used as defined in [4] and [8]. - Network Access Identifier (NAI) - NAI mobility option - MN-MAI mobility option 3. Security Issues in DHAAD In this section, we describe how the DHAAD is performed. We then analyse the vulnerabilities of the mechanism and how such vulnerabilities can be used by the malicious nodes to launch DoS attacks. In addition, we also discuss a potential risk caused by DHAAD. 3.1 DHAAD Operation Sometimes when the mobile node needs to send Binding Update to its home agent to register its new primary care-of address, the mobile node may not know the home agent's address on its home link for some reason, such as home agent crash or being reconfigured, etc. In this case, the mobile node sends a DHAAD Request to Home Agents Anycast Address. One of the home agents on home link responds with a DHAAD Reply message that contains an ordered list of home agents. The mobile node attempts to initiate its home registration to each of listed addresses in turn, until the registration is accepted. This procedure is illustrated in Figure 1. Qian, Lei Expires - May 2005 [Page 5] +------+ +----------+ +----------------+ | MN | | HA | | Available HAs | +---+--+ +-----+----+ +--------+-------+ | | | |1.DHAAD Request | +------------->| | | | | |2.DHAAD Reply | | |<-------------+ | | | | |3.Binding Update | +--------------|----------------->| | | | |4.Binding Acknowledge | |<-------------|------------------+ | | | Figure 1: DHAAD Request and Reply According to current specification [1], "No security is required for DHAAD." It is based on the following consideration: mobile node cannot be tricked into using wrong home agent, as all other communication with home agents is secure [1]. The messages between mobile node and home agent are protected by IPSec which is able to ensure the authentication of both parties. 3.2 DoS Attack In this section, we describe that although the potential attackers cannot trick a mobile node to register with an illegitimate home agent, they can easily launch DoS attack and prevent mobile nodes from registering with legitimate home agents. The procedure of the DoS attack is illustrated in Figure 2. Qian, Lei Expires - May 2005 [Page 6] +------+ +--------+ +-------+ +---------------+ | MN | |Attacker| | HA | |Available HAs | +--+---+ +----+---+ +---+---+ +-------+-------+ | | | | |1.DHAAD Request | | +------------|---------->| | | | | | |2.DHAAD Reply | | |<-----------+ | | | | | | |3.DHAAD Reply (discarded by MN) | |<-----------|-----------+ | | | | | |4.Binding Update (failure) | +------------|-----------|-------`.-------->| | | | \ | `. +-----`.----------------+ |Cannot setup SA. MN | |repeats step 1 to 3 | |again and again. Cause | |a Dos Attack | +-----------------------+ Figure2: DoS attack In Figure 2, since the DHAAD Request is sent without protection, attackers in the foreign link may sniff the DHAAD Request and respond with a faked DHAAD Reply. The faked DHAAD Reply contains a false home agent address list. The mobile node may try to register with these faked home agents in turn. Although the mobile node cannot be tricked into using wrong home agents, it still may spend a long time on trying to register if there are a large number of faked home agents in the list. If mobile node cannot find a legitimate home agent, it sends DHAAD Request again. The procedure may repeat again and again, and the mobile node can never find a legitimate home agent. DoS attack may also be performed by replying a null home agent address list. When the attacker sniffs a DHAAD Request, it responds a DHAAD Reply with a null home agent address list. It's possible that the mobile node would be misled into believing that there is no available home agent on the home network. Although the legitimate home agent may also respond a DHAAD Reply message, the mobile node is not in the state of waiting for DHAAD Reply so the valid reply message may be discarded. The mobile node cannot get service from a legitimate home agent. It is possible for an attacker to achieve at least partially same Qian, Lei Expires - May 2005 [Page 7] results as with the above-mentioned DoS attack by simply blocking the Mobile IPv6 messages on a link. However, when compared with the attacker just blocks the Binding Updates, the DoS attack allows an attacker without the ability to perform Man-in-the-Middle attacks to prevent a mobile node from using Mobile IPv6. The attacker can also achieve more permanent result using the DoS attack, since mobile node will remain in a broken state with no home agents even after movement. In wireless LANs, all the nodes in the network can typically hear the traffic from each other, but cannot easily block the traffic. Using the above-described attack, a malicious node can disrupt the connectivity of all mobile nodes starting in the WLAN with minimal effort. The attack could also be easily launched automatically against any mobile node starting up on the network. 3.3 Disclosing Home Agent Addresses to Attackers The DHAAD function could be used to learn the addresses of home agents in the home network. See [1] for more information. 4. Proposed Solutions 4.1 Threats Analysis As illustrated in section 3.2, the DoS attack results from attackers sending faked DHAAD Reply messages. It is important to note that although the attacker is able to sniff a DHAAD Request message, the request message arrives at the destination (i.e. one home agent in home network) as well. Fortunately, the mobile node would receive a legitimate DHAAD Reply sent by the home agent, although the mobile node may receive other faked DHAAD Replies sent by attackers. To prevent the DoS attack, the key challenge is then how to determine whether a received DHAAD Reply message is from a legitimate home agent. It is still possible for the attacker to discover the addresses of the home agents via DHAAD, even if we could authenticate the DHAAD Reply. The attacker may learn the home agent address list by sniffing the DHAAD Reply message. Based on the analysis above, besides the DHAAD Reply message authentication, we also should authenticate DHAAD Request message and encrypt the DHAAD Reply message. There are three possible solutions described in the following sections. In section 4.2, we suggest to use IPSec to protect DHAAD Qian, Lei Expires - May 2005 [Page 8] Reply message. In section 4.3, we improve the IPSec solution by introducing a mechanism to authenticate DHAAD Request message. In section 4.4, we propose another simple solution to authenticate DHAAD Reply message without using IPSec. 4.2 IPSec Solution Since the DHAAD Reply is a unicast message sent from one of the home agents to the mobile node, IPSec could be applied to authenticate the DHAAD Reply message. The advantage of this approach is that IPSec is an existing and widely used technique. Protection can be achieved without extra effort. However, use of IPSec with IKE may introduce significant overhead on network transmission and host computation. To protect one message (i.e. DHAAD Reply), the home agent has to setup an IPSec Security Association (SA) with the mobile node. When using IPSec with Internet Key Exchange (IKE), IKE session involves at least six messages (three round trips) exchange to setup a SA between two nodes. It may also need a large number of computations. For small handheld devices, the use of IPSec may be too taxing on battery and processor performance [3]. Such overhead becomes particularly significant if this SA is used only once to protect DHAAD Reply message from the responding home agent and may not be used later for Binding Updates. A more serious problem of this mechanism is that it could introduce another kind of DoS attack. Home agent becomes vulnerable to DoS attacks, if it initiates IKE to protect DHAAD Reply with IPSec. An attacker could easily launch a DoS attack against all home agents on the home link by sending a large number of DHAAD Requests using different source addresses. Home agent(s) would create a new IKE session for each DHAAD Request, eventually running out of resources to serve valid mobile nodes. Note that there is no efficient mechanism to trace the attacker back to its real origin due to the DHAAD Requests are not authenticated. To prevent the DoS attack introduced by the IPSec solution, we propose an improved IPSec solution in section 4.3. 4.3 DHAAD Request Authentication Solution Overview We assume that there is some shared secret, such as a pre-shared key, between mobile node and all home agents in the home agent anycast group. How to get the shared secret is out of scope of this draft. Authentication of DHAAD Request is achieved by verifying the hash payload contained in the message. If the message is from a legitimate Qian, Lei Expires - May 2005 [Page 9] mobile node, the home agent should initiate an IKE session to setup IPSec SA, then send the DHAAD Reply with the protection of the SA, which ensures the authentication and confidentiality of DHAAD Reply message. This procedure is illustrated in Figure 3. +-------+ +-------+ +----------------+ | MN | | HA | | Available HAs | +---+---+ +----+--+ +--------+-------+ | | | |1.DHAAD Request (with MN-NAI, HASH_REQ) +---------------->| | | | 2.Authentication | | |-----+ | | | + | | |<----+ | | | | |3.DHAAD Reply (protected by IPSec) | |<----------------+ | | | | |4.Binding Update | | +-----------------|----------------->| | | | Figure 3: DHAAD Request authentication Step 1. The mobile node computes a HASH_REQ from its MN-NAI mobility option, care-of address and pre-shared key between the mobile node and home agent anycast group. The mobile node constructs the DHAAD Request with the MN-NAI mobility option and the Authentication option (i.e. HASH_REQ), and then transmits the message to the home agent. Step 2. One of the possible home agents receives the DHAAD Request and performs the authentication procedure. First, the home agent determines the pre-shared key with mobile node according to the MN- NAI mobility option in the DHAAD Request. Second, it computes a HASH_REQ from mobile node's NAI, mobile node's care-of address and the pre-shared key. If the computed HASH_REQ and the received HASH_REQ match, then this message is valid and the home agent should perform Step 3. If the test fails, the home agent should discard the message. Step 3. The home agent initiates an IPSec SA between its unicast address and mobile node's care-of address. After SA is set up, the DHAAD Reply is sent to mobile node with the protection of IPSec. Step 4. The mobile node receives the DHAAD Reply and tries to register with the home agents in the Home Agent Address List Qian, Lei Expires - May 2005 [Page 10] contained in the DHAAD Reply message. This solution has the same advantages with the IPSec solution mentioned in Section 4.3, moreover it protects home agent against the DoS attack. In addition, it prevents the attackers from using DHAAD as a tool to get home agent addresses from the home link. Since the potential risk described in section 3.3 is not very significant, we propose another simpler solution in section 4.4 only aims to protect home agent and mobile node against DoS attack. 4.4 DHAAD Reply Authentication Solution Overview We assume that there is some shared secret, such as a pre-shared key, between each mobile node-home agent pair. We have the same assumption in IKE [2] if pre-shared key is used in phase 1 authentication. How to get the shared secret is out of scope of this draft. Our goal of authenticating the reply is achieved by verifying the authentication option in the DHAAD Reply message. The procedure is illustrated in Figure 4. +-------+ +-------+ +----------------+ | MN | | HA | | Available HAs | +---+---+ +----+--+ +--------+-------+ | | | |1.DHAAD Request (with MN-NAI) | +---------------->| | | | | |2.DHAAD Reply (with HASH_RSP, HA-NAI) |<----------------+ | | | | |3.Authentication | | +-----+ | | | + | | |<----+ | | | | | |4.Binding Update | | +-----------------|----------------->| | | | Figure 4: DHAAD Reply authentication Step 1. Mobile node initiates DHAAD procedure by sending DHAAD Request to a mobile IPv6 Home Agents Anycast Address. The mobile node sends the DHAAD Request with the MN-NAI mobility option [4]. Qian, Lei Expires - May 2005 [Page 11] Step 2. When one of the home agents receives the DHAAD Request, it computes a one-way hash, HASH_RSP, from the identifier field in the DHAAD Request, home agent address list and the pre-shared key determined by the mobile node's NAI. Then the home agent constructs HA-NAI mobility option and Authentication option and transmits the message to the mobile node. Step 3. When the mobile node receives the DHAAD Reply, it uses HA-NAI mobility option to determine the pre-shared key between the mobile node and the home agent. Then the mobile node computes HASH_RSP from four factors: the identifier field of the DHAAD Request, the home agent's NAI, the home agent address list and the pre-shared key between mobile node-home agent pair. If the computed HASH_RSP and the received HASH_REP match, then this message is valid and the home agent should perform step 4. Otherwise the home agent should discard the message. Step 4. The mobile node tries to register with a legitimate home agent by sending the Binding Update message. 5. Message Format for DHAAD Request Authentication Solution In this section, we define the message format for the DHAAD Request authentication solution. 5.1 DHAAD Request Message In this draft, we extend the message with two options: MN-NAI mobility option and Authentication option. The new DHAAD Request message format is defined as follows: Qian, Lei Expires - May 2005 [Page 12] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . MN-NAI Mobility Option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Authentication Option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MN-NAI mobility option is defined in [4]. Authentication option is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type to be defined by IANA. An 8-bit identifier of the type authentication option. Length: 8-bit unsigned integer, representing the length in octets of the reserved field and authenticator field, not including the type and length fields. Qian, Lei Expires - May 2005 [Page 13] Authenticator: The length of Authenticator is 96-bit. This field is the information to authenticate the DHAAD messages. 5.2 DHAAD Reply Message For description of the message, see [1]. 6. Message Processing for DHAAD Request Authentication Solution 6.1 Mobile Node Message Processing Mobile node initiates DHAAD function by constructing and sending a DHAAD Request message to Home Agents Anycast Address. Before sending the DHAAD Request message, it performs the following steps: Step 1. Construct the identifier field using pseudo random function. Step 2. Determine pre-shared key between the mobile node and the Home Agents Anycast Address. Step 3. Compute a HASH_REQ, where: HASH_REQ = First (96,HMAC_SHA1(MN-HA pre-shared key, identifier | MN-NAI | IP_MN )) Note: MN-HA pre-shared key = the pre-shared key got in step 1 identifier = the identifier field in the DHAAD Request MN-NAI = the NAI in the MN-NAI mobility option IP_MN = the mobile node's care-of address Step 4. Construct MN-NAI mobility option. Step 5. Construct Authentication option from the HASH_REQ computed in step 3. Step 6. Transmit the DHAAD Request message to the Home Agents Anycast Address. The mobile node processes the DHAAD Reply message as described in section 11.4.1 of the Mobile IPv6 specification [1]. 6.2 Home Agent Message Processing When the home agent receives a DHAAD Request, it authenticates the Qian, Lei Expires - May 2005 [Page 14] message by following steps: Step 1. Determine the pre-shared key according to the NAI in the MN- NAI mobility option. Step 2. Compute the HASH_REQ where: HASH_REQ = First (96,HMAC_SHA1(MN-HA pre-shared key, identifier | MN-NAI | IP_MN )) Note: MN-HA pre-shared key = the pre-shared key got in step 1 identifier = the identifier field in the DHAAD Request MN-NAI = the NAI in the MN-NAI mobility option IP_MN = the mobile node's care-of address Step 3. If the HASH_REQ is not identical to the HASH_REQ in the DHAAD Request Authentication option, the home agent regards it as an invalid DHAAD Request message and discards it. Otherwise perform step 4. Step 4. If the DHAAD Request is from a legitimate mobile node, the home agent constructs a DHAAD Reply message and sends to the mobile node. Before sending the DHAAD Reply, it sets up a SA with the mobile node's care-of address. Then the DHAAD Reply message is sent with the protection of IPSec. 7. Message Format for DHAAD Reply Authentication Solution In this section, we define the message format for the DHAAD Reply authentication solution. 7.1 DHAAD Request Message We extend the message with MN-NAI mobility option [4]. The new DHAAD Request message format is defined as follows: Qian, Lei Expires - May 2005 [Page 15] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . MN-NAI Mobility Option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MN-NAI mobility option format is defined in [4]. 7.2 DHAAD Reply Message In this draft, we extend the DHAAD Reply message with HA-NAI mobility option and Authentication option. The new DHAAD Reply message format is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA-NAI Mobility Option . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Option . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . Home Agent Addresses . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The HA-NAI mobility option is defined as follows: Qian, Lei Expires - May 2005 [Page 16] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | NAI . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type NAI-OPTION-TYPE to be defined by IANA. An 8-bit identifier of the type mobility option. Option Length 8-bit unsigned integer, representing the length in octets of the subtype and NAI, not including the Option Type and Option Length fields. Subtype Subtype field defines the type of NAI, identifying the home agent entity. NAI A string of form user@realm as defined in [8]. Authentication option has been defined in section 5.1. 8. Message Processing for DHAAD Reply Authentication Solution 8.1 Mobile Node Message Processing Mobile node initiates the DHAAD function by constructing and sending a DHAAD Request message to Home Agents Anycast Address. Before the mobile node sending the DHAAD Request message, it performs the following steps: Step 1. Construct the identifier field in DHAAD Request using pseudo random function. Step 2. Construct MN-NAI mobility option. Step 3. Transmit the DHAAD Request message to Home Agents Anycast Address. Qian, Lei Expires - May 2005 [Page 17] When receiving DHAAD Reply, the mobile node performs the following steps to verify the authentication of the message: Step 1. Determine the pre-shared key according to the NAI in the HA- NAI mobility option. Step 2. Compute the HASH_RSP where: HASH_RSP = First (96,HMAC_SHA1(MN-HA pre-shared key, identifier | HA-NAI | home agent address list)) Note: MN-HA pre-shared key = the pre-shared key got in step 1 identifier = the identifier field in the DHAAD Request HA-NAI = the NAI in HA-NAI mobility option home agent address list = home agent address list in the DHAAD Reply Step 3. If the computed HASH_REQ and the received HASH_REQ match, then this message is valid and the home agent should perform step 4. If the test fails, it should discard the message. Step 4. The mobile node attempts home registration with any of the addresses listed in the home agent address field of the DHAAD Reply. 8.2 Home Agent Message Processing When the home agent receives a DHAAD Request, it performs the following steps: Step 1. Determine the pre-shared key according to the NAI in the MN- NAI mobility option. Step 2. Construct HA-NAI mobility option. Step 3. Compute the HASH_RSP where: HASH_RSP = First (96,HMAC_SHA1(MN-HA pre-shared key, identifier | HA-NAI | home agent address list)) Note: MN-HA pre-shared key = the pre-shared key got in step 1 identifier = the identifier filed in the DHAAD Request HA-NAI = the NAI in the HA-NAI mobility option home agent address list = home agent address list to be Qian, Lei Expires - May 2005 [Page 18] contained in the DHAAD Reply Step 4. Construct Authentication option from the HASH_RSP Step 5. Transmit the DHAAD Reply message to the mobile node. 9. IANA Considerations This document defines a new Authentication option and a HA-NAI mobility option. The Authentication option is defined in section 5.1, which is a new ICMPv6 option. The HA-NAI mobility option is defined in section 7.2, which is a new subtype of NAI mobility option. The type value for the two options needs to be assigned from the same space used by the mobility options defined in [1]. 10. Summary We described a potential DoS attack against DHAAD, which has never been mentioned in any RFCs or drafts before. The DoS attack prevents an IPv6 mobile node from registering with its home agent. This draft also presents three mechanisms for securing the DHAAD function. Two of them are alternative methods for protecting mobile node against DoS attacks. The third one can be used for protecting the home agents on home link alone or together with either one of the two methods for protecting mobile node. Together the mechanisms effectively protect the DHAAD function. 11. References [1]D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004 [2]D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998 [3]A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury, "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth- protocol-00.txt, July 2, 2004 [4] A. Patel, K. Leung, H. Akhtar, and K. Chowdhury, "Network Access Identifier Option for Mobile IPv6", draft-ietf-mip6-nai-option- 00.txt, July 2004 [5]Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999 [6]Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [7]National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995 [8]Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999 Qian, Lei Expires - May 2005 [Page 19] 12. Acknowledgments Some useful discussions with Kunchan Lan are hereby acknowledged. Author's Addresses Qian Sun The University of New South Wales Sydney, NSW 2052, Australia Email: qsun300@cse.unsw.edu.au Lei Mu The University of New South Wales Sydney, NSW 2052, Australia Email: lmux801@cse.unsw.edu.au Mahbub Hassan The University of New South Wales Sydney, NSW 2052, Australia Email: mahbub@cse.usw.edu.au and National ICT Australia (NICTA) Locked Bag 9013 Alexandria NSW 1435, Australia Email: mahbub.hassan@nicta.com.au Henrik Petander Helsinki University of Technology POB 5400, FIN-02015 HUT, Finland Email: henrik.petander@hut.fi Qian, Lei Expires - May 2005 [Page 20]