[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-arkko-mipshop-cga-cba) 00 01 02 03 RFC 4866

Network Working Group                                           J. Arkko
Internet-Draft                              Ericsson Research NomadicLab
Expires: March 29, 2007                                          C. Vogt
                                             Universitaet Karlsruhe (TH)
                                                               W. Haddad
                                                       Ericsson Research
                                                      September 25, 2006


    Applying Cryptographically Generated Addresses and Credit-Based
                      Authorization to Mobile IPv6
                   draft-ietf-mipshop-cga-cba-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 29, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document proposes an enhanced security mechanism for Mobile IPv6
   route optimization, providing lower handoff delays, increased
   security, and reduced signaling overhead.




Arkko, et al.            Expires March 29, 2007                 [Page 1]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Objectives . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1  Handoff Latency  . . . . . . . . . . . . . . . . . . . . .   5
     2.2  Security . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3  Signaling Overhead . . . . . . . . . . . . . . . . . . . .   6
   3.   Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   7
   4.   Protocol Operation . . . . . . . . . . . . . . . . . . . . .   9
     4.1  Sending Binding Update Messages  . . . . . . . . . . . . .   9
     4.2  Receiving Binding Update Messages  . . . . . . . . . . . .  13
     4.3  Sending Binding Acknowledgment messages  . . . . . . . . .  15
     4.4  Receiving Binding Acknowledgment Messages  . . . . . . . .  16
     4.5  Sending CGA Parameters . . . . . . . . . . . . . . . . . .  16
     4.6  Receiving CGA Parameters . . . . . . . . . . . . . . . . .  18
     4.7  Sending Permanent Home Keygen Tokens . . . . . . . . . . .  19
     4.8  Receiving Permanent Home Keygen Tokens . . . . . . . . . .  19
     4.9  Handling Payload Packets . . . . . . . . . . . . . . . . .  20
     4.10   Credit Aging . . . . . . . . . . . . . . . . . . . . . .  22
     4.11   Simultaneous Movements . . . . . . . . . . . . . . . . .  22
   5.   Option Formats and Status Codes  . . . . . . . . . . . . . .  22
     5.1  CGA Parameters Option  . . . . . . . . . . . . . . . . . .  23
     5.2  Signature Option . . . . . . . . . . . . . . . . . . . . .  24
     5.3  Permanent Home Keygen Token Option . . . . . . . . . . . .  24
     5.4  Care-of Test Init Option . . . . . . . . . . . . . . . . .  25
     5.5  Care-of Test Option  . . . . . . . . . . . . . . . . . . .  26
     5.6  Status Codes . . . . . . . . . . . . . . . . . . . . . . .  26
   6.   Security Considerations  . . . . . . . . . . . . . . . . . .  27
     6.1  Home Address Ownership . . . . . . . . . . . . . . . . . .  28
     6.2  Care-of Address Ownership  . . . . . . . . . . . . . . . .  29
     6.3  Time Shifting Attacks  . . . . . . . . . . . . . . . . . .  31
     6.4  Replay Attacks . . . . . . . . . . . . . . . . . . . . . .  32
     6.5  Resource Exhaustion  . . . . . . . . . . . . . . . . . . .  33
     6.6  IP Address Ownership of Correspondent Node . . . . . . . .  33
   7.   Performance Considerations . . . . . . . . . . . . . . . . .  34
   8.   Protocol Constants . . . . . . . . . . . . . . . . . . . . .  34
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  35
   10.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . .  35
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  36
     11.1   Normative References . . . . . . . . . . . . . . . . . .  36
     11.2   Informative References . . . . . . . . . . . . . . . . .  36
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  38
   A.   Overview of CGA  . . . . . . . . . . . . . . . . . . . . . .  38
   B.   Overview of Credit-Based Authorization . . . . . . . . . . .  40
   C.   Change Log . . . . . . . . . . . . . . . . . . . . . . . . .  41
        Intellectual Property and Copyright Statements . . . . . . .  44





Arkko, et al.            Expires March 29, 2007                 [Page 2]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


1.  Introduction

   Mobile IPv6 route optimization [1] allows mobile nodes to communicate
   with correspondent nodes via a direct path in spite of changes in IP
   connectivity.  Route optimization reduces the latency of packet
   propagation to a minimum, in opposition to the default approach of
   routing all packets via a stationary home agent.  It was designed in
   an effort to accommodate real-time and interactive applications in
   the presence of IP mobility.

   Mobile and correspondent nodes use a stable "home address" in
   identifying the mobile node at stack layers above IP, while packets
   are sent or received via a "care-of address" that routes to the
   mobile node's current network attachment.  The Mobile IPv6 protocol
   swaps the IP addresses when a packet traverses the IP layer.  Both
   end nodes maintain a binding between the home address and the care-of
   address.  It is the mobile node's responsibility to update the
   binding at the correspondent node when it changes IP connectivity.

   From a security perspective, the request for a binding update
   requires a correspondent node to verify a mobile node's ownership of
   both the home and the care-of address.  Unprecedented attack
   possibilities [8] would arise if correspondent nodes took liberties
   with respect to these obligations:  An impersonator could claim a
   victim's IP address and request a correspondent node to bind this, as
   a home address, to its own care-of address.  The impersonator could
   then communicate on behalf of the victim.  A flooding attacker could
   use its own home address in combination with a care-of address that
   in fact would belong to a victim.  This victim would receive packets
   that should actually be routed to the attacker.

   A fundamental constraint for the security design of route
   optimization is that it must do without a pre-existing relationship
   between a mobile node and a correspondent node.  Reliance on a PKI is
   likewise assessed unsuitable given a number of intrinsic problems [9]
   that PKIs would entail in the context of mobility.  The default
   mechanism to authorize a binding update for a correspondent node is
   instead based on a preceding return routability procedure.  This
   allows the correspondent node to verify the mobile node's
   reachability at the home and care-of addresses in an ad-hoc, non-
   cryptographic manner.  Reachability at both IP addresses indicates
   (though it does not guarantee) the mobile node's ownership of the IP
   addresses, and hence that binding these IP addresses is secure.

   Unfortunately, the home and care-of address tests of the return
   routability procedure are still vulnerable to those impersonators and
   flooding attackers which can interpose in the respective test.  This
   may be considered acceptable for the care-of address test given that



Arkko, et al.            Expires March 29, 2007                 [Page 3]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   a flooding attacker capable of compromising the test would expose
   itself to the same packet flood that also befalls the victim.  Yet
   impersonation is a more intractable threat, which constitutes an
   obstacle for the deployment of route optimization.  Besides security-
   related drawbacks, performance-wise, both IP address tests have the
   disadvantage of increasing handoff delays.

   The protocol defined in this document amends Mobile IPv6 route
   optimization in two ways:  A mobile node's home address is secured
   against impersonation through an interface identifier that is
   cryptographically and verifiably bound to the mobile node's public/
   private-key pair.  The mobile node proves ownership of the home
   address by providing evidence that it knows the correct private key.
   An initial home address test confirms the home address prefix, but
   subsequent tests can be spared.  This alone would leave the latency
   of the care-of address test, so in addition, correspondent nodes
   allow this test to proceed in parallel with regular data traffic.  To
   preclude the threat of redirection-based flooding until the test
   succeeds, the amount of data sent to the care-of address is bound by
   a dynamically determined limit.  These two optional enhancements can
   be applied separately or, preferably, in conjunction.



2.  Objectives

   The design of Mobile IPv6 route optimization is in may ways
   conservative, leaving room to optimize handoff delay, security, and
   signaling overhead.  The protocol defined in this document tackles
   these issues and thus constitutes a more progressive variant of the
   base mobility protocol.

   In spite of any improvements in the mobility protocol, it is
   important to take into account that other mobility-related activities
   in the protocol stack may have their own impact, in particular on
   handoff delay.  E.g., attachment procedures, access control, and
   authentication at the link layer contribute their own delay.  So do
   IPv6 tasks such as router discovery, neighbor discovery, movement
   detection, and address configuration.  These other delays are in many
   cases significantly larger than the handoff delay of Mobile IPv6
   route optimization.  The protocol defined in this document
   concentrates on making the mobility signaling as efficient as
   possible, ignoring mobility-related functions elsewhere in the
   protocol stack.  The improvements that the protocol facilitates hence
   ought to be seen in view of the entire protocol stack.






