GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4225

Network Working Group P. Nikander Request for Comments: 4225 J. Arkko Category: Informational Ericsson Research NomadicLab

                                                               T. Aura
                                                    Microsoft Research
                                                         G. Montenegro
                                                 Microsoft Corporation
                                                           E. Nordmark
                                                      Sun Microsystems
                                                         December 2005
 Mobile IP Version 6 Route Optimization Security Design Background

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document is an account of the rationale behind the Mobile IPv6
 (MIPv6) Route Optimization security design.  The purpose of this
 document is to present the thinking and to preserve the reasoning
 behind the Mobile IPv6 security design in 2001 - 2002.
 The document has two target audiences: (1) helping MIPv6 implementors
 to better understand the design choices in MIPv6 security procedures,
 and (2) allowing people dealing with mobility or multi-homing to
 avoid a number of potential security pitfalls in their designs.

Nikander, et al. Informational [Page 1] RFC 4225 Mobile IPv6 RO Security Design December 2005

Table of Contents

 1. Introduction ....................................................3
    1.1. Assumptions about the Existing IP Infrastructure ...........4
    1.2. The Mobility Problem and the Mobile IPv6 Solution ..........6
    1.3. Design Principles and Goals ................................8
       1.3.1. End-to-End Principle ..................................8
       1.3.2. Trust Assumptions .....................................8
       1.3.3. Protection Level ......................................8
    1.4. About Mobile IPv6 Mobility and its Variations ..............9
 2. Avenues of Attack ...............................................9
    2.1. Target ....................................................10
    2.2. Timing ....................................................10
    2.3. Location ..................................................11
 3. Threats and Limitations ........................................11
    3.1. Attacks Against Address 'Owners' ("Address Stealing").. ...12
       3.1.1. Basic Address Stealing ...............................12
       3.1.2. Stealing Addresses of Stationary Nodes ...............13
       3.1.3. Future Address Sealing ...............................14
       3.1.4. Attacks against Secrecy and Integrity ................15
       3.1.5. Basic Denial-of-Service Attacks ......................16
       3.1.6. Replaying and Blocking Binding Updates ...............16
    3.2. Attacks Against Other Nodes and Networks (Flooding) .......16
       3.2.1. Basic Flooding .......................................17
       3.2.2. Return-to-Home Flooding ..............................18
    3.3. Attacks against Binding Update Protocols ..................18
       3.3.1. Inducing Unnecessary Binding Updates .................19
       3.3.2. Forcing Non-Optimized Routing ........................20
       3.3.3. Reflection and Amplification .........................21
    3.4. Classification of Attacks .................................22
    3.5. Problems with Infrastructure-Based Authorization ..........23
 4. Solution Selected for Mobile IPv6 ..............................24
    4.1. Return Routability ........................................24
       4.1.1. Home Address Check ...................................26
       4.1.2. Care-of-Address Check ................................27
       4.1.3. Forming the First Binding Update .....................27
    4.2. Creating State Safely .....................................28
       4.2.1. Retransmissions and State Machine ....................29
    4.3. Quick expiration of the Binding Cache Entries .............29
 5. Security Considerations ........................................30
    5.1. Residual Threats as Compared to IPv4 ......................31
    5.2. Interaction with IPsec ....................................31
    5.3. Pretending to Be One's Neighbor ...........................32
    5.4. Two Mobile Nodes Talking to Each Other ....................33
 6. Conclusions ....................................................33
 7. Acknowledgements ...............................................34
 8. Informative References .........................................34

Nikander, et al. Informational [Page 2] RFC 4225 Mobile IPv6 RO Security Design December 2005

1. Introduction

 Mobile IPv4 is based on the idea of supporting mobility on top of
 existing IP infrastructure, without requiring any modifications to
 the routers, the applications, or the stationary end hosts.  However,
 in Mobile IPv6 [6] (as opposed to Mobile IPv4), the stationary end
 hosts may provide support for mobility, i.e., route optimization.  In
 route optimization, a correspondent node (CN) (i.e., a peer for a
 mobile node) learns a binding between the mobile node's stationary
 home address and its current temporary care-of address.  This binding
 is then used to modify the handling of outgoing (as well as the
 processing of incoming) packets, leading to security risks.  The
 purpose of this document is to provide a relatively compact source
 for the background assumptions, design choices, and other information
 needed to understand the route optimization security design.  This
 document does not seek to compare the relative security of Mobile
 IPv6 and other mobility protocols, or to list all the alternative
 security mechanisms that were discussed during the Mobile IPv6 design
 process.  For a summary of the latter, we refer the reader to [1].
 Even though incidental implementation suggestions are included for
 illustrative purposes, the goal of this document is not to provide a
 guide to implementors.  Instead, it is to explain the design choices
 and rationale behind the current route optimization design.  The
 authors participated in the design team that produced the design and
 hope, via this note, to capture some of the lessons and reasoning
 behind that effort.
 The authors' intent is to document the thinking behind that design
 effort as it was.  Even though this note may incorporate more recent
 developments in order to illustrate the issues, it is not our intent
 to present a new design.  Rather, along with the lessons learned,
 there is some effort to clarify differing opinions, questionable
 assumptions, or newly discovered vulnerabilities, should such new
 information be available today.  This is also very important, because
 it may benefit the working group's hindsight as it revises or
 improves the Mobile IPv6 specification.
 To fully understand the security implications of the relevant design
 constraints, it is necessary to explore briefly the nature of the
 existing IP infrastructure, the problems Mobile IP aims to solve, and
 the design principles applied.  In the light of this background, we
 can then explore IP-based mobility in more detail and have a brief
 look at the security problems.  The background is given in the rest
 of this section, starting from Section 1.1.
 Although the introduction in Section 1.1 may appear redundant to
 readers who are already familiar with Mobile IPv6, it may be valuable
 to read it anyway.  The approach taken in this document is very

Nikander, et al. Informational [Page 3] RFC 4225 Mobile IPv6 RO Security Design December 2005

 different from that in the Mobile IPv6 specification.  That is, we
 have explicitly aimed to expose the implicit assumptions and design
 choices made in the base Mobile IPv6 design, while the Mobile IPv6
 specification aims to state the result of the design.  By
 understanding the background, it is much easier to understand the
 source of some of the related security problems, and to understand
 the limitations intrinsic to the provided solutions.
 In particular, this document explains how the adopted design for
 "Return Routability" (RR) protects against the identified threats
 (Section 3).  This is true except for attacks on the RR protocol
 itself, which require other countermeasures based on heuristics and
 judicious implementation (Section 3.3).
 The rest of this document is organized as follows: after this
 introductory section, we start by considering the avenues of attack
 in Section 2.  The security problems and countermeasures are studied
 in detail in Section 3.  Section 4 explains the overall operation and
 design choices behind the current security design.  Section 5
 analyzes the design and discuss the remaining threats.  Finally,
 Section 6 concludes this document.

1.1. Assumptions about the Existing IP Infrastructure

 One of the design goals in the Mobile IP design was to make mobility
 possible without changing too much.  This was especially important
 for IPv4, with its large installed base, but the same design goals
 were inherited by Mobile IPv6.  Some alternative proposals take a
 different approach and propose larger modifications to the Internet
 architecture (see Section 1.4).
 To understand Mobile IPv6, it is important to understand the MIPv6
 design view of the base IPv6 protocol and infrastructure.  The most
 important base assumptions can be expressed as follows:
 1.  The routing prefixes available to a node are determined by its
     current location, and therefore the node must change its IP
     address as it moves.
 2.  The routing infrastructure is assumed to be secure and well
     functioning, delivering packets to their intended destinations as
     identified by destination address.
 Although these assumptions may appear to be trivial, let us explore
 them a little further.  First, in current IPv6 operational practice
 the IP address prefixes are distributed in a hierarchical manner.
 This limits the number of routing table entries each individual
 router needs to handle.  An important implication is that the

Nikander, et al. Informational [Page 4] RFC 4225 Mobile IPv6 RO Security Design December 2005

 topology determines what globally routable IP addresses are available
 at a given location.  That is, the nodes cannot freely decide what
 globally routable IP address to use; they must rely on the routing
 prefixes served by the local routers via Router Advertisements or by
 a DHCP server.  In other words, IP addresses are just what the name
 says, addresses (i.e., locators).
 Second, in the current Internet structure, the routers collectively
 maintain a distributed database of the network topology and forward
 each packet towards the location determined by the destination
 address carried in the packet.  To maintain the topology information,
 the routers must trust each other, at least to a certain extent.  The
 routers learn the topology information from the other routers, and
 they have no option but to trust their neighbor routers about distant
 topology.  At the borders of administrative domains, policy rules are
 used to limit the amount of perhaps faulty routing table information
 received from the peer domains.  While this is mostly used to weed
 out administrative mistakes, it also helps with security.  The aim is
 to maintain a reasonably accurate idea of the network topology even
 if someone is feeding faulty information to the routing system.
 In the current Mobile IPv6 design, it is explicitly assumed that the
 routers and the policy rules are configured in a reasonable way, and
 that the resulting routing infrastructure is trustworthy enough.
 That is, it is assumed that the routing system maintains accurate
 information of the network topology, and that it is therefore able to
 route packets to their destination locations.  If this assumption is
 broken, the Internet itself is broken in the sense that packets go to
 wrong locations.  Such a fundamental malfunction of the Internet
 would render hopeless any other effort to assure correct packet
 delivery (e.g., any efforts due to Mobile IP security
 considerations).

