tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4866

 
 
 

Enhanced Route Optimization for Mobile IPv6

Part 2 of 3, p. 10 to 32
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 10 
4.  Protocol Operation

   Enhanced Route Optimization allows a mobile node to securely
   authenticate to a correspondent node based on the CGA property of its
   home address, and to request a concurrent care-of address test for
   increased handoff efficiency.  Depending on whether the mobile node
   wishes to take advantage of either or both of these enhancements, the
   messages exchanged during a correspondent registration are different.
   This is described in the following.

4.1.  Sending Binding Update Messages

   A mobile node may initiate a correspondent registration for any of
   the following reasons:

   o  To establish a new binding at a correspondent node while away from
      its home link so that subsequent packets will be route-optimized
      and no longer be routed through the mobile node's home agent.

Top      Up      ToC       Page 11 
   o  To update an existing binding at the correspondent node while
      moving from one point of IP attachment to another.

   o  To follow up an early Binding Update message with a complete
      Binding Update message after receiving a Binding Acknowledgment
      message with a Care-of Test option.

   o  To refresh an existing binding at the correspondent node without
      changing the current point of IP attachment.

   o  To request the correspondent node to renew an existing permanent
      home keygen token shared between the mobile node and the
      correspondent node (see Section 4.5).

   o  To request the correspondent node to deregister an existing
      binding.


     Mobile node               Home agent           Correspondent node
         |                         |                         |
         |                         |                         |
         ~ Handoff                 |                         |
         |                         |                         |
         |-Binding Update--------->|                         |
         |-early Binding Update + Care-of Test Init option-->|
         |                         |                         |
         |                         |                         |
         |<------------Binding Ack-|                         |
         |<----------early Binding Ack + Care-of Test option-|
         |                         |                         |
         |                         |                         |
         |-Binding Update----------------------------------->|
         |                         |                         |
         |                         |                         |
         |<--------------------------------------Binding Ack-|
         |                         |                         |

    Figure 1: Correspondent registration with authentication by a proof
     of the mobile node's knowledge of a permanent home keygen token;
                      concurrent care-of address test

   In any of these cases, the mobile node sends a Binding Update message
   to the correspondent node.  The Binding Update message is
   authenticated by one of the following three authentication methods:

   o  If the mobile node's home address is a CGA, but the mobile node
      does not have a permanent home keygen token in its Binding Update
      List entry for the correspondent node, the mobile node SHOULD

Top      Up      ToC       Page 12 
      authenticate the Binding Update message based on the CGA property
      of its home address.  This requires the mobile node to send its
      CGA parameters and signature to the correspondent node and to pass
      a check of reachability at the home address.

   o  If the mobile node's home address is a CGA, and the mobile node
      has a permanent home keygen token in its Binding Update List entry
      for the correspondent node, the mobile node MUST authenticate the
      Binding Update message by a proof of its knowledge of the
      permanent home keygen token.

   o  If the mobile node's home address is not a CGA, the mobile node
      MUST authenticate the Binding Update message through a proof of
      reachability at its home address.

   The lifetime requested by the mobile node in the Lifetime field of
   the Binding Update message MUST NOT exceed MAX_CGA_BINDING_LIFETIME
   (see Section 7) if the Binding Update message is to be authenticated
   based on the CGA property of the mobile node's home address or by a
   proof of the mobile node's knowledge of a permanent home keygen
   token.  If the selected authentication method is a proof of the
   mobile node's reachability at the home address, the lifetime MUST NOT
   exceed MAX_RR_BINDING_LIFETIME [1].  It is RECOMMENDED in all cases
   that the mobile node requests the maximum permitted lifetime in order
   to avoid unnecessary binding refreshes and thus reduce signaling
   overhead.  The Lifetime field of a Binding Update message that
   requests the deletion of an existing binding at the correspondent
   node MUST be set to zero.

   If the selected authentication method is by way of the CGA property
   of the mobile node's home address, the mobile node includes its CGA
   parameters and signature in the Binding Update message by adding one
   or more CGA Parameters options (see Section 5.1) directly followed by
   a Signature option (see Section 5.2).  This is described in
   Section 4.5.  Once a permanent home keygen token has been obtained
   from the correspondent node, the mobile node MUST authenticate all
   subsequent Binding Update messages by a proof of its knowledge of
   this permanent home keygen token until either the binding lifetime
   expires, the permanent home keygen token is renewed, or the mobile
   node explicitly deregisters the binding at the correspondent node.
   This ensures that an attacker on the path from the correspondent node
   to the mobile node's home address cannot downgrade the mobile node's
   chosen authentication method to a proof of reachability at the home
   address.  The mobile node MAY choose to ignore the CGA property of
   its home address and authenticate Binding Update messages through a
   proof of reachability at the home address.  However, this behavior
   increases the vulnerability to on-path attackers and is therefore NOT
   RECOMMENDED.

