idnits 2.17.1 

draft-irtf-mobopts-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 3978, Section 5.1.a on line 18.

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

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2315.

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

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

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement. 

  ** 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 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:

        This document is an Internet-Draft and is subject to all provisions of
        Section 3 of RFC 3667.

        By submitting this Internet-Draft, each author represents that any
        applicable patent or other IPR claims of which he or she is aware
        have been or will be disclosed, and any of which he or she
        becomes aware will be disclosed, in accordance with Section 6 of
        BCP 79.


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

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

  == 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 (January 26, 2005) is 7030 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)

  == Unused Reference: '7' is defined on line 2156, but no explicit reference
     was found in the text

  == Unused Reference: '14' is defined on line 2181, but no explicit
     reference was found in the text

  == Unused Reference: '16' is defined on line 2187, but no explicit
     reference was found in the text

  == Unused Reference: '30' is defined on line 2242, but no explicit
     reference was found in the text

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

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

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

  -- No information found for draft-daley-mip6-locpriv - is the name correct?

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

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

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

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

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

  == Outdated reference: A later version (-03) exists of
     draft-haddad-momipriv-problem-statement-00

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

  == 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. '9')

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

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

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

  == 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. '13')

  == 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. '14')

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

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

  == 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. '16')

  == 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. '17')

  == 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. '18')

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


     Summary: 18 errors (**), 0 flaws (~~), 18 warnings (==), 31 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: July 30, 2005                                           C. Vogt
4	                                                 University of Karlsruhe
5	                                                        January 26, 2005

7	      A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route
8	                              Optimization
9	               draft-irtf-mobopts-ro-enhancements-00.txt

11	Status of this Memo

13	   This document is an Internet-Draft and is subject to all provisions
14	   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
15	   author represents that any applicable patent or other IPR claims of
16	   which he or she is aware have been or will be disclosed, and any of
17	   which he or she become aware will be disclosed, in accordance with
18	   RFC 3668.

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

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

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

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

36	   This Internet-Draft will expire on July 30, 2005.

38	Copyright Notice

40	   Copyright (C) The Internet Society (2005).

42	Abstract

44	   The Mobile IPv6 protocol favors sending packets via the minimum
45	   routing path between a mobile node and its correspondent node over
46	   sending them through a home agent.  This feature is called route
47	   optimization.  Route optimization requires authentication and
48	   authorization of initially unacquainted and untrusted parties--a
49	   requirement that was rather new to the Internet community at the time
50	   Mobile IPv6 was designed.  To solve the problem, the so-called
51	   return-routability procedure was built into Mobile IPv6.  It lets the
52	   mobile node retrieve from the correspondent node two cryptographic
53	   tokens, which the mobile node can use to authenticate itself and
54	   prove its presence at a claimed new location after movement.
55	   Recently, a number of improvements or optional alternatives have been
56	   suggested to the standard procedure.  Many of these improvements
57	   attempt further reduction of signaling messages and latency, but
58	   other improvements such as better security have also been suggested.
59	   This paper summarizes the goals for enhancements to
60	   route-optimization, discusses the security threats that such
61	   enhancements must consider, and categorizes the techniques that one
62	   can use for optimization.  The paper highlights the key ideas of
63	   various recent proposals, and it evaluates the performance gain that
64	   such proposals can yield.  It also discusses how significant
65	   enhancements to Mobile IPv6 are compared to ongoing optimization work
66	   in other parts of the network stack.  Finally, the paper identifies
67	   needs for additional research.

69	Table of Contents

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

114	1.  Introduction

116	   An IP address traditionally combines identification and location
117	   semantics.  The address prefix locates a node's point of network
118	   attachment.  It is used by routers to forward IP packets towards the
119	   correct destination.  At the same time, existing transport protocols
120	   and applications, commonly termed "upper layers", use the IP address
121	   as part of a session identification.  This naturally rules out
122	   mobility: Whenever a mobile node moves from one IP-attachment point
123	   to another, its IP address must change to reflect the new location.
124	   The new "identity", however, causes sessions at upper layers to
125	   abort.

127	   Protocol designers thus had to decide whether to change transport
128	   protocols and applications, or to come up with a new IP-layer
129	   protocol that could separate location from identification
130	   functionality in a way transparent to upper layers.  Due to the
131	   prevalence of TCP and the significant base of existing applications,
132	   most people opted for the latter approach.  Mobile IPv6 [29], its
133	   IPv4 counterpart [28], and the Host Identity Protocol [9] are three
134	   dominant mobility-management protocols that the IETF has developed to
135	   facilitate the continued use of existing transport protocols and
136	   applications in an Internet with mobility support.  This document
137	   focuses on Mobile IPv6.

139	   Mobile IPv6 uses two IP addresses per mobile node in an attempt to
140	   separate location semantics from identification semantics: a
141	   transient "care-of address" is used for the purpose of routing.  It
142	   is re-configured whenever the mobile node moves to a new
143	   IP-attachment point.  A static "home address" is configured with the
144	   network prefix from a non-mobile "home agent's" network.  The home
145	   address doesn't change when the mobile node moves, and it can be used
146	   for session identification at upper layers.

148	   The mobile node keeps the home agent up to date about its current
149	   care-of address.  In the event that packets are sent to the mobile
150	   node's home address, the home agent captures them and tunnels them to
151	   the mobile node's care-of address.  In the opposite direction, the
152	   mobile node may tunnel packets to the home agent who, in turn,
153	   decapsulates them and forwards them on to the correspondent node.
154	   This behavior was termed "bidirectional tunneling".  It works fine
155	   even if the correspondent node is unaware of its peer being mobile.
156	   The correspondent node can just use the home address, and the home
157	   agent will take care that packets find their way to the mobile node's
158	   actual location.  Obviously, this entails a lot of routing overhead
159	   in many common scenarios.

161	   For better routing efficiency, Mobile IPv6 defines a second mode,
162	   "route optimization", that allows two nodes to directly communicate.
163	   Route optimization requires the correspondent node to be aware of the
164	   mobile node's current care-of address.  The mobile node informs the
165	   correspondent node whenever its care-of address changes.

167	   All signaling between a mobile node and its home agent is
168	   authenticated, and optionally encrypted, through IPsec.  The IPsec
169	   security associations can either be manually configured into the
170	   nodes, or they can be dynamically derived through IKE.  The mobile
171	   node and home agent must also be configured with the material they
172	   need to identify themselves, and the home agent must be able to
173	   authorize a mobile node to use a particular home address.

175	   Preconfiguration of home agents and mobile nodes requires
176	   administrative labor, but it is doable, because the association
177	   between a mobile node and its home agent, or set of potential home
178	   agents, is typically known in advance.  On the other hand, when route
179	   optimization is used between an arbitrary pair of nodes, there is
180	   generally no relationship between the two nodes prior to
181	   communication.  Empowering a node--not necessarily a mobile one--to
182	   redirect packets from one IP address to another hence poses two
183	   questions:

185	   o  When the correspondent node receives a command to redirect a
186	      mobile node's packets, how can the correspondent node be sure that
187	      it is the legitimate mobile node, rather than a malicious third
188	      node, which has send this command?
189	   o  How can the correspondent node rely on the mobile node actually
190	      being present at the IP address to which packets are to be
191	      redirected?

193	   The first question identifies the need for a mobile node to
194	   authenticate itself during a correspondent registration.  Without
195	   such authentication, a malicious node could interfere with a packet
196	   flow of another node, redirecting the flow to its own location for
197	   inspection purposes, or redirecting it to a random IP address for the
198	   purpose of denial of service against the legitimate recipient.  The
199	   second question refers to spoofed care-of addresses: Probing a mobile
200	   node's presence at a care-of address is important to prevent
201	   malicious parties to redirect packets to other nodes that neither
202	   expect nor want those packets.

204	   A variety of approaches have been proposed to solve the
205	   above-mentioned issues for the case of route optimization.  People
206	   finally elected the "return-routability procedure" as a default
207	   mechanism for Mobile IPv6.  The return-routability procedure delivers
208	   a pair of secret tokens to a mobile node's home and care-of
209	   addresses.  The mobile node needs these tokens to prove that it is
210	   the legitimate owner of the home address and that it is reachable at
211	   the care-of address.  (Actually, the return-routability procedure is
212	   less strict: It only determines whether a node is on the path towards
213	   the two addresses, rather than that it actually holds the two
214	   addresses.  This is a compromise that the procedure accepts.)

216	   The return-routability procedure is run right before a mobile node
217	   registers a new care-of address with a correspondent node.  It is
218	   also run periodically in case the mobile node does not move for a
219	   while.  The advantage of the return-routability procedure is that it
220	   is lightway and does not require any sort of pre-shared
221	   authentication material.  Moreover, it can be implemented in a
222	   stateless way at the correspondent node's side.  On the other hand,
223	   the return-routability procedure usually consumes one round-trip
224	   time, which comes into addition to the rest of any pending
225	   registration.  This can lead to a handover delay unacceptable for
226	   many real-time or interactive applications like Voice over IP (VoIP)
227	   and audio or video streaming.  Also, the periodic repetitions imply a
228	   hidden signaling overhead that may interfere with mobile nodes who
229	   intend to sleep during times of inactivity.  Finally, the security
230	   level of the return-routability procedure can be increased.  It
231	   limits vulnerabilities to attackers that are on the path from the
232	   correspondent node to the mobile node or to the home agent.  The
233	   residual vulnerabilities are similar to those that exist anyway in an
234	   Internet without mobility support.  But still, mechanisms that use
235	   stronger, possibly cryptographic authentication can provide a higher
236	   level of security than the return-routability procedure does.

238	   This paper describes and classifies strategies that can enhance or
239	   optimize Mobile IPv6 route optimization.  Following this
240	   introduction, Section 2 discusses which new security threats
241	   mobility-management protocols need to take into account.  Section 3
242	   explains the current route-optimization protocol, identifies the
243	   goals and assumptions based on which it was developed, and briefly
244	   analyzes its security properties.  A number of potential goals for
245	   enhancements (such as reducing latency) are discussed in Section 4.
246	   Section 5 reviews techniques that can be used to enhance or optimize
247	   Mobile IPv6 route optimization.  Section 6 discusses how these
248	   techniques are applied in existing enhancement and optimization
249	   proposals, evaluates some of these proposals, and identifies
250	   opportunities for further research.  The paper concludes in
251	   Section 8.

253	2.  Mobility-Related Security Threats

255	   Mobile IPv6 allows a node to redirect those packets, that a
256	   correspondent node would otherwise send to one IP address (the home
257	   address), to a second IP address (the care-of address).

259	   Unfortunately, the ability for redirection can also be misused by a
260	   malicious node for an arbitrary pair of IP addresses unless
261	   appropriate precautions are taken.

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

269	2.1  Impersonation Attacks

271	   The probably most obvious issue with mobility is to ensure that only
272	   a mobile node itself has the ability to change its care-of address.
273	   If care-of-address registrations were unauthenticated, an attacker
274	   could easily impersonate an arbitrary victim.  For instance, the
275	   attacker could contact the victim's correspondent node and register
276	   its own IP address on behalf of its victim.  The correspondent node
277	   would assume that the victim's care-of address has changed, and it
278	   would redirect all packets intended for the victim to the attacker
279	   instead.  The attacker could forward the packets to the victim after
280	   analyzing, or even tampering with, their payloads.  In a related
281	   offense, the perpetrator could simply cause havoc at its victim by
282	   directing the victim's packets to a random or non-existent IP
283	   address.  These attacks are jointly referred to as "impersonation
284	   attacks".  Impersonation attacks can be prevented through proper
285	   authentication techniques that keep an outsider from assuming another
286	   node's identity.

288	   It is important to recognize that impersonation attacks not only
289	   impact those nodes that have an interest in mobility.  Although the
290	   attacker makes the correspondent node believe that the victim is
291	   mobile, neither the attacker nor the victim do have to be mobile.
292	   Indeed, mobile nodes, non-moving nodes with mobility support, as well
293	   as traditional stationary nodes are potentially endangered because
294	   they all share the same IPv6 identifier namespace.  (Actually, even
295	   IPv4 nodes are jeopardized when IPv4-to-IPv6 translation occurs on
296	   the path between these nodes and their correspondent peers.) This
297	   unfolds the need for mandatory protection of mobility-related
298	   signaling in order to safeguard the Internet community as a whole.

300	   Beyond their large group of potential victims, mobility-related
301	   impersonation attacks allow an attacker to choose the location from
302	   where to wage its attack.  For example, the impersonator could
303	   position itself at a place where it is easier to inject spoofed
304	   care-of-address registration packets into the network than anywhere
305	   on the direct path between the victims.  The attacker may also move
306	   to a place where it can remain unrecognized.  In contrast to this, in
307	   the non-mobile Internet that we have today, an attacker can only
308	   listen to or tamper with packets while it is on the path between its
309	   victims.  Similarly, a mobility-management protocol may give the
310	   attacker the possibility to shift the time for its attack.  The
311	   attacker might be able to register false care-of addresses even
312	   before its victims' conversation begins, or attack a network long
313	   after it has visited it.  In the non-mobile Internet, an attacker
314	   must strike at the same time as its victims communicate.  The ability
315	   to choose the location and time for an attack constitutes a dangerous
316	   new degree of freedom for the attacker.

318	2.2  Resource-Exhaustion Attacks