1.1.1. A Note on Source Addresses and Ingress Filtering

 Some of the threats and attacks discussed in this document take
 advantage of the ease of source address spoofing.  That is, in the
 current Internet it is possible to send packets with a false source
 IP address.  The eventual introduction of ingress filtering is
 assumed to prevent this.  When ingress filtering is used, traffic
 with spoofed addresses is not forwarded.  This filtering can be
 applied at different network borders, such as those between an
 Internet service provider (ISP) and its customers, between downstream
 and upstream ISPs, or between peer ISPs [5].  Obviously, the
 granularity of ingress filters specifies how much you can "spoof
 inside a prefix".  For example, if an ISP ingress filters a
 customer's link but the customer does nothing, anything inside the
 customer's /48 prefix could be spoofed.  If the customer does

Nikander, et al. Informational [Page 5] RFC 4225 Mobile IPv6 RO Security Design December 2005

 filtering at LAN subnets, anything inside the /64 prefixes could be
 spoofed.  Despite the limitations imposed by such "in-prefix
 spoofing", in general, ingress filtering enables traffic to be
 traceable to its real source network [5].
 However, ingress filtering helps if and only if a large part of the
 Internet uses it.  Unfortunately, there are still some issues (e.g.,
 in the presence of site multi-homing) that, although not
 insurmountable, do require careful handling, and that are likely to
 limit or delay its usefulness [5].

1.2. The Mobility Problem and the Mobile IPv6 Solution

 The Mobile IP design aims to solve two problems at the same time.
 First, it allows transport layer sessions (TCP connections, UDP-
 based transactions) to continue even if the underlying host(s) move
 and change their IP addresses.  Second, it allows a node to be
 reached through a static IP address, a home address (HoA).
 The latter design choice can also be stated in other words: Mobile
 IPv6 aims to preserve the identifier nature of IP addresses.  That
 is, Mobile IPv6 takes the view that IP addresses can be used as
 natural identifiers of nodes, as they have been used since the
 beginning of the Internet.  This must be contrasted to proposed and
 existing alternative designs where the identifier and locator natures
 of the IP addresses have been separated (see Section 1.4).
 The basic idea in Mobile IP is to allow a home agent (HA) to work as
 a stationary proxy for a mobile node (MN).  Whenever the mobile node
 is away from its home network, the home agent intercepts packets
 destined to the node and forwards the packets by tunneling them to
 the node's current address, the care-of address (CoA).  The transport
 layer (e.g., TCP, UDP) uses the home address as a stationary
 identifier for the mobile node.  Figure 1 illustrates this basic
 arrangement.
 The basic solution requires tunneling through the home agent, thereby
 leading to longer paths and degraded performance.  This tunneling is
 sometimes called triangular routing since it was originally planned
 that the packets from the mobile node to its peer could still
 traverse directly, bypassing the home agent.

Nikander, et al. Informational [Page 6] RFC 4225 Mobile IPv6 RO Security Design December 2005

  +----+                                       +----+
  | MN |=#=#=#=#=#=#=#=#=tunnel=#=#=#=#=#=#=#=#|#HA |
  +----+         ____________                  +-#--+
    | CoA    ___/            \_____              # Home Link
   -+-------/      Internet    * * *-*-*-*-#-#-#-#-----
           |               * *      |    * Home Address
            \___       * *    _____/   + * -+
                \_____*______/         | MN |
                      *                + - -+
                    +----+
                    | CN |    Data path as     * * * *
                    +----+    it appears to correspondent node
                              Real data path   # # # #
           Figure 1.  Basic Mode of Operation in Mobile IPv6
 To alleviate the performance penalty, Mobile IPv6 includes a mode of
 operation that allows the mobile node and its peer, a correspondent
 node (CN), to exchange packets directly, bypassing the home agent
 completely after the initial setup phase.  This mode of operation is
 called route optimization (RO).  When route optimization is used, the
 mobile node sends its current care-of address to the correspondent
 node, using binding update (BU) messages.  The correspondent node
 stores the binding between the home address and care-of address into
 its Binding Cache.
 Whenever MIPv6 route optimization is used, the correspondent node
 effectively functions in two roles.  Firstly, it is the source of the
 packets it sends, as usual.  Secondly, it acts as the first router
 for the packets, effectively performing source routing.  That is,
 when the correspondent node is sending out packets, it consults its
 MIPv6 route optimization data structures and reroutes the packets, if
 necessary.  A Binding Cache Entry (BCE) contains the home address and
 the care-of address of the mobile node, and records the fact that
 packets destined to the home address should now be sent to the
 destination address.  Thus, it represents a local routing exception.
 The packets leaving the correspondent node are source routed to the
 care-of address.  Each packet includes a routing header that contains
 the home address of the mobile node.  Thus, logically, the packet is
 first routed to the care-of address and then, virtually, from the
 care-of address to the home address.  In practice, of course, the
 packet is consumed by the mobile node at the care-of address; the
 header just allows the mobile node to select a socket associated with
 the home address instead of one with the care-of address.  However,
 the mechanism resembles source routing, as there is routing state
 involved at the correspondent node, and a routing header is used.

Nikander, et al. Informational [Page 7] RFC 4225 Mobile IPv6 RO Security Design December 2005

 Nevertheless, this routing header is special (type 2) to avoid the
 risks associated with using the more general (type 0) variant.

1.3. Design Principles and Goals

 The MIPv6 design and security design aimed to follow the end-to-end
 principle, to notice the differences in trust relationships between
 the nodes, and to be explicit about delivering a practical (instead
 of an over-ambitious) level of protection.

1.3.1. End-to-End Principle

 Perhaps the leading design principle for Internet protocols is the
 so-called end-to-end principle [4][11].  According to this principle,
 it is beneficial to avoid polluting the network with state, and to
 limit new state creation to the involved end nodes.
 In the case of Mobile IPv6, the end-to-end principle is applied by
 restricting mobility-related state primarily to the home agent.
 Additionally, if route optimization is used, the correspondent nodes
 also maintain a soft state relating to the mobile nodes' current
 care-of addresses, the Binding Cache.  This can be contrasted to an
 approach that would use individual host routes within the basic
 routing system.  Such an approach would create state on a huge number
 of routers around the network.  In Mobile IPv6, only the home agent
 and the communicating nodes need to create state.

1.3.2. Trust Assumptions

 In the Mobile IPv6 security design, different approaches were chosen
 for securing the communication between the mobile node and its home
 agent and between the mobile node and its correspondent nodes.  In
 the home agent case, it was assumed that the mobile node and the home
 agent know each other through a prior arrangement, e.g., due to a
 business relationship.  In contrast, it was strictly assumed that the
 mobile node and the correspondent node do not need to have any prior
 arrangement, thereby allowing Mobile IPv6 to function in a scalable
 manner, without requiring any configuration at the correspondent
 nodes.

1.3.3. Protection Level

 As a security goal, Mobile IPv6 design aimed to be "as secure as the
 (non-mobile) IPv4 Internet" was at the time of the design, in the
 period 2001 - 2002.  In particular, that means that there is little
 protection against attackers that are able to attach themselves
 between a correspondent node and a home agent.  The rationale is
 simple: in the 2001 Internet, if a node was able to attach itself to

Nikander, et al. Informational [Page 8] RFC 4225 Mobile IPv6 RO Security Design December 2005

 the communication path between two arbitrary nodes, it was able to
 disrupt, modify, and eavesdrop all the traffic between the two nodes,
 unless IPsec protection was used.  Even when IPsec was used, the
 attacker was still able to block communication selectively by simply
 dropping the packets.  The attacker in control of a router between
 the two nodes could also mount a flooding attack by redirecting the
 data flows between the two nodes (or, more practically, an equivalent
 flow of bogus data) to a third party.

1.4. About Mobile IPv6 Mobility and its Variations

 Taking a more abstract angle, IPv6 mobility can be defined as a
 mechanism for managing local exceptions to routing information in
 order to direct packets that are sent to one address (the home
 address) to another address (the care-of address).  It is managing in
 the sense that the local routing exceptions (source routes) are
 created and deleted dynamically, according to instructions sent by
 the mobile node.  It is local in the sense that the routing
 exceptions are valid only at the home agent, and in the correspondent
 nodes if route optimization is used.  The created pieces of state are
 exceptions in the sense that they override the normal topological
 routing information carried collectively by the routers.
 Using the terminology introduced by J. Noel Chiappa [14], we can say
 that the home address functions in the dual role of being an end-
 point identifier (EID) and a permanent locator.  The care-of address
 is a pure, temporary locator, which identifies the current location
 of the mobile node.  The correspondent nodes effectively perform
 source routing, redirecting traffic destined to the home address to
 the care-of address.  This is even reflected in the packet structure:
 the packets carry an explicit routing header.
 The relationship between EIDs and permanent locators has been
 exploited by other proposals.  Their technical merits and security
 problems, however, are beyond the scope of this document.

2. Avenues of Attack

 From the discussion above, it should now be clear that the dangers
 that Mobile IPv6 must protect from lie in creation (or deletion) of
 the local routing exceptions.  In Mobile IPv6 terms, the danger is in
 the possibility of unauthorized creation of Binding Cache Entries
 (BCE).  The effects of an attack differ depending on the target of
 the attack, the timing of the attack, and the location of the
 attacker.

