idnits 2.17.1 

draft-arkko-mip6-ro-enhancements-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3667, Section 5.1 on line 16.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 2321.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2305.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2311.

  ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
     2327), which is fine, but *also* found old RFC 2026, Section 10.4C,
     paragraph 1 text on line 37.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

        By submitting this Internet-Draft, I certify that any applicable patent
        or other IPR claims of which I am aware have been disclosed, or
        will be disclosed, and any of which I become aware will be
        disclosed, in accordance with RFC 3668.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  == The page length should not exceed 58 lines per page, but there was 48
     longer pages, the longest (page 47) being 69 lines

  == It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 51 pages


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 2004) is 7133 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. '1'

  -- Possible downref: Normative reference to a draft: ref. '2' 

  -- Possible downref: Non-RFC (?) normative reference: ref. '3'

  -- Possible downref: Normative reference to a draft: ref. '5' 

  -- Possible downref: Non-RFC (?) normative reference: ref. '7'

  == Outdated reference: A later version (-03) exists of
     draft-qiu-mip6-certificated-binding-update-02

  -- Possible downref: Normative reference to a draft: ref. '9' 

  ** Downref: Normative reference to an Informational draft:
     draft-bradner-pbk-frame (ref. '10')

  -- Possible downref: Normative reference to a draft: ref. '12' 

  == Outdated reference: A later version (-04) exists of
     draft-haddad-mip6-cga-omipv6-02

  -- Possible downref: Normative reference to a draft: ref. '13' 

  -- Possible downref: Non-RFC (?) normative reference: ref. '14'

  ** Obsolete normative reference: RFC 3775 (ref. '15') (Obsoleted by RFC
     6275)

  ** Obsolete normative reference: RFC 2406 (ref. '16') (Obsoleted by RFC
     4303, RFC 4305)

  == Outdated reference: A later version (-10) exists of
     draft-ietf-ipsec-esp-v3-08

  == Outdated reference: A later version (-03) exists of
     draft-ietf-mipshop-fast-mipv6-02

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-mipshop-fast-mipv6 (ref. '18')

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-ipv6-node-requirements (ref. '19')

  -- Possible downref: Non-RFC (?) normative reference: ref. '20'

  == Outdated reference: A later version (-07) exists of
     draft-ietf-ipv6-optimistic-dad-01

  == Outdated reference: A later version (-10) exists of
     draft-ietf-hip-base-00

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-hip-base (ref. '22')

  == Outdated reference: A later version (-03) exists of
     draft-ietf-mip6-ro-sec-01

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-mip6-ro-sec (ref. '23')

  -- Possible downref: Non-RFC (?) normative reference: ref. '24'

  ** Obsolete normative reference: RFC 3344 (ref. '25') (Obsoleted by RFC
     5944)

  -- No information found for draft-ietf-mip6-precfgKbm - is the name correct?

  -- Possible downref: Normative reference to a draft: ref. '26' 

  -- Possible downref: Normative reference to a draft: ref. '27' 

  -- Possible downref: Non-RFC (?) normative reference: ref. '28'

  == Outdated reference: A later version (-05) exists of
     draft-ietf-mip6-bootstrap-ps-00

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-mip6-bootstrap-ps (ref. '29')

  == Outdated reference: A later version (-07) exists of
     draft-ietf-mip6-auth-protocol-00

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-mip6-auth-protocol (ref. '30')

  -- Possible downref: Non-RFC (?) normative reference: ref. '31'

  -- Possible downref: Normative reference to a draft: ref. '32' 

  == Outdated reference: A later version (-04) exists of
     draft-ietf-mipshop-hmipv6-02

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-mipshop-hmipv6 (ref. '33')

  -- Possible downref: Non-RFC (?) normative reference: ref. '34'

  -- Possible downref: Normative reference to a draft: ref. '35' 

  -- Possible downref: Normative reference to a draft: ref. '36' 


     Summary: 20 errors (**), 0 flaws (~~), 14 warnings (==), 26 comments
     (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	Network Working Group                                           J. Arkko
2	Internet-Draft                              Ericsson Research NomadicLab
3	Expires: April 1, 2005                                           C. Vogt
4	                                                 University of Karlsruhe
5	                                                            October 2004

7	      A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route
8	                              Optimization
9	                  draft-arkko-mip6-ro-enhancements-00

11	Status of this Memo

13	   By submitting this Internet-Draft, I certify that any applicable
14	   patent or other IPR claims of which I am aware have been disclosed,
15	   and any of which I become aware will be disclosed, in accordance with
16	   RFC 3668.

18	   Internet-Drafts are working documents of the Internet Engineering
19	   Task Force (IETF), its areas, and its working groups. Note that other
20	   groups may also distribute working documents as Internet-Drafts.

22	   Internet-Drafts are draft documents valid for a maximum of six months
23	   and may be updated, replaced, or obsoleted by other documents at any
24	   time. It is inappropriate to use Internet-Drafts as reference
25	   material or to cite them other than as "work in progress."

27	   The list of current Internet-Drafts can be accessed at http://
28	   www.ietf.org/ietf/1id-abstracts.txt.

30	   The list of Internet-Draft Shadow Directories can be accessed at
31	   http://www.ietf.org/shadow.html.

33	   This Internet-Draft will expire on April 1, 2005.

35	Copyright Notice

37	   Copyright (C) The Internet Society (2004). All Rights Reserved.

39	Abstract

41	   The Mobile IPv6 mobility-management protocol enables minimum routing
42	   paths between a mobile node and a correspondent node, which may
43	   itself be mobile. This feature is called route optimization. Route
44	   optimization requires authorization of initially unacquainted and
45	   untrusted parties. A so-called return-routability procedure was
46	   integrated into the Mobile IPv6 in order to do this securely. The
47	   return-routability procedure equips the mobile node with
48	   cryptographic tokens that authenticate the mobile node and prove the
49	   mobile node's presence at a claimed new location after movement.
50	   Recently, a number of improvements or optional alternatives have been
51	   suggested to the standard procedure. The primary driver between these
52	   improvements is oftentimes further reduction of signaling messages
53	   and latency, but other improvements such as better security have also
54	   been suggested. This document discusses the potential goals for
55	   future enhancements of route optimization, the security threats that
56	   such enhancements must consider, and the various enhancement
57	   proposals and their key ideas. An evaluation of some recent proposals
58	   is included, as well as a discussion of how significant the Mobile
59	   IPv6 related optimizations are related to other ongoing optimization
60	   efforts. Finally, needs for future research are outlined.

62	Table of Contents

64	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
65	   2.   Mobility-Related Security Threats  . . . . . . . . . . . . .   6
66	     2.1  Impersonation Attacks  . . . . . . . . . . . . . . . . . .   6
67	     2.2  Resource-Exhaustion Attacks  . . . . . . . . . . . . . . .   7
68	     2.3  Flooding Attacks . . . . . . . . . . . . . . . . . . . . .   8
69	   3.   Mobile IPv6 Route Optimization . . . . . . . . . . . . . . .   9
70	     3.1  Goals and Assumptions  . . . . . . . . . . . . . . . . . .  10
71	     3.2  Return Routability Procedure . . . . . . . . . . . . . . .  11
72	     3.3  Security Analysis  . . . . . . . . . . . . . . . . . . . .  16
73	   4.   Objectives for Enhancement . . . . . . . . . . . . . . . . .  17
74	     4.1  Latency Optimizations  . . . . . . . . . . . . . . . . . .  17
75	     4.2  Signaling Optimizations  . . . . . . . . . . . . . . . . .  18
76	     4.3  Security Enhancements  . . . . . . . . . . . . . . . . . .  19
77	     4.4  Applicability Enhancements . . . . . . . . . . . . . . . .  20
78	   5.   The Toolbox  . . . . . . . . . . . . . . . . . . . . . . . .  20
79	     5.1  Address Tests  . . . . . . . . . . . . . . . . . . . . . .  21
80	     5.2  Protected Tunnels  . . . . . . . . . . . . . . . . . . . .  21
81	     5.3  Optimistic Behaviour . . . . . . . . . . . . . . . . . . .  22
82	     5.4  Proactive Tests  . . . . . . . . . . . . . . . . . . . . .  22
83	     5.5  Concurrent Tests . . . . . . . . . . . . . . . . . . . . .  23
84	     5.6  Diverted Routing . . . . . . . . . . . . . . . . . . . . .  24
85	     5.7  Credit-Based Authorization . . . . . . . . . . . . . . . .  25
86	     5.8  Heuristic Monitoring . . . . . . . . . . . . . . . . . . .  26
87	     5.9  Cryptographically Generated Addresses  . . . . . . . . . .  27
88	     5.10   Semi-Permanent Security Associations . . . . . . . . . .  28
89	     5.11   Pre-Configuration  . . . . . . . . . . . . . . . . . . .  29
90	     5.12   Infrastructure . . . . . . . . . . . . . . . . . . . . .  29
91	     5.13   Cryptographically Bound Identifiers  . . . . . . . . . .  30
92	     5.14   Local Mobility . . . . . . . . . . . . . . . . . . . . .  30
93	     5.15   Local Repair . . . . . . . . . . . . . . . . . . . . . .  31
94	     5.16   Processing Improvements  . . . . . . . . . . . . . . . .  32
95	     5.17   Delegation . . . . . . . . . . . . . . . . . . . . . . .  33
96	   6.   Analysis . . . . . . . . . . . . . . . . . . . . . . . . . .  33
97	     6.1  Categorization of Techniques . . . . . . . . . . . . . . .  33
98	     6.2  Evaluation of Some Proposals . . . . . . . . . . . . . . .  34
99	     6.3  Further Research . . . . . . . . . . . . . . . . . . . . .  42
100	   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  44
101	   8.   Conclusions  . . . . . . . . . . . . . . . . . . . . . . . .  44
102	   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  47
103	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  50
104	   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  50
105	        Intellectual Property and Copyright Statements . . . . . . .  51

107	1.  Introduction

109	   Traditionally, an IP address combines identification and location
110	   semantics. The address prefix locates a node's point of network
111	   attachment. It is used by routers to forward IP packets towards the
112	   correct destination. At the same time, existing transport protocols
113	   and applications, commonly termed "upper layers", use the IP address
114	   as part of a session identification. This naturally rules out
115	   mobility: Whenever a mobile node moves from one access network to
116	   another, its IP address must change to reflect the new location. The
117	   new "identity", however, causes sessions at upper layers to abort.

119	   Protocol designers thus had to decide whether to change transport
120	   protocols and applications, or to come up with a new IP-layer
121	   protocol that could separate location from identification
122	   functionality. Due to the prevalence of TCP and the significant base
123	   of existing applications, most people opted for the latter approach.
124	   Mobile IPv6 [15], its IPv4 counterpart [25], and the Host Identity
125	   Protocol [22] are three dominant mobility-management protocols that
126	   the IETF has developed to facilitate the continued use of existing
127	   transport protocols and applications in an Internet with mobility
128	   support. This document focuses on Mobile IPv6.

130	   Mobile IPv6 uses two IP addresses per mobile node in an attempt to
131	   separate location semantics from identification semantics: a
132	   transient "care-of address" is used for the purpose of routing. It is
133	   reconfigured whenever the mobile node moves to a new access network.
134	   A static "home address" is configured with the network prefix from a
135	   non-mobile "home agent's" network. The home address doesn't change
136	   when the mobile node moves, and it can be used for session
137	   identification at upper layers. The home address also serves as a
138	   node identifier for Mobile IPv6 itself. In the Mobile IPv6 base mode,
139	   "bidirectional tunneling", the home agent intercepts packets
140	   addressed to the mobile node's home address, and it tunnels those
141	   packets to the mobile node's current care-of address. After
142	   decapsulation at the mobile node, these packets bear the mobile
143	   node's home address and are as such accepted at upper layers. In the
144	   opposite direction, transport protocols and applications at the
145	   mobile node generate packets with the home address in the IPv6 Source
146	   Address field. The mobile node tunnels these packets to the home
147	   agent who, in turn, decapsulates them and forwards them on to the
148	   final recipient.

150	   Bidirectional tunneling through the home agent provides for location
151	   privacy, as a communication peer never sees the mobile node's care-of
152	   address. It is also a very safe approach to mobility, because all
153	   signaling between the mobile node and the home agent can easily be
154	   protected by means of a pre-established security association and
155	   trust relationship. Last, but not least, the beauty of bidirectional
156	   tunneling is that it does not require support from a mobile node's
157	   correspondent peer. On the other hand, middle-box-style approaches
158	   like bidirectional tunneling loose attractiveness due to the
159	   additional overhead that a growing population of mobile nodes can
160	   pose on the Internet. A home agent can also be a single point of
161	   failure or a performance bottleneck. This leads to the concept of
162	   "route optimization".

164	   With Mobile IPv6 route optimization, packets can be directly relayed
165	   between a mobile node and its correspondent node. The mobile node
166	   keeps the correspondent node up to date about its current care-of
167	   address. When a route-optimized packets is received from the network,
168	   either at the mobile node or at the correspondent node, the Mobile
169	   IPv6 implementation replaces the care-of address in the packet's IPv6
170	   header by the mobile node's home address before the packet is handed
171	   to the upper layer. Vice versa, when a packet is received from the
172	   upper layer, the Mobile IPv6 implementation replaces the home address
173	   in the packet's IPv6 header by the mobile node's current care-of
174	   address before the packet is injected into the network.

176	   The need for routing efficiency was deemed important enough to
177	   outweigh a number of disadvantages that come along with route
178	   optimization. First of all, different than bidirectional tunneling,
179	   route optimization requires mobility support from the correspondent
180	   node. Also, route optimization reveals the mobile node's current
181	   care-of address to the correspondent node, and thus makes the mobile
182	   node tracable. Route optimization should therefore not be used when
183	   location privacy is an issue. Last, but not least, route optimization
184	   would impose significant security threats if it was not accompanied
185	   by a new security protocol: Although one can generally neither
186	   presuppose a security association nor a trust relationship between a
187	   mobile node and its communication peer, a correspondent node should
188	   be able to verify the origin, the integrity, and the validity of all
189	   received registration messages. Indeed, a mobile node must authorize
190	   its requests to the correspondent node, protect a registration
191	   message against tampering, and prove to the correspondent node that
192	   it is indeed reachable through the to-be-registered care-of address.
193	   Such protection is necessary to prevent impersonation and
194	   denial-of-service attacks [23].

196	   As part of the registration procedure, a correspondent node probes a
197	   mobile node's home address to verify the mobile node's identity. It
198	   also probes the mobile node's care-of address to gain assurance that
199	   the mobile node is reachable at this address. The two address tests
200	   are combined in the so-called "return-routability procedure".

202	   The return-routability procedure is to be executed for each
203	   care-of-address update, or periodically in case the mobile node does
204	   not move for a while. This can lead to a handover delay unacceptable
205	   for many real-time or interactive applications like Voice over IP
206	   (VoIP) and audio or video streaming. Moreover, the periodic
207	   repetitions imply a hidden signaling overhead that may interfere with
208	   mobile nodes who intend to sleep during times of inactivity. Finally,
209	   the return-routability procedure uses "weak authentication" to bind a
210	   home address to the legitimate owner. It limits vulnerabilities to
211	   attackers that are on the path from the correspondent node to the
212	   mobile node or to the home agent. The residual vulnerabilities are
213	   similar to those that exist anyway in today's non-mobile Internet.
214	   But still, mechanisms that use strong authentication of IP addresses
215	   can provide a higher level of security than the return-routability
216	   procedure does.

218	   This document describes and classifies possible enhancements to the
219	   return-routability procedure. Following this introduction, section
220	   Section 2 shows which new security threats arise in an Internet with
221	   mobility support. Section 3 explains the care-of-address registration
222	   protocol as defined in RFC 3775 [15], including the
223	   return-routability procedure. A number of potential goals for
224	   enhancements (such as reducing latency) are discussed in Section 4.
225	   Known optimization techniques are discussed in Section 5. Section 6
226	   discusses how these techniques are used by existing optimization
227	   proposals, evaluates some of these proposals, and proposes some
228	   further work.

230	2.  Mobility-Related Security Threats

232	   Mobile IPv6 allows a node to redirect those packets, that a
233	   correspondent node would otherwise send to one IP address (the home
234	   address), to a second IP address (the care-of address). But the
235	   ability for redirection could also be misused by a malicious node for
236	   an arbitrary pair of IP addresses if no appropriate precautions were
237	   taken.

239	   Overall, there are three major families of mobility-related threats:
240	   impersonation attacks, resource-exhaustion attacks, and flooding
241	   attacks. The following subsections take a closer look at each of the
242	   categories. Threats are described in the light of Mobile IPv6, but
243	   some of them apply to other mobility-management protocols as well.

245	2.1  Impersonation Attacks

247	   The probably most obvious issue with mobility is how one can ensure
248	   that only a mobile node itself has the ability to change its care-of
249	   address. If care-of-address registrations were unauthenticated, an
250	   attacker could easily impersonate an arbitrary victim. For instance,
251	   the attacker could contact the victim's correspondent node and
252	   register its own IP address on behalf of its victim. The
253	   correspondent node would assume that the victim's care-of address has
254	   changed, and it would redirect all packets intended for the victim to
255	   the attacker instead. The attacker could forward the packets to the
256	   victim after analyzing, or even tampering with, their payloads. In a
257	   related offense, the perpetrator could simply cause havoc at its
258	   victim by directing the victim's packets to a random or non-existent
259	   IP address. These attacks are jointly referred to as "impersonation
260	   attacks". Impersonation attacks can be prevented through proper
261	   authentication techniques that keep an outsider from assuming another
262	   node's identity.

264	   It is important to recognize that impersonation attacks not only
265	   impact those nodes that have an interest in mobility. Although the
266	   attacker makes the correspondent node believe that the victim is
267	   mobile, neither the attacker nor the victim do have to be mobile.
268	   Indeed, mobile nodes, non-moving nodes with mobility support, as well
269	   as traditional stationary nodes are potentially endangered because
270	   they all share the same IPv6 identifier namespace. (Actually, even
271	   IPv4 nodes are jeopardized when IPv4-to-IPv6 translation occurs on
272	   the path between these nodes and their correspondent peers.) This
273	   unfolds the need for mandatory protection of mobility-related
274	   signaling in order to safeguard the Internet community as a whole.

276	   Beyond their large group of potential victims, mobility-related
277	   impersonation attacks allow an attacker to choose the location from
278	   where to wage its attack. For example, the impersonator could
279	   position itself at a place where it is easier to inject spoofed
280	   care-of-address registration packets into the network than anywhere
281	   on the direct path between the victims. The attacker may also move to
282	   a place where it can remain unrecognized. In contrast to this, in the
283	   non-mobile Internet that we have today, an attacker can only listen
284	   to or tamper with packets while it is on the path between its
285	   victims. Similarly, a mobility-management protocol may give the
286	   attacker the possibility to shift the time for its attack. The
287	   attacker might be able to register false care-of addresses even
288	   before its victims' conversation begins, or attack a network long
289	   after it has visited it. In the non-mobile Internet, an attacker must
290	   strike at the same time as its victims communicate. The ability to
291	   choose the location and time for an attack constitutes a dangerous
292	   new degree of freedom for the attacker.

294	2.2  Resource-Exhaustion Attacks

296	   Mobility support at correspondent nodes can become an issue if it
297	   takes a lot of processing capacity to handle an incoming
298	   care-of-address registration. During times of increased signaling
299	   load, a correspondent node may thus end up having to commit a
300	   significant fraction of its resources to mobility-related
301	   transactions. What is worse, an attacker may take advantage of this
302	   vulnerability. It could swamp the correspondent node with large
303	   quantities of bogus registrations messages, keeping it from doing
304	   useful work. Such denial-of-service attempts are called
305	   "resource-exhaustion attacks". Clearly, if mobility support is to be
306	   implemented on a large basis, handling care-of-address registrations
307	   must be lightweight in order to lessen the susceptibility to resource
308	   exhaustion. Another effective technique is to defer resource
309	   commitment until late in the registration process: Once the
310	   registrant has proven its identity or shown that it is willing to
311	   invest resources itself, it is less likely malicious. As a last
312	   resort, busy Internet servers should limit the resources they devote
313	   to registration processing, and they may give preference to those
314	   mobile nodes they know or have recently had meaningful communications
315	   with.

317	   It is worthwhile to stress the trade-off between effectiveness of
318	   signaling authentication and resilience against increased signaling
319	   load. On one hand, a strong authentication mechanism can effectively
320	   prevent certain impersonation attacks. On the other hand, the
321	   resources a correspondent node must spend on the verification of a
322	   registering node's authenticity increases with the complexity of the
323	   authentication algorithm. The susceptibility to resource exhaustion
324	   thus grows with the level of protection against impersonation
325	   attacks.

327	2.3  Flooding Attacks

329	   A third mobility-related security threat emanates from
330	   redirection-based flooding attacks. Redirection-based flooding
331	   attacks are characterized by a victim being bombarded with unwanted
332	   packets at a rate that the victim, and possibly the victim's access
333	   network, cannot handle. As with impersonation attacks, it is
334	   important to compare existing flooding attacks in today's non-mobile
335	   Internet with redirection-based flooding attacks that could be made
336	   possible through an insecure mobility-management protocol.

338	   Three types of flooding attacks can be identified in today's
339	   Internet. The simplest one is a "direct flooding attack". Here, the
340	   attacker itself sends bogus packets to the victim. In an indirect
341	   "reflection attack", the attacker tricks a third node, the
342	   "reflection point", to send the packets. It typically uses a known
343	   protocol vulnerability to make the reflection point generate these
344	   packets [24]. For example, the attacker may send spoofed ICMP Echo
345	   Request packets to the reflection point, using its victim's IP
346	   address in the packets' IPv6 Source Address field. For each such
347	   request, the reflection point generates an ICMP Echo Reply message,
348	   which it sends "back" to the victim. The advantage of a reflection
349	   attack over a direct flooding attack is that the attacker is usually
350	   harder to track when flooding traffic comes from a third node.
351	   Another example for a reflection attack is TCP-SYN flooding. Here,
352	   the attacker sends TCP SYN packets, again with false source
353	   addresses, to the reflection point, which in turn sends TCP SYN-ACK
354	   packets to someone who does not expect these packets. Since most TCP
355	   servers are configured so that they re-send a TCP SYN packet multiple
356	   times when failing to receive an acknowledgement, this reflection
357	   attack can even produce a small amplification. Gaining higher
358	   amplification in today's Internet necessitates more complex
359	   strategies like "distributed flooding attacks". In a distributed
360	   flooding attack, the attacker typically gains control over other
361	   nodes by spreading viral software. Then, at a certain point of time,
362	   infected nodes simultaneously commence a joint flooding attack
363	   against a common victim.

365	   The introduction of mobility support renders amplified flooding
366	   attacks much less complex. Suppose a mobile node is allowed to change
367	   its care-of address without having to evidence that it is present at
368	   the new care-of address. Then, an attacker can subscribe, through its
369	   own IP address, to a large data flow (e.g., a video stream) offered
370	   by some server on the Internet. The attacker can easily accomplish
371	   the initial handshake procedure with the server while it uses its own
372	   IP address. Once data is flowing, the attacker can redirect the flow
373	   to the IP address of an arbitrary victim. The attacker can use the
374	   sequence numbers learned during the initial handshake procedure in
375	   order to spoof acknowledgements for packets that it assumes the
376	   server has sent to the victim. In this attack, not the attacker, but
377	   a faithful server on the Internet can be made generate packets used
378	   for an attack. The server does not have to be infected with
379	   compromised code, and neither the victim nor the server has to be
380	   mobile. The attacker produces as little as spoofed feedback
381	   information to keep the data flow alive. To make matters worse, the
382	   attacker can redirect data flows from multiple servers to the victim.

384	   Support for Mobile IPv6 route optimization is recommended to all IPv6
385	   nodes [19]. The base of correspondent nodes that an attacker could
386	   exploit for a redirection-based flooding attack would therefore be
387	   immense. Also note that no distribution of viral software would be
388	   necessary. The severity of this new type of flooding is that it would
389	   provide potentially unbounded amplification at comparably low cost.

391	3.  Mobile IPv6 Route Optimization

393	   The potential for new security threats necessitates the protection of
394	   mobility-related signaling in Mobile IPv6. The development of an
395	   appropriate security design, however, is a challenge: Nodes that
396	   never met before must find a way to authenticate themselves,
397	   preferably without the need for a global PKI. Also, a trade-off
398	   between cryptographic complexity and resilience to resource
399	   exhaustion must be found.

401	   This section explains the security design for Mobile IPv6 route
402	   optimization in the light of the goals and assumptions based on which
403	   it was built.

405	3.1  Goals and Assumptions

407	   An important objective for the development of Mobile IPv6 was to
408	   provide for a wide, preferably universal, support for route
409	   optimization. In fact, support for Mobile IPv6 and, thus, route
410	   optimization is recommended in the requirements suite for IPv6 nodes
411	   [19]. It was, and still is, believed that the additional routing
412	   overhead associated with bidirectional tunneling is too much of a
413	   burden on the core Internet given that the number of connected mobile
414	   nodes is expected to grow substantially within the next years.

416	   The aspiration for wide-scale deployment of route optimization has an
417	   impact on how correspondent nodes can authenticate mobile nodes.
418	   Authentication can be performed based on a preconfigured shared
419	   secret or through a trusted public-key infrastructure (PKI).
420	   Unfortunately, both approaches turn out to be impractical for route
421	   optimization.

423	   Preconfiguration is not an option because there is usually no
424	   pre-existing relationship between communicating nodes. A PKI could
425	   assist unacquainted nodes in the authentication process. But a PKI
426	   for Mobile IPv6 would have to be able to authenticate all mobile
427	   nodes on the Internet. It is generally believed that no such PKIs can
428	   be constructed. More seriously, a PKI that simply authenticates users
429	   would not suffice to prevent mobility related attacks. It would be
430	   necessary to have authorization of specific IP addresses. This seems
431	   hard even for home addresses, as IP address assignment is usually
432	   handled by other network entities than the PKI nodes.  Moreover,
433	   authorization of care-of addresses would be infeasible, as these
434	   addresses change all the time. The global PKI would also constitute
435	   an attractive target for attacks, endangering the Internet as a
436	   whole.

438	   Due to these difficulties, the concept of "weak authentication" was
439	   elaborated for the use between nodes that have no a-priori
440	   relationship. The intent was to make an Internet with mobility
441	   support as secure as the non-mobile Internet is today.

443	   It is important to recognize that some mobility-related attacks can
444	   be prevented through authentication/authorization of the used IP
445	   addresses, while others cannot. Impersonation attacks belong the the
446	   former class. Protection against resource-exhaustion attacks requires
447	   that the protocol is of low complexity, or delays state creation and
448	   computation in an appropriate manner until peer has shown its
449	   credentials. On the other hand, redirection-based flooding attacks
450	   are based on care-of-address spoofing. Mandatory authentication may
451	   lessen the attractiveness of such flooding, but certainly cannot
452	   prevent it. Care-of-address validity must therefore be ensured
453	   through different means.

455	   One option is to enforce proper use of care-of addresses already at
456	   the mobile node's point of network attachment. The correspondent node
457	   may then simply believe in the validity of a care-of address without
458	   doing any verification itself. Many access networks today provide
459	   this service through ingress filtering [11]. However, the crux with
460	   verifying a care-of address at the fringe of the Internet is that an
461	   attacker can choose the location from where to wage a flooding
462	   attack. As long as there are access networks where ingress filtering,
463	   or an equivalent technique, is not deployed, an attacker can always
464	   avoid care-of-address verification. Mobile IPv6 hence does not rely
465	   on ingress filtering.

467	   Another way to protect against care-of-address spoofing is to have a
468	   correspondent node probe a mobile node's new care-of address before
469	   it sends packet there. This verification strategy operates end to
470	   end, and it is independent of support from the access network. Mobile
471	   IPv6 uses care-of address probing during the return-routability
472	   procedure.

474	   It should be mentioned that care-of-address verification can be
475	   omitted in scenarios where the correspondent node has confidence in
476	   the mobile node's honesty. In fact, Mobile IPv6 assumes a trust
477	   relationship between mobile nodes and their respective home agents.
478	   It is believed that the mandatory security association between mobile
479	   nodes and home agents implicates the trust. This is certainly a
480	   feasible hypothesis in many cases, but one ought to bear that, in
481	   some scenarios, it may be not. If the home registration process had a
482	   care-of address verification, the extension of Mobile IPv6 for
483	   bootstrapping solutions would be easier [29].

485	3.2  Return Routability Procedure

487	   The security design for Mobile IPv6 route optimization is shaped from
488	   the assumptions outlined in the preceding section. At the heart of a
489	   correspondent registration is the return-routability procedure, a
490	   protocol for weak authentication and end-to-end care-of-address
491	   verification [15]. This section gives a nutshell view on the standard
492	   Mobile IPv6 correspondent registration. A correspondent registration
493	   has two phases: First, the return-routability procedure is executed,
494	   then the registration proper is accomplished.

496	   Mobile Node                 Home Agent             Correspondent Node
497	        |                          |                          |
498	        | 1. Binding Update (BU)   |                          |
499	        |------------------------->|                          |
500	        |                          |                          |
501	        | 2. Binding Ack (BA)      |                          |
502	        |<-------------------------|                          |
503	        |                          |                          |
504	        | 3a. Home Test Init (HoTI)|                          |
505	        |------------------------->|------------------------->|
506	        |                                                     |
507	        | 3b. Care-of Test Init (CoTI)                        |
508	        |---------------------------------------------------->|
509	        |                                                     |
510	        |                          | 4a.Home Test (HoT)       |
511	        |<-------------------------|<-------------------------|
512	        |                          |                          |
513	        |                            4b.Care-of Test (CoT)    |
514	        |<----------------------------------------------------|
515	        |                                                     |
516	        | 5. Binding Update (BU)                              |
517	        |-----------------------------------------------------|
518	        |                                                     |
519	        |                            6. Binding Ack (BA)      |
520	        |<----------------------------------------------------|
521	        |                                                     |

523	        Note 1: Waiting for the Binding Acknowledgement from
524	        the home agent may proceed in parallel with the rest
525	        of the process.

527	        Note 2: The home and care-of tests can be done in
528	        parallel. That is, the Home Test Init and Care-of Test
529	        Init messages can be sent one after another, and the
530	        process completes when a response has been received
531	        to both.

533	        Note 3: Acknowledgements are optional (but often
534	        desirable).

536	      Figure 1. Correspondent registration process.

538	            Figure 1: Mobile IPv6 Correspondent Registration

540	   When the mobile node detects that it has moved to a different access
541	   network, it configures an IP address with the prefix of the new
542	   network. The mobile node registers this IP address as its new care-of
543	   address with the home agent (home registration) and with each
544	   correspondent node capable of supporting route optimization
545	   (correspondent registration). The correspondent registration includes
546	   a return-routability procedure for authentication and care-of-address
547	   verification purposes. Figure Figure 1 depicts the overall process.
548	   The home and correspondent registrations may be interleaved as the
549	   mobile node can already initiate the correspondent registration while
550	   the home registration is still in progress. Messages (1) and (2)
551	   comprise the home registration; messages (3a) to (6) make up the
552	   correspondent registration. In the latter, messages (3a), (3b), (4a),
553	   and (4b) constitute the return-routability procedure. The following
554	   is a more detailed description of the registration process.

556	   When the mobile node has configured a care-of address after movement,
557	   it sends to its home agent a Binding Update message (1). The Binding
558	   Update message informs the home agent about the mobile node's new
559	   care-of address. The new care-of address is in the packet's IPv6
560	   source address, the home address is placed into the IPv6
561	   destination-options extension header. The Binding Update message is
562	   authenticated, and optionally encrypted, by means of an IPsec
563	   security association between the mobile node and the home agent.

565	   When the home agent receives the Binding Update message, it can
566	   determine the appropriate IPsec security association based on the
567	   mobile node's home address. Provided that the message is properly
568	   authenticated, the home agent registers the mobile node's new care-of
569	   address. In case the home agent maintains an IPsec tunnel for packets
570	   routed through the home network, it also updates the corresponding
571	   security association to the new care-of address [6]. The home agent
572	   sends back to the mobile node a Binding Acknowledgement message (2)
573	   to indicate successful care-of-address registration. Like the Binding
574	   Update message, the Binding Acknowledgement message is authenticated,
575	   and possibly encrypted, through IPsec.

577	   Once the home registration is complete, the mobile node initiates the
578	   correspondent registration. (In case the mobile nodes communicates
579	   with multiple correspondent nodes, it can register with all of them
580	   in parallel.) The mobile node sends to the correspondent node two
581	   messages in parallel: a Home Test Init message and a Care-of Test
582	   Init message. The Home Test Init message (3a) is tunneled to the
583	   mobile node's home agent, and forwarded on to the correspondent node.
584	   The Home Test Init message includes a random Home Init Cookie, which
585	   the correspondent node will return in its Home Test message. This
586	   gives the mobile node reasonable assurance that the Home Test message
587	   was sent by the correspondent node itself rather than a hidden
588	   attacker impersonating the correspondent node. In fact, the returned
589	   cookie can only guarantee that the Home Test message was generated by
590	   some node on the path from the mobile node via the home agent to the
591	   correspondent node. The Home Test Init message and the Home Test
592	   message may (and should) be protected through IPsec on the path
593	   between the mobile node and the home agent, but they are unprotected
594	   on the path between the home agent and the correspondent node. On the
595	   latter path, a malicious node may thus eavesdrop on the Home Init
596	   Cookie and return it in a spoofed Home Test message.

598	   The Care-of Test Init message (3b) does not go through the mobile
599	   node's home agent. It takes the direct path to the correspondent
600	   node. Again, the Care-of Test Init message includes a random cookie,
601	   the Care-of Init Cookie, to be returned by the correspondent node in
602	   the Care-of Test message. Both the Care-of Test Init and the Care-of
603	   Test messages cannot be protected by IPsec in the general case, since
604	   there is usually no security association between the mobile node and
605	   the correspondent node. For this reason, the cookie mechanism can
606	   only restrict the sender of the Care-of Test message to the direct
607	   path between the mobile node and the correspondent node. Still, the
608	   mobile node considers this a sufficient proof that the Care-of Test
609	   message was generated by the correspondent node itself.

611	   In the above, the return-routability procedure was generated after
612	   the home registration was complete. This is not necessarily so. The
613	   mobile node may reduce the registration latency by sending messages
614	   (1), (3a), and (4b) simultaneously.

616	   When the correspondent node receives the Home Test Init message, it
617	   sends back to the mobile node a Home Test message (4a). The Home Test
618	   message is directed to the mobile node's home address, hence passes
619	   the mobile node's home agent. The Home Test message contains a Home
620	   Keygen Token, a Home Nonce Index, and the Home Init Cookie copied
621	   from the Home Test Init message. The mobile node needs the Home
622	   Keygen Token to authenticate the Binding Update message, as described
623	   below. The Home Nonce Index identifies a random value based on which
624	   the correspondent node has computed the Home Keygen Token. The mobile
625	   node will include the Home Nonce Index in the subsequent Binding
626	   Update message to allow the correspondent node to reproduce the Home
627	   Keygen Token without having to explicitly store it.

629	   Likewise, upon receiving the Care-of Test Init message, the
630	   correspondent node sends back to the mobile node a Care-of Test
631	   message (4b). The Care-of Test message is directed to the mobile
632	   node's new care-of address, hence does not pass the mobile node's
633	   home agent. Similar to the Home Test message, the Care-of Test
634	   message contains a Care-of Keygen Token, a Care-of Nonce Index, and
635	   the Care-of Init Cookie copied from the Care-of Test Init message.
636	   The mobile node needs the Care-of Keygen Token for the Binding Update
637	   message in order to prove its reachability at the new care-of
638	   address. This is described below. When returned in the Binding Update
639	   message, the Care-of Nonce Index allows the correspondent node to
640	   reproduce the Care-of Keygen Token without having to store it.

642	   The mobile node then sends a Binding Update message (5) to the
643	   correspondent node. The Binding Update message contains a
644	   message-authentication code produced on the basis of the Home and the
645	   Care-of Keygen Tokens. It also contains the Home Nonce Index and the
646	   Care-of Nonce Index. The mobile node may request the correspondent
647	   node to return a Binding Acknowledgement message by raising the
648	   A-flag in the Binding Update message.

650	   When the correspondent node receives the Binding Update message, it
651	   can reproduce the Home Keygen Token and the Care-of Keygen Token with
652	   the help of the two nonce indices. The tokens, in turn, allow the
653	   correspondent node to verify the message-authentication code. If the
654	   message-authentication code is ok, the correspondent node can assume
655	   two things. First, the mobile node must have received the Home Keygen
656	   Token. Hence, the mobile node is the legitimate owner of the home
657	   address with high probability, since the Home Keygen Token was sent,
658	   as part of the Home Test message, to the mobile node's home address.
659	   Second, the mobile node must have received the Care-of Keygen Token.
660	   Therefore, the mobile node is apparently reachable through the new
661	   care-of address, since the Care-of Keygen Token was sent, as part of
662	   the Care-of Test message, to the mobile node's care-of address.
663	   Beyond this, the message-authentication code validates the Binding
664	   Update message's integrity.

666	   Provided that the verification of the message-authentication code
667	   succeeds, the correspondent node creates a binding-cache entry with
668	   the mobile node's new care-of address. The correspondent node uses
669	   the mobile node's new care-of address as soon as the binding-cache
670	   entry is in place. In case the A-flag in the Binding Update message
671	   is set, the correspondent node sends back to the mobile node a
672	   Binding Acknowledgement message (6) to indicate a successful
673	   care-of-address update.

675	   Both home and the correspondent registrations are valid for limited
676	   time only. For security reasons, these lifetimes are limited for
677	   correspondent nodes. If, after seven minutes, the mobile node did not
678	   move, it must refresh the existing registration with its
679	   correspondent nodes.

681	3.3  Security Analysis

683	   To analyse the security of the return-routability procedure, one
684	   should evaluate its protection against the tree types of attacks
685	   described in section Section 2: impersonation attacks against a
686	   mobile node, resource-exhaustion attacks against mobile nodes or
687	   correspondent nodes, and flooding attacks against third parties.

689	   Mobile IPv6 uses the home address as an identifier for a mobile node.
690	   Impersonation attacks are thus based on claiming ownership of another
691	   node's IP address. The return-routability procedure can prevent such
692	   attacks unless the attacker is on the path from the correspondent
693	   node to the victim (in the case of a stationary victim) or from the
694	   correspondent node to the victim's home agent (if the victim is
695	   mobile). However, if an attacker happens to be on the critical path,
696	   it can spoof a Home Test Init message on behalf of the victim,
697	   eavesdrop on the returning Home Test message, and thus illegitimately
698	   acquire a Home Keygen Token. The impersonator can produce its own
699	   Care-of Keygen Token by sending the victim's correspondent peer a
700	   Care-of Test Init message with a care-of address the impersonator
701	   itself is reachable through. Both tokens allow the attacker to send
702	   an authenticated Binding Update message on behalf of the victim.