Top      Up      ToC       Page 13 
     Mobile node              Home agent          Correspondent node
         |                         |                         |
         |                         |                         |
         |-Home Test Init--------->|------------------------>|
         |                         |                         |
         |<------------------------|<--------------Home Test-|
         |                         |                         |
         |                         |                         |
         ~ Handoff                 |                         |
         |                         |                         |
         |-Binding Update--------->|                         |
         |-early Binding Update + Care-of Test Init option-->|
         |                         |                         |
         |                         |                         |
         |<------------Binding Ack-|                         |
         |<----------early Binding Ack + Care-of Test option-|
         |                         |                         |
         |                         |                         |
         |-Binding Update----------------------------------->|
         |                         |                         |
         |                         |                         |
         |<--------------------------------------Binding Ack-|
         |                         |                         |

     Figure 2: Correspondent registration with authentication based on
     reachability verification at the home address; concurrent care-of
                               address test

   The mobile node also includes its CGA parameters in the Binding
   Update message when it intends to renew an existing permanent home
   keygen token shared with the correspondent node.  This is
   accomplished, as before, by adding to the message one or more CGA
   Parameters options and a Signature option.

   The authenticator for the Binding Update message is calculated based
   on a permanent or temporary home keygen token.  Which type of home
   keygen token the mobile node uses in calculating the authenticator
   depends on the authentication method:

   o  If the Binding Update message is to be authenticated based on the
      CGA property of the mobile node's home address, the mobile node
      MUST use a temporary home keygen token from the correspondent
      node.  The mobile node may already have a valid temporary home
      keygen token in its Binding Update List entry for the
      correspondent node, or it may retrieve one through the exchange of
      a Home Test Init message and a Home Test message.

Top      Up      ToC       Page 14 
   o  If the Binding Update message is to be authenticated by a proof of
      the mobile node's knowledge of a permanent home keygen token, the
      mobile node MUST use the permanent home keygen token that is has
      in its Binding Update List entry for the correspondent node.

   o  If the Binding Update message is to be authenticated through a
      proof of reachability at the home address, the mobile node MUST
      use a temporary home keygen token from the correspondent node.  As
      before, the mobile node may already have a valid temporary home
      keygen token in its Binding Update List entry for the
      correspondent node, or it may retrieve one through the exchange of
      a Home Test Init message and a Home Test message.

   Unless the purpose of the Binding Update message is to delete an
   existing binding at the correspondent node, the authenticator is also
   calculated based on a care-of keygen token.  The mobile node selects
   this as follows:

   o  If the mobile node has a valid care-of keygen token for the to-be-
      registered care-of address in its Binding Update List entry for
      the correspondent node, the mobile node MUST use this in
      calculating the authenticator for the Binding Update message.  The
      Binding Update message is in this case "complete".

   o  If the mobile node does not have a valid care-of keygen token in
      its Binding Update List entry for the correspondent node, the
      mobile node SHOULD define the care-of keygen token to be zero and
      use this in calculating the authenticator for the Binding Update
      message.  The Binding Update message is in this case "early".

   o  If the mobile node does not have a valid care-of keygen token in
      its Binding Update List entry for the correspondent node, the
      mobile node MAY choose to retrieve a care-of keygen token through
      the exchange of a Care-of Test Init message and a Care-of Test
      message, as defined in [1], without sending an early Binding
      Update message.  In this case, the mobile node waits for receipt
      of the Care-of Test message and uses the care-of
      keygen token contained therein in calculating the authenticator
      for a complete Binding Update message.  This approach increases
      the handoff latency, however, and is therefore NOT RECOMMENDED.

   For reduced handoff delays, the mobile node SHOULD simultaneously
   initiate home and correspondent registrations for a particular
   care-of address.  The mobile node SHOULD also pursue home and
   correspondent deregistrations in parallel if it wishes to discontinue
   Mobile IPv6 service while away from its home link.  However, when the
   mobile node commits home and correspondent deregistrations after
   returning back to the home link after a period of roaming, the mobile

Top      Up      ToC       Page 15 
   node MUST initiate the home deregistration first, and it MUST wait
   for a Binding Acknowledgment message indicating a successful home
   deregistration before it initiates the correspondent deregistration.
   This behavior ensures that the home agent does not proxy the mobile
   node's home address while the mobile node is on the home link, hence
   preventing interference between the mobile node and the home agent
   during Duplicate Address Detection.  Since a home deregistration
   consumes only a link-local round-trip time when the mobile node
   pursues it from the home link, the cost of not parallelizing it with
   a correspondent deregistration, in terms of increased handoff delay,
   is typically negligible.

   Moreover, when the Binding Update message for the correspondent
   registration is to be authenticated based on the CGA property of the
   mobile node's home address or through a proof of reachability at the
   home address, the mobile node SHOULD initiate the exchange of Home
   Test Init and Home Test messages prior to handoff in order to
   proactively elicit a fresh home keygen token from the correspondent
   node.  This reduces handoff delays further.  A Home Test Init message
   may be sent periodically whenever the home keygen token previously
   acquired from the correspondent node is about to expire.  Tokens are
   valid for 3.5 minutes [1], so the interval between successive Home
   Test Init messages should be a little less.  Alternatively, the
   mobile node may be able to send the Home Test Init message right in
   time if its link layer provides a trigger announcing imminent
   handoff.  Proactive home address tests are technically feasible
   because a home address does not change across handoffs.

   If the mobile node initiates the home address test from the home
   link, it MUST address the Home Test Init message directly to the
   correspondent node.  The Home Test message will then be received
   directly from the correspondent node.  If the home address test is
   initiated from a visited link, the mobile node MUST tunnel the Home
   Test Init message to the home agent.  The Home Test message will then
   be tunneled back to the mobile node by the home agent.  A home
   address test SHOULD NOT overlap with a home registration or home
   deregistration since this could result in the loss of the Home Test
   Init or Home Test message.

   If the Binding Update message is early, the mobile node MUST add a
   Care-of Test Init option (see Section 5.4) to the message, requesting
   the correspondent node to return a new care-of keygen token.  The
   Care-of Test Init option MUST follow the CGA Parameters and Signature
   options, if those exist in the Binding Update message.  Once a
   responding Binding Acknowledgment message with a Care-of Test option
   (see Section 5.5) is received, the mobile node MUST use the care-of

