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

Versions: 00 01 02 03 04 draft-ietf-mipshop-cga-cba

Network Working Group                                           J. Arkko
Internet-Draft                              Ericsson Research NomadicLab
Expires: December 25, 2006                                       C. Vogt
                                             Universitaet Karlsruhe (TH)
                                                               W. Haddad
                                                       Ericsson Research
                                                           June 23, 2006


    Applying Cryptographically Generated Addresses and Credit-Based
                      Authorization to Mobile IPv6
                   draft-arkko-mipshop-cga-cba-04.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 December 25, 2006.

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 December 25, 2006               [Page 1]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Objectives . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1  Handoff Latency  . . . . . . . . . . . . . . . . . . . . .   4
     2.2  Security . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3  Signaling Overhead . . . . . . . . . . . . . . . . . . . .   6
   3.   Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   6
   4.   Protocol Operation . . . . . . . . . . . . . . . . . . . . .   9
     4.1  Sending Binding Update messages  . . . . . . . . . . . . .   9
     4.2  Receiving Binding Update messages  . . . . . . . . . . . .  12
     4.3  Sending Binding Acknowledgment messages  . . . . . . . . .  14
     4.4  Receiving Binding Acknowledgment messages  . . . . . . . .  15
     4.5  Sending CGA Parameters . . . . . . . . . . . . . . . . . .  15
     4.6  Receiving CGA Parameters . . . . . . . . . . . . . . . . .  15
     4.7  Renewing a Permanent Home Keygen Token . . . . . . . . . .  15
     4.8  Handling Payload Packets . . . . . . . . . . . . . . . . .  16
     4.9  Credit Aging . . . . . . . . . . . . . . . . . . . . . . .  17
     4.10   Cryptographic Calculations . . . . . . . . . . . . . . .  18
     4.11   Simultaneous Movements . . . . . . . . . . . . . . . . .  18
   5.   Option Formats and Status Codes  . . . . . . . . . . . . . .  19
     5.1  CGA Parameters Option  . . . . . . . . . . . . . . . . . .  19
     5.2  Permanent Home Keygen Token Option . . . . . . . . . . . .  20
     5.3  Signature Option . . . . . . . . . . . . . . . . . . . . .  20
     5.4  Care-of Test Init Option . . . . . . . . . . . . . . . . .  21
     5.5  Care-of Test Option  . . . . . . . . . . . . . . . . . . .  22
     5.6  Status Codes . . . . . . . . . . . . . . . . . . . . . . .  22
   6.   Security Considerations  . . . . . . . . . . . . . . . . . .  23
   7.   Performance Considerations . . . . . . . . . . . . . . . . .  24
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  25
   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1  Normative References . . . . . . . . . . . . . . . . . . .  25
     9.2  Informative References . . . . . . . . . . . . . . . . . .  26
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  27
   A.   Acknowledgment . . . . . . . . . . . . . . . . . . . . . . .  28
   B.   Overview of CGA  . . . . . . . . . . . . . . . . . . . . . .  28
   C.   Overview of Credit-Based Authorization . . . . . . . . . . .  30
        Intellectual Property and Copyright Statements . . . . . . .  32













Arkko, et al.           Expires December 25, 2006               [Page 2]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