704	   The described susceptibility to attacks from the routing path between
705	   two communicating nodes conforms with the design objective to make
706	   the security of a mobile Internet as secure as the current,
707	   non-mobile Internet. After all, an on-path attacker can compromise
708	   the communications of two nodes already today. It can block
709	   communications, or it can interfere by ingesting its own packets.

711	   The similarity between the home-address test and the care-of-address
712	   test belies the different purpose of these exchanges. While the
713	   former is to prevent impersonation attacks, the latter tackles the
714	   problem of flooding attacks by probing a mobile node's presence at a
715	   new care-of address. As with the home-address test, there are
716	   scenarios where the care-of-address test takes no effect. Namely, it
717	   cannot protect against attackers that are on the path between the
718	   victim and the correspondent node at which traffic is to be
719	   redirected. In this scenario, the attacker can perform a
720	   care-of-address test on behalf of the victim further down the path.

722	   Again, the exposure to on-path attacks corresponds to the objectives
723	   of the Mobile IPv6 security design. Flooding attacks initiated by an
724	   on-path attacker are already a threat in the non-mobile Internet: An
725	   on-path attacker could initiate, say, a large file download from an
726	   FTP server on behalf of a victim if the attacker is on the path from
727	   the FTP server to the victim. In this case, the attacker would
728	   probably do a TCP handshake using the victim's IP address. As it is
729	   on path, the attacker could hear the messages from the FTP server,
730	   and it could respond to them. The attacker would so learn the TCP
731	   Initial Sequence Number, which it needs to later spoof
732	   acknowledgements on behalf of its victim. These things considered,
733	   the care-of-address test inherent in the return-routability procedure
734	   limits flooding attacks to exactly those situations in which
735	   comparable flooding attacks are already possible today.