Arkko, et al.            Expires March 29, 2007                 [Page 4]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


2.1  Handoff Latency

   The typical handoff delay in Mobile IPv6 route optimization is 1
   round-trip time between the mobile node and the home agent for the
   home registration, 1 round-trip time between the mobile node and the
   home agent plus 1 round-trip time between the home agent and the
   correspondent node for the return routability procedure, and 1 one-
   way time from the mobile node to the correspondent node for the
   propagation of the Binding Update message.  (The assumption here is
   that the latency of the return routability procedure is dominated by
   the home-address test.)  The first packet sent to the new care-of
   address requires 1 additional one-way time to propagate from the
   correspondent node to the mobile node.  The mobile node can resume
   transmissions right after it has dispatched the Binding Update
   message.  But if it requests a Binding Acknowledgment message from
   the correspondent node, communications are usually delayed until this
   is received.

   Handoff delays in Mobile IPv6 route optimization are additive to
   other delays at IP layer or link layer.  They can cause perceptible
   quality degradations for interactive and real-time applications.  TCP
   bulk-data transfers are likewise affected since long handoff
   latencies may lead to successive retransmission timeouts and degraded
   throughput [10].  This protocol eliminates the additional handoff
   delay induced by Mobile IPv6 route optimization for packets that a
   mobile node sends, and it reduces the delay to 1 round-trip time
   between the mobile node and the correspondent node for packets that
   the mobile node receives.


2.2  Security

   Given that mobile and correspondent nodes with support for Mobile
   IPv6 route optimization form a true subset of all Internet nodes, the
   security design of the mobility protocol cannot make the Internet any
   safer than it is without the mobility protocol.  The return
   routability procedure was therefore designed with the objective to
   provide a level of security which compares to that of today's non-
   mobile Internet [8].  As such, it protects against impersonation and
   denial of service that an insecure mobility protocol may be
   vulnerable to.  In particular, the return routability procedure
   satisfies the following key requirements for mobility protocols:

   o  An attacker should not be able to redirect a third node's
      communication flow to itself or to another IP address, at least
      not beyond what is already possible in plain IPv6.  This
      requirement applies both to ongoing and future communication
      flows.



Arkko, et al.            Expires March 29, 2007                 [Page 5]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   o  An attacker should not be able to redirect its own communication
      flows to a third party, flooding the victim with unrequested
      packets.  Such redirection-based flooding attack would provide
      substantial amplification that is today only possible through a
      network of compromised nodes [11].  E.g., an attacker could
      accomplish the initial TCP handshake for a voluminous file
      download through its own address (or home address, for that
      matter), and then redirect the flow to the address of its victim.
      The attacker could spoof acknowledgments on behalf of the victim
      based on the sequence numbers it learned from the initial
      handshake, but those would be small compared to the full-sized
      segments that the correspondent node generates.

   o  Attackers should not be able to cause denial-of-service through
      potentially expensive computations involved in the mobility
      protocol.

   Applications that require a higher security level than the return
   routability procedure can provide are generally advised to use end-
   to-end protection such as IPsec or TLS.  But even then are they
   vulnerable to denial of service.  Furthermore, these mechanisms
   either require end nodes to be preconfigured with credentials for
   mutual authentication, or they depend on a public-key infrastructure.
   Either approache impedes [9] wide deployment of Mobile IPv6 route
   optimization.  The protocol defined in this document permits end
   nodes to authenticate each other by means of a cryptographic property
   of their home addresses.  It neither depends on preconfiguration nor
   on a public-key infrastructure, and yet it conforms to the key
   requirements listed above.


2.3  Signaling Overhead

   A complete correspondent registration involves 6 message
   transmissions at the mobile node, totaling about 376 bytes (cf.
   [12]).  This signaling overhead may be acceptable if movements are
   infrequent.  E.g., a mobile node that moves once every 30 minutes
   generates an average of 1.7 bits/second of signaling traffic.  Higher
   mobility causes more serious overhead, however.  A cell size of 100
   meters and a speed of 120 km/h yields 1 movement every 3 seconds and
   about 1,000 bits/second of signaling traffic.  This compares to a
   highly compressed voice stream with a typical data rate of 10,000 to
   30,000 bits/second.  The protocol defined in this document introduces
   a new message exchange between mobile and correspondent nodes in
   order to accomplish the desired improvements in handoff delay.  The
   implied new signaling overhead is compensated for by verifying
   reachability of the care-of address in-band, sparing a separate
   message exchange.



Arkko, et al.            Expires March 29, 2007                 [Page 6]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   Standard Mobile IPv6 requires mobile nodes to renew a binding at a
   correspondent node at least every 7 minutes.  The signaling overhead
   amounts to 7.16 bits per second if the mobile node communicates with
   a stationary node [12].  It doubles if both peers are mobile.  This
   overhead may be negligible when the nodes communicate, but it can be
   an issue for mobile nodes that are inactive and stay at the same
   location for a while.  These nodes typically prefer to go to standby
   mode to conserve battery power.  Also, the periodic refreshments
   consume a fraction of the wireless bandwidth that one could use more
   efficiently.  The protocol defined in this document allows
   correspondent nodes to specify a binding lifetime much larger than 7
   minutes.  It thereby reduces the signaling overhead generated by
   mobile nodes that do not change their care-of address for a while.



3.  Protocol Design

   The protocol defined in this document applies a set of techniques in
   order to meet the objectives discussed in Section 2.  These are
   summarized in the following:

   Cryptographically generated home addresses

      A Mobile IPv6 binding is conceptually a packet redirection from a
      home address to a care-of address.  The home address is the source
      of the redirection, whereas the care-of address is the
      destination.  The packets to be redirected can hence be identified
      based on the home address.  This motivates a strong, cryptographic
      ownership proof for the home address.  The protocol defined in
      this document features this through the application of
      cryptographically generated home addresses [13][14].  In general,
      a cryptographically generated address [15] provides a strong,
      cryptographic binding between the interface identifier of the
      address and the address owner's public key.  This enables other
      nodes to securely authenticate the owner as such, modulo the
      correctness of the address prefix.  Cryptographically generated
      home addresses can supersede home address tests with the exeption
      of an initial test for validating the home address prefix.  This
      facilitates lower handoff delays as well as longer binding
      lifetimes and, consequently, reduced signaling overhead for nodes
      which temporarily do not move.

   Non-cryptographic care-of addresses

      In contrast to a home address, a care-of address does not have
      identifying functionality.  There is hence little benefit in a
      cryptographic ownership proof of a care-of address.  Given that



Arkko, et al.            Expires March 29, 2007                 [Page 7]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


      the care-of address is the destination of a packet redirection, it
      is rather the mobile node's reachability at the care-of address
      which matters.  The protocol defined in this document uses care-of
      address tests for this purpose, but allows correspondent nodes to
      send packets to a new care-of address already before the mobile
      node has been found to be reachable at the address.

   Semi-permanent security associations

      Cryptographically generated addresses involve public-key
      cryptography and are computationally inefficient to validate.
      Further, the technique requires a significant amount of
      supplementary data to be piggybacked onto protected messages.  The
      protocol defined in this document therefore leverages the
      cryptographic property of home addresses to securely exchange a
      secret shared key between a mobile node and a correspondent node
      [16].  This key is used to authenticate subsequent signaling
      messages efficiently.

   Initial home address tests

      An initial home address test is necessary in order to prevent
      redirection-based flooding attacks against an alleged home
      network.  Specifically, in the absence of a home address test, a
      malicious node can cryptographically generate a home address with
      the prefix of a targeted victim network, and register a binding
      between this spoofed home address and its own IP address at a
      correspondent node.  The attacker proceeds to request the
      correspondent node, which may be a public server, to send a stream
      of packets to its current location.  The attacker then de-
      registers the binding, or lets it expire, with the consequence of
      having the correspondent node redirect the packet stream "back" to
      the victim network.  The result is a flooding attack against the
      victim network.  To avoid such misuse, the initial home address
      test is executed at the same time as the semi-permanent security
      association is being established [16].  The test does not need to
      be repeated upon subsequent movements, however.

   Concurrent care-of address tests

      The protocol defined in this document allows a correspondent node
      to send packets to a new care-of address already before a proof of
      reachability at that address has been received from the mobile
      node.  Specifically, when the mobile node moves to a different
      link, it first registers its new care-of address without providing
      a proof of reachability.  The correspondent node registers the
      unverified care-of address on a tentative basis and sends a token
      to the mobile node based on which the latter can follow up with a