320	   Mobility support at correspondent nodes can become an issue if it
321	   takes a lot of processing capacity to handle an incoming
322	   care-of-address registration.  During times of increased signaling
323	   load, a correspondent node may thus end up having to commit a
324	   significant fraction of its resources to mobility-related
325	   transactions.  What is worse, an attacker may take advantage of this
326	   vulnerability.  It could swamp the correspondent node with large
327	   quantities of bogus registrations messages, keeping it from doing
328	   useful work.  Such denial-of-service attempts are called
329	   "resource-exhaustion attacks".  Clearly, if mobility support is to be
330	   implemented on a large basis, handling care-of-address registrations
331	   must be lightweight in order to lessen the susceptibility to resource
332	   exhaustion.  Another effective technique is to defer resource
333	   commitment until late in the registration process: Once the
334	   registrant has proven its identity or shown that it is willing to
335	   invest resources itself, it is less likely malicious.  As a last
336	   resort, busy Internet servers should limit the resources they devote
337	   to registration processing, and they may give preference to those
338	   mobile nodes they know or have recently had meaningful communications
339	   with.

341	   It is worthwhile to stress the trade-off between effectiveness of
342	   signaling authentication and resilience against increased signaling
343	   load.  On one hand, a strong authentication mechanism can effectively
344	   prevent certain impersonation attacks.  On the other hand, the
345	   resources a correspondent node must spend on the verification of a
346	   registering node's authenticity increases with the complexity of the
347	   authentication algorithm.  The susceptibility to resource exhaustion
348	   thus grows with the level of protection against impersonation
349	   attacks.

351	2.3  Flooding Attacks

353	   A third mobility-related security threat emanates from
354	   redirection-based flooding attacks.  Redirection-based flooding
355	   attacks are characterized by a victim being bombarded with unwanted
356	   packets at a rate that the victim, and possibly the victim's access
357	   network, cannot handle.  As with impersonation attacks, it is
358	   important to compare existing flooding attacks in today's non-mobile
359	   Internet with redirection-based flooding attacks that could be made
360	   possible through an insecure mobility-management protocol.

362	   Three types of flooding attacks can be identified in today's
363	   Internet.  The simplest one is a "direct flooding attack".  Here, the
364	   attacker itself sends bogus packets to the victim.  In an indirect
365	   "reflection attack", the attacker tricks a third node, the
366	   "reflection point", to send the packets.  It typically uses a known
367	   protocol vulnerability to make the reflection point generate these
368	   packets [38].  For example, the attacker may send spoofed ICMP Echo
369	   Request packets to the reflection point, using its victim's IP
370	   address in the packets' IPv6 Source Address field.  For each such
371	   request, the reflection point generates an ICMP Echo Reply message,
372	   which it sends "back" to the victim.  The advantage of a reflection
373	   attack over a direct flooding attack is that the attacker is usually
374	   harder to track when flooding traffic comes from a third node.
375	   Another example for a reflection attack is TCP-SYN flooding.  Here,
376	   the attacker sends TCP SYN packets, again with false source
377	   addresses, to the reflection point, which in turn sends TCP SYN-ACK
378	   packets to someone who does not expect these packets.  Since most TCP
379	   servers are configured so that they re-send a TCP SYN packet multiple
380	   times when failing to receive an acknowledgement, this reflection
381	   attack can even produce a small amplification.  Gaining higher
382	   amplification in today's Internet necessitates more complex
383	   strategies like "distributed flooding attacks".  In a distributed
384	   flooding attack, the attacker typically gains control over other
385	   nodes by spreading viral software.  Then, at a certain point of time,
386	   infected nodes simultaneously commence a joint flooding attack
387	   against a common victim.

389	   The introduction of mobility support renders amplified flooding
390	   attacks much less complex.  Suppose a mobile node is allowed to
391	   change its care-of address without having to evidence that it is
392	   present at the new care-of address.  Then, an attacker can subscribe,
393	   through its own IP address, to a large data flow (e.g., a video
394	   stream) offered by some server on the Internet.  The attacker can
395	   easily accomplish the initial handshake procedure with the server
396	   while it uses its own IP address.  Once data is flowing, the attacker
397	   can redirect the flow to the IP address of an arbitrary victim.  The
398	   attacker can use the sequence numbers learned during the initial
399	   handshake procedure in order to spoof acknowledgements for packets
400	   that it assumes the server has sent to the victim.  In this attack,
401	   not the attacker, but a faithful server on the Internet can be made
402	   generate packets used for an attack.  The server does not have to be
403	   infected with compromised code, and neither the victim nor the server
404	   has to be mobile.  The attacker produces as little as spoofed
405	   feedback information to keep the data flow alive.  To make matters
406	   worse, the attacker can redirect data flows from multiple servers to
407	   the victim.

409	   Support for Mobile IPv6 route optimization is recommended to all IPv6
410	   nodes [11].  The base of correspondent nodes that an attacker could
411	   exploit for a redirection-based flooding attack would therefore be
412	   immense.  Also note that no distribution of viral software would be
413	   necessary.  The severity of this new type of flooding is that it
414	   would provide potentially unbounded amplification at comparably low
415	   cost.

417	3.  Mobile IPv6 Route Optimization

419	   Route optimization requires the mobile node to register its current
420	   care-of address with both its home agent and correspondent node.  The
421	   process of doing so is called a "home registration" and a
422	   "correspondent registration", respectively.

424	   When a mobile node begins communicating with a particular
425	   correspondent node after a successful home registration, all packets
426	   are initially routed through the mobile node's home agent, and
427	   bidirectionally tunneled between the home agent and the mobile node's
428	   current attachment point.  For increased routing performance, the
429	   mobile node should do a correspondent registration as early as
430	   possible.

432	   This section explains the standard Mobile IPv6 registration procedure
433	   in the case that route optimization is used.  The goals and
434	   assumptions based on which this registration process was developed
435	   are presented thereafter.  The section concludes with a security
436	   analysis of the Mobile IPv6 registration process.

438	3.1  Registration Procedure

440	   A mobile node registers its current care-of address with its home
441	   agent and correspondent node.  As a result, the home agent and
442	   correspondent node create "bindings" between the mobile node's home
443	   address and current care-of address.  The following is a nutshell
444	   presentation of Mobile IPv6 home and correspondent registrations.
445	   Figure 1 illustrates this process.  The interested reader is referred
446	   to RFC 3775 [29] for the complete specification.

448	   Mobile                                              Correspondent
449	    Node                      Home Agent                    Node
450	      |                           |                           |
451	      | 1. Binding Update (BU)    |                           |
452	      |-------------------------->|                           |
453	      |                           |                           |
454	      | 2. Binding Ack (BA)       |                           |
455	      |<--------------------------|                           |
456	      |                           |                           |
457	      | 3a. Home Test Init (HoTI) |                           |
458	      |-------------------------->|-------------------------->|
459	      |                                                       |
460	      | 3b. Care-of Test Init (CoTI)                          |
461	      |------------------------------------------------------>|
462	      |                                                       |
463	      |                           | 4a. Home Test (HoT)       |
464	      |<--------------------------|<--------------------------|
465	      |                           |                           |
466	      |                             4b. Care-of Test (CoT)    |
467	      |<------------------------------------------------------|
468	      |                                                       |
469	      | 5. Binding Update (BU)                                |
470	      |-------------------------------------------------------|
471	      |                                                       |
472	      |                             6. Binding Ack (BA)       |
473	      |<------------------------------------------------------|
474	      |                                                       |

476	              Figure 1: Mobile IPv6 Registration Procedure

478	   When the mobile node detects that it has moved to a different access
479	   network, it configures a new care-of address.  The mobile node then
480	   initiates a home registration by sending to the home agent a Binding
481	   Update (BU) message.  The BU contains the mobile node's home address,
482	   current care-of address, and some supplementary information.  If the
483	   home registration succeeds, the home agents returns a Binding
484	   Acknowledgement (BA) message, informing the mobile node that its home
485	   address is now bound to the new care-of address.  The BA also
486	   specifies for how long the binding will stay in place.

488	   RFC 3775 requires that the BU and BA be authenticated, and recommends
489	   that they also be encrypted, through IPsec.  The mobile node and home
490	   agent may be pre-configured with the necessary security associations,
491	   or they may dynamically create them through IKE.  In the latter case,
492	   the nodes have to be preconfigured with an identifier and the
493	   credentials necessary to prove their identity during the IKE
494	   authentication stage.  This could be a preconfigured shared secret or
495	   a public/private-key pair combined with a certificate that binds the
496	   public key to the identifier.  Finally, the home agent needs
497	   sufficient information to authorize a mobile node to use a particular
498	   home address.

500	   The correspondent registration consists of a return-routability
501	   procedure followed by the registration proper.  The
502	   return-routability procedure, in turn, is a combination of two
503	   message exchanges, one exchange that goes through the home network
504	   and another direct exchange.  The return-routability procedure aims
505	   to determine whether the mobile node is reachable at its home address
506	   and care-of address.  The mobile node may initiate the
507	   return-routability procedure at any time after it has sent the BU to
508	   the home agent.  It then sends a Home Test Init (HoTI) message and a
509	   Care-of Test Init (CoTI) message to the correspondent node.  The HoTI
510	   is tunneled to the home agent, which forwards the message to the
511	   correspondent node.  The CoTI is sent to the correspondent node on
512	   the direct path.

514	   When the correspondent node receives the HoTI, it generates a Home
515	   Keygen Token, which it returns to the mobile node's home address in a
516	   Home Test (HoT) message.  The mobile node needs the Home Keygen Token
517	   to show that it is the legitimate owner of its home address.
518	   Similarly, when the correspondent node receives a CoTI, it sends a
519	   Care-of Test (CoT) message with a Care-of Keygen Token to the mobile
520	   node's care-of address.  The mobile node needs the Care-of Keygen
521	   Token to prove its reachability at the new care-of address.  The
522	   tokens are produced based on unpredictable nonces, the mobile node's
523	   home and care-of address, respectively, and some auxiliary data.
524	   Sufficient information is communicated as part of the registration
525	   protocol such that the correspondent node will eventually be able to
526	   recompute both tokens without having to explicitly store either of
527	   them.  Note that, although some Mobile IPv6 implementations do the
528	   two message exchanges in sequence, a standard-conform and more
529	   efficient way is doing them in parallel.  Home and Care-of Keygen
530	   Tokens are good for 3.5 minutes, so if the mobile node changes its
531	   care-of address again during this period, it may reuse its Home
532	   Keygen Token.  The HoTI-HoT and CoTI-CoT exchanges are respectively
533	   called "home-address test" and "care-of-address test".

535	   RFC 3775 recommends that the HoTI and HoT be authenticated, and
536	   optionally encrypted, through an IPsec tunnel between the mobile node
537	   and the home agent.  It is the home agent's responsibility to update
538	   the corresponding security association to the new tunnel end point
539	   during the home registration.

541	   Once the mobile node has received the HoT and CoT from the
542	   correspondent node as well as the BU from the home agent, it can send
543	   a BU to the correspondent node, requesting the correspondent node to
544	   bind its home address to its current care-of address.  The mobile
545	   node must compute a message-authentication code keyed with the Home
546	   and Care-of Keygen Tokens.  When the correspondent node receives the
547	   BU, it can thus decide that the mobile node, first, owns the home
548	   address mentioned in the BU and, second, is reachable at the care-of
549	   address to which that home address is to be bound.  The mobile node
550	   may optionally request the correspondent node to return a BA for
551	   confirmation by setting a flag in the BU.  Note that the BA is
552	   mandatory for the home registration.

554	   Bindings at correspondent nodes have a maximum lifetime of seven
555	   minutes.  If a binding is not updated within this time, the mobile
556	   node must re-do the correspondent registration.  This includes
557	   another run of the return-routability procedure.

559	3.2  Goals and Assumptions

561	   An important objective for the development of Mobile IPv6 was to
562	   provide for a wide, preferably universal, support for route
563	   optimization.  In fact, support for Mobile IPv6 and, thus, route
564	   optimization is recommended in the requirements suite for IPv6 nodes
565	   [11].  It was, and still is, believed that the additional routing
566	   overhead associated with bidirectional tunneling is too much of a
567	   burden on the core Internet given that the number of connected mobile
568	   nodes is expected to grow substantially within the next decades.

570	   The aspiration for wide-scale deployment of route optimization has an
571	   impact on how a correspondent node can authorize a mobile node to use
572	   a particular home address.  A mobile node must authenticate itself,
573	   preferably without any pre-configured keys, as the legitimate owner
574	   of the home address packets addressed to which it seeks to redirect
575	   to a certain care-of address.  Without such authentication, any
576	   node--not necessarily a mobile one--could redirect any other node's
577	   packets.  The challenge here is to bind to a given home address a
578	   property that only the mobile node owning that home address can have.

580	   The return-routability procedure was elected as the default
581	   authentication mechanism for Mobile IPv6 route optimization.  It
582	   verifies home-address ownership through a routing property and so
583	   does without any pre-configured authentication material.  When a
584	   mobile node shows that it can receive messages sent to its home
585	   address, this is understood as reasonable evidence that the mobile
586	   node is the legitimate home-address owner.  Strictly speaking, the
587	   return-routability procedure checks only that the mobile node is
588	   somewhere on the path between the correspondent node and the home
589	   address.  An on-path attacker could thus hijack a communications
590	   connection that is not protected otherwise.  However, the problem
591	   with on-path attackers is independent of mobility and already existed
592	   before the introduction of Mobile IPv6.  Hence, the
593	   return-routability procedure does not create a new security threat.

595	   Of course, there are alternatives to the return-routability
596	   procedure.  Preconfiguring shared secrets into mobile nodes and
597	   correspondent nodes is one, leveraging public-key cryptography is
598	   another.  These approaches may in fact do a very good job in certain
599	   scenarios.  However, both of them have deficiencies as far as general
600	   applicability goes.  The following explains why neither approach was
601	   taken up as the default authentication mechanism in Mobile IPv6.