Top      Up      ToC       Page 16 
   keygen token contained therein in calculating the authenticator for a
   complete Binding Update message and send this message to the
   correspondent node.

   If the Binding Update message is authenticated based on the CGA
   property of the mobile node's home address, the mobile node MAY add a
   CGA Parameters Request option (see Section 5.6) to the Binding Update
   message so as to request the correspondent node to prove ownership of
   its IP address within the Binding Acknowledgment message.  This
   ownership proof enables the mobile node to verify that the permanent
   home keygen token returned in the Binding Acknowledgment message was
   generated by the right correspondent node.

   The mobile node includes the nonce indices associated with the
   selected home and care-of keygen tokens in the Binding Update message
   using a Nonce Indices option [1].  The home nonce index is thereby
   determined as follows:

   o  If the Binding Update message is to be authenticated based on the
      CGA property of the mobile node's home address, the mobile node
      uses a temporary home keygen token to calculate the authenticator
      for the Binding Update message, and the associated home nonce
      index MUST be taken from the Home Test message with which the home
      keygen token was obtained.

   o  If the Binding Update message is to be authenticated by a proof of
      the mobile node's knowledge of a permanent home keygen token, the
      home nonce index MUST be set to zero.

   o  If the Binding Update message is to be authenticated through a
      proof of the mobile node's reachability at the home address, the
      mobile node uses a temporary home keygen token to calculate the
      authenticator for the Binding Update message, and the associated
      home nonce index MUST be taken from the Home Test message with
      which the home keygen token was obtained.

   The care-of nonce index is determined according to the following
   rules:

   o  If the Binding Update message is complete, the care-of nonce index
      is taken from the Care-of Test option or Care-of Test message with
      which the care-of keygen token (used to calculate the
      authenticator for the Binding Update message) was obtained.

   o  If the Binding Update message is early, the care-of nonce index
      MUST be set to zero.

Top      Up      ToC       Page 17 
   o  If the purpose of the Binding Update message is to delete a
      binding at the correspondent node, the care-of nonce index MUST be
      set to zero.

   The Nonce Indices option follows the CGA Parameters, Signature,
   Care-of Test Init, and CGA Parameters Request options if those are
   included in the Binding Update message as well.

   The mobile node finally calculates an authenticator for the Binding
   Update message based on the selected home and care-of keygen tokens,
   following the rules described in Section 5.2 and Section 6.2.7 of
   [1].  For a Binding Update message that requests the deletion of an
   existing binding at the correspondent node, the authenticator is
   calculated based on only a home keygen token, and it does not
   incorporate a care-of keygen token.  The authenticator is placed into
   the Authenticator field of a Binding Authorization Data option [1],
   which the mobile node adds to the Binding Update message as the last
   option.

     Mobile node               Home agent           Correspondent node
         |                         |                         |
         |                         |                         |
         ~ Handoff                 |                         |
         |                         |                         |
         |-Binding Update--------->|                         |
         |-Care-of Test Init-------------------------------->|
         |                         |                         |
         |                         |                         |
         |<------------Binding Ack-|                         |
         |<-------------------------------------Care-of Test-|
         |                         |                         |
         |                         |                         |
         |-Binding Update----------------------------------->|
         |                         |                         |
         |                         |                         |
         |<--------------------------------------Binding Ack-|
         |                         |                         |

    Figure 3: Correspondent registration with authentication by a proof
     of the mobile node's knowledge of a permanent home keygen token;
                       explicit care-of address test

   The time-sequence diagrams in Figure 1 through Figure 3 illustrate
   the operation of Enhanced Route Optimization based on a few selected
   message exchanges.  Figure 1 shows the messages exchanged for a
   correspondent registration where an early Binding Update message is
   authenticated by a proof of the mobile node's knowledge of a
   permanent home keygen token.  A Care-of Test Init option in the early

Top      Up      ToC       Page 18 
   Binding Update message requests the correspondent node to add to the
   Binding Acknowledgment message a fresh care-of keygen token in a
   Care-of Test option.  The mobile node finally concludes the
   correspondent registration with a complete Binding Update message.
   Figure 2 shows the procedure of a correspondent registration where
   the Binding Update message is authenticated with a proof of
   reachability at the home address.  The home address test is
   proactively performed prior to handoff, permitting the mobile node to
   issue a Binding Update message directly after the handoff.  The
   Binding Update message is again early, and a care-of keygen token is
   delivered to the mobile node along with the Binding Acknowledgment
   message.  Figure 3 depicts a correspondent registration where the
   mobile node initially obtains a fresh care-of keygen token through
   the dedicated exchange of Care-of Test Init and Care-of Test
   messages.  It subsequently issues a complete Binding Update message
   that is authenticated with the CGA property of the home address.

4.2.  Receiving Binding Update Messages

   When the correspondent node receives a Binding Update message, it
   must first verify whether the sending mobile node is the legitimate
   owner of the home address specified in the message.  The
   correspondent node selects the authentication method based on the
   home nonce index given in the Nonce Indices option of the Binding
   Update message, and on the existence of CGA Parameters and Signature
   options in the Binding Update message:

   o  If the home nonce index is set to a non-null value and the Binding
      Update message includes one or more CGA Parameters options
      followed by a Signature option, the correspondent node MUST
      authenticate the Binding Update message based on the CGA property
      of the mobile node's home address.

   o  If the home nonce index is zero and the Binding Update message
      does not include one or more CGA Parameters options followed by a
      Signature option, the correspondent node MUST authenticate the
      Binding Update message by a proof of the mobile node's knowledge
      of a permanent home keygen token.

   o  If the home nonce index is set to a non-null value and the Binding
      Update message does not include one or more CGA Parameters options
      followed by a Signature option, the correspondent node MUST
      authenticate the Binding Update message through a proof of the
      mobile node's reachability at the home address.