Nikander, et al. Informational [Page 9] RFC 4225 Mobile IPv6 RO Security Design December 2005

2.1. Target

 Basically, the target of an attack can be any node or network in the
 Internet (stationary or mobile).  The basic differences lie in the
 goals of the attack: does the attacker aim to divert (steal) the
 traffic destined to and/or sourced at the target node, or does it aim
 to cause denial-of-service to the target node or network?  The target
 does not typically play much of an active role attack.  As an
 example, an attacker may launch a denial-of-service attack on a given
 node, A, by contacting a large number of nodes, claiming to be A, and
 subsequently diverting the traffic at these other nodes so that A is
 no longer able to receive packets from those nodes.  A itself need
 not be involved at all before its communications start to break.
 Furthermore, A is not necessarily a mobile node; it may well be
 stationary.
 Mobile IPv6 uses the same class of IP addresses for both mobile nodes
 (i.e., home and care-of addresses) and stationary nodes.  That is,
 mobile and stationary addresses are indistinguishable from each
 other.  Attackers can take advantage of this by taking any IP address
 and using it in a context where, normally, only mobile (home or
 care-of) addresses appear.  This means that attacks that otherwise
 would only concern mobile nodes are, in fact, a threat to all IPv6
 nodes.
 In fact, a mobile node appears to be best protected, since a mobile
 node does not need to maintain state about the whereabouts of some
 remote nodes.  Conversely, the role of being a correspondent node
 appears to be the weakest, since there are very few assumptions upon
 which it can base its state formation.  That is, an attacker has a
 much easier task in fooling a correspondent node to believe that a
 presumably mobile node is somewhere it is not, than in fooling a
 mobile node itself into believing something similar.  On the other
 hand, since it is possible to attack a node indirectly by first
 targeting its peers, all nodes are equally vulnerable in some sense.
 Furthermore, a (usually) mobile node often also plays the role of
 being a correspondent node, since it can exchange packets with other
 mobile nodes (see also Section 5.4).

2.2. Timing

 An important aspect in understanding Mobile IPv6-related dangers is
 timing.  In a stationary IPv4 network, an attacker must be between
 the communication nodes at the same time as the nodes communicate.
 With the Mobile IPv6 ability of creating binding cache entries, the
 situation changes.  A new danger is created.  Without proper
 protection, an attacker could attach itself between the home agent
 and a correspondent node for a while, create a BCE at the

Nikander, et al. Informational [Page 10] RFC 4225 Mobile IPv6 RO Security Design December 2005

 correspondent node, leave the position, and continuously update the
 correspondent node about the mobile node's whereabouts.  This would
 make the correspondent node send packets destined to the mobile node
 to an incorrect address as long as the BCE remained valid, i.e.,
 typically until the correspondent node is rebooted.  The converse
 would also be possible: an attacker could also launch an attack by
 first creating a BCE and then letting it expire at a carefully
 selected time.  If a large number of active BCEs carrying large
 amounts of traffic expired at the same time, the result might be an
 overload towards the home agent or the home network.  (See Section
 3.2.2 for a more detailed explanation.)

2.3. Location

 In a static IPv4 Internet, an attacker can only receive packets
 destined to a given address if it is able to attach itself to, or to
 control, a node on the topological path between the sender and the
 recipient.  On the other hand, an attacker can easily send spoofed
 packets from almost anywhere.  If Mobile IPv6 allowed sending
 unprotected Binding Updates, an attacker could create a BCE on any
 correspondent node from anywhere in the Internet, simply by sending a
 fraudulent Binding Update to the correspondent node.  Instead of
 being required to be between the two target nodes, the attacker could
 act from anywhere in the Internet.
 In summary, by introducing the new routing exception (binding cache)
 at the correspondent nodes, Mobile IPv6 introduces the dangers of
 time and space shifting.  Without proper protection, Mobile IPv6
 would allow an attacker to act from anywhere in the Internet and well
 before the time of the actual attack.  In contrast, in the static
 IPv4 Internet, the attacking nodes must be present at the time of the
 attack and they must be positioned in a suitable way, or the attack
 would not be possible in the first place.

3. Threats and Limitations

 This section describes attacks against Mobile IPv6 Route Optimization
 and what protection mechanisms Mobile IPv6 applies against them.  The
 goal of the attacker can be to corrupt the correspondent node's
 binding cache and to cause packets to be delivered to a wrong
 address.  This can compromise secrecy and integrity of communication
 and cause denial-of-service (DoS) both at the communicating parties
 and at the address that receives the unwanted packets.  The attacker
 may also exploit features of the Binding Update (BU) mechanism to
 exhaust the resources of the mobile node, the home agent, or the
 correspondent nodes.  The aim of this section is to provide an
 overview of the various protocol mechanisms and their limitations.
 The details of the mechanisms are covered in Section 4.

Nikander, et al. Informational [Page 11] RFC 4225 Mobile IPv6 RO Security Design December 2005

 It is essential to understand that some of the threats are more
 serious than others, that some can be mitigated but not removed, that
 some threats may represent acceptable risk, and that some threats may
 be considered too expensive to the attacker to be worth preventing.
 We consider only active attackers.  The rationale behind this is that
 in order to corrupt the binding cache, the attacker must sooner or
 later send one or more messages.  Thus, it makes little sense to
 consider attackers that only observe messages but do not send any.
 In fact, some active attacks are easier, for the average attacker, to
 launch than a passive one would be.  That is, in many active attacks
 the attacker can initiate binding update processing at any time,
 while most passive attacks require the attacker to wait for suitable
 messages to be sent by the target nodes.
 Nevertheless, an important class of passive attacks remains:  attacks
 on privacy.  It is well known that simply by examining packets,
 eavesdroppers can track the movements of individual nodes (and
 potentially, users) [3].  Mobile IPv6 exacerbates the problem by
 adding more potentially sensitive information into the packets (e.g.,
 Binding Updates, routing headers or home address options).  This
 document does not address these attacks.
 We first consider attacks against nodes that are supposed to have a
 specified address (Section 3.1), continuing with flooding attacks
 (Section 3.2) and attacks against the basic Binding Update protocol
 (Section 3.3).  After that, we present a classification of the
 attacks (Section 3.4).  Finally, we consider the applicability of
 solutions relying on some kind of a global security infrastructure
 (Section 3.5).

3.1. Attacks Against Address 'Owners' ("Address Stealing")

 The most obvious danger in Mobile IPv6 is address "stealing", when an
 attacker illegitimately claims to be a given node at a given address
 and tries to "steal" traffic destined to that address.  We first
 describe the basic variant of this attack, follow with a description
 of how the situation is affected if the target is a stationary node,
 and continue with more complicated issues related to timing (so
 called "future" attacks), confidentiality and integrity, and DoS
 aspects.

3.1.1. Basic Address Stealing

 If Binding Updates were not authenticated at all, an attacker could
 fabricate and send spoofed binding updates from anywhere in the
 Internet.  All nodes that support the correspondent node
 functionality would become unwitting accomplices to this attack.  As

Nikander, et al. Informational [Page 12] RFC 4225 Mobile IPv6 RO Security Design December 2005

 explained in Section 2.1, there is no way of telling which addresses
 belong to mobile nodes that really could send binding updates and
 which addresses belong to stationary nodes (see below), so
 potentially any node (including "static" nodes) is vulnerable.
      +---+  original       +---+ new packet   +---+
      | B |<----------------| A |- - - - - - ->| C |
      +---+  packet flow    +---+ flow         +---+
                              ^
                              |
                              | False BU: B -> C
                              |
                          +----------+
                          | Attacker |
                          +----------+
                     Figure 2.  Basic Address Stealing
 Consider an IP node, A, sending IP packets to another IP node, B.
 The attacker could redirect the packets to an arbitrary address, C,
 by sending a Binding Update to A.  The home address (HoA) in the
 binding update would be B and the care-of address (CoA) would be C.
 After receiving this binding update, A would send all packets
 intended for the node B to the address C.  See Figure 2.
 The attacker might select the care-of address to be either its own
 current address, another address in its local network, or any other
 IP address.  If the attacker selected a local care-of address
 allowing it to receive the packets, it would be able to send replies
 to the correspondent node.  Ingress filtering at the attacker's
 local+ network does not prevent the spoofing of Binding Updates but
 forces the attacker either to choose a care-of address from inside
 its own network or to use the Alternate care-of address sub-option.
 The binding update authorization mechanism used in the MIPv6 security
 design is primarily intended to mitigate this threat, and to limit
 the location of attackers to the path between a correspondent node
 and the home agent.

3.1.2. Stealing Addresses of Stationary Nodes

 The attacker needs to know or guess the IP addresses of both the
 source of the packets to be diverted (A in the example above) and the
 destination of the packets (B, above).  This means that it is
 difficult to redirect all packets to or from a specific node because
 the attacker would need to know the IP addresses of all the nodes
 with which it is communicating.