1.  Introduction

   Mobile IPv6 [1] includes a mode for route optimization that allows
   nodes to communicate with reduced latency via a direct routing path.
   Route optimization is protected through a "return routability
   procedure", which serves essentially two purposes:

   o  A correspondent node can (weakly) authenticate a mobile node based
      on a verification of the mobile node's reachability at its home
      address.

   o  A correspondent node can verify that the mobile node is reachable
      at the claimed care-of address.

   While authentication prevents impersonation threats, the reachability
   verification for the care-of address protects against "redirection-
   based flooding attacks" [8].

   Standard route optimization is limited by the capabilities of the
   return routability procedure.  For one thing, the procedure does not
   protect against an impersonator on the path between the mobile node's
   home agent and the correspondent node.  This vulnerability may
   oftentimes be acceptable, given that it already exists in the non-
   mobile Internet of today.  But scenarios with higher security needs
   are also conceivable.  Second, the return routability procedure
   consumes a significant of the overall handoff delay.  Since route
   optimization was orignally developed with an intent to improve
   support for interactive real-time applications, it is exactly those
   applications that suffer from prolonged handoff delays.

   This document amends the Mobile IPv6 base specification by two
   optional, interrelated, yet orthogonal optimizations to the return
   routability procedure.  The first optimization enables unidirectional
   or mutual authentication based on a cryptographically generated home
   address [9].  This replaces the weaker authentication through pure
   reachability verification at a home address.  The second optimization
   allows a correspondent node to securely verify a mobile node's
   reachability at a new care-of address while it already sends data
   packets to that care-of address [10].  The two optimizations 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



Arkko, et al.           Expires December 25, 2006               [Page 3]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   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.


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





Arkko, et al.           Expires December 25, 2006               [Page 4]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


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.

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



Arkko, et al.           Expires December 25, 2006               [Page 5]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


2.3  Signaling Overhead

   A complete correspondent registration involves 6 message
   transmissions at the mobile node, totaling about 376 bytes (cf.
   [14]).  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.

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



Arkko, et al.           Expires December 25, 2006               [Page 6]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


      this document features this through the application of
      cryptographically generated home addresses [15][16].  In general,
      a cryptographically generated address [9] 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
      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
      [17].  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-



Arkko, et al.           Expires December 25, 2006               [Page 7]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


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



Arkko, et al.           Expires December 25, 2006               [Page 8]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


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

   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.





Arkko, et al.           Expires December 25, 2006               [Page 9]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   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 addess
   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.3).  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
   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.7).
   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:




Arkko, et al.           Expires December 25, 2006              [Page 10]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


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




Arkko, et al.           Expires December 25, 2006              [Page 11]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


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


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



Arkko, et al.           Expires December 25, 2006              [Page 12]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


      authenticator of the Binding Update message.  If the correspondent
      node does not have a permanent home keygen token for the mobile
      node in its Binding Cache, the correspondent node MUST reject the
      Binding Update message.

   o  If the Binding Update message is to be authenticated through
      verification of the mobile node's reachability at the home
      address, the correspondent node MUST 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
      message.  In case the correspondent node does have a permanent
      home keygen token in its Binding Cache entry for the mobile node,
      it MUST reject the Binding Update message.  This is necessary to
      ensure that an attacker cannot bid down the authentication method
      to hijack a mobile node's legitimate binding.

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

   If the validation fails, the correspondent node MUST discard the
   Binding Update message.  The correspondent node may have to send a
   Binding Acknowledgment message with a 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



Arkko, et al.           Expires December 25, 2006              [Page 13]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


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




Arkko, et al.           Expires December 25, 2006              [Page 14]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   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

   TBD.


4.6  Receiving CGA Parameters

   TBD.


4.7  Renewing a Permanent Home Keygen Token

   A mobile node MAY request a correspondent node to renew an existing



Arkko, et al.           Expires December 25, 2006              [Page 15]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   permanent home kegen token at any time, but it MUST do so in the
   imminent event of a sequence number rollover, or when the lifetime of
   the binding at the correspondent node is about to expire.


4.8  Handling Payload Packets

   A 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 to a VERIFIED care-of address
   of that mobile node.

   Figure 1 depicts the actions taken by the correspondent node when a
   packet is received.  Figure 2 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 1: Receiving Packets with Credit-Based Authorization













Arkko, et al.           Expires December 25, 2006              [Page 16]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   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 2: Sending Packets with Credit-Based Authorization




4.9  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



