doc: Add RFC documents

1 files changed, 3027 insertions, 0 deletions

diff --git a/doc/rfc/rfc4866.txt b/doc/rfc/rfc4866.txt
new file mode 100644
index 0000000..29ca054
--- /dev/null
+++ b/doc/rfc/rfc4866.txt
@@ -0,0 +1,3027 @@
+
+
+
+
+
+
+Network Working Group                                           J. Arkko
+Request for Comments: 4866                  Ericsson Research NomadicLab
+Category: Standards Track                                        C. Vogt
+                                             Universitaet Karlsruhe (TH)
+                                                               W. Haddad
+                                                       Ericsson Research
+                                                                May 2007
+
+
+              Enhanced Route Optimization for Mobile IPv6
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document specifies an enhanced version of Mobile IPv6 route
+   optimization, providing lower handoff delays, increased security, and
+   reduced signaling overhead.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Objectives ......................................................4
+      2.1. Handoff Latency ............................................5
+      2.2. Security ...................................................5
+      2.3. Signaling Overhead .........................................7
+   3. Protocol Design .................................................7
+      3.1. Cryptographically Generated Home Addresses .................7
+      3.2. Non-Cryptographic Care-of Addresses ........................8
+      3.3. Semi-Permanent Security Associations .......................8
+      3.4. Initial Home Address Tests .................................8
+      3.5. Concurrent Care-of Address Tests ...........................9
+      3.6. Credit-Based Authorization .................................9
+      3.7. Parallel Home and Correspondent Registrations .............10
+   4. Protocol Operation .............................................10
+      4.1. Sending Binding Update Messages ...........................10
+      4.2. Receiving Binding Update Messages .........................18
+      4.3. Sending Binding Acknowledgment Messages ...................22
+
+
+
+Arkko, et al.               Standards Track                     [Page 1]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+      4.4. Receiving Binding Acknowledgment Messages .................23
+      4.5. Sending CGA Parameters ....................................25
+      4.6. Receiving CGA Parameters ..................................26
+      4.7. Sending Permanent Home Keygen Tokens ......................27
+      4.8. Receiving Permanent Home Keygen Tokens ....................28
+      4.9. Renewing Permanent Home Keygen Tokens .....................28
+      4.10. Handling Payload Packets .................................28
+      4.11. Credit Aging .............................................31
+      4.12. Simultaneous Movements ...................................32
+   5. Option Formats and Status Codes ................................32
+      5.1. CGA Parameters Option .....................................32
+      5.2. Signature Option ..........................................33
+      5.3. Permanent Home Keygen Token Option ........................34
+      5.4. Care-of Test Init Option ..................................35
+      5.5. Care-of Test Option .......................................35
+      5.6. CGA Parameters Request Option .............................36
+      5.7. Status Codes ..............................................36
+   6. Security Considerations ........................................38
+      6.1. Home Address Ownership ....................................39
+      6.2. Care-of Address Ownership .................................41
+      6.3. Credit-Based Authorization ................................43
+      6.4. Time Shifting Attacks .....................................46
+      6.5. Replay Attacks ............................................47
+      6.6. Resource Exhaustion .......................................47
+      6.7. IP Address Ownership of Correspondent Node ................47
+   7. Protocol Constants and Configuration Variables .................49
+   8. IANA Considerations ............................................50
+   9. Acknowledgments ................................................50
+   10. References ....................................................51
+      10.1. Normative References .....................................51
+      10.2. Informative References ...................................51
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko, et al.               Standards Track                     [Page 2]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+1.  Introduction
+
+   Mobile IPv6 route optimization [1] enables mobile and correspondent
+   nodes to communicate via a direct routing path despite changes in IP
+   connectivity on the mobile node side.  Both end nodes use a stable
+   "home address" in identifying the mobile node at stack layers above
+   IP, while payload packets are sent or received via a "care-of
+   address" that routes to the mobile node's current network attachment.
+   Mobile IPv6 swaps the home and care-of addresses when a payload
+   packet traverses the IP layer.  The association between a mobile
+   node's home address and care-of address is called a "binding" for the
+   mobile node.  It is the responsibility of the mobile node to update
+   its binding at the correspondent node through a "correspondent
+   registration" when it changes IP connectivity.  A correspondent
+   registration further involves the mobile node's home agent, which
+   proxies the mobile node at the home address and mainly serves as a
+   relay for payload packets exchanged with correspondent nodes that do
+   not support route optimization.  The mobile node keeps the home agent
+   up to date about its current care-of address by means of "home
+   registrations".
+
+   From a security perspective, the establishment of a binding during a
+   correspondent registration requires the correspondent node to verify
+   the mobile node's ownership of both the home address and the care-of
+   address.  Unprecedented impersonation and flooding threats [5] would
+   arise if correspondent nodes took liberties with respect to these
+   obligations.  A correspondent registration hence incorporates a "home
+   address test" and a "care-of address test", collectively called the
+   "return routability procedure".  These tests allow the correspondent
+   node to probe the mobile node's reachability at the home and care-of
+   addresses in an ad hoc, non-cryptographic manner.  Successful
+   reachability verification at both IP addresses indicates (though it
+   does not guarantee) the mobile node's ownership of the IP addresses,
+   and hence that a binding between the home address and the care-of
+   address is legitimate.
+
+   The advantage of the return routability procedure is that it is
+   lightweight and does not depend on a public-key infrastructure or on
+   a preexisting relationship between the mobile node and the
+   correspondent node.  This facilitates a broad deployment.  On the
+   other hand, the procedure has an adverse impact on handoff delays
+   since both the home address test and the care-of address test consist
+   of an end-to-end message exchange between the mobile node and the
+   correspondent node.  The latency of the home address test may be
+   particularly high because it routes through the home agent.  The
+   return routability procedure is also vulnerable to attackers that are
+   in a position where they can interpose in the home or care-of address
+   test.  The value of interposing is limited in that the return
+
+
+
+Arkko, et al.               Standards Track                     [Page 3]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   routability procedure must be repeated in intervals of at most 7
+   minutes, even in the absence of changes in IP connectivity on the
+   mobile node side.  But this comes at the cost of an increased
+   signaling overhead.  Much effort has therefore gone into improvements
+   for Mobile IPv6 route optimization [6] that mitigate these
+   disadvantages.
+
+   This document specifies Enhanced Route Optimization, an amendment to
+   route optimization in base Mobile IPv6.  Enhanced Route Optimization
+   secures a mobile node's home address against impersonation through an
+   interface identifier that is cryptographically and verifiably bound
+   [2] to the public component of the mobile node's public/private-key
+   pair.  The mobile node proves ownership of the home address by
+   providing evidence that it knows the corresponding private key.  An
+   initial home address test validates the home address prefix;
+   subsequent home address tests are unnecessary.  Enhanced Route
+   Optimization further allows mobile and correspondent nodes to resume
+   bidirectional communications in parallel with pursuing a care-of
+   address test.  The latency of the home and care-of address tests are
+   therefore eliminated in most cases.  The use of cryptographically
+   generated home addresses also mitigates the threat of impersonators
+   that can interpose on the home address test and thereby facilitate
+   longer binding lifetimes.  This leads to increased security and a
+   reduction in signaling overhead.  Cryptographically generated home
+   addresses and concurrent care-of address tests are preferably applied
+   together, but a mobile node may choose to use only one of these
+   enhancements.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [3].
+
+2.  Objectives
+
+   The design of route optimization in base Mobile IPv6 is in many ways
+   conservative, leaving room to optimize handoff delay, security, and
+   signaling overhead.  Enhanced Route Optimization tackles these issues
+   and thus constitutes a more progressive variant of Mobile IPv6.
+
+   Despite any Mobile IPv6 optimizations, it is important to take into
+   account that mobility-related activities elsewhere in the protocol
+   stack may have their own impact.  For example, attachment procedures,
+   access control, and authentication at the link layer contribute their
+   own handoff delays.  So do IP layer tasks such as router discovery,
+   neighbor discovery, movement detection, and IP address configuration.
+   The handoff delays and signaling overhead of Mobile IPv6 are
+
+
+
+
+
+Arkko, et al.               Standards Track                     [Page 4]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   typically small compared to the total delay and overhead.  The
+   improvements of Enhanced Route Optimization hence ought to be seen in
+   view of the entire protocol stack.
+
+2.1.  Handoff Latency
+
+   The typical handoff delay in base Mobile IPv6 route optimization is
+   one round-trip time between the mobile node and the home agent for
+   the home registration, one round-trip time between the mobile node
+   and the home agent plus one round-trip time between the home agent
+   and the correspondent node for the return routability procedure, and
+   one one-way time from the mobile node to the correspondent node for
+   the propagation of the Binding Update message.  (The assumption here
+   is that the latency of the return routability procedure is dominated
+   by the home address test.)  The first payload packet sent to the new
+   care-of address requires one additional one-way time to propagate
+   from the correspondent node to the mobile node.  The mobile node can
+   resume transmissions right after it has dispatched the Binding Update
+   message.  But if it requests a Binding Acknowledgment message from
+   the correspondent node, communications are usually delayed until this
+   is received.
+
+   Handoff delays in base Mobile IPv6 route optimization are additive to
+   other delays at the IP layer or link layer.  They can cause
+   perceptible quality degradations for interactive and real-time
+   applications.  TCP bulk-data transfers are likewise affected since
+   long handoff latencies may lead to successive retransmission timeouts
+   and degraded throughput [7].  An objective of Enhanced Route
+   Optimization is hence a reduction of the handoff latency.
+
+2.2.  Security
+
+   The return routability procedure was designed with the objective to
+   provide a level of security that compares to that of today's non-
+   mobile Internet [5].  As such, it protects against impersonation,
+   denial-of-service, and flooding threats that do not exist in the non-
+   mobile Internet, but that the introduction of mobility would
+   introduce in the absence of appropriate countermeasures.  In
+   particular, the return routability procedure satisfies the following
+   requirements:
+
+   o  An attacker off the path from a correspondent node to a victim
+      should not be able to trick a correspondent node into redirecting
+      packets, which should normally be delivered to a victim, to
+      itself, or to a third IP address.  The attacker could otherwise
+      impersonate the victim to the correspondent node or cause denial
+      of service against the victim.  The attacker may launch these
+
+
+
+
+Arkko, et al.               Standards Track                     [Page 5]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+      attacks from an arbitrary position, which would not necessarily
+      have to be on the path between the victim and the correspondent
+      node.
+
+   o  An attacker off the path from a correspondent node to a victim
+      should not be able to trick the correspondent node into
+      redirecting packets, which should normally be delivered to the
+      attacker itself, to the victim.  The attacker could otherwise
+      flood the victim with unrequested packets.  Such "redirection-
+      based flooding" may be appealing to the attacker because the
+      burden of generating the flooding packets and sending them to the
+      victim would be on the correspondent node rather than on the
+      attacker.  The attacker could spoof multiple correspondent nodes
+      into flooding the same victim.  This would enable the attacker to
+      impact the victim much stronger than with a direct flooding
+      attack, where the attacker itself would generate and send the
+      flooding packets.  Comparable amplification is today only possible
+      through an army of compromised nodes [8].  One way to cause
+      redirection-based flooding is this: The attacker could accomplish
+      the initial TCP handshake for a voluminous file download through
+      its own IP address, and subsequently bind the victim's IP address
+      (as a care-of address) to the attacker's own IP address (or home
+      address).  The correspondent node thereby redirects the download
+      to the victim.  The attacker could spoof acknowledgments on behalf
+      of the victim based on the sequence numbers it learned during the
+      initial handshake in order to maintain or accelerate the download.
+      The acknowledgments would be smaller and typically less than the
+      full-sized segments that the correspondent node generates, hence
+      facilitating the amplification.
+
+   o  Attackers should not be able to cause denial of service against
+      mobile or correspondent nodes through exploiting expensive
+      computations involved in the mobility protocol.
+
+   The return routability procedure precludes impersonation, denial of
+   service, and redirection-based flooding by attackers that are not on
+   the path from a correspondent node to a victim, and it is
+   sufficiently lightweight not to expose expensive operations.  But the
+   return routability procedure fails to protect against attackers that
+   are located on the path from the correspondent node to the victim.
+   Applications that require a higher security level are generally
+   advised to use end-to-end protection such as IP security (IPsec) or
+   Transport Layer Security (TLS).  But even then are they vulnerable to
+   denial of service or flooding.  Furthermore, end-to-end security
+   mechanisms generally require mobile and correspondent nodes to be
+   preconfigured with authentication credentials, or they depend on a
+   public-key infrastructure.  Both would hinder a wide deployment of
+   Mobile IPv6 route optimization if it was a prerequisite for the
+
+
+
+Arkko, et al.               Standards Track                     [Page 6]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   protocol.  An objective of Enhanced Route Optimization is hence to
+   securely authenticate mobile nodes without preconfigured credentials
+   or a public-key infrastructure, even in the presence of attackers on
+   the path from the correspondent node to the victim.
+
+2.3.  Signaling Overhead
+
+   A complete correspondent registration involves six message
+   transmissions at the mobile node, totaling about 376 bytes [9].  This
+   signaling overhead may be acceptable if movements are infrequent.
+   For example, a mobile node that moves once every 30 minutes generates
+   an average of 1.7 bits/s of signaling traffic.  Higher mobility
+   causes more substantial overhead, however.  A cell size of 100 meters
+   and a speed of 120 km/h yields a change in IP connectivity every 3 s
+   and about 1,000 bits/s of signaling traffic.  This is significant
+   compared to a highly compressed voice stream with a typical data rate
+   of 10,000 to 30,000 bits/s.
+
+   Furthermore, base Mobile IPv6 requires mobile nodes to renew a
+   correspondent registration at least every 7 minutes.  The signaling
+   overhead amounts to 7.16 bits/s if the mobile node communicates with
+   a stationary node [9].  It doubles if both peers are mobile.  This
+   overhead may be negligible when the nodes communicate, but it can be
+   an issue for mobile nodes that are inactive and stay at the same
+   location for a while.  These nodes typically prefer to go to standby
+   mode to conserve battery power.  Also, the periodic refreshments
+   consume a fraction of the wireless bandwidth that one could use more
+   efficiently.  These observations lead to the objective of Enhanced
+   Route Optimization to reduce the signaling overhead of a base Mobile
+   IPv6 correspondent registrations as much as possible, in particular
+   when the mobile node does not move for a while.
+
+3.  Protocol Design
+
+   Enhanced Route Optimization consists of a set of optimizations that
+   collectively afford the achievement of the objectives discussed in
+   Section 2.  These optimizations are summarized in the following.
+
+3.1.  Cryptographically Generated Home Addresses
+
+   A Mobile IPv6 binding is conceptually a packet redirection from a
+   home address to a care-of address.  The home address is the source of
+   the redirection and the care-of address is the destination.  The
+   packets to be redirected can hence be identified based on the home
+   address.  This motivates a cryptographic ownership proof for the home
+   address.  Enhanced Route Optimization applies cryptographically
+   generated home addresses for this purpose [10][11].  In general, a
+   Cryptographically Generated Address (CGA) provides a strong,
+
+
+
+Arkko, et al.               Standards Track                     [Page 7]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   cryptographic binding between its interface identifier and the CGA
+   owner's public key.  This facilitates a cryptographic home address
+   ownership proof without a public-key infrastructure, enabling other
+   nodes to securely and autonomously authenticate the CGA owner as
+   such, modulo the correctness of the CGA's subnet prefix.
+   Cryptographically generated home addresses can supersede home address
+   tests with the exception of an initial test for validating the home
+   address prefix.  This facilitates lower handoff delays and longer
+   binding lifetimes, as well as reduced signaling overhead for mobile
+   nodes that temporarily do not move.  Enhanced Route Optimization also
+   optionally enables the correspondent node to prove ownership of its
+   IP address.
+
+3.2.  Non-Cryptographic Care-of Addresses
+
+   In contrast to a home address, a care-of address does not have
+   identifying functionality.  There is hence little benefit in a
+   cryptographic ownership proof of a care-of address.  Given that the
+   care-of address is the destination of a packet redirection, it is
+   rather the mobile node's reachability at the care-of address that
+   matters.  Enhanced Route Optimization uses care-of address tests for
+   this purpose, but allows correspondent nodes to send packets to a new
+   care-of address before the mobile node has been found to be reachable
+   there.
+
+3.3.  Semi-Permanent Security Associations
+
+   CGA-based authentication involves public-key cryptography and is
+   hence computationally much less efficient than authentication through
+   a shared secret key.  The technique further requires a substantial
+   amount of supplementary CGA parameters to be piggybacked onto
+   protected messages.  Enhanced Route Optimization mitigates these
+   disadvantages in that it utilizes an initial CGA-based authentication
+   to securely exchange a secret permanent home keygen token between a
+   mobile node and a correspondent node.  The permanent home keygen
+   token is used to authenticate the mobile node more efficiently in
+   subsequent correspondent registrations.  Mobile and correspondent
+   nodes renew the permanent home keygen token on an infrequent basis.
+   The token is therefore neither constant nor short-lived, which is why
+   the security association between the mobile node and the
+   correspondent node is called "semi-permanent".
+
+3.4.  Initial Home Address Tests
+
+   An initial home address test is necessary despite a cryptographic
+   proof of home address ownership to protect against spoofed subnet
+   prefixes in home addresses.  In the complete absence of home address
+   tests, a malicious node could cryptographically generate a home
+
+
+
+Arkko, et al.               Standards Track                     [Page 8]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   address with the subnet prefix of a victim network, and request a
+   correspondent node to register a binding between this spoofed home
+   address and the attacker's own care-of address.  The attacker then
+   tricks the correspondent node into sending a stream of packets to the
+   care-of address and subsequently deregisters the binding or lets it
+   expire.  The consequence is that the correspondent node redirects the
+   packet stream "back" to the home address, causing the victim network
+   to be flooded with unrequested packets.  To preclude such misuse, an
+   initial home address test is required for the mobile node and the
+   correspondent node to establish a semi-permanent security
+   association.  The home address test is, if possible, executed in
+   proactive manner so as to save a potentially costly message exchange
+   via the home agent during the critical handoff period.  The home
+   address test does not need to be repeated upon subsequent movements.
+
+3.5.  Concurrent Care-of Address Tests
+
+   Enhanced Route Optimization allows a correspondent node to send
+   payload packets to a mobile node's new care-of address before the
+   mobile node has been found to be reachable at the care-of address.
+   When the mobile node changes IP connectivity, it first updates its
+   binding at the correspondent node to the new care-of address without
+   providing a proof of reachability.  The correspondent node registers
+   the new care-of address on a tentative basis and sets it to
+   UNVERIFIED state.  Payload packets can then be exchanged
+   bidirectionally via the new care-of address, while the mobile node's
+   reachability at the new care-of address is verified concurrently.
+   The correspondent node moves the care-of address to VERIFIED state
+   once reachability verification completes.
+
+3.6.  Credit-Based Authorization
+
+   Concurrent care-of address tests without additional protection would
+   enable an attacker to trick a correspondent node into temporarily
+   redirecting payload packets, which would otherwise be addressed to
+   the attacker itself, to the IP address of a victim.  Such
+   "redirection-based flooding" [5] may be appealing to the attacker
+   because the correspondent node (not the attacker) generates the
+   flooding packets and sends them to the victim.  This enables the
+   attacker to amplify the strength of the attack to a significant
+   degree compared to a direct flooding attack where the attacker itself
+   would generate the flooding packets.
+
+   Enhanced Route Optimization protects against redirection-based
+   flooding attacks through the use of Credit-Based Authorization.
+   Credit-Based Authorization manages the effort that a correspondent
+   node expends in sending payload packets to a care-of address in
+   UNVERIFIED state so as to ensure that a redirection-based flooding
+
+
+
+Arkko, et al.               Standards Track                     [Page 9]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   attack cannot be more effective than direct flooding.  The ability to
+   send unrequested packets is an inherent property of packet-oriented
+   networks, and direct flooding is a threat that results from this.
+   Since direct flooding exists with and without mobility support, and
+   redirection-based flooding attacks cannot be any more efficient than
+   this, Credit-Based Authorization increases the security level
+   provided by Enhanced Route Optimization with respect to flooding to
+   that of the non-mobile Internet.  Enhanced Route Optimization
+   therefore satisfies the objective to provide a security level
+   comparable to that of the non-mobile Internet.
+
+   The measuring and limiting of effort are technically realized through
+   the concept of "credit", which a correspondent node maintains to put
+   its own effort in relation to the effort that a mobile node expends
+   during regular communications with the correspondent node.  The
+   correspondent node increases the credit for payload packets it
+   receives from a care-of address of the mobile node in VERIFIED state,
+   and it reduces the credit in proportion to its own effort for sending
+   payload packets to a care-of address of the mobile node in UNVERIFIED
+   state.
+
+3.7.  Parallel Home and Correspondent Registrations
+
+   Enhanced Route Optimization enables mobile nodes to pursue a
+   correspondent registration in parallel with the respective home
+   registration.  This reduces handoff delays compared to base Mobile
+   IPv6, which requires mobile nodes to wait for a Binding
+   Acknowledgment message indicating a successful home registration
+   before they initiate a correspondent registration.
+
+4.  Protocol Operation
+
+   Enhanced Route Optimization allows a mobile node to securely
+   authenticate to a correspondent node based on the CGA property of its
+   home address, and to request a concurrent care-of address test for
+   increased handoff efficiency.  Depending on whether the mobile node
+   wishes to take advantage of either or both of these enhancements, the
+   messages exchanged during a correspondent registration are different.
+   This is described in the following.
+
+4.1.  Sending Binding Update Messages
+
+   A mobile node may initiate a correspondent registration for any of
+   the following reasons:
+
+   o  To establish a new binding at a correspondent node while away from
+      its home link so that subsequent packets will be route-optimized
+      and no longer be routed through the mobile node's home agent.
+
+
+
+Arkko, et al.               Standards Track                    [Page 10]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   o  To update an existing binding at the correspondent node while
+      moving from one point of IP attachment to another.
+
+   o  To follow up an early Binding Update message with a complete
+      Binding Update message after receiving a Binding Acknowledgment
+      message with a Care-of Test option.
+
+   o  To refresh an existing binding at the correspondent node without
+      changing the current point of IP attachment.
+
+   o  To request the correspondent node to renew an existing permanent
+      home keygen token shared between the mobile node and the
+      correspondent node (see Section 4.5).
+
+   o  To request the correspondent node to deregister an existing
+      binding.
+
+
+     Mobile node               Home agent           Correspondent node
+         |                         |                         |
+         |                         |                         |
+         ~ Handoff                 |                         |
+         |                         |                         |
+         |-Binding Update--------->|                         |
+         |-early Binding Update + Care-of Test Init option-->|
+         |                         |                         |
+         |                         |                         |
+         |<------------Binding Ack-|                         |
+         |<----------early Binding Ack + Care-of Test option-|
+         |                         |                         |
+         |                         |                         |
+         |-Binding Update----------------------------------->|
+         |                         |                         |
+         |                         |                         |
+         |<--------------------------------------Binding Ack-|
+         |                         |                         |
+
+    Figure 1: Correspondent registration with authentication by a proof
+     of the mobile node's knowledge of a permanent home keygen token;
+                      concurrent care-of address test
+
+   In any of these cases, the mobile node sends a Binding Update message
+   to the correspondent node.  The Binding Update message is
+   authenticated by one of the following three authentication methods:
+
+   o  If the mobile node's home address is a CGA, but the mobile node
+      does not have a permanent home keygen token in its Binding Update
+      List entry for the correspondent node, the mobile node SHOULD
+
+
+
+Arkko, et al.               Standards Track                    [Page 11]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+      authenticate the Binding Update message based on the CGA property
+      of its home address.  This requires the mobile node to send its
+      CGA parameters and signature to the correspondent node and to pass
+      a check of reachability at the home address.
+
+   o  If the mobile node's home address is a CGA, and the mobile node
+      has a permanent home keygen token in its Binding Update List entry
+      for the correspondent node, the mobile node MUST authenticate the
+      Binding Update message by a proof of its knowledge of the
+      permanent home keygen token.
+
+   o  If the mobile node's home address is not a CGA, the mobile node
+      MUST authenticate the Binding Update message through a proof of
+      reachability at its home address.
+
+   The lifetime requested by the mobile node in the Lifetime field of
+   the Binding Update message MUST NOT exceed MAX_CGA_BINDING_LIFETIME
+   (see Section 7) if the Binding Update message is to be authenticated
+   based on the CGA property of the mobile node's home address or by a
+   proof of the mobile node's knowledge of a permanent home keygen
+   token.  If the selected authentication method is a proof of the
+   mobile node's reachability at the home address, the lifetime MUST NOT
+   exceed MAX_RR_BINDING_LIFETIME [1].  It is RECOMMENDED in all cases
+   that the mobile node requests the maximum permitted lifetime in order
+   to avoid unnecessary binding refreshes and thus reduce signaling
+   overhead.  The Lifetime field of a Binding Update message that
+   requests the deletion of an existing binding at the correspondent
+   node MUST be set to zero.
+
+   If the selected authentication method is by way of the CGA property
+   of the mobile node's home address, the mobile node includes its CGA
+   parameters and signature in the Binding Update message by adding one
+   or more CGA Parameters options (see Section 5.1) directly followed by
+   a Signature option (see Section 5.2).  This is described in
+   Section 4.5.  Once a permanent home keygen token has been obtained
+   from the correspondent node, the mobile node MUST authenticate all
+   subsequent Binding Update messages by a proof of its knowledge of
+   this permanent home keygen token until either the binding lifetime
+   expires, the permanent home keygen token is renewed, or the mobile
+   node explicitly deregisters the binding at the correspondent node.
+   This ensures that an attacker on the path from the correspondent node
+   to the mobile node's home address cannot downgrade the mobile node's
+   chosen authentication method to a proof of reachability at the home
+   address.  The mobile node MAY choose to ignore the CGA property of
+   its home address and authenticate Binding Update messages through a
+   proof of reachability at the home address.  However, this behavior
+   increases the vulnerability to on-path attackers and is therefore NOT
+   RECOMMENDED.
+
+
+
+Arkko, et al.               Standards Track                    [Page 12]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+     Mobile node              Home agent          Correspondent node
+         |                         |                         |
+         |                         |                         |
+         |-Home Test Init--------->|------------------------>|
+         |                         |                         |
+         |<------------------------|<--------------Home Test-|
+         |                         |                         |
+         |                         |                         |
+         ~ Handoff                 |                         |
+         |                         |                         |
+         |-Binding Update--------->|                         |
+         |-early Binding Update + Care-of Test Init option-->|
+         |                         |                         |
+         |                         |                         |
+         |<------------Binding Ack-|                         |
+         |<----------early Binding Ack + Care-of Test option-|
+         |                         |                         |
+         |                         |                         |
+         |-Binding Update----------------------------------->|
+         |                         |                         |
+         |                         |                         |
+         |<--------------------------------------Binding Ack-|
+         |                         |                         |
+
+     Figure 2: Correspondent registration with authentication based on
+     reachability verification at the home address; concurrent care-of
+                               address test
+
+   The mobile node also includes its CGA parameters in the Binding
+   Update message when it intends to renew an existing permanent home
+   keygen token shared with the correspondent node.  This is
+   accomplished, as before, by adding to the message one or more CGA
+   Parameters options and a Signature option.
+
+   The authenticator for the Binding Update message is calculated based
+   on a permanent or temporary home keygen token.  Which type of home
+   keygen token the mobile node uses in calculating the authenticator
+   depends on the authentication method:
+
+   o  If the Binding Update message is to be authenticated based on the
+      CGA property of the mobile node's home address, the mobile node
+      MUST use a temporary home keygen token from the correspondent
+      node.  The mobile node may already have a valid temporary home
+      keygen token in its Binding Update List entry for the
+      correspondent node, or it may retrieve one through the exchange of
+      a Home Test Init message and a Home Test message.
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 13]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   o  If the Binding Update message is to be authenticated by a proof of
+      the mobile node's knowledge of a permanent home keygen token, the
+      mobile node MUST use the permanent home keygen token that is has
+      in its Binding Update List entry for the correspondent node.
+
+   o  If the Binding Update message is to be authenticated through a
+      proof of reachability at the home address, the mobile node MUST
+      use a temporary home keygen token from the correspondent node.  As
+      before, the mobile node may already have a valid temporary home
+      keygen token in its Binding Update List entry for the
+      correspondent node, or it may retrieve one through the exchange of
+      a Home Test Init message and a Home Test message.
+
+   Unless the purpose of the Binding Update message is to delete an
+   existing binding at the correspondent node, the authenticator is also
+   calculated based on a care-of keygen token.  The mobile node selects
+   this as follows:
+
+   o  If the mobile node has a valid care-of keygen token for the to-be-
+      registered care-of address in its Binding Update List entry for
+      the correspondent node, the mobile node MUST use this in
+      calculating the authenticator for the Binding Update message.  The
+      Binding Update message is in this case "complete".
+
+   o  If the mobile node does not have a valid care-of keygen token in
+      its Binding Update List entry for the correspondent node, the
+      mobile node SHOULD define the care-of keygen token to be zero and
+      use this in calculating the authenticator for the Binding Update
+      message.  The Binding Update message is in this case "early".
+
+   o  If the mobile node does not have a valid care-of keygen token in
+      its Binding Update List entry for the correspondent node, the
+      mobile node MAY choose to retrieve a care-of keygen token through
+      the exchange of a Care-of Test Init message and a Care-of Test
+      message, as defined in [1], without sending an early Binding
+      Update message.  In this case, the mobile node waits for receipt
+      of the Care-of Test message and uses the care-of
+      keygen token contained therein in calculating the authenticator
+      for a complete Binding Update message.  This approach increases
+      the handoff latency, however, and is therefore NOT RECOMMENDED.
+
+   For reduced handoff delays, the mobile node SHOULD simultaneously
+   initiate home and correspondent registrations for a particular
+   care-of address.  The mobile node SHOULD also pursue home and
+   correspondent deregistrations in parallel if it wishes to discontinue
+   Mobile IPv6 service while away from its home link.  However, when the
+   mobile node commits home and correspondent deregistrations after
+   returning back to the home link after a period of roaming, the mobile
+
+
+
+Arkko, et al.               Standards Track                    [Page 14]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   node MUST initiate the home deregistration first, and it MUST wait
+   for a Binding Acknowledgment message indicating a successful home
+   deregistration before it initiates the correspondent deregistration.
+   This behavior ensures that the home agent does not proxy the mobile
+   node's home address while the mobile node is on the home link, hence
+   preventing interference between the mobile node and the home agent
+   during Duplicate Address Detection.  Since a home deregistration
+   consumes only a link-local round-trip time when the mobile node
+   pursues it from the home link, the cost of not parallelizing it with
+   a correspondent deregistration, in terms of increased handoff delay,
+   is typically negligible.
+
+   Moreover, when the Binding Update message for the correspondent
+   registration is to be authenticated based on the CGA property of the
+   mobile node's home address or through a proof of reachability at the
+   home address, the mobile node SHOULD initiate the exchange of Home
+   Test Init and Home Test messages prior to handoff in order to
+   proactively elicit a fresh home keygen token from the correspondent
+   node.  This reduces handoff delays further.  A Home Test Init message
+   may be sent periodically whenever the home keygen token previously
+   acquired from the correspondent node is about to expire.  Tokens are
+   valid for 3.5 minutes [1], so the interval between successive Home
+   Test Init messages should be a little less.  Alternatively, the
+   mobile node may be able to send the Home Test Init message right in
+   time if its link layer provides a trigger announcing imminent
+   handoff.  Proactive home address tests are technically feasible
+   because a home address does not change across handoffs.
+
+   If the mobile node initiates the home address test from the home
+   link, it MUST address the Home Test Init message directly to the
+   correspondent node.  The Home Test message will then be received
+   directly from the correspondent node.  If the home address test is
+   initiated from a visited link, the mobile node MUST tunnel the Home
+   Test Init message to the home agent.  The Home Test message will then
+   be tunneled back to the mobile node by the home agent.  A home
+   address test SHOULD NOT overlap with a home registration or home
+   deregistration since this could result in the loss of the Home Test
+   Init or Home Test message.
+
+   If the Binding Update message is early, the mobile node MUST add a
+   Care-of Test Init option (see Section 5.4) to the message, requesting
+   the correspondent node to return a new care-of keygen token.  The
+   Care-of Test Init option MUST follow the CGA Parameters and Signature
+   options, if those exist in the Binding Update message.  Once a
+   responding Binding Acknowledgment message with a Care-of Test option
+   (see Section 5.5) is received, the mobile node MUST use the care-of
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 15]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   keygen token contained therein in calculating the authenticator for a
+   complete Binding Update message and send this message to the
+   correspondent node.
+
+   If the Binding Update message is authenticated based on the CGA
+   property of the mobile node's home address, the mobile node MAY add a
+   CGA Parameters Request option (see Section 5.6) to the Binding Update
+   message so as to request the correspondent node to prove ownership of
+   its IP address within the Binding Acknowledgment message.  This
+   ownership proof enables the mobile node to verify that the permanent
+   home keygen token returned in the Binding Acknowledgment message was
+   generated by the right correspondent node.
+
+   The mobile node includes the nonce indices associated with the
+   selected home and care-of keygen tokens in the Binding Update message
+   using a Nonce Indices option [1].  The home nonce index is thereby
+   determined as follows:
+
+   o  If the Binding Update message is to be authenticated based on the
+      CGA property of the mobile node's home address, the mobile node
+      uses a temporary home keygen token to calculate the authenticator
+      for the Binding Update message, and the associated home nonce
+      index MUST be taken from the Home Test message with which the home
+      keygen token was obtained.
+
+   o  If the Binding Update message is to be authenticated by a proof of
+      the mobile node's knowledge of a permanent home keygen token, the
+      home nonce index MUST be set to zero.
+
+   o  If the Binding Update message is to be authenticated through a
+      proof of the mobile node's reachability at the home address, the
+      mobile node uses a temporary home keygen token to calculate the
+      authenticator for the Binding Update message, and the associated
+      home nonce index MUST be taken from the Home Test message with
+      which the home keygen token was obtained.
+
+   The care-of nonce index is determined according to the following
+   rules:
+
+   o  If the Binding Update message is complete, the care-of nonce index
+      is taken from the Care-of Test option or Care-of Test message with
+      which the care-of keygen token (used to calculate the
+      authenticator for the Binding Update message) was obtained.
+
+   o  If the Binding Update message is early, the care-of nonce index
+      MUST be set to zero.
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 16]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   o  If the purpose of the Binding Update message is to delete a
+      binding at the correspondent node, the care-of nonce index MUST be
+      set to zero.
+
+   The Nonce Indices option follows the CGA Parameters, Signature,
+   Care-of Test Init, and CGA Parameters Request options if those are
+   included in the Binding Update message as well.
+
+   The mobile node finally calculates an authenticator for the Binding
+   Update message based on the selected home and care-of keygen tokens,
+   following the rules described in Section 5.2 and Section 6.2.7 of
+   [1].  For a Binding Update message that requests the deletion of an
+   existing binding at the correspondent node, the authenticator is
+   calculated based on only a home keygen token, and it does not
+   incorporate a care-of keygen token.  The authenticator is placed into
+   the Authenticator field of a Binding Authorization Data option [1],
+   which the mobile node adds to the Binding Update message as the last
+   option.
+
+     Mobile node               Home agent           Correspondent node
+         |                         |                         |
+         |                         |                         |
+         ~ Handoff                 |                         |
+         |                         |                         |
+         |-Binding Update--------->|                         |
+         |-Care-of Test Init-------------------------------->|
+         |                         |                         |
+         |                         |                         |
+         |<------------Binding Ack-|                         |
+         |<-------------------------------------Care-of Test-|
+         |                         |                         |
+         |                         |                         |
+         |-Binding Update----------------------------------->|
+         |                         |                         |
+         |                         |                         |
+         |<--------------------------------------Binding Ack-|
+         |                         |                         |
+
+    Figure 3: Correspondent registration with authentication by a proof
+     of the mobile node's knowledge of a permanent home keygen token;
+                       explicit care-of address test
+
+   The time-sequence diagrams in Figure 1 through Figure 3 illustrate
+   the operation of Enhanced Route Optimization based on a few selected
+   message exchanges.  Figure 1 shows the messages exchanged for a
+   correspondent registration where an early Binding Update message is
+   authenticated by a proof of the mobile node's knowledge of a
+   permanent home keygen token.  A Care-of Test Init option in the early
+
+
+
+Arkko, et al.               Standards Track                    [Page 17]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Binding Update message requests the correspondent node to add to the
+   Binding Acknowledgment message a fresh care-of keygen token in a
+   Care-of Test option.  The mobile node finally concludes the
+   correspondent registration with a complete Binding Update message.
+   Figure 2 shows the procedure of a correspondent registration where
+   the Binding Update message is authenticated with a proof of
+   reachability at the home address.  The home address test is
+   proactively performed prior to handoff, permitting the mobile node to
+   issue a Binding Update message directly after the handoff.  The
+   Binding Update message is again early, and a care-of keygen token is
+   delivered to the mobile node along with the Binding Acknowledgment
+   message.  Figure 3 depicts a correspondent registration where the
+   mobile node initially obtains a fresh care-of keygen token through
+   the dedicated exchange of Care-of Test Init and Care-of Test
+   messages.  It subsequently issues a complete Binding Update message
+   that is authenticated with the CGA property of the home address.
+
+4.2.  Receiving Binding Update Messages
+
+   When the correspondent node receives a Binding Update message, it
+   must first verify whether the sending mobile node is the legitimate
+   owner of the home address specified in the message.  The
+   correspondent node selects the authentication method based on the
+   home nonce index given in the Nonce Indices option of the Binding
+   Update message, and on the existence of CGA Parameters and Signature
+   options in the Binding Update message:
+
+   o  If the home nonce index is set to a non-null value and the Binding
+      Update message includes one or more CGA Parameters options
+      followed by a Signature option, the correspondent node MUST
+      authenticate the Binding Update message based on the CGA property
+      of the mobile node's home address.
+
+   o  If the home nonce index is zero and the Binding Update message
+      does not include one or more CGA Parameters options followed by a
+      Signature option, the correspondent node MUST authenticate the
+      Binding Update message by a proof of the mobile node's knowledge
+      of a permanent home keygen token.
+
+   o  If the home nonce index is set to a non-null value and the Binding
+      Update message does not include one or more CGA Parameters options
+      followed by a Signature option, the correspondent node MUST
+      authenticate the Binding Update message through a proof of the
+      mobile node's reachability at the home address.
+
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 18]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   In addition to the validation procedure for Binding Update messages
+   specified in [1], the correspondent node must take the following
+   additional steps to reject Binding Update messages that are
+   inappropriately authenticated:
+
+   o  If the Binding Update message includes one or more CGA Parameters
+      options followed by a Signature option and the home nonce index is
+      zero, the correspondent node MUST send a Binding Acknowledgment
+      message with status code 150 ("Non-null home nonce index
+      expected").  This ensures that a Binding Update message that is
+      authenticated based on the CGA property of the mobile node's home
+      address must also provide a proof of the mobile node's
+      reachability at the home address.
+
+   o  If the Binding Update message is to be authenticated by a proof of
+      the mobile node's knowledge of a permanent home keygen token, the
+      correspondent node MUST verify that it has a Binding Cache entry
+      for the mobile node that includes a permanent home keygen token.
+      In case the correspondent node does not have a Binding Cache entry
+      for the mobile node, or if the existing Binding Cache entry for
+      the mobile node does not include a permanent home keygen token,
+      the correspondent node MUST reject the Binding Update message by
+      sending a Binding Acknowledgment message with status code 147
+      ("Permanent home keygen token unavailable").
+
+   o  If the Binding Update message is to be authenticated through a
+      proof of the mobile node's reachability at the home address, the
+      correspondent node MUST verify that it does not have a permanent
+      home keygen token in its Binding Cache entry for the mobile node.
+      If the correspondent node has a permanent home keygen token in its
+      Binding Cache entry for the mobile node, it MUST reject the
+      Binding Update message by sending a Binding Acknowledgment message
+      with status code 149 ("Permanent home keygen token exists").  This
+      ensures that an attacker cannot downgrade the authentication
+      method to hijack the binding of a legitimate mobile node.
+
+   The authenticator for the Binding Update message is calculated based
+   on a permanent or temporary home keygen token.  Which type of home
+   keygen token the correspondent node uses in validating the
+   authenticator, and how it retrieves or recomputes the home keygen
+   token, depends on the authentication method:
+
+   o  If the Binding Update message is to be authenticated based on the
+      CGA property of the mobile node's home address, the correspondent
+      node MUST recompute the temporary home keygen token defined by the
+      (non-null) home nonce index in the Nonce Indices option of the
+      Binding Update message, and it MUST use this recomputed token in
+      validating the authenticator of the message.
+
+
+
+Arkko, et al.               Standards Track                    [Page 19]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   o  If the Binding Update message is to be authenticated by a proof of
+      the mobile node's knowledge of a permanent home keygen token, the
+      correspondent node MUST use the permanent home keygen token that
+      it has in its Binding Cache entry for the mobile node in
+      validating the authenticator of the Binding Update message.
+
+   o  If the Binding Update message is to be authenticated through
+      verification of the mobile node's reachability at the home
+      address, the correspondent node MUST recompute the temporary home
+      keygen token defined by the (non-null) home nonce index in the
+      Nonce Indices option of the Binding Update message, and it MUST
+      use this recomputed token in validating the authenticator of the
+      message.
+
+   Unless the purpose of the Binding Update message is to delete an
+   existing binding at the correspondent node, the authenticator is also
+   calculated based on a care-of keygen token.  Which care-of keygen
+   token the correspondent node uses in validating the authenticator
+   depends on whether the Binding Update message is complete or early:
+
+   o  If the care-of nonce index in the Nonce Indices option of the
+      Binding Update message is set to a non-null value, the Binding
+      Update message is complete.  In this case, the correspondent node
+      MUST recompute the care-of keygen token that is identified by the
+      care-of nonce index, and it MUST use this recomputed token in
+      validating the authenticator of the message.
+
+   o  If the care-of nonce index in the Nonce Indices option of the
+      Binding Update message is zero, the Binding Update message is
+      early.  The care-of keygen token to be used by the correspondent
+      node in validating the authenticator of the Binding Update message
+      is zero in this case.
+
+   The correspondent node finally validates the authenticator in the
+   Binding Update message based on the selected home and care-of keygen
+   tokens, following the algorithm described in Section 9.5.1 of [1].
+
+   If the validation fails, the correspondent node MUST discard the
+   Binding Update message.  The correspondent node may have to send a
+   Binding Acknowledgment message with a status code indicating the
+   failure, as described in [1].
+
+   Provided that the validation of the authenticator in the Binding
+   Update message succeeds, the correspondent node registers the mobile
+   node's new care-of address, either updating an existing Binding Cache
+   entry, if one exists, or creating a new Binding Cache entry.  The
+   lifetime granted for the binding depends on the lifetime requested by
+   the mobile node in the Lifetime field of the Binding Update message
+
+
+
+Arkko, et al.               Standards Track                    [Page 20]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   and the method by which the Binding Update message is authenticated.
+   If the Binding Update message is authenticated based on the CGA
+   property of the mobile node's home address or by a proof of the
+   mobile node's knowledge of a permanent home keygen token, the
+   lifetime for the binding SHOULD be set to the maximum of
+   MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime
+   field of the Binding Update message.  If the Binding Update message
+   is authenticated through a proof of the mobile node's reachability at
+   the home address, then the lifetime for the binding SHOULD be set to
+   the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in
+   the Lifetime field of the Binding Update message.  The correspondent
+   node may in either case grant a further reduced lifetime, but it MUST
+   NOT accept a higher lifetime.
+
+   The state of the new care-of address depends on whether the Binding
+   Update message is complete or early:
+
+   o  If the Binding Update message is complete, the new care-of address
+      is set to VERIFIED state.  The correspondent node may then
+      immediately send packets to the new care-of address without
+      restrictions.
+
+   o  If the Binding Update message is early, the new care-of address is
+      set to UNVERIFIED state.  The correspondent node MUST then follow
+      the rules defined in Section 4.10 for sending packets to this
+      care-of address until the care-of address is set in VERIFIED
+      state.
+
+   If the Binding Update message contains one or multiple CGA Parameters
+   options, the mobile node is requesting the correspondent node to
+   accept the included CGA parameters either for establishing a new, or
+   for renewing an existing permanent home keygen token shared between
+   the mobile node and the correspondent node.  The correspondent node
+   MUST in this case check if the CGA Parameters options are directly
+   followed by a Signature option and, if so, validate the CGA
+   parameters and signature as described in Section 4.6.
+
+   If the CGA Parameters option is not directly followed by a Signature
+   option, or the validation of the included CGA parameters and
+   signature fails, the correspondent node MUST discard the Binding
+   Update message and send a Binding Acknowledgment message with status
+   code 148 ("CGA and signature verification failed") to the mobile
+   node.
+
+   Provided that the signature included in the Signature option is
+   correct, the correspondent node generates a permanent home keygen
+   token to be shared with the mobile node and stores it in its Binding
+   Cache entry for the mobile node.  The permanent home keygen token is
+
+
+
+Arkko, et al.               Standards Track                    [Page 21]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   sent to the mobile node within a Binding Acknowledgment message as
+   described in Section 4.3.
+
+4.3.  Sending Binding Acknowledgment Messages
+
+   Upon receipt of a valid Binding Update message, the correspondent
+   node returns to the mobile node a Binding Acknowledgment message in
+   any of the following cases:
+
+   o  The Acknowledge flag in the Binding Update message is set.
+
+   o  The Binding Update message contains one or multiple CGA Parameters
+      options directly followed by a Signature option, and the signature
+      included in the latter was determined to be correct.
+
+   o  The Binding Update message is early and includes a Care-of Test
+      Init option.
+
+   If the Binding Update message further contains a CGA Parameters
+   Request option and the correspondent node's IP address is a CGA, the
+   correspondent node MUST include its CGA parameters and signature in
+   the Binding Acknowledgment message by adding one or more CGA
+   Parameters options directly followed by a Signature option.  The
+   correspondent node's CGA parameters and signature enable the mobile
+   node to verify that the permanent home keygen token received in the
+   Binding Acknowledgment message was generated by the right
+   correspondent node.  If the Binding Update message contains a CGA
+   Parameters Request option, but the correspondent node's IP address is
+   not a CGA, the correspondent node ignores the CGA Parameters Request
+   option and processes the Binding Update message further as described
+   below.
+
+   If the Binding Update message contains one or multiple CGA Parameters
+   options directly followed by a Signature option, and the signature
+   included in the latter was determined to be correct, the
+   correspondent node MUST add a Permanent Home Keygen Token option (see
+   Section 5.3) with a new permanent home keygen token to the Binding
+   Acknowledgment message.  The correspondent node also stores this
+   permanent home keygen token in its Binding Cache entry for the mobile
+   node.
+
+   If the Binding Update message includes a Care-of Test Init option,
+   the correspondent node MUST append to the Binding Acknowledgment
+   message a Care-of Test option with a pseudo-random value in the
+   Care-of Keygen Token field.  The Care-of Test option MUST appear
+   after the Permanent Home Keygen Token option in case both options are
+   present in the Binding Acknowledgment message.
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 22]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   A Binding Authorization Data option must be added to the Binding
+   Acknowledgment message as a last option, as described in Section 5.2
+   and Section 6.2.7 of [1].
+
+4.4.  Receiving Binding Acknowledgment Messages
+
+   A mobile node first verifies a received Binding Acknowledgment
+   message according to the rules specified in [1].  Provided that the
+   Binding Acknowledgment message is not rejected based on these rules,
+   the mobile node takes the following additional steps.
+
+   If the mobile node included a CGA Parameters Request option in the
+   Binding Update message and the Binding Acknowledgment message
+   contains a Permanent Home Keygen Token option, the mobile node first
+   processes any CGA Parameters and Signature options in the Binding
+   Acknowledgment message in the following manner.  If the Binding
+   Acknowledgment message contains one or more CGA Parameters options
+   that are directly followed by a Signature option, the mobile node
+   MUST check the ownership of the correspondent node's IP address by
+   verifying the included CGA parameters and signature as described in
+   Section 4.6.  If the validation of the CGA parameters and signature
+   fails, the mobile node MUST silently discard the Binding
+   Acknowledgment message.  The mobile node MUST also silently discard
+   the Binding Acknowledgment message if the message includes one or
+   more CGA Parameters options that are not directly followed by a
+   Signature option, or if the Binding Acknowledgment message lacks any
+   CGA Parameters options in the presence of a Signature option.
+
+   If the mobile node did not include a CGA Parameters Request option in
+   the Binding Update message or the Binding Acknowledgment message does
+   not contain a Permanent Home Keygen Token option, the mobile node
+   ignores any CGA Parameters and Signature options that the Binding
+   Acknowledgment message may contain.  Careful use of the CGA
+   Parameters Request option in Binding Update messages enables the
+   mobile node to control the processing resources it spends on the
+   verification of a correspondent node's CGA as well as to disable such
+   verification in the case of persistent verification failures, which
+   may be due to misconfigured or outdated CGA software [12] on the
+   correspondent node side or at the mobile node itself.  Specifically,
+   if the mobile node repeatedly fails to receive a Binding
+   Acknowledgment message including valid CGA Parameters and Signature
+   options in response to sending a Binding Update message with a CGA
+   Parameters Request option, the mobile node SHOULD refrain from
+   including a CGA Parameters Request option in future Binding Update
+   messages for the same correspondent node.
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 23]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   If the mobile node included a CGA Parameters Request option in the
+   Binding Update message, but the Binding Acknowledgment message does
+   not contain any CGA Parameters or Signature options, the mobile node
+   cannot be sure if the correspondent node's IP address is simply not a
+   CGA, or if the Binding Acknowledgment message originates from an
+   attacker on the path from the mobile node to the correspondent node.
+   To avoid accepting a permanent home keygen token from an on-path
+   attacker, the mobile node MUST give precedence to Binding
+   Acknowledgment messages that include valid CGA Parameters and
+   Signature options over Binding Acknowledgment messages without such
+   options.  One possible algorithm for the mobile node to follow in
+   this regard is to always accept the Binding Acknowledgment message
+   received first, and if this message does not contain valid CGA
+   Parameters or Signature options and another Binding Acknowledgment
+   message including such options is received later on, to revert any
+   state changes involved in accepting the first Binding Acknowledgment
+   in favor of this subsequent Binding Acknowledgment message.  Giving
+   precedence to Binding Acknowledgment messages with valid CGA
+   Parameters and Signature options over Binding Acknowledgment messages
+   without such options enables the mobile node to communicate with
+   correspondent nodes that do not use a CGA, and at the same time
+   protects against most on-path attackers.  The strategy does not
+   protect against an attacker that can intercept Binding Acknowledgment
+   messages from the correspondent node, but such an attacker could
+   preclude mobility management between the mobile node and the
+   correspondent node anyway.  When the mobile node has permanently
+   accepted a Binding Acknowledgment message without valid CGA
+   Parameters and Signature options, the mobile node SHOULD refrain from
+   including a CGA Parameters Request option in future Binding Update
+   messages for the same correspondent node.
+
+   If the Binding Acknowledgment message contains a Permanent Home
+   Keygen Token option, the mobile node extracts the permanent home
+   keygen token included in this option and stores it in its Binding
+   Update List entry for the correspondent node.  Future Binding Update
+   messages will then be authenticated by a proof of the mobile node's
+   knowledge of this permanent home keygen token.
+
+   If the Binding Acknowledgment message contains a Care-of Test option,
+   the mobile node extracts the care-of keygen token included in this
+   option, stores the token in its Binding Update List entry for the
+   correspondent node, and sends the correspondent node a complete
+   Binding Update message as defined in Section 4.1.  Note that the
+   complete Binding Update message will be authenticated based on the
+   CGA property of the mobile node's home address if the Binding
+   Acknowledgment message also includes a Permanent Home Keygen Token
+   option.  This is independent of the authentication method that was
+   used for the corresponding early Binding Update message.
+
+
+
+Arkko, et al.               Standards Track                    [Page 24]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   A mobile node MUST ensure that, while it has a binding for a certain
+   home address at a correspondent node, it also has a valid binding at
+   its home agent for the same home address.  This may at times require
+   the mobile node to extend the binding lifetime at the home agent,
+   request a correspondent node to use a binding lifetime less than the
+   permitted maximum, or explicitly deregister an existing binding at a
+   correspondent node.
+
+   If the mobile node authenticates Binding Update messages for a
+   particular correspondent node by proving its knowledge of a permanent
+   home keygen token, but registrations at this correspondent node
+   persistently fail, the mobile node SHOULD renew the permanent home
+   keygen token by sending a Binding Update message that is
+   authenticated based on the CGA property of its home address.  This
+   Binding Update message includes the mobile node's CGA parameters and
+   signature, and it requests the correspondent node to generate a new
+   permanent home keygen token and send this to the mobile node within a
+   Binding Acknowledgment message.
+
+   If the mobile node persistently receives Binding Acknowledgment
+   messages with status code 148 ("CGA and signature verification
+   failed") from a correspondent node, the mobile node SHOULD
+   authenticate future Binding Update messages for the same
+   correspondent nodes through a proof of its reachability at the home
+   address.  This enables the mobile node to recover from misconfigured
+   or outdated CGA software [12] on the correspondent node side or at
+   the mobile node itself.
+
+4.5.  Sending CGA Parameters
+
+   A mobile node includes its CGA parameters and signature in a Binding
+   Update message for a correspondent node in any of the following
+   situations:
+
+   o  To acquire a permanent home keygen token if the mobile node's home
+      address is a CGA, and the mobile node does not yet have a
+      permanent home keygen token from the correspondent node.
+
+   o  To extend the lifetime of an existing binding if the mobile node
+      already has a permanent home keygen token from the correspondent
+      node, and the lifetime of the binding at the correspondent node is
+      about to expire.
+
+   o  To renew an existing permanent home keygen token to prevent replay
+      attacks in the imminent event of a sequence number rollover, or
+      for improved protection against cryptanalysis.
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 25]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   A correspondent node whose IP address is a CGA includes its CGA
+   parameters and signature in a Binding Acknowledgment message for the
+   mobile node when it receives a Binding Update message with a CGA
+   Parameters Request option.
+
+   CGA parameters are transmitted in the format of the CGA Parameters
+   data structure defined in [2].  The CGA Parameters data structure is
+   split over one or more CGA Parameters options as described in
+   Section 5.1.  The last CGA Parameters option MUST be directly
+   followed by a Signature option.
+
+   The value for the Signature field in the Signature option is
+   calculated according to the signature generation algorithm defined in
+   Section 6 of [2].  The value is calculated with the mobile or
+   correspondent node's private key over the following sequence of
+   octets:
+
+      mobility data =
+         care-of address | correspondent node IP address | MH data
+
+   where "|" denotes concatenation.  "Care-of address" is the mobile
+   node's care-of address, and "correspondent node IP address" is the IP
+   address of the correspondent node that is visible to protocol layers
+   above IP.  In case the correspondent node is mobile, "correspondent
+   node IP address" refers to the correspondent node's home address.
+   "MH data" is the content of the Binding Update or Binding
+   Acknowledgment message including the mobility header and all options
+   up to the last CGA Parameters option.  That is, "MH data" excludes
+   the IPv6 header and any IPv6 extension headers other than the
+   mobility header itself.  The "mobility data" constitutes what is
+   referred to as the "message" in Section 6 of [2].
+
+   The value for the Signature field is calculated as if the Checksum
+   field in the mobility header was zero.  The Checksum field in the
+   transmitted packet is still calculated in the usual manner, with the
+   calculated value in the Signature field being a part of the packet
+   protected by the checksum.
+
+4.6.  Receiving CGA Parameters
+
+   Mobile and correspondent nodes that receive a Binding Update or
+   Binding Acknowledgment message including one or more CGA Parameters
+   options directly followed by a Signature option first process the
+   message as described in [1].  This includes a verification of the
+   authenticator in the Authenticator field of the Binding Authorization
+   Data option.  If the Binding Update or Binding Acknowledgment message
+   is rejected due to an incorrect authenticator or for any other
+   reason, the message is not processed further.
+
+
+
+Arkko, et al.               Standards Track                    [Page 26]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Otherwise, if the validation of the Binding Update or Binding
+   Acknowledgment message succeeds, the mobile or correspondent node
+   reassembles the CGA Parameters data structure from the CGA Parameters
+   options included in the message as described in Section 5.1, and
+   executes the CGA verification algorithm defined in Section 5 of [2].
+   The CGA verification algorithm takes the to-be-verified CGA and the
+   reassembled CGA Parameters data structure as input.  The to-be-
+   verified CGA is the mobile node's home address when the CGA
+   verification algorithm is executed by the correspondent node.  When
+   the mobile node executes the CGA verification algorithm, the to-be-
+   verified CGA is the correspondent node's IP address that is visible
+   to protocol layers above IP.  This is the correspondent node's home
+   address in case the correspondent node is mobile.  The following
+   steps are skipped if the CGA verification fails.
+
+   If the CGA verification succeeds, the mobile or correspondent node
+   performs a more time-consuming check of the signature.  It extracts
+   the signature from the Signature field in the Signature option and
+   executes the signature verification algorithm defined in Section 6 of
+   [2].  The signature verification algorithm takes as input the to-be-
+   verified CGA as defined above, the reassembled CGA Parameters data
+   structure, the MH data as defined in Section 4.5, the CGA Message
+   Type tag of Enhanced Route Optimization as defined in Section 7, and
+   the signature itself.
+
+4.7.  Sending Permanent Home Keygen Tokens
+
+   A correspondent node assigns a mobile node a new permanent home
+   keygen token after it has received from the mobile node a Binding
+   Update message with included CGA Parameters and Signature options,
+   and these options have been successfully validated as described in
+   Section 4.6.  The permanent home keygen token is a 64-bit value
+   randomly generated by the correspondent node.  The correspondent node
+   stores the permanent home keygen token in the binding cache entry
+   that it maintains for the mobile node.
+
+   The correspondent node sends the permanent home keygen token to the
+   mobile node in encrypted form within a Permanent Home Keygen Token
+   option in a Binding Acknowledgment message.  It sends this message
+   even if the Acknowledge flag in the corresponding Binding Update
+   message was clear.  The correspondent node encrypts the permanent
+   home keygen token with the mobile node's public key using the
+   RSAES-PKCS1-v1_5 format [4], and places the ciphertext into the
+   Permanent Home Keygen Token field of the Permanent Home Keygen Token
+   option.
+
+   The Binding Authorization Data option MUST be the last option in the
+   Binding Acknowledgment message.  That is, the authenticator in the
+
+
+
+Arkko, et al.               Standards Track                    [Page 27]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Binding Authorization Data option covers the Permanent Home Keygen
+   Token option.
+
+4.8.  Receiving Permanent Home Keygen Tokens
+
+   A mobile node that receives a Binding Acknowledgment message first
+   processes the message as described in [1], independent of whether the
+   message includes a Permanent Home Keygen Token option.  This includes
+   a verification of the authenticator in the Authenticator field of the
+   Binding Authorization Data option.  If the Binding Acknowledgment
+   message is rejected due to an incorrect authenticator or for any
+   other reason, the mobile node does not process the message further.
+
+   Otherwise, if the mobile node accepts the Binding Acknowledgment
+   message and the message includes a Permanent Home Keygen Token
+   option, the mobile node extracts the ciphertext from the Permanent
+   Home Keygen Token field in this option and decrypts it with its
+   private key using the RSAES-PKCS1-v1_5 format [4].  The result of the
+   encryption is the permanent home keygen token to be used in further
+   registrations with the correspondent node.  The mobile node stores
+   the permanent home keygen token in the Binding Update List entry that
+   it maintains for the correspondent node.
+
+4.9.  Renewing Permanent Home Keygen Tokens
+
+   A mobile node that shares a permanent home keygen token with a
+   correspondent node MUST NOT use the same sequence number twice with
+   this permanent home keygen token in order to protect against replay
+   attacks.  The mobile node MUST renew the permanent home keygen token
+   by including its CGA parameters and signature in a Binding Update
+   message for the correspondent node when a sequence number rollover is
+   imminent.  In addition, the mobile node MAY renew its permanent home
+   keygen token at any time.  Periodic renewal of the permanent home
+   keygen token provides increased protection against cryptanalysis.
+   Finally, the mobile node may in most cases want to renew the
+   permanent home keygen token when the lifetime of its binding at the
+   correspondent node expires.
+
+4.10.  Handling Payload Packets
+
+   The immediate exchange of an early Binding Update message after a
+   handoff on the mobile node side enables mobile and correspondent
+   nodes to quickly reestablish route-optimized communications via the
+   mobile node's new care-of address.  The mobile node may send payload
+   packets to the correspondent node from the new care-of address as
+   soon as it has dispatched the early Binding Update message.  The
+   correspondent node redirects outgoing payload packets for the mobile
+   node to the new care-of address once it has received the early
+
+
+
+Arkko, et al.               Standards Track                    [Page 28]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Binding Update message and registered the new care-of address.  Here,
+   a "payload packet" is defined as a packet that originates at a
+   protocol layer above IP.
+
+           Inbound
+        payload packet
+              |
+              |
+              V
+      _________________                           _____________________
+     /                 \                         |                     |
+    /  Care-of address  \     Yes                |   Increase credit   |
+   |         in          |---------------------> |     counter by      |
+    \  VERIFIED state?  /                        | payload packet size |
+     \_________________/                         |_____________________|
+              |                                             |
+              |                                             |
+              | No                                          |
+              |                                             V
+              |                                   _____________________
+              |                                  |                     |
+              |                                  |   Deliver payload   |
+              +--------------------------------> |   packet to upper-  |
+                                                 |    layer protocol   |
+                                                 |_____________________|
+
+                Figure 4: Handling outbound payload packets
+
+   A new care-of address that was registered with an early Binding
+   Update message is maintained in UNVERIFIED state by the correspondent
+   node until the correspondent node receives a complete Binding Update
+   message from the mobile node.  The correspondent node then sets the
+   care-of address to VERIFIED state.  The state of the care-of address
+   determines the maximum amount of data that the correspondent node is
+   allowed to send to the care-of address, as is necessary to prevent
+   amplified, redirection-based flooding attacks.  For this purpose, the
+   correspondent node maintains a "credit counter" for each mobile node
+   with an entry in its Binding Cache.  Whenever a payload packet
+   arrives from a mobile node with a care-of address in VERIFIED state,
+   the correspondent node SHOULD increase the mobile node's credit
+   counter by the size of the received payload packet.  The
+   correspondent node MAY be restricted by policy to increase the credit
+   counter by a lower value or not to increase the credit at all.  The
+   credit counter does not change when an inbound payload packet is
+   received from a care-of address in UNVERIFIED state.  Figure 4 shows
+   a flow chart of this procedure.
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 29]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+           Outbound
+        payload packet
+              |
+              |
+              V
+      _________________                           _____________________
+     /                 \                         |                     |
+    /  Care-of address  \     Yes                |    Send payload     |
+   |         in          |---------------------> |      packet to      |
+    \  VERIFIED state?  /                        |   care-of address   |
+     \_________________/                         |_____________________|
+              |
+              |                                   _____________________
+              | No                               |                     |
+              |                                  |   Discard payload   |
+              |                      +---------> |        packet       |
+              |                      |           |     immediately     |
+              V                      |           |_____________________|
+      _________________              |            _____________________
+     /                 \             |           |                     |
+    /  Credit counter   \   Yes     / \          |    Send payload     |
+   |  less than payload  |-------> |   |-------> |      packet to      |
+    \   packet size?    /           \ /          |    home address     |
+     \_________________/             |           |_____________________|
+              |                      |            _____________________
+              |                      |           |                     |
+              | No                   |           |   Buffer payload    |
+              |                      +---------> |     packet for      |
+              |                                  | later transmission  |
+              |                                  |_____________________|
+              V
+    _____________________                         _____________________
+   |                     |                       |                     |
+   |    Reduce credit    |                       |    Send payload     |
+   |     counter by      |---------------------> |      packet to      |
+   | payload packet size |                       |   care-of address   |
+   |_____________________|                       |_____________________|
+
+                Figure 5: Handling outbound payload packets
+
+   When the correspondent node has a payload packet to send to the
+   mobile node, further treatment of the payload packet depends on the
+   state of the mobile node's care-of address and the current value of
+   the mobile node's credit counter, as illustrated in Figure 5: The
+   correspondent node MUST send the payload packet to the mobile node's
+   care-of address if the care-of address is in VERIFIED state.  If the
+   care-of address is in UNVERIFIED state and the value of the credit
+   counter is higher than or equal to the size of the payload packet,
+
+
+
+Arkko, et al.               Standards Track                    [Page 30]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   the correspondent node MUST reduce the mobile node's credit counter
+   by the size of the payload packet and send the payload packet to the
+   care-of address as well.  However, if the care-of address is in
+   UNVERIFIED state and the credit counter is less than the size of the
+   payload packet, the payload packet MUST NOT be sent to the mobile
+   node's care-of address.  The correspondent node SHOULD then discard
+   the payload packet, although it MAY alternatively buffer the payload
+   packet until the care-of address moves to VERIFIED state, or send the
+   payload packet to the mobile node's home address.  The credit counter
+   of the mobile node does not change when the correspondent node sends
+   a payload packet to the mobile node's care-of address while the
+   care-of address is in VERIFIED state.
+
+   The amount of data that the mobile node may send to the correspondent
+   node is never restricted due to the state of the mobile node's
+   care-of address.  The care-of address state also does not change the
+   addressing and routing of payload packets in either traffic
+   direction: All payload packets that originate from the mobile node
+   have the care-of address in the Source Address field of the IPv6
+   header and the home address in the Home Address option of the IPv6
+   Destination Options extension header.  Vice versa, all payload
+   packets from the correspondent node have the care-of address in the
+   Destination Address field of the IPv6 header and the home address in
+   the IPv6 Routing extension header.
+
+4.11.  Credit Aging
+
+   A correspondent node ensures that all credit counters that it
+   maintains gradually decrease over time.  Each credit counter is
+   multiplied with a factor, CreditAgingFactor, of less than one in
+   fixed time intervals of CreditAgingInterval length.  Such "credit
+   aging" limits the total credit that a mobile node can earn, provided
+   that the replenishing rate for the credit is constant or nearly
+   constant.  It thereby enforces an upper bound on the rate at which
+   the correspondent node can durably sent to the mobile node's care-of
+   address while the care-of address is in UNVERIFIED state.  In the
+   absence of credit aging, a malicious node with poor up-link capacity
+   could adopt the role of a mobile node, build up credit at a very slow
+   speed and over a long period, and spend this credit during a much
+   shorter period on redirecting a burst of payload packets to the IP
+   address of a victim.
+
+   Choosing appropriate values for CreditAgingFactor and
+   CreditAgingInterval is important to facilitate applications where the
+   correspondent node sends at a higher rate than the mobile node.  If
+   CreditAgingFactor or CreditAgingInterval is too small, the credit
+   counter might persistently prevent the transmission of payload
+   packets to a care-of address in UNVERIFIED state.  The values given
+
+
+
+Arkko, et al.               Standards Track                    [Page 31]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   in Section 7 are RECOMMENDED as they work well when the correspondent
+   node transfers a file to the mobile node via a TCP connection and the
+   end-to-end round-trip time does not exceed 500 milliseconds.
+
+4.12.  Simultaneous Movements
+
+   As specified in [1], Binding Update messages are sent to a mobile
+   correspondent node's home address.  This makes it possible for two
+   mobile nodes to continue communications even if both of them change
+   IP connectivity at the same time.
+
+5.  Option Formats and Status Codes
+
+   Enhanced Route Optimization uses a set of new mobility options and
+   status codes in addition to the mobility options and status codes
+   defined in [1].  These are described below.
+
+5.1.  CGA Parameters Option
+
+   The CGA Parameters option is used in Binding Update and Binding
+   Acknowledgment messages.  It contains part of the mobile or
+   correspondent node's CGA parameters. [1] limits mobility header
+   options to a maximum length of 255 bytes, excluding the Option Type
+   and Option Length fields.  Since the CGA parameters are likely to
+   exceed this limit, multiple CGA Parameters options may have to be
+   concatenated to carry all CGA parameters.
+
+   The format of the CGA Parameters option is as follows:
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                     |  Option Type  | Option Length |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     :                                                               :
+     :                          CGA Parameters                       :
+     :                                                               :
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option Type
+
+      8-bit identifier of the type of this mobility option.  Its value
+      is 12.
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 32]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Option Length
+
+      8-bit unsigned integer representing the length of the CGA
+      Parameters field in octets.
+
+   CGA Parameters
+
+      This field contains up to 255 bytes of the CGA Parameters data
+      structure defined in [2].  The concatenation of all CGA Parameters
+      options in the order they appear in the Binding Update message
+      MUST result in the original CGA Parameters data structure.  All
+      CGA Parameters options in the Binding Update message except the
+      last one MUST contain exactly 255 bytes in the CGA Parameters
+      field, and the Option Length field MUST be set to 255 accordingly.
+      All CGA Parameters options MUST appear directly one after another,
+      that is, a mobility option of a different type MUST NOT be placed
+      in between two CGA Parameters options.
+
+5.2.  Signature Option
+
+   The Signature option is used in Binding and Binding Acknowledgment
+   Update messages.  It contains a signature that the mobile or
+   correspondent node generates with its private key over one or more
+   preceding CGA Parameters options.
+
+   The format of the Signature option is as follows:
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                     |  Option Type  | Option Length |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     :                                                               :
+     :                            Signature                          :
+     :                                                               :
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option Type
+
+      8-bit identifier of the type of this mobility option.  Its value
+      is 13.
+
+   Option Length
+
+      8-bit unsigned integer representing the length of the Signature
+      field in octets.
+
+
+
+Arkko, et al.               Standards Track                    [Page 33]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Signature
+
+      This field contains the mobile or correspondent node's signature,
+      generated with the mobile or correspondent node's private key as
+      specified in Section 4.5.
+
+5.3.  Permanent Home Keygen Token Option
+
+   The Permanent Home Keygen Token option is used in Binding
+   Acknowledgment messages.  It contains a permanent home keygen token,
+   which the correspondent node sends to the mobile node after it has
+   received a Binding Update message containing one or more CGA
+   Parameters options directly followed by a Signature option from the
+   mobile node.
+
+   The format of the Permanent Home Keygen Token option is as follows:
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                     |  Option Type  | Option Length |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     :                                                               :
+     :                  Permanent Home Keygen Token                  :
+     :                                                               :
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option Type
+
+      8-bit identifier of the type of this mobility option.  Its value
+      is 14.
+
+   Option Length
+
+      8-bit unsigned integer representing the length of the Permanent
+      Home Keygen Token field in octets.
+
+   Permanent Home Keygen Token
+
+      This field contains the permanent home keygen token generated by
+      the correspondent node.  The content of this field MUST be
+      encrypted with the mobile node's public key as defined in
+      Section 4.7.  The length of the permanent home keygen token is 8
+      octets before encryption, though the ciphertext [4] and, hence,
+      the Permanent Home Keygen Token field may be longer.
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 34]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+5.4.  Care-of Test Init Option
+
+   The Care-of Test Init option is included in Binding Update messages.
+   It requests a correspondent node to return a Care-of Test option with
+   a fresh care-of keygen token in the Binding Acknowledgment message.
+
+   The format of the Care-of Test Init option is as follows:
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                     |  Option Type  | Option Length |
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option Type
+
+      8-bit identifier of the type of this mobility option.  Its value
+      is 15.
+
+   Option Length
+
+      This field MUST be set to zero.
+
+5.5.  Care-of Test Option
+
+   The Care-of Test option is used in Binding Acknowledgment messages.
+   It contains a fresh care-of keygen token, which the correspondent
+   node sends to the mobile node after it has received a Care-of Test
+   Init option in a Binding Update message.
+
+   The format of the Care-of Test option is as follows:
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                     |  Option Type  | Option Length |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                     Care-of Keygen Token                      +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option Type
+
+      8-bit identifier of the type of this mobility option.  Its value
+      is 16.
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 35]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Option Length
+
+      This field MUST be set to 8.  It represents the length of the
+      Care-of Keygen Token field in octets.
+
+   Care-of Keygen Token
+
+      This field contains the care-of keygen token generated by the
+      correspondent node, as specified in Section 4.3.
+
+5.6.  CGA Parameters Request Option
+
+   The CGA Parameters Request option is included in Binding Update
+   messages that are authenticated based on the CGA property of the
+   mobile node's home address.  It requests a correspondent node to
+   return its CGA parameters and signature in the Binding Acknowledgment
+   message, enabling the mobile node to verify that the permanent home
+   keygen token returned in the Binding Acknowledgment message was
+   generated by the right correspondent node.
+
+   The format of the CGA Parameters Request option is as follows:
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                     |  Option Type  | Option Length |
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option Type
+
+      8-bit identifier of the type of this mobility option.  Its value
+      is 11.
+
+   Option Length
+
+      This field MUST be set to zero.
+
+5.7.  Status Codes
+
+   Enhanced Route Optimization uses the following four new status codes
+   for Binding Acknowledgment messages in addition to the status codes
+   defined in [1]:
+
+   Permanent home keygen token unavailable (147)
+
+      A correspondent node returns a Binding Acknowledgment message with
+      status code 147 to a mobile node if it has received from the
+      mobile node a Binding Update message that was authenticated
+
+
+
+Arkko, et al.               Standards Track                    [Page 36]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+      through the CGA property of the mobile node's home address, but
+      the correspondent node either does not have a Binding Cache entry
+      for the mobile node, or the existing Binding Cache entry for the
+      mobile node does not contain a permanent home keygen token.  A
+      Binding Acknowledgment message with status code 147 indicates to
+      the mobile node that it should request a new permanent home keygen
+      token from the correspondent node by sending the correspondent
+      node a Binding Update message including its CGA parameters and
+      signature.  This in particular enables the mobile node to quickly
+      recover from state loss at the correspondent node.
+
+      [1] does not allow a correspondent node to send a Binding
+      Acknowledgment message with a status code indicating failure when
+      the authenticator of a received Binding Update message turns out
+      to be incorrect.  This causes additional handoff latency with high
+      probability because the mobile node can detect the problem only
+      after the expiration of a retransmission timer.  The mobile node
+      is furthermore likely to assume packet loss and resend the
+      incorrectly authenticated Binding Update message additional times.
+      A Binding Acknowledgment message with status code 147 helps the
+      mobile node to identify the underlying problem more efficiently
+      when the correspondent node could not verify the CGA property of
+      the mobile node's home address.
+
+   CGA and signature verification failed (148)
+
+      A correspondent node returns a Binding Acknowledgment message with
+      status code 148 to a mobile node if it has received from the
+      mobile node a Binding Update message that includes one or more CGA
+      Parameters options directly followed by a Signature option, but
+      either the CGA property of the home address cannot be verified
+      based on the contents of the CGA Parameters options, or the
+      verification of the signature in the Signature option has failed.
+
+   Permanent home keygen token exists (149)
+
+      A correspondent node returns a Binding Acknowledgment message with
+      status code 149 to a mobile node if it has received from the
+      mobile node a Binding Update message that was authenticated
+      through verification of the mobile node's reachability at the home
+      address and does not include one or more CGA Parameters options
+      directly followed by a Signature option, but the correspondent
+      node has a permanent home keygen token in its Binding Cache entry
+      for the mobile node.  The Binding Update message is processed
+      further if it includes one or more CGA Parameters options directly
+      followed by a Signature option.  This enables a mobile node to
+      obtain a new permanent home keygen token from the correspondent
+      node in case it has lost the existing one, for instance, due to a
+
+
+
+Arkko, et al.               Standards Track                    [Page 37]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+      reboot.  Whether the correspondent node accepts the Binding Update
+      message in this case depends on the verification of the CGA
+      parameters and the signature provided in the Binding Update
+      message.
+
+   Non-null home nonce index expected (150)
+
+      A correspondent node returns a Binding Acknowledgment message with
+      status code 150 to a mobile node if it has received from the
+      mobile node a Binding Update message that includes one or more CGA
+      Parameters options directly followed by a Signature option, but
+      the home nonce index specified in the Nonce Indices option is
+      zero.  This behavior ensures that a Binding Update message that is
+      authenticated based on the CGA property of the mobile node's home
+      address must also provide a proof of the mobile node's
+      reachability at the home address.
+
+6.  Security Considerations
+
+   Enhanced Route Optimization differs from base Mobile IPv6 in that it
+   applies a set of optimizations for increased handoff performance,
+   stronger security, and reduced signaling overhead.  These
+   optimizations entail the following conceptual changes to the security
+   model [5] of base Mobile IPv6:
+
+   o  Base Mobile IPv6 conducts periodic tests of a mobile node's
+      reachability at the home address as a proof of home address
+      ownership.  Enhanced Route Optimization applies an initial
+      cryptographic home address ownership proof in combination with a
+      verification of the mobile node's reachability at the home address
+      in order to securely exchange a secret permanent home keygen
+      token.  The permanent home keygen token is used for cryptographic
+      authentication of the mobile node during subsequent correspondent
+      registrations, so that these later correspondent registrations can
+      be securely bound to the initial home address ownership proof.  No
+      further periodic reachability verification at the home address
+      tests is performed.
+
+   o  Base Mobile IPv6 requires a mobile node to prove its reachability
+      at a new care-of address during a correspondent registration.
+      This implies that the mobile node and the correspondent node must
+      exchange Care-of Test Init and Care-of Test messages before the
+      mobile node can initiate the binding update proper.  Enhanced
+      Route Optimization allows the mobile node to initiate the binding
+      update first and follow up with a proof of reachability at the
+      care-of address.  Mobile and correspondent nodes can so resume
+      communications early on after a handoff, while reachability
+      verification proceeds concurrently.  The amount of data that the
+
+
+
+Arkko, et al.               Standards Track                    [Page 38]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+      correspondent node is permitted to send to the care-of address
+      until reachability verification completes is governed by Credit-
+      Based Authorization.
+
+   o  The maximum binding lifetime for correspondent registrations is 7
+      minutes in base Mobile IPv6.  A mobile node must hence
+      periodically refresh a correspondent registration in cases where
+      it does not change IP connectivity for a while.  This protocol
+      increases the maximum binding lifetime to 24 hours, reducing the
+      need for periodic refreshes to a negligible degree.
+
+   The ensuing discussion addresses the implications that these
+   conceptual changes of the Mobile IPv6 security model have.  The
+   discussion ought to be seen in context with the security
+   considerations of [1], [2], and [5].
+
+6.1.  Home Address Ownership
+
+   Enhanced Route Optimization requires a mobile node to deliver a
+   strong cryptographic proof [2] that it is the legitimate owner of the
+   home address it wishes to use.  The proof is based on the true home
+   address owner's knowledge of the private component in a public/
+   private-key pair with the following two properties:
+
+   o  As an input to an irreversible CGA generation function along with
+      a set of auxiliary CGA parameters, the public key results in the
+      mobile node's home address.
+
+   o  Among the CGA parameters that are fed into the CGA generation
+      function is a modifier that, as an input to an irreversible hash
+      extension function along with the public key, results in a string
+      with a certain minimum number of leading zeroes.  Three reserved
+      bits in the home address encode this minimum number.
+
+   The first property cryptographically binds the home address to the
+   mobile node's public key and, by virtue of public-key cryptography,
+   to the private key.  It allows the mobile node to claim ownership of
+   the home address by proving its knowledge of the private key.  The
+   second property increases the cost of searching in brute-force manner
+   for a public/private-key pair that suffices the first property.  This
+   increases the security of a cryptographically generated home address
+   despite its limitation to 59 bits with cryptographic significance.
+   Solely enforcing the first property would otherwise allow an attacker
+   to find a suitable public/private-key pair in O(2^59) steps.  By
+   addition of the second property, the complexity of a brute-force
+   search can be increased to O(2^(59+N)) steps, where N is the minimum
+   number of leading zeroes that the result of the hash extension
+   function is required to have.
+
+
+
+Arkko, et al.               Standards Track                    [Page 39]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   In practice, for a legitimate mobile node to cryptographically
+   generate a home address, the mobile node must first accomplish a
+   brute-force search for a suitable modifier, and then use this
+   modifier to execute the CGA generation function.  An attacker who is
+   willing to spoof the mobile node's home address, so-called "IP
+   address stealing" [5], then has two options: It could either generate
+   its own public/private-key pair and perform a brute-force search for
+   a modifier which, in combination with the generated public key,
+   suffices the initially described two properties; or it could integer-
+   factor the mobile node's public key, deduce the corresponding private
+   key, and copy the mobile node's modifier without a brute-force
+   search.  The cost of the attack can be determined by the mobile node
+   in either case: Integer-factoring a public key becomes increasingly
+   complex as the length of the public key grows, and the key length is
+   at the discretion of the mobile node.  The cost of a brute-force
+   search for a suitable modifier increases with the number of leading
+   zeroes that the result of the hash extension function is required to
+   have.  This number, too, is a parameter that the mobile node can
+   choose.  Downgrading attacks, where the attacker reduces the cost of
+   spoofing a cryptographically generated home address by choosing a set
+   of CGA parameters that are less secure than the CGA parameters the
+   mobile node has used to generate the home address, are hence
+   impossible.
+
+   The CGA specification [2] requires the use of RSA public and private
+   keys, and it stipulates a minimum key length of 384 bits.  This
+   requirement that was tailored to Secure Neighbor Discovery for IPv6
+   [13], the original CGA application.  Enhanced Route Optimization does
+   not increase the minimum key length because, in the absence of
+   downgrading attacks as explained before, the ability to use short
+   keys does not compromise the security of home addresses that were
+   cryptographically generated using longer keys.  Moreover, extensions
+   to [2] may eventually permit the use of public/private-key classes
+   other than RSA.  Such extensions are compatible with the CGA
+   application of Enhanced Route Optimization.  Care must be taken in
+   selecting an appropriate key class and length, however.  Home
+   addresses are typically rather stable in nature, so the chosen
+   parameters must be secure for a potentially long home address
+   lifetime.  Where RSA keys are used, a minimum key length of 1024 bits
+   is therefore RECOMMENDED.
+
+   While the CGA generation function cryptographically ties the
+   interface identifier of a home address to the subnet prefix of the
+   home address, the function accepts any subnet prefix and hence does
+   not prevent a node from cryptographically generating a home address
+   with a spoofed subnet prefix.  As a consequence, the CGA property of
+   a home address does not guarantee the owner's reachability at the
+   home address.  This could be misused for a "return-to-home flooding
+
+
+
+Arkko, et al.               Standards Track                    [Page 40]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   attack" [5], where the attacker uses its own public key to
+   cryptographically generate a home address with a subnet prefix from a
+   victim network, requests a correspondent node to bind this to the
+   attacker's current care-of address, initiates the download of a large
+   file via the care-of address, and finally deregisters the binding or
+   lets it expire.  The correspondent node would then redirect the
+   packets being downloaded to the victim network identified by the
+   subnet prefix of the attacker's spoofed home address.  The protocol
+   defined in this document performs a reachability test for the home
+   address at the time the home address is first registered with the
+   correspondent node.  This precludes return-to-home flooding.
+
+   The verification of the CGA property of a mobile node's home address
+   involves asymmetric public-key cryptography, which is relatively
+   complex compared to symmetric cryptography.  Enhanced Route
+   Optimization mitigates this disadvantage through the use of symmetric
+   cryptography after an initial public-key-based verification of the
+   mobile node's home address has been performed.  Specifically, the
+   correspondent node assigns the mobile node a permanent home keygen
+   token during the initial correspondent registration based on which
+   the mobile node can authenticate to the correspondent node during
+   subsequent correspondent registrations.  Such authentication enables
+   the correspondent node to bind a subsequent correspondent
+   registration back to the initial public-key-based verification of the
+   mobile node's home address.  The permanent home keygen token is never
+   sent in plain text; it is encrypted with the mobile node's public key
+   when initially assigned, and irreversibly hashed during subsequent
+   correspondent registrations.
+
+6.2.  Care-of Address Ownership
+
+   A secure proof of home address ownership can mitigate the threat of
+   IP address stealing, but an attacker may still bind a correct home
+   address to a false care-of address and thereby trick a correspondent
+   node into redirecting packets, which would otherwise be delivered to
+   the attacker itself, to a third party.  Neglecting to verify a mobile
+   node's reachability at its claimed care-of address could therefore
+   cause one or multiple correspondent nodes to unknowingly contribute
+   to a redirection-based flooding attack against a victim chosen by the
+   attacker.
+
+   Redirection-based flooding attacks may target a single node, a link,
+   or a router or other critical network device upstream of an entire
+   network.  Accordingly, the attacker's spoofed care-of address may be
+   the IP address of a node, a random IP address from a subnet prefix of
+   a particular link, or the IP address of a router or other network
+   device.  An attack against a network potentially impacts a larger
+   number of nodes than an attack against a specific node, although
+
+
+
+Arkko, et al.               Standards Track                    [Page 41]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   neighbors of a victim node on a broadcast link typically suffer the
+   same damage as the victim itself.
+
+   Requiring mobile nodes to cryptographically generate care-of
+   addresses in the same way as they generate home addresses would
+   mitigate the threat of redirection-based flooding only marginally.
+   While it would prevent an attacker from registering as its care-of
+   address the IP address of a specific victim node, the attacker could
+   still generate a different CGA-based care-of address with the same
+   subnet prefix as that of the victim's IP address.  Flooding packets
+   redirected towards this care-of address would then not have to be
+   received and processed by any specific node, but they would impact an
+   entire link or network and thus cause comparable damage.  CGA-based
+   care-of addresses therefore have little effectiveness with respect to
+   flooding protection.  On the other hand, they would require a
+   computationally expensive, public-key-based ownership proof whenever
+   the care-of address changes.  For these reasons, Enhanced Route
+   Optimization uses regular IPv6 care-of addresses.
+
+   A common misconception is that a strong proof of home address
+   ownership would mitigate the threat of redirection-based flooding and
+   consequently eliminate the need to verify a mobile node's
+   reachability at a new care-of address.  This notion may originate
+   from the specification of a base Mobile IPv6 home registration in
+   [1], which calls for the authentication of a mobile node based on an
+   IPsec security association, but does not require this to be
+   supplemented by a verification of the mobile node's reachability at
+   the care-of address.  However, the reason not to mandate reachability
+   verification for a home registration is in this case the existence of
+   an administrative relationship between the home agent and the mobile
+   node, rather than the fact that the home agent can securely verify
+   the mobile node's home address ownership, or that the home
+   registration is IPsec-protected.  The administrative relationship
+   with the mobile node allows the home agent, first, to trust in the
+   correctness of a mobile node's care-of address and, second, to
+   quickly identify the mobile node should it still start behaving
+   maliciously, for example, due to infection by malware.  Section 15.3
+   in [1] and Section 1.3.2 in [5] explain these prerequisites.
+
+   Assuming trust, an administrative relationship between the mobile
+   node and its home agent is viable, given that the home agent is an
+   integral part of the mobility services that a mobile user typically
+   subscribes to, sets up her- or himself, or receives based on a
+   business relationship.  A Mobile IPv6 extension [14] that leverages a
+   shared authentication key, preconfigured on the mobile node and the
+   correspondent node, preassumes the same relationship between the
+   mobile node and a correspondent node.  While this assumption limits
+   the applicability of the protocol (Section 2 of [14] acknowledges
+
+
+
+Arkko, et al.               Standards Track                    [Page 42]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   this), it permits omission of care-of address reachability
+   verification as in the case of the home registration.  Enhanced
+   Router Optimization does not make assumptions on the relationship
+   between mobile and correspondent nodes.  This renders the protocol
+   applicable to arbitrary scenarios, but necessitates that
+   correspondent nodes must verify a mobile node's reachability at every
+   new care-of address.
+
+6.3.  Credit-Based Authorization
+
+   Enhanced Route Optimization enables mobile and correspondent nodes to
+   resume bidirectional communications after a handoff on the mobile-
+   node side before the mobile node's reachability at the new care-of
+   address has been verified by the correspondent node.  Such
+   concurrency would in the absence of appropriate protection
+   reintroduce the threat of redirection-based flooding, which
+   reachability verification was originally designed to eliminate: Given
+   that the correspondent node is in general unaware of the round-trip
+   time to the mobile node, and since reachability verification may fail
+   due to packet loss, the correspondent node must accept a sufficiently
+   long concurrency period for reachability verification to complete.
+   An attacker could misuse this to temporarily trick the correspondent
+   node into redirecting packets to the IP address of a victim.  The
+   attacker may also successively postpone reachability verification in
+   that it registers with the correspondent node anew, possibly with a
+   different spoofed care-of address, shortly before the correspondent
+   node's maximum permitted concurrency period elapses and the
+   correspondent node switches to waiting for the completion of
+   reachability verification without sending further packets.  This
+   behavior cannot necessarily be considered malicious on the
+   correspondent node side since even a legitimate mobile node's
+   reachability may fail to become verified before the mobile node's
+   care-of address changes again.  This may be due to high mobility on
+   the mobile node side, or to persistent packet loss on the path
+   between the mobile node and the correspondent node.  It is generally
+   non-trivial to decide on the correspondent node side whether the
+   party at the other end behaves legitimately under adverse conditions
+   or maliciously.
+
+   Enhanced Route Optimization eliminates the threat of redirection-
+   based flooding despite concurrent reachability verification through
+   the use of Credit-Based Authorization.  Credit-Based Authorization
+   manages the effort that a correspondent node expends in sending
+   payload packets to a care-of address in UNVERIFIED state.  This is
+   accomplished based on the following three hypotheses:
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 43]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   1.  A flooding attacker typically seeks to shift the burden of
+       assembling and sending flooding packets to a third party.
+       Bandwidth is an ample resource for many attractive victims, so
+       the effort for sending the high rate of flooding packets required
+       to impair the victim's ability to communicate may exceed the
+       attacker's own capacities.
+
+   2.  The attacker can always flood a victim directly by generating
+       bogus packets itself and sending those to the victim.  Such an
+       attack is not amplified, so the attacker must be provisioned
+       enough to generate a packet flood sufficient to bring the victim
+       down.
+
+   3.  Consequently, the additional effort required to set up and
+       coordinate a redirection-based flooding attack pays off for the
+       attacker only if the correspondent node can be tricked into
+       contributing to and amplifying the attack.
+
+   Non-amplified redirection-based flooding is hence, from an attacker's
+   perspective, no more attractive than pure direct flooding, where the
+   attacker itself sends bogus packets to the victim.  It is actually
+   less attractive given that the attacker needs to maintain a context
+   for mobility management in order to coordinate the redirection.  On
+   this basis, Credit-Based Authorization extinguishes the motivation
+   for redirection-based flooding by preventing the amplification that
+   could be reached through it, rather than eliminating malicious packet
+   redirection in the first place.  The ability to send unrequested
+   packets is an inherent property of packet-oriented networks, and
+   direct flooding is a threat that results from this.  Since direct
+   flooding exists with and without mobility support, it constitutes a
+   reasonable measure in comparing the security provided by Enhanced
+   Route Optimization to the security of the non-mobile Internet.
+   Through the use of Credit-Based Authorization, Enhanced Route
+   Optimization satisfies the objective to provide a security level
+   comparable to that of the non-mobile Internet.
+
+   Since the perpetrator of a redirection-based flooding attack would
+   take on the role of a mobile node, Credit-Based Authorization must be
+   enforced on the correspondent node side.  The correspondent node
+   continuously monitors the effort that the mobile node spends in
+   communicating with the correspondent node.  The mobile node's effort
+   is then taken as a limit on the effort that the correspondent node
+   may spend in sending payload packets when the mobile node's care-of
+   address is in UNVERIFIED state.  The permission for the correspondent
+   node to send a limited amount of payload packets to a care-of address
+   in UNVERIFIED state enables immediate resumption of bidirectional
+   communications once the mobile node has registered a new IP address
+   with the correspondent node after a handoff.
+
+
+
+Arkko, et al.               Standards Track                    [Page 44]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   If what appears to be a mobile node is in fact an attacker who tricks
+   the correspondent node into redirecting payload packets to the IP
+   address of a victim, Credit-Based Authorization ensures that the
+   stream of flooding packets ceases before the effort that the
+   correspondent node spends on generating the stream exceeds the effort
+   that the attacker has recently spent itself.  The flooding attack is
+   therefore at most as effective as a direct flooding attack, and
+   consequently fails to produce any amplification.
+
+   Another property of Credit-Based Authorization is that it does not
+   assign a mobile node credit while its care-of addresses is in
+   UNVERIFIED state.  This deserves justification since it would
+   technically be feasible to assign credit independent of the state of
+   the mobile node's care-of address.  However, the assignment of credit
+   for packets received from a care-of address in UNVERIFIED state would
+   introduce a vulnerability to sustained reflection attacks.
+   Specifically, an attacker could cause a correspondent node to
+   redirect packets for the attacker to the IP address of a victim, and
+   sustain the packet flow towards the victim in that it continuously
+   replenishes its credit by sending packets to the correspondent node.
+   Although such a redirection-based reflection attack would fail to
+   produce any amplification, it may still be appealing to an attacker
+   who wishes to pursue an initial transport protocol handshake with the
+   correspondent node -- which typically requires the attacker to
+   receive some unguessable data -- and redirect the download to the
+   victim's IP address afterwards.  Credit-Based Authorization ensures
+   that the attacker in this case cannot acquire additional credit once
+   the download has been redirected, and thereby forces the attack to
+   end quickly.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 45]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+6.4.  Time Shifting Attacks
+
+   Base Mobile IPv6 limits the lifetime of a correspondent registration
+   to 7 minutes and so arranges that a mobile node's reachability at its
+   home and care-of addresses is reverified periodically.  This ensures
+   that the return routability procedure's vulnerability to
+   eavesdropping cannot be exploited by an attacker that is only
+   temporarily on the path between the correspondent node and the
+   spoofed home or care-of address.  Such "time shifting attacks" [5]
+   could otherwise be misused for off-path IP address stealing, return-
+   to-home flooding, or flooding against care-of addresses.
+
+   Enhanced Route Optimization repeats neither the initial home address
+   test nor any care-of address test in order to decrease handoff delays
+   and signaling overhead.  This does not limit the protocol's
+   robustness to IP address stealing attacks because the required CGA-
+   based ownership proof for home addresses already eliminates such
+   attacks.  Reachability verification does not add further protection
+   in this regard.  On the other hand, the restriction to an initial
+   reachability verification facilitates time-shifted, off-path flooding
+   attacks -- either against home addresses with incorrect prefixes or
+   against spoofed care-of addresses -- if the perpetrator can interpose
+   in the exchange before it moves to a different location.
+
+   The design choice against repeated home and care-of address tests was
+   made based on the observation that time shifting attacks are already
+   an existing threat in the non-mobile Internet of today.
+   Specifically, an attacker can temporarily move onto the path between
+   a victim and a correspondent node, request a stream of packets from
+   the correspondent node on behalf of the victim, and then move to a
+   different location.  Most transport protocols do not verify an
+   initiator's reachability at the claimed IP address after an initial
+   verification during connection establishment.  It enables an attacker
+   to participate only in connection establishment and then move to an
+   off-path position, from where it can spoof acknowledgments to feign
+   continued presence at the victim's IP address.  The threat of time
+   shifting hence already applies to the non-mobile Internet.
+
+   It should still be acknowledged that the time at which Enhanced Route
+   Optimization verifies a mobile node's reachability at a home or
+   care-of address may well antecede the establishment of any transport
+   layer connection.  This gives an attacker more time to move away from
+   the path between the correspondent node and the victim and so makes a
+   time shifting attack more practicable.  If the lack of periodic
+   reachability verification is considered too risky, a correspondent
+   node may enforce reruns of home or care-of address tests by limiting
+   the registration lifetime, or by sending Binding Refresh Request
+   messages to a mobile node.
+
+
+
+Arkko, et al.               Standards Track                    [Page 46]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+6.5.  Replay Attacks
+
+   The protocol specified in this document relies on 16-bit base Mobile
+   IPv6 sequence numbers and periodic rekeying to avoid replay attacks.
+   Rekeying allows mobile and correspondent nodes to reuse sequence
+   numbers without exposing themselves to replay attacks.  It must be
+   pursued at least once every 24 hours due to the maximum permitted
+   binding lifetime for correspondent registrations.  Mobile and
+   correspondent nodes also rekey whenever a rollover in sequence number
+   space becomes imminent.  This is unlikely to happen frequently,
+   however, given that available sequence numbers are sufficient for up
+   to 32768 correspondent registrations, each consisting of an early and
+   a complete Binding Update message.  The sequence number space thus
+   permits an average rate of 22 correspondent registrations per minute
+   without exposing a need to rekey throughout the 24-hour binding
+   lifetime.
+
+6.6.  Resource Exhaustion
+
+   While a CGA-based home address ownership proof provides protection
+   against unauthenticated Binding Update messages, it can expose a
+   correspondent node to denial-of-service attacks since it requires
+   computationally expensive public-key cryptography.  Enhanced Route
+   Optimization limits the use of public-key cryptography to only the
+   first correspondent registration and if/when rekeying is needed.  It
+   is RECOMMENDED that correspondent nodes in addition track the amount
+   of processing resources they spend on CGA-based home address
+   ownership verification, and that they reject new correspondent
+   registrations that involve public-key cryptography when these
+   resources exceed a predefined limit. [2] discusses the feasibility of
+   CGA-based resource exhaustion attacks in depth.
+
+6.7.  IP Address Ownership of Correspondent Node
+
+   Enhanced Route Optimization enables mobile nodes to authenticate a
+   received Binding Acknowledgment message based on a CGA property of
+   the correspondent node's IP address, provided that the correspondent
+   node has a CGA.  The mobile node requests this authentication by
+   including a CGA Parameters Request option in the Binding Update
+   message that it sends to the correspondent node, and the
+   correspondent node responds by adding its CGA parameters and
+   signature to the Binding Acknowledgment message within CGA Parameters
+   and Signature options.  Proving ownership of the correspondent node's
+   IP address protects the mobile node from accepting a spoofed Binding
+   Acknowledgment message and from storing the included permanent home
+   keygen token for use during future correspondent registrations.  Such
+   an attack would result in denial of service against the mobile node
+   because it would prevent the mobile node from transacting any binding
+
+
+
+Arkko, et al.               Standards Track                    [Page 47]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   updates with the obtained permanent home keygen token.  Enhanced
+   Route Optimization recommends renewal of a permanent home keygen
+   token in case of persistent correspondent registration failures,
+   allowing mobile nodes to recover from denial-of-service attacks that
+   involve spoofed permanent home keygen tokens.
+
+   The threat of the described denial-of-service attack is to some
+   extent mitigated by requirements on the attacker's location: A
+   Binding Update message that requests a correspondent node to provide
+   a permanent home keygen token is authenticated based on the CGA
+   property of the mobile node's home address.  This authentication
+   method involves a home address test, providing the mobile node with a
+   home keygen token based on which it can calculate the authenticator
+   of the Binding Update message.  Since the mobile node expects the
+   authenticator of the returning Binding Acknowledgment message to be
+   calculated with the same home keygen token, an attacker that is
+   willing to spoof a Binding Acknowledgment message that includes a
+   permanent home keygen token must eavesdrop on the home address test.
+   The attacker must hence be present on the path from the correspondent
+   node to the mobile node's home agent while the home address test
+   proceeds.  Moreover, if the Binding Update message requesting the
+   permanent home keygen token is complete, its authenticator is further
+   calculated based on a care-of keygen token.  The attacker must then
+   also know this care-of keygen token to generate the authenticator of
+   the Binding Acknowledgment message.  This requires the attacker to be
+   on the path from the correspondent node to the mobile node's current
+   IP attachment at the time the correspondent node sends the care-of
+   keygen token to the mobile node within a Care-of Test message or the
+   Care-of Test option of a Binding Acknowledgment message.
+
+   Since a mobile node in general does not know whether a particular
+   correspondent node's IP address is a CGA, the mobile node must be
+   prepared to receive a Binding Acknowledgment message without CGA
+   Parameters and Signature options in response to sending a Binding
+   Update message with an included CGA Parameters Request option.  Per
+   se, this mandatory behavior may enable downgrading attacks where the
+   attacker would send, on the correspondent node's behalf, a Binding
+   Acknowledgment message without CGA Parameters and Signature options,
+   claiming that the correspondent node's IP address is not a CGA.
+   Enhanced Route Optimization mitigates this threat in that it calls
+   for mobile nodes to prioritize Binding Acknowledgment messages with
+   valid CGA Parameters and Signature options over Binding
+   Acknowledgment messages without such options.  This protects against
+   downgrading attacks unless the attacker can intercept Binding
+   Acknowledgment messages from the correspondent node.  Given that the
+   attacker must be on the path from the correspondent node to the
+   mobile node's home agent at roughly the same time as explained above,
+   the attacker may not be able to intercept the correspondent node's
+
+
+
+Arkko, et al.               Standards Track                    [Page 48]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Binding Acknowledgment messages.  On the other hand, an attacker that
+   can intercept Binding Acknowledgment messages from the correspondent
+   node is anyway in a position where it can pursue denial of service
+   against the mobile node and the correspondent node.  This is a threat
+   that already exists in the non-mobile Internet, and it is not
+   specific to Enhanced Route Optimization.
+
+   External mechanisms may enable the mobile node to obtain certainty
+   about whether a particular correspondent node's IP address is a CGA.
+   The mobile node may then insist on an IP address ownership proof from
+   the correspondent node, in which case it would discard any received
+   Binding Acknowledgment messages that do not contain valid CGA
+   Parameters and Signature options.  One conceivable means for mobile
+   nodes to distinguish between standard IPv6 addresses and CGAs might
+   be an extension to the Domain Name System.
+
+7.  Protocol Constants and Configuration Variables
+
+   [2] defines a CGA Message Type namespace from which CGA applications
+   draw CGA Message Type tags to be used in signature calculations.
+   Enhanced Route Optimization uses the following constant, randomly
+   generated CGA Message Type tag:
+
+      0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13
+
+   [1] bounds the lifetime for bindings that were established with
+   correspondent nodes by way of the return routability procedure to
+   MAX_RR_BINDING_LIFETIME.  Enhanced Route Optimization adopts this
+   limit for bindings that are authenticated through a proof of the
+   mobile node's reachability at the home address.  However, the binding
+   lifetime is limited to the more generous constant value of
+   MAX_CGA_BINDING_LIFETIME when the binding is authenticated through
+   the CGA property of the mobile node's home address:
+
+      MAX_CGA_BINDING_LIFETIME   86400 seconds
+
+   Credit aging incorporates two configuration variables to gradually
+   decrease a mobile node's credit counter over time.  It is RECOMMENDED
+   that a correspondent node uses the following values:
+
+      CreditAgingFactor          7/8
+      CreditAgingInterval        5 seconds
+
+
+
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 49]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+8.  IANA Considerations
+
+   This document defines the following six new mobility options, which
+   must be assigned type values within the mobility option numbering
+   space of [1]:
+
+   o  CGA Parameters Request mobility option (11)
+
+   o  CGA Parameters mobility option (12)
+
+   o  Signature mobility option (13)
+
+   o  Permanent Home Keygen Token mobility option (14)
+
+   o  Care-of Test Init mobility option (15)
+
+   o  Care-of Test mobility option (16)
+
+   This document allocates the following four new status codes for
+   Binding Acknowledgment messages:
+
+   o  "Permanent home keygen token unavailable" (147)
+
+   o  "CGA and signature verification failed" (148)
+
+   o  "Permanent home keygen token exists" (149)
+
+   o  "Non-null home nonce index expected" (150)
+
+   The values to be assigned for these status codes must all be greater
+   than or equal to 128, indicating that the respective Binding Update
+   message was rejected by the receiving correspondent node.
+
+   This document also defines a new 128-bit value under the CGA Message
+   Type namespace [2].
+
+9.  Acknowledgments
+
+   The authors would like to thank Tuomas Aura, Gabriel Montenegro,
+   Pekka Nikander, Mike Roe, Greg O'Shea, Vesa Torvinen (in alphabetical
+   order) for valuable and interesting discussions around
+   cryptographically generated addresses.
+
+   The authors would also like to thank Marcelo Bagnulo, Roland Bless,
+   Zhen Cao, Samita Chakrabarti, Greg Daley, Vijay Devarapalli, Mark
+   Doll, Lakshminath Dondeti, Francis Dupont, Lars Eggert, Eric Gray,
+   Manhee Jo, James Kempf, Suresh Krishnan, Tobias Kuefner, Lila Madour,
+   Vidya Narayanan, Mohan Parthasarathy, Alice Qinxia, and Behcet
+
+
+
+Arkko, et al.               Standards Track                    [Page 50]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   Sarikaya (in alphabetical order) for their reviews of and important
+   comments on this document and the predecessors of this document.
+
+   Finally, the authors would also like to emphasize that [15] pioneered
+   the use of cryptographically generated addresses in the context of
+   Mobile IPv6 route optimization, and that this document consists
+   largely of material from [16], [17], and [18] and the contributions
+   of their authors.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+         IPv6", RFC 3775, June 2004.
+
+   [2]   Aura, T., "Cryptographically Generated Addresses (CGA)",
+         RFC 3972, March 2005.
+
+   [3]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+         Levels", IETF BCP 14, RFC 2119, March 1997.
+
+   [4]   Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
+         (PKCS) #1: RSA Cryptography Specifications Version 2.1",
+         RFC 3447, February 2003.
+
+10.2.  Informative References
+
+   [5]   Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
+         Nordmark, "Mobile IP Version 6 Route Optimization Security
+         Design Background", RFC 4225, December 2005.
+
+   [6]   Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements
+         to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
+
+   [7]   Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
+         IPv6", Proceedings of the IEEE Wireless Communications and
+         Networking Conference, IEEE, April 2006.
+
+   [8]   Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS
+         Defense Mechanisms", ACM SIGCOMM Computer Communication Review,
+         Vol. 34, No. 2, ACM Press, April 2004.
+
+   [9]   Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
+         Lifetime Extension", Work in Progress, May 2004.
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 51]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+   [10]  O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6
+         (CAM)", ACM SIGCOMM Computer Communication Review, ACM Press,
+         Vol. 31, No. 2, April 2001.
+
+   [11]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
+         Authentication in the IPv6 World", Revised papers from the
+         International Workshop on Security Protocols, Springer-Verlag,
+         April 2002.
+
+   [12]  Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms
+         in Cryptographically Generated Addresses (CGAs)", Work
+         in Progress, April 2007.
+
+   [13]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+         Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [14]  Perkins, C., "Securing Mobile IPv6 Route Optimization Using a
+         Static Shared Key", RFC 4449, June 2006.
+
+   [15]  Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of
+         Mobile IPv6 Binding Updates and Acknowledgments", Work
+         in Progress, March 2002.
+
+   [16]  Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying
+         Cryptographically Generated Addresses to Optimize MIPv6  (CGA-
+         OMIPv6)", Work Progress, May 2005.
+
+   [17]  Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding
+         Updates for Mobile IPv6", Work in Progress, February 2004.
+
+   [18]  Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner,
+         "Credit-Based Authorization for Mobile IPv6 Early Binding
+         Updates", Work in Progress, May 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 52]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+Authors' Addresses
+
+   Jari Arkko
+   Ericsson Research NomadicLab
+   FI-02420 Jorvas
+   Finland
+
+   EMail: jari.arkko@ericsson.com
+
+
+   Christian Vogt
+   Institute of Telematics
+   Universitaet Karlsruhe (TH)
+   P.O. Box 6980
+   76128 Karlsruhe
+   Germany
+
+   EMail: chvogt@tm.uka.de
+
+
+   Wassim Haddad
+   Ericsson Research
+   8400, Decarie Blvd
+   Town of Mount Royal
+   Quebec H4P 2N2, Canada
+
+   EMail: wassim.haddad@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 53]
+
+RFC 4866              Enhanced Route Optimization               May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+Arkko, et al.               Standards Track                    [Page 54]
+