Nikander, et al. Informational [Page 13] RFC 4225 Mobile IPv6 RO Security Design December 2005

 Nodes with well-known addresses, such as servers and those using
 stateful configuration, are most vulnerable.  Nodes that are a part
 of the network infrastructure, such as DNS servers, are particularly
 interesting targets for attackers and particularly easy to identify.
 Nodes that frequently change their address and use random addresses
 are relatively safe.  However, if they register their address into
 Dynamic DNS, they become more exposed.  Similarly, nodes that visit
 publicly accessible networks such as airport wireless LANs risk
 revealing their addresses.  IPv6 addressing privacy features [3]
 mitigate these risks to an extent, but note that addresses cannot be
 completely recycled while there are still open sessions that use
 those addresses.
 Thus, it is not the mobile nodes that are most vulnerable to address
 stealing attacks; it is the well-known static servers.  Furthermore,
 the servers often run old or heavily optimized operating systems and
 may not have any mobility related code at all.  Thus, the security
 design cannot be based on the idea that mobile nodes might somehow be
 able to detect whether someone has stolen their address, and reset
 the state at the correspondent node.  Instead, the security design
 must make reasonable measures to prevent the creation of fraudulent
 binding cache entries in the first place.

3.1.3. Future Address Sealing

 If an attacker knows an address that a node is likely to select in
 the future, it can launch a "future" address stealing attack.  The
 attacker creates a Binding Cache Entry with the home address that it
 anticipates the target node will use.  If the Home Agent allows
 dynamic home addresses, the attacker may be able to do this
 legitimately.  That is, if the attacker is a client of the Home Agent
 and is able to acquire the home address temporarily, it may be able
 to do so and then to return the home address to the Home Agent once
 the BCE is in place.
 Now, if the BCE state had a long expiration time, the target node
 would acquire the same home address while the BCE is still effective,
 and the attacker would be able to launch a successful man-in-the-
 middle or denial-of-service attack.  The mechanism applied in the
 MIPv6 security design is to limit the lifetime of Binding Cache
 Entries to a few minutes.
 Note that this attack applies only to fairly specific conditions.
 There are also some variations of this attack that are theoretically
 possible under some other conditions.  However, all of these attacks
 are limited by the Binding Cache Entry lifetime, and therefore they
 are not a real concern with the current design.

Nikander, et al. Informational [Page 14] RFC 4225 Mobile IPv6 RO Security Design December 2005

3.1.4. Attacks against Secrecy and Integrity

 By spoofing Binding Updates, an attacker could redirect all packets
 between two IP nodes to itself.  By sending a spoofed binding update
 to A, it could capture the data intended to B.  That is, it could
 pretend to be B and highjack A's connections with B, or it could
 establish new spoofed connections.  The attacker could also send
 spoofed binding updates to both A and B and insert itself in the
 middle of all connections between them (man-in-the-middle attack).
 Consequently, the attacker would be able to see and modify the
 packets sent between A and B.  See Figure 3.
   Original data path, before man-in-the-middle attack
        +---+                               +---+
        | A |                               | B |
        +---+                               +---+
          \___________________________________/
   Modified data path, after the falsified binding updates
        +---+                               +---+
        | A |                               | B |
        +---+                               +---+
          \                                  /
           \                                /
            \          +----------+        /
             \---------| Attacker |-------/
                       +----------+
                     Figure 3.  Man-in-the-Middle Attack
 Strong end-to-end encryption and integrity protection, such as
 authenticated IPsec, can prevent all the attacks against data secrecy
 and integrity.  When the data is cryptographically protected, spoofed
 binding updates could result in denial of service (see below) but not
 in disclosure or corruption of sensitive data beyond revealing the
 existence of the traffic flows.  Two fixed nodes could also protect
 communication between themselves by refusing to accept binding
 updates from each other.  Ingress filtering, on the other hand, does
 not help, as the attacker is using its own address as the care-of
 address and is not spoofing source IP addresses.
 The protection adopted in MIPv6 Security Design is to authenticate
 (albeit weakly) the addresses by return routability (RR), which
 limits the topological locations from which the attack is possible
 (see Section 4.1).

Nikander, et al. Informational [Page 15] RFC 4225 Mobile IPv6 RO Security Design December 2005

3.1.5. Basic Denial-of-Service Attacks

 By sending spoofed binding updates, the attacker could redirect all
 packets sent between two IP nodes to a random or nonexistent address
 (or addresses).  As a result, it might be able to stop or disrupt
 communication between the nodes.  This attack is serious because any
 Internet node could be targeted, including fixed nodes belonging to
 the infrastructure (e.g., DNS servers) that are also vulnerable.
 Again, the selected protection mechanism is return routability (RR).

3.1.6. Replaying and Blocking Binding Updates

 Any protocol for authenticating binding updates has to consider
 replay attacks.  That is, an attacker may be able to replay recently
 authenticated binding updates to the correspondent and, consequently,
 to direct packets to the mobile node's previous location.  As with
 spoofed binding updates, this could be used both for capturing
 packets and for DoS.  The attacker could capture the packets and
 impersonate the mobile node if it reserved the mobile's previous
 address after the mobile node has moved away and then replayed the
 previous binding update to redirect packets back to the previous
 location.
 In a related attack, the attacker blocks binding updates from the
 mobile at its new location, e.g., by jamming the radio link or by
 mounting a flooding attack.  The attacker then takes over the
 mobile's connections at the old location.  The attacker will be able
 to capture the packets sent to the mobile and to impersonate the
 mobile until the correspondent's Binding Cache entry expires.
 Both of the above attacks require that the attacker be on the same
 local network with the mobile, where it can relatively easily observe
 packets and block them even if the mobile does not move to a new
 location.  Therefore, we believe that these attacks are not as
 serious as ones that can be mounted from remote locations.  The
 limited lifetime of the Binding Cache entry and the associated nonces
 limit the time frame within which the replay attacks are possible.
 Replay protection is provided by the sequence number and MAC in the
 Binding Update.  To not undermine this protection, correspondent
 nodes must exercise care upon deleting a binding cache entry, as per
 section 5.2.8 ("Preventing Replay Attacks") in [6].

3.2. Attacks Against Other Nodes and Networks (Flooding)

 By sending spoofed binding updates, an attacker could redirect
 traffic to an arbitrary IP address.  This could be used to overload
 an arbitrary Internet address with an excessive volume of packets
 (known as a 'bombing attack').  The attacker could also target a

Nikander, et al. Informational [Page 16] RFC 4225 Mobile IPv6 RO Security Design December 2005

 network by redirecting data to one or more IP addresses within the
 network.  There are two main variations of flooding: basic flooding
 and return-to-home flooding.  We consider them separately.

3.2.1. Basic Flooding

 In the simplest attack, the attacker knows that there is a heavy data
 stream from node A to B and redirects this to the target address C.
 However, A would soon stop sending the data because it is not
 receiving acknowledgements from B.
      (B is attacker)
      +---+  original       +---+ flooding packet   +---+
      | B |<================| A |==================>| C |
      +---+  packet flow    +---+ flow              +---+
       |                      ^
        \                    /
         \__________________/
        False binding update + false acknowledgements
               Figure 4.  Basic Flooding Attack
 A more sophisticated attacker would act itself as B; see Figure 4.
 It would first subscribe to a data stream (e.g., a video stream) and
 redirect this stream to the target address C.  The attacker would
 even be able to spoof the acknowledgements.  For example, consider a
 TCP stream.  The attacker would perform the TCP handshake itself and
 thus know the initial sequence numbers.  After redirecting the data
 to C, the attacker would continue to send spoofed acknowledgements.
 It would even be able to accelerate the data rate by simulating a
 fatter pipe [12].
 This attack might be even easier with UDP/RTP.  The attacker could
 create spoofed RTCP acknowledgements.  Either way, the attacker would
 be able to redirect an increasing stream of unwanted data to the
 target address without doing much work itself.  It could carry on
 opening more streams and refreshing the Binding Cache entries by
 sending a new binding update every few minutes.  Thus, the limitation
 of BCE lifetime to a few minutes does not help here without
 additional measures.
 During the Mobile IPv6 design process, the effectiveness of this
 attack was debated.  It was mistakenly assumed that the target node
 would send a TCP Reset to the source of the unwanted data stream,
 which would then stop sending.  In reality, all practical TCP/IP
 implementations fail to send the Reset.  The target node drops the
 unwanted packets at the IP layer because it does not have a Binding

Nikander, et al. Informational [Page 17] RFC 4225 Mobile IPv6 RO Security Design December 2005

 Update List entry corresponding to the Routing Header on the incoming
 packet.  Thus, the flooding data is never processed at the TCP layer
 of the target node, and no Reset is sent.  This means that the attack
 using TCP streams is more effective than was originally believed.
 This attack is serious because the target can be any node or network,
 not only a mobile one.  What makes it particularly serious compared
 to the other attacks is that the target itself cannot do anything to
 prevent the attack.  For example, it does not help if the target
 network stops using Route Optimization.  The damage is compounded if
 these techniques are used to amplify the effect of other distributed
 denial-of-service (DDoS) attacks.  Ingress filtering in the
 attacker's local network prevents the spoofing of source addresses
 but the attack would still be possible by setting the Alternate
 care-of address sub-option to the target address.
 Again, the protection mechanism adopted for MIPv6 is return
 routability.  This time it is necessary to check that there is indeed
 a node at the new care-of address, and that the node is the one that
 requested redirecting packets to that very address (see Section
 4.1.2).

3.2.2. Return-to-Home Flooding

 A variation of the bombing attack would target the home address or
 the home network instead of the care-of address or a visited network.
 The attacker would claim to be a mobile with the home address equal
 to the target address.  While claiming to be away from home, the
 attacker would start downloading a data stream.  The attacker would
 then send a binding update cancellation (i.e., a request to delete
 the binding from the Binding Cache) or just allow the cache entry to
 expire.  Either would redirect the data stream to the home network.
 As when bombing a care-of address, the attacker can keep the stream
 alive and even increase the data rate by spoofing acknowledgements.
 When successful, the bombing attack against the home network is just
 as serious as that against a care-of address.
 The basic protection mechanism adopted is return routability.
 However, it is hard to fully protect against this attack; see Section
 4.1.1.