Arkko, et al.            Expires March 29, 2007                 [Page 8]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


      proof of reachability.  This completes the binding update.

   Credit-Based Authorization

      Concurrent care-of address tests without additional protection
      would enable an attacker to temporarily redirect its own
      communication flows to a spoofed, unverified care-of address.
      This introduces a vulnerability to redirection-based flooding
      attacks and is hence in conflict with the security requirements
      defined in Section 2.2.  Recall that the appeal of redirection-
      based flooding attacks is the potential for significant
      amplification.  Credit-Based Authorization [17] guarantees that
      malicious packet redirection cannot generate amplification.  This
      defeats the purpose of redirection-based flooding:  Any attacker
      could more effectively flood its victim by sending bogus packets
      directly.

   Reduced reachability verification

      A cryptographically generated home address does not tell whether
      its prefix is correct, so there is still need for a home address
      test.  Reachability verification is also required for care-of
      addresses since those are not cryptographically protected.  The
      protocol defined in this document executes a home address test
      during the initial key establishment procedure and a care-of
      address test upon each handoff.  However, due to the strong,
      cryptographic address ownership authentication of the home
      address, binding lifetimes can be much longer than in standard
      Mobile IPv6 route optimization, and reachability tests may occur
      on a less frequent basis.




4.  Protocol Operation

   The protocol defined in this document features a variety of possible
   message exchanges.  These are described below, packaged by the type
   of message processing operation.


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 so that further
      packets can be route-optimized and do no longer need to be routed



Arkko, et al.            Expires March 29, 2007                 [Page 9]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


      through the mobile node's home agent.

   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 its 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 (cf. Section 4.5).

   In any of these cases, the mobile node sends a Binding Update message
   to the correspondent node.  The Binding Update message MUST be
   authenticated either through the CGA property of the mobile node's
   home address, or through a proof of reachability at the home address.
   The appropriate authentication method is selected as follows:

   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 with the CGA property of its home address.

   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 MUST
      authenticate the Binding Update message with a proof of
      reachability at its home address.

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

   The mobile node SHOULD request the correspondent node to accept its
   CGA parameters for future CGA-based authentication if its home
   address is a CGA, but it does not yet have a permanent home keygen
   token from the correspondent node.  The mobile node then includes its
   CGA parameters in the Binding Update message by adding one or more
   CGA Parameters options (cf. Section 5.1) followed by a Signature
   option (cf. Section 5.2).  Once a permanent home keygen token has
   been obtained from the correspondent node, the mobile node MUST
   authenticate all subsequent Binding Update messages with the CGA
   property of its home address until either the binding lifetime
   expires, or the mobile node explicitly de-registers from the



Arkko, et al.            Expires March 29, 2007                [Page 10]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   correspondent node.  The mobile node MAY choose to ignore the CGA
   property of its home address and continue authenticating Binding
   Update messages through a proof of reachability at the home address,
   but this behavior is NOT RECOMMENDED.

   The mobile node also includes its CGA parameters in the Binding
   Update message if it intends to renew an existing permanent home
   keygen token shared with the correspondent node (cf. Section 4.5).
   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 through the
      CGA property of the mobile node's home address, 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.
      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 as defined in [1].

   The authenticator for the Binding Update message is further
   calculated based on a care-of keygen token.  The care-of keygen token
   to be used is selected as follows:

   o  If the mobile node has a valid care-of keygen token 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



Arkko, et al.            Expires March 29, 2007                [Page 11]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


      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 is NOT RECOMMENDED,
      however.

   If the Binding Update message is early, the mobile node MUST add a
   Care-of Test Init option to the message, requesting the correspondent
   node to return a new care-of keygen token.  Once a responding Binding
   Acknowledgment message with a Care-of Test option is received, the
   mobile node MUST use the care-of keygen token contained therein in
   calculating the authenticator for a complete Binding Update message
   and send this message to the 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].  These nonce indices are determined
   as follows:

   o  The home nonce index is defined to be zero if the Binding Update
      message is to be authenticated through the CGA property of the
      mobile node's home address.  (In this case, the mobile node uses a
      permanent home keygen token to calculate the authenticator for the
      Binding Update message.)

   o  If the Binding Update message is to be authenticated through a
      proof of 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 is
      taken from the Home Test message with which the home keygen token
      was obtained.

   o  The care-of nonce index is zero if the Binding Update message is
      early.

   o  If the Binding Update message is complete, the associated nonce
      index is taken from the Care-of Test message with which the
      care-of keygen token was obtained.

   The Nonce Indices option follows the CGA Parameters and Signature
   options, if any.

   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 [1].  The authenticator is placed
   into a Binding Authorization Data option [1], which the mobile node
   adds to the Binding Update message as the last option.



