MobiSeND Deliverable SP4a: Link Layer Security Issues in IPv6 mobility protocols

Tony Cheneau Tony.Cheneau@it-sudparis.eu Arnaud Ebalard arnaud.ebalard@eads.net Thierry Ernst Thierry.Ernst@inria.fr

Maryline Laurent-Maknavicius Maryline.Maknavicius@it-sudparis.eu June 8, 2009

Abstract

The objective of the document is to identify in IPv6 mobility protocols the security issues related to the interactions over the network link (Neighbor Discovery) hosting IPv6 mobile nodes and to realize a state of the art of lacks and specic solutions associated to those protocols. On one hand, this study will focus on IPv6 mobility protocols standardised at the IETF (e.g. Mobile IPv6, NEMO Basic Support, Hierachical Mobile IPv6, Fast Mobile IPv6) and on the other hand on more prospective approaches (e.g. Proxy Mobile IPv6, MANEMO, Global HAHA) for which there are no stable specications.

Contents
1 Introduction to IPv6 Mobility and its challenges 2 Node-managed mobility: the Mobile IPv6 family 2.1 Node-managed mobility concept . . . . . . . . . . . . . . . 2.2 Overview of the IPv6 mobility support protocols . . . . . . 2.2.1 Host mobility support (MIPv6) . . . . . . . . . . . . 2.2.2 Network mobility support (NEMO BS) . . . . . . . 2.2.3 Hierarchical mobility support (HMIPv6) . . . . . . . 2.2.4 Combination of NEMO and MANET: MANEMO . . 2.2.5 Global distribution of HAs: Global HAHA . . . . . . 2.3 Common new IPv6 headers and options . . . . . . . . . . . 2.3.1 Type 2 Routing Header . . . . . . . . . . . . . . . . 2.3.2 Destination Option Header - Home Address Option 2.3.3 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 MIPv6 and Routing Optimization . . . . . . . . . . . . . . 2.4.1 Non optimized mode . . . . . . . . . . . . . . . . . . 2.4.2 Optimized mode . . . . . . . . . . . . . . . . . . . . 2.5 MIPv6 and Link Layer security issues . . . . . . . . . . . . 2.5.1 Scope and Hypothesis . . . . . . . . . . . . . . . . . 2 4 4 6 6 6 7 8 9 10 10 11 12 12 13 15 17 17

2.5.2

2.6

2.7

Link detection mechanism and Returning Home events . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 Summary and possible threats . . . . . . . . . . . . 2.5.4 Current solutions and possible workarounds . . . . . MIPv6 and DHAAD Mechanism . . . . . . . . . . . . . . . 2.6.1 Presentation . . . . . . . . . . . . . . . . . . . . . . 2.6.2 DHAAD Mechanism: the attack and SEND limitation NEMO and Link Layer security issues . . . . . . . . . . . . 2.7.1 NEMO and DHAAD Mechanism: the attack and SEND limitation . . . . . . . . . . . . . . . . . . . .

18 19 22 23 23 25 26 26

3 Network-managed mobility: NetLMM 3.1 Network-managed mobility concept . . . . . . . . . . . . . 3.2 PMIPv6: a NetLMM implementation . . . . . . . . . . . . 3.2.1 Interactions between the Mobile Node and the Mobile Access Gateway . . . . . . . . . . . . . . . . . 3.2.2 Interactions between the Mobile Access Gateway and the Local Mobility Anchor . . . . . . . . . . . 3.3 Link Layer security issues in PMIPv6 . . . . . . . . . . . 3.3.1 Link between the LMA and the MAG . . . . . . . 3.3.2 Link between the MN and the MAG . . . . . . . . 3.4 Current solutions . . . . . . . . . . . . . . . . . . . . . . . 3.5 Remaining problems . . . . . . . . . . . . . . . . . . . . . 4 Synthesis A MIPv6 Home Return A.1 Mobile IPv6 Home Link detection mechanism . . . . . . . A.2 Emission of deregistration BU by the MN . . . . . . . . . A.3 Receipt and validation of deregistration BU by the HA . . A.4 Local impacts of BU processing on the HA and emission of BA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Local impact associated with BU emission and BA processing on the MN . . . . . . . . . . . . . . . . . . . . . . . . B Bibliography

26 . 26 . 29 . 29 . . . . . . 31 33 33 34 34 35 35 36 . 36 . 36 . 38 . 40 . 41 42

1 Introduction to IPv6 Mobility and its challenges

When a node changes its point of attachment for another subnetwork or simply loses one of its connection mean (no more coverage, for instance) for another, the address of the nodes interface attached to the new link must be changed accordingly. This has two main consequences : 1. existing connections (TCP connections, IPsec SA, IKE sessions, . . . ) between the node and its clients/peers become invalid, because they are bound to the IP address 2. the mobile node is no more accessible at its old address if someone wants to contact it in order to mount new connections. Its trac does not follow it at its new point of attachment : its address is not stable.

To understand the problems associated with IP mobility, one must understand the dual role of an IP address for a node : it is both a node identier 1 (Identier) but also an address for routing packets to the node (Locator). Through the use of hierarchical addressing in IPv6, the last function can be seen as the information required to access the nodes topological location. In IPv6, all devices must be congured with an IPv6 address bearing a prex that is topologically meaningful, i.e. representing the position of the subnet in the Internet hierarchy. The Internet is hierarchically organized and the further down the hierarchy the more meaningful the prex is. So, the rst 64 bits of the IPv6 address indicate the subnet in which a node is attached, and these together with the last 64 bits which identify the interface uniquely identify the node. So, in a mobile environment, when a node is moving from one subnet to another, like from the network of the campus to a WiFi access point in the street, the device necessarily needs to change its IP address. As a result, all sessions, which are based on the IP addresses of the source and destination break, and new sessions can only be initiated if the correspondent knows the current IP address. This is due to the fact that traditional transport layer protocols (TCP, UDP) use the IP address as a stationary identier of the node. Every protocol that deals with IP mobility has to take those facts into account and provide solutions to deal with that duality. It is interesting to note that the same problems also arise with multihoming technologies because they also have to provide a way to designate a node (Identier) that is compatible with multiple prexes (Locator). The diculty of the challenge is to nd a mobility support solution that is both ecient and also compatible with the current internet, i.e. that does not require modications at the infrastructure level. Mobility support mechanisms have thus been devised in order to provide transparent and uninterrupted access to the Internet while the device changes its point of attachment. These protocols solve both problems at the same time. First, they allow transport layer sessions to continue even if the underlying nodes move and change their IP addresses. Second, the protocols allow a node to be accessed through a static IP address. In other words, mobility support tries to preserve the identier nature of the IP address though IP addresses are locators by their nature. Both single terminals and entire networks (access networks deployed in public transportation, sensors networks embedded in vehicles, and personal area networks, i.e. networks of devices attached to people) could change their point of attachment, so mobility support mechanisms are ` ` declined into Ohost mobility supportO and Onetwork mobility supportO respectively. A number of protocols have been specied by the IETF 6 to provide this support: Mobility support is provided by the main following protocols: 1. Mobile IPv6 (MIPv6) for mobile hosts (host mobility support). 2. NEMO Basic Support (NEMO-BS) for mobile routers and their attached nodes (network mobility support). 3. Hierarchical Mobile IPv6 (HMIPv6) provides a mixed global-local solution optimizing mobility management signaling when the mobile nodes are roaming locally (note that HMIPv6 is limited to support mobile hosts only).
1 this is by this means that the node is commonly specied, as a service provider, even if it most probably requires a preliminary DNS query

4. Proxy Mobile IPv6 (PMIPv6) for local mobility management, i.e. within a single administrative domain (note that P-MIPv6 is limited to support mobile hosts only). Mobile IPv6, NEMO Basic Support and HMIPv6 are relying on the same kind of signaling (they all use Type 2 Routing Header and the Home Address Option dened in the MIPv6 specication) and require the mobile node to actively take part in all mobility management operations (i.e. this is a node-managed mobility approach). On the other hand PMIPv6 is not relying on this kind of signaling and is operating transparently to the mobile node (i.e. this is a network-managed mobility approach).

2 Node-managed mobility: the Mobile IPv6 family

This section is presenting the node-managed mobility family of protocols and approaches based on Mobile IPv6 signaling: Mobile IPv6 itself, NEMO Basic Support, HMIPv6, Global HAHA and MANEMO.

2.1

Node-managed mobility concept

Here follows a description of the common concept applying to all mobility protocols studied in the context of MobiSend. As outlined earlier, providing IPv6 mobility is a challenging issue because the protocol must keep in the time a synchronisation between the nodes position information (Locator) and the nodes identication information (Identier). Without entering all the details of the protocol in this section, MIPv6, NEMO-BS and HMIPv6 modify the routing of packets in a way that is transparent for the infrastructure. PMIPv6 does it in a way which is transparent to the mobile node (i.e. mobility is managed by the access network, not the mobile node itself). All protocols use a specic helper in the home network of the node (a router known as the Home Agent or HA) and also extensions of the IPv6 protocol. IPv6 mobility terminology is specied in [1]. IPv6 mobility protocols provide an IPv6 mobile node (abbreviated as MN which could either be a mobile host or mobile router) with the ability to use a xed address of its home network, no matter what its movements and current position are. It allows the IPv6 layer to mask the eects of mobility for upper layer protocols such as TCP or UDP, and for that reason to the applications that use them. For that purpose, the protocol separates the two elements in the following way. It denes the concept of Home Address (HoA) : this address of nodes home network (in expected deployments, its subnet in a corporate LAN) is used as an Identier for the node. It is associated to the node, no matter its current network of attachment. It also species the Care-of Address (CoA), which is the address the node has in the network it is currently visiting. It has no identication role at all and is only used as a Locator for the packet destinated to the HoA to be routed to the topological position of the node. This address is

internet

Correspondent Node network

CN
Home Network

HA
at

HoA

tun

nel
MN
at its
Foreign Network

CoA

Figure 1: IPv6 mobility concept

a valid global unicast address whose prex belongs to the visited access network. There is no direct means to distinguish a Home Address from a Care-of Address from another IPv6 global unicast address. The mobile node is associated with the, Home Agent (HA) located in the home network, whose functions are : to maintain a binding between the Care-of Address (CoA) of the node and its Home Address (HoA). to tunnel trac packets addressed to the Home Address to the Mobile Node at its current position, in a foreign network. To perform these tasks, the Home Agent emulates the presence of the Mobile Node on the subnet. Maintaining the binding between the addresses is performed by the reception and processing of specic messages (Binding Update) sent by the Mobile Node when its point of attachment changes. From the Mobile Node standpoint, trac destinated to its home address simply comes from a (possibly protected) tunnel with its home agent which is also used by the node when packet sent with its Home Address are emitted. The whole process is presented in Figure 1. The Mobile IPv6 family of protocols is transparent for the correspondent of the mobile node, no specictask being required from their side2 : for that reason, there is no simple distinguisher between a mobile node and another common node. Routing is not optimal, because packets sent/received from/by the mobile are required to transit through the Home Agent. As a result they could undergo latency through this inecient routing. Solutions to this problem are known as routing optimization and dier in the case of host mobility support and network mobility support.
2 in