Arkko, et al.           Expires December 25, 2006              [Page 17]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   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.10  Cryptographic Calculations

   The Signature option is calculated with the mobile node's private key
   over the following sequence of octets:

      Mobility Data = care-of address | correspondent | MH Data

   Where | denotes concatenation and "correspondent" is the
   correspondent node's IPv6 address.  Note that in case the
   correspondent node is mobile, correspondent refers to the
   correspondent node's home address.

   MH Data is the content of the mobility message including the MH
   header.  The Authenticator within the Binding Authorization Data
   option is zeroed for purposes of calculating the signature.

   The RSA signature is generated by using the RSASSA-PKCS1-v1_5 [2]
   signature algorithm with the SHA-1 hash algorithm.

   When the SKey option is used, the correspondent node MUST encrypt the
   Kbm with the MN's public key using the RSAES-PKCS1-v1_5 format [2].


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.






Arkko, et al.           Expires December 25, 2006              [Page 18]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


5.  Option Formats and Status Codes


5.1  CGA Parameters Option

   Options of this type are used to carry the mobile node's public key
   and the CGA parameters needed by the correspondent node to check the
   validity of the mobile node's CGA.  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 entire CGA information, which is
   likely to exceed the limit specified in RFC 3775.

   The format of the 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.

   Option Data

      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 December 25, 2006              [Page 19]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


5.2  Permanent Home Keygen Token Option

   As it has been mentioned above, the correspondent node MUST send a
   new Kbm each time it receives a Binding Update message containing the
   CGA Parameter option.  For this purpose, this proposal uses a new
   option called SKey option, which MUST be inserted in the Binding
   Acknowledgment message.

   The format of the 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  |  Length = 16  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +      Semi-Permanent Key for Binding Management (Kbmperm)      +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option.

   Option Data

      This field contains the Kbmperm value.  Note that the content of
      this field MUST be encrypted with the mobile node's public key as
      defined in Section 4.10.  The length of Kbmperm value is 20 octets
      (before encryption or padding possibly involved [2]).



5.3  Signature Option

   When the mobile node signs the Binding Update message with its CGA
   private key, it MUST insert the signature in the SIG option.  Such
   scenario occurs when the mobile node sends its first Binding Update
   message to the correspondent node and if the mobile node reboots
   during an ongoing session.



Arkko, et al.           Expires December 25, 2006              [Page 20]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   The option format 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.

   Option Data

      This field contains the signature of the MH message it is
      contained within.



5.4  Care-of Test Init Option

   A mobile node that wishes to employ the care-of address test
   optimization MAY employ this option in Binding Update message sent to
   a correspondent node in which it has previously established a Binding
   Cache entry.  When received by such a correspondent node, it SHOULD
   return a Care-of Keygen Token option in the Binding Acknowledgement
   message.

   The option format 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 December 25, 2006              [Page 21]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option = 0.



5.5  Care-of Test Option

   This option is returned by a correspondent node upon seeing a Care-of
   Test Init option in a Binding Update.

   The option format 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 = 8.

   Care-of Keygen Token

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



5.6  Status Codes

   The following new Status codes are allocated:






Arkko, et al.           Expires December 25, 2006              [Page 22]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   Lost Kbmperm State (<To Be Allocated By IANA>)

      This code is returned when the correspondent node does not have a
      Binding Cache Entry, Kbmperm, or has an invalid Binding
      Authorization Data option.  The code MUST only be used in to
      respond to Binding Updates that contain one of the mobility
      options defined in this document.




6.  Security Considerations

   This draft describes a method to exploit the CGA features in order to
   authenticate route optimization signaling.  In fact, the CGA replaces
   the authentication by providing a proof of ownership while the RR
   procedure replaces the authentication by a routing property.

   This proof of ownership ensures that only the mobile node will be
   able to change the routing of packets destined to it, modulo
   exhaustive attacks on the CGA mechanism itself.  The feasibility of
   such attacks and the defenses against them have been discussed in
   [18].

   Note that, as specified, the proof of ownership protection applies
   only to the correspondent node believing the statements made by the
   mobile node.  There is no guarantee that the answers from the
   correspondent node truly come from that correspondent node and not
   from someone who was on the path to the correspondent node during the
   initial contact phase.  This is because we do not require
   correspondent nodes to have CGAs, and as a result, they can not make
   any statements that are authenticated in the strong sense.  We chose
   not to protect against this, because this attack is something that
   already exists in plain IPv6, as is explained in the following.  Lets
   assume that the correspondent node does not care about the IP address
   of the peers contacting it and that it does not protect its payload
   packets cryptographically.  Then, a man-in-the-middle can always use
   its own address when communicating to the correspondent node, and the
   correspondent node's address when communicating to the mobile node.
   Philosophically, one can also argue that since the problem we attempt
   to solve here is routing modifications for the mobile node's address,
   it is sufficient to ensure that these modifications are protected.

   It should be mentioned that while the CGA can provide a protection
   against unauthenticated Binding Update messages, it can expose the
   involved nodes to denial-of-service attacks since it is
   computationally expensive.  The draft limits the use of CGA to only
   the first registration and if/when re-keying is needed.  In addition,



Arkko, et al.           Expires December 25, 2006              [Page 23]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   it is RECOMMENDED that nodes track the amount of resources spent to
   the CGA processing, and disable the processing of new requests when
   these resources exceed a predefined limit.

   The protocol specified in this document relies on standard 16-bit
   Mobile IPv6 sequence numbers and periodic rekeying to avoid replay
   attacks.  Nodes rekey at least once every 24 hours.  Nodes also rekey
   whenever a rollover in the available sequence-number space becomes
   imminent.  Rekeying allows the nodes to reuse sequence numbers
   without exposing themselves to replay attacks.

   This protocol is secure against flooding attacks due to the use of
   care-of-address tests, Credit-Based Authorization, and the use of an
   initial home address test.



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








Arkko, et al.           Expires December 25, 2006              [Page 24]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


8.  IANA Considerations

   This document defines a new CGA Message Type name space for use as
   type tags in messages that may be signed using CGA signatures.  The
   values in this name space are 128-bit unsigned integers.  Values in
   this name space are allocated on a First Come First Served basis [3].
   IANA assigns new 128-bit values directly without a review.

   CGA Message Type values for private use MAY be generated with a
   strong random-number generator without IANA allocation.

   This document defines a new 128-bit value under the CGA Message Type
   [18] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13.

   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 also allocates a new Status code value.



9.  References

9.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]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

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

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

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



Arkko, et al.           Expires December 25, 2006              [Page 25]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


9.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]   Aura, T., "Cryptographically Generated Addresses (CGA)",
         IETF Request for Comments 3972, March 2005.

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

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

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

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

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

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

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

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

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




Arkko, et al.           Expires December 25, 2006              [Page 26]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


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

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

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

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

   [23]  Nikander, P., "Mobile IP version 6 Route Optimization Security
         Design Background", draft-ietf-mip6-ro-sec-03 (work in
         progress), May 2005.

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

   [25]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
         IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress),
         April 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





Arkko, et al.           Expires December 25, 2006              [Page 27]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   Wassim Haddad
   Ericsson Research
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2, Canada

   Email: wassim.haddad@ericsson.com



Appendix A.  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 Greg Daley, Samita Chakrabarti,
   Marcelo Bagnulo, Suresh Krishnan, Mohan Parthasarathy, Lila Madour,
   Francis Dupont, Roland Bless, Mark Doll, and Tobias Kuefner for their
   review and comments on the predecessors of this document.

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



Appendix B.  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
   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



Arkko, et al.           Expires December 25, 2006              [Page 28]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   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
   [4] ASN.1 structure of the type SubjectPublicKeyInfo defined in the
   Internet X.509 certificate profile [5].

   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.

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









Arkko, et al.           Expires December 25, 2006              [Page 29]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


Appendix C.  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
   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



Arkko, et al.           Expires December 25, 2006              [Page 30]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


   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.




















Arkko, et al.           Expires December 25, 2006              [Page 31]

Internet-Draft         CGA and CBA for Mobile IPv6             June 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 December 25, 2006              [Page 32]

Internet-Draft         CGA and CBA for Mobile IPv6             June 2006


Acknowledgment

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















































Arkko, et al.           Expires December 25, 2006              [Page 33]


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