Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4866

Enhanced Route Optimization for Mobile IPv6

Pages: 54
Proposed Standard
Errata
Part 3 of 3 – Pages 32 to 54
First   Prev   None

Top   ToC   RFC4866 - Page 32   prevText

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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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   ToC   RFC4866 - 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.