a non-optimized mode

2.2 Overview of the IPv6 mobility support protocols

The description of the IPv6 mobility protocols has been kept short to avoid entering into the details of the frame content. Only the logical part of the protocols is discussed, providing a high level presentation sucient to discuss the security mechanisms of the protocol (intrinsic and IPsec related) and current research under progress.

2.2.1

Host mobility support (MIPv6)

Host mobility support allows a single IPv6 host (i.e. a mobile terminal or PDA) to change its point of attachment to the Internet topology. Mobile IPv6 (RFC 3775) [2] has been normalized at the IETF by the former mip6 working group. It is currently being revised by the mext working group. Figure 1 presents all the involved entities when the MN is operating Mobile IPv6. The Home Agent (HA), the Correspondent Node (CN) and the MN have addresses congured on dierent prexes.

2.2.2

Network mobility support (NEMO BS)

Network mobility support allows entire IPv6 networks (i.e. a mobile router and a number of connected devices such a sensors, servers, multimedia devices, etc.) to change their point of attachment to the Internet topology. Cases of moving networks include networks of sensors deployed in vehicles, access networks deployed in public transportation (trains, buses, aircrafts, etc.) and Personal Area Networks (PANs, small networks made of personal devices such as those found on remen or wheelchairs, etc.). In-vehicle networks are the preferred use cases. A mobile network is attached to the Internet topology through the Mobile Router (MR), which serves as a gateway between the moving network and the Internet. Nodes embedded in the mobile network behind the MR are referred to as Mobile Network Nodes (MNNs). The mobile router is moving around with its attached nodes and changing its point of attachment to the Internet topology. As a result, all its attached nodes change their position in the topology. NEMO Basic Support (RFC 3963) [3, 4, 5] has been normalized at the IETF by the former nemo working group. The work has been taken over by the mext6 working group. It is designed to maintain Internet connectivity between all the nodes in the moving network and the infrastructure. This is performed without interruption or failure of the data session under transmission, and transparently to the MNNs. The protocol only requires new functionalities at the MR. Initially, all nodes on board the mobile network (MNNs and the MR) have an address congured from the same prex, referred to as the Mobile Network Prex (MNP) and provided by MR. The MR obtains a new CoA on each of the new attachment point. MNNs, which are standard IPv6 nodes, retain their IP address irrespective of the Mobile Routers whereabouts, The Mobile Router registers the CoA with the HA for the entire MNP. As a result, a bidirectional tunnel is established between the MR and the HA. Since the IP address of the nodes behind the Mobile Router is not changed, any packet destined to the mobile network is thus routed rst to the HA where it is tunnelled, to the MRs CoA. The MR decapsulates the original packet and routes it to its nal destination.

This process enables Correspondent Nodes (CN), i.e. the MNNs peer communication node, to send trac to the permanent address of the MNN, and the Home Agent takes care of forwarding it by tunnelling the trac to the MRs Care-of Address. In the opposite direction, the trac from the MNN to the CN is reverse tunnelled from the MR to the HA, so the CN will see that the packets come from the MNNs permanent address. As we see, MNNs dont need to be upgraded with complex mobility management procedures to benet from the Internet connectivity provided by the mobile router. Network mobility support is thus very easy to deploy, at a minimum cost as the design of such user terminals (MNNs) is simplied Figure 1 presents all the involved entities in the generic IPv6 mobility concept. The Home Agent (HA), the Correspondent Node (CN) and the MN, acting as a mobile router (MR) have addresses congured on dierent prexes. Contrary to Mobile IPv6, NEMO Basic Support doesnt dene any solution to avoid routing via the Home Agent. This is a design choice of the former NEMO WG as security brings a number of concerns. It was thus decided to specify a simple solution and to leave routing optimization for later work. Since then, many solutions have been proposed to the IETF but so far the WG has not decided to include the specication of a solution for routing optimization as a WG item. The issues related to NEMO Route Optimization have been described by the IETF in RFC 4888 [6] and the solution space analyzed in RFC 4889 [7].

2.2.3

Hierarchical mobility support (HMIPv6)