3.3. Attacks against Binding Update Protocols

 Security protocols that successfully protect the secrecy and
 integrity of data can sometimes make the participants more vulnerable
 to denial-of-service attacks.  In fact, the stronger the
 authentication, the easier it may be for an attacker to use the

Nikander, et al. Informational [Page 18] RFC 4225 Mobile IPv6 RO Security Design December 2005

 protocol features to exhaust the mobile's or the correspondent's
 resources.

3.3.1. Inducing Unnecessary Binding Updates

 When a mobile node receives an IP packet from a new correspondent via
 the home agent, it may initiate the binding update protocol.  An
 attacker can exploit this by sending the mobile node a spoofed IP
 packet (e.g., ping or TCP SYN packet) that appears to come from a new
 correspondent node.  Since the packet arrives via the home agent, the
 mobile node may start the binding update protocol with the
 correspondent node.  The decision as to whether to initiate the
 binding update procedure may depend on several factors (including
 heuristics, cross layer information, and configuration options) and
 is not specified by Mobile IPv6.  Not initiating the binding update
 procedure automatically may alleviate these attacks, but it will not,
 in general, prevent them completely.
 In a real attack the attacker would induce the mobile node to
 initiate binding update protocols with a large number of
 correspondent nodes at the same time.  If the correspondent addresses
 are real addresses of existing IP nodes, then most instances of the
 binding update protocol might even complete successfully.  The
 entries created in the Binding Cache are correct but useless.  In
 this way, the attacker can induce the mobile to execute the binding
 update protocol unnecessarily, which can drain the mobile's
 resources.
 A correspondent node (i.e., any IP node) can also be attacked in a
 similar way.  The attacker sends spoofed IP packets to a large number
 of mobiles, with the target node's address as the source address.
 These mobiles will initiate the binding update protocol with the
 target node.  Again, most of the binding update protocol executions
 will complete successfully.  By inducing a large number of
 unnecessary binding updates, the attacker is able to consume the
 target node's resources.
 This attack is possible against any binding update authentication
 protocol.  The more resources the binding update protocol consumes,
 the more serious the attack.  Therefore, strong cryptographic
 authentication protocol is more vulnerable to the attack than a weak
 one or unauthenticated binding updates.  Ingress filtering helps a
 little, since it makes it harder to forge the source address of the
 spoofed packets, but it does not completely eliminate this threat.
 A node should protect itself from the attack by setting a limit on
 the amount of resources (i.e., processing time, memory, and
 communications bandwidth) that it uses for processing binding

Nikander, et al. Informational [Page 19] RFC 4225 Mobile IPv6 RO Security Design December 2005

 updates.  When the limit is exceeded, the node can simply stop
 attempting route optimization.  Sometimes it is possible to process
 some binding updates even when a node is under the attack.  A mobile
 node may have a local security policy listing a limited number of
 addresses to which binding updates will be sent even when the mobile
 node is under DoS attack.  A correspondent node (i.e., any IP node)
 may similarly have a local security policy listing a limited set of
 addresses from which binding updates will be accepted even when the
 correspondent is under a binding update DoS attack.
 The node may also recognize addresses with it had meaningful
 communication in the past and only send binding updates to, or accept
 them from, those addresses.  Since it may be impossible for the IP
 layer to know about the protocol state in higher protocol layers, a
 good measure of the meaningfulness of the past communication is
 probably per-address packet counts.  Alternatively, Neighbor
 Discovery [2] (Section 5.1, Conceptual Data Structures) defines the
 Destination Cache as a set of entries about destinations to which
 traffic has been sent recently.  Thus, implementors may wish to use
 the information in the Destination Cache.
 Section 11.7.2 ("Correspondent Registration") in [6] does not specify
 when such a route optimization procedure should be initiated.  It
 does indicate when it may justifiable to do so, but these hints are
 not enough.  This remains an area where more work is needed.
 Obviously, given that route optimization is optional, any node that
 finds the processing load excessive or unjustified may simply turn it
 off (either selectively or completely).

3.3.2. Forcing Non-Optimized Routing

 As a variant of the previous attack, the attacker can prevent a
 correspondent node from using route optimization by filling its
 Binding Cache with unnecessary entries so that most entries for real
 mobiles are dropped.
 Any successful DoS attack against a mobile or correspondent node can
 also prevent the processing of binding updates.  We have previously
 suggested that the target of a DoS attack may respond by stopping
 route optimization for all or some communication.  Obviously, an
 attacker can exploit this fallback mechanism and force the target to
 use the less efficient home agent-based routing.  The attacker only
 needs to mount a noticeable DoS attack against the mobile or
 correspondent, and the target will default to non-optimized routing.
 The target node can mitigate the effects of the attack by reserving
 more space for the Binding Cache, by reverting to non-optimized
 routing only when it cannot otherwise cope with the DoS attack, by

Nikander, et al. Informational [Page 20] RFC 4225 Mobile IPv6 RO Security Design December 2005

 trying aggressively to return to optimized routing, or by favoring
 mobiles with which it has an established relationship.  This attack
 is not as serious as the ones described earlier, but applications
 that rely on Route Optimization could still be affected.  For
 instance, conversational multimedia sessions can suffer drastically
 from the additional delays caused by triangle routing.

3.3.3. Reflection and Amplification

 Attackers sometimes try to hide the source of a packet-flooding
 attack by reflecting the traffic from other nodes [1].  That is,
 instead of sending the flood of packets directly to the target, the
 attacker sends data to other nodes, tricking them to send the same
 number, or more, packets to the target.  Such reflection can hide the
 attacker's address even when ingress filtering prevents source
 address spoofing.  Reflection is particularly dangerous if the
 packets can be reflected multiple times, if they can be sent into a
 looping path, or if the nodes can be tricked into sending many more
 packets than they receive from the attacker, because such features
 can be used to amplify the traffic by a significant factor.  When
 designing protocols, one should avoid creating services that can be
 used for reflection and amplification.
 Triangle routing would easily create opportunities for reflection: a
 correspondent node receives packets (e.g., TCP SYN) from the mobile
 node and replies to the home address given by the mobile node in the
 Home Address Option (HAO).  The mobile might not really be a mobile
 and the home address could actually be the target address.  The
 target would only see the packets sent by the correspondent and could
 not see the attacker's address (even if ingress filtering prevents
 the attacker from spoofing its source address).
      +----------+ TCP SYN with HAO    +-----------+
      | Attacker |-------------------->| Reflector |
      +----------+                     +-----------+
                                             |
                                             | TCP SYN-ACK to HoA
                                             V
                                       +-----------+
                                       | Flooding  |
                                       | target    |
                                       +-----------+
                        Figure 5.  Reflection Attack
 A badly designed binding update protocol could also be used for
 reflection: the correspondent would respond to a data packet by
 initiating the binding update authentication protocol, which usually

Nikander, et al. Informational [Page 21] RFC 4225 Mobile IPv6 RO Security Design December 2005

 involves sending a packet to the home address.  In that case, the
 reflection attack can be discouraged by copying the mobile's address
 into the messages sent by the mobile to the correspondent.  (The
 mobile's source address is usually the same as the care-of address,
 but an Alternative Care-of Address sub-option can specify a different
 care-of address.)  Some of the early proposals for MIPv6 security
 used this approach and were prone to reflection attacks.
 In some of the proposals for binding update authentication protocols,
 the correspondent node responded to an initial message from the
 mobile with two packets (one to the home address, one to the care-of
 address).  It would have been possible to use this to amplify a
 flooding attack by a factor of two.  Furthermore, with public-key
 authentication, the packets sent by the correspondent might have been
 significantly larger than the one that triggers them.
 These types of reflection and amplification can be avoided by
 ensuring that the correspondent only responds to the same address
 from which it received a packet, and only with a single packet of the
 same size.  These principles have been applied to MIPv6 security
 design.

3.4. Classification of Attacks

 Sect. Attack name                            Target Sev. Mitigation
 ---------------------------------------------------------------------
 3.1.1 Basic address stealing                 MN     Med. RR
 3.1.2 Stealing addresses of stationary nodes Any    High RR
 3.1.3 Future address stealing                MN     Low  RR, lifetime
 3.1.4 Attacks against secrecy and integrity  MN     Low  RR, IPsec
 3.1.5 Basic denial-of-service attacks        Any    Med. RR
 3.1.6 Replaying and blocking binding updates MN     Low  lifetime,
                                                          seq number,
                                                          MAC
 3.2.1 Basic flooding                         Any    High RR
 3.2.2 Return-to-home flooding                Any    High RR
 3.3.1 Inducing unnecessary binding updates   MN, CN Med. heuristics
 3.3.2 Forcing non-optimized routing          MN     Low  heuristics
 3.3.3 Reflection and amplification           N/A    Med. BU design
                Figure 6.  Summary of Discussed Attacks
 Figure 6 gives a summary of the attacks discussed.  As it stands at
 the time of writing, the return-to-the-home flooding and the
 induction of unnecessary binding updates look like the threats
 against which we have the least amount of protection, compared to
 their severity.

Nikander, et al. Informational [Page 22] RFC 4225 Mobile IPv6 RO Security Design December 2005