Arkko, et al.            Expires March 29, 2007                [Page 12]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


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.  This is
   accomplished either through the CGA property of the home address, or
   through verification of the mobile node's reachability at the home
   address.  The correspondent node selects the authentication method
   based on the home nonce index given in the Nonce Indices option of
   the Binding Update message:

   o  If the home nonce index is zero, the correspondent node MUST
      authenticate the Binding Update message through the CGA property
      of the home address.

   o  If the home nonce index is set to a non-null value, the
      correspondent node MUST authenticate the Binding Update message
      through verification of the mobile node's reachability at the home
      address.

   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 to retrieve or recompute the home keygen
   token, depends on the authentication method:

   o  If the Binding Update message is to be authenticated through the
      CGA property of the mobile node's home address, the correspondent
      node should have a permanent home keygen token in its Binding
      Cache entry for the mobile node.  If so, the correspondent node
      MUST use this permanent home keygen token in validating the
      authenticator of the Binding Update message.  If the correspondent
      node does not have a Binding Cache entry for the mobile node or
      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 TBD ("Permanent Home
      Keygen Token Unavailable").

   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 verify that it does not have
      a permanent home keygen token in its Binding Cache entry for the
      mobile node.  Provided that no permanent home keygen token is
      found, 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



Arkko, et al.            Expires March 29, 2007                [Page 13]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


      message.  On the other hand, in case the correspondent node does
      have a permanent home keygen token in its Binding Cache entry for
      the mobile node, further action depends on whether the Binding
      Update message includes a CGA Parameters option.  If the message
      does not include a CGA Parameters option, the correspondent node
      MUST reject the message by sending a Binding Acknowledgment
      message with status code TBD ("Conflicting Permanent Home Keygen
      Token").  This is necessary to ensure that an attacker cannot bid
      down the authentication method to hijack a mobile node's
      legitimate binding.  However, if a CGA Parameters option is
      included in the Binding Update message, the message is processed
      further.  The sending mobile node is in this case requesting a new
      permanent home keygen token.  Binding Update messages sent for the
      purpose of renewing an existing permanent home keygen token are
      usually authenticated through the CGA property of the mobile
      node's home address, based on the existing permanent home keygen
      token.  However, a mobile node may authenticate the Binding Update
      message through verification of its reachability at the home
      address when it has lost the permanent home keygen token, for
      instance, due to a reboot.  The correspondent node MUST then
      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 use this recomputed token in validating the
      authenticator of the message.  Note that the Binding Update
      message will still be rejected eventually should the
      authentication through the CGA property of the mobile node's home
      address fail during processing of the CGA Parameters option.

   The authenticator for the Binding Update message is further
   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 defined by the index, and
      it MUST use this recomputed token in validating the authenticator
      of the message.

   o  If the care-of nonce index is zero, the Binding Update message is
      early.  In this case, the correspondent node uses a value of zero
      in validating the authenticator of the Binding Update message.

   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 [1].




Arkko, et al.            Expires March 29, 2007                [Page 14]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   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 negative status code 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
   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 5.4 for sending packets to this
      care-of address until the care-of address is set in VERIFIED
      state.

   If the Binding Update message contains a CGA Parameters option, 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 option is directly followed
   by a Signature option and, if so, validate the signature included in
   the latter.  This is done as described in Section 4.6.

   If the CGA Parameters option is not directly followed by a Signature
   option, or the validation of the signature included in the Signature
   option fails, the correspondent node MUST silently discard the
   Binding Update message.

   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
   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



Arkko, et al.            Expires March 29, 2007                [Page 15]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   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 is early and includes a Care-of Test
      Init option.

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

   If the Binding Update message is early, the Binding Acknowledgment
   message MUST contain a Care-of Test option with a pseudo-random value
   in the Care-of Keygen Token field.

   If the Binding Update message contains a CGA Parameters option
   followed by a Signature option, and the signature included in the
   latter was determined to be correct, the Binding Acknowledgment
   message MUST include a Permanent Home Keygen Token option with the
   permanent home keygen token stored in the correspondent node's
   Binding Cache entry for the mobile node.


4.4  Receiving Binding Acknowledgment Messages

   A mobile node verifies a received Binding Acknowledgment message
   according to the rules specified in [1].

   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 this token in the appropriate entry of its Binding
   Update List, and sends the correspondent node a complete Binding
   Update message as defined in section Section 4.1.

   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 the appropriate
   entry of its Binding Update List.  Future Binding Update messages
   will then be authenticated based on the CGA property of the mobile
   node's home address.


4.5  Sending CGA Parameters

   A mobile node SHOULD send its CGA parameters to the correspondent
   node in any of the following situations:




Arkko, et al.            Expires March 29, 2007                [Page 16]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   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 extent 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 reinitialize the available sequence number space if the mobile
      node already has a permanent home keygen token from the
      correspondent node, and a sequence number rollover is imminent.

   In addition, a mobile node that already has a permanent home keygen
   token from the correspondent node MAY renew this token at any time by
   sending its CGA parameters to the correspondent node.  Periodic
   renewal of the permanent home keygen token provides increased
   protection against cryptanalysis.

   The mobile node sends its CGA parameters to the correspondent node
   within a Binding Update message in the format of the CGA Parameters
   data structure defined in [18].  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 (see Section 5.2).  The Nonce Indices
   and Binding Authorization Data options MUST appear after the
   Signature option.

   The mobile node calculates the value for the Signature field in the
   Signature option according to the signature generation algorithm
   defined in section 6 of [18].  The value is calculated with the
   mobile node's private CGA 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 the mobile node uses.  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 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 [18].

   The value for the Signature field is calculated as if the Checksum



Arkko, et al.            Expires March 29, 2007                [Page 17]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   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

   A correspondent node that receives a Binding Update message first
   processes the message as described in [1], even if the message
   includes CGA Parameters and Signature options.  This includes a
   verification of the Authenticator value in the Binding Authorization
   Data option.  If the Binding Update message is rejected due to an
   incorrect Authenticator value or for any other reason, the
   correspondent node does not process the message further.

   Otherwise, if the correspondent node accepts the Binding Update
   message and the message includes one or more CGA Parameters options
   directly followed by a Signature option, the correspondent node
   proceeds to verify the cryptographic properties of the mobile node's
   home address in the Binding Update message.  It reassembles the CGA
   Parameters data structure from the CGA Parameters options included in
   the Binding Update message as described in Section 5.1, and executes
   the CGA verification algorithm defined in [18].  The CGA verification
   algorithm takes the home address and the reassembled CGA Parameters
   data structure as input.  If the home address fails the CGA
   verification, the correspondent node skips the steps below and sends
   a Binding Acknowledgment message with status code TBD (CGA and
   signature verification failed) to the mobile node.

   If the cryptographic properties of the mobile node's home address are
   verified to be correct, the correspondent node performs the 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 [18].  The signature
   verification algorithm takes as input the home address, the
   reassembled CGA Parameters data structure, the MH data as defined in
   Section 4.5, and the CGA Message Type tag for this protocol as
   defined in Section 8, and the signature itself.  If the signature
   verification fails, the correspondent node skips the steps below and
   sends a Binding Acknowledgment message with status code TBD (CGA and
   signature verification failed) to the mobile node.

   The correspondent node does not accept the mobile node's home address
   as a CGA if either the CGA verification or the signature verification
   fails.  However, in both cases, the correspondent node still accepts
   the contents of the Binding Update message excluding the CGA
   Parameters and Signature options, but does not provide a permanent



Arkko, et al.            Expires March 29, 2007                [Page 18]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   home keygen token in the Binding Acknowledgment message.  The
   correspondent node in particular follows the rules in [1] for sending
   a Binding Acknowledgment message to the mobile node.

   If both the CGA verification and the signature verification are
   successful, the correspondent node sends a Binding Acknowledgment
   message with an included Permanent Home Keygen Token option to the
   mobile node as described in Section 4.7.


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 Binding Update message was clear.
   The Binding Acknowlegment message is built according to the rules in
   [1], except that it includes the Permanent Home Keygen Token option.
   The correspondent node encrypts the permanent home keygen token with
   the mobile node's public key using the RSAES-PKCS1-v1_5 format [2],
   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 value in
   the 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], even if the message
   includes a Permanent Home Keygen Token option.  This includes a
   verification of the Authenticator value in the Binding Authorization
   Data option.  If the Binding Acknowledgment message is rejected due
   to an incorrect Authenticator value or for any other reason, the
   mobile node does not process the message further.




Arkko, et al.            Expires March 29, 2007                [Page 19]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   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 CGA key using the RSAES-PKCS1-v1_5 format [2].  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  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 the early Binding Update message has been transmitted.  Like
   all other route-optimized payload packets that originate from the
   mobile node, these packets have the new 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.  The
   correspondent node redirects outgoing payload packets for the mobile
   node to the new care-of address once it has received the early
   Binding Update message and registered the new care-of address.  These
   payload packets have the new care-of address in the Destination
   Address field of the IPv6 header and the home address in the IPv6
   Routing extension header.

   The correspondent node limits the amount of data it sends to the
   mobile node while the new care-of address is UNVERIFIED to prevent
   amplified, redirection-based flooding attacks.  This is specifically
   realized as follows:  The correspondent node maintains a "credit
   counter" for each mobile nodes with which it uses the protocol
   specified in this document.  Whenever a packet arrives from one of
   these mobile nodes, the correspondent node SHOULD increase that
   mobile node's credit counter by the size of the received packet.
   When the correspondent node has a packet to be sent to the mobile
   node, if the mobile node's care-of address is labeled UNVERIFIED, the
   correspondent node checks whether it can send the packet to the
   UNVERIFIED care-of address:  The packet SHOULD be sent if the value
   of the credit counter is higher than the size of the outbound packet.
   If the credit counter is too low, the packet MUST be discarded or
   buffered until address verification succeeds.  When a packet is sent
   to a mobile node at an UNVERIFIED care-of address, the mobile node's
   credit counter MUST be reduced by the size of the packet.  The mobile
   node's credit counter is not affected by packets that the host sends



Arkko, et al.            Expires March 29, 2007                [Page 20]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   to a VERIFIED care-of address of that mobile node.

   Figure 2 depicts the actions taken by the correspondent node when a
   packet is received.  Figure 3 shows the decision chain in the event a
   packet is sent.

     Inbound
     packet
        |
        |       +-----------------+                 +-----------------+
        |       |  Increase the   |                 |   Deliver the   |
        +-----> | credit counter  |---------------> |  packet to the  |
                | by packet size  |                 |   application   |
                +-----------------+                 +-----------------+

        Figure 2: Receiving Packets with Credit-Based Authorization



   Outbound
   packet
      |          _________________
      |         /                 \                 +-----------------+
      |        /      Is the       \       No       | Send the packet |
      +-----> |   care-of address   |-------------> | to the care-of  |
               \    UNVERIFIED?    /                |     address     |
                \_________________/                 +-----------------+
                         |
                         | Yes
                         |
                         v
                 _________________
                /                 \                 +-----------------+
               /   Credit counter  \       No       |                 |
              |          >=         |-------------> | Drop the packet |
               \    packet size?   /                |                 |
                \_________________/                 +-----------------+
                         |
                         | Yes
                         |
                         v
                +-----------------+                 +-----------------+
                |   Reduce the    |                 | Send the packet |
                | credit counter  |---------------> | to the care-of  |
                | by packet size  |                 |     address     |
                +-----------------+                 +-----------------+

         Figure 3: Sending Packets with Credit-Based Authorization



Arkko, et al.            Expires March 29, 2007                [Page 21]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


4.10  Credit Aging

   A correspondent node ensures that the credit counters it maintains
   for its mobile nodes gradually decrease over time.  Such "credit
   aging" prevents a malicious node from building up credit at a very
   slow speed and using this, all at once, for a severe burst of
   redirected packets.

   Credit aging SHOULD be implemented by multiplying credit counters
   with a factor, CreditAgingFactor, less than one in fixed time
   intervals of CreditAgingInterval length.  Choosing appropriate values
   for CreditAgingFactor and CreditAgingInterval is important to ensure
   that the correspondent node can send packets to an address in state
   UNVERIFIED even when the mobile node sends at a lower rate than the
   correspondent node itself.  When CreditAgingFactor or
   CreditAgingInterval are too small, the mobile node's credit counter
   might be too low to continue sending packets until address
   verification concludes.

   The following values are used for the credit-aging parameters defined
   in this document:

      CreditAgingFactor        7/8
      CreditAgingInterval      5 seconds


   Note: These parameter values 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 exeed 500 milliseconds.


4.11  Simultaneous Movements

   As specified in RFC 3775 [1], Mobility Header messages are generally
   sent via the mobile node's home agent and to the peer's home address,
   if it is also mobile.  This makes it possible for two mobile nodes to
   communicate even if they are moving simultaneously.



5.  Option Formats and Status Codes

   The protocol specified in this document introduces a set of new
   mobility options and status codes.  These are described below.







Arkko, et al.            Expires March 29, 2007                [Page 22]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


5.1  CGA Parameters Option

   Options of this type are used to carry the mobile node's public key
   and the parameters needed by the correspondent node to check the CGA
   property of the mobile node's home address.  RFC 3775 [1] limits
   mobility header options to a maximum length of 255 bytes, excluding
   the Option Type and Option Length fields.  For this reason, multiple
   options of this type are used to carry the all parameters, which are
   likely to exceed the limit specified in RFC 3775.

   The format of the CGA Parameters option is the following:

      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

      <To Be Assigned By IANA>

   Option Length

      Length of the option

   CGA Parameters

      This field contains up to 255 bytes of the string holding the
      mobile node's CGA public key and other CGA parameters in the
      format defined in [18].  The concatenation of all options of this
      type in the order they appear in the Binding Update message MUST
      result in the string defined in [18].  All options of this type
      carried in the Binding Update message except the last one MUST
      contain exactly 255 bytes in the Option Data field, and the Option
      Length field MUST be set to 255 accordingly.  All options of this
      type MUST appear one after another, i.e., an option of a different
      type MUST NOT be placed in between two options of this type.







Arkko, et al.            Expires March 29, 2007                [Page 23]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


5.2  Signature Option

   The mobile node MUST provide a signature generated with its private
   CGA key if it includes a CGA Parameters option in a Binding Update
   message.  The signature MUST be inserted into a Signature option that
   follows the CGA Parameters option.

   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

      <To Be Assigned By IANA>

   Option Length

      Length of the option

   Signature

      This field contains the signature generated as specified in
      Section 4.5.



5.3  Permanent Home Keygen Token Option

   A correspondent node MUST send a new permanent home keygen token to a
   mobile node each time it receives a Binding Update message containing
   the CGA Parameters option from the mobile node.  The permanent home
   keygen token is carried in a Permanent Home Keygen Token option,
   which the correspondent node MUST insert in the Binding
   Acknowledgment message for the mobile node.

   The format of the Permanent Home Keygen Token option is as follows:





Arkko, et al.            Expires March 29, 2007                [Page 24]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


      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  |  Length = 16  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                  Permanent Home Keygen Token                  +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      <To Be Assigned By IANA>

   Option Length

      Length of the option

   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 or padding possibly involved [2]).