Top      Up      ToC       Page 19 
   In addition to the validation procedure for Binding Update messages
   specified in [1], the correspondent node must take the following
   additional steps to reject Binding Update messages that are
   inappropriately authenticated:

   o  If the Binding Update message includes one or more CGA Parameters
      options followed by a Signature option and the home nonce index is
      zero, the correspondent node MUST send a Binding Acknowledgment
      message with status code 150 ("Non-null home nonce index
      expected").  This ensures that a Binding Update message that is
      authenticated based on the CGA property of the mobile node's home
      address must also provide a proof of the mobile node's
      reachability at the home address.

   o  If the Binding Update message is to be authenticated by a proof of
      the mobile node's knowledge of a permanent home keygen token, the
      correspondent node MUST verify that it has a Binding Cache entry
      for the mobile node that includes a permanent home keygen token.
      In case the correspondent node does not have a Binding Cache entry
      for the mobile node, or if the existing Binding Cache entry for
      the mobile node does not include a permanent home keygen token,
      the correspondent node MUST reject the Binding Update message by
      sending a Binding Acknowledgment message with status code 147
      ("Permanent home keygen token unavailable").

   o  If the Binding Update message is to be authenticated through a
      proof of the mobile node's reachability at the home address, the
      correspondent node MUST verify that it does not have a permanent
      home keygen token in its Binding Cache entry for the mobile node.
      If the correspondent node has a permanent home keygen token in its
      Binding Cache entry for the mobile node, it MUST reject the
      Binding Update message by sending a Binding Acknowledgment message
      with status code 149 ("Permanent home keygen token exists").  This
      ensures that an attacker cannot downgrade the authentication
      method to hijack the binding of a legitimate mobile node.

   The authenticator for the Binding Update message is calculated based
   on a permanent or temporary home keygen token.  Which type of home
   keygen token the correspondent node uses in validating the
   authenticator, and how it retrieves or recomputes the home keygen
   token, depends on the authentication method:

   o  If the Binding Update message is to be authenticated based on the
      CGA property of the mobile node's home address, the correspondent
      node MUST recompute the temporary home keygen token defined by the
      (non-null) home nonce index in the Nonce Indices option of the
      Binding Update message, and it MUST use this recomputed token in
      validating the authenticator of the message.

Top      Up      ToC       Page 20 
   o  If the Binding Update message is to be authenticated by a proof of
      the mobile node's knowledge of a permanent home keygen token, the
      correspondent node MUST use the permanent home keygen token that
      it has in its Binding Cache entry for the mobile node in
      validating the authenticator of the Binding Update message.

   o  If the Binding Update message is to be authenticated through
      verification of the mobile node's reachability at the home
      address, the correspondent node MUST recompute the temporary home
      keygen token defined by the (non-null) home nonce index in the
      Nonce Indices option of the Binding Update message, and it MUST
      use this recomputed token in validating the authenticator of the
      message.

   Unless the purpose of the Binding Update message is to delete an
   existing binding at the correspondent node, the authenticator is also
   calculated based on a care-of keygen token.  Which care-of keygen
   token the correspondent node uses in validating the authenticator
   depends on whether the Binding Update message is complete or early:

   o  If the care-of nonce index in the Nonce Indices option of the
      Binding Update message is set to a non-null value, the Binding
      Update message is complete.  In this case, the correspondent node
      MUST recompute the care-of keygen token that is identified by the
      care-of nonce index, and it MUST use this recomputed token in
      validating the authenticator of the message.

   o  If the care-of nonce index in the Nonce Indices option of the
      Binding Update message is zero, the Binding Update message is
      early.  The care-of keygen token to be used by the correspondent
      node in validating the authenticator of the Binding Update message
      is zero in this case.

   The correspondent node finally validates the authenticator in the
   Binding Update message based on the selected home and care-of keygen
   tokens, following the algorithm described in Section 9.5.1 of [1].

   If the validation fails, the correspondent node MUST discard the
   Binding Update message.  The correspondent node may have to send a
   Binding Acknowledgment message with a status code indicating the
   failure, as described in [1].

   Provided that the validation of the authenticator in the Binding
   Update message succeeds, the correspondent node registers the mobile
   node's new care-of address, either updating an existing Binding Cache
   entry, if one exists, or creating a new Binding Cache entry.  The
   lifetime granted for the binding depends on the lifetime requested by
   the mobile node in the Lifetime field of the Binding Update message

Top      Up      ToC       Page 21 
   and the method by which the Binding Update message is authenticated.
   If the Binding Update message is authenticated based on the CGA
   property of the mobile node's home address or by a proof of the
   mobile node's knowledge of a permanent home keygen token, the
   lifetime for the binding SHOULD be set to the maximum of
   MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime
   field of the Binding Update message.  If the Binding Update message
   is authenticated through a proof of the mobile node's reachability at
   the home address, then the lifetime for the binding SHOULD be set to
   the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in
   the Lifetime field of the Binding Update message.  The correspondent
   node may in either case grant a further reduced lifetime, but it MUST
   NOT accept a higher lifetime.

   The state of the new care-of address depends on whether the Binding
   Update message is complete or early:

   o  If the Binding Update message is complete, the new care-of address
      is set to VERIFIED state.  The correspondent node may then
      immediately send packets to the new care-of address without
      restrictions.

   o  If the Binding Update message is early, the new care-of address is
      set to UNVERIFIED state.  The correspondent node MUST then follow
      the rules defined in Section 4.10 for sending packets to this
      care-of address until the care-of address is set in VERIFIED
      state.

   If the Binding Update message contains one or multiple CGA Parameters
   options, the mobile node is requesting the correspondent node to
   accept the included CGA parameters either for establishing a new, or
   for renewing an existing permanent home keygen token shared between
   the mobile node and the correspondent node.  The correspondent node
   MUST in this case check if the CGA Parameters options are directly
   followed by a Signature option and, if so, validate the CGA
   parameters and signature as described in Section 4.6.

   If the CGA Parameters option is not directly followed by a Signature
   option, or the validation of the included CGA parameters and
   signature fails, the correspondent node MUST discard the Binding
   Update message and send a Binding Acknowledgment message with status
   code 148 ("CGA and signature verification failed") to the mobile
   node.

   Provided that the signature included in the Signature option is
   correct, the correspondent node generates a permanent home keygen
   token to be shared with the mobile node and stores it in its Binding
   Cache entry for the mobile node.  The permanent home keygen token is

Top      Up      ToC       Page 22 
   sent to the mobile node within a Binding Acknowledgment message as
   described in Section 4.3.

4.3.  Sending Binding Acknowledgment Messages

   Upon receipt of a valid Binding Update message, the correspondent
   node returns to the mobile node a Binding Acknowledgment message in
   any of the following cases:

   o  The Acknowledge flag in the Binding Update message is set.

   o  The Binding Update message contains one or multiple CGA Parameters
      options directly followed by a Signature option, and the signature
      included in the latter was determined to be correct.

   o  The Binding Update message is early and includes a Care-of Test
      Init option.

   If the Binding Update message further contains a CGA Parameters
   Request option and the correspondent node's IP address is a CGA, the
   correspondent node MUST include its CGA parameters and signature in
   the Binding Acknowledgment message by adding one or more CGA
   Parameters options directly followed by a Signature option.  The
   correspondent node's CGA parameters and signature enable the mobile
   node to verify that the permanent home keygen token received in the
   Binding Acknowledgment message was generated by the right
   correspondent node.  If the Binding Update message contains a CGA
   Parameters Request option, but the correspondent node's IP address is
   not a CGA, the correspondent node ignores the CGA Parameters Request
   option and processes the Binding Update message further as described
   below.

   If the Binding Update message contains one or multiple CGA Parameters
   options directly followed by a Signature option, and the signature
   included in the latter was determined to be correct, the
   correspondent node MUST add a Permanent Home Keygen Token option (see
   Section 5.3) with a new permanent home keygen token to the Binding
   Acknowledgment message.  The correspondent node also stores this
   permanent home keygen token in its Binding Cache entry for the mobile
   node.

   If the Binding Update message includes a Care-of Test Init option,
   the correspondent node MUST append to the Binding Acknowledgment
   message a Care-of Test option with a pseudo-random value in the
   Care-of Keygen Token field.  The Care-of Test option MUST appear
   after the Permanent Home Keygen Token option in case both options are
   present in the Binding Acknowledgment message.

Top      Up      ToC       Page 23 
   A Binding Authorization Data option must be added to the Binding
   Acknowledgment message as a last option, as described in Section 5.2
   and Section 6.2.7 of [1].

4.4.  Receiving Binding Acknowledgment Messages

   A mobile node first verifies a received Binding Acknowledgment
   message according to the rules specified in [1].  Provided that the
   Binding Acknowledgment message is not rejected based on these rules,
   the mobile node takes the following additional steps.

   If the mobile node included a CGA Parameters Request option in the
   Binding Update message and the Binding Acknowledgment message
   contains a Permanent Home Keygen Token option, the mobile node first
   processes any CGA Parameters and Signature options in the Binding
   Acknowledgment message in the following manner.  If the Binding
   Acknowledgment message contains one or more CGA Parameters options
   that are directly followed by a Signature option, the mobile node
   MUST check the ownership of the correspondent node's IP address by
   verifying the included CGA parameters and signature as described in
   Section 4.6.  If the validation of the CGA parameters and signature
   fails, the mobile node MUST silently discard the Binding
   Acknowledgment message.  The mobile node MUST also silently discard
   the Binding Acknowledgment message if the message includes one or
   more CGA Parameters options that are not directly followed by a
   Signature option, or if the Binding Acknowledgment message lacks any
   CGA Parameters options in the presence of a Signature option.

   If the mobile node did not include a CGA Parameters Request option in
   the Binding Update message or the Binding Acknowledgment message does
   not contain a Permanent Home Keygen Token option, the mobile node
   ignores any CGA Parameters and Signature options that the Binding
   Acknowledgment message may contain.  Careful use of the CGA
   Parameters Request option in Binding Update messages enables the
   mobile node to control the processing resources it spends on the
   verification of a correspondent node's CGA as well as to disable such
   verification in the case of persistent verification failures, which
   may be due to misconfigured or outdated CGA software [12] on the
   correspondent node side or at the mobile node itself.  Specifically,
   if the mobile node repeatedly fails to receive a Binding
   Acknowledgment message including valid CGA Parameters and Signature
   options in response to sending a Binding Update message with a CGA
   Parameters Request option, the mobile node SHOULD refrain from
   including a CGA Parameters Request option in future Binding Update
   messages for the same correspondent node.

Top      Up      ToC       Page 24 
   If the mobile node included a CGA Parameters Request option in the
   Binding Update message, but the Binding Acknowledgment message does
   not contain any CGA Parameters or Signature options, the mobile node
   cannot be sure if the correspondent node's IP address is simply not a
   CGA, or if the Binding Acknowledgment message originates from an
   attacker on the path from the mobile node to the correspondent node.
   To avoid accepting a permanent home keygen token from an on-path
   attacker, the mobile node MUST give precedence to Binding
   Acknowledgment messages that include valid CGA Parameters and
   Signature options over Binding Acknowledgment messages without such
   options.  One possible algorithm for the mobile node to follow in
   this regard is to always accept the Binding Acknowledgment message
   received first, and if this message does not contain valid CGA
   Parameters or Signature options and another Binding Acknowledgment
   message including such options is received later on, to revert any
   state changes involved in accepting the first Binding Acknowledgment
   in favor of this subsequent Binding Acknowledgment message.  Giving
   precedence to Binding Acknowledgment messages with valid CGA
   Parameters and Signature options over Binding Acknowledgment messages
   without such options enables the mobile node to communicate with
   correspondent nodes that do not use a CGA, and at the same time
   protects against most on-path attackers.  The strategy does not
   protect against an attacker that can intercept Binding Acknowledgment
   messages from the correspondent node, but such an attacker could
   preclude mobility management between the mobile node and the
   correspondent node anyway.  When the mobile node has permanently
   accepted a Binding Acknowledgment message without valid CGA
   Parameters and Signature options, the mobile node SHOULD refrain from
   including a CGA Parameters Request option in future Binding Update
   messages for the same correspondent node.

   If the Binding Acknowledgment message contains a Permanent Home
   Keygen Token option, the mobile node extracts the permanent home
   keygen token included in this option and stores it in its Binding
   Update List entry for the correspondent node.  Future Binding Update
   messages will then be authenticated by a proof of the mobile node's
   knowledge of this permanent home keygen token.

   If the Binding Acknowledgment message contains a Care-of Test option,
   the mobile node extracts the care-of keygen token included in this
   option, stores the token in its Binding Update List entry for the
   correspondent node, and sends the correspondent node a complete
   Binding Update message as defined in Section 4.1.  Note that the
   complete Binding Update message will be authenticated based on the
   CGA property of the mobile node's home address if the Binding
   Acknowledgment message also includes a Permanent Home Keygen Token
   option.  This is independent of the authentication method that was
   used for the corresponding early Binding Update message.

Top      Up      ToC       Page 25 
   A mobile node MUST ensure that, while it has a binding for a certain
   home address at a correspondent node, it also has a valid binding at
   its home agent for the same home address.  This may at times require
   the mobile node to extend the binding lifetime at the home agent,
   request a correspondent node to use a binding lifetime less than the
   permitted maximum, or explicitly deregister an existing binding at a
   correspondent node.

   If the mobile node authenticates Binding Update messages for a
   particular correspondent node by proving its knowledge of a permanent
   home keygen token, but registrations at this correspondent node
   persistently fail, the mobile node SHOULD renew the permanent home
   keygen token by sending a Binding Update message that is
   authenticated based on the CGA property of its home address.  This
   Binding Update message includes the mobile node's CGA parameters and
   signature, and it requests the correspondent node to generate a new
   permanent home keygen token and send this to the mobile node within a
   Binding Acknowledgment message.

   If the mobile node persistently receives Binding Acknowledgment
   messages with status code 148 ("CGA and signature verification
   failed") from a correspondent node, the mobile node SHOULD
   authenticate future Binding Update messages for the same
   correspondent nodes through a proof of its reachability at the home
   address.  This enables the mobile node to recover from misconfigured
   or outdated CGA software [12] on the correspondent node side or at
   the mobile node itself.

4.5.  Sending CGA Parameters

   A mobile node includes its CGA parameters and signature in a Binding
   Update message for a correspondent node in any of the following
   situations:

   o  To acquire a permanent home keygen token if the mobile node's home
      address is a CGA, and the mobile node does not yet have a
      permanent home keygen token from the correspondent node.

   o  To extend the lifetime of an existing binding if the mobile node
      already has a permanent home keygen token from the correspondent
      node, and the lifetime of the binding at the correspondent node is
      about to expire.

   o  To renew an existing permanent home keygen token to prevent replay
      attacks in the imminent event of a sequence number rollover, or
      for improved protection against cryptanalysis.

Top      Up      ToC       Page 26 
   A correspondent node whose IP address is a CGA includes its CGA
   parameters and signature in a Binding Acknowledgment message for the
   mobile node when it receives a Binding Update message with a CGA
   Parameters Request option.

   CGA parameters are transmitted in the format of the CGA Parameters
   data structure defined in [2].  The CGA Parameters data structure is
   split over one or more CGA Parameters options as described in
   Section 5.1.  The last CGA Parameters option MUST be directly
   followed by a Signature option.

   The value for the Signature field in the Signature option is
   calculated according to the signature generation algorithm defined in
   Section 6 of [2].  The value is calculated with the mobile or
   correspondent node's private key over the following sequence of
   octets:

      mobility data =
         care-of address | correspondent node IP address | MH data

   where "|" denotes concatenation.  "Care-of address" is the mobile
   node's care-of address, and "correspondent node IP address" is the IP
   address of the correspondent node that is visible to protocol layers
   above IP.  In case the correspondent node is mobile, "correspondent
   node IP address" refers to the correspondent node's home address.
   "MH data" is the content of the Binding Update or Binding
   Acknowledgment message including the mobility header and all options
   up to the last CGA Parameters option.  That is, "MH data" excludes
   the IPv6 header and any IPv6 extension headers other than the
   mobility header itself.  The "mobility data" constitutes what is
   referred to as the "message" in Section 6 of [2].

   The value for the Signature field is calculated as if the Checksum
   field in the mobility header was zero.  The Checksum field in the
   transmitted packet is still calculated in the usual manner, with the
   calculated value in the Signature field being a part of the packet
   protected by the checksum.

4.6.  Receiving CGA Parameters

   Mobile and correspondent nodes that receive a Binding Update or
   Binding Acknowledgment message including one or more CGA Parameters
   options directly followed by a Signature option first process the
   message as described in [1].  This includes a verification of the
   authenticator in the Authenticator field of the Binding Authorization
   Data option.  If the Binding Update or Binding Acknowledgment message
   is rejected due to an incorrect authenticator or for any other
   reason, the message is not processed further.

Top      Up      ToC       Page 27 
   Otherwise, if the validation of the Binding Update or Binding
   Acknowledgment message succeeds, the mobile or correspondent node
   reassembles the CGA Parameters data structure from the CGA Parameters
   options included in the message as described in Section 5.1, and
   executes the CGA verification algorithm defined in Section 5 of [2].
   The CGA verification algorithm takes the to-be-verified CGA and the
   reassembled CGA Parameters data structure as input.  The to-be-
   verified CGA is the mobile node's home address when the CGA
   verification algorithm is executed by the correspondent node.  When
   the mobile node executes the CGA verification algorithm, the to-be-
   verified CGA is the correspondent node's IP address that is visible
   to protocol layers above IP.  This is the correspondent node's home
   address in case the correspondent node is mobile.  The following
   steps are skipped if the CGA verification fails.

   If the CGA verification succeeds, the mobile or correspondent node
   performs a more time-consuming check of the signature.  It extracts
   the signature from the Signature field in the Signature option and
   executes the signature verification algorithm defined in Section 6 of
   [2].  The signature verification algorithm takes as input the to-be-
   verified CGA as defined above, the reassembled CGA Parameters data
   structure, the MH data as defined in Section 4.5, the CGA Message
   Type tag of Enhanced Route Optimization as defined in Section 7, and
   the signature itself.

4.7.  Sending Permanent Home Keygen Tokens

   A correspondent node assigns a mobile node a new permanent home
   keygen token after it has received from the mobile node a Binding
   Update message with included CGA Parameters and Signature options,
   and these options have been successfully validated as described in
   Section 4.6.  The permanent home keygen token is a 64-bit value
   randomly generated by the correspondent node.  The correspondent node
   stores the permanent home keygen token in the binding cache entry
   that it maintains for the mobile node.

   The correspondent node sends the permanent home keygen token to the
   mobile node in encrypted form within a Permanent Home Keygen Token
   option in a Binding Acknowledgment message.  It sends this message
   even if the Acknowledge flag in the corresponding Binding Update
   message was clear.  The correspondent node encrypts the permanent
   home keygen token with the mobile node's public key using the
   RSAES-PKCS1-v1_5 format [4], and places the ciphertext into the
   Permanent Home Keygen Token field of the Permanent Home Keygen Token
   option.

   The Binding Authorization Data option MUST be the last option in the
   Binding Acknowledgment message.  That is, the authenticator in the

Top      Up      ToC       Page 28 
   Binding Authorization Data option covers the Permanent Home Keygen
   Token option.

4.8.  Receiving Permanent Home Keygen Tokens

   A mobile node that receives a Binding Acknowledgment message first
   processes the message as described in [1], independent of whether the
   message includes a Permanent Home Keygen Token option.  This includes
   a verification of the authenticator in the Authenticator field of the
   Binding Authorization Data option.  If the Binding Acknowledgment
   message is rejected due to an incorrect authenticator or for any
   other reason, the mobile node does not process the message further.

   Otherwise, if the mobile node accepts the Binding Acknowledgment
   message and the message includes a Permanent Home Keygen Token
   option, the mobile node extracts the ciphertext from the Permanent
   Home Keygen Token field in this option and decrypts it with its
   private key using the RSAES-PKCS1-v1_5 format [4].  The result of the
   encryption is the permanent home keygen token to be used in further
   registrations with the correspondent node.  The mobile node stores
   the permanent home keygen token in the Binding Update List entry that
   it maintains for the correspondent node.

4.9.  Renewing Permanent Home Keygen Tokens

   A mobile node that shares a permanent home keygen token with a
   correspondent node MUST NOT use the same sequence number twice with
   this permanent home keygen token in order to protect against replay
   attacks.  The mobile node MUST renew the permanent home keygen token
   by including its CGA parameters and signature in a Binding Update
   message for the correspondent node when a sequence number rollover is
   imminent.  In addition, the mobile node MAY renew its permanent home
   keygen token at any time.  Periodic renewal of the permanent home
   keygen token provides increased protection against cryptanalysis.
   Finally, the mobile node may in most cases want to renew the
   permanent home keygen token when the lifetime of its binding at the
   correspondent node expires.

4.10.  Handling Payload Packets

   The immediate exchange of an early Binding Update message after a
   handoff on the mobile node side enables mobile and correspondent
   nodes to quickly reestablish route-optimized communications via the
   mobile node's new care-of address.  The mobile node may send payload
   packets to the correspondent node from the new care-of address as
   soon as it has dispatched the early Binding Update message.  The
   correspondent node redirects outgoing payload packets for the mobile
   node to the new care-of address once it has received the early

Top      Up      ToC       Page 29 
   Binding Update message and registered the new care-of address.  Here,
   a "payload packet" is defined as a packet that originates at a
   protocol layer above IP.

           Inbound
        payload packet
              |
              |
              V
      _________________                           _____________________
     /                 \                         |                     |
    /  Care-of address  \     Yes                |   Increase credit   |
   |         in          |---------------------> |     counter by      |
    \  VERIFIED state?  /                        | payload packet size |
     \_________________/                         |_____________________|
              |                                             |
              |                                             |
              | No                                          |
              |                                             V
              |                                   _____________________
              |                                  |                     |
              |                                  |   Deliver payload   |
              +--------------------------------> |   packet to upper-  |
                                                 |    layer protocol   |
                                                 |_____________________|

                Figure 4: Handling outbound payload packets

   A new care-of address that was registered with an early Binding
   Update message is maintained in UNVERIFIED state by the correspondent
   node until the correspondent node receives a complete Binding Update
   message from the mobile node.  The correspondent node then sets the
   care-of address to VERIFIED state.  The state of the care-of address
   determines the maximum amount of data that the correspondent node is
   allowed to send to the care-of address, as is necessary to prevent
   amplified, redirection-based flooding attacks.  For this purpose, the
   correspondent node maintains a "credit counter" for each mobile node
   with an entry in its Binding Cache.  Whenever a payload packet
   arrives from a mobile node with a care-of address in VERIFIED state,
   the correspondent node SHOULD increase the mobile node's credit
   counter by the size of the received payload packet.  The
   correspondent node MAY be restricted by policy to increase the credit
   counter by a lower value or not to increase the credit at all.  The
   credit counter does not change when an inbound payload packet is
   received from a care-of address in UNVERIFIED state.  Figure 4 shows
   a flow chart of this procedure.

Top      Up      ToC       Page 30 
           Outbound
        payload packet
              |
              |
              V
      _________________                           _____________________
     /                 \                         |                     |
    /  Care-of address  \     Yes                |    Send payload     |
   |         in          |---------------------> |      packet to      |
    \  VERIFIED state?  /                        |   care-of address   |
     \_________________/                         |_____________________|
              |
              |                                   _____________________
              | No                               |                     |
              |                                  |   Discard payload   |
              |                      +---------> |        packet       |
              |                      |           |     immediately     |
              V                      |           |_____________________|
      _________________              |            _____________________
     /                 \             |           |                     |
    /  Credit counter   \   Yes     / \          |    Send payload     |
   |  less than payload  |-------> |   |-------> |      packet to      |
    \   packet size?    /           \ /          |    home address     |
     \_________________/             |           |_____________________|
              |                      |            _____________________
              |                      |           |                     |
              | No                   |           |   Buffer payload    |
              |                      +---------> |     packet for      |
              |                                  | later transmission  |
              |                                  |_____________________|
              V
    _____________________                         _____________________
   |                     |                       |                     |
   |    Reduce credit    |                       |    Send payload     |
   |     counter by      |---------------------> |      packet to      |
   | payload packet size |                       |   care-of address   |
   |_____________________|                       |_____________________|

                Figure 5: Handling outbound payload packets

   When the correspondent node has a payload packet to send to the
   mobile node, further treatment of the payload packet depends on the
   state of the mobile node's care-of address and the current value of
   the mobile node's credit counter, as illustrated in Figure 5: The
   correspondent node MUST send the payload packet to the mobile node's
   care-of address if the care-of address is in VERIFIED state.  If the
   care-of address is in UNVERIFIED state and the value of the credit
   counter is higher than or equal to the size of the payload packet,

Top      Up      ToC       Page 31 
   the correspondent node MUST reduce the mobile node's credit counter
   by the size of the payload packet and send the payload packet to the
   care-of address as well.  However, if the care-of address is in
   UNVERIFIED state and the credit counter is less than the size of the
   payload packet, the payload packet MUST NOT be sent to the mobile
   node's care-of address.  The correspondent node SHOULD then discard
   the payload packet, although it MAY alternatively buffer the payload
   packet until the care-of address moves to VERIFIED state, or send the
   payload packet to the mobile node's home address.  The credit counter
   of the mobile node does not change when the correspondent node sends
   a payload packet to the mobile node's care-of address while the
   care-of address is in VERIFIED state.

   The amount of data that the mobile node may send to the correspondent
   node is never restricted due to the state of the mobile node's
   care-of address.  The care-of address state also does not change the
   addressing and routing of payload packets in either traffic
   direction: All payload packets that originate from the mobile node
   have the care-of address in the Source Address field of the IPv6
   header and the home address in the Home Address option of the IPv6
   Destination Options extension header.  Vice versa, all payload
   packets from the correspondent node have the care-of address in the
   Destination Address field of the IPv6 header and the home address in
   the IPv6 Routing extension header.

4.11.  Credit Aging

   A correspondent node ensures that all credit counters that it
   maintains gradually decrease over time.  Each credit counter is
   multiplied with a factor, CreditAgingFactor, of less than one in
   fixed time intervals of CreditAgingInterval length.  Such "credit
   aging" limits the total credit that a mobile node can earn, provided
   that the replenishing rate for the credit is constant or nearly
   constant.  It thereby enforces an upper bound on the rate at which
   the correspondent node can durably sent to the mobile node's care-of
   address while the care-of address is in UNVERIFIED state.  In the
   absence of credit aging, a malicious node with poor up-link capacity
   could adopt the role of a mobile node, build up credit at a very slow
   speed and over a long period, and spend this credit during a much
   shorter period on redirecting a burst of payload packets to the IP
   address of a victim.

   Choosing appropriate values for CreditAgingFactor and
   CreditAgingInterval is important to facilitate applications where the
   correspondent node sends at a higher rate than the mobile node.  If
   CreditAgingFactor or CreditAgingInterval is too small, the credit
   counter might persistently prevent the transmission of payload
   packets to a care-of address in UNVERIFIED state.  The values given

Top      Up      ToC       Page 32 
   in Section 7 are RECOMMENDED as they work well when the correspondent
   node transfers a file to the mobile node via a TCP connection and the
   end-to-end round-trip time does not exceed 500 milliseconds.

4.12.  Simultaneous Movements

   As specified in [1], Binding Update messages are sent to a mobile
   correspondent node's home address.  This makes it possible for two
   mobile nodes to continue communications even if both of them change
   IP connectivity at the same time.



(page 32 continued on part 3)

Next RFC Part