3.5. Problems with Infrastructure-Based Authorization

 Early in the MIPv6 design process, it was assumed that plain IPsec
 could be the default way to secure Binding Updates with arbitrary
 correspondent nodes.  However, this turned out to be impossible.
 Plain IPsec relies on an infrastructure for key management, which, to
 be usable with any arbitrary pair of nodes, would need to be global
 in scope.  Such a "global PKI" does not exist, nor is it expected to
 come into existence any time soon.
 More minor issues that also surfaced at the time were: (1)
 insufficient filtering granularity for the state of IPsec at the
 time, (2) cost to establish a security association (in terms of CPU
 and round trip times), and (3) expressing the proper authorization
 (as opposed to just authentication) for binding updates [13].  These
 issues are solvable, and, in particular, (1) and (3) have been
 addressed for IPsec usage with binding updates between the mobile
 node and the home agent [7].
 However, the lack of a global PKI remains unsolved.
 One way to provide a global key infrastructure for mobile IP could be
 DNSSEC.  Such a scheme is not completely supported by the existing
 specifications, as it constitutes a new application of the KEY RR,
 something explicitly limited to DNSSEC [8] [9] [10].  Nevertheless,
 if one were to define it, one could proceed along the following
 lines: A secure reverse DNS that provided a public key for each IP
 address could be used to verify that a binding update is indeed
 signed by an authorized party.  However, in order to be secure, each
 link in such a system must be secure.  That is, there must be a chain
 of keys and signatures all the way down from the root (or at least
 starting from a trust anchor common to the mobile node and the
 correspondent node) to the given IP address.  Furthermore, it is not
 enough that each key be signed by the key above it in the chain.  It
 is also necessary that each signature explicitly authorize the lower
 key to manage the corresponding address block below.
 Even though it would be theoretically possible to build a secure
 reverse DNS infrastructure along the lines shown above, the practical
 problems would be daunting.  Whereas the delegation and key signing
 might work close to the root of the tree, it would probably break
 down somewhere along the path to the individual nodes.  Note that a
 similar delegation tree is currently being proposed for Secure
 Neighbor Discovery [15], although in this case only routers (not
 necessarily every single potential mobile node) need to secure such a
 certificate.  Furthermore, checking all the signatures on the tree
 would place a considerable burden on the correspondent nodes, making
 route optimization prohibitive, or at least justifiable only in very

Nikander, et al. Informational [Page 23] RFC 4225 Mobile IPv6 RO Security Design December 2005

 particular circumstances.  Finally, it is not enough simply to check
 whether the mobile node is authorized to send binding updates
 containing a given home address, because to protect against flooding
 attacks, the care-of address must also be verified.
 Relying on this same secure DNS infrastructure to verify care-of
 addresses would be even harder than verifying home addresses.
 Instead, a different method would be required, e.g., a return
 routability procedure.  If so, the obvious question is whether the
 gargantuan cost of deploying the global secure DNS infrastructure is
 worth the additional protection it affords, as compared to simply
 using return routability for both home address and care-of address
 verification.

4. Solution Selected for Mobile IPv6

 The current Mobile IPv6 route optimization security has been
 carefully designed to prevent or mitigate the threats that were
 discussed in Section 3.  The goal has been to produce a design with a
 level of security close to that of a static IPv4-based Internet, and
 with an acceptable cost in terms of packets, delay, and processing.
 The result is not what one would expect: it is definitely not a
 traditional cryptographic protocol.  Instead, the result relies
 heavily on the assumption of an uncorrupted routing infrastructure
 and builds upon the idea of checking that an alleged mobile node is
 indeed reachable through both its home address and its care-of
 address.  Furthermore, the lifetime of the state created at the
 corresponded nodes is deliberately restricted to a few minutes, in
 order to limit the potential threat from time shifting.
 This section describes the solution in reasonable detail (for further
 details see the specification), starting from Return Routability
 (Section 4.1), continuing with a discussion about state creation at
 the correspondent node (Section 4.2), and completing the description
 with a discussion about the lifetime of Binding Cache Entries
 (Section 4.3).

4.1. Return Routability

 Return Routability (RR) is the name of the basic mechanism deployed
 by Mobile IPv6 route optimization security design.  RR is based on
 the idea that a node should be able to verify that there is a node
 that is able to respond to packets sent to a given address.  The
 check yields false positives if the routing infrastructure is
 compromised or if there is an attacker between the verifier and the
 address to be verified.  With these exceptions, it is assumed that a
 successful reply indicates that there is indeed a node at the given

Nikander, et al. Informational [Page 24] RFC 4225 Mobile IPv6 RO Security Design December 2005

 address, and that the node is willing to reply to the probes sent to
 it.
 The basic return routability mechanism consists of two checks, a Home
 Address check (see Section 4.1.1) and a care-of-address check (see
 Section 4.1.2).  The packet flow is depicted in Figure 7.  First, the
 mobile node sends two packets to the correspondent node: a Home Test
 Init (HoTI) packet is sent through the home agent, and a Care-of Test
 Init (CoTI) directly.  The correspondent node replies to both of
 these independently by sending a Home Test (HoT) in response to the
 Home Test Init and a Care-of Test (CoT) in response to the Care-of
 Test Init.  Finally, once the mobile node has received both the Home
 Test and Care-of Test packets, it sends a Binding Update to the
 correspondent node.
         +------+   1a) HoTI            +------+
         |      |---------------------->|      |
         |  MN  |   2a) HoT             |  HA  |
         |      |<----------------------|      |
         +------+                       +------+
 1b) CoTI | ^  |                        /  ^
          | |2b| CoT                   /  /
          | |  |                      /  /
          | |  | 3) BU               /  /
          V |  V                    /  /
         +------+   1a) HoTI       /  /
         |      |<----------------/  /
         |  CN  |   2a) HoT         /
         |      |------------------/
         +------+
               Figure 7.  Return Routability Packet Flow
 It might appear that the actual design was somewhat convoluted.  That
 is, the real return routability checks are the message pairs < Home
 Test, Binding Update > and < Care-of Test, Binding Update >.  The
 Home Test Init and Care-of Test Init packets are only needed to
 trigger the test packets, and the Binding Update acts as a combined
 routability response to both of the tests.
 There are two main reasons behind this design:
 o  avoidance of reflection and amplification (see Section 3.3.3), and
 o  avoidance of state exhaustion DoS attacks (see Section 4.2).
 The reason for sending two Init packets instead of one is to avoid
 amplification.  The correspondent node does not know anything about

Nikander, et al. Informational [Page 25] RFC 4225 Mobile IPv6 RO Security Design December 2005

 the mobile node, and therefore it just receives an unsolicited IP
 packet from some arbitrary IP address.  In a way, this is similar to
 a server receiving a TCP SYN from a previously unknown client.  If
 the correspondent node were to send two packets in response to an
 initial trigger, that would provide the potential for a DoS
 amplification effect, as discussed in Section 3.3.3.
 This scheme also avoids providing for a potential reflection attack.
 If the correspondent node were to reply to an address other than the
 source address of the packet, that would create a reflection effect.
 Thus, the only safe mechanism possible for a naive correspondent is
 to reply to each received packet with just one packet, and to send
 the reply to the source address of the received packet.  Hence, two
 initial triggers are needed instead of just one.
 Let us now consider the two return routability tests separately.  In
 the following sections, the derivation of cryptographic material from
 each of these is shown in a simplified manner.  For the real formulas
 and more detail, please refer to [6].

4.1.1. Home Address Check

 The Home Address check consists of a Home Test (HoT) packet and a
 subsequent Binding Update (BU).  It is triggered by the arrival of a
 Home Test Init (HoTI).  A correspondent node replies to a Home Test
 Init by sending a Home Test to the source address of the Home Test
 Init.  The source address is assumed to be the home address of a
 mobile node, and therefore the Home Test is assumed to be tunneled by
 the Home Agent to the mobile node.  The Home Test contains a
 cryptographically generated token, home keygen token, which is formed
 by calculating a hash function over the concatenation of a secret
 key, Kcn, known only by the correspondent node, the source address of
 the Home Test Init packet, and a nonce.
    home keygen token = hash(Kcn | home address | nonce | 0)
 An index to the nonce is also included in the Home Test packet,
 allowing the correspondent node to find the appropriate nonce more
 easily.
 The token allows the correspondent node to make sure that any binding
 update received subsequently has been created by a node that has seen
 the Home Test packet; see Section 4.2.
 In most cases, the Home Test packet is forwarded over two different
 segments of the Internet.  It first traverses from the correspondent
 node to the Home Agent.  On this trip, it is not protected and any
 eavesdropper on the path can learn its contents.  The Home Agent then

Nikander, et al. Informational [Page 26] RFC 4225 Mobile IPv6 RO Security Design December 2005

 forwards the packet to the mobile node.  This path is taken inside an
 IPsec ESP protected tunnel, making it impossible for the outsiders to
 learn the contents of the packet.
 At first, it may sound unnecessary to protect the packet between the
 home agent and the mobile node, since it travelled unprotected
 between the correspondent node and the mobile node.  If all links in
 the Internet were equally insecure, the additional protection would
 be unnecessary.  However, in most practical settings the network is
 likely to be more secure near the home agent than near the mobile
 node.  For example, if the home agent hosts a virtual home link and
 the mobile nodes are never actually at home, an eavesdropper should
 be close to the correspondent node or on the path between the
 correspondent node and the home agent, since it could not eavesdrop
 at the home agent.  If the correspondent node is a major server, all
 the links on the path between it and the home agent are likely to be
 fairly secure.  On the other hand, the Mobile Node is probably using
 wireless access technology, making it sometimes trivial to eavesdrop
 on its access link.  Thus, it is fairly easy to eavesdrop on packets
 that arrive at the mobile node.  Consequently, protecting the HA-MN
 path is likely to provide real security benefits even when the CN-HA
 path remains unprotected.