5.4  Care-of Test Init Option

   The Care-of Test Init option is included in a Binding Update message
   to request the 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 |
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Arkko, et al.            Expires March 29, 2007                [Page 25]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   Option Type

      <To Be Assigned By IANA>

   Option Length

      Length of the option



5.5  Care-of Test Option

   A correspondent node sends a Binding Acknowledgment message with a
   Care-of Test option when it receives a valid Binding Update message
   that includes a Care-of Test Init message.  The Care-of Test message
   contains a fresh care-of keygen token.

   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

      <To Be Assigned By IANA>

   Option Length

      Length of the option

   Care-of Keygen Token

      A care-of keygen token, generated as defined in RFC 3775.



5.6  Status Codes

   The protocol defined in this document uses the following new status
   code for Binding Acknowledgment messages:




Arkko, et al.            Expires March 29, 2007                [Page 26]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   Permanent Home Keygen Token Unavailable (<To Be Allocated By IANA>)

      A correspondent node returns a Binding Acknowledgment message with
      this status code to a mobile node if it has received from the
      mobile node a Binding Update message that was authenticated
      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 include a permanent home keygen token.  A
      Binding Acknowledgment message with this status code allows the
      mobile node to quickly request a new permanent home keygen token
      from the correspondent node in case of state loss at the
      correspondent node.

      Standard Mobile IPv6 does not allow a correspondent node to send a
      negative Binding Acknowledgment message when the authenticator of
      a received Binding Update message turns out to be incorrect.  This
      is likely to cause additional handoff latency 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 negative Binding
      Acknowledgment message with the status code helps the mobile node
      to identify the underlying problem much more efficiently.

   Conflicting Permanent Home Keygen Token (<To Be Allocated By IANA>)

      A correspondent node returns a Binding Acknowledgment message with
      this status code 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 a CGA Parameters 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 a CGA Parameters
      option.  This is necessary to enable a mobile node to obtain a new
      permanent home keygent token from the correspondent node in case
      it has lost the existing one, for instance, due to a reboot.
      Whether the correspondent node accepts the Binding Update message
      in this case depends on the verification of the signature provided
      for the CGA parameters included in the message.




6.  Security Considerations

   The protocol defined in this document makes the following conceptual



Arkko, et al.            Expires March 29, 2007                [Page 27]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   changes to the base protocol specified in RFC 3775:

   o  RFC 3775 uses periodic tests of a mobile node's reachability at
      the home address as a proof of home address ownership.  This
      protocol uses 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 binding updates, so that these later binding
      updates can be securely bound to the initial home address
      ownership proof.  No further, periodic reachability verification
      at the home address tests is performed.

   o  RFC 3775 requires a mobile node to prove its reachability at a new
      care-of address when updating a binding at a correspondent node.
      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.  This protocol
      allows the mobile node to initiate the binding update first and
      then 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.

   o  The maximum binding lifetime for correspondent registrations is 7
      minutes in RFC 3775.  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, eliminating the need for
      periodic refreshes.

   The following subsections discuss the implications that these changes
   have on security.  The discussion ought to be seen in context with
   the security considerations of [1], [18], and [8].


6.1  Home Address Ownership

   The protocol defined in this document requires a mobile node to
   deliver a strong cryptographic proof that it is the owner of the home
   address it wishes to use.  The proof requires knowledge of a private
   key for which the corresponding public key will, as an input to the
   CGA generation algorithm along with suitable other parameters, result
   in the desired home address.  Spoofing another node's home or regular
   IPv6 address, so-called "IP address stealing" [8], hence requires an
   attacker to find a suitable public/private key pair in a brute-force
   manner.  The effort for doing so successfully is very high [18].



Arkko, et al.            Expires March 29, 2007                [Page 28]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   This makes the attack, which would otherwise permit impersonation and
   denial of service, extremely unlikely.

   While the CGA generation algorithm cryptographically ties the
   interface identifier of the CGA to the prefix, the algorithm accepts
   any prefix and hence does not prevent a node from generating a CGA
   from a different network.  As a consequence, the cryptographic
   property of a CGA does not guarantee that the alledged CGA owner is
   indeed reachable at the IP address.  An attacker could in fact use
   its own public key to generate a CGA-based home address with an
   incorrect prefix, request a correspondent node to bind this to the
   attacker's true care-of address, request a stream of packets via the
   care-of address, and then let the binding expire.  The result would
   be a "return-to-home flooding" [8] attack against the victim network
   for which the home address was generated.  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.

   During the initial registration, the correspondent node assigns the
   mobile node a permanent home keygen token for use during subsequent
   binding updates.  The permanent home keygen token is a symmetric
   secret key that allows for computationally more efficient
   authentication than a reapplied public-key-based home address
   ownership proof.  Authentication of the mobile node allows the
   correspondent node to securely bind a subsequent binding update back
   to the home address ownership proof and reachability verification
   performed during the first registration.  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 binding updates.  Both mobile and correspondent
   nodes can therefore trust that the permanent home keygen token is
   known to only itself and the mobile node.


6.2  Care-of Address Ownership

   A secure proof of home address ownership can mitigate the threat of
   IP address stealing, but a malicious node may still bind a correct
   home address to a false care-of address and thereby redirect packets,
   which would otherwise be delivered to the node itself, to a third
   party.  Neglection to verify a given care-of address could therefore
   cause one or multiple correspondent nodes to unknowingly contribute
   to a "redirection-based flooding" [8] attack against a victim chosen
   by the attacker.

   A redirection-based flooding attack may target an entire network,
   rather than a single node, either by loading the network with



Arkko, et al.            Expires March 29, 2007                [Page 29]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   packets, or by overwhelming a router or other critical network device
   further upstream.  The attacker in this case directs the flooding
   packets against an arbitrary IP address matching a prefix of the
   victim network or, respectively, against the IP address of the
   network device in focus.  An attack against a network potentially
   impacts a larger number of nodes than an attack against a specific
   node, although neighbors of a victim node on a broadcast link
   typically suffer the same damage as the victim itself.

   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 for a verification of the care-of
   address.  This notion may originate from the specification of a home
   registration in RFC 3775, which authenticates a mobile node based on
   an IPsec security association, but does not supplement this by an
   ownership proof of the care-of address.  Yet the waiver for the
   care-of address test is in this case not justified by the fact that
   the home agent can securely verify the mobile node's home address
   ownership, or that the home registration is IPsec-protected.  It is
   rather based a prerequired administrative relationship between the
   home agent and the mobile node that 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, e.g., due to compromise by malware.  Section
   15.3 in [1] and section 1.3.2 in [8] explain these prerequisites.

   Assuming trust and 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 which the mobile node's user
   typically has subscribed to, has set up her- or himself, or is
   receiving based on a business relationship.  A Mobile IPv6 extension
   [19] that leverages a shared authentication key, pre-configured 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 [19] acknowledges this), it permits omission of care-of address
   reachability verification as in the case of the home registration.
   The protocol defined in this document does not make assumptions on
   the relationship between mobile and correspondent nodes and thence
   applies to arbitrary scenarios.  The implication of the lack of trust
   is that correspondent nodes must verify a mobile node's reachability
   at every new care-of address.

   Requiring mobile nodes to cryptographically generate care-of
   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 new CGA-based care-of address with a



Arkko, et al.            Expires March 29, 2007                [Page 30]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   prefix from the victim network.  Directing a packet flood towards
   this care-of address would then not require any specific node to
   actually receive and process the packets, but it would impact an
   entire link or network and thus cause comparable damage.  CGA-based
   care-of addresses are therefore little effective with respect to
   flooding protection, but would on the other hand require a
   computationally expensive, public-key-based ownership proof upon
   every binding update.  The protocol described in this document uses
   regular IPv6 care-of addresses for these reasons.

   Concurrent verification of a mobile node's reachability at a new
   care-of address would in the absence of appropriate protection
   mechanisms re-introduce the threat of redirection-based flooding:  An
   attacker could register a false care-of address, thereby trick its
   correspondent node into sending packets to a victim, delay the
   rechability verification process as much as possible, and finally
   register a different, possibly also spoofed care-of address.  The
   attacker may in fact iterate through multiple incorrect care-of
   addresses which all route to the victim's link.  Since even a
   legitimate mobile node may at times undergo two handoffs shortly
   after one another so that no time is left to finish reachability
   verification, it is in general impossible to decide at the
   correspondent node side whether a failed reachability verification is
   due to malicious intents or to other reasons.

   The protocol defined in this document uses Credit-Based Authorization
   to protect against misuse of concurrent reachability verification.
   Credit-Based Authorization does not prevent malicious packet
   redirection itself, but rather reduces the effectiveness of such an
   attack to that of a simple, direct flooding attack where the
   perpetrator itself sends packets to the victim.  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 Credit-Based Authorization to the security of the non-mobile
   Internet.  Through the use of Credit-Based Authorization, the
   protocol defined in this document hence satisfies the objective to
   provide a security level comparable to the non-mobile Internet.


6.3  Time Shifting Attacks

   RFC 3775 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 re-verified periodically.  This ensures that
   the return routability procedure's vulnerability to eavesdropping
   cannot be exploited by an attacker which is only temporarily on the



Arkko, et al.            Expires March 29, 2007                [Page 31]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   path between the correspondent node and the spoofed home or care-of
   address.  Such "time shifting attacks" [8] could otherwise be misused
   for off-path IP address stealing, return-to-home flooding, or
   flooding of care-of addresses.

   The protocol defined in this document neither repeats 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
   protection of existing IP addresses solely rests on the required CGA-
   based ownership proof for home addresses, and it does not gain
   further strength through reachability testing.  But the restriction
   to a single reachability test does facilitate 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 initial reachability test before it moves to a
   different location.

   The design choice against repeated IP address tests was made based on
   the observation that time shifting attacks are already an accepted
   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.  While a well-heeded responsibility of transport
   protocols and applications is to verify an initiator's IP address
   during connection establishment, subsequent verification typically
   takes place only by means of forgeable acknowledgments for received
   data.  Participation in the initial handshake is then sufficient to
   spoof acknowledgments from an off-path position later on and thus
   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 the mobility
   protocol verifies reachability of 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 can enforce reruns of
   an home or care-of address test by limiting the registration lifetime
   or sending Binding Refresh Request messages to a mobile node.


6.4  Replay Attacks

   The protocol specified in this document relies on standard 16-bit
   Mobile IPv6 sequence numbers and periodic rekeying to avoid replay



Arkko, et al.            Expires March 29, 2007                [Page 32]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   attacks.  Rekeying allows the nodes to reuse sequence numbers without
   exposing themselves to replay attacks.  Mobile and correspondent
   nodes rekey at least once every 24 hours due to the maximum permitted
   lifetime of a correspondent registration.  The 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 binding updates, each
   consisting of an early and a full Binding Update message.  The
   sequence number space thus permits an average rate of 22 binding
   updates per minute without exposing a need to rekey throughout the
   24-hour registration lifetime.


6.5  Resource Exhaustion

   While a CGA-based home address ownership proof provides protection
   against unauthenticated Binding Update messages, it can expose the
   involved nodes to denial-of-service attacks since it requires
   computationally expensive public-key cryptography.  The protocol
   defined in this document limits the use of public-key cryptography to
   only the first registration and if/when re-keying is needed.  It is
   RECOMMENDED that nodes in addition track the amount of processing
   resources they spend on CGA-based home address ownership
   verification, and that they reject new requests when these resources
   exceed a predefined limit. [18] discusses the feasibility of CGA-
   based resource exhaustion attacks in depth.


6.6  IP Address Ownership of Correspondent Node

   The protocol defined in this document does not verify ownership of a
   correspondent node's IP address.  A mobile node has hence no
   guarantee that a received permanent home keygen token indeed
   originates with the correspondent node.  In particular, a man-in-the-
   middle attacker could interpose during the initial correspondent
   registration, pretend to be the correspondent node, and deliver its
   own permanent home keygen token to the mobile node.  This attacker
   would have to be able to send both a Home Test message as well as a
   Binding Acknowledgment message on behalf of the correspondent node,
   and it may have to intercept the mobile node's Home Test Init and
   Binding Update messages.  This potentially requires presence on
   separate paths.  A successully spoofed inital registration would
   allow the attacker to impersonate the correspondent node also during
   subsequent binding updates of the mobile node, as long as it remains
   in a position to intercept and respond to the mobile node's Binding
   Update messages.

   The primary reason not to protect ownership of the correspondent



Arkko, et al.            Expires March 29, 2007                [Page 33]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   node's IP address is that the threat emanating from a man in the
   middle on the path between two communicating nodes already exists in
   the non-mobile Internet.  The threat can therefore more effectively
   be eliminated in a mobility-independent manner.  This design choice
   also reduces the complexity of the protocol defined in this document
   and curtails the requirements imposed on the correspondent node.



7.  Performance Considerations

   Performance of our protocol depends on whether we look at the initial
   or subsequent runs.  The number of messages in the initial run is one
   less as in base Mobile IPv6, but the size of the messages is
   increased somewhat.

   On a mobile node that does not move that often, there is a
   significant signaling reduction, as the lifetimes can be set higher
   than in return routability.  For instance, a mobile node that stays
   in the same address for a day will get a 99.52% signaling reduction.
   Such long lifetimes can be achieved immediately, as opposed to
   methods like [12] that grow them gradually.

   On a mobile node that moves fast, the per-movement signaling is
   reduced by 33%.

   Latency on the initial run is not affected, but on the subsequent
   movements there's a significant impact.  This is because the home
   address test is eliminated.  The exact effect depends on network
   topology, but if the home agent is far away and the correspondent
   node is on the same link, latency is almost completely eliminated.

   Additional latency and signaling improvements could be achieved
   through mechanisms that optimize the care-of address tests in some
   way.  This is outside the scope of this document, however.



8.  Protocol Constants

   The CGA specification defines a CGA Message Type name space from
   which CGA applications draw CGA Message Type tags to be used in
   signature calculations.  This protocol uses a CGA Message Type tag of
   0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13.  The tag value has been
   generated randomly.






Arkko, et al.            Expires March 29, 2007                [Page 34]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


9.  IANA Considerations

   This document defines a set of new mobility options, which must be
   assigned Option Type values within the mobility option numbering
   space of [1].

   This document allocates two new status codes, "Permanent Home Keygen
   Token Unavailable" and "Conflicting Permanent Home Keygen Token", for
   Binding Acknowledgment messages.  The value to be assigned for both
   status codes must 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 name space [18].



10.  Acknowledgment

   The authors would like to thank Pekka Nikander, Tuomas Aura, Greg
   O'Shea, Mike Roe, Gabriel Montenegro, Vesa Torvinen for
   interesting discussions around cryptographically generated addresses.

   The authors would also like to thank Vidya Narayanan and Lakshminath
   Dondeti for their reviews of and comments on this document, as well
   as Greg Daley, Samita Chakrabarti, Marcelo Bagnulo, Suresh Krishnan,
   Mohan Parthasarathy, Lila Madour, Francis Dupont, Roland Bless, Mark
   Doll, and Tobias Kuefner for their reviews of and comments on the
   predecessors of this document.

   Finally, the authors would also like to emphasize that [20] pioneered
   the use of cryptographically generated addresses in the context of
   Mobile IPv6 route optimization, and that this document consists
   largely of material from [21], [22], and [17] and the contributions
   of their authors.















Arkko, et al.            Expires March 29, 2007                [Page 35]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


11.  References

11.1  Normative References

   [1]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

   [2]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
        RFC 3447, February 2003.

   [3]  International Telecommunications Union, "Information Technology
        - ASN.1 encoding rules: Specification of Basic Encoding Rules
        (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
        Rules (DER)", ITU-T Recommendation X.690, July 2002.

   [4]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and Certificate Revocation
        List (CRL) Profile", RFC 3280, April 2002.

   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [7]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)", RFC 2461, December 1998.

11.2  Informative References

   [8]   Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
         Nordmark, "Mobile IP Version 6 Route Optimization Security
         Design Background", IETF Request for Comments 4225,
         December 2005.

   [9]   Vogt, C. and J. Arkko, "Taxonomy and Analysis of Enhancements
         to Mobile IPv6 Route Optimization", IETF Internet Draft
         draft-irtf-mobopts-ro-enhancements-08.txt (work in progress),
         May 2006.

   [10]  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.

   [11]  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.



Arkko, et al.            Expires March 29, 2007                [Page 36]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   [12]  Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
         Lifetime Extension",
         draft-arkko-mipv6-binding-lifetime-extension-00 (work in
         progress), May 2004.

   [13]  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.

   [14]  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.

   [15]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         IETF Request for Comments 3972, March 2005.

   [16]  Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)",
         draft-haddad-mipv6-omipv6-01 (work in progress), February 2004.

   [17]  Vogt, C., "Credit-Based Authorization for Mobile IPv6 Early
         Binding Updates",
         draft-vogt-mipv6-credit-based-authorization-00 (work in
         progress), May 2004.

   [18]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-06 (work in progress), April 2004.

   [19]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
         IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress),
         April 2004.

   [20]  Roe, M., "Authentication of Mobile IPv6 Binding Updates and
         Acknowledgments", draft-roe-mobileip-updateauth-02 (work in
         progress), March 2002.

   [21]  Haddad, W., "Applying Cryptographically Generated Addresses to
         Optimize MIPv6  (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-04
         (work in progress), May 2005.

   [22]  Vogt, C., "Early Binding Updates for Mobile IPv6",
         draft-vogt-mip6-early-binding-updates-00 (work in progress),
         February 2004.

   [23]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [24]  Nikander, P., "Mobile IP version 6 Route Optimization Security



Arkko, et al.            Expires March 29, 2007                [Page 37]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


         Design Background", draft-ietf-mip6-ro-sec-03 (work in
         progress), May 2005.

   [25]  Dupont, F. and J. Combes, "Using IPsec between Mobile and
         Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-01 (work
         in progress), June 2004.


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



Appendix A.  Overview of CGA

   As described in [18], a Cryptographically Generated Address (CGA) is
   an IPv6 address, which contains a set of bits generated by hashing
   the IPv6 address owner's public key.  Such feature allows the user to
   provide a "proof of ownership" of its IPv6 address.

   The CGA offers three main advantages: it makes the spoofing attack
   against the IPv6 address much harder and allows to sign messages with
   the owner's private key.  CGA does not require any upgrade or