737	   Yet, the limitation to on-path attacks alone is insufficient to
738	   prevent a related style of attack that is called "space- and
739	   time-shift attacks". In these attacks, the perpetrator taps the
740	   critical wire in order to obtain the secret information it needs, and
741	   it then moves to a saver place and starts an attack from there. The
742	   attacker could also wait for a better point of time. It may even
743	   install a binding on behalf of a victim before the victim starts
744	   communicating. Mobile IPv6 requires mobile nodes to refresh active
745	   care-of-address registrations in intervals of at most seven minutes
746	   in an attempt to mitigate the threat of space- and time-shift
747	   attacks.

749	   The return-routability procedure is such that the correspondent node
750	   does not need to explicitly store the Home or Care-of Keygen Tokens
751	   sent to a mobile node. Given the index of a random nonce that was
752	   used to create a token, the correspondent node can recalculate the
753	   token. This saves the correspondent node from attacks against its
754	   memory. On the other hand, it may open the door for attacks against
755	   the correspondent node's processing capacity. A token is a SHA-1 hash
756	   on the mobile node's care-of or home address, the correspondent
757	   node's address, a random nonce, and a secret known only to the
758	   correspondent node. The related processing overhead is hence rather
759	   moderate, although a correspondent node should implement its own
760	   policies to manage resources in a situation of increased processing
761	   workload.

763	4.  Objectives for Enhancement

765	   This section discusses the objectives for enhanced or alternative
766	   designs for route optimization. We discuss the objectives from a
767	   requirements perspective, such as the need for decreasing latency.
768	   The technical means to reach those objectives is not considered here,
769	   nor is the feasibility of achieving them.

771	4.1  Latency Optimizations

773	   A disadvantage of the return-routability procedure is that a mobile
774	   node must wait for both address tests to complete before it can
775	   register a new care-of address. Therefore, a correspondent
776	   registration consumes, at a minimum, one and a half round-trip times
777	   between a mobile node and its correspondent node, counting the
778	   parallel address tests and the transfer of the Binding Update
779	   message. An additional one-way time elapses until the first packet
780	   from the correspondent node arrives at the new care-of address. Note
781	   that two different paths are employed: the direct path between the
782	   mobile node and the correspondent node, and the path via the home
783	   agent. The actual latency is governed by the path with a longer
784	   round-trip time.

786	   Direct communications to the correspondent node can optimistically
787	   start right after the Binding Update message has been sent (i.e.,
788	   after one round-trip time), but more generally are delayed until the
789	   Binding Acknowledgement message is received (i.e., after two
790	   round-trip times).

792	   Similarly, optimistic mobile nodes are allowed by RFC 3775 to start
793	   their return-routability procedure right after sending a Binding
794	   Update message to their home agent. They can so reduce the latency
795	   for the correspondent registration. But more generally, mobile nodes
796	   wait for the home registration to be completed and acknowledged
797	   before continuing with the correspondent registration.

799	   Depending on the type of application, the above delays can be an
800	   issue. For instance, this can be a problem in real-time voice-over-IP
801	   applications. Even fast bulk-data transfer can be affected if the
802	   lack of packets during the movement period is interpreted as
803	   congestion, leading to a new TCP slow start. There appears to be
804	   general consensus that faster mechanisms for route optimization are
805	   needed.

807	   Note that delays introduced by the rest of the stack can be
808	   significant as well (see Section 6.3.1). The sum of the delays from
809	   the link layer, IP layer, and IP mobility mechanisms must not exceed
810	   the requirements of the application.

812	4.2  Signaling Optimizations

814	   As stated in Section 3, one objective of the return-routability
815	   procedure is to prevent time-shift attacks. Time-shift attacks are
816	   prepared on the path between the victim and its correspondent node,
817	   but launched at a later time and from a different, probably more
818	   amenable location. Since authentication material is exchanged in
819	   unencrypted form during the return-routability procedure, an on-path
820	   eavesdropper can get hold of it. Mobile IPv6 requires that
821	   authentication material have limited lifetime in an attempt to
822	   prevent the eavesdropper from taking the stolen information to a
823	   different position. Registrations must be refreshed at least every
824	   seven minutes, even in the absent of handovers. Such periodic
825	   re-registrations limit the likelihood and feasibility of off-path
826	   attacks. After all, if a malicious node overheard authentication
827	   material on path and moved off path to launch the attack, it would
828	   have to get back on path when the authentication material is due to
829	   be refreshed.

831	   [5] shows that the seven-minute refreshment interval implies a
832	   signaling overhead of 7.16 bps [5] when one mobile node communicates
833	   with a stationary node. If both peers are mobile, the signaling
834	   overhead doubles. For two communicating nodes, this signaling
835	   overhead is certainly negligible. On the other hand, the accumulated
836	   overhead generated by a network provider's customer base can grow an
837	   issue. As an example, consider a mobile-phone provider that offers
838	   some sort of event-driven messenger service for its customers. For
839	   instant message delivery and reduced load on the core network, the
840	   provider may prescribe the use of route optimization. (Note that,
841	   with bi-directional tunneling, messages for all subscribers would
842	   have to be relayed through a home agent. This could drastically the
843	   increase network load.) On the other hand, even route optimization
844	   requires a home agent. For example, of the 716 Mbps signaling
845	   overhead generated by 100 million route-optimized mobile nodes, 220
846	   Mbps goes through the home agent.

848	   The signaling may also be an issue for mobile nodes that are inactive
849	   and stay at the same location for a while. Usually, these nodes have
850	   limited energy supply and prefer to go to standby mode when no
851	   transmissions are needed. Route optimization, however, would require
852	   them to continually wake up and re-register. This shows that an
853	   optimization for reduced signaling could be beneficial.

855	4.3  Security Enhancements

857	   In the current Internet, nodes can, and typically will, communicate
858	   even though they do not have a pre-existing relationship. This is
859	   usually not an issue, because most data exchanged on the Internet is
860	   non-confidential. On the other hand, recall from Section 2 that
861	   mobility does require authentication also for non-confidential
862	   communications, because mobility-related attacks may otherwise
863	   compromise the Internet community as a whole.

865	   The standard return-routability procedure takes a zero-configuration
866	   approach. This is lightway and prevents mobility-related attacks
867	   reasonably well. On the other hand, better security would be useful,
868	   particularly to limit what on-path attackers (including the nodes in
869	   the same network as the endpoints) can do.  There are existing
870	   proposals that offer higher security in Mobile IPv6 [32] and in other
871	   protocols such as HIP [27].

873	   However, even with better security for mobility management, the
874	   Internet as a whole cannot get any safer than the non-mobile
875	   Internet. For instance, even with plain IPv6 can on-path attackers
876	   cause denial of service, or inspect and modify cleartext packets.
877	   Communications that are encrypted end-to-end are vulnerable only to
878	   denial of service. So, applications that require strong security are
879	   generally advised to end-to-end mechanisms such as IPsec or TLS.

881	   However, better route-optimization security may become necessary in
882	   the future, if improvements in other areas of Internet technology
883	   remove some of these plain IPv6 vulnerabilities. For instance, the
884	   use of Secure Neighbor Discovery [4] on the network where one of the
885	   endpoints resides removes some of the existing threats.

887	   Yet, a security association alone does not suffice as an enhanced
888	   security mechanism. General security associations typically do not
889	   show that a node owns a specific IP address, a property that is
890	   desired in the case of route optimization to authenticate home
891	   addresses. Certificate technology, for instance, usually does not
892	   track the correct IP-address assignments of a large group of users.
893	   Also, the validity of care-of addresses cannot be ensured by a
894	   security association alone. The security association must either be
895	   accompanied by a trust relationship, or care-of addresses must be
896	   checked otherwise. This shows that enhancements to the security of
897	   route optimization are likely to employ Mobile-IPv6-specific
898	   technology rather than general-purpose security tools.

900	4.4  Applicability Enhancements

902	   In Mobile IPv6, a mobile node's home address and current care-of
903	   address are carried in all route-optimized packets. The course of the
904	   mobile node may therefore easily be tracked by an observer. This can
905	   be an issue in situations where the mobile node prefers not to reveal
906	   its location. Location privacy, however, is inherently not supported
907	   by Mobile IPv6 route optimization. One solution is to fall back to
908	   bidirectional tunneling when location privacy is an issue. The path
909	   between the mobile node and its home agent can then be encrypted
910	   through IPsec ESP [16][17]. For full privacy protection the mobile
911	   node may have to re-establish its IPsec security associations,
912	   however, so that it cannot be tracked through its SPIs. On the path
913	   between the home agent and the correspondent node, all packets bear
914	   the mobile node's home address only. Hence, it is impossible for an
915	   outsider to realize when the mobile node is at home and when it is
916	   not.

918	5.  The Toolbox

920	   This section introduces a number of techniques (the "toolbox") that
921	   can be used in the construction of a route optimization protocol. The
922	   section starts with the basic techniques used in RFC 3775 and
923	   continues with additional techniques that have been proposed as
924	   enhancements or alternatives.

926	   It is important to note that many of the specific techniques are
927	   insufficient or insecure on their own, as they address just one
928	   aspect of the problem. It is the combination of a set of techniques
929	   that makes a secure and efficient route optimization mechanism
930	   possible. Different techniques also have different trade-offs with
931	   respect to, say, universal applicability versus efficiency.

933	5.1  Address Tests

935	   An address test can be employed to ensure that the peer is live and
936	   at least on the path to a specific destination address. RFC 3775 uses
937	   address tests for two purposes, for ensuring (weak) ownership of the
938	   home address, and for preventing flooding attacks related to spoofed
939	   care-of addresses.

941	   As specified in RFC 3775, such address tests can also be stateless
942	   for the correspondent node, making their use in denial-of-service
943	   attacks harder.

945	   The limitations of address tests relate to their security properties
946	   and the required number of messages. The security provided by an
947	   address test can only guarantee that the peer is on the path, not
948	   that the peer truly owns its address or other identifier. On the
949	   other hand, on-path attackers are in any case capable of performing
950	   the same type of attacks as would be possible by misuse of route
951	   optimization, so this does not present a significant new threat in
952	   the Internet.

954	   The use of two address tests requires four messages although it can
955	   usually be completed in one roundtrip by employing parallelism.

957	5.2  Protected Tunnels

959	   An additional technique used in RFC 3775 is the protection of a part
960	   of the signaling communications through an encrypted tunneled to the
961	   home agent. This prevents other nodes, close to the mobile node, from
962	   seeing the home address tests.

964	   Given the starting point that we can not assume a security
965	   association with the correspondent node, this protection exists only
966	   for the mobile node side; an attacker close to the correspondent node
967	   would be able to perform various attacks (similar to those that an
968	   attacker in that position would be able to do even in the non-mobile
969	   case). The use of security associations with correspondent nodes is
970	   discussed further in Section 5.11.

972	5.3  Optimistic Behaviour

974	   RFC 3775 leaves quite a bit of freedom for mobile nodes regarding
975	   when they initiate the different procedures, and when they start
976	   sending data packets. An optimistic mobile node can initiate the
977	   return routability procedure right after sending the Binding Update
978	   to the home agent, even before it has gotten an Acknowledgement back.

980	   Mobile nodes may also start sending data packets right after having
981	   sent the Binding Update to the correspondent node.

983	   The drawback of this behaviour is that a dropped, re-ordered, or
984	   rejected Binding Update can cause data packets to be dropped.

986	5.4  Proactive Tests

988	   One technique for reducing delay is to move some of the tasks from
989	   the critical path to an earlier stage. In particular,
990	   movement-related signaling that needs to complete before
991	   communications can resume is on the critical path.

993	   As discussed in [15] and [36], the home address test in standard
994	   Mobile IPv6 can be done "proactively". This eliminates the need to do
995	   a home address test after the movement.

997	   As described in Section 3, a mobile node must refresh an existing
998	   binding at least every seven minutes. Since a Home Keygen Token is
999	   generally valid for no longer than 3.5 minutes, the mobile node must
1000	   acquire a fresh Home Keygen Token prior to a binding refreshment. If
1001	   a mobile node seeks to have available a fresh Home Keygen Token at
1002	   all times it needs to initiate a proactive home-address test every
1003	   3.5 minutes even though it may not need to refresh its binding. Thus,
1004	   upon a handover, the mobile node has already a fresh Home Keygen
1005	   Token at hand when it arrives at the new link after handover.
1006	   (Alternatively, the mobile node may be able to receive a trigger from
1007	   its local link layer indicating that a handover is imminent. In this
1008	   case, the mobile node may initiate the home-address test right in
1009	   time instead of doing it periodically every 3.5 minutes.)

1011	   Another optimization possibility is performing a care-of address test
1012	   before the movement.  This is possible only if the mobile node is
1013	   capable of attaching to two networks simultaneously.

1015	5.5  Concurrent Tests

1017	   Assuming a proactive home test has been performed but a care-of test
1018	   has not, the mobile node cannot send a Binding Update immediately
1019	   after the handover because it is still missing a valid Care-of Keygen
1020	   Token for the new care-of address. On the other hand, the mobile node
1021	   already has the Home Keygen Token. Recall from Section 3 that the
1022	   Home Keygen Token authenticates the mobile node, through certifying
1023	   the mobile node's ownership of the home address. In the concurrent
1024	   test technique, the mobile node sends to the correspondent node an
1025	   Early Binding Update. This message is is similar to the Binding
1026	   Update used in standard Mobile IPv6 except that it is authenticated
1027	   with the Home Keygen Token only.

1029	   When the correspondent node receives the Early Binding Update, it can
1030	   be confident that the mobile node uses the correct home address,
1031	   because a valid Home Keygen Token was used to sign the message. On
1032	   the other hand, the message-authentication code does not bear a
1033	   Care-of Keygen Token, so the correspondent node cannot be sure
1034	   whether the mobile node is actually present at the claimed new
1035	   care-of address. The correspondent node thus registers the mobile
1036	   node's new care-of address, labeling it "unconfirmed" for the time
1037	   being.

1039	   The mobile node can use the new care-of address as soon as it has
1040	   dispatched the Early Binding Update. The mobile node then initiates a
1041	   care-of-address test. When it receives the Care-of Keygen Token, it
1042	   can send to the correspondent node a standard Binding Update. The
1043	   message-authentication code is produced with the new Care-of Keygen
1044	   Token and the Home Keygen Token from the proactive home-address test.
1045	   When the correspondent node receives the standard Binding Update
1046	   message, it can be confident that the mobile node uses the correct
1047	   home address, and that the mobile node is actually present at the new
1048	   care-of address. The correspondent node then changes the status of
1049	   the new care-of address from "unconfirmed" to "confirmed".

1051	   Due to the lack of care-of-address authentication in the Early
1052	   Binding Update message, there needs to be additional protection while
1053	   a mobile node's care-of address is unconfirmed. If no such protection
1054	   is provided, a malicious node may misuse Early Binding Updates to
1055	   register, as an unconfirmed care-of address, the IP address of a
1056	   third party. This implies a vulnerability to flooding attacks (c.f.
1057	   Section 2). Albeit the vulnerability is limited to a short period
1058	   after handover, there needs to be additional protection while a
1059	   mobile node's care-of address is unconfirmed. Heuristics could be
1060	   used, but are per definition reactive. Heuristics may also result in
1061	   false positives or, even worse, false negatives. (An enhancement to
1062	   concurrent tests that avoids these problems is discussed in Section
1063	   5.7.)

1065	   The concurrent tests avoid the delay that emanates from the home- and
1066	   care-of-address test by moving both tests to more suitable phases.
1067	   This saves one round-trip time between the mobile node and the
1068	   correspondent node, potentially through the home agent due to
1069	   bidirectional tunneling for the home-address test. A disadvantage,
1070	   however, is the increase in signaling that comes with the proactive
1071	   home-address test: Unless the mobile node cannot anticipate a
1072	   handover through link-layer triggers, the home-address test must be
1073	   performed roughly every 3.5 minutes instead of the minimum rate of
1074	   once every seven minutes prescribed by the Mobile IPv6 base
1075	   specification. ([5] describes an signaling-reduction technique that
1076	   can mitigate this impact when combined with Early Binding Updates.)

1078	5.6  Diverted Routing

1080	   Given that the per-movement signaling takes some time, mobile nodes
1081	   can optionally request their traffic to be routed through their home
1082	   address while this signaling is being completed.

1084	   The performance impact of this approach depends on the length of the
1085	   signaling period and the capacity and latency of the path through the
1086	   home agent. We can generally analyze the fate of the different parts
1087	   of the inbound payload traffic stream as follows:

1089	   Packets sent before movement is known