4.1.2. Care-of-Address Check

 From the correspondent node's point of view, the Care-of-Address
 check is very similar to the home check.  The only difference is that
 now the source address of the received Care-of Test Init packet is
 assumed to be the care-of address of the mobile node.  Furthermore,
 the token is created in a slightly different manner in order to make
 it impossible to use home tokens for care-of tokens or vice versa.
    care-of keygen token = hash(Kcn | care-of address | nonce | 1)
 The Care-of Test traverses only one leg, directly from the
 correspondent node to the mobile node.  It remains unprotected all
 along the way, making it vulnerable to eavesdroppers near the
 correspondent node, on the path from the correspondent node to the
 mobile node, or near the mobile node.

4.1.3. Forming the First Binding Update

 When the mobile node has received both the Home Test and Care-of Test
 messages, it creates a binding key, Kbm, by computing a hash function
 over the concatenation of the tokens received.
 This key is used to protect the first and the subsequent binding
 updates, as long as the key remains valid.

Nikander, et al. Informational [Page 27] RFC 4225 Mobile IPv6 RO Security Design December 2005

 Note that the key Kbm is available to anyone who is able to receive
 both the Care-of Test and Home Test messages.  However, they are
 normally routed by different routes through the network, and the Home
 Test is transmitted over an encrypted tunnel from the home agent to
 the mobile node (see also Section 5.4).

4.2. Creating State Safely

 The correspondent node may remain stateless until it receives the
 first Binding Update.  That is, it does not need to record receiving
 and replying to the Home Test Init and Care-of Test Init messages.
 The Home Test Init/Home Test and Care-of Test Init/Care-of Test
 exchanges take place in parallel but independently of each other.
 Thus, the correspondent can respond to each message immediately, and
 it does not need to remember doing that.  This helps in potential
 denial-of-service situations: no memory needs to be reserved for
 processing Home Test Init and Care-of Test Init messages.
 Furthermore, Home Test Init and Care-of Test Init processing is
 designed to be lightweight, and it can be rate limited if necessary.
 When receiving a first binding update, the correspondent node goes
 through a rather complicated procedure.  The purpose of this
 procedure is to ensure that there is indeed a mobile node that has
 recently received a Home Test and a Care-of Test that were sent to
 the claimed home and care-of addresses, respectively, and to make
 sure that the correspondent node does not unnecessarily spend CPU or
 other resources while performing this check.
 Since the correspondent node does not have any state when the binding
 update arrives, the binding update itself must contain enough
 information so that relevant state can be created.  To that end, the
 binding update contains the following pieces of information:
 Source address:  The care-of address specified in the Binding Update
    must be equal to the source address used in the Care-of Test Init
    message.  Notice that this applies to the effective Care-of
    Address of the Binding Update.  In particular, if the Binding
    Update includes an Alternate Care-of Address (AltCoA) [6], the
    effective CoA is, of course, this AltCoA.  Thus, the Care-of Test
    Init must have originated from the AltCoA.
 Home address:  The home address specified in the Binding Update must
    be equal to the source address used in the Home Test Init message.
 Two nonce indices:  These are copied over from the Home Test and
    Care-of Test messages, and together with the other information
    they allow the correspondent node to re-create the tokens sent in
    the Home Test and Care-of Test messages and used for creating Kbm.

Nikander, et al. Informational [Page 28] RFC 4225 Mobile IPv6 RO Security Design December 2005

    Without them, the correspondent node might need to try the 2-3
    latest nonces, leading to unnecessary resource consumption.
 Message Authentication Code (MAC):  The binding update is
    authenticated by computing a MAC function over the care-of
    address, the correspondent node's address and the binding update
    message itself.  The MAC is keyed with the key Kbm.
 Given the addresses, the nonce indices (and thereby the nonces) and
 the key Kcn, the correspondent node can re-create the home and care-
 of tokens at the cost of a few memory lookups and computation of one
 MAC and one hash function.
 Once the correspondent node has re-created the tokens, it hashes the
 tokens together, giving the key Kbm.  If the Binding Update is
 authentic, Kbm is cached together with the binding.  This key is then
 used to verify the MAC that protects integrity and origin of the
 actual Binding Update.  Note that the same Kbm may be used for a
 while, until the mobile node moves (and needs to get a new care-of-
 address token), the care-of token expires, or the home token expires.

4.2.1. Retransmissions and State Machine

 Note that since the correspondent node may remain stateless until it
 receives a valid binding update, the mobile node is solely
 responsible for retransmissions.  That is, the mobile node should
 keep sending the Home Test Init / Care-of Test Init messages until it
 receives a Home Test / Care-of Test, respectively.  Similarly, it may
 need to send the binding update a few times in the case it is lost
 while in transit.

4.3. Quick expiration of the Binding Cache Entries

 A Binding Cache Entry, along with the key Kbm, represents the return
 routability state of the network at the time when the Home Test and
 Care-of Test messages were sent out.  It is possible that a specific
 attacker is able to eavesdrop a Home Test message at some point of
 time, but not later.  If the Home Test had an infinite or a long
 lifetime, that would allow the attacker to perform a time shifting
 attack (see Section 2.2).  That is, in the current IPv4 architecture
 an attacker on the path between the correspondent node and the home
 agent is able to perform attacks only as long as the attacker is able
 to eavesdrop (and possibly disrupt) communications on that particular
 path.  A long living Home Test, and consequently the ability to send
 valid binding updates for a long time, would allow the attacker to
 continue its attack even after the attacker is no longer able to
 eavesdrop on the path.

Nikander, et al. Informational [Page 29] RFC 4225 Mobile IPv6 RO Security Design December 2005

 To limit the seriousness of this and other similar time shifting
 threats, the validity of the tokens is limited to a few minutes.
 This effectively limits the validity of the key Kbm and the lifetime
 of the resulting binding updates and binding cache entries.
 Although short lifetimes are required by other aspects of the
 security design and the goals, they are clearly detrimental for
 efficiency and robustness.  That is, a Home Test Init / Home Test
 message pair must be exchanged through the home agent every few
 minutes.  These messages are unnecessary from a purely functional
 point of view, thereby representing overhead.  What is worse, though,
 is that they make the home agent a single point of failure.  That is,
 if the Home Test Init / Home Test messages were not needed, the
 existing connections from a mobile node to other nodes could continue
 even when the home agent fails, but the current design forces the
 bindings to expire after a few minutes.
 This concludes our walk-through of the selected security design.  The
 cornerstones of the design were the employment of the return
 routability idea in the Home Test, Care-of Test, and binding update
 messages, the ability to remain stateless until a valid binding
 update is received, and the limiting of the binding lifetimes to a
 few minutes.  Next we briefly discuss some of the remaining threats
 and other problems inherent to the design.

5. Security Considerations

 This section gives a brief analysis of the security design, mostly in
 the light of what was known when the design was completed in Fall
 2002.  It should be noted that this section does not present a proper
 security analysis of the protocol; it merely discusses a few issues
 that were known at the time the design was completed.
 It should be kept in mind that the MIPv6 RO security design was never
 intended to be fully secure.  Instead, as we stated earlier, the goal
 was to be roughly as secure as non-mobile IPv4 was known to be at the
 time of the design.  As it turns out, the result is slightly less
 secure than IPv4, but the difference is small and most likely
 insignificant in real life.
 The known residual threats as compared with IPv4 are discussed in
 Section 5.1.  Considerations related to the application of IPsec to
 authorize route optimization are discussed in Section 5.2.  Section
 5.3 discusses an attack against neighboring nodes.  Finally, Section
 5.4 deals with the special case of two mobile nodes conversing and
 performing the route optimization procedure with each other.

Nikander, et al. Informational [Page 30] RFC 4225 Mobile IPv6 RO Security Design December 2005

5.1. Residual Threats as Compared to IPv4

 As we mentioned in Section 4.2, the lifetime of a binding represents
 a potential time shift in an attack.  That is, an attacker that is
 able to create a false binding is able to reap the benefits of the
 binding as long as the binding lasts.  Alternatively, the attacker is
 able to delay a return-to-home flooding attack (Section 3.2.2) until
 the binding expires.  This is different from IPv4, where an attacker
 may continue an attack only as long as it is on the path between the
 two hosts.
 Since the binding lifetimes are severely restricted in the current
 design, the ability to do a time shifting attack is equivalently
 restricted.
 Threats possible because of the introduction of route optimization
 are, of course, not present in a baseline IPv4 internet (Section
 3.3).  In particular, inducing unnecessary binding updates could
 potentially be a severe attack, but this would be most likely due to
 faulty implementations.  As an extreme measure, a correspondent node
 can protect against these attacks by turning off route optimization.
 If so, it becomes obvious that the only residual attack against which
 there is no clear-cut prevention (other than its severe limitation as
 currently specified) is the time shifting attack mentioned above.