Arkko, et al.            Expires March 29, 2007                [Page 38]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   modification in the infrastructure.

   The CGA offers a method for binding a public key to an IPv6 address.
   The binding between the public key and the address can be verified by
   re-computing and comparing the hash value of the public key and other
   parameters sent in the specific message with the interface identifier
   in the IPv6 address belonging to the owner.  Note that an attacker
   can always create its own CGA address but he will not be able to
   spoof someone else's address since he needs to sign the message with
   the corresponding private key, which is supposed to be known only by
   the real owner.

   CGA assures that the interface identifier part of the address is
   correct, but does little to ensure that the node is actually
   reachable at that identifier and prefix.  As a result, CGA needs to
   be employed together with a reachability test where redirection
   denial-of-service attacks are a concern.

   Each CGA is associated with a public key and auxiliary parameters.
   In this protocol, the public key MUST be formatted as a DER-encoded
   [3] ASN.1 structure of the type SubjectPublicKeyInfo defined in the
   Internet X.509 certificate profile [4].

   The CGA verification takes as input an IPv6 address and auxiliary
   parameters.  These parameters are the following:

   o  a 128-bit modifier, which can be any value,

   o  a 64-bit subnet prefix, which is equal to the subnet prefix of the
      CGA,

   o  an 8-bit collision count, which can have values 0, 1 and 2.

   If the verification succeeds, the verifier knows that the public key
   in the CGA parameters is the authentic public key of the address
   owner.  In order to sign a message, a node needs the CGA, the
   associated CGA parameters, the message and the private cryptographic
   key that corresponds to the public key in the CGA parameters.  The
   node needs to use a 128 bit type tag for the message from the CGA
   Message Type name space.  The type tag is an IANA-allocated 128 bit
   integer.

   To sign a message, a node performs the following two steps:

   1.  Concatenate the 128 bit type tag (in the network byte order) and
       message with the type tag to the left and message to the right.
       The concatenation is the message to be signed in the next step.




Arkko, et al.            Expires March 29, 2007                [Page 39]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   2.  Generate the RSA signature.  The inputs to the generation
       procedure are the private key and the concatenation created in
       a).




Appendix B.  Overview of Credit-Based Authorization

   To prevent redirection-based flooding attacks, the easiest way would
   be not to use a new care-of address until it has been verified.  This
   could proceed unnoticed when the mobile node can meanwhile
   communicate through a second interface.  However, many situations are
   conceivable in which mobile nodes have a single interface only.  The
   care-of-address test would increase signaling delays by one round-
   trip time in such cases.  To avoid this additional delay, a new
   care-of address is used as soon as possible, and the correspondent
   node verifies the mobile node's reachability at that care-of address
   concurrently.  Credit-Based Authorization for concurrent care-of-
   address tests prevents illegitimate packet redirection until the
   validity of the address has been established.  This is accomplished
   based on the following three hypotheses:

   1.  A flooding attacker typically seeks to somehow multiply the
       packets it generates itself for the purpose of its attack because
       bandwidth is an ample resource for many attractive victims.

   2.  An attacker can always cause unamplified flooding by sending
       packets to its victim directly.

   3.  Consequently, the additional effort required to set up a
       redirection-based flooding attack would pay off for the attacker
       only if amplification could be obtained this way.

   On this basis, rather than eliminating malicious packet redirection
   in the first place, Credit-Based Authorization prevents any
   amplification that can be reached through it.  This is accomplished
   by limiting the data a correspondent node can send to an unverified
   care-of address of a mobile node by the data recently received from
   that mobile node.  Redirection-based flooding attacks thus become
   less attractive than, e.g., pure direct flooding, where the attacker
   itself sends bogus packets to the victim.

   Figure 10 illustrates Credit-Based Authorization: The correspondent
   node measures the bytes received from the mobile node.  When the
   mobile node changes to a new care-of address, the correspondent node
   labels this address UNVERIFIED and sends packets there as long as the
   sum of the packet sizes does not exceed the measured, received data



Arkko, et al.            Expires March 29, 2007                [Page 40]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   volume.  The mobile node's reachability at the new care-of address
   meanwhile gets verified When the care-of-address test completes with
   success, the correspondent node relabels the care-of address from
   UNVERIFIED to VERIFIED.  As of then, packets can be sent to the new
   care-of address without restrictions.  When insufficient credit is
   left while the care-of address is still UNVERIFIED, the correspondent
   node stops sending further packets until address verification
   completes.

      +-------------+         +--------------------+
      | Mobile Node |         | Correspondent Node |
      +-------------+         +--------------------+
             |                          |
     address |------------------------->| credit += size(packet)
    verified |                          |
             |------------------------->| credit += size(packet)
             |<-------------------------| don't change credit
             |                          |
             + address change           |
     address |<-------------------------| credit -= size(packet)
   unverified|------------------------->| credit += size(packet)
             |<-------------------------| credit -= size(packet)
             |                          |
             |<-------------------------| credit -= size(packet)
             |                          X credit < size(packet) ==> drop
             |                          |
             + address change           |
     address |                          |
    verified |<-------------------------| don't change credit
             |                          |

                   Figure 10: Credit-Based Authorization


   The correspondent node ensures that the mobile node's acquired credit
   gradually decrease over time.  Such "credit aging" prevents a
   malicious node from building up credit at a very slow speed and using
   this, all at once, for a severe burst of redirected packets.



Appendix C.  Change Log

   The following is a list of technical changes that were made from
   version 00 to version 01 of this document.  Editorial revisions are
   not explicitly mentioned.





Arkko, et al.            Expires March 29, 2007                [Page 41]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


   o  Revised Section 1 to reflect the comments from Vidya and
      Lakshminath.  The text now makes it much clearer that there are
      two individual optimizations for home and care-of address
      verification.

   o  Added Section 4.5 describing when the mobile node sends CGA
      parameters to the correspondent node and how the CGA Parameters
      and Signature options are used to accomplish this.

   o  Added Section 4.6 describing the correspondent node's operation
      upon receiving a Binding Update message with included CGA
      Parameters and Signature options.

   o  Added Section 4.7 describing how a correspondent node generates
      and encrypts a permanent home keygen token and sends the token in
      a Permanent Home Keygen Token option within a Binding
      Acknowledgment message to the mobile node.

   o  Added Section 4.8 describing how a mobile node decrypts a
      permanent home keygen token received in a Binding Acknowledgment
      message with a Permanent Home Keygen Token option.

   o  Removed Section "Renewing a Permanent Home Keygen Token" (formerly
      Section 4.7).  The section described when the mobile node should
      renew an existing permanent home keygen token.  This is now
      explained in Section 4.5.

   o  Section 4.9 now also describes when mobile and correspondent nodes
      resume route-optimized payload transmission after handoff on the
      mobile node side.

   o  Removed Section "Cryptographic Calculations" (formerly Section
      4.10).  The section described how the signature in a Signature
      option and the contents of the former SKey option are calculated.
      The signature calculation is now described in Section 4.5.  The
      SKey option was replaced by the Permanent Home Keygen Token
      option, and the contents of this are now described in Section 4.7.

   o  Cleaned up section Section 5.

   o  Replaced status code "Lost Kbmperm State" in Section 5.6 with a
      new status code, "Permanent Home Keygen Token Unavailable".  Added
      a second status code "Conflicting Permanent Home Keygen Token".
      Section 4 ("Protocol Operation") and Section 9 ("IANA
      Considerations") were modified accordingly.

   o  Revised Section 6 so that it now addresses the comments made by
      Vidya and Lakshminath.  In particular, the text now explains why a



Arkko, et al.            Expires March 29, 2007                [Page 42]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


      care-of address test is required in spite of the more secure, CGA-
      based home address verification.  The section also starts with an
      overview of the conceptual changes that the proposed protocol
      applies to RFC 3775.

   o  Added Section 8 defining the CGA Message Type tag to be allocated
      for this protocol.












































Arkko, et al.            Expires March 29, 2007                [Page 43]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


Intellectual Property Statement

   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.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.





Arkko, et al.            Expires March 29, 2007                [Page 44]

Internet-Draft         CGA and CBA for Mobile IPv6        September 2006


Acknowledgment

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















































Arkko, et al.            Expires March 29, 2007                [Page 45]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/