1091	      The correspondent node does not know the mobile node has moved
1092	      until it has been told about this. In addition, being able to tell
1093	      the correspondent node may itself involve some security-related
1094	      signalling. The packets sent before the movement is are going to
1095	      be lost, unless the mobile node is still connected also to its
1096	      previous attachment point or local repair techniques (see Section
1097	      5.15) are used.

1099	   Packets sent during the early part of signaling

1101	      Assuming that the route optimization signaling involves messages
1102	      through the home agent, it can be expected that at least the first
1103	      packets sent from the correspondent will make it to the mobile
1104	      node before the registration process is complete. This is because
1105	      they have to travel the same path.

1107	   Packets sent during the later part of signaling

1109	      The fate of the packets sent via the home agent close to the end
1110	      of the signaling period depends on the relative capacity and
1111	      latency of the home agent and direct paths. If former path has a
1112	      high latency, it might be better to queue the packets and wait for
1113	      the signalling to be completed.

1115	      One potential research direction is to look at whether the
1116	      properties of the paths could be learned during the signaling and
1117	      then used to decide the optimal time when the correspondent node
1118	      should start queueing packets.

1120	   The situation for the outbound traffic stream is similar, except that
1121	   the mobile node knows immediately that it has moved, and thus first
1122	   packets do not get lost.

1124	   This technique appeared originally in [36] and has since then be used
1125	   also in [13].

1127	5.7  Credit-Based Authorization

1129	   Credit-Based Authorization (CBA) [35] is a technique that allows a
1130	   correspondent node to already send packets to a new care-of address
1131	   while the care-of-address test is in progress. The mobile node
1132	   registers the new care-of address first, and it initiates the
1133	   care-of-address test thereafter. CBA ensures that the mobile node
1134	   still cannot wage an amplified flooding attack.

1136	   The attraction of a redirection-based flooding attack emanates from
1137	   its inherent potential for amplification. This is to say, the flooded
1138	   victim sees itself confronted with a much higher data load than the
1139	   attacker generates itself. The idea of CBA is that a correspondent
1140	   node, when requested by a mobile node to switch to an unconfirmed
1141	   care-of address, weighs the volume and rate of packets recently
1142	   received from the mobile node against the volume and rate of packet
1143	   that it sends to the mobile node's unconfirmed care-of address. Thus,
1144	   if an attacker decided to misuse an unconfirmed care-of address for
1145	   malicious redirection, it would not gain any amplification. Indeed,
1146	   it would take less coordinative effort, and be at least equally
1147	   effective, to send bogus packets to the victim directly.

1149	   With CBA, a correspondent node maintains a credit account for each
1150	   entry in its binding cache. When the correspondent receives a packet
1151	   from a mobile node, it increases the credit in that mobile node's
1152	   binding-cache entry by the size of the inbound packet. While the
1153	   binding-cache entry holds a confirmed care-of address, the credit
1154	   does not change when the correspondent node sends a packet that
1155	   care-of address. However, when the care-of address is unconfirmed,
1156	   the credit decreases by the size of each packet sent to that address.
1157	   If the credit would be decreased to a negative value for a particular
1158	   packet, that packet cannot be sent to the care-of address. With
1159	   Mobile IPv6 and concurrent tests, the correspondent node can send
1160	   such packets to the mobile node's home address. This is legitimate
1161	   because the home address has been proactively verified before. For
1162	   other protocols that do not provide an equivalent static IP address
1163	   through which a mobile node is reachable, such packets may either be
1164	   buffered for later transmission, or they may simply be discarded. HIP
1165	   [27] and Mobike belong to the latter protocol category, although, in
1166	   HIP, rendez-vous servers may theoretically be extended to provide
1167	   mobile nodes with static IP addresses for constant reachability.

1169	   The correspondent node exponentially ages existing credit, thereby
1170	   giving precedence to credit obtained recently. This guarantees that a
1171	   mobile node cannot collect credit over an extended time period at a
1172	   very slow speed and use this credit, all at once, for a short but
1173	   potent data burst towards a fraudulent unconfirmed care-of address.

1175	   It is believed that a fair-minded mobile node sends packets to the
1176	   correspondent node as part of its normal operation. Under many
1177	   circumstances, the mobile node should thus automatically earn credit
1178	   due to its normal behavior. Still, the proposal for CBA specifies an
1179	   alternative mode that better accommodates applications with
1180	   asymmetric traffic patterns such as file transfers and media
1181	   streaming. Those applications are characterized by high throughput
1182	   towards the client, typically the mobile node, and comparably little
1183	   throughput towards the serving correspondent node. In the second
1184	   mode, the correspondent node allocates credit for packets that it
1185	   sends to a confirmed care-of address of the mobile node, rather than
1186	   for packets that it receives. It is perspicuous that a mobile node,
1187	   as well as an attacker, invests comparable effort for data reception
1188	   as for transmission, in terms of bandwidth, memory, and processing
1189	   capacity. In-band care-of-address spot checks allow the correspondent
1190	   node to determine the approximate packet loss on the path towards the
1191	   mobile node, and to derive the mobile node's average reception rate.
1192	   An interesting property of the first version of CBA is that it does
1193	   not require support from a mobile node. A mobile node neither needs
1194	   to understand that CBA is effective at the correspondent node, nor
1195	   does it have to have an idea of how much credit it currently has. If
1196	   packet loss is not an issue, care-of-address spot checks may be
1197	   omitted so that the second version of CBA is transparent as well.

1199	5.8  Heuristic Monitoring

1201	   Heuristic approaches are conceivable as well. For instance, one may
1202	   consider a lifetime limit for unconfirmed care-of addresses which,
1203	   supplemented by a heuristic for misuse detection, can prevent, or at
1204	   least effectually discourage, misuse of such addresses. The challenge
1205	   here seems to be a feasible heuristic: On one hand, the heuristic
1206	   must be sufficiently rigid to catch any malicious intents at the
1207	   other side. On the other hand, however, it must not have a negative
1208	   impact on a fair-minded mobile node's communications.

1210	   Correspondent nodes could also track the behaviour of mobile nodes
1211	   over a longer period of time, and refuse communicating with them if
1212	   they misbehave. The problem with this approach is that attackers can
1213	   invent new addresses and other correspondent nodes to use in their
1214	   attacks.

1216	5.9  Cryptographically Generated Addresses

1218	   Public-key cryptography is a powerful mechanism for mutual
1219	   authentication between two nodes that do not know each other. Yet,
1220	   the key question with public-key cryptography is how the nodes can
1221	   trust in the respective other node's public key. How can an attacker
1222	   be stopped to spoof its identity and use a false public key? The crux
1223	   is that, generally, one cannot see from an identifier to which public
1224	   key it belongs. There may not even be a one-to-one relationship
1225	   between the identifier and the public key.

1227	   In today's Internet, the identity-key matching problem is solved
1228	   through certification authorities that have a reputation to be
1229	   trustworthy. Nodes that want to mutually authenticate send each other
1230	   their identities and public keys. Each node can then contact a
1231	   trusted certification authority and have it verify whether the two
1232	   parameters match. Once a node knows that its peer's public key is
1233	   correct, it can verify whether the peer actually knows the right
1234	   private key by decrypting the encrypted version of a certain piece of
1235	   data.

1237	   This mechanism has two disadvantages: First, it relies on the trusted
1238	   certification authorities. If the certification authorities fail or
1239	   are target of an attack, public-key cryptography is seriously
1240	   compromised. Second, authorities usually delegate certain requests to
1241	   other authorities. So, going through the authentication process can
1242	   be time and resource consuming for the querier.

1244	   These two drawbacks made public-key cryptography little attractive
1245	   for Mobile IPv6. On the other hand, the described mechanism was
1246	   designed to authenticate arbitrary transactions. This level of
1247	   generality is actually not needed for mobility support. For example,
1248	   a proof of home-address ownership would be sufficient in Mobile IPv6.
1249	   This is where Cryptographically Generated Addresses (CGA) is helpful
1250	   [8].

1252	   A CGA is an IPv6 address, which contains a set of bits generated by
1253	   hashing the IPv6 address owner's public key. Such feature allows the
1254	   user to proof that it is the legitimate owner of the its IPv6
1255	   address.

1257	   The CGA offers three main advantages: First, it makes the spoofing
1258	   attack against the IPv6 address much harder. Second, it allows to
1259	   sign messages with the owner's private key. Third, CGA does not
1260	   require any upgrade or modification in the infrastructure.

1262	   The CGA offers a method for binding a public key to an IPv6 address.
1263	   The binding between the public key and the CGA can be verified by
1264	   re-computing and comparing the hash value of the public key and other
1265	   parameters with the interface identifier from the owner's IPv6
1266	   address. Both the public and the additional parameters are sent with
1267	   the message that requires authentication. Note that an attacker can
1268	   always create its own CGA address but he will not be able to spoof
1269	   someone else's address since he needs to sign the message with the
1270	   corresponding private key, which is supposed to be known only by the
1271	   real owner.

1273	   The CGA technique was originally described in [28] and in [31], and
1274	   it has later been used in [32], [8], and [13], among others.

1276	5.10  Semi-Permanent Security Associations

1278	   In the above techniques each movement involves a new, complete round
1279	   of signaling. In the semi-permanent security association technique a
1280	   key is established upon first contact, and then this key is later
1281	   used in movements later, making the signaling efficient and secure.
1282	   The primary security benefit of this approach is that the subsequent
1283	   communications can be securely bound to the initial contact.

1285	   Another way to look at this technique is that a key is created for a
1286	   specific purpose or resource, and that all requests relating to that
1287	   resource have to be authenticated by the same key.

1289	   This technique works well in applications where the secured resource
1290	   can be identified by the key. For instance, in HIP [27],
1291	   opportunistic security can be achieved through binding all
1292	   communications to the public keys generated by the participants.

1294	   This technique is less secure when the resource is identified by some
1295	   other means. For instance, if solely this technique is used for route
1296	   optimization security in Mobile IPv6, there is nothing that prevents
1297	   a malicious node from grabbing someone else's address and claiming
1298	   that all subsequent signaling related to that address has to be
1299	   authenticated through the attacker's public key. As a result, this
1300	   technique is typically applied together with some other means to
1301	   ensure the ownership of the resource, such as CGA as was done in
1302	   [13].

1304	   Semi-permanent security associations were first developed in [10]
1305	   where they were called Purpose Built Keys (PBKs). They have since
1306	   then been applied in [12] and [13].

1308	5.11  Pre-Configuration

1310	   The currently standardized route optimization method is based on the
1311	   assumption that no security association or configuration can be
1312	   expected between mobile and correspondent nodes either directly or
1313	   via an infrastructure. However, in situations where such
1314	   configuration is possible, efficiency and security improvements
1315	   become possible.

1317	   Perhaps the simplest route optimization security mechanism is the use
1318	   of a shared secret between the mobile and correspondent nodes, as
1319	   defined in [26].

1321	5.12  Infrastructure

1323	   Infrastructure can provide assistance by vouching for the correctness
1324	   of the home address, correctness of the care-of address, or the
1325	   trustworthiness of the mobile node.

1327	   This infrastructure can take many forms, such as a PKI tailored for
1328	   for the route optimization problem or AAA enhanced with the required
1329	   features.

1331	   In its basic form, the infrastructure hands out home addresses and
1332	   associates some keys with these addresses. It could produce
1333	   certificates that could be used by others to verify the binding of
1334	   the used key to the right home address, or it could provide a query
1335	   interface where this verification is performed within the
1336	   infrastructure.

1338	   Setting up such infrastructure has generally been considered
1339	   impossible for general Internet use. One of the problems is the
1340	   current separation of address assignment and security
1341	   infrastructures.  However, [9] suggests a useful simplification: only
1342	   home agents need to be assigned such prefix-based certificates, as
1343	   they can vouch for their own mobile nodes. This makes the
1344	   infrastructure problem more tractable.

1346	   The infrastructure could also just identify the trustworthy mobile
1347	   nodes. Together with an identifier for each mobile node, this could
1348	   be used to retroactively track down misbehaving nodes.

1350	   The use of infrastructure for care-of address verification could be
1351	   based on the querying local network access system about the existence
1352	   of a node at a claimed address. The mobile node would be identified
1353	   by some means (such as a public key) known both to the correspondent
1354	   node and the AAA network. The problem with this is that a global AAA
1355	   system would have to be provided in order for a correspondent node to
1356	   find out whether a mobile node connecting to it from the other side
1357	   of the world is legitimate.

1359	5.13  Cryptographically Bound Identifiers

1361	   The primary problem in route optimization is to ensure that the home
1362	   address is owned by the node that claims it. While the Mobile IPv6
1363	   architecture can not easily be changed with respect to the use of the
1364	   home address as an identifier, other protocols have avoided some of
1365	   these problems through the use of a cryptographic identifier.  For
1366	   instance, in HIP [27] a cryptographic identity is the primary
1367	   identifier that binds all communications and upper layer protocols to
1368	   the lower-level signaling exchanges. In HIP this identifier is a
1369	   public key compressed to a 128-bit value through a hash function. The
1370	   use of this type of identifiers avoids the home address ownership
1371	   problem, but it is still necessary to verify the correctness of
1372	   care-of addresses to avoid flooding attacks.

1374	5.14  Local Mobility

1376	   Local mobility can be provided via protocols such as Hierarchical
1377	   Mobile IPv6 [33]. Local mobility supplements the end-to-end mobility
1378	   support of standard Mobile IPv6. It brings performance improvements
1379	   in terms of signaling overhead and handover latency. Hierarchical
1380	   Mobile IPv6 introduces the concept of a regional Mobile Anchor Point
1381	   (MAP). A MAP acts as a local home agent towards a visiting mobile
1382	   node, and it proxies the mobile node towards the mobile node's home
1383	   agent and correspondent nodes. Typically, a MAP serves multiple
1384	   access networks, which are together referred to as the MAP's domain.
1385	   Access routers in the MAP domain distribute the MAP's IP address in
1386	   Router Advertisement extensions. The MAP is a router at a preferably
1387	   central position within its domain.

1389	   When a mobile node enters a visited network, it configures an
1390	   "on-link care-of address" with the local network prefix through
1391	   standard IPv6 Address Autoconfiguration. The mobile node may also
1392	   configure a wider-scope "regional care-of address" with the MAP's
1393	   network prefix and register the on-link and regional care-of
1394	   addresses with the MAP. The MAP treats a mobile node's regional
1395	   care-of address as a home agent treats the mobile node's home
1396	   address. In particular, it performs Duplicate Address Detection for
1397	   the regional care-of address. A bidirectional tunnel is established
1398	   between the MAP and the mobile node.

1400	   The mobile node registers the regional care-of address with its home
1401	   agent and correspondent nodes. The MAP is prepared to intercept
1402	   packets addressed the regional care-of address. It tunnels these
1403	   packets to the mobile node's on-link care-of address. Vice versa, the
1404	   mobile node may--or may have to if administratively prescribed in the
1405	   access network--tunnel outbound packets to the MAP, which in turn
1406	   decapsulates these packets and forwards them on to the recipient.
1407	   When the mobile node moves to a different network within the same MAP
1408	   domain, it updates the binding at the MAP, but it can leave the
1409	   existing bindings at its home agent and correspondent nodes in place.

1411	5.15  Local Repair

1413	   A local repair technique involves reducing the ill effects of a
1414	   movement, such as the ability to redirect packets received at a
1415	   previous location to the new location.

1417	   Fast Handovers for Mobile IPv6 [18] is one such optimization. It
1418	   provides support from the access network that assists a mobile node
1419	   during handover. Fast Handovers packages three functions: proxy
1420	   router discovery, proactive IPv6 address configuration and proxy
1421	   neighbor discovery, and provision against packet loss during
1422	   handover.

1424	   When a mobile node recognizes that a handover to a new access point
1425	   is imminent--for instance, through a trigger from its local link
1426	   layer--the mobile node can inquire of its current, old access router
1427	   about a router attached to the detected new access point. For this,
1428	   the mobile node sends a Router Solicitation for Proxy Advertisement
1429	   to the old access router along with the MAC address of the new access
1430	   point. Access routers are configured with tables matching near-by
1431	   access points' MAC addresses to information about attached access
1432	   routers. When the old access router hears a Router Solicitation for
1433	   Proxy Advertisement, it looks up its table for an access router on
1434	   the prospective new link, and it sends a Proxy Router Advertisement
1435	   on behalf of that router.

1437	   With the Proxy Router Advertisement at hand, the mobile node can
1438	   configure a care-of address for the new link, even though it is still
1439	   connected to the old link. Preferably right before handover, the
1440	   mobile node signals the new care-of address to its old access router.
1441	   The old access router verifies the new care-of address with the new
1442	   access router and sends to the mobile node an acknowledgement
1443	   indicating the result. If the suggested care-of address is
1444	   acceptable, the new access router starts proxying the address.
1445	   Otherwise, it signals an alternate care-of address to the old access
1446	   router which, in turn, includes that address in its acknowledgement.

1448	   Packets for the mobile node may still arrive at the old care-of
1449	   address after the mobile node has switched to the new link. The old
1450	   access router tunnels those packets to the mobile node's new care-of
1451	   address.

1453	   There are two exceptions that are worthwhile mentioning. During proxy
1454	   router discovery, the old access router may not be configured with
1455	   information about an appropriate new access router. No proxy router
1456	   discovery can then be provided. Nonetheless may the mobile node
1457	   request the old access router, from the new link, to forward any
1458	   packets that subsequently arrive at the old care-of address.
1459	   Furthermore, during proactive IPv6 address configuration, it may turn
1460	   out that the mobile node's suggested care-of address is unacceptable,
1461	   and the mobile node may no longer be at the old link when the old
1462	   access router sends the acknowledgement with the alternate care-of
1463	   address. In this case, the mobile node fails when attempting to
1464	   connect to the new network with the unacceptable care-of address. The
1465	   new access router may then install a host route for the old care-of
1466	   address and set up a bidirectional tunnel with the old access router
1467	   between the old and new care-of addresses. (Note that outbound
1468	   tunneling is necessary to ensure topological correctness of the
1469	   packets' IPv6 source addresses.) Thus, the mobile node may continue
1470	   to use its old care-of address at the new link until it has
1471	   successfully configured a new care-of address through standard IPv6
1472	   Address Autoconfiguration.

1474	   In a non-optimized environment, standard router discovery and IPv6
1475	   Address Autoconfiguration can cause substantial disruption to ongoing
1476	   communications during a handover. With Fast Handovers, a mobile node
1477	   can accomplish these tasks proactively before the handover. Moreover,
1478	   the mobile node's communication peers typically continue to use an
1479	   outdated care-of address for some time after a handover due to the
1480	   natural latency of global Mobile IPv6 signaling. In a standard
1481	   setting, packets sent to a stale care-of address are typically
1482	   dropped. Fast Handovers salvage these packets by means of the
1483	   tunneling service from the old to the new access router. This enables
1484	   lossless handovers.

1486	   Fast Handovers can nicely be integrated with Hierarchical Mobile IPv6
1487	   [33]. The mobile node then registers a prospective new care-of
1488	   address directly through the MAP, rather than through the old access
1489	   router, for efficiency reasons. The forwarding service for packets
1490	   sent to an outdated care-of address is also provided by the MAP.

1492	5.16  Processing Improvements

1494	   Processing power is in general not as significant issue in route
1495	   optimization as the amount of signaling and latency. However, this
1496	   can still be an issue for busy servers or proposals that are based on
1497	   public key operations. For these cases, new types of cryptographic
1498	   algorithms (such as ECC instead of RSA) might provide some
1499	   assistance.

1501	5.17  Delegation

1503	   Given that the home agent does not need to move or conserve battery
1504	   energy, it can be used for performing computationally expensive
1505	   tasks. It can also be used for parts of the signaling, to reduce
1506	   communications over slow wireless links.

1508	   Some work relating to delegation has been done in [32] and [9].

1510	6.  Analysis

1512	   This section analyzes the previously presented techniques in relation
1513	   to each other and the enhancement objectives. We start by looking at
1514	   how the techniques can be categorized, continue by studying a number
1515	   of proposals that apply a number of techniques to reach a goal, and
1516	   conclude with some subjects for further research in this area.

1518	6.1  Categorization of Techniques

1520	   Local techniques require support from the access network that the
1521	   mobile node is attached to. HMIP and FMIP are examples of local
1522	   techniques. They can significantly mitigate the disruptive impact
1523	   that movements have on ongoing communications.  Yet, they require
1524	   investments at the access network and thus imply additional costs for
1525	   the network operator. Also, local optimizations are ineffective for
1526	   handovers across administrative domains unless providers have mutual
1527	   agreements to interconnect their networks.

1529	   End-to-end techniques do without the need infrastructure in the
1530	   access network. They also work across administrative domains. On the
1531	   other hand, end-to-end approaches cannot leverage the short distances
1532	   to local network entities, but have to cope with global, thus
1533	   potentially long, round-trip times. Hence, end-to-end techniques
1534	   cannot usually catch up with the high performance gains that are
1535	   characteristical for local optimizations.

1537	   Zero-configuration techniques require no preconfiguration or
1538	   assistance from a managed infrastructure. Address tests, proactive
1539	   tests, concurrent tests, diverted routing, credit-based schemes,
1540	   monitoring, CGA, semi-permanent, cryptographically bound identifiers,
1541	   processing improvements, and delegation are zero-configuration
1542	   techniques.

1544	   Pre-configuration and infrastructure-based methods are not
1545	   zero-configuration techniques.

1547	   Local techniques have traditionally been implemented in a manner that
1548	   requires configuration, but there appears to be no fundamental reason
1549	   why this would have to be so.

1551	6.2  Evaluation of Some Proposals

1553	6.2.1  Local Assistance

1555	   IETF's two current protocols for localized assistance to mobile nodes
1556	   have been described in Section 5.14 and Section 5.15.

1558	   Hierarchical Mobile IPv6 (HMIPv6) screens a mobile node's movements
1559	   within a MAP domain from nodes not inside that domain. In case
1560	   standard Mobile IPv6 is used end-to-end, this eliminates most of the
1561	   global signaling: While its regional care-of address does not change,
1562	   a mobile node does not need to update its home agent or correspondent
1563	   nodes beyond the mandatory periodic refreshments. Not having to
1564	   signal on a global basis also reduces handover latency.

1566	   Updates to the home agent and to correspondent nodes are necessary
1567	   only when the mobile node leaves the current MAP domain. The mobile
1568	   node may then register a new regional care-of address with a
1569	   different MAP if one is available. Note that switching MAPs usually
1570	   requires the mobile node to signal more than if standard Mobile IPv6
1571	   was used alone. Local and end-to-end signaling then comes together
1572	   because, as it stands, a mobile node must contact the new MAP
1573	   seperately from its home agent and correspondent nodes. Due to
1574	   dependencies between a MAP registration and a contemporary home or
1575	   correspondent registration, a mobile node may want to wait for the
1576	   MAP registration to complete before it initiates the standard Mobile
1577	   IPv6 registration procedure. Handover latency is then increased in
1578	   addition to the signaling overhead. Future work should thus go into
1579	   the integration of MAP registrations with standard Mobile IPv6
1580	   signaling.

1582	   Another interesting research opportunity seems to be a mechanism that
1583	   tells neighboring MAPs from different administrative sites that their
1584	   domains overlap. The MAPs could then mutually advertise each other
1585	   throughout certain parts of their domains.

1587	   The cost for an inter-MAP handover in terms of signaling load and
1588	   delay strongly depends on the network topology. In an optimal layout,
1589	   a MAP is located somewhere on the path from the mobile node to its
1590	   home agent and correspondent nodes. This may be the case if the MAP
1591	   is co-located with an Internet gateway. Then, switching MAPs is
1592	   cheap. On the other hand, if the MAP is way off the direct path
1593	   between a mobile node and its peers, the additional overhead might
1594	   become noticeable. Indeed, a good topological layout is crucial for
1595	   the performance of HMIPv6.

1597	   Fast Handovers for Mobile IPv6 (FMIPv6) streamlines the
1598	   router-discovery and IPv6-address-configuration processes, and it
1599	   facilitates lossless handovers. FMIPv6 assumes that access routers
1600	   are capable of matching a neighboring access point to the access
1601	   router to which it attaches. The capability is a prerequisite for
1602	   proxy router discovery. Yet, it is still an open issue how access
1603	   routers learn about this information. Manual configuration is one
1604	   option, though it can be extremely expensive. More attractive would
1605	   be an automated mechanism that allows access routers to dynamically
1606	   recognize access points to which mobile nodes may want to switch. A
1607	   related issue is how such knowledge can be securely obtained across
1608	   the borders of administrative sites. These are opportunities for
1609	   future research.

1611	   Note that Hierarchical Mobile IPv6 may be used even when the no
1612	   Mobile IPv6 is used beyond the local domain. I.e., a mobile node may
1613	   use its regional care-of address as a temporary home address. The
1614	   mobile node would thus appear to a correspondent node as a stationary
1615	   node in the MAP's network. The same is true for a combination between
1616	   HMIPv6 and FMIPv6, but FMIPv6 alone cannot be used without standard
1617	   Mobile IPv6. It should also be mentioned that HMIPv6 provides
1618	   location privacy for mobile nodes as long as the mobile nodes do not
1619	   move across MAP domains. In fact, a mobile node appears to parties
1620	   outside its current MAP domain as a stationary host located in the
1621	   MAP's network because it does not advertise its link-local addresses
1622	   to those nodes.

1624	   Of course, there are disadvantages with HMIPv6 and FMIPv6. Local
1625	   optimizations in general require investments in the access network
1626	   and thus imply additional costs for the network operator. Also, as
1627	   mentioned, localized mobility support may even cause increased
1628	   overhead in certain situations. And local mechanisms are to date
1629	   ineffective for handovers across administrative domains unless
1630	   providers have mutual agreements to interconnect their networks.

1632	6.2.2  Preconfigured Secret Method

1634	   It has been explained in section Section 3 that the
1635	   return-routability procedure serves two purposes: The home-address
1636	   test allows the nodes to authenticate mobility-related signaling, and
1637	   the care-of-address test is needed to verify a mobile node's
1638	   reachability. Preconfigured shared secrets allow nodes to
1639	   authenticate without the home-address test. But without further
1640	   assumptions, preconfiguration cannot streamline the care-of-address
1641	   verification process.

1643	   The Home Keygen Token exchange from the return-routability procedure
1644	   is the default authentication technique used in Mobile IPv6. It
1645	   facilitates reasonable security even for nodes that have no
1646	   pre-existing relationship. On the other hand, nodes that do share a
1647	   common secret should be allowed to omit the home-address test. This
1648	   can be beneficial in certain scenarios where the home-address test
1649	   causes a long handover latency due to packet redirection through the
1650	   home agent.

1652	   On the other hand, the latency improvement can be much higher if not
1653	   only the Home Keygen Token exchange, but also the Care-of Keygen
1654	   Token exchange is ignored. Eliminating the latter, however, requires
1655	   some sort of trust into mobile nodes not to spoof a care-of address.
1656	   In fact, [26], a method being standardized by the IETF MIP6 Working
1657	   Group, is based on this trust model.

1659	   The assumption that mobile nodes be fair-minded turns out to be quite
1660	   far stretching. On on side, it affords the elimination of the entire
1661	   return-routability procedure, not just the Home Keygen Token
1662	   exchange. As explained in [26], and can also be inferred from figure
1663	   Figure 1, this can cut handover latency in half. On the other hand,
1664	   the assumption significantly limits the applicability of the
1665	   optimization. There are certainly scenarios where preconfiguration
1666	   per se would be possible, but no trust model can be assumed. For
1667	   instance, an ISP may configure its media servers with the keys of its
1668	   customers. The customers could then use their keys and Mobile IPv6
1669	   for communications with the media servers, but some customers might
1670	   misuse the lack of a care-of-address test to wage a
1671	   re-direction-based flooding attack against an arbitrary IP host. This
1672	   example reveals the difference between a security association for
1673	   authentication and a trust relationship for misuse prevention.

1675	   In an effort to extend preconfiguration to scenarios where no trust
1676	   relationship can be presupposed, one may combine it with
1677	   care-of-address tests. Of course, the care-of-address test would
1678	   partly vitiate the handover-latency improvement that preconfigured
1679	   keys brings without the care-of-address test. But handover latency
1680	   may still improve over the standard return-routability procedure
1681	   because a care-of-address test is usually faster than a complete
1682	   return-routability procedure. (This is because the complete
1683	   return-routability procedure includes a home-address test, which is
1684	   usually more expensive than the care-of-address test because it is
1685	   directed through a home agent.) Also pre-authentication facilitates
1686	   stronger authentication mechanisms and thus the use of route
1687	   optimization for applications that would otherwise opt for
1688	   bidirectional tunneling due to security concerns.

1690	   Moreover, preconfiguration can be used along with a combination of a
1691	   concurrent care-of-address test and credit-based authorization or
1692	   heuristic monitoring. This approach eliminates the home-address test
1693	   and makes the care-of-address test transparent to applications. It
1694	   also keeps the possibility to use an alternative authentication
1695	   mechanism.

1697	   These things said, it seems like a good idea to make the
1698	   preconfiguration protocol bendable to different environments. Is
1699	   there a small group of people who trust each other? Then, of course,
1700	   group members are unlikely to spoof care-of addresses, and we can go
1701	   without the care-of-address test. Or are we talking about the
1702	   customer base of a big ISP? Then, proper authentication does usually
1703	   not imply trust, and it may not be feasible to use preconfigured keys
1704	   without checking a mobile node's reachability. Tracability techniques
1705	   are not a compensation for the missing care-of-address test, because
1706	   they are a reactive measure, whereas a care-of-address test is a
1707	   proactive one.

1709	   Specifically, the integration of key preconfiguration with
1710	   care-of-address test could be done as follows. In case the
1711	   care-of-address test is deemed necessary, a preconfigured 64-bit key
1712	   can substitute the Home Keygen Token. The Home Keygen Token may also
1713	   be derived in some defined way from the preconfigured key. Either
1714	   way, signaling messages can then be authenticated in the same way as
1715	   defined in the Mobile IPv6 specification. This amendment to [26]
1716	   helps to broaden the scope of key preconfiguration to environments
1717	   where end-hosts have administrative relationships with each other,
1718	   but do not necessarily trust each other.

1720	6.2.3  CGA-Based Optimizations

1722	   CGA assures that a mobile node is the legitimate owner of its home
1723	   address. As far as the correctness of home addresses go, CGA provides
1724	   more assurance than the pure use of routing paths. This makes it
1725	   possible to have a significant decrease in the signaling frequency.
1726	   In addition, the public keys used in the CGA technique allow certain
1727	   data to be communicated privately between the nodes, which makes some
1728	   of our other techniques possible.

1730	   GA could also be used to reduce the risk of flooding attacks via
1731	   care-of addresses, as attackers would be unable to manufacture victim
1732	   addresses for a specific host. However, only the interface-identifier
1733	   part of an IPv6 address is cryptographically generated, so flooding a
1734	   network or a link is still an issue. As a result, CGA needs to be
1735	   employed together with a reachability test in scenarios where
1736	   redirection-based flooding attacks are a concern. An interesting
1737	   future path for research would be to consider the combination of
1738	   concurrent care-of-address tests together with CGA-based care-of
1739	   addresses.

1741	   CGA is typically used to assure the correctness of the home address
1742	   that the mobile node claims to own, and combined together with other
1743	   techniques to prevent flooding attacks. Note that this implies that
1744	   an initial home address test is typically required too in order to
1745	   avoid the deletion of a binding to flood an unconfirmed home address.

1747	   The crux with using cryptographically generated care-of addresses is
1748	   address collisions: A given public key hashes to exactly one value.
1749	   CGA uses modifiers in the case of collisions. But as such modifiers
1750	   weaken the cryptographic strength of CGAs, only a few (usually four)
1751	   modifiers are allowed.

1753	6.2.4  CBA-Based Latency Reduction

1755	   As shown in Section 2, the ability to change a packet flows
1756	   destination IP address can potentially be misused for a malicious
1757	   redirection-based flooding attack. Mobile IPv6 and similar
1758	   mobility-management protocols like Host Identity Protocol (HIP) [27]
1759	   and current Mobike proposals solve this issue by probing a new IP
1760	   address before that IP address is used as a destination for payload
1761	   packets. Unfortunately, by definition, IP-address probing cannot be
1762	   done in a proactive style. After all, a handover involving an
1763	   IP-address change invalidates any previous probes.

1765	   Instead, a new care-of address may be probed while packets are
1766	   already flowing to that care-of address. This concept of concurrent
1767	   care-of-address tests was first mentioned in [36]. CBA was added to
1768	   secure the time phase during which a mobile node's reachability at
1769	   the new care-of address is not yet verified, but the new care-of
1770	   address is already in use. After all, this time phase could otherwise
1771	   introduce a susceptibility to malicious redirection, if but for an
1772	   albeit short time.

1774	   As shown in Section 2, the attraction to redirection-based flooding
1775	   attacks is its potential for easy-to-get amplification. Note that CBA
1776	   does not prevent an attacker from spoofing its care-of address. But
1777	   the attacker will not be able to wage an amplified flooding attack.
1778	   More specifically, the amount of data that can be redirected to an
1779	   unconfirmed care-of address is sufficient for a fair-minded mobile
1780	   node to continue communications during the care-of-address test, but
1781	   it is far from satisfactory for an attacker planning denial of
1782	   service.

1784	   The challenge with CBA is how much data the correspondent node may
1785	   exactly send to a care-of address while it is unconfirmed. If it
1786	   sends too much, an attacker could take advantage of this. If it sends
1787	   to little, a fair-minded mobile node might suffer performance
1788	   degradations during the handover phase. As shown in Section 5.7,
1789	   there are two modes for Credit-Based Authorization. In the first
1790	   mode, the correspondent node weighs the data volume that it has
1791	   recently received from a mobile node with the data volume that it may
1792	   maximally send to an unconfirmed care-of address of that mobile node.
1793	   This is the most straightforward way to make redirection-based
1794	   flooding attacks comparable to direct flooding attacks, which are,
1795	   after all, already possible and easy to perform in today's non-mobile
1796	   Internet. The second mode takes the data volume a mobile node has
1797	   recently received at a confirmed care-of address as a limit on how
1798	   much data the mobile node can receive after handover to a new,
1799	   unconfirmed care-of address. This second mode gives away some of the
1800	   first mode's straightforwardness in exchange for a better support for
1801	   applications with asymmetric data throughput. This was deemed
1802	   necessary in consideration of applications like media streaming,
1803	   television broadcasts, and file transfers, where the mobile node
1804	   typically receives multiple orders of magnitude more data than it
1805	   sends.

1807	   One should evaluate whether the second mode of Credit-Based
1808	   Authorization could be misused by an attacker that has an asymmetric
1809	   connection to the Internet. Wide-spread digital subscriber lines
1810	   (DSL) usually have a much higher download rate than upload rate. The
1811	   limited upload rate would render most denial-of-service attempts
1812	   through direct flooding meaningless. But the strong download rate
1813	   could be misused to illegitimately build up credit at one or many
1814	   correspondent nodes. The credit could then be used for a more potent,
1815	   redirection-based flooding attack.

1817	   It turns out that this issue is less serious than it may seem at
1818	   first glance. The reason is that, in order to build up enough credit
1819	   at the remote end, the attacker would initially have to expose itself
1820	   to exactly the same packet flood that it could then redirect towards
1821	   the victim. Note that this is true for both data volume and data
1822	   rate: While data volume directly affects how much credit the
1823	   correspondent node allocates, the data rate is indirectly taken into
1824	   account through credit aging.

1826	   The second CBA mode requires some sort of feedback for the
1827	   correspondent node about how many packets that the correspondent node
1828	   sends to a mobile node actually make it all the way to that mobile
1829	   node. As mentioned in  Section 5.7, care-of-address spot checks
1830	   provide this feedback. But they require more significant
1831	   modifications to the Mobile IPv6 base specification than the first
1832	   mode of CBA does. Moreover, while the first mode operates completely
1833	   transparent to the mobile node, the second obviously does not.

1835	   CBA uses exponential aging to gradually reduce credit that has been
1836	   earned in the past. This way, an attacker is prevented to collect
1837	   credit over a long time interval and use this credit, all at once,
1838	   for a short but potent data burst towards a victim. Care must be
1839	   taken to set the aging factor to an appropriate value.

1841	   Finally, one should mention that CBA-based concurrent care-of-address
1842	   tests can be used to improve other mobility-management protocols that
1843	   verify a new IP address through probing. This includes HIP and
1844	   certain Mobike proposals. Also, CBA-based concurrent care-of-address
1845	   tests can be integrated into other Mobile IPv6 optimization
1846	   techniques described in this document. Approaches that may benefit
1847	   are, for example, CGA-based ones (cf. Section 6.2.3) as well as those
1848	   that use shared-secret preconfiguration (cf. Section 6.2.2). Last,
1849	   but not least, in scenarios where a home agent cannot trust in the
1850	   correctness of the registered mobile nodes' care-of addresses,
1851	   CBA-based concurrent care-of-address tests could be proscribed even
1852	   for home registrations. The same is true for Hierarchical Mobile
1853	   IPv6, which, as it stands, assumes a MAP can be confident that mobile
1854	   nodes use correct on-link care-of addresses, and so gets around the
1855	   care-of-address test.

1857	6.2.5  Prefix-Based Certificates

1859	   The Mobile IPv6 base specification avoids strong authentication
1860	   cryptography for signaling between mobile nodes and correspondent
1861	   nodes. One reason for this is the impracticality of a global trusted
1862	   PKI that could approve bindings between the mobile nodes' identities
1863	   and public keys. Another reason is that limited power resources and
1864	   processing capacity at the mobile nodes generally rule out any
1865	   complex cryptographic operations. Robustness to resource-exhaustion
1866	   attacks requires a similar restrictiveness on the correspondent-node
1867	   side.

1869	   [9] suggest promoting the home agent to a security proxy operating on
1870	   behalf of its mobile nodes. Correspondent nodes can trust a home
1871	   agent based on a certificate that binds the home-network prefix to
1872	   the public key of the home agent. The home agent, in turn, vouches
1873	   for the correctness of its mobile nodes' home addresses. This
1874	   approach is called Certificate-based Binding Update (CBU).

1876	   CBU circumvents the lack of a global PKI in an elegant way. Rather
1877	   than having to issue a certificate per mobile node, only a
1878	   certificate per home-network prefix is required. This reduction in
1879	   complexity makes certificate-based approaches to mobile-node
1880	   authentication more feasible than it is today. The approach also
1881	   avoids heavy computations at mobile nodes since all such computations
1882	   are performed by the home agent. This mitigates the issue with
1883	   resource limitations at mobile nodes.

1885	   As a side effect, once the end-to-end security association between a
1886	   mobile node and a correspondent node has been created, CBU allows for
1887	   improved signaling delay during all subsequent handovers.

1889	   On the other hand, it should be mentioned that the processing
1890	   overhead at correspondent nodes actually increases compared to
1891	   standard correspondent registrations. This may not be an issue since
1892	   resources at stationary correspondent nodes are usually higher than
1893	   those of many mobile devices, and home agents would do the
1894	   cryptographic operations for mobile correspondent nodes.
1895	   Correspondent nodes should hence be provided with sufficient
1896	   resources, at least where the correspondent node is not a popular web
1897	   server or other central resource. One should, however, bear in mind
1898	   that the increased overhand implies a higher risk to
1899	   resource-exhaustion attacks.

1901	   The identity of a mobile node may in certain scenarios also be
1902	   verifiable through an AAA infrastructure. A home AAA server, which
1903	   may or may not be co-located with the home agent, can then contact a
1904	   remote AAA server in the correspondent node's network. Note that this
1905	   moves some of the authentication overhead from the correspondent node
1906	   to the remote AAA server. An AAA-based approach can also dynamically
1907	   assign mobile-node requests to different correspondent nodes while
1908	   keeping secret authenticating material local at a single AAA server.

1910	   There is ongoing work on the integration of AAA with Mobile IPv6
1911	   [30]. The current focus is on authentication between mobile nodes and
1912	   home agents. The proposal is thus a replacement for the IPsec-based
1913	   authentication protocol for home registrations. But the concept of
1914	   security proxies presented in [9] may as well be re-used for
1915	   enhancements to the AAA infrastructure.

1917	   CBU does not solve the issue with care-of-address spoofing: A
1918	   vouching home agent does not prevent a malicious mobile node from
1919	   faking its care-of address. The culprit could cheat its home agent,
1920	   or it could cooperate with it. This said, CBU should be combined with
1921	   a care-of-address test that rules out redirection-based flooding
1922	   attacks. A combination of concurrent care-of-address tests and CBA
1923	   (cf. Section 5.7) can be used to keep the signaling delay during
1924	   handover as low as it currently is in [9].

1926	6.3  Further Research

1928	   Mobility-related optimizations are currently actively studied by many
1929	   researchers, looking at a number of different protocol layers. The
1930	   preceding section also identifies some worthwhile amendments to the
1931	   existing proposals that require further work. While some of the basic
1932	   methods for route optimization are fairly well understood and are
1933	   being deployed, there are a number of interesting, newer approaches
1934	   that deserve to be studied in more detail. This section discusses
1935	   some research directions that appear fruitful, or necessary in the
1936	   future, and that go beyond the existing proposals described so far.

1938	6.3.1  Related Research in Other Protocol Layers

1940	   The efficiency, security, and other functionality related to
1941	   movements is not dependent only on Mobile IPv6 route optimization
1942	   (even if researchers often pose their analysis in that light).  A
1943	   movement that is visible at the IP layer involves all lower layers as
1944	   well; this includes layer 2 attachment procedures, layer 2 security
1945	   mechanism negotiation, authentication and key agreement, IP router
1946	   and neighbor discovery, address autoconfiguration, duplicate address
1947	   detection and so forth. A complete network attachment typically
1948	   requires over twenty link and IP layer messages, assuming features
1949	   necessary for a commercial deployment (such as security) are turned
1950	   on.

1952	   A significant research question is the overall performance of the
1953	   network access stack as a whole. Current protocol stacks have a
1954	   number of limitations in addition to the long attachment delays [1],
1955	   such as denial-of-service vulnerabilities, difficulties in trusting a
1956	   set of access nodes distributed to physically insecure locations,
1957	   inability to get enough information for a handoff decision, and so
1958	   on.

1960	   A number attempts are ongoing to improve various parts of the stack,
1961	   in particular focusing on performance of movements. These attempts
1962	   include link-layer enhancements, parameter tuning [34], network
1963	   access authentication mechanisms [14], fast handover mechanisms [20],
1964	   [2], and IP layer attachment improvements (such as Optimistic DAD
1965	   [21]).

1967	   It is uncertain how far this optimization can be taken by only
1968	   looking at the different parts individually. It is possible that a
1969	   more integrated approach would be necessary to gain a more
1970	   significant improvement [3].

1972	   It is also unclear at this time which components are the most
1973	   critical ones. Reference [1] suggests that IP mobility related
1974	   signaling contributes only under 10% of the overall delay in an IEEE
1975	   802.11 environment. The most significant delays are caused by link
1976	   layer and IPv6 attachment. However, the results are not conclusive,
1977	   as there is a factor five difference between the best and worst
1978	   cases. The results can also be affected by a number of conditions,
1979	   such as the availability of specific link layer optimizations, or the
1980	   type of security mechanism used in the Mobile IPv6 home
1981	   registrations.

1983	6.3.2  New Route Optimization Work

1985	   The primary driver to improve route optimization appears to be better
1986	   efficiency for a few usage scenarios, such as fast movements or the
1987	   ability to reduce signaling frequencies for hosts in standby mode.
1988	   Ongoing work addresses these aspects already quite well; most of the
1989	   suggested methods are quite stable in this regard. It is expected
1990	   that further (perhaps smaller) improvements continue to be achieved
1991	   through research and parameter tuning far into the future. This is
1992	   particularly true because the optimizations are often targeted to a
1993	   specific usage situation, and may not give the same improvement in
1994	   another situation. As a result, the publication of a few enhanced
1995	   methods for different situations seems more reasonable than expecting
1996	   to define a final, single method.

1998	   The development of an infrastructure-based route optimization method
1999	   is clearly a longer-term project. At this stage, it is not even clear
2000	   that such a mechanism is needed. We believe the prefix-based
2001	   certificate approach shows some promise in this area, particularly if
2002	   it can be combined with the deployment of these certificates for some
2003	   other purposes, such as Secure Neighbor Discovery [4]. The pre-shared
2004	   method being standardized at the IETF is simple and efficient, but we
2005	   do not expect it to be applicable in wide enough number of cases to
2006	   make a significant difference in practice.

2008	   In the following we list some potentially interesting research ideas
2009	   for new route optimization methods:

2011	   o  Local mobility or local repair optimizations that require no
2012	      configuration.
2013	   o  Care-of address verification mechanisms that employ lower layer
2014	      assistance or Secure Neighbor Discovery.
2015	   o  The introduction of optimizations developed in the context of
2016	      Mobile IPv6 to HIP or other mobility protocols, or to layer 2
2017	      mobility solutions.
2018	   o  Extension of the developed techniques to full multiaddressing,
2019	      i.e., including also multi-homing.
2020	   o  Further development of techniques based on "asymmetric cost wars"
2021	      [7], such as CBA.

2023	6.3.3  Experimentation and Simulation

2025	   As discussed earlier, even the contribution of different stack parts
2026	   to overall movement delays is unclear. More measurements are needed,
2027	   particularly ones that
2028	   o  Measure a realistic network scenario, enabling all features that
2029	      would likely be needed in commercial deployment. These features
2030	      include link-layer access control, for instance. Similarly, it is
2031	      necessary to include support for already specified optimizations.
2032	   o  Measure or simulate the performance impacts of various suggested
2033	      improvements to the different parts of the stack.
2034	   o  Measure implementation differences between systems based on the
2035	      same specifications. It would be valuable to know how much
2036	      implementations differ with regards to, for instance, the use of
2037	      the parallelism that RFC 3775 allows in the home and correspondent
2038	      registrations, the return routability procedure, and transmission
2039	      of packets before Binding Acknowledgements have arrived.
2040	   o  Measure the effect of network conditions, such as packet loss, and
2041	      their effect to existing and new route optimization mechanisms.
2042	   o  Collect data about the behaviour of mobile nodes in different
2043	      networks. Different route optimization mechanisms behave
2044	      differently depending on what the frequency of movements is, or
2045	      what payload traffic streams exist at the different stages of the
2046	      mobile node's existence.
2047	   o  Measure or simulate the performance of different route
2048	      optimization schemes under different application scenarios, such
2049	      as symmetric/asymmetric applications, only seldomly active mobile
2050	      nodes, and so on.

2052	7.  Security Considerations

2054	   Security issues related to route optimization are an integral part of
2055	   the problem and have been discussed in the body of the document.

2057	8.  Conclusions

2059	   Mobility related optimizations are currently actively studied by many
2060	   researchers. Some of the basic Mobile IPv6 related methods, such as
2061	   the return routability method, pre-shared secrets, CGAs are either
2062	   already being applied in practical systems or will be soon. A growing
2063	   number of new proposals are being studied that attempt to optimize
2064	   these methods further, or make them better applicable to a particular
2065	   situation.

2067	   Many of the current proposals are mature enough to withstand close
2068	   scrutiny. Their relative advantages are somewhat subjective, however.
2069	   For instance, some may have a high cost in terms of configuration
2070	   while others do not need configuration but are slower. It is expected
2071	   that more than one new method is needed for this reason. Deployment
2072	   experience will also be needed, so publication of a few alternative
2073	   methods as RFCs would be desirable.

2075	   It is interesting to note, however, that historically most if not all
2076	   current proposals had predecessors that were shown to be insecure.
2077	   For instance, the initial return routabality and CGA methods were
2078	   proposed before the need for flooding attack protection was
2079	   understood, concurrent tests were first proposed with a limited form
2080	   of flooding protection, and several proposals employing
2081	   semi-permanent security associations have suffered from address
2082	   stealing attacks. This shows the need to reserve sufficient amount of
2083	   time for community analysis and review of new methods.

2085	   Another interesting observation is that mature proposals combine a
2086	   number of techniques and do not rely on a single approach. This is
2087	   due to the nature of the problem, where several different types of
2088	   vulnerabilities have to be avoided.

2090	   But it is also necessary to avoid overly expensive or complex
2091	   solutions. For instance, in evaluating the security needs for the
2092	   route optimization problem, it is important to compare these needs to
2093	   other vulnerabilities, such as denial-of-service, that already exist
2094	   for on path attackers. These vulnerabilities should not be made
2095	   worse, but it is not necessarily a requirement to use managed,
2096	   expensive security either.

2098	   A significant research question is the overall performance of the
2099	   whole stack in a mobile setting. This includes but is not limited to
2100	   IP mobility. Current network access protocol stacks have a number of
2101	   limitations, such as long attachment and movement latencies [1] -- an
2102	   attachment typically requires over twenty link and IP layer messages
2103	   -- denial-of-service vulnerabilities, and so on.

2105	   A number attempts are currently being made to improve various parts
2106	   of the stack, in particular focusing on high-performance movements.
2107	   These attempts include link-layer enhancements, parameter tuning
2108	   [34], network access authentication mechanisms [14], fast handover
2109	   mechanisms [20][2], and IP layer attachment improvements such as
2110	   Optimistic DAD [21]. It is uncertain how far this optimization can be
2111	   taken by only looking at the different parts individually. It is also
2112	   unclear at this time which components are the most critical ones.

2114	   Other significant research questions include the effect of various
2115	   network conditions such as packet loss to the current methods and
2116	   whether different application situations require different
2117	   optimization methods.  Our current understanding about the different
2118	   traffic patterns and their effects in mobility is limited, and
2119	   experiments, modelling, and simulations will be needed.

2121	9  References

2123	   [1]   Alimian, A. and B. Aboba, "Analysis of Roaming Techniques",
2124	         IEEE Contribution 11-04-0377r1 2004.

2126	   [2]   Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to
2127	         RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress),
2128	         November 2003.

2130	   [3]   Arkko, J., Eronen, P., Nikander, P. and V. Torvinen, "Secure
2131	         and Efficient Network Access", Extended abstract to be
2132	         presented in the DIMACS workshop, November 2004.

2134	   [4]   Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
2135	         "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
2136	         (work in progress), July 2004.

2138	   [5]   Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
2139	         Lifetime Extension",
2140	         draft-arkko-mipv6-binding-lifetime-extension-00 (work in
2141	         progress), May 2004.

2143	   [6]   Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
2144	         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
2145	         Agents", RFC 3776, June 2004.

2147	   [7]   Arkko, J. and P. Nikander, "Weak Authentication:  How to
2148	         Authenticate Unknown Principals without Trusted Parties",
2149	         Proceedings of Security Protocols Workshop 2002, Cambridge, UK,
2150	         April 16-19,  2002.

2152	   [8]   Aura, T., "Cryptographically Generated Addresses (CGA)",
2153	         draft-ietf-send-cga-06 (work in progress), April 2004.

2155	   [9]   Bao, F., "Certificate-based Binding Update Protocol (CBU)",
2156	         draft-qiu-mip6-certificated-binding-update-02 (work in
2157	         progress), August 2004.

2159	   [10]  Bradner, S., Mankin, A. and J. Schiller, "A Framework for
2160	         Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in
2161	         progress), June 2003.

2163	   [11]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
2164	         Defeating Denial of Service Attacks which employ IP Source
2165	         Address Spoofing", BCP 38, RFC 2827, May 2000.

2167	   [12]  Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)",
2168	         draft-haddad-mipv6-omipv6-01 (work in progress), February 2004.

2170	   [13]  Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying
2171	         Cryptographically Generated Addresses to Optimize MIPv6
2172	         (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-02 (work in
2173	         progress), June 2004.

2175	   [14]  Institute of Electrical and Electronics Engineers, "Local and
2176	         Metropolitan Area Networks: Port-Based Network Access Control",
2177	         IEEE Standard 802.1X, September 2001.

2179	   [15]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
2180	         IPv6", RFC 3775, June 2004.

2182	   [16]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
2183	         (ESP)", RFC 2406, November 1998.

2185	   [17]  Kent, S., "IP Encapsulating Security Payload (ESP)",
2186	         draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004.

2188	   [18]  Koodli, R., "Fast Handovers for Mobile IPv6",
2189	         draft-ietf-mipshop-fast-mipv6-02 (work in progress), July 2004.

2191	   [19]  Loughney, J., "IPv6 Node Requirements",
2192	         draft-ietf-ipv6-node-requirements-11 (work in progress), August
2193	         2004.

2195	   [20]  Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
2196	         "Proactive Key Distribution to support fast and secure
2197	         roaming", IEEE Contribution 11-03-084r1-I, January 2003.

2199	   [21]  Moore, N., "Optimistic Duplicate Address Detection for IPv6",
2200	         draft-ietf-ipv6-optimistic-dad-01 (work in progress), June
2201	         2004.

2203	   [22]  Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00
2204	         (work in progress), June 2004.

2206	   [23]  Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
2207	         Nordmark, "Mobile IP version 6 Route Optimization Security
2208	         Design Background", draft-ietf-mip6-ro-sec-01 (work in
2209	         progress), July 2004.

2211	   [24]  Paxson, V., "An Analysis of Using Reflectors for Distributed
2212	         Denial-of-Service Attacks",  Computer Communication Review
2213	         31(3)., July 2001.

2215	   [25]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2216	         2002.

2218	   [26]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
2219	         IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April
2220	         2004.

2222	   [27]  Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity
2223	         Protocol", draft-moskowitz-hip-09 (work in progress), February
2224	         2004.

2226	   [28]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
2227	         Authentication in the IPv6 World", Proceedings of the Cambridge
2228	         Security Protocols Workshop, April 2001.

2230	   [29]  Patel, A., "Problem Statement for bootstrapping Mobile IPv6",
2231	         draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004.

2233	   [30]  Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. Chowdhury,
2234	         "Authentication Protocol for Mobile IPv6",
2235	         draft-ietf-mip6-auth-protocol-00 (work in progress), July 2004.

2237	   [31]  O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
2238	         Computer Communications Review, April 2001.

2240	   [32]  Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
2241	         Mobile IPv6 Binding Updates and Acknowledgments",
2242	         draft-roe-mobileip-updateauth-02 (work in progress), March
2243	         2002.

2245	   [33]  Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
2246	         "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
2247	         draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004.

2249	   [34]  Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b
2250	         MAC Layer Handover Time", Laboratory for Communication
2251	         Networks, KTH, Royal Institute of Technology, Stockholm,
2252	         Sweden, TRITA-IMIT-LCN R 03:02, April 2003.

2254	   [35]  Vogt, C., Arkko, J., Bless, R., Doll, M. and T. Kuefner,
2255	         "Credit-Based Authorization for Mobile IPv6 Early Binding
2256	         Updates", draft-vogt-mipv6-credit-based-authorization-00 (work
2257	         in progress), May 2004.

2259	   [36]  Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding
2260	         Updates for Mobile IPv6",
2261	         draft-vogt-mip6-early-binding-updates-00 (work in progress),
2262	         February 2004.

2264	Authors' Addresses

2266	   Jari Arkko
2267	   Ericsson Research NomadicLab

2269	   FI-02420 Jorvas
2270	   Finland

2272	   EMail: jari.arkko@ericsson.com

2274	   Christian Vogt
2275	   Institute of Telematics
2276	   University of Karlsruhe
2277	   P.O. Box 6980
2278	   76128 Karlsruhe
2279	   Germany

2281	   EMail: chvogt@tm.uka.de
2282	   URI:   http://www.tm.uka.de/~chvogt/

2284	Appendix A.  Acknowledgements

2286	   The authors wish to thank Gabriel Montenegro and Rajeev Koodli for
2287	   their support, review, and suggestions related to this paper.

2289	Intellectual Property Statement

2291	   The IETF takes no position regarding the validity or scope of any
2292	   Intellectual Property Rights or other rights that might be claimed to
2293	   pertain to the implementation or use of the technology described in
2294	   this document or the extent to which any license under such rights
2295	   might or might not be available; nor does it represent that it has
2296	   made any independent effort to identify any such rights. Information
2297	   on the IETF's procedures with respect to rights in IETF Documents can
2298	   be found in BCP 78 and BCP 79.

2300	   Copies of IPR disclosures made to the IETF Secretariat and any
2301	   assurances of licenses to be made available, or the result of an
2302	   attempt made to obtain a general license or permission for the use of
2303	   such proprietary rights by implementers or users of this
2304	   specification can be obtained from the IETF on-line IPR repository at
2305	   http://www.ietf.org/ipr.

2307	   The IETF invites any interested party to bring to its attention any
2308	   copyrights, patents or patent applications, or other proprietary
2309	   rights that may cover technology that may be required to implement
2310	   this standard. Please address the information to the IETF at
2311	   ietf-ipr@ietf.org.

2313	Disclaimer of Validity

2315	   This document and the information contained herein are provided on an
2316	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2317	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2318	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2319	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2320	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2321	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2323	Copyright Statement

2325	   Copyright (C) The Internet Society (2004). This document is subject
2326	   to the rights, licenses and restrictions contained in BCP 78, and
2327	   except as set forth therein, the authors retain all their rights.

2329	Acknowledgment

2331	   Funding for the RFC Editor function is currently provided by the
2332	   Internet Society.