Hierarchical Mobile IPv6 (HMIPv6) is a proposed enhancement to reduce the amount of signalling and improve the performance of MIPV6 handovers. It introduces an extension of MIPv6 and IPv6 Neighbor Discovery to allow local mobility handling This extension allows minimizing MIPv6 signalling overhead by introducing mobility regions and local HAs. The movement within the region induces Binding Update only once, to ` the Olocal HAO called Mobility Anchor Point (MAP). The MAP serves as a local entity to update the new location of the mobile node. The MAP can be located anywhere within a hierarchy of routers but it only makes sense if the MAP is located between the MN location and HA and CN locations. In this case, instead of a latency that is proportional to the minimum round-trip time between the MN and the HA or the CN, it is proportional to the round-trip time between the MN and the MAP. The MN has two kinds of Care-of Addresses: the Regional Care-of Address (RCoA) and the On-link Care-of Address (LCoA). MN obtains the RCoA from the MAP of the visited network, which remains unchanged as long as the MN is roaming within the given domain. The LCoA identies the current position of the terminal, and if it changes within the logical domain, it must update it only to the MAP (it sends a Binding Update). The Home Agent and Correspondent Nodes are not aware of this change; the visible Care-of Address (RCoA) remains the same for them while the MN keeps changing its point of attachment inside the visited domain. The MAP captures the messages sent to the MNOs RCoA, and forwards LCoA using local routing mechanism. All the CNs them to the MNOs and the HA know the Regional Care-of Address (RCoA) of the MN which is unique for the MN within the entire region. CNs and the HA exchange

data trac with the MN by using its RCoA as destination address. The MAP tunnels the trac to the actual location, the on-link CoA (LCoA) of the MN. As a consequence, the radio link is only used by one BU to each MAP for a MN, when it moves within the region and gets a new LCoA. Also, the amount of signalling messages leaving the domain is reduced significantly, and so is the resulting delay. However, the movement between regions induces more signalling overhead MIPv6, since the MN may discover available MAPs, select one and register to it, and then, update the HA and possibly the CNs if route optimization is used, with the new RCoA. In planning it is not the same if a network is implemented over a campus or over a busy highway. In the rst case, low speed movement is dominant, in which handover is rare, so signalling trac is lower. On a busy highway high speed movement causes more frequent handover events, thus the handling of increased signalling load must be solved.

2.2.4

Combination of NEMO and MANET: MANEMO

MANEMO is the integration of the Mobile Ad-Hoc Network (MANET) and the Network Mobility (NEMO) concepts. Originally MANEMO was built to solve route optimization in Nested-NEMO (referred to as the Pinball Routing), where several NEMO networks are being crossed when establishing an end-to-end connection. Those mobile networks are generally the same location, thus packet delivery within the nested structure can be optimized with a MANET routing protocol, allowing direct communications between dierent Mobile Routers. If connection breaks within the MANET, the Mobile Networks will revert back to the NEMO protocol. This MANEMO usage is known as NEMO-Centric MANEMO. Solving Nested NEMO routing problem is just a part of MANEMO. Combining MANET and NEMO can be used to solve various topics such as disaster recovery, vehicular network, Layer-3 sensors networks, Personal Area Network (gure 2). . .

Figure 2: Example of making Personal Area Network with MANEMO. The MANET backbone provides an access to the Internet.
There are two kinds of MANEMO schemes in the literature: NEMOCentric MANEMO (the one mainly used to solve Nested NEMO routing problem) and MANET-Centric MANEMO. MANET-Centric MANEMO

(see gure 3) concerns scenario where MANET is for organizing local communications inside the Mobile Network and where NEMO merely provides internet connectivity. NEMO usually provides Internet connectivity and global reachability making MANEMO accessible from the Internet.

Figure 3: Example of a MANET-Centric MANEMO. NEMO helps the MANET to keep a stable address topology within the MANEMO.
MANEMO is on its early stage of study. No MANEMO protocols have been proposed. Security considerations are foreseen to be the same as in NEMO and in MANET.

2.2.5

Global distribution of HAs: Global HAHA

Global Home Agent to Home Agent protocol [8] initially targeted solving the NEMO scenario where a Mobile Router inside an airplane moves too far away from its Home Agent, and exchanging trac with a Correspondent Node that is geographically close to it takes a too much longer path. Figure 4 illustrates the problem. To achieve this aim, Global HAHA removes the link-layer dependency in MIPv6 and NEMO, making the Home Link virtual. Neighbor Discovery messages and extensions (used in MIPv6 and NEMO) are removed and replaced by Layer-3 only messages (no more Layer-2 bindings in the messages). This supports Home Agent global distribution and reduces the distance between the Mobile Router and a Correspondent Node (topologically speaking) when going through the Home Agent.

Figure 4: The Mobile Router is roaming, the trac is forwarded back to another continent in order to reach the Home Agent even though the Correspondent Node is topologically close.
Practically speaking, the Mobile Router connects to the closest Home Agent being detected thanks to the Dynamic Home Agent Address Discovery procedure (despite its insecurity, as described in [9]). When this Home Agent is not the primary Home Agent (the rst one the MR connects to), the Home Agent proxies the request to the primary Home Agent. When a packet goes through the Home Agent, it will go out from the closest Home Agent to the Correspondent Node (topologically speaking). Routing is ensured between Home Agents by a BGP-like routing protocol. Hence, the longest path to a Correspondent Node is MR-HAmr-HAcn-CN where HAmr is the closest Home Agent to the Mobile Router and where HAcn is the closest Home Agent to the Correspondent Node, providing a much more optimized path. Since Global HA to HA protocol is Layer-3 only, no specic security considerations can be made about link-layer access.

2.3
2.3.1

Common new IPv6 headers and options

Type 2 Routing Header

This header is used by MIPv6, NEMO BS, HMIPv6 but not PMIPv6. Among the extensions dened in RFC 2460 [10]3 , Routing Header mechanism can be used by a node to list one or more intermediary routers through which the packet will ow in the path towards its destination. When used, the Next Header eld of previous header takes the value 43. As depicted on gure 5, a type eld leaves room for modication of extensions semantic. In a standard use (Type 0 Routing Header, also dened in RFC 2460 [10]), it provides the equivalent of Lose Source Routing Mechanism available under IPv4. Every router in the list uses the values of segleft and Hdr Ext Len elds to get the address of the next router the packet will be forwarded to. Then, it switches this address with the one in the destination eld of the received
3 Type 0 Routing Header has been deprecated for security reasons by [11], but the generic mechanism and the specic Type 2 routing header are still used by MIPv6, NEMO BS and HMIPv6.

10

32 bits

8 32 128

Next Header

Hdr Ext Len = N

Routing Type = 0

Segments Left

Reserved

Address[1]

8 x N bytes

128

Address[N/2]

Figure 5: Type 0 Routing Header Format

packet. After the value of Seg Left eld has been decremented, the packet is reemitted. The nal destination of the packet is the one that receives the packet with a null Seg Left values (the last address in the initially emitted packet). Mobile IPv6 denes a new specic type, Type 2, which is a restricted version of Type 0 Routing Header that limits the list of intermediary routers to a single entry. A specic type has been designed mainly for security reasons; it is only understood by nodes that implement Mobile IPv6. Its use is detailed in following subsection.

2.3.2

Destination Option Header - Home Address Option

This header is used by MIPv6, NEMO BS, HMIPv6 but not PMIPv6. This type of header is used to carry optional information that will be processed only by the destination node. For that reason, no router on the path will never consider that option4 . It is identied by a value of 60 in the Next Header eld of previous header.
32 bits

Next Header

Hdr Ext Len

Options

Figure 6: IPv6 Destination Option Header format

The Hdr Ext Len provides the length of that header in 8 bytes unit (rst 8 bytes are not included), Next Header eld providing the type of
is a generic rule for IPv6 extension, except for the Hop-By-Hop extension that is processed by every node on the path
4 this

11

next header and Options being the generic container carrying a variable number of options encoded as TLV5 . RFC 3775 denes a specic option, the Home-Address Option, to be carried by the Destination Option Header extension. The role of this option can be compared to the one of the Type 2 Routing Header : it warns the destination that the source of the packet is not the address in the source eld of the IPv6 header but the one in the option. The interest of that trick is that packets can be sent with a valid source address from the foreign network of the Mobile Node. With an invalid source address (the HoA, for instance), the packet could be dropped by egress ltering mechanism.

2.3.3

Remarks

Because the deepest intent of the Type 2 Routing Header and Home Address Option is to pass ingress/egress ltering mechanism, the security related concerns are of primary interest. They are discussed extensively in the Security section. A simple way to introduce the use of Type 2 Routing Header and HoA is as mechanism to create degenerated tunnels allowing respectively : a node to send trac to a peer to a nal destination address congured locally on the receiver but which is dierent from the one found in the IPv6 header of the emitted packets (which is compatible with current location of the receiver). a node to send trac to a peer from a source address congured locally (but unrelated/incompatible with its current location) but using a dierent source address in the source eld of the IPv6 header.

2.4

MIPv6 and Routing Optimization

The common concept applying to all mobility protocols has been outlined in 2.1, here follows a description of the specicities of Mobile IPv6 i.e. routing optimization and a security analysis in the context of MobiSend. In some cases, when the Correspondent Node of the Mobile Node is also MIPv6-aware6 , the Home Agent function can be delegated to the Correspondent Node. More precisely, the CN is made aware of the Careof Address associated to the Home Address (it maintains a binding cache). In a simple fashion, the binding cache is a parallel routing table that can be updated by the Mobile Node. When trac destinated to an address matches the value of a Home Address in the cache, the trac is tunneled to the Mobile Node at the associated Care-of Address. This mode is called Route Optimization, and allows direct connections with optimal routing and no delay. It is optional and can be refused by any side. At the moment, even if it is expected, the security of the usual and optimized modes are not equivalent.
5 Type 6 it

Length Value structure supports a limited subset of MIPv6 called Correspondent Node function

12

internet

Correspondent Node network

CN
ets xt p ack
Home Network

1. initia

l packe

HA
at

HoA

tun

nel

3.

2. Binding Update Foreign Network

MN
at its

CoA 1. Initial Packet 2. Binding Update (BU) : src = CoA, dst = CN, HAO, RH type 2 (HoA) 3a. Traffic to CN : src = CoA, dst = CN, HAO 3b. Traffic to CN : src = CN, dst = CoA, RH Type 2 (HoA)

Figure 7: Mobile IPv6 with route optimization 2.4.1 Non optimized mode

Detecting a new point of attachment : when a mobile node changes its point of attachment, it receives a Router Advertisement message that contains an IPv6 prex. This one diers from the one associated with its current CoA. When receiving this message, the node congures itself with a new CoA belonging to the advertised prex. Obviously, to avoid waiting for an unsolicited Router Advertisement, the mobile node solicits routers on the link as shown on gure 8. Association step After the conguration of a new CoA, the mobile node has to update the binding maintained on its home agent, that currently references the old CoA. To do that, it sends a (IPsec protected) Binding Update message to its Home Agent which updates its binding cache. The Home Agent acknowledges the reception of the BU with a Binding Acknowledgement message. This simple exchange leads to an update of the tunnel between the Home Agent and the Mobile Node. At that moment, the trac can ow again in both directions. It is interesting to note that during the period starting at the loss of connectivity for the Mobile Node and the reception of the Binding Update by its Home Agent, the trac : destinated to the Mobile Node and forwarded through the tunnel by the Home Agent is still owing to the old location of the node. is no more emitted by the Mobile Node because the route to the Home Agent does not exist anymore as a result of the connectivity loss. At both sides, i.e. on the Mobile Node and its peers, the result is temporarily the same, a temporary loss of connectivity, which obviously results for active sessions using connection-oriented protocols like TCP to some annoying timeouts (window scaling, exponential backo mechanism and slow restart of the connection).

13

Ne

MN 0. Movement Detection
Router S

Routeur d'accs
olicitation

CN

Router A

dvertisem

ent

HA 1. Association
Binding U pdate
ck.

Binding A

2. Data trafc

ICMPv6

Echo Re

quest

ICMPv6

Echo Re q

uest
ply

ICMPv6

ply Echo Re

ICMPv6

Echo Re

3. Return Routability

HoTI
HoTI

CoTI

HA
HoT
HoT

CoT

4. Association

Binding Update

Binding Ack.

5. Data trafc

ICMPv6 Echo Re

quest

ply ICMPv6 Echo Re

IPv6-IPv6 tunnel

Figure 8: Packet Exchanges in Mobile IPv6

14

Obviously, previous latency can be reduced in multiple ways. One will rst notice that the hypothesis here is that the only connection mean is lost and then recovered (like during a roaming in a Wi network). If multiple connection means are available, with one being preferred and used (for instance ethernet for speed/eciency/price reasons) and the others (wi, 3G, GPRS, Bluetooth) being active but unused, something can be done : because the connections are already up on the other connectivity means, a Binding Update can be sent as soon as the loss of connectivity is detected. This direction is actually studied in Mobile IPv6 Working groups along with others that oer the possibility to register multiple Care-Of Addresses to a Home Agent.

2.4.2

Optimized mode

The aim of the routing optimization is to allow a direct connection between the Mobile Node and its Correspondent Nodes that support Mobile-IPv6 (the Correspondent Node functionality). If the relation between the Mobile Node and the Home Agent is clear and, in the end, quite simple, the one between the MN and its CN is not that simple. One reason for the complexity is the hypothesis on the relationship between the MN and the CN : the assumption is that there is no initial trust relationship between them (they are not part of the same trust domain), so no shared secret or strong authentication means7 .

1. HoTI

MN
I

HA
1.

3. HoT

Ho

TI
3.

Ho

1. HoTI tunnel via le HA 2. CoTI mis directement au CN 3. HoT tunnel via le HA 4. CoT mis directement au MN

CN

Figure 9: Return Routability procedure

For that reason, the Mobile Node has to prove to its CN its possession of the addresses it says it is available at : its HoA and its CoA. This proof is provided if the MN is able to send and receive trac from these two addresses : this is the aim of the Return Routability Procedure8 .
7 One will argue that no security should be required between the MN and the CN : in fact, as soon as the CN has a binding cache, he must have some condence in the information he puts in it. You just dont want to accept any address translation information from anyone : that would lead to uncontrolled spoong possibilities 8 [12] describes the challenge and section 15 of [2] the details of the nal solution

15

4. C oT

2.

oT

tunnel

From a practical standpoint, the procedure is complicated to keep it stateless from the CN standpoint. It is based on the exchange of two cookies, Care-of Init Cookie and Home Init Cookie, emitted by the MN to the CN. The rst one is sent directly with the CoA of the MN, the second one in an indirect way with the HoA of the MN, using the tunnel through the HA. The reception by the CN of these two elements provides a proof that the MN is able to discuss with both its CoA and its HoA. These two cookies are respectively returned in the CoT and HoT messages emitted by the CN to the MN, respectively responding to the received CoTI and HoTI messages. They prove the MN in a relative way that the responses do come from someone that is able to emit trac with the address of the CN and to receive trac from the foreign network of the MN and from its home network. They prevent a node on the foreign network or on the path between the MN and the CN can forge the answers. Such an attacker must be able to access the trac emitted from the home network to the CN. Nonetheless, this use of cookies does not provide any solution against an attacker on the CNs network that would be able to access its trac and also send some as the CN. Thus, the security level of the communication is similar with the one of a common communication over the Internet between two simple clients that do not use Mobile IPv6. Furthermore, two types of Keygen Token (Care-of Keygen Token and Home Keygen Token) are emitted in response by the CN, respectively destinated to the HoA of the MN and to its CoA. The future use of these two tokens to authenticate the binding update messages to the CN allows to limit the origin of people able to receive trac at those addresses. The following gure summarizes the elements exchanged during the Return Routability Procedure :

1. HoTI

MN

tunnel
in in g cl ud C C in a g a C C re-o re ar ar f -o ee- K f I of of ey ni In N ge t C on n o it C ce To oki oo In ke e ki de n e x

HA
1.

3. HoT
3. Ho TI
in clu di ng

Ho

T
in Ho H o Ho me me m Ke In e yg it C No e e nc n T ook In it e ok ie Co In en de ok x ie

Ho

2.

1. HoTI tunneled via the HA 2. CoTI sent directly to the CN 3. HoT tunneled via the HA 4. CoT sent directly to the MN

CN

Figure 10: Exchanges during the Return Routability Procedure

16

4. C oT

in

cl

ud

C oT I

clu

di

ng

2.5

MIPv6 and Link Layer security issues

Note: In order to discuss the issues described in this section on IETF MEXT WG mailing list, an IETF draft has been written based on the content of this: [13]. It also contains practical feedback on the implementation of the attack on an existing implementation.

2.5.1

Scope and Hypothesis

In order to analyze the Link Layer security issues in Mobile IPv6, it is interesting to see the purposes of the link layer interactions that the two main entities of the protocol (the Mobile Node and the Home Agent) perform : the HA : acting as a ND proxy for registered MNs which are currently in a foreign network, the HA defends the HoA on the MNs Home Link when it is away, intercepts packets destined to the HoA and tunnels them to the associated MN at its CoA. Its operations as a ND Proxy for MNs HoA are basically subject to the same ND threats as the ones existing for common neighbors of the link. Security issues linked to SEND for a ND proxy are described in another deliverable [14]. In practice, additional hypothesis can be made about the Home Network; Being part of a controlled infrastructure, those threats can be reduced, mitigated or avoided. As discussed in next item dedicated to the MN, those hypothesis can usually not be made about the foreign networks where the MN operates. the MN : upon movement, the MN performs link layer interactions with the new foreign network it nds itself in. From a security standpoint, this network has to be considered as an hostile environment. The interactions of the MN on foreign networks can be summarized the following way : it sends RS messages in order to get some RA from the router(s) of the link. The RA gathered during the router discovery steps are used by the MN for conguring a CoA and most importantly to detect if the current link is the home link or a foreign link. For that reason, the MN in this potentially hostile environment is subject to ND protocol threats, already identied in another deliverable of the project. But because the Home Link detection mechanism is based on information gathered using NDP and may be the trigger for some additional security critical steps, it may be a vector for additional MIPv6 threats. The remaining of this subsection specically focuses on this last MIPv6-specic link layer security issue associated with home link detection. For the reasons provided below, one additional hypothesis we make is that tunneled trac (data and some specic signaling messages) is protected using IPsec, even if not mandated by the reference documents: The Home Agent and the Mobile Node belong to a common trust domain, and are already expected to support IPsec and share common credentials for protecting signaling with IPsec in transport mode. In

17

that context, supporting tunnel mode is expected to be inexpensive from a deployment standpoint9 . As specied in [15] and [16], Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the protection of packets belonging to the return routability procedure. Protection of IPsec payload trac is documented for both static and dynamic keying with IKEv1 [15] and IKEv2 [16]. Public implementations are known to support it. Except for specic devices which will operate on some trusted operator or internal networks, Mobile Nodes are expected to nd themselves in untrusted/hostile foreign networks. In that context, corporate deployments will require the use of IPsec for tunneled data. Public deployments will also probably take that path. In the end, as discussed later in this section, IPsec tunneling and common tunneling of data are basically handled in the same way. The remaining of this section discusses the possible issues associated with current Home Link Detection mechanism and Returning Home procedure as specied in the main MIPv6 reference documents ([2], [15], [16] and [17]). As described previously, this is done under the hypothesis that IPsec is used to protect the trac exchanged between the Mobile Node and its Home Agent.

2.5.2 Link detection mechanism and Returning Home events

To keep current section a reasonable size, the detailed analysis of reference documents including normative excerpts of those specications is maintained in appendix A, at the end of the document. If you are interested by more details on the topic, you should denitely read that appendix. Here, we provide a review of : The Home Link Detection mechanism performed by the MN The events associated with the Returning Home procedure on both the MN and the HA. It is based on detailed analysis available in the appendix. The MIPv6 specication provides a simple (one would say primitive) Home Link Detection mechanism for the MN : simply put, when a Prex Information Option found in an RA message received by the MN includes its Home Subnet Prex, the MN considers it is on its Home Link. The reaction of the MN to this event is dened, but in a loose fashion : It is expected to send a deregistration BU : the content of the BU is provided by [2] (the set of ags in Mobility Header MH header) but the specic format of the packet is just suggested (no HAO and no AltCoA option). In practice, the document does not prevent an implementation to include an AltCoA option or a HAO in Destination Option Header.
9 One

would argue about the performance cost of having IPsec protected data trac

18

 [2] precisely describes the steps that should then occur at ND level, in order for the MN to be able to use its HoA, which was previously defended by the HA. We do not cover these steps here. [2] expects the tunnel with the HA to be torn down. [15] also follows that direction by expecting the IPsec tunnel with the HA to be torn down. In practice, this is what existing implementations do. The specic order in which things are expected to happen is unclear, and more or less left as an implementation decision despite its importance : for obvious eciency reasons, the MN usually does not wait for the BA to come back from the HA in order to tear its IPsec tunnel down; just like it does not wait for a BA to come back when performing a handover to another foreign network. From a HA perspective, with respect to the ND processing, things are well dened. For the sequence of events and specic format of the BU (limitation on the content) are loosely dened too.

2.5.3

Summary and possible threats

Setting up a full deregistration attack There is nothing in all the MIPv6 reference documents regarding the security of the Home Link Detection mechanism and Returning Home procedure. Those are basically not considered as possible threat vectors. Here, we discuss the possible threats associated with the loose expectations of reference documents and the reliance on untrusted information to trigger changes in tunneling and IPsec security policies. The only document which considers the topic is [18], which has an interesting Section 5 entitled Exploiting Neighbor Discovery in a MIPv6 Environment. That section being quite short, it is provided10 here for completeness and commented below as an initial introduction to the possible threats: This threat oers a malicious node two edges. It requires rst that the attacker be attached to the same foreign link as the MN, and the discovery of the MNs home agent IP address as well as the MNs IP home address (which may not pose a serious problem). After learning these two information, the attacker advertises the MNs home prex on the link thus leading the MN to believe that it has returned to its home network. Such information will prompt the MN to send a BU message to its HA to request de-registration. However, such early deregistration may not be possible as the foreign network may have activated ingress ltering. But the main goal for the attacker is to get a valid copy of the MNs BU message and such goal is achieved. If the malicious node concludes that the MN is still receiving data packets tunneled by the HA to its current CoA, then it will get involved in the MN de-registeration procedure by forwarding the BU message to the MNs HA on another interface where ingress ltering is not activated (i.e. under the assumption that the attacker is multihomed). Upon receiving the BU message, the HA will de-register the MN and stops tunneling data packets to the MNs CoA. In addition, the
10 text

is extracted from current version, i.e. version 2

19

HA sends back a BA message which will never reach the MN. From that moment, the data trac sent by the CN(s) stops at the MNs home network. However, the lack of ACK messages sent by the MN will prompt the CN(s) at some point to halt sending data trac and eventually tear down the session(s). However, the situation gets worse if the malicious node decides to push further in his attack by sending fake ACK messages to the CN(s), i.e. using the MNs home address. In such situation, the CN(s) will keep sending data trac to the MNs HA (where they eventually get discarded) and thus, may cause severe disruption within the home access network, possibly leading to a network ooding attack in some specic topologies. Note that as they may be more than one MN attached to the same foreign link and using the same home prex, such attack may lead to collective de-registration. As discussed in the draft and predicted by the summary provided previously, it is expected to be quite easy for an attacker on a foreign link to have a MN think that it is at home and have it send a de-registration BU. For that purpose, as noted in the draft, the attacker only needs to acquire the Home Agent address, its Home Prex and have the ability to forge packets. The addresses are public information available from the trac of the MN. The draft introduces the possibility that ingress ltering implemented in the foreign network could lead to the BU being dropped before hitting the HA. In fact, for a common HAO-free deregistration BU packet sent by a MN to its HA while believing it is at home, the source address of the packet is the HoA. With that hypothesis, the packet is both topologically invalid from the foreign networks perspective11 , but it is also invalid from the destination sites perspective12 . But those expectations do not provide any security guarantees. The solution proposed in the draft for the attacker is to relay its packets via another connection mean which does not undergo ingress ltering. It is interesting to note that it will still not work if the Home Network implements ingress ltering too, and the attacker (and the MN) will never get a Binding Ack in response. The only way for an attacker would be to have a simultaneous access to the MNs foreign network and to its home network. Lets be wild and consider for a moment that our implementations do not have restrictions13 on the expected format of the BU. This could be the case because of code reuse. In that context, there are some patches the attacker may explore. For instance, if the attacker manages to get the ESP protected BU sent by the MN in its common format : IPv6 header (source = HoA, destination = home agent) ESP header in transport mode Mobility header Binding Update
11 it should be dropped if some ltering mechanism has been put in place by the ISP of the foreign site or even the administrator of the site 12 it should denitely be dropped at the MNs network site boundaries 13 both from the MN build perspective and the HA processing perspective

20

It could simply modify the packet in the following way to add a destination option header with an HAO to make it look that way: IPv6 header (source = Attacker_Address, destination = home agent) Destination Options header Home Address option (HoA) ESP header in transport mode Mobility header Binding Update The packet will still be perfectly valid at all levels: Mobility Header checksum is computed based on MH content (which has not been modied) and using the usual L4 pseudo header which is also be the after the changes: the nal addresses are still the HoA and the Home Agent address, the next header eld is still MH. The last element of the pseudo header, the length of the upper layer is not bound to the modied payload length eld of the IPv6 header but to the unchanged length eld of the MH header. The part protected by ESP has not been modied during the addition so it should still be gracefully processed by the HA IPsec stack. In the end, the mangled packet now has a more interesting layout: it has a topologically valid source address which will allow it to be routed to the HA. For previous reasons, it should be processed successfully by the IPsec stack of the HA and delivered to its MIPv6 module. Then, whether it will be considered valid by the HA is a matter of implementation and interpretation of the reference documents. Among the questions/points, we can list the following : There is no AltCoA in the packet: in our example, there is none. But, here again, reference documents are not clear on the topic. AltCoA is usually expected in BU to benet from the IPsec protection. But there are specic non normative notes in [2] and [15] for deregistration BU sent from Home: usual ones do not include the AltCoA option. In the end, the Mobile IPv6 implementation for Linux always includes the AltCoA option, even for deregistration BU sent when back home. Under the assumption that the HA processes the BU, can we expect it to send the BA in the same fashion, using a RH2? This is clearly implementation dependent. From a specication point of view, the BU is always sent to the source address of initial packet. In our example, Attacker_Address. Will the attacker be able to mangle received BA and have it be processed by the MN? Yes, for the same reasons as the ones given to explain why the mangled BU is still valid. As a temporary summary, the specic implementation of the MIPv6 module running on the MN and the HA, the kind of ltering implemented in the foreign and home networks will impact the diculty and requirements of setting up a full BU/BA exchange leading to a complete deregistration on both sides. Partial deregistration

21

It is interesting to note that the nal goal of the attacker is not to mount a full deregistration attack, but to have the MN drop its IPsec tunnel protection. In that context, a full attack would obviously do the job but some less restrictive solutions may exist. For instance, the reference documents leave quite some latitude with respect to the order of events. For obvious performance reasons, it is common that the MIPv6 modules does not wait for the BA from its HA to start using its new address. In the context of the deregistration when coming back home, the MN may drop its IPsec tunnel protection early, just after sending its BU and before receiving the BA. This is exactly what Mobile IPv6 for Linux implementation does. Conclusion As a conclusion, the Home Link Detection mechanism relies on untrusted and spoofable ND information. It is used as a trigger for a significant security event when IPsec is used for protecting data between the MN and its HA: the removal of this IPsec tunnel protection on a foreign network. Moreover, various parts of the reference documents leave quite some room for the build and processing of packets and the order of events associated with deregistration and Home Return. It may lead to interoperability issues but it may also simplify the work of an attacker which intends to exploit previous aw. From our standpoint, when IPsec is used to protect data trac, even if an attacker manages to access the Home Subnet of a MN, this should not provide it the ability to have one such MN drop its IPsec protection on a foreign network. At the moment, current MIPv6 reference documents allow that to happen.

2.5.4

Current solutions and possible workarounds

In this subsection, we discuss some possible leads for solving the issue presented in this section. Rely on SEND-protected RA for Home Link Detection The rst idea that comes to mind is to try and work on the root of the issues, the Home Link Detection movement. By removing an attacker the ability to spoof RA on a foreign network with crafted ones including PIO with Home Subnet Prex, the issue could possibly be prevented. For that purpose, from a theoretical standpoint, SEND could directly be used, simply by creating a Secure Home Link Detection mechanism in which it would be required that RA advertising the Home Subnet Prex be signed. That way, an attacker on a foreign link would not be able to trigger a deregistration and the IPsec tunnel protection to be dropped. It should be noted that this possible solution comes with the following drawbacks : It requires SEND to be implemented on the Home Network. It requires SEND to be supported by the MIPv6 implementation. It does not protect the MNs on a foreign link against an attacker that has simultaneous access to both the MNs Home Subnet and the MNs foreign subnet. Never drop IPsec tunnel protection

22

MIPv6 specication does not mandate the removal of the tunneling between the MN and the HA. [15] and [16], even if they expect the IPsec tunnel to be torn down when back home do not mandate it either. It is possible to solve the issue by having MN warning their HA that they are not willing to drop their IPsec tunnel when back home. This simple solution14 would provide an ecient workaround to the issue. One would argue that this solution could have negative drawbacks on performance. No home network The last obvious and most simple solution to the issue is basically another variant of previous proposal (Never drop IPsec tunnel protection), but this time by removing the ability for the MN to come back home.

2.6
2.6.1

MIPv6 and DHAAD Mechanism

Presentation

This section describes another security issue with MIPv6. This is concerning the Dynamic Home Agent Address Discovery (DHAAD) mechanism. This mechanism allows a Mobile Node, when it is aware of the Home Network Prex (HNP), to discover a HA with which it could register to. Each HA on a specic HNP adds information about the fact it acts as HA in a modied RA it sends regularly. The format of a modied RA is as shown in the gure 11.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-

Figure 11: Modied Router Advertisement header

Where, the new eld is specied as follows: The Flag H indicates that the router is also a Mobile IPv6 Home Agent. The format of the Prex Information Option has been also modied as shown in the gure 12.
14 indicating that willingness to keep IPsec tunnel protection up and running on the home subnet is just a matter of a single ag in a BU

23

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 | Prefix Length |L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Prex Information option

Where, the new eld is specied as follows: The Flag R indicates that the routers IP address is contained in the Prefix eld, has the same scope and conforms to the same lifetime value as the advertised prex. At last, two new options have been specied: the Advertisement Interval option and the Home Agent Information option. The Advertisement Interval option is used by the router to advertise the interval between two unsolicited multicast RA messages sent by it. This option helps a Mobile Node for its movement detection algorithm. The format of a Advertisement option is as shown in the gure 13.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertisement Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13: Advertisement Interval option

Where, the main elds are specied as follows: The Type is equal to 7; Advertisement Interval contains the maximum time, in milliseconds, between successive unsolicited RA messages sent by the router. The Home Agent Information option is used by a Home Agent to advertise information regarding its Home Agent functionality. The format of a Home Agent Information option is as shown in the gure 14.

24

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Preference | Home Agent Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: Home Agent Information option

Where, the main elds are specied as follows: The Type is equal to 8; Home Agent Preference contains a value that will be used by a Mobile Node to decide which HA to choose: higher is the value, better to choose this HA is preferable; Home Agent Lifetime contains the lifetime regarding the Home Agent functionality. The default value is the same as the Router Lifetime eld in the RA Header and must not be equal to zero. On the other hand, a new data structure has been specied: the Home Agents List. This data structure allows a HA to store information about each of all the other Home Agents on a same link and each entry contains: The Link-Local Address of a HA on the link; One or more global IP addresses for this HA; The remaining Lifetime of this entry which is either the Home Agent Lifetime value in the Home Agent Information option or the Router Lifetime value in the RA Header; The Preference for this HA which is either the Home Agent Preference value in the the Home Agent Information option or zero. To update this data structure, the HA has only to listen the modied RA messages on the link. Finally, two new ICMP messages have been specied: the HAAD Request message and the HAAD Reply message. To know which Home Agents are on the HNP link, a MN sends a HAAD Request to the Mobile IPv6 Home-Agents anycast address [19] linked to this HNP. The HA receiving the DHAAD Request message replies with DHAAD Reply message containing a list of Home Agents addresses on the HNP link, taken from its Home Agents List data structure, ordered by the Preference value.

2.6.2 tion

DHAAD Mechanism: the attack and SEND limita-

The goal of the attack is to poison the Home Agents List data structure. When SEND is not deployed on the Home link, any malicious node can send modied RA messages with fake information (e.g. the highest Preference) to poison the Home Agents List data structure of all the Home Agents located on this link. When SEND is deployed on the Home link, as the information updating the Home Agents List data structure are provided with the RA messages itself secured with SEND, any malicious node must be also a legitimate, but compromised, router to be able to poison the Home Agents List data structure of all the Home Agents located on this link. Indeed, information regarding HA functionality are not covered by SEND which

25

has only be specied to secure the Neighbor Discovery protocol but not potential mechanisms based on it. Such a working example of this attack may be found in the section 2.7.1. This attack has been advertised in the document [9] and should be taken into account for the document [17].

2.7

NEMO and Link Layer security issues

The common concept applying to all mobility protocols has been outlined in 2.1. The issues identied for Mobile IPv6 in section 2.5 also apply to NEMO Basic Support.

2.7.1 NEMO and DHAAD Mechanism: the attack and SEND limitation
The attack described in section 2.6.2 is well adapted in a NEMO context. Indeed, when the malicious node is a Mobile Router, the NEMO Base standard [3] allows it to be a legitimate router for the Home Link and so, when SEND is deployed on the Home link, to have the right security material to send RA messages protected with SEND on this Home Link. The consequence is that this malicious Mobile Router would be able to poison the Home Agents List data structure of all the Home Agents located on the Home link because the security provided by SEND doesnt cover the HA information in the RA messages. This attack has been advertised in the document [9] and should be taken into account for the document [17].

3
3.1

Network-managed mobility: NetLMM

Network-managed mobility concept

Network-Based Localized Mobility Management 15 (NetLMM) is an active Working Group of the IETF which aims to provide a solution to the Local Mobility issue. NetLMM is described in three dierent RFCs documents detailing the problem statement [20], the goals [21] and the security threats [22]. Next paragraphs will describe general guidelines required for the future NetLMM protocol (highly likely to be Proxy MIP). A local mobility occurs when a Mobile Node moves between two Access Points connected to two dierent Access Routers which belong to the same access network. Hence, NetLMM is particularly useful for scenarios such as a campus network or other scenario where the network belongs to the same authority.
15 http://www.ietf.org/html.charters/netlmm-charter.html

26

Figure 15: Dierences between Intra-Link mobility, Local Mobility and Global Mobility. Adapted from document RFC 4830[20].
Figure 15 explains the dierence between Intra-Link Mobility, Local Mobility and Global Mobility. The need of a Local Mobility can be explained by some lacks in other mobility models: Intra-Mobility is ensured with the help of proprietary Layer 2 protocols oered by WLAN switches that connect Access Points physically and enable them to provide Layer 2 handover. Even if these protocols are not generally interoperable among vendors, they remain popular among End Users as they do not need to modify the Mobile Nodes existing network stack. The lack of interoperability and the always increasing number of wireless protocols lead to the need of a Layer 2 agnostic protocol. Global Mobility provided by protocols such as Mobile IP [2], HIP [23] or MOBIKE [24] can be used in the Local Mobility context but they are not particularly adapted to this environment. They put constraints on the Mobile Node, modifying its network stack, they are not ecient in terms of update/handover latency and involve a lot of signaling overhead. They also raise some security concerns. MIP, for example, also brings some tracing issues : the Care Of

27

address (which is the locator of the node) can help detecting a Mobile Nodes movements. Hence there is a need for dening a Layer 2 agnostic protocol that uses low signaling trac and requires no modication at the End Users side. To avoid Layer 2 protocol dependency, NetLMM uses Layer 3 linkagnostic protocols.

Figure 16: A Mobile Node is moving between two Mobile Access Gateways. MNs trac is tunneled back to its new location.
As shown in gure 16, the core architecture of NetLMM is composed by a Mobility Access Gateway (MAG), a Local Mobility Anchor (LMA), and a Mobile Node (MN). Contrary to MIP, focus has been placed on low constraints on the MN side, and all the complexity on the LMA and the MAG. The LMA is usually connected to the Internet. Multiple MAGs are generally connected to the LMA, forming a star topology. The MAG nally provides forwarding services to the MN. When a Mobile Node moves, it attaches to a new MAG while keeping the same address inside LMAs boundaries. Usage of xed addresses helps solving the privacy issues as no tracing of MN can be done to determine its movements within a NetLMM domain. As part of the eort, NetLMM WG has standardized the Proxy Mobile IPv6 (PMIPv6) protocol [25], which is described in the next section. Note that PMIPv6 has been selected as the only one ocial NetLMM protocol [26].

28

3.2

PMIPv6: a NetLMM implementation

The Proxy Mobile IPv6 (PMIPv6) protocol, as the name suggests, extends the MIP protocol described in section 2.4. It adds to the Mobile IPv6 protocol [2] two messages derived from the Binding Update and the Binding Acknowledgement: the Proxy Binding Update message and the Proxy Binding Acknowledgement. PMIPv6 uses a Per-MN-Prex model. This means that each MN will be allocated one or more dedicated Home Network Prex. Only one address is reserved and is not available to the Mobile Node in each subnet prex : the Subnet-Router anycast address (as dened in RFC 4291 [27]), used by the MAG announcing the corresponding prex to the MN. The remaining addresses available in each Home Network Prex can then be used freely by MN to congure its addresses (one or more addresses by prex(es)) : statefully, with DHCPv6 [28], statelessly, with the Neighbor Discovery Protocol [29] or manually by an administrator. PMIPv6 supports Multihomed MN: this means that a MN can connect to the same PMIPv6 domain through more than one interfaces and simultaneously uses these interfaces. Each interface will be given a dierent Home Network Prex (as they are managed as dierent mobility sessions by the LMA). Each mobility session being registered between a LMA and a MAG generates a point-to-point link between them. This is the link in which trac addressed to the MN will go through. So far, PMIPv6 supports IPv6, and will support IPv4. Works for IPv4 support have been initiated in the IPv4-PMIP draft[30] but are not detailed in this document. NetLMM terminology (Mobile Access Gateway, Local Mobility Anchor, . . . ) applies to the PMIPv6 protocol with the same meaning.

3.2.1 Interactions between the Mobile Node and the Mobile Access Gateway
PMIPv6 [25] provides a network-based IP mobility management support to a MN and does not aect MN stack. MN has no need to support Mobile IPv6 signaling [2] and does only support IPv6 Neighbor Discovery messages as dened in documents RFC 4861 [31] and RFC 4862 [29]. However, taking into account certain mobility hints that MN is connected, disconnected, or will soon lose its connection,. . . can help decreasing handovers delay. One of the key functions of the MAG element is to emulate the MNs Home Network on the access link. It must ensure the MN does not detect any change with respect to its Layer-3 attachment even after it changes its point of attachment in the PMIPv6 domain. Moreover MAG acts as the MNs default router. Hence, when the MN moves from a MAG to another, it receives Router Advertisement messages. If those messages are sent by MAGs using a dierent link-local address and a dierent link-layer address, the MN detects a new default router each time it attaches to a new MAG, as shown in gure 17. This implies that, in PMIPv6, link-local address and (optionally) link-layer address of the MAGs are xed within the same PMIPv6 domain for the same MN. The link-layer address of a new MAG is discovered by the MN in the Router Advertisement messages. The same problem with dynamic addresses can also apply upon MNs attachment to a new link. The event related to the interface state change triggers the MN to perform some Duplicate Address Detection (DAD)

29

Figure 17: Signaling in a MN hando over a PMIPv6 architecture

operation for the link-local and global address(es). If the MN activates the mechanism Detecting Network Attachment in IPv6 (DNAv6), as specied in Work in Progress draft [32], it may not detect the link change due to DNAv6 optimizations and may not trigger the DAD procedure for its existing addresses. This might lead to link-local address collisions on the MAG-MN link after the MNs hando to a new link, but the following requirements apply in PMIPv6: MAGs link-local address needs to be generated by the LMA so the MAGs link-local addresses remain the same as the MN moves. MN is identied by its Mobile Node Identier (which is unique across the same domain). This identier is required in order for the MAG to associate a MN with its point-to-point link. The Mobile Node-Identier is carried in Proxy Binding Update/Proxy Binding Acknowledgement messages (see details in the next section) by the

30

MN-Identier option (as dened in RFC 4283 [33]). Thus there is no need for the MAG to refer to the Link-local Address of the MN when communicating with the LMA. Fixed addresses raise an important issue : a MAG cannot use the Secure Neighbor Discovery [34] (SEND) protocol on a MAG address. Indeed, a xed address implies the same public key pairs on each node. From a security point of view, sharing of a private key across multiple MAGs is not desirable. Ongoing works in the IETF may provide a solution to this problem in the future and will be discussed in the next Current solutions section. A MN, upon receiving Router Advertisement messages on the access link, attempts to congure its interface using either stateful or stateless address conguration modes, as required by the MAG in Router Advertisement messages. At the end of a successful address conguration procedure, the MN can obtain one or more addresses from its Home Network Prex(es). Depending on the PMIPv6 domain administrator, a routing optimisation can be used to save a round-trip between MN and LMA. When two nodes are attached to the same MAG, they can communicate directly without the trac being tunneled through the LMA.

3.2.2 Interactions between the Mobile Access Gateway and the Local Mobility Anchor
The functionalities provided by the LMA are reuse of the Home Agent functionality and signaling provided by Mobile IPv6 specication [2]. The LMA is responsible for maintaining the MNs reachability state and is the topological anchor point for the MNs Home Network Prex(es). In order to receive packets on behalf of the MN, the LMA needs to act as the last hop router for the MNs Home Network Prex(es). Between the MAG and the LMA, two dierent message types are used: the Proxy Binding Update messages and the Proxy Binding Acknowledgement messages. Proxy Binding Update messages are sent by the MAG to the LMAs and are usually answered by the LMAs with a Proxy Binding Acknowledgement message. Proxy Binding Update (PBU) messages and Proxy Binding Acknowledgement (PBA) messages are respectively Binding Update and Binding Acknowledgement messages with a new P ag (set to 1). PBU and PBA messages also come with support for new options. For example an Access Technology Type option, specifying the type of access technology the MN is using, must be present in the PBU messages. Another option, the Home Network Prex Option is used to exchange information about MNs prex when registering or updating a mobility session. This option can be found several times in the same message to signal that the MN possesses more than one Home Network Prex (implying that a MN generates at least one address for each prex(es)). One or more Home Network Prex can be sent in the PBU to LMA that needs to check the prex(es) (or a larger scoped prex) are owned by the LMA before assigning them to the MN (in case of a handover). The last worth mentioning option is the Timestamp option. This Timestamp option initially can be carried into a PBU message. This option, when available, replaces the Sequence Number eld (used in Mobile IPv6 [2]) in PBU and PBA messages and provides a mechanism to match the PBU/PBA messages by comparing the received Timestamp with the

31

last received one. When a LMA receives PBU messages with this option, it answers with this option in its PBA messages. The Timestamp usage requires clock synchronization between LMAs and MAGs with available mechanisms such as Network Time Protocol [35] (NTP) or Simple NTP [36]. Sequence Number usage was not selected as the default synchronization mechanism in PMIPv6 as it raises the issue of transferring context (i.e. sequence number value) between MAGs when the MN is moving from one MAG to another. Moreover, this context transfer is not explicitly raised in PMIPv6 specication. To distinguish possible actions that MN can perform, the PBU message contains a eld named Hando Indicator giving hints about handover situation. This eld can express: attachment over a new interface: there is a need for a new independent mobility session because, for example, MN wants to connect another of its interfaces to a PMIPv6 domain where a mobility session is already active and registered into the LMA. This should not be considered as a hando between interfaces. hando between two dierent interfaces of the MN. hando between MAGs of the same interface. hando state has not changed (Re-registration) since last PBU message: basically it prevents a Binding Cache Entry from being removed by the LMA due to inactivity of the session. hando state is unknown: the MAG cannot determine if the MNs attachment is due to an existing mobility session or a new one. It can also mean that the MN has moved away from MAGs access link. With the help of the Hando Indicator, the PBU message can: announce that a MAG requests a Home Network Prex to the LMA on behalf of a MN (the Home Network Prex is null). update the status of a MN on the LMA when an event occurs, for example, if the MN has performed a hando toward a new MAG. update the status of a MN on the LMA when no event happens, only to notify LMA the mobility session is still active through the same MAG and it still needs its trac to be forwarded. allow the MAG de-registering a MN to a LMA (when the message lifetime value decreases to 0). Upon acceptation of a correct PBU (no wrong Home Network Prex, good credential,. . . ), if there is no bi-directional tunnel between the MAG and LMA, the LMA must create a new tunnel. Tunnels end-points are Proxy-Care of Address (the egress address of the MAG) and LMAs address. The LMA handles the Proxy Care-of Address as the Care-of Address of the MN to be registered. A PBA message in response to a PBU message, can express: a new Home Network Prex(es) allocated by the LMA to the MN. an error or/and the reason why the Home Network-prex was not oered to the MN. everything is OK (in response to a PBU message indicating an update).

32

When the MAG detects (by various means) that a MN has moved away from its access link or has been turned o, it sends the PBU to deregister the MN from the LMA. After a certain delay, if no PBU message for this MN has been received by the LMA (sent by the same MAG or by a new one where the node is newly connected), the LMA destroys the mobility session considering that the MN is no longer connected to the network. The bi-directional tunnel between the MAG and the LMA can then be closed (if the tunnel is dynamically activated). This behaviour permits to detect MNs that turn o or move. Note that PMIPv6 can work with a Global Mobility Management protocol. Draft [37] describes usage of PMIPv6 working tightly with MIPv6, where a common Home Agent would serve as the mobility agent for all types of IPv6 nodes (MIPv6 ready and IPv6 compliant only nodes).

3.3

Link Layer security issues in PMIPv6

NetLMM security threats have been analyzed and categorized in document RFC 4832 [22] named Security Threats to Network-Based Localized Mobility Management. The PMIPv6 protocol has been developed in regards to these considerations. The companion document named Interface between a PMIPv6 MAG and a MN [38] also provides some interesting information about security issues in the interaction between the MN and the MAG. Some drafts [39], [40], enhance the PMIPv6 protocol and provide a faster handover, but the security analysis below does not cover these drafts.

3.3.1

Link between the LMA and the MAG

The MAG and the LMA implement IPsec [41] for protecting the PMIPv6 signaling messages. Integrity protection of ESP [42] is used for securing PBU and PBA, thus eliminating the threat of impersonation on the MAG-LMA link. Using IPsec also allows the LMA to only accept messages from authorized MAGs, ensuring an access control and a mutual authentication. MNs tunneled trac can also be protected by ESP for integrity and condentiality. If this security is not used, MNs tunneled trac can be altered on the MAG-LMA link. Compromised LMAs and MAGs are a big risk. A compromised LMA or MAG can alter, delay or even drop trac toward a MN, thus acting like a Man-In-The-Middle. A compromised LMA can also redirect a lot of trac to a single MAG, achieving a Denial of Service attack. A resource exhaustion attack can also be launched by a compromised MAG toward the LMA by creating a lot of routes to non-existing MN. But this is mitigated because the specication add that, in order to counter a compromised MAG attack, the LMA, on receiving a PBU message, may verify MNs attachment point. However, it is not specied how it can be achieved in practice. It should be noted that the Timestamp option in PBU/PBA message exchange does not aim to provide a basic protection from replay attacks, since a packet can be replayed in a default 300 ms time frame. It is only useful to match packet exchanges. Anti-replay protection is ensured by ESP integrity protection.

33

3.3.2

Link between the MN and the MAG

PMIPv6 specication goes with the strong assumption of having an established trust between the MN and the MAG before any protocol operations. A secure binding between the MNs identity and its link-layer address is provided by authentication mechanisms on the access link as for example EAP [43]. Thus, link is supposed to be secured and no address spoong is available. The MAG will be able to identify the MN on its access link. When a LMA receives a PBU message from a MAG, it tries to associate the information with an active mobility session. To do this, analysis is based upon some criteria: the Mobile-Node Identier and the Home Network Prex(es) allocated to the MN. If a MN can successfully make a MAG into thinking it owns Mobile-Node Identier and Home Network Prex(es) of another MN, it can successfully gain control of MNs trac by asking the MAG to update the cache of the LMA. The Mobile-Node Identier can be acquired in dierent ways. Generally it is obtained by the MAG as part of MNs authentication to the link. For example, it can be communicated with the RADIUS [44] attribute named ChargeableUser-Identier, a SEND public key, a ppp-negotiated interface identier or even IEEE 48bit MAC address. In the latter case, it is foreseen that the MAC address can be spoofed, so it is generally not a wise choice to use it and it should be avoided. Depending on the access link technology, an attacker can launch a Man-In-The-Middle attack on the MN/MAG link. If the Mobile-Node Identier can be spoofed, the attacker can identify itself as the victims MN to the MAG. The attacker then can act as the MAG. This can be easily achieved on shared-media links.

3.4

Current solutions

Two drafts - Secure Proxy ND Support for SEND [45] and Authorization Certicates for Routers and Proxies [46] - are contributions of the Cga & Send maIntenance (CSI) working group. Both of them complete each other and together provide a solution to MN/MAG link security. The Secure Proxy ND Support for SEND proposes a solution for the MAGs to keep a xed address when the node moves and still permits for the dierent MAGs to possess dierent public/private key pairs. Each MAG possesses a public/private key pair and a certicate (linked to the public key) that enables itself to act as a router and as a Neighbor Discovery proxy. The router can then add to Neighbor Discovery messages a Proxy Signature option that is veried in the same way as the RSA signature option, except that it is linked to the MAG. Hence the MAG address is not directly linked to the key pair and still is veriable by the MN. These addresses are referred to as non Cryptographically Generated Addresses (nCGA). Note that the MN has to use a full-edged CGA in order to be recognized (and then authorized) by the MAG. This approach has the same limitations than SEND. That is, it is not specied how the certicate is provided to the MAG and how trust anchors certicate is dened inside MN. This solution alone only ensures that a MN can trust a MAG but it cant help providing a unique Mobile-Node Identier when there is no authentication protocol on the MNs link. This previous solution is extended by the draft document Interface between a PMIPv6 MAG and a MN [38]. This document proposes a 4 Neighbor Discovery messages exchanges that permit the MN and the MAG to trust each other. The

34

message exchange is explained in gure 18. The rst and the last steps are the messages usually exchanged between the MN and the MAG when the MN is performing a handover. The Neighbor Solicitation (step 2) and Neighbor Advertisement (step 3) are only useful in order to prove to the MAG that the MN is authentic. Between the third and the last steps, the MAG being sure of MNs identity can safely use MNs SEND public key as the Mobile-Node Identier. After retrieving the MNs prex(es) from the LMA, the MAG can then send the Router Advertisement for these prex(es) to the MN.

Figure 18: Signaling between a MN and a MAG when no authentication services are available on the link.

3.5

Remaining problems

So far, there is no denitive normalized solution for the Proxy SEND solution. However proposed PMIP protocol provides a good security solution when a correct link-access protocol is available. SEND based protection will cover (when being normalized) the case where no link-access authentication is available.

Synthesis

In this document, several security issues related to the interactions over the network link are identied for the mobility protocols: Mobile IPv6, NEMO, NetLMM, MANEMO. They are mainly related to some attackers spoong the mobility-related nodes like MN, HA, MAG... or compromising them. Note that the issues can only be identied on clearly dened mobility protocols. Some of the mobility approaches are only concepts at the time of writing. For instance, MANEMO has no protocols dened yet, so the security issues can not be identied. Global HAHA is a layer-3 only protocol, so no security considerations can be made about the link-layer access. PMIPv6 is dened as a NetLMM implementation and its security closely relies on the existence of a proxy SEND solution to authenticate the link access. The analysis of MIPv6 and its implementation results in identifying the Returning Home process issue which can take the form of a full or partial deregistration attacks. This issue was recently posted to the IETF mext Working Group as the draft [13]. Some possible solutions to solve these issues are given in [47]. NEMO is closely related to MIPv6, so it suers from the same security issues than MIPv6.

35

MIPv6 Home Return

To keep the core of the document readable but still have the details available, this appendix provides a comprehensive analysis of MIPv6 main reference documents for what is related to Home Link detection and the Returning Home events.

A.1 Mobile IPv6 Home Link detection mechanism

The Mobile IPv6 Home Link detection mechanism is quite simple. In fact, it is specied in [2] by a simple sentence, in section 11.5.4 (Returning Home): A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prex is again on-link. At the time of writing, MIPv6 specication is being revised and that part of the document has been enhanced, to support interactions with IKEv2 for Home Prex Assignment [48]. Current version (02) of the draft [17] now includes a new specic subsection providing a simple detection algorithm16 . The relevant part of the algorithm is provided below : ... o Given the availability of the home prex, the MN checks whether or not the home prex matches one of the prexes received in the RA. If it does, the MN concludes that it has returned home. ... It basically goes in the same direction as [2]: Mobile Node considers itself on its home link if it detects a match between an advertised prex and its home subnet prex. In the end, the expected Home Link detection mechanism has not been modied compared to the one specicied in the original MIPv6 specication: simply put, if the MN nds itself on a link where its Home Subnet Prex is advertised, it considers itself at home.

A.2

Emission of deregistration BU by the MN

This excerpt from section 11.5.4 (Returning Home) of [15]17 describes the emission of the deregistration BU to the HA, just after it has detected it is at home (using previous mechanism) : ... The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In this home registration, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the Lifetime eld to zero, and set the care-of address for the binding to the mobile nodes own home address. The
on [49] current revision 02 of the document [17], the section has not been modied, but now has number 11.5.5
17 In 16 based

36

mobile node MUST use its home address as the source address in the Binding Update. ... As for all Binding Update messages sent to the Home Agent as part of Home Registration, IPsec protection is expected. Usually, in order for the CoA information to be IPsec protected 18 , the Alternate CoA Option must be present in the BU. This is explicitly stated in Section 11.7.1 (Sending Binding Updates to the Home Agent) of [15] : ... o The care-of address for the binding MUST be used as the Source Address in the packets IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Update. This option MUST be included in all home registrations, as the ESP protocol will not be able to protect care-of addresses in the IPv6 header. (Mobile IPv6 implementations that know they are using IPsec AH to protect a particular message might avoid this option. For brevity the usage of AH is not discussed in this document.) ... Nonetheless, this expected behavior is somewhat dierent when the Mobile Node is at home and needs to send its Binding Update. This is described at the end of the following excerpt from Section 4.3 (IPsec Protocol Processing ) of [15] : o When ESP is used to protect Binding Updates, there is no protection for the care-of address which appears in the IPv6 header outside the area protected by ESP. It is important for the home agent to verify that the care-of address has not been tampered with. As a result, the attacker would have redirected the mobile nodes trac to another address. In order to prevent this, Mobile IPv6 implementations MUST use the Alternate Care-of Address mobility option in Binding Updates sent by mobile nodes while away from home. The exception to this is when the mobile node returns home and sends a Binding Update to the home agent in order to de-register. In this case no Alternate Care-of Address option is needed, as described in Section 3.1. More specically, as described in section 11.5.4 of [2], the HoA must be set as source address of the Binding Update message : ... In this home registration, the mobile node MUST set [...] the care-of address for the binding to the mobile nodes own home address. The mobile node MUST use its home address as the source address in the Binding Update. ... Still in [15] (Section 3.1,Binding Updates and Acknowledgements), specic examples of expected packet layouts are given for registration when the node comes back home :
18 ESP

does not provide protection for packet source address

37

When the mobile node is at home, the above rules are dierent as the mobile node can use its home address as a source address. This typically happens for the de-registration Binding Update when the mobile is returning home. In this situation, the Binding Updates MUST support at least the following headers in the following order: IPv6 header (source = home address, destination = home agent) ESP header in transport mode Mobility header Binding Update This layout is associated with MUST support statements and is expected to be used. Note that [16], the revised version of [15], provides the same description and expects the same behavior. It is interesting to note that MIPv6 specication splits the emission and validation steps : previous discussion were associated with the emission of the deregistration BU by the MN. Processing rules for validation and parsing of BU by the HA when receiving it are covered in dierent sections of the document and discussed later in next subsection.

A.3 Receipt and validation of deregistration BU by the HA

The reference documents require that Home Agent supports previous Layout for deregistration Binding Update. Even if this is probably the expected layout, this is not the only possible solution. Additional information are given in Section 9.5.1 of [2], for validating Binding Update messages in general. Section 10.3.2 of [2] covers in details Primary Care-of Address DeRegistration. Here, the validation of deregistration BU format by the HA leaves room for dierent layouts : A binding may need to be de-registered when the mobile node returns home or when the mobile node knows that it will not have any care-of addresses in the visited network. A Binding Update is validated and authorized in the manner described in the previous section; note that when the mobile node de-registers when it is at home, it may not include the Home Address destination option, in which case the mobile nodes home address is the source IP address of the deregistration Binding Update. This section describes the processing of a valid Binding Update that requests the receiving node to no longer serve as its home agent, de-registering its primary care-of address. The non-normative may not include the Home Address destination option is ambiguous and error-prone : section 11.5.4 has a MUST use its home address as the source address in the Binding Update. If the Home Agent allows deregistration BUs with Home Address destination option, this leaves room for those to be sent from a foreign network, probably to support the case where the mobile node knows that it will not have any care-of addresses in the visited network. Because of the rules for determining care-of address and home address, provided in section 9.5.1 :

38

The specied care-of address MUST be determined as follows: o If the Alternate Care-of Address option is present, the care-of address is the address in that option. o Otherwise, the care-of address is the Source Address eld in the packets IPv6 header. The home address for the binding MUST be determined as follows: o If the Home Address destination option is present, the home address is the address in that option. o Otherwise, the home address is the Source Address eld in the packets IPv6 header. the following various deregistration BU sent by a Mobile Node should probably be considered valid (even if the specic layout may not be supported on a specic implementation) : IPv6 header (source = some address (possibly the HoA), destination = home agent) ESP header in transport mode Mobility header Binding Update Alternate Care-of Address option (Home Address) Weird deregistration BU, example 1

IPv6 header (source = Home Address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode Mobility header Binding Update Weird deregistration BU, example 2

IPv6 header (source = some address (possibly the HoA), destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode Mobility header Binding Update Alternate Care-of Address option (Home Address) Weird deregistration BU, example 3 The last example is the common layout expected by the HA when the MN is on a foreign network. The point here is that the expected layout for deregistration BU sent by the MN should be strictly checked by the HA when receiving the BU. It seems that the receiving rules for the HA are not that strict, possibly to support the case where mobile node knows that it will not have any care-of addresses in the visited network.

39

A.4 Local impacts of BU processing on the HA and emission of BA

In this subsection, we just make the hypothesis that the HA has received a deregistration BU which it has considered valid and that it has determined the care-of address and the home-address as described in section 9.5.1 of [2], quoted in previous subsection. The expected behavior by the HA is to remove the binding (local modication of MIPv6 related structures). It is also expected (even if not mandatory) that the tunnel with the Mobile Node be removed, now that it is back home. This is described at the end of section 11.5.4 of [2] : Note that the tunnel via the home agent typically stops operating at the same time that the home registration is deleted. When IPsec is used for protecting tunneled trac, the same behavior is expected. Section 4.2 of [16] species that : o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile nodes care-of address is torn down. The security policy entries, which were used for protecting tunneled trac between the mobile node and the home agent, SHOULD be made inactive (for instance, by removing them and installing them back later through an API). The corresponding security associations could be kept as they are or deleted depending on how they were created. If the security associations were created dynamically using IKE, they are automatically deleted when they expire. If the security associations were created through manual conguration, they MUST be retained and used later when the mobile node moves away from home again. The security associations protecting Binding Updates, Binding Acknowledgements and Mobile Prex Discovery messages SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again. This SHOULD in [16] was a MUST in [15]. The protection of BU/BA trac using ESP in transport mode is unmodied by the deregistration. After those changes, the HA sends back a BA to the MN. This is required because the A bit is set in the BU sent by the MN for deregistration, a BA is always sent by the HA, as described in section 9.5.4 of [17] : o If the Binding Update was discarded as described in Section 9.2 or Section 9.5.1, a Binding Acknowledgement MUST NOT be sent. Otherwise the treatment depends on the following rules. o If the Acknowledge (A) bit set is set in the Binding Update, a Binding Acknowledgement MUST be sent. Otherwise, the treatment depends on the below rule. o If the node rejects the Binding Update due to an expired nonce index, sequence number being out of window (Section 9.5.1), or insuciency of resources (Section 9.5.2), a Binding Acknowledgement MUST be sent. If the node accepts the Binding Update, the Binding Acknowledgement SHOULD NOT be sent.

40

This means that following the emission of a deregistration BU, a MN should expect to receive a BA. With regard to the address the BA is sent, section 9.5.4 of [2] contains the following : If the Source Address eld of the IPv6 header that carried the Binding Update does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent and the Binding Update packet MUST be silently discarded. Otherwise, the acknowledgement MUST be sent to the Source Address. Unlike the treatment of regular packets, this addressing procedure does not use information from the Binding Cache. However, a routing header is needed in some cases. If the Source Address is the home address of the mobile node, i.e., the Binding Update did not contain a Home Address destination option, then the Binding Acknowledgement MUST be sent to that address and the routing header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST be sent using a type 2 routing header which contains the mobile nodes home address. This basically implies that a deregistration BU with a HAO will possibly trigger a BA with a RH2 sent to whatever address was in the IPv6 header source address eld in the BU. Simply put, the BA is expect to be sent to the real address from which the BU was sent. In section 3.1 of [15], the common cases for the deregistration BA sent from the home network is covered : The Binding Acknowledgement messages sent to the home address MUST support at least the following headers in the following order: IPv6 header (source = home agent, destination = home address) ESP header in transport mode Mobility header Binding Acknowledgement

A.5 Local impact associated with BU emission and BA processing on the MN

Once it has sent the deregistration BU, the MN is expected to perform some modication of its ND behavior, as discussed in section 11.5.5 (Returning home) of [17]. Some nal changes are performed after receiving the BA from the HA : After the Mobile Node sends the Binding Update, it MUST be prepared to reply to Neighbor Solicitations for its home address. Such replies MUST be sent using a unicast Neighbor Advertisement to the senders link-layer address. It is necessary to reply, since sending the Binding Acknowledgement from the home agent may require performing Neighbor Discovery, and the mobile node may not be able to distinguish Neighbor Solicitations coming from the home agent from other Neighbor Solicitations. Note that a race condition exists where both the mobile node and the home agent respond to the same

41

solicitations sent by other nodes; this will be only temporary, however, until the Binding Update is accepted. After receiving the Binding Acknowledgement for its Binding Update to its home agent, the mobile node MUST multicast onto the home link (to the all-nodes multicast address) a Neighbor Advertisement [20], to advertise the mobile nodes own link-layer address for its own home address. The specication focuses on link layer interactions but does not provide information on the timing associated with the removal of the tunnel and/or IPsec Security Policies for tunnel trac. For performance reasons it usually happens when the BU is sent19 to avoid sending packets with a possibly invalid source address (the old CoA) while waiting for the BA to come back. If the same timing is kept when returning home, the MN will drop its IPsec protection as soon as it has sent the deregistration Binding Update.

Bibliography

References
[1] J. Manner and M. Kojo. Mobility Related Terminology. RFC 3753, Internet Engineering Task Force, June 2004. [2] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775, Internet Engineering Task Force, June 2004. [3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Network Mobility (NEMO) Basic Support Protocol. RFC 3963, Internet Engineering Task Force, January 2005. [4] Thierry Ernst and Hong-Yon Lach. Network Mobility Support Terminology. Request For Comments (RFC) 4885, IETF, July 2007. [5] Thierry Ernst. Network Mobility Support Goals and Requirements. Request For Comments (RFC) 4886, IETF, July 2007. [6] ChanWah Ng, Pascal Thubert, Masafumi Watari, and Fan Zhao. Network Mobility Routing Optimization Problem Statement. Request For Comments (RFC) 4888, IETF, July 2007. [7] ChanWah Ng, Fan Zhao, Masafumi Watari, and Pascal Thubert. Network Mobility Routing Optimization Solution Space Analysis. Request For Comments (RFC) 4889, IETF, July 2006. [8] P. Thubert, R. Wakikawa, and V. Devarapalli. Global HA to HA protocol. Internet-Draft draft-thubert-mext-global-haha-00, Internet Engineering Task Force, March 2008. Work in progress. [9] F. Dupont, J. Combes, and M. Laurent-Maknavicius. Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful. Internet-Draft draft-dupont-mext-dhaadharmful-00, Internet Engineering Task Force, June 2008. Work in progress. [10] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specication. RFC 2460, Internet Engineering Task Force, December 1998.
19 UMIP,

the linux implementation, does just that

42

[11] J. Abley, P. Savola, and G. Neville-Neil. Deprecation of Type 0 Routing Headers in IPv6. RFC 5095, Internet Engineering Task Force, December 2007. [12] P. Nikander, J. Arkko, T. Aura, G. Montenegro, and E. Nordmark. Mobile IP Version 6 Route Optimization Security Design Background. RFC 4225, Internet Engineering Task Force, December 2005. [13] A.Ebalard. Mobile IPv6 Home Link Detection Mechanism Security considerations. Internet-Draft draft-ebalard-mext-hld-security00, Internet Engineering Task Force, April 2009. Work in progress. [14] Arnaud Ebalard and Jean-Michel Combes and Maryline LaurentMaknavicius. MobiSEND ANR SP1a project deliverable. Technical Report 0007, ANR, 2008. [15] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. RFC 3776, Internet Engineering Task Force, June 2004. [16] V. Devarapalli and F. Dupont. Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. RFC 4877, Internet Engineering Task Force, April 2007. [17] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. Internet-Draft draft-ietf-mext-rfc3775bis-02, Internet Engineering Task Force, October 2008. Work in progress. [18] W. Haddad, G. Tsirtsis, B. Lim, S. Krishnan, and F. Dupont. Mobile IPv6 Residual Threats. Internet-Draft draft-haddad-mext-mip6residual-threats-02, Internet Engineering Task Force, July 2008. Work in progress. [19] D. Johnson and S. Deering. Reserved IPv6 Subnet Anycast Addresses. RFC 2526, Internet Engineering Task Force, March 1999. [20] J. Kempf. Problem Statement for Network-Based Localized Mobility Management (NETLMM). RFC 4830, Internet Engineering Task Force, April 2007. [21] J. Kempf. Goals for Network-Based Localized Mobility Management (NETLMM). RFC 4831, Internet Engineering Task Force, April 2007. [22] C. Vogt and J. Kempf. Security Threats to Network-Based Localized Mobility Management (NETLMM). RFC 4832, Internet Engineering Task Force, April 2007. [23] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson. Host Identity Protocol. RFC 5201, Internet Engineering Task Force, April 2008. [24] T. Kivinen and H. Tschofenig. Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol. RFC 4621, Internet Engineering Task Force, August 2006. [25] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil. Proxy Mobile IPv6. RFC 5213, Internet Engineering Task Force, August 2008. [26] G. Giaretta. The NetLMM Protocol. Internet-Draft draft-giarettanetlmm-dt-protocol-02.txt, Internet Engineering Task Force, April 2007. Work in progress.

43

[27] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. RFC 4291, Internet Engineering Task Force, February 2006. [28] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney. Dynamic Host Conguration Protocol for IPv6 (DHCPv6). RFC 3315, Internet Engineering Task Force, July 2003. [29] S. Thomson, T. Narten, and T. Jinmei. IPv6 Stateless Address Autoconguration. RFC 4862, Internet Engineering Task Force, September 2007. [30] R. Wakikawa and S. Gundavelli. IPv4 Support for Proxy Mobile IPv6. Internet-Draft draft-ietf-netlmm-pmip6-ipv4-support-06, Internet Engineering Task Force, November 2008. Work in progress. [31] T. Narten, E. Nordmark, W. Simpson, and H. Soliman. Neighbor Discovery for IP version 6 (IPv6). RFC 4861, Internet Engineering Task Force, September 2007. [32] S. Narayanan, J. Kempf, E. Nordmark, B. Pentland, J. Choi, G. Daley, and N. Montavont. Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 Design). Internet-Draft draftietf-dna-protocol-08, Internet Engineering Task Force, July 2008. Work in progress. [33] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury. Mobile Node Identier Option for Mobile IPv6 (MIPv6). RFC 4283, Internet Engineering Task Force, November 2005. [34] J. Arkko, J. Kempf, B. Zill, and P. Nikander. SEcure Neighbor Discovery (SEND). RFC 3971, Internet Engineering Task Force, March 2005. [35] D. Mills. Network Time Protocol (Version 3) Specication, Implementation and Analysis. RFC 1305, Internet Engineering Task Force, March 1992. [36] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. RFC 4330, Internet Engineering Task Force, January 2006. [37] D. Oulai and S. Krishnan. IPv4 support in PMIP-MIP interaction. Internet-Draft draft-oulai-netlmm-mip-interaction-v4support-00, Internet Engineering Task Force, July 2008. Work in progress. [38] J. Laganier, S. Narayanan, and P. McCann. Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node. Internet-Draft draft-ietf-netlmm-mn-ar-if-03, Internet Engineering Task Force, February 2008. Work in progress. [39] H. Yokota, K. Chowdhury, R. Koodli, B. Patil, and F. Xia. Fast Handovers for PMIPv6. Internet-Draft draft-yokota-mipshop-pfmipv603, Internet Engineering Task Force, July 2008. Work in progress. [40] Y. Han and B. Park. A Fast Handover Scheme in Proxy Mobile IPv6. Internet-Draft draft-han-netlmm-fast-pmipv6-00, Internet Engineering Task Force, July 2008. Work in progress. [41] S. Kent and K. Seo. Security Architecture for the Internet Protocol. RFC 4301, Internet Engineering Task Force, December 2005. [42] C. Kaufman. Internet Key Exchange (IKEv2) Protocol. RFC 4306, Internet Engineering Task Force, December 2005.

44

[43] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz. Extensible Authentication Protocol (EAP). RFC 3748, Internet Engineering Task Force, June 2004. [44] F. Adrangi, A. Lior, J. Korhonen, and J. Loughney. Chargeable User Identity. RFC 4372, Internet Engineering Task Force, January 2006. [45] S. Krishnan, J. Laganier, and M. Bonola. Secure Proxy ND Support for SEND. Internet-Draft draft-krishnan-csi-proxy-send-00, Internet Engineering Task Force, June 2008. Work in progress. [46] S. Krishnan, A. Kukec, and K. Ahmed. Certicate prole and certicate management for SEND. Internet-Draft draft-krishnan-cgaextsend-cert-eku-02, Internet Engineering Task Force, November 2008. Work in progress. [47] Tony Cheneau and Maryline Laurent-Maknavicius. MobiSEND ANR SP2 project deliverable. Technical Report 0007, ANR, 2008. [48] G. Giaretta, J. Kempf, and V. Devarapalli. Mobile IPv6 Bootstrapping in Split Scenario. RFC 5026, Internet Engineering Task Force, October 2007. [49] S. Krishnan and G. Tsirtsis. MIPv6 Home Link Detection. InternetDraft draft-krishnan-mext-hld-01, Internet Engineering Task Force, March 2008. Work in progress.

45