5.2. Interaction with IPsec

 A major motivation behind the current binding update design was
 scalability, which implied the ability to run the protocol without
 any existing security infrastructure.  An alternative would have been
 to rely on existing trust relationships, perhaps in the form of a
 special-purpose Public Key Infrastructure in conjunction with IPsec.
 That would have limited scalability, making route optimization
 available only in environments where it is possible to create
 appropriate IPsec security associations between the mobile nodes and
 the corresponding nodes.
 There clearly are situations where there exists an appropriate
 relationship between a mobile node and the correspondent node.  For
 example, if the correspondent node is a server that has pre-
 established keys with the mobile node, that would be the case.
 However, entity authentication or an authenticated session key is not
 necessarily sufficient for accepting Binding Updates.
 Home Address Check:  If one wants to replace the home address check
    with cryptographic credentials, these must carry proper
    authorization for the specific home address, and care must be
    taken to make sure that the issuer of the certificate is entitled

Nikander, et al. Informational [Page 31] RFC 4225 Mobile IPv6 RO Security Design December 2005

    to express such authorization.  At the time of the design work,
    the route optimization security design team was not aware of
    standardized certificate formats to do this, although more recent
    efforts within the IETF are addressing this issue.  Note that
    there is plenty of motivation to do so, as any pre-existing
    relationship with a correspondent node would involve the mobile
    node's home address (instead of any of its possible care-of
    addresses).  Accordingly, the IKE exchange would most naturally
    run between the correspondent node and the mobile node's home
    address.  This still leaves open the issue of checking the mobile
    node's care-of address.
 Care-of Address Check:  As for the care-of-address check, in
    practice, it seems highly unlikely that nodes could completely
    replace the care-of-address check with credentials.  Since the
    care-of addresses are ephemeral, in general it is very difficult
    for a mobile node to present credentials that taken at face value
    (by an arbitrary correspondent node) guarantee no misuse for, say,
    flooding attacks (Section 3.2).  As discussed before, a
    reachability check goes a long way to alleviate such attacks.
    Notice that, as part of the normal protocol exchange, establishing
    IPsec security associations via IKE includes one such reachability
    test.  However, as per the previous section, the natural IKE
    protocol exchange runs between the correspondent node and the
    mobile node's home address.  Hence, another reachability check is
    needed to check the care-of address at which the node is currently
    reachable.  If this address changes, such a reachability test is
    likewise necessary, and it is included in ongoing work aimed at
    securely updating the node's current address.
 Nevertheless, the Mobile IPv6 base specification [6] does not specify
 how to use IPsec together with the mobility procedures between the
 mobile node and correspondent node.  On the other hand, the
 specification is carefully written to allow the creation of the
 binding management key Kbm through some different means.
 Accordingly, where an appropriate relationship exists between a
 mobile node and a correspondent node, the use of IPsec is possible,
 and is, in fact, being pursued in more recent work.

5.3. Pretending to Be One's Neighbor

 One possible attack against the security design is to pretend to be a
 neighboring node.  To launch this attack, the mobile node establishes
 route optimization with some arbitrary correspondent node.  While
 performing the return routability tests and creating the binding
 management key Kbm, the attacker uses its real home address but a
 faked care-of address.  Indeed, the care-of address would be the
 address of the neighboring node on the local link.  The attacker is

Nikander, et al. Informational [Page 32] RFC 4225 Mobile IPv6 RO Security Design December 2005

 able to create the binding since it receives a valid Home Test
 normally, and it is able to eavesdrop on the Care-of Test, as it
 appears on the local link.
 This attack would allow the mobile node to divert unwanted traffic
 towards the neighboring node, resulting in an flooding attack.
 However, this attack is not very serious in practice.  First, it is
 limited in the terms of location, since it is only possible against
 neighbors.  Second, the attack works also against the attacker, since
 it shares the local link with the target.  Third, a similar attack is
 possible with Neighbor Discovery spoofing.

5.4. Two Mobile Nodes Talking to Each Other

 When two mobile nodes want to establish route optimization with each
 other, some care must be exercised in order not to reveal the reverse
 tokens to an attacker.  In this situation, both mobile nodes act
 simultaneously in the mobile node and the correspondent node roles.
 In the correspondent node role, the nodes are vulnerable to attackers
 that are co-located at the same link.  Such an attacker is able to
 learn both the Home Test and Care-of Test sent by the mobile node,
 and therefore it is able to spoof the location of the other mobile
 host to the neighboring one.  What is worse is that the attacker can
 obtain a valid Care-of Test itself, combine it with the Home Test,
 and then claim to the neighboring node that the other node has just
 arrived at the same link.
 There is an easy way to avoid this attack.  In the correspondent node
 role, the mobile node should tunnel the Home Test messages that it
 sends through its home agent.  This prevents the co-located attacker
 from learning any valid Home Test messages.

6. Conclusions

 This document discussed the security design rationale for the Mobile
 IPv6 Route Optimization.  We have tried to describe the dangers
 created by Mobile IP Route Optimization, the security goals and
 background of the design, and the actual mechanisms employed.
 We started the discussion with a background tour to the IP routing
 architecture the definition of the mobility problem.  After that, we
 covered the avenues of attack: the targets, the time shifting
 abilities, and the possible locations of an attacker.  We outlined a
 number of identified threat scenarios, and discussed how they are
 mitigated in the current design.  Finally, in Section 4 we gave an
 overview of the actual mechanisms employed, and the rational behind
 them.

Nikander, et al. Informational [Page 33] RFC 4225 Mobile IPv6 RO Security Design December 2005

 As far as we know today, the only significant difference between the
 security of an IPv4 Internet and that of an Internet with Mobile IPv6
 (and route optimization) concerns time shifting attacks.
 Nevertheless, these are severely restricted in the current design.
 We have also briefly covered some of the known subtleties and
 shortcomings, but that discussion cannot be exhaustive.  It is quite
 probable that new subtle problems will be discovered with the design.
 As a consequence, it is most likely that the design needs to be
 revised in the light of experience and insight.

7. Acknowledgements

 We are grateful for: Hesham Soliman for reminding us about the threat
 explained in Section 5.3, Francis Dupont for first discussing the
 case of two mobile nodes talking to each other (Section 5.4) and for
 sundry other comments, Pekka Savola for his help in Section 1.1.1,
 and Elwyn Davies for his thorough editorial review.

8. Informative References

 [1]   Aura, T., Roe, M., and J. Arkko, "Security of Internet Location
       Management", Proc. 18th Annual Computer Security Applications
       Conference, pages 78-87, Las Vegas, NV, USA, IEEE Press,
       December 2002.
 [2]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
       for IP Version 6 (IPv6)", RFC 2461, December 1998.
 [3]   Narten, T. and R. Draves, "Privacy Extensions for Stateless
       Address Autoconfiguration in IPv6", RFC 3041, January 2001.
 [4]   Bush, R. and D. Meyer, "Some Internet Architectural Guidelines
       and Philosophy", RFC 3439, December 2002.
 [5]   Baker, F. and P. Savola, "Ingress Filtering for Multihomed
       Networks", BCP 84, RFC 3704, March 2004.
 [6]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
       IPv6", RFC 3775, June 2004.
 [7]   Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
       Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
       Agents", RFC 3776, June 2004.
 [8]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
       "DNS Security Introduction and Requirements", RFC 4033, March
       2005.

Nikander, et al. Informational [Page 34] RFC 4225 Mobile IPv6 RO Security Design December 2005

 [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
       "Resource Records for the DNS Security Extensions", RFC 4034,
       March 2005.
 [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
       "Protocol Modifications for the DNS Security Extensions", RFC
       4035, March 2005.
 [11]  Chiappa, J., "Will The Real 'End-End Principle' Please Stand
       Up?", Private Communication, April 2002.
 [12]  Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP
       Congestion Control with a Misbehaving Receiver", ACM Computer
       Communication Review, 29:5, October 1999.
 [13]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
       Authentication in the IPv6 World", Security Protocols 9th
       International Workshop, Cambridge, UK, April 25-27 2001, LNCS
       2467, pages 12-26, Springer, 2002.
 [14]  Chiappa, J., "Endpoints and Endpoint Names: A Proposed
       Enhancement to the Internet Architecture", Private
       Communication, 1999.
 [15]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
       Neighbor Discovery (SEND)", RFC 3971, March 2005.

Nikander, et al. Informational [Page 35] RFC 4225 Mobile IPv6 RO Security Design December 2005

Authors' Addresses

 Pekka Nikander
 Ericsson Research NomadicLab
 JORVAS  FIN-02420
 FINLAND
 Phone: +358 9 299 1
 EMail: pekka.nikander@nomadiclab.com
 Jari Arkko
 Ericsson Research NomadicLab
 JORVAS  FIN-02420
 FINLAND
 EMail: jari.arkko@ericsson.com
 Tuomas Aura
 Microsoft Research Ltd.
 Roger Needham Building
 7  JJ Thomson Avenue
 Cambridge CB3 0FB
 United Kingdom
 EMail: Tuomaura@microsoft.com
 Gabriel Montenegro
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA  98052
 USA
 EMail: gabriel_montenegro_2000@yahoo.com
 Erik Nordmark
 Sun Microsystems
 17 Network Circle
 Menlo Park, CA 94025
 USA
 EMail: erik.nordmark@sun.com

Nikander, et al. Informational [Page 36] RFC 4225 Mobile IPv6 RO Security Design December 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

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

Nikander, et al. Informational [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4225.txt · Last modified: 2005/12/13 22:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki