tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4866

 
 
 

Enhanced Route Optimization for Mobile IPv6

Part 3 of 3, p. 32 to 54
Prev RFC Part

 


prevText      Top      Up      ToC       Page 32 
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.

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
   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

Top      Up      ToC       Page 37 
      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

Top      Up      ToC       Page 38 
      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

Top      Up      ToC       Page 39 
      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.

Top      Up      ToC       Page 40 
   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

Top      Up      ToC       Page 41 
   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

Top      Up      ToC       Page 42 
   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

Top      Up      ToC       Page 43 
   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:

Top      Up      ToC       Page 44 
   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.

Top      Up      ToC       Page 45 
   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.

Top      Up      ToC       Page 46 
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.

Top      Up      ToC       Page 47 
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

Top      Up      ToC       Page 48 
   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

Top      Up      ToC       Page 49 
   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

Top      Up      ToC       Page 50 
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

Top      Up      ToC       Page 51 
   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.

Top      Up      ToC       Page 52 
   [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.

Top      Up      ToC       Page 53 
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

Top      Up      ToC       Page 54 
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.