603	   If a shared secret is pre-configured into a mobile node and its
604	   correspondent node, the correspondent node can authenticate the
605	   mobile node by having it encrypt a piece of random data and comparing
606	   the result with the expected ciphertext.  This process is simple and
607	   appealing.  The crux is that there is usually no existing
608	   relationship between an arbitrary pair of nodes before the nodes
609	   start communicating.  Preconfiguration may hence not be feasible in
610	   many cases.  And where preconfiguration does apply will it involve
611	   considerable administrative overhead, which makes the approach
612	   impractical except for some very limited scenarios.  Also note that a
613	   security association alone does not show that a node owns a specific
614	   IP address.  This property, however, is required for Mobile IPv6
615	   route optimization, so an external mechanism is needed to authorize
616	   an authenticated mobile node to use a specific home address.

618	   Public-key cryptography requires some external binding between a
619	   public key and the identity this public key is supposed to protect.
620	   Certificates issued by a trusted authority can usually do this job,
621	   although there is little experience with using home addresses as
622	   identifiers in the certificates.  (E.g., the home address could be
623	   placed into a certificate's Subject AltName field.) Given a
624	   certificate that binds a public key to a home address, the owner of
625	   this home address can authenticate itself as such by signing some
626	   arbitrary piece of data with its private key.  Since everybody can
627	   verify the signature with the mobile node's public key, this proves,
628	   in the end, that the mobile node actually knows the private key
629	   complementing the certified public key, and the certificate authority
630	   vouches that the public key, in turn, is associated with the home
631	   address.  The issue with public-key cryptography in the case of
632	   Mobile IPv6 is the extraordinarily high number of potential home
633	   addresses.  Many experts doubt that one could built a public-key
634	   infrastructure (PKI) of the size appropriate for Mobile IPv6.
635	   Furthermore, making certificates bind home addresses to public keys
636	   is per se an issue, because IP address assignment is typically
637	   handled by other network entities than the PKI nodes.  A global PKI
638	   would also constitute an attractive target for attacks, endangering
639	   the Internet as a whole.

641	   It is important to recognize that some mobility-related attacks can
642	   be prevented through authentication and authorization to use a
643	   particular home address, while others cannot.  A dominant threat
644	   uncovered is resource-exhaustion attacks.  In fact, the stronger the
645	   authentication algorithms, the easier it is to exploit the resources
646	   of a node running these algorithms.  In a resource-exhaustion attack,
647	   an attacker brings down its victim through massively sending it bogus
648	   requests.  Protection against malicious resource exhaustion was
649	   another key driver in the Mobile IPv6 security-design process.  The
650	   intent was primarily to safeguard those hosts which offer a popular
651	   or critical service without necessarily having to be mobile
652	   themselves.  A Mobile IPv6 correspondent registration is robust
653	   against resource-exhaustion attacks in that it is of low complexity
654	   and delays state creation as well as computational tasks at the
655	   correspondent node until the mobile node has shown its credentials.

657	   Redirection-based flooding attacks are another threat that cannot be
658	   encountered by authentication.  Mandatory authentication may lessen
659	   the attractiveness of such flooding, but certainly cannot prevent it.
660	   There must hence be a different mechanism that prevents malicious use
661	   of care-of addresses.  In Mobile IPv6, a correspondent node probes a
662	   mobile node's new care-of address before it sends packet there.  This
663	   verification strategy operates end to end, and it is as such
664	   independent of any support from the network.

666	   An alternative that does require network support is to enforce proper
667	   use of care-of addresses already at the mobile node's point of
668	   network attachment.  The correspondent node may then simply believe
669	   in the validity of a care-of address without doing any verification
670	   itself.  Many access networks today provide this service through
671	   ingress filtering [34].  However, the crux with verifying a care-of
672	   address at the fringe of the Internet is that an attacker can choose
673	   the location from where to wage a flooding attack.  As long as there
674	   are access networks where ingress filtering, or an equivalent
675	   technique, is not deployed, an attacker can always avoid
676	   care-of-address verification.  Designers therefore made Mobile IPv6
677	   not to rely on ingress filtering.  Certificate-based authorization of
678	   care-of addresses is also infeasible because care-of addresses change
679	   in a typically unpredictable way, whereas certificates are static.

681	   It should be mentioned that care-of-address verification can be
682	   omitted in scenarios where the mobile node is considered trustworthy.
683	   For instance, RFC 3775 is based on the assumption that there is a
684	   trust relationship between mobile nodes and their respective home
685	   agents.  The care-of-address test is hence omitted during home
686	   registrations.  This is certainly a feasible hypothesis in many
687	   cases, but one ought to bear in mind that, in some scenarios, it may
688	   be not.  As an example, a mobile services provider may not be able to
689	   trust all individuals from its large customer basis, so it may probe
690	   a mobile node's care-of address even during a home registration
691	   irrespective of what RFC 3775 defines.

693	3.3  Security Analysis

695	   To analyze the security of the return-routability procedure, one
696	   should evaluate its protection against the tree types of attacks
697	   described in section Section 2: impersonation attacks against third
698	   parties, resource-exhaustion attacks against mobile nodes or
699	   correspondent nodes, and flooding attacks against third parties.

701	   In the context of Mobile IPv6, impersonation is an attack in which
702	   the perpetrator claims ownership over a victim's IP address,
703	   pretending that this IP address be its own Mobile IPv6 home address.
704	   The return-routability procedure can prevent such attacks unless the
705	   attacker is on the path from the correspondent node to the victim (in
706	   the case of a stationary victim) or from the correspondent node to
707	   the victim's home agent (if the victim is mobile).  However, if an
708	   attacker happens to be on the critical path, it can spoof a HoTI on
709	   behalf of the victim, eavesdrop on the returning HoT, and thus
710	   illegitimately acquire a Home Keygen Token.  The impersonator can
711	   produce its own Care-of Keygen Token by sending the victim's
712	   correspondent peer a tailored CoTI with a care-of address through
713	   which the impersonator is itself reachable.  Having both tokens
714	   allows the attacker to send an authenticated BU on behalf of the
715	   victim.

717	   The return-routability procedure's susceptibility to attacks from the
718	   routing path conforms with the objective to prevent new attack types
719	   that did not exist before the introduction of Mobile IPv6, but to
720	   disregard existing threats that are independent of whether mobility
721	   is supported or not.  For instance, redirecting someone else's
722	   packets from outside those packets' routing path is generally
723	   impossible with plain IP, but a "man in the middle" may well launch a
724	   successful attack from a position on the routing path.  This said, it
725	   stands to reason why the return-routability procedure prevents
726	   off-path attacks, but does little to stop on-path attacks.

728	   Similarly, the return-routability procedure does not prevent an
729	   attacker from registering a care-of address which is located such
730	   that the attacker is on the path between the care-of address and the
731	   correspondent node.  This attacker is in a position to launch a
732	   redirection-based flooding attack against the node using the target
733	   care-of address (or the entire network this care-of address belongs
734	   to).  But here again could the attacker launch a comparable attack
735	   already without the help of Mobile IPv6, simply by setting up an
736	   upper-layer connection with the victim's IP address.  For instance,
737	   an on-path attacker could perform a TCP handshake on behalf of its
738	   victim, initiating, say, a large file download from an FTP server.
739	   With the TCP sequence numbers at hand, the attacker could also send
740	   acknowledgements on behalf of its victim to keep the data flow going
741	   or even accelerate it.

743	   However, reducing the return-routability procedure's vulnerability to
744	   the routing path is insufficient to prevent a related style of attack
745	   that is called "space- and time-shift attacks".  In these attacks,
746	   the perpetrator taps the critical wire in order to eavesdrop on or
747	   manipulate return-routability messages, and it then moves to a saver
748	   place and starts an impersonation attack from there.  The attacker
749	   may also wait for a better point of time.  It may even install a
750	   binding on behalf of a victim before the victim starts communicating.
751	   The mandatory, periodic registration refreshes defined by RFC 3775
752	   mitigate the threat of space- and time-shift attacks.

754	   The return-routability procedure is such that the correspondent node
755	   does not need to explicitly store the Home or Care-of Keygen Tokens
756	   sent to a mobile node.  The information communicated in the protocol
757	   is sufficient for the correspondent node to re-calculate the token.
758	   This saves the correspondent node from attacks against its memory.
759	   On the other hand, it may open the door for attacks against the
760	   correspondent node's processing capacity.  A token is a SHA-1 hash on
761	   the mobile node's and correspondent node's IP addresses, a random
762	   nonce, and a secret known only to the correspondent node.  The
763	   computational overhead required to do the hash is rather moderate,
764	   although a correspondent node should implement its own policies to
765	   manage resources in a situation of increased processing workload.

767	4.  Objectives for Enhancement

769	   This section identifies areas in which route optimization, as
770	   specified in RFC 3775, may be incompatible with the requirements of
771	   certain applications.  Objectives to enhance route optimization
772	   usually boil down to optimizations to the return-routability
773	   procedure, or alternative mechanisms that may replace the
774	   return-routability procedure.  The enhancement objectives are herein
775	   discussed from a requirements perspective, such as the need for
776	   decreasing latency.  The technical means to reach those objectives is
777	   not considered, nor is the feasibility of achieving them.

779	4.1  Latency Optimizations

781	   A disadvantage of route optimization is that a mobile node must run a
782	   return-routability procedure before it can inform the correspondent
783	   node about its new care-of address.  Therefore, a correspondent
784	   registration consumes, at a minimum, one and a half round-trip times
785	   until the correspondent node receives the BU, assuming that the
786	   mobile node performs the home-address and care-of-address tests in
787	   parallel.  An additional one-way time is needed until the first
788	   packet from the correspondent node, and possibly an optional BA,
789	   arrives at the new care-of address.  Note that the CoTI, CoT, BU are
790	   transmitted on the direct path between the mobile node and the
791	   correspondent node, whereas the HoTI and HoT go through the home
792	   agent.  The actual latency of the return-routability procedure is
793	   governed by the path with a longer round-trip time.

795	   Direct communications to the correspondent node can optimistically
796	   start right after the Binding Update message has been sent (i.e.,
797	   after one round-trip time), but more generally are delayed until the
798	   Binding Acknowledgement message is received (i.e., after two
799	   round-trip times).

801	   Similarly, optimistic mobile nodes are allowed by RFC 3775 to start
802	   their return-routability procedure right after sending a Binding
803	   Update message to their home agent.  They can so reduce the latency
804	   for the correspondent registration.  But more generally, mobile nodes
805	   wait for the home registration to be completed and acknowledged
806	   before initiating the correspondent registration.

808	   Depending on the type of application, the above delays can be an
809	   issue.  Interactive, real-time applications, like voice over IP, are
810	   an example where the delays may cause perceptible quality
811	   degradations.  Even fast bulk-data transfer can be affected if the
812	   lack of packets during the movement period is interpreted as
813	   congestion and leads to a new TCP slow start.  There appears to be
814	   general consensus that faster mechanisms for route optimization are
815	   needed.

817	   Note that the handover delay from an application's perspective is not
818	   just the latency of the IP mobility mechanism, but also includes
819	   delays at the IP layer and the link layer.  In fact, the delays
820	   introduced by the rest of the stack can be significant as well
821	   Section 6.3.1.

823	4.2  Signaling Optimizations

825	   As mentioned in section Section 3, correspondent registrations have a
826	   maximum lifetime of seven minutes and must be refreshed in case they
827	   are not updated to a different care-of address in the meantime.  The
828	   reason for this is to reasonably reduce the window of vulnerability
829	   to time- and space-shift attacks, where an attacker eavesdrops on
830	   unencrypted authentication material exchanged during the
831	   return-routability procedure and launches an impersonation attack at
832	   a later time and from a different, probably more amenable location.
833	   Periodic re-registrations limit the likelihood and feasibility of
834	   such off-path attacks, since the attacker would have to get back on
835	   path whenever the authentication material is due to be refreshed.

837	   A calculation in [2] shows that the seven-minute refreshment interval
838	   implies a signaling overhead of 7.16 bps when a mobile node
839	   communicates with a stationary node.  The overhead doubles if both
840	   peers are mobile.  On one hand, this signaling overhead is certainly
841	   negligible when the nodes actually communicate.  On the other hand,
842	   it may cause problems for mobile nodes that are inactive and stay at
843	   the same location for a while, but still want to have route
844	   optimization ready with some correspondent node.  These nodes
845	   typically prefer to go to standby mode to conserve battery power.

847	   An example where the maintenance of route optimization in the absence
848	   of traffic may be useful is some sort of messenger service that
849	   mobile nodes can subscribe to.  Here, having route optimization in
850	   place would allow the correspondent node in charge of sending the
851	   messages to instantaneously create an efficient connection.  If the
852	   mobile node used bidirectional tunneling instead, the first packet
853	   that the correspondent node sent would be relayed through the home
854	   agent and trigger a correspondent registration upon arrival at the
855	   mobile node.  Since a messenger service is likely to send a few
856	   packets per event only, the belatedly created new correspondent
857	   registration would probably remain completely unused.

859	   Also, the accumulated signaling overhead for route-optimization
860	   maintenance generated by a large customer base may be an issue from a
861	   network provider's point of view.  Not only do the signaling packets
862	   have to be routed through the network, part of them must also be
863	   processed by home agents.  For example, of the 716 Mbps signaling
864	   overhead generated by 100 million route-optimized mobile nodes, 220
865	   Mbps goes through a home agent.

867	   This discussion shows that there are scenarios in which an
868	   optimization for reduced signaling would be beneficial.  These
869	   scenarios are important enough to have an impact on the deployment of
870	   Mobile IPv6.

872	4.3  Security Enhancements

874	   The return-routability procedure is lightway and prevents
875	   mobility-related attacks reasonably well.  In some cases, however,
876	   may better security be useful.  One may in particular attempt to
877	   limit what on-path attackers can do.  Attackers that operate in the
878	   same networks as one of the communication end points are also a
879	   threat that one may want to avoid.  There are existing proposals that
880	   offer higher security in Mobile IPv6 [24] and in other
881	   mobility-management protocols such as HIP [22].

883	   However, even with better security for mobility management can the
884	   Internet as a whole not become any safer than the non-mobile
885	   Internet.  For instance, on-path attackers can cause denial of
886	   service, or inspect and modify cleartext packets, already without
887	   misusing a mobility-management protocol.  Applications that require
888	   strong security are therefore generally advised to end-to-end
889	   mechanisms such as IPsec or TLS.  But even communications that are
890	   protected on an end-to-end basis are vulnerable to denial of service.

892	   Better route-optimization security may become necessary in the
893	   future, if technological improvements remove some of the existing
894	   mobility-unrelated vulnerabilities of the Internet.  For instance,
895	   the use of Secure Neighbor Discovery [20] in a network where one of
896	   the communication end points resides can remove some of the existing
897	   threats.

899	4.4  Applicability Enhancements

901	   As per RFC 3775, a mobile node's home address and current care-of
902	   address are carried in all route-optimized packets.  The course of
903	   the mobile node is therefore trackable, both by the correspondent
904	   node as well as by a third party.  This can be an issue in situations
905	   where the mobile node prefers not to reveal its location.  Location
906	   privacy, however, is inherently not supported by Mobile IPv6 route
907	   optimization.  A workaround is to fall back to bidirectional
908	   tunneling when location privacy becomes an issue.  Packets that carry
909	   the mobile node's care-of address are then only transferred between
910	   the mobile node and the home agent, and they can be encrypted through
911	   IPsec ESP [27][10] on that path.  However, the mobile node may have
912	   to periodically re-establish its IPsec security associations so that
913	   it cannot be tracked through its SPIs.

915	   Scenarios where location privacy is desired are one example where
916	   Mobile IPv6 proves insufficient.  Early improvement efforts have
917	   already started in this area [8][4].  There may also be other
918	   deployment scenarios where the applicability of Mobile IPv6 is
919	   limited and could be extended.

921	5.  Enhancements Toolbox

923	   This section introduces a number of techniques, a "toolbox", that can
924	   be used in the construction of an efficient and secure
925	   route-optimization protocol.  The section starts with the standard
926	   mechanisms used in RFC 3775 and continues with additional techniques
927	   that have been proposed as enhancements or alternatives.

929	   It is important to mention that many enhancements techniques are
930	   insufficient or insecure when applied on their own, because the scope
931	   of each of them is usually limited to a certain sub-issue.  It is the
932	   combination of a set of techniques that makes an efficient and secure
933	   route-optimization mechanism possible.  Different techniques also
934	   have different trade-offs with respect to, say, universal
935	   applicability versus efficiency.

937	5.1  IP-Address Tests

939	   An IP-address test can be employed to ensure that the peer is live
940	   and on the path to a specific destination address.  RFC 3775 uses
941	   IP-address tests for two purposes: The home-address test provides
942	   evidence that a mobile node owns the home address it wants to use;
943	   the care-of-address test serves to preventing flooding attacks
944	   related to spoofed care-of addresses.  As specified in RFC 3775,
945	   IP-address tests can be stateless for the correspondent node, making
946	   their use in denial-of-service attacks harder.

948	   IP-ddress tests are a zero-configuration approach that is independent
949	   of ancillary infrastructure.  The subsequent disadvantage is that
950	   IP-address tests can only guarantee that a peer is on the path to the
951	   probed IP address, not that the peer truly owns this IP address.  On
952	   the other hand, the types of attacks that an on-path attacker can do
953	   with route optimization are the same that an on-path attacker can
954	   anyway do without route optimization, so there is actually no
955	   significant new threat.

957	   The use of two IP-address tests requires four messages.  Both tests
958	   can be performed in parallel, so they can be completed in one
959	   round-trip time.

961	5.2  Protected Tunnels

963	   An additional technique used in RFC 3775 is the protection of a part
964	   of the signaling communications through an authorized and,
965	   optionally, encrypted tunnel between a mobile node and its home
966	   agent.  This prevents other nodes, close to the mobile node, from
967	   seeing a home-address test.

969	   Given the starting point that we cannot assume a pre-existing
970	   end-to-end security relationship between the mobile node and the
971	   correspondent node, this protection exists only for the mobile node's
972	   side.  In case the correspondent node is stationary, the path between
973	   the home agent and the correspondent node remains unprotected.  An
974	   attacker on that path can still perform attacks, but these attacks
975	   are similar to those that an on-path attacker can anyway do without
976	   route optimization.  So, as with IP-address tests, the intent here is
977	   not to introduce any significant new threat to the Internet.  The
978	   same is true in case the correspondent node is mobile.  It then has
979	   its own home agent, and it is the path between the two home agents
980	   that stays unprotected.

982	5.3  Optimistic Behavior

984	   RFC 3775 leaves quite a bit of freedom for a mobile node with respect
985	   to scheduling signaling and data packets.  An optimistic mobile node
986	   can initiate the return-routability procedure right after sending the
987	   BU to its home agent, even before it has gotten a BA back.

989	   The mobile node must wait for the home agent's BA before it can send
990	   a BU to the correspondent node.  However, the mobile node may start
991	   sending data packets to the correspondent node right after it has
992	   sent this BU without having to wait for a BA.

994	   The drawback of the described optimistic behavior is that a dropped,
995	   re-ordered, or rejected BU can cause data packets to be dropped.
996	   Such packet loss would also have an effect on pessimistic signaling,
997	   however.  As a result, further experimentation and simulation may be
998	   needed to quantify to the effects of optimistic techniques under
999	   different conditions.

1001	5.4  Proactive IP-Address Tests

1003	   The post-movement time period during which a mobile node and
1004	   correspondent node cannot fully communicate is oftentimes called the
1005	   "critical phase".  Usually, the critical phase spans a home
1006	   registration and a correspondent registration including a
1007	   return-routability procedure.  One technique to shorten the critical
1008	   phase is to move some of these tasks to an earlier stage.  In
1009	   particular, the home-address test can be done proactively before a
1010	   handover, instead of doing it afterwards, without violating the base
1011	   specification.  This is discussed in [25].

1013	   A Home Keygen Token is generally valid for 3.5 minutes.
1014	   Consequently, the mobile node must initiate a proactive home-address
1015	   test at least every 3.5 minutes if it seeks to have available a fresh
1016	   Home Keygen Token at all times.  This is especially helpful if the
1017	   mobile node cannot foresee the next handover.  Alternatively, the
1018	   mobile node may be able to receive a trigger from its local link
1019	   layer indicating that a handover is imminent.  In this case, the
1020	   mobile node may initiate the home-address test right in time instead
1021	   of doing it periodically every 3.5 minutes.  Note, however, that the
1022	   mobile node must anyway re-initiate the correspondent
1023	   registration--and, thus, the home-address test--after the maximum
1024	   binding lifetime of seven minutes.  Link-layer triggers can therefore
1025	   save the mobile node at most every second home-address test (unless
1026	   they are combined with additional techniques such as [2]).

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

1032	5.5  Concurrent IP-Address Tests

1034	   If one assumes that a mobile node can attach to only a single network
1035	   at a time, executing the care-of-address test proactively before a
1036	   handover is not an option.  However, one may authorize a mobile node
1037	   to start using a new care-of address right after the handover,
1038	   without doing the care-of-address test first, with the restriction
1039	   that a care-of-address test be initiated rightaway.  The peers could
1040	   then already exchange packets through the new care-of address while
1041	   the test is being executed.  In recent literature, one refers to the
1042	   care-of address as "unconfirmed" when the correspondent node does not
1043	   yet know the result of the concurrent care-of-address test, and one
1044	   calls it "confirmed" thereafter.  The lifetime of the associated
1045	   binding can be limited to a few seconds as long as the care-of
1046	   address is unconfirmed, and it can be extended once it becomes
1047	   confirmed.

1049	   It is important to understand that concurrency is legitimate only for
1050	   care-of-address tests.  In contrast, home-address tests are done for
1051	   mobile-node authentication, which must be done before any signaling
1052	   messages are accepted.  Authentication guarantees that only the
1053	   legitimate mobile node can create or update a binding pertaining to
1054	   its home address.  However, both IP-address tests are in general
1055	   simultaneously performed during the critical handover period, and one
1056	   can expect the home-address test to have a longer latency than the
1057	   care-of-address test.  The full benefit of eliminating the
1058	   care-of-address tests from the critical handover period by means of
1059	   concurrency can therefore only unfold if some other mechanism is used
1060	   to move the home-address tests out of the critical handover period as
1061	   well.  For instance, one can do the home-address tests proactively
1062	   before a handover as suggested in Section 5.4, or one may use
1063	   cryptographically generated home addresses as proposed further down
1064	   in Section 5.9.

1066	   Concurrent care-of-address tests were first proposed in [25] where
1067	   they were combined with proactive home-address tests.  In [25], as
1068	   soon as the mobile node has configured a new care-of address after a
1069	   handover, it sends to the correspondent node an Early Binding Update
1070	   (EBU) message.  The mobile node signs the EBU with a
1071	   message-authentication code keyed only with the Home Keygen Token
1072	   that the mobile node has previously retrieved through a proactive
1073	   home-address test.  Upon reception of the EBU, the correspondent node
1074	   creates a tentative binding for the new care-of address, which can
1075	   then be used while the care-of-address test is being executed.  When
1076	   the care-of-address is done, the mobile node sends a standard BU to
1077	   the correspondent node, concluding the registration procedure.

1079	   From the reception of an EBU to the reception of the corresponding
1080	   standard BU, the correspondent node cannot be sure whether the mobile
1081	   node is actually present at the claimed new care-of address.  A
1082	   malicious node may misuse this property to redirect packets to a
1083	   third party's IP address during this phase of uncertainty.  Under
1084	   many circumstances, this will not be acceptable even if the lifetime
1085	   for an unconfirmed care-of address is tentative only, and there needs
1086	   to be external protection.  Techniques like those described in
1087	   Section 5.7 or Section 5.8 can help.

1089	5.6  Diverted Routing

1091	   Given that the per-movement signaling takes some time, a mobile node
1092	   can optionally request its traffic to be routed through its home
1093	   address while this signaling is being completed.  The performance
1094	   impact of this technique depends on the length of the critical phase
1095	   as well as on the capacity and latency of the direct path and the
1096	   path through the home agent.  With respect to the packets that the
1097	   correspondent node sends, the following analysis can be made.

1099	   The correspondent node does not know that the mobile node has moved
1100	   until it has been told about this.  It continues to send packets to
1101	   the mobile node's old care-of address until that time.  These packets
1102	   are usually lost and must be transmitted by upper-layer mechanisms.
1103	   In addition, even the request to delete or deactivate a binding
1104	   requires some security-related signaling to prevent misuse by
1105	   unauthorized nodes.  Zero packet loss can generally only be achieved
1106	   through local repair techniques in the mobile node's access network
1107	   (cf Section 5.14), or if the mobile node can simultaneously attach to
1108	   two IP networks.

1110	   Once the correspondent node knows that the old care-of address is
1111	   stale, it can send further packets to the home address.  If one
1112	   assumes that the correspondent registration for the new care-of
1113	   address involves messages through the home agent, it is obvious that
1114	   at least some of these packets reach the mobile node before the new
1115	   binding is set up.  After all, signaling and data packets travel the
1116	   same path.

1118	   It depends on the capacity and latency of the path through the home
1119	   agent relative to the latency of the direct path for how long the
1120	   correspondent node should continue to send packets to the home
1121	   address.  If the former path has a high latency, it might be better
1122	   to queue some of the packets until the correspondent registration is
1123	   complete and packets can be directly sent to the mobile node.  One
1124	   potential research direction is to look at whether the properties of
1125	   the paths could be learned during the signaling and then used to
1126	   decide the optimal time when the correspondent node should start
1127	   queueing packets.

1129	   The situation for the packets that the mobile node sends is similar:
1130	   Although the mobile node knows immediately that it has moved, RFC
1131	   3775 does not allow the mobile node to route-optimize packets from
1132	   new care-of address until it has formally updated the correspondent
1133	   node about the new care-of address.  Of course, the mobile node may
1134	   buffer packets until the correspondent registration is done so that
1135	   no packets get lost.

1137	   Diverted routing appeared originally in [25] and has since been used
1138	   also in [6].

1140	5.7  Credit-Based Authorization

1142	   As described in Section 5.5, a new care-of address may already be
1143	   used while the care-of-address tests is in progress.  The
1144	   prerequesite is that sufficient protection is provided against
1145	   redirection-based third-party flooding.  One way of doing this is
1146	   authorizing a mobile node to receive packets at a new, unconfirmed
1147	   care-of address based on credit that the mobile node has collected
1148	   with a previous care-of address.  (See Section 5.5 for a definition
1149	   on when a care-of address is confirmed and when it is unconfirmed.)
1150	   This mechanism has become known as Credit-Based Authorization (CBA)
1151	   [26].

1153	   CBA limits the data volume and rate that the correspondent node sends
1154	   during a concurrent care-of-address test such that it does not exceed
1155	   the data volume and rate that the mobile node has sent in the recent
1156	   past.  The intention here is not so much to prevent redirection-based
1157	   flooding attacks altogether as to render impossible any kind of
1158	   amplification that can be achieved through redirection.  It is this
1159	   inherent potential for amplification which constitutes the attraction
1160	   to redirection-based flooding: While the attacker simply does an
1161	   initial connection setup and a subsequent correspondent registration
1162	   for packet redirection, it is the correspondent node which generates
1163	   the packets (typically full-sized TCP segments) that the victim ends
1164	   up having to receive.  Transport-layer acknowledgements can generally
1165	   be faked, so the attacker can easily keep the redirected data stream
1166	   alive.  In the end, the correspondent node spends, unknowingly, much
1167	   more resources on the flooding attack than the attacker itself.  CBA
1168	   renders such amplification impossible.  This makes redirection-based
1169	   flooding attacks very unattractive to the attacker because it would
1170	   take the attacker less coordinative effort, and be at least equally
1171	   effective, if it sent bogus packets to the victim directly.

1173	   Technically, CBA works as follows.  A CBA-enabled correspondent node
1174	   maintains a credit account for each mobile node it communicates with.
1175	   The correspondent node increases the mobile node's credit by the size
1176	   of each inbound packet received from the mobile node.  When the
1177	   correspondent node sends a packet to the mobile node, and a
1178	   concurrent care-of-address test is in progress, the IP address to
1179	   which the packet is sent depends on how much credit is left.  If the
1180	   credit is higher than the size of the outbound packet, that packet is
1181	   directly sent to the mobile node's care-of address.  However, in case
1182	   the remaining credit is too small, the packet is sent to the mobile
1183	   node's home address.  Since the home agent has a trust relationship
1184	   with the mobile node, it can forward these packets to the mobile
1185	   node's care-of address without having to do a reachability check
1186	   first.  Exponential aging limits the lifetime of collected credit.
1187	   This guarantees that the mobile node cannot collect credit over an
1188	   extended time period at a very slow speed and use this credit, all at
1189	   once, for a short but potent data burst towards a faked care-of
1190	   address.

1192	   Allocating a mobile node's credit based on the packets that the
1193	   mobile node sends and reducing the credit based on packets that the
1194	   mobile node receives is defined as CBA mode 1.  With applications
1195	   that send comparable data volumes into both directions, CBA mode 1
1196	   works fine.  On the other hand, CBA mode 1 may prevent the mobile
1197	   node from collecting the amount of credit it needs for a handover
1198	   when applications with asymmetric traffic patterns are in use.  For
1199	   instance, file transfers and media streaming are characterized by
1200	   high throughput towards the client, typically the mobile node, and
1201	   comparably little throughput towards the serving correspondent node.
1202	   To better accommodate such applications, a second CBA mode was
1203	   designed.

1205	   With CBA mode 2, credit allocation is based on packets that the
1206	   mobile node receives from the correspondent node rather than on
1207	   packets that the mobile node sends.  New credit is allocated while
1208	   the mobile node's current care-of address is confirmed; existing
1209	   credit is used up while the care-of address is unconfirmed.  Thus,
1210	   its is the data flow from the correspondent node to the mobile node
1211	   that is responsible for both credit allocation and reduction,
1212	   resolving the issue with applications producing asymmetric traffic
1213	   patterns.

1215	   It is less obvious why CBA mode 2 outrules flooding-attack
1216	   amplification than it is for CBA mode 1.  The key observation is that
1217	   a mobile node invests comparable effort for packet reception as for
1218	   packet transmission, in terms of bandwidth, memory, and processing
1219	   capacity.  It is therefore legitimate to give a mobile node credit
1220	   for packets that it has received and processed.  The question is,
1221	   though, how the correspondent node can determine how many of the
1222	   packets sent to a mobile node are actually received and processed by
1223	   that mobile node.  As mentioned above, relying on transport-layer
1224	   acknowledgements is not an option as such messages can easily be
1225	   faked.  CBA mode 2 hence defines its own feedback mechanism, Care-of
1226	   Address Spot Checks, which is much more robust to spoofing.  With
1227	   Care-of Address Spot Checks, the correspondent node periodically tags
1228	   packets that it sends to the mobile node with a random, unguessable
1229	   number, a so-called Spot Check Token.  When the mobile node receives
1230	   a packet with an attached Spot Check Token, it buffers the token
1231	   until it sends the next packet to the correspondent node.  The Spot
1232	   Check Token is then included in this packet.  Upon reception, the
1233	   correspondent node verifies whether the returned Spot Check Token
1234	   matches a token recently sent to the mobile node.  New credit is
1235	   allocated in proportion to the ratio between the number of
1236	   successfully returned Spot Check Tokens and the total number of
1237	   tokens sent.  This implies that new credit is approximately
1238	   proportional to the fraction of packets have made their way at least
1239	   up to the mobile node's IPv6 stack.  The preciseness of Care-of
1240	   Address Spot Checks can be traded with overhead through the frequency
1241	   with which packets are tagged with Spot Check Tokens.

1243	5.8  Heuristic Monitoring

1245	   Heuristic approaches to protect concurrent care-of-address tests are
1246	   conceivable as well.  For instance, one may consider a lifetime limit
1247	   for unconfirmed care-of addresses which, supplemented by a heuristic
1248	   for misuse detection, can prevent, or at least effectually
1249	   discourage, misuse of such addresses.  The challenge here seems to be
1250	   a feasible heuristic: On one hand, the heuristic must be sufficiently
1251	   rigid to catch any malicious intents at the other side.  On the other
1252	   hand, it should not have a negative impact on a fair-minded mobile
1253	   node's communications.

1255	   Another problem with heuristics is that they are usually reactive.
1256	   The correspondent node can only respond to misbehavior after it
1257	   appeared.  If the response comes quickly, attacks may simply not be
1258	   worthwhile.  But premature actions should be avoided, of course.  One
1259	   must also bear in mind that an attacker may be able to use different
1260	   home addresses, and it in general hard for the correspondent node to
1261	   see that the set of home addresses belongs to the same node.  The
1262	   attacker may also use multiple correspondent nodes for its attack in
1263	   an attempt to amplify the result.

1265	5.9  Cryptographically Bound Identifiers

1267	   Cryptographically Generated Addresses (CGA) offer a method for
1268	   binding a public key to an IP address.  A CGA is an IPv6 address with
1269	   a standard routing prefix and an interface identifier generated from
1270	   a hash on the CGA owner's public key and some additional parameters.
1271	   A CGA allows the owner to assert a claim on its address: It can sign
1272	   a to-be-authenticated message with its private key and attach its
1273	   public key along the parameters necessary to recompute the CGA.  The
1274	   recipient of this message can then verify whether the address is
1275	   correct.

1277	   CGAs offer three main advantages: First, spoofing attacks against a
1278	   CGA are much harder than attacks against a normal IP address.  Though
1279	   an attacker may always create its own CGA, it is unlikely to find a
1280	   public/private key pair that produces someone else's CGA.  Second,
1281	   CGA-based authentication works entirely end-to-end; it does not
1282	   depend on a certification infrastructure.  Third, CGAs are
1283	   syntactically just ordinary IPv6 addresses.  Their additional
1284	   semantics do not require any upgrade or modification to the Internet.

1286	   Many applications are conceivable where CGAs can be advantageous.  In
1287	   Mobile IPv6, CGAs can bind a mobile node's home or care-of address to
1288	   its public key.  CGAs were originally described in [36] and in [37],
1289	   and they have later been used in [24], [19], [6], and others.

1291	   One limitation of CGAs is that the hash on the CGA owner's public key
1292	   can only be 62 bits long.  The rest of the address is occupied by a
1293	   64-bit routing prefix as well as the universal/local and
1294	   individual/group bits.  A brute-force attacker might thus be able to
1295	   find a public/private key pair that produces a certain CGA.  It could
1296	   then claim ownership over this CGA.  The threat can usually be
1297	   contained by including the address prefix in the hash computation, so
1298	   that an attacker, in case it did find the right public/private key
1299	   pair, could not form CGAs for multiple networks from it.

1301	   Higher security can be achieved through longer cryptographically
1302	   bound identifiers.  For instance, a node's primary identifier in the
1303	   "Host Identity Protocol" (HIP) [22] is a 128-bit hash on the node's
1304	   public key.  It is used as an IP-address replacement at stack layers
1305	   above IP.  On the other hand, a 128-bit identifier is not routable,
1306	   so there needs to be some external location mechanism if a node wants
1307	   to contact a peer of which it only knows the identifier.

1309	5.10  Pre-Configuration

1311	   The return-routability procedure was designed for communication peers
1312	   that do not share an a-priori security association.  In order to
1313	   thwart off-path attacks nonetheless, the procedure can establish only
1314	   very short-living security associations.  However, in certain,
1315	   restricted scenarios, it may be possible to pre-configure mobile and
1316	   correspondent nodes with security associations.  Such security
1317	   associations can have much longer lifetimes because pre-configuration
1318	   is inherently more secure than the plaintext token exchange from the
1319	   return-routability procedure.

1321	   Pre-configuration has two major benefits.  The first one is strong,
1322	   cryptographic authentication and encryption, which can be applied to
1323	   both signaling and data packets.  The second advantage is lower
1324	   signaling delay, because the additional round-trip time otherwise
1325	   needed for the return-routability procedure can be spared.  The
1326	   obvious disadvantage of pre-configuration is its limited
1327	   applicability.

1329	   It is important to recognize the necessity to unambiguously bind a
1330	   security association to the home address that it is to protect.  With
1331	   regards to the return-routability procedure, this binding is realized
1332	   by routing the HoTI and HoT through the home address.  In the case of
1333	   a pre-configured security association, the association must be
1334	   related to the home address as part of the configuration.  Note that
1335	   this affects both secret-key and public-key cryptography.

1337	   Two proposals for pre-configuration are currently under discussion in
1338	   the IETF as optional enhancements to RFC 3775.  [15] re-uses most
1339	   from the standard authentication and authorization procedure defined
1340	   in RFC 3775.  The only difference is that mobile nodes are endowed
1341	   with the information they need to compute Home and Care-of Keygen
1342	   Tokens themselves rather than having to obtain them through the
1343	   return-routability procedure.  [5] replaces the standard RFC-3775
1344	   concepts with IPsec and the Internet Key Exchange (IKE) protocol.

1346	   From a technical standpoint, a pre-configured security association
1347	   can only replace a home-address test, not a care-of-address test.
1348	   After all, a correspondent node cannot verify, based on the
1349	   association alone, whether a mobile node is actually present at the
1350	   announced care-of address.  The problem can be circumvented by
1351	   postulating that the correspondent node has sufficient trust in the
1352	   mobile node to believe that the care-of address is correct.  However,
1353	   this assumption, which is made in [15], discourages the use of
1354	   pre-configuration in scenarios where such trust is unavailable.  For
1355	   instance, a mobile-phone operator may be able to configure
1356	   subscribers with secret keys for authorization to a particular
1357	   service, but it may not be able to vouch that all subscribers use
1358	   this service in a trustworthy manner.

1360	   Another way to avoid the problem of care-of-address verification is
1361	   to rely on access networks to filter out packets with incorrect IP
1362	   source addresses (cf.  Section 5.12).  This approach is taken in [5].
1363	   However, the problem with local filtering is that it must be deployed
1364	   everywhere an attacker may possibly access the Internet in order to
1365	   be fully protective.  Otherwise, an attacker can always find a place
1366	   from where a spoofing attack is possible, endangering IP nodes
1367	   anywhere.  As things stand, the assumption that deployment of
1368	   filtering techniques be universal is speculative.

1370	   Both of the above two assumptions can be eliminated through
1371	   care-of-address tests, facilitating the use of pre-configuration in
1372	   spite of lacking trust relationships or the existence of acess
1373	   networks without local filtering techniques.  Care-of-address tests
1374	   can be made concurrent for higher efficiency.

1376	5.11  Semi-Permanent Security Associations

1378	   A middle-way approach in between the return-routatibility procedure's
1379	   short-term security associations and pre-configured permanent ones is
1380	   to dynamically set up a semi-permanent security association upon
1381	   first contact, and to use it to authenticate signaling over a longer
1382	   period.  Subsequent signaling can then be unambiguously bound to the
1383	   initial contact.

1385	   On-demand security associations for IPsec are traditionally
1386	   established by executing IKE between two peers.  This works well when
1387	   the negotiated keys are securely bound to the entity that they are to
1388	   protect.  For instance, in HIP, the guarded entity is a 128-bit
1389	   identifier which can be derived from the owner's public key through a
1390	   hash function.  In Mobile IPv6, however, the to-be-protected entity
1391	   is a plain IPv6 home address, which is syntactically
1392	   indistinguishable from other IPv6 addresses.  Given that no direct
1393	   authentication between the peers is generally feasible, there is no
1394	   way for a mobile node to prove possession of its home address either.
1395	   This would allow an attacker to do the IKE exchange with an arbitrary
1396	   victim's IP address, and to discretionarily redirect the victim's
1397	   traffic from that time on.  Although the attacker would have to be on
1398	   the path between the victim and the correspondent node while running
1399	   IKE, it could move off the path once the keys have been exchanged.
1400	   As the victim lacks the keys, it cannot even re-claim its IP address.

1402	   As a result, dynamic semi-permanent security associations must be
1403	   bound to the right home addresses through some additional technique
1404	   when used in the context of Mobile IPv6.  For instance, they can be
1405	   combined with an initial, one-time home-address test, or IKE can be
1406	   run through the home address.  Another way is using CGAs as proposed
1407	   in [6].

1409	   No matter how they are secured, dynamic semi-permanent security
1410	   associations cannot be leveraged to prove the correctness of a
1411	   care-of address.  They hence fail to solve the problem with
1412	   redirection-based flooding attacks, and should only be applied in
1413	   conjunction with care-of-address tests.  Semi-permanent security
1414	   associations were first developed in [3] where they were called
1415	   "Purpose Built Keys" (PBK).

1417	5.12  Infrastructure

1419	   Infrastructure can provide assistance by vouching for the
1420	   authenticity of a home address, the correctness of a care-of address,
1421	   or the trustworthiness of a mobile node.  Infrastructure can take
1422	   many forms, such as a PKI tailored for route optimization, or an AAA
1423	   infrastructure enhanced with the required features.

1425	   In its basic form, such an infrastructure hands out home addresses
1426	   and associates a key with each home address.  It may also produce
1427	   certificates that can be used by others to verify the binding between
1428	   a key and a home address, or it may provide a query interface where
1429	   this verification is performed within the infrastructure.

1431	   Setting up this type of infrastructure has generally been considered
1432	   impossible for general Internet use.  One of the problems is the
1433	   current separation of IP-address assignment and security
1434	   infrastructures.  However, Certificate-based Binding Updates (CBU)
1435	   [23] are a useful simplification: A home agent is assigned a
1436	   certificate that binds the home-network prefix to the home agent's
1437	   public key.  Correspondent nodes can trust the home agent based on
1438	   the certificate, and the home agent vouches for the trustworthiness
1439	   of the mobile nodes it serves.  The advantage is that, rather than
1440	   having to issue a certificate per mobile node, only a certificate per
1441	   home-network prefix is required.  This makes the infrastructure
1442	   problem more tractable.  Furthermore, the home agent may help to
1443	   establish an end-to-end security association between the mobile node
1444	   and the correspondent node so that subsequent messages can be
1445	   securely exchanged on the direct path between the communicating
1446	   peers.  This allows for improved signaling delay during later
1447	   handovers.

1449	   The infrastructure can also help to separate the trustworthy mobile
1450	   nodes from the non-trustworthy ones.  Together with an identifier for
1451	   each mobile node, this could be used to retroactively track down
1452	   misbehaving nodes.

1454	   AAA architectures are another approach to mobile-node authentication.
1455	   A home AAA server, which may or may not be co-located with the home
1456	   agent, can then contact a remote AAA server in the correspondent
1457	   node's network.  Note that this moves some of the authentication
1458	   overhead from the correspondent node to the remote AAA server.  An
1459	   AAA-based approach can also dynamically assign mobile-node requests
1460	   to different correspondent nodes while keeping secret authenticating
1461	   material local at a single AAA server.

1463	   Verification of care-of addresses may be based on infrastructure in
1464	   the mobile node's local access network.  For instance, as a care-of
1465	   address normally appears as a BU's IP source address, the
1466	   infrastructure can verify that the IP source addresses of all packets
1467	   leaving the network are correct.  Ingress filtering [34] provides
1468	   this feature to the extent that only the prefix of an outbound
1469	   packet's IP source address is inspected.  The pertinence of this
1470	   check strongly depends on whether it is done directly in the access
1471	   router or further up the packet's path.

1473	   The problem with verifying a care-of address at the fringe of the
1474	   Internet is that there is no way for a remote correspondent node to
1475	   decide whether a packet has really undergone a check or not.  And
1476	   although many access networks today already do ingress filtering, an
1477	   attacker can always find a network where such a technique is not
1478	   deployed.

1480	   A more secure approach to care-of-address verification is hence to
1481	   let the correspondent node itself verify a mobile node's care-of
1482	   address by querying a piece of infrastructure, located in the mobile
1483	   node's access network, about the mobile node's presence at a
1484	   particular care-of address.  For this, the mobile node would have to
1485	   be identifiable by means known to both the correspondent node and the
1486	   infrastructure.  If the care-of address is cryptographically
1487	   generated (cf.  Section 5.9) and configured through Secure Neighbor
1488	   Discovery [20], the mobile node can be securely identified by the
1489	   care-of address alone.  Otherwise, if CGAs are unavailable, an
1490	   additional PKI or AAA architecture is needed to distribute the
1491	   required credentials.

1493	5.13  Local Mobility

1495	   Mobile IPv6 handles all mobility on an end-to-end basis.  However, it
1496	   may sometimes make sense to handle part of a mobile node's movements
1497	   entirely within the local access network.  This can yield performance
1498	   improvements in terms of signaling overhead and handover latency.

1500	   Hierarchical Mobile IPv6 [18] is an optimization of RFC 3775 for
1501	   local mobility support.  It introduces the concept of a regional
1502	   Mobile Anchor Point (MAP) that acts as a local home agent towards
1503	   visiting mobile nodes and proxies them towards their home agents and
1504	   correspondent nodes.  When a mobile node enters a visited network, it
1505	   configures an "on-link care-of address", like in RFC 3775, and a
1506	   wider-scope "regional care-of address" from a MAP's network.  The
1507	   mobile node registers a binding between the two care-of addresses
1508	   with the MAP, and it uses the regional care-of address for
1509	   communicating with nodes outside the local network.  When the mobile
1510	   node moves to a different network within the same MAP's realm, it
1511	   configures a new on-link care-of address, but keeps its regional
1512	   care-of address.  For the outside world it thus seems as if the
1513	   mobile node was stationary within the MAP's network.

1515	   The mobile node may in addition register the regional care-of address
1516	   with its own home agent and its correspondent nodes.  This allows the
1517	   mobile node to roam between the domains of different MAPs without
1518	   breaking ongoing communication connections.

1520	5.14  Local Repair

1522	   When a mobile node moves from one IP-attachment point to another,
1523	   some packets are likely to be still in flight towards the old
1524	   location.  Local repair techniques can be used to forward these
1525	   packets to the new IP-attachment point.  This can be done through a
1526	   tunnel or a host route between the old and new access router.

1528	   Local repair usually implies that packets are buffered at the old or
1529	   new access network.  If the mobile node leaves the old access network
1530	   without telling its new care-of address, it must signal this
1531	   information back subsequently.  In-flight packets arriving at the old
1532	   network should in this case be buffered until the mobile node's new
1533	   location is known.  Alternatively, the mobile node may be able to
1534	   proactively determine its new care-of address before it moves.
1535	   In-flight packets can then immediately be forwarded to the new
1536	   location, where they probably have to be buffered for a little while
1537	   until the mobile node arrives.  A protocol that supports both modes
1538	   is defined in [17].

1540	5.15  Assisted Auto-Configuration

1542	   The local network may assist a mobile node in finding a new access
1543	   router to which it can handover.  For instance, in [17], the mobile
1544	   node can search for a suitable access point and ask its current
1545	   access router to proxy-advertise the router to which this access
1546	   point is attached.

1548	   Additionally, the local network may support the mobile node in
1549	   configuring a new care-of address from its old link.  In [17], after
1550	   the mobile node has determined the access router that it wants to
1551	   handover to, it may suggest a new care-of address.  The candidate
1552	   care-of address is signaled to the prospective access router which
1553	   performs DAD on the care-of address and signals the result back to
1554	   the mobile node.  The new access router also performs Proxy Neighbor
1555	   Discovery in case the new care-of address is available.

1557	   Assisted auto-configuration can have enormous performance benefits,
1558	   especially when combined with local repair techniques.  A
1559	   disadvantage is the investments for setting up the required
1560	   infrastructure.  Also, local support must be provided in both the old
1561	   and the new access network, so handovers between different
1562	   administrative domains may be problematic.

1564	5.16  Processing Improvements

1566	   One goal for designing the return-routability procedure was low
1567	   computational complexity.  The processing overhead for route
1568	   optimization should thus be acceptable in general.  However,
1569	   mechanisms alternative to the return-routability procedure, such as
1570	   public-key cryptography, may be more taxing on processing resources.
1571	   Here, it may help to replace RSA algorithms with ECC techniques.
1572	   Moreover, even the low-complexity cryptographic algorithms used in
1573	   the return-routability procedure may be too expensive for very busy
1574	   servers.

1576	5.17  Delegation

1578	   Given that the home agent does not need to move or conserve battery
1579	   energy, it can be used for performing computationally expensive
1580	   tasks.  It can also be used for parts of the signaling in order to
1581	   reduce communications over slow wireless links.  Some work relating
1582	   to delegation has been done in [24], [23], and [32].

1584	6.  Analysis

1586	   This section analyzes the techniques presented in Section 5 in
1587	   relation to each other and in the context of the enhancement
1588	   objectives described in Section 4.  The techniques are categorized
1589	   first.  Some recent proposals for route-optimization enhancement,
1590	   which rely on one or combine multiple of these techniques, are
1591	   subsequently evaluated.  The section concludes with a number of
1592	   opportunities for further research in the area of route optimization.

1594	6.1  Categorization of Techniques

1596	   Local techniques include support for micro-mobility, route repair,
1597	   and assisted auto-configuration.  They seek to reduce or eliminate
1598	   long end-to-end round-trip times or delays caused by standard
1599	   auto-configuration techniques.  Local techniques have traditionally
1600	   been implemented in a manner that requires configuration, but there
1601	   appears to be no fundamental reason why this would have to be so.

1603	   IP-address tests, which may be proactive or concurrent, credit-based
1604	   authorization, heuristic monitoring, CGAs, semi-permanent security
1605	   associations, and cryptographically bound identifiers are end-to-end
1606	   techniques.  They are independent of local network support and are
1607	   thus very flexible.  They may also be inexpensive to deploy.  The
1608	   cost for these advantages is typically a smaller performance gain
1609	   compared to local mechanisms due to global, thus potentially long,
1610	   round-trip times.

1612	   Zero-configuration techniques require no prior configuration or
1613	   assistance from a managed infrastructure.  IP-address tests, diverted
1614	   routing, credit-based authorization, heuristic monitoring, CGAs,
1615	   semi-permanent security associations, cryptographically bound
1616	   identifiers, processing improvements, and delegation are
1617	   zero-configuration techniques.  Mechanisms that require
1618	   pre-configuration or some kind of infrastructure are not among
1619	   zero-configuration techniques.

1621	6.2  Evaluation of Recent Proposals

1623	6.2.1  Local Assistance

1625	   There are currently two proposals in the IETF for local mobility
1626	   assistance, Hierarchical Mobile IPv6 and Fast Handovers for Mobile
1627	   IPv6.  Hierarchical Mobile IPv6 (HMIPv6) [18] screens a mobile node's
1628	   movements within a MAP domain from nodes not inside that domain.  In
1629	   case standard Mobile IPv6 is used end-to-end, this eliminates most of
1630	   the global signaling: While its regional care-of address does not
1631	   change, a mobile node does not need to update its home agent or
1632	   correspondent nodes beyond the mandatory periodic refreshments.  Not
1633	   having to signal on a global basis also reduces handover latency.

1635	   Updates to the home agent and to correspondent nodes are necessary
1636	   only when the mobile node leaves the current MAP domain.  The mobile
1637	   node may then register a new regional care-of address with a
1638	   different MAP if one is available.  Note that switching MAPs usually
1639	   requires the mobile node to signal more than if standard Mobile IPv6
1640	   was used alone.  Local and end-to-end signaling then comes together
1641	   because, as it stands, a mobile node must contact the new MAP
1642	   separately from its home agent and correspondent nodes.  Due to
1643	   dependencies between a MAP registration and a contemporary home or
1644	   correspondent registration, a mobile node may want to wait for the
1645	   MAP registration to complete before it initiates the standard Mobile
1646	   IPv6 registration procedure.  Handover latency is then increased in
1647	   addition to the signaling overhead.  Future work could thus go into
1648	   the integration of MAP registrations with standard Mobile IPv6
1649	   signaling.

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

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

1666	   The second local optimization, Fast Handovers for Mobile IPv6
1667	   (FMIPv6) [17], streamlines the router-discovery and
1668	   IPv6-address-configuration processes, and it facilitates lossless
1669	   handovers.  FMIPv6 assumes that access routers are capable of
1670	   matching a neighboring access point to the access router to which it
1671	   attaches.  The capability is a prerequisite for proxy router
1672	   discovery.  Yet, it is still an open issue how access routers learn
1673	   about this information.  Manual configuration is one option, though
1674	   it can be extremely expensive.  More attractive would be an automated
1675	   mechanism that allows access routers to dynamically recognize access
1676	   points to which mobile nodes may want to switch.  A related issue is
1677	   how such knowledge can be securely obtained across the borders of
1678	   administrative sites.  These are opportunities for future research.

1680	   Note that Hierarchical Mobile IPv6 is applicable even when Mobile
1681	   IPv6 is not used beyond the local domain.  I.e., a mobile node may
1682	   use its regional care-of address as a temporary home address.  The
1683	   mobile node would thus appear to a correspondent node as a stationary
1684	   node in the MAP's network.  This allows the mobile node to keep its
1685	   movements private as long as it stays within the same MAP domain.
1686	   FMIPv6 can be used in combination with standard Mobile IPv6, HMIPv6,
1687	   or both, but it cannot be used without either.

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

1697	6.2.2  Pre-Configuration

1699	   The Home Keygen Token exchange from the return-routability procedure
1700	   is the default authentication technique used in Mobile IPv6.  It
1701	   facilitates reasonable security even between nodes that have no
1702	   pre-existing relationship.  On the other hand, nodes that do share a
1703	   common secret should be allowed to omit the home-address test.  This
1704	   can be beneficial in certain scenarios where the home-address test
1705	   causes a long handover latency due to packet redirection through the
1706	   home agent.  Note that a shared secret cannot replace the
1707	   care-of-address test.  Eliminating the care-of-address test requires
1708	   some sort of trust into mobile nodes not to spoof a care-of address.
1709	   The pre-configuration approach standardized in the IETF [15] uses a
1710	   shared secret between the mobile node and the correspondent node, and
1711	   it assumes that mobile nodes are trustworthy.

1713	   The assumption that mobile nodes be fair-minded turns out to be quite
1714	   far stretching.  On on side, it affords the elimination of the entire
1715	   return-routability procedure, not just the Home Keygen Token
1716	   exchange.  As explained in [15], and as it can also be inferred from
1717	   figure Figure 1, this cuts the average handover latency in half.  On
1718	   the other hand, the assumption significantly limits the applicability
1719	   of the optimization.  There are certainly scenarios where
1720	   pre-configuration per se would be possible, but no trust model can be
1721	   assumed.  For instance, an ISP may configure its media servers with
1722	   the keys of its customers.  The customers could then use
1723	   pre-configured Mobile IPv6 for communications with the media servers,
1724	   but some customers might misuse the lack of a care-of-address test to
1725	   wage a redirection-based flooding attack against a third party.  This
1726	   example reveals the difference between a security association for
1727	   authentication and a trust relationship for misuse prevention.

1729	   In an effort to extend pre-configuration to scenarios where no trust
1730	   relationship can be presupposed, one may combine it with
1731	   care-of-address tests.  Of course, using a care-of-address test
1732	   partly vitiates the handover-latency improvement that can be reached
1733	   otherwise.  But there may still be a positive impact on handover
1734	   latency, because pre-configuration eliminates the triangular
1735	   home-address test through the home agent, whereas the care-of-address
1736	   test uses the direct, and typically faster, path between the
1737	   communicating nodes.  For increased performance, a concurrent
1738	   care-of-address test can be used in combination with credit-based
1739	   authorization or heuristic monitoring.  It should also be noted that
1740	   pre-configuration facilitates stronger authentication mechanisms than
1741	   the return-routability procedure, and thus the use of route
1742	   optimization may become more suitable for applications with high
1743	   security requirements.

1745	   These things said, it seems like a good idea to make the
1746	   pre-configuration protocol bendable to different environments.  Is
1747	   there a small group of people who trust each other? Then, of course,
1748	   group members are unlikely to spoof care-of addresses, and the
1749	   care-of-address test may be omitted.  Or is the group of users large
1750	   and users are primarily unknown to each other like the customer base
1751	   of a big ISP? Then, proper authentication does usually not imply
1752	   trust, and it may not be feasible to use pre-configured keys without
1753	   checking a mobile node's reachability.  Traceability techniques are
1754	   not necessarily a compensation for the missing care-of-address test,
1755	   because they are a reactive measure, whereas a care-of-address test
1756	   is a proactive one.

1758	6.2.3  CGA-Based Optimizations

1760	   CGAs can guarantee that a mobile node is the legitimate owner of its
1761	   home address.  They provide higher assurance than the pure use of
1762	   routing paths.  This facilitates a significant reduction in the
1763	   number of signaling messages per correspondent registration as well
1764	   as the periodicity of these registrations.  In addition, the public
1765	   keys used in the CGA technique allow packets to be transferred
1766	   privately, a feature that can be used for both data encryption and
1767	   for other route-optimization enhancements.

1769	   CGA may also be used to reduce the risk of flooding attacks via
1770	   care-of addresses, as attackers should be unable to generate a
1771	   private/public-key pair of which the public key hashes to a
1772	   particular victim's IP address.  However, only the interface
1773	   identifier of a CGA is cryptographically generated, so flooding a
1774	   network or a link is still an issue.  As a result, CGAs should be
1775	   employed together with a care-of-address test in scenarios where
1776	   redirection-based flooding attacks are a concern.  Similarly, an
1777	   initial home-address test is typically required, too, in order to
1778	   avoid that the deletion of a binding causes a flood upon a faked home
1779	   address.

1781	   To resolve collisions in case CGAs are used as care-of addresses, a
1782	   collision count is part of the input to the CGA hash function.
1783	   Increasing the collision count by one changes the result of the hash
1784	   function, so new CGAs can be successively tried until an unused one
1785	   is found.  On the other hand, the collision count also helps an
1786	   attacker in faking a CGA: It may use the same private/public-key pair
1787	   to efficiently generate multiple CGAs.  For this reason, the
1788	   collision count should usually be limited to a few bytes only.

1790	6.2.4  Credit-Based Authorization

1792	   With CBA, a new care-of address can be probed in parallel with
1793	   already using it.  This eliminates the handover latency that the
1794	   reachability check entails when performed during the critical
1795	   handover period.  Depending on how much credit a mobile node has at
1796	   the time of handover, packets are either routed via its home network
1797	   or directly to its care-of address.  The performance benefits depend
1798	   on the relative delay characteristics of the direct path between the
1799	   communicating peers and the path through the home agent.  They also
1800	   depend on how fast the transport-layer protocol in use detects and
1801	   retransmits lost packets.

1803	   CBA depends on the mobile node being able to collect an amount of
1804	   credit high enough to bring it through the next handover.  How easy
1805	   it is for a mobile node to acquire new credit depends on the CBA
1806	   mode, on the credit-aging factor, and on the application's traffic
1807	   patterns.  (See Section 5.7 for a description of the two CBA modes.)
1808	   In general, applications with symmetric traffic patterns make it easy
1809	   for the mobile node to get sufficient credit.  CBA mode 1, however,
1810	   can be problematic when most data is sent from the correspondent node
1811	   to the mobile node unless the credit-aging factor is very small.  The
1812	   reason is that, in this mode, earned credit is proportional to
1813	   packets sent to the correspondent node, whereas spent credit is
1814	   proportional to packets going into the opposite direction.  Also, CBA
1815	   does not work well in either mode if the mobile node moves so rapidly
1816	   that it does not manage to refill its credit account between two
1817	   successive handovers.

1819	   Note that CBA is an optimization technique which can be integrated
1820	   into any mobility-management protocol that verifies IP addresses
1821	   through probing.  Protocols that may benefit are, for instance, other
1822	   Mobile IPv6 optimization techniques described in this paper such as
1823	   CGA-based ones (cf.  Section 5.9).  Also, when Mobile IPv6 is used
1824	   with pre-configured shared keys between mobile nodes and
1825	   correspondent nodes (cf.  Section 6.2.2), but reachability checks are
1826	   still prescribed to ensure that properly authenticated mobile nodes
1827	   do not lie about their care-of address, CBA may be applied to
1828	   eliminate the additional cost that the reachability checks would
1829	   otherwise entail.  Moreover, in scenarios where a home agent cannot
1830	   trust in the correctness of the registered mobile nodes' care-of
1831	   addresses, CBA-based concurrent care-of-address tests could be
1832	   proscribed even for home registrations.  The same is true for
1833	   Hierarchical Mobile IPv6, which, as it stands, assumes that a MAP can
1834	   be confident that mobile nodes use correct on-link care-of addresses,
1835	   and so gets around the care-of-address test.

1837	   Furthermore, CBA may also be used to parallelize reachability checks
1838	   in the Host Identity Protocol (HIP) [22] and current Mobike
1839	   proposals.  Note, however, that mobility-management protocols in
1840	   general do not have an equivalent to Mobile IPv6's static home
1841	   addresses through which mobile nodes stay reachable at all times.
1842	   Hence, temporarily routing a mobile node's packets through a static
1843	   IP address in case this mobile node runs out of credit during a
1844	   handover may not always be an option.

1846	   A nice property of CBA mode 1 is that it does not require support
1847	   from the mobile node.  The mobile node neither needs to understand
1848	   that CBA is effective at the correspondent node, nor does it have to
1849	   have an idea of how much credit it currently has.  A legitimate
1850	   question is whether this is true even if the correspondent node may
1851	   temporarily send packets to the home address of a mobile node that
1852	   has run out of credit.  After all, RFC 3775 suggests that mobile
1853	   nodes interpret the reception of a tunneled packet as a hint to
1854	   initiate a new correspondent registration, which would obviously be
1855	   inappropriate in the described situation.  The answer is that all
1856	   correspondent registration are subject to rate limiting, so mobile
1857	   nodes can be expected not to misunderstand tunneled packets during
1858	   the handover procedure.

1860	   Care-of Address Spot Checks must be responded to by a mobile node.
1861	   Consequently, CBA mode 2 can only be implemented transparently to the
1862	   mobile node in scenarios where packet loss is not an issue and
1863	   Care-of Address Spot Checks can be omitted.

1865	   Last, but not least, an interesting question is whether CBA mode 2
1866	   could be misused by an attacker that has an asymmetric connection to
1867	   the Internet.  Wide-spread digital subscriber lines (DSL), for
1868	   instance, typically have a much higher download rate than upload
1869	   rate.  The limited upload rate would render most denial-of-service
1870	   attempts through direct flooding meaningless.  But the strong
1871	   download rate could be misused to illegitimately build up credit at
1872	   one or many correspondent nodes.  The credit could then be used for a
1873	   more potent, redirection-based flooding attack.  The reason why this
1874	   has so far not been considered an issue is that, in order to build up
1875	   enough credit at the remote end, the attacker would first have to
1876	   expose itself to the same packet flood that it could then redirect
1877	   towards the victim.  This is obviously true with respect to data
1878	   volume.  Since credit is aged over time, it also applies to the data
1879	   rate.

1881	6.2.5  Prefix-Based Certificates

1883	   The Mobile IPv6 base specification avoids strong authentication
1884	   cryptography for signaling between mobile nodes and correspondent
1885	   nodes.  One reason for this is the impracticality of a global trusted
1886	   PKI that could approve bindings between the mobile nodes' identities
1887	   and public keys.  Another reason is that limited power resources and
1888	   processing capacity at the mobile nodes generally rule out any
1889	   complex cryptographic operations.  Robustness to resource-exhaustion
1890	   attacks requires a similar restrictiveness on the correspondent-node
1891	   side.

1893	   CBU circumvents the lack of a global PKI.  The reduction in the
1894	   number of potentially required certificates makes certificate-based
1895	   approaches to mobile-node authentication more feasible than it is
1896	   today.  The approach also avoids heavy computations at mobile nodes
1897	   since public-key cryptography is handled by the home agent.  On the
1898	   other hand, the processing overhead at correspondent nodes actually
1899	   increases compared to standard correspondent registrations.  This may
1900	   not be an issue since resources at stationary correspondent nodes are
1901	   usually higher than those of many mobile devices.  But it may be an
1902	   issue if the correspondent node is a popular web server or other
1903	   central resource that cannot afford doing complex cryptographic
1904	   operations.  One should, however, bear in mind that the increased
1905	   overhand implies a higher risk to resource-exhaustion attacks.

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

1916	   There is ongoing work on the integration of AAA with Mobile IPv6
1917	   [13].  The current focus is on authentication between mobile nodes
1918	   and home agents with the intention to replace the IPsec-based
1919	   authentication protocol for home registrations.  But the concept of
1920	   security proxies proposed in [23] may as well be re-used for
1921	   enhancements to the AAA infrastructure.

1923	6.3  Future Research

1925	   Mobility-related optimizations are currently actively studied by many
1926	   researchers at different protocol layers.  The preceding sections
1927	   identify ideas and existing proposals for enhancing route
1928	   optimization.  While some of the basic methods are fairly well
1929	   understood and are being deployed, there are a number of interesting,
1930	   newer approaches that deserve to be studied in more detail.  This
1931	   section discusses research directions that appear fruitful, or
1932	   necessary in the future, and that go beyond the existing proposals
1933	   described so far.

1935	6.3.1  Research at Other Protocol Layers

1937	   The efficiency and security related to movements does not depend on
1938	   Mobile IPv6 route optimization alone, even if researchers often pose
1939	   their analysis in that light.  A movement that is visible at the IP
1940	   layer involves all lower layers as well.  This includes layer 2
1941	   attachment procedures; layer 2 security mechanisms such as
1942	   negotiation, authentication, and key agreement; IPv6 Router and
1943	   Neighbor Discovery; as well as IPv6 Address Autoconfiguration and
1944	   Duplicate Address Detection.  A complete network attachment typically
1945	   requires over twenty link- and IP-layer messages, assuming that
1946	   features necessary for a commercial deployment (such as security) are
1947	   turned on.

1949	   A significant research question is the performance of the
1950	   network-access stack as a whole.  Current protocol stacks have a
1951	   number of limitations in addition to the long attachment delays [31],
1952	   such as denial-of-service vulnerabilities, difficulties in trusting a
1953	   set of access nodes distributed to physically insecure locations, or
1954	   the inability to retrieve sufficient information for making a handoff
1955	   decision.

1957	   A number attempts are ongoing to improve various parts of the stack,
1958	   mostly focusing on handover performance.  These include link-layer
1959	   enhancements, parameter tuning [39], network-access authentication
1960	   mechanisms [1], fast-handover mechanisms [35], AAA architectures
1961	   [21], and IP-layer attachment improvements [12].  It is uncertain how
1962	   far this optimization can be taken by only looking at the different
1963	   parts individually.  An integrated approach may be necessary to gain
1964	   more significant improvements [32].

1966	   It is also unclear at this time which components are the most
1967	   critical ones.  [31] suggests that mobility-related signaling
1968	   contributes only under 10% of the overall delay in an IEEE 802.11
1969	   environment.  The most significant delays are caused at the link
1970	   layer and for IPv6 attachment.  However, the results are not
1971	   conclusive due to the high deviation between the measurements.  The
1972	   results can also be affected by a number of conditions, such as the
1973	   availability of specific link-layer optimizations, or the type of
1974	   security mechanism used for Mobile IPv6 home registrations.

1976	6.3.2  Further Route Optimization Research

1978	   The primary driver to improve route optimization appears to be better
1979	   efficiency for a few usage scenarios, such as fast movements or the
1980	   ability to reduce signaling frequencies for hosts in standby mode.
1981	   Ongoing work addresses these aspects already quite well, and many of
1982	   the suggested methods are reasonably stable in this regard.  It is
1983	   expected that further, perhaps smaller improvements will continue to
1984	   be achieved through research and parameter tuning far into the
1985	   future.  This is particularly true because the optimizations are
1986	   often targeted to a specific usage scenario, and may not give the
1987	   same improvement in other situations.  As a result, the publication
1988	   of a few enhanced methods for different scenarios seems more
1989	   reasonable than expecting to define a final, all-encompassing method.

1991	   The development of an infrastructure-based route-optimization method
1992	   is clearly a longer-term project.  At this stage, it is not even
1993	   clear that such a mechanism is needed.  The Certificate-Based Binding
1994	   Update Protocol shows some promise in this area, particularly if it
1995	   can be combined with other mechanisms that use certificates, such as
1996	   Secure Neighbor Discovery [20].  Pre-configuring keys into end hosts
1997	   [15] is simple and efficient, but the number of scenarios where it
1998	   applies is likely to be very limited only.

2000	   The following is a list of interesting ideas for new
2001	   route-optimization research.

2003	   o  Local mobility or local repair optimizations that require no
2004	      configuration.

2006	   o  Care-of-address verification mechanisms that employ lower-layer
2007	      assistance or Secure Neighbor Discovery.

2009	   o  The introduction of optimizations developed in the context of
2010	      Mobile IPv6 to HIP or other mobility protocols, or to link-layer
2011	      mobility solutions.

2013	   o  The extension of the developed techniques to full
2014	      multi-addressing, including also multi-homing.

2016	   o  Further development of techniques that are based on "asymmetric
2017	      cost wars" [33], such as CBA.

2019	   o  Integrated techniques taking into account both link and IP layer
2020	      mobility tasks.

2022	6.3.3  Experimentation and Simulation

2024	   As discussed earlier, the contribution of different stack parts to
2025	   the overall movement latency is still unclear.  The following is a
2026	   list of areas where measurements and experimentation can yield
2027	   further, valuable insight.

2029	   o  Measurements of a realistic network scenario, enabling all
2030	      features that would likely be needed in a commercial deployment.
2031	      These features include link-layer access control, for instance.
2032	      Similarly, it is necessary to consider support for existing
2033	      enhancement proposals.

2035	   o  Measurements and simulations of the performance impacts that
2036	      existing enhancement proposals have on the different parts of the
2037	      stack.

2039	   o  Measurements and comparisons of different implementations that are
2040	      based on the same specification.  For instance, it would be
2041	      valuable to know how much implementations differ with regards to
2042	      the use of parallelism that RFC 3775 allows in home and
2043	      correspondent registrations, or with respect to early packet
2044	      transmission before reception of a BA.

2046	   o  Measurements of the impact that network conditions such as packet
2047	      loss can have on existing and new route-optimization mechanisms.

2049	   o  Statistical data collection on the behavior of mobile nodes in
2050	      different networks.  Route-optimization techniques behave
2051	      differently depending on what the frequency of movements is, or
2052	      what traffic streams appear during a mobile node's lifetime.

2054	   o  Measurements or simulations of the performance that existing
2055	      route-optimization schemes show under different application
2056	      scenarios, such as the use of applications with symmetric vs.
2057	      asymmetric traffic patterns.

2059	7.  Security Considerations

2061	   Security issues related to route optimization are an integral part of
2062	   this paper and are as such discussed throughout the paper.

2064	8.  Conclusions

2066	   Mobility-related optimizations are currently actively studied by many
2067	   researchers.  Some of the basic techniques--such as the
2068	   return-routability procedure, pre-configured keys, or CGAs--are
2069	   either already being deployed or can expected to be in the near
2070	   future.  A growing number of new proposals are being studied that
2071	   attempt to optimize these basic techniques further, or to make them
2072	   better applicable to a particular scenario.

2074	   Many of the current proposals are mature enough to withstand close
2075	   scrutiny.  Their relative advantages are rather subjective, however.
2076	   For instance, some proposals are very efficient, but have a high cost
2077	   in terms of configuration, whereas others do not require
2078	   configuration, but are slower.  It hence appears likely that more
2079	   than one new method will have to be standardized.  Deployment
2080	   experience is also important, so publication of a few alternative
2081	   methods as RFCs would be desirable.

2083	   It is interesting to see that most if not all current proposals had
2084	   predecessors that were shown to be insecure.  For instance, the
2085	   initial return-routability procedure as well as the first versions of
2086	   CGAs were published before the threat of flooding attacks was fully
2087	   understood.  Concurrent care-of-address tests were also first
2088	   suggested with insufficient protection against flooding attacks.  And
2089	   several proposals employing semi-permanent security associations have
2090	   initially suffered from impersonation attacks.  This shows the need
2091	   to reserve a sufficient amount of time for community analysis and
2092	   review of new methods.

2094	   Another interesting observation is that most mature proposals combine
2095	   a number of techniques and do not rely on any single approach.  This
2096	   is due to the intricate nature of the problem: to build a mechanism
2097	   that is efficient and at the same time avoids a quite significant
2098	   number of potential security vulnerabilities.

2100	   On the other hand, it is also necessary to avoid overly expensive or
2101	   complex solutions.  For instance, in evaluating the security needs
2102	   for route optimization, it is important to compare these needs to
2103	   other vulnerabilities, e.g., denial-of-service attacks, that already
2104	   exist for on-path attackers in an Internet without mobility support.
2105	   Of course, a mobility-management protocol should not make these
2106	   vulnerabilities worse.  But since the issues already exist, it is not
2107	   necessarily a requirement that they be solved by a
2108	   mobility-management protocol.

2110	   A significant research question is the overall performance of the
2111	   network stack in a mobile setting.  This includes mobility management
2112	   at the IP layer, but is not limited to it.  Current network-access
2113	   protocol stacks have a number of limitations, such as long attachment
2114	   and movement latencies or significant denial-of-service
2115	   vulnerabilities.  It is uncertain whether further, significant
2116	   benefits can be achieved if one continues to look at the different
2117	   parts of the network stack individually.  Most likely, a more
2118	   comprehensive approach is needed.  It is also unclear at this time
2119	   which components of the network stack are the most critical ones to
2120	   optimize.

2122	   Other significant research questions include what effect network
2123	   conditions such as packet loss can have on current proposals, and to
2124	   what degree proposals depend on specific application patterns.  Our
2125	   current understanding about the different traffic patterns and their
2126	   effects on mobility is limited, and experiments, modelling, and
2127	   simulations will be needed.

2129	9.  References

2131	   [1]   Institute of Electrical and Electronics Engineers, "Local and
2132	         Metropolitan Area Networks: Port-Based Network Access Control",
2133	         IEEE Standard 802.1X, September 2001.

2135	   [2]   Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
2136	         Lifetime Extension",
2137	         Internet-Draft draft-arkko-mipv6-binding-lifetime-extension-00,
2138	         May 2004.

2140	   [3]   Bradner, S., Mankin, A. and J. Schiller, "A Framework for
2141	         Purpose-Built Keys (PBK)",
2142	         Internet-Draft draft-bradner-pbk-frame-06, June 2003.

2144	   [4]   Daley, G., "Location Privacy and Mobile IPv6",
2145	         Internet-Draft draft-daley-mip6-locpriv-00, January 2004.

2147	   [5]   Dupont, F. and J. Combes, "Using IPsec between Mobile and
2148	         Correspondent IPv6 Nodes",
2149	         Internet-Draft draft-dupont-mipv6-cn-ipsec-01, June 2004.

2151	   [6]   Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying
2152	         Cryptographically Generated Addresses to Optimize MIPv6
2153	         (CGA-OMIPv6)", Internet-Draft draft-haddad-mip6-cga-omipv6-02,
2154	         June 2004.

2156	   [7]   Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)",
2157	         Internet-Draft draft-haddad-mipv6-omipv6-01, February 2004.

2159	   [8]   Haddad, W., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv
2160	         Problem Statement",
2161	         Internet-Draft draft-haddad-momipriv-problem-statement-00,
2162	         October 2004.

2164	   [9]   Moskowitz, R., "Host Identity Protocol",
2165	         Internet-Draft draft-ietf-hip-base-00, June 2004.

2167	   [10]  Kent, S., "IP Encapsulating Security Payload (ESP)",
2168	         Internet-Draft draft-ietf-ipsec-esp-v3-08, March 2004.

2170	   [11]  Loughney, J., "IPv6 Node Requirements",
2171	         Internet-Draft draft-ietf-ipv6-node-requirements-11, August
2172	         2004.

2174	   [12]  Moore, N., "Optimistic Duplicate Address Detection for IPv6",
2175	         Internet-Draft draft-ietf-ipv6-optimistic-dad-01, June 2004.

2177	   [13]  Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. Chowdhury,
2178	         "Authentication Protocol for Mobile IPv6",
2179	         Internet-Draft draft-ietf-mip6-auth-protocol-00, July 2004.

2181	   [14]  Patel, A., "Problem Statement for bootstrapping Mobile IPv6",
2182	         Internet-Draft draft-ietf-mip6-bootstrap-ps-00, July 2004.

2184	   [15]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
2185	         IPv6", Internet-Draft draft-ietf-mip6-precfgKbm-00, April 2004.

2187	   [16]  Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
2188	         Nordmark, "Mobile IP version 6 Route Optimization Security
2189	         Design Background", Internet-Draft draft-ietf-mip6-ro-sec-01,
2190	         July 2004.

2192	   [17]  Koodli, R., "Fast Handovers for Mobile IPv6",
2193	         Internet-Draft draft-ietf-mipshop-fast-mipv6-02, July 2004.

2195	   [18]  Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
2196	         "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
2197	         Internet-Draft draft-ietf-mipshop-hmipv6-02, June 2004.

2199	   [19]  Aura, T., "Cryptographically Generated Addresses (CGA)",
2200	         Internet-Draft draft-ietf-send-cga-06, April 2004.

2202	   [20]  Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
2203	         "SEcure Neighbor Discovery (SEND)",
2204	         Internet-Draft draft-ietf-send-ndopt-06, July 2004.

2206	   [21]  Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to
2207	         RADIUS", Internet-Draft draft-irtf-aaaarch-handoff-04, November
2208	         2003.

2210	   [22]  Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity
2211	         Protocol", Internet-Draft draft-moskowitz-hip-09, February
2212	         2004.

2214	   [23]  Bao, F., "Certificate-based Binding Update Protocol (CBU)",
2215	         Internet-Draft draft-qiu-mip6-certificated-binding-update-02,
2216	         August 2004.

2218	   [24]  Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
2219	         Mobile IPv6 Binding Updates and Acknowledgments",
2220	         Internet-Draft draft-roe-mobileip-updateauth-02, March 2002.

2222	   [25]  Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding
2223	         Updates for Mobile IPv6",
2224	         Internet-Draft draft-vogt-mip6-early-binding-updates-00,
2225	         February 2004.

2227	   [26]  Vogt, C., Arkko, J., Bless, R., Doll, M. and T. Kuefner,
2228	         "Credit-Based Authorization for Mobile IPv6 Early Binding
2229	         Updates",
2230	         Internet-Draft draft-vogt-mipv6-credit-based-authorization-00,
2231	         May 2004.

2233	   [27]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
2234	         (ESP)", RFC 2406, November 1998.

2236	   [28]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2237	         2002.

2239	   [29]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
2240	         IPv6", RFC 3775, June 2004.

2242	   [30]  Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
2243	         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
2244	         Agents", RFC 3776, June 2004.

2246	   [31]  Alimian, A. and B. Aboba, "Analysis of Roaming Techniques",
2247	         IEEE Contribution 11-04-0377r1 2004.

2249	   [32]  Arkko, J., Eronen, P., Nikander, P. and V. Torvinen, "Secure
2250	         and Efficient Network Access", Extended abstract to be
2251	         presented in the DIMACS workshop, November 2004.

2253	   [33]  Arkko, J. and P. Nikander, "Weak Authentication: How to
2254	         Authenticate Unknown Principals without Trusted Parties",
2255	         Proceedings of Security Protocols Workshop 2002, Cambridge, UK,
2256	         April 16-19,  2002.

2258	   [34]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
2259	         Defeating Denial of Service Attacks which employ IP Source
2260	         Address Spoofing", BCP 38, RFC 2827, May 2000.

2262	   [35]  Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
2263	         "Proactive Key Distribution to Support Fast and Secure
2264	         Roaming", IEEE Contribution 11-03-084r1-I, January 2003.

2266	   [36]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
2267	         Authentication in the IPv6 World", Proceedings of the Cambridge
2268	         Security Protocols Workshop, April 2001.

2270	   [37]  O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
2271	         Computer Communications Review, April 2001.

2273	   [38]  Paxson, V., "An Analysis of Using Reflectors for Distributed
2274	         Denial-of-Service Attacks",  Computer Communication Review
2275	         31(3)., July 2001.

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

2282	Authors' Addresses

2284	   Jari Arkko
2285	   Ericsson Research NomadicLab
2286	   FI-02420 Jorvas
2287	   Finland

2289	   Email: jari.arkko@ericsson.com

2291	   Christian Vogt
2292	   Institute of Telematics
2293	   University of Karlsruhe
2294	   P.O. Box 6980
2295	   76128 Karlsruhe
2296	   Germany

2298	   Email: chvogt@tm.uka.de
2299	   URI:   http://www.tm.uka.de/~chvogt/

2301	Appendix A.  Acknowledgements

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

2306	Intellectual Property Statement

2308	   The IETF takes no position regarding the validity or scope of any
2309	   Intellectual Property Rights or other rights that might be claimed to
2310	   pertain to the implementation or use of the technology described in
2311	   this document or the extent to which any license under such rights
2312	   might or might not be available; nor does it represent that it has
2313	   made any independent effort to identify any such rights.  Information
2314	   on the procedures with respect to rights in RFC documents can be
2315	   found in BCP 78 and BCP 79.

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

2324	   The IETF invites any interested party to bring to its attention any
2325	   copyrights, patents or patent applications, or other proprietary
2326	   rights that may cover technology that may be required to implement
2327	   this standard.  Please address the information to the IETF at
2328	   ietf-ipr@ietf.org.

2330	Disclaimer of Validity

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

2340	Copyright Statement

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

2346	Acknowledgment

2348	   Funding for the RFC Editor function is currently provided by the
2349	   Internet Society.