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

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

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


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

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo suggests a new and enhanced route optimization security
   mechanism for Mobile IPv6.  The primary motivation for this new
   mechanism is the reduction of signaling load and handoff delay.  The
   performance improvement achieved is elimination of all signaling



Vogt, et al.            Expires September 7, 2006               [Page 1]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   while not moving, and most of the per-movement signaling can be done
   when payload traffic flow has already been moved.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Efficiency of Base Mobile IPv6 . . . . . . . . . . . . . . .   3
   3.   Overview of CGA  . . . . . . . . . . . . . . . . . . . . . .   5
   4.   Overview of Credit-Based Authorization . . . . . . . . . . .   7
   5.   Protocol . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1  Requirements . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2  Design Rationale . . . . . . . . . . . . . . . . . . . . .   9
     5.3  Overview of Signaling  . . . . . . . . . . . . . . . . . .  11
     5.4  Handling Payload Packets . . . . . . . . . . . . . . . . .  13
     5.5  Credit Aging . . . . . . . . . . . . . . . . . . . . . . .  15
     5.6  Cryptographic Calculations . . . . . . . . . . . . . . . .  16
     5.7  Simultaneous Movements . . . . . . . . . . . . . . . . . .  16
   6.   Option Formats and Status Codes  . . . . . . . . . . . . . .  16
     6.1  The CGA Parameters Option  . . . . . . . . . . . . . . . .  16
     6.2  The Shared Key Option  . . . . . . . . . . . . . . . . . .  17
     6.3  The Signature (SIG) Option . . . . . . . . . . . . . . . .  18
     6.4  The Care-of Test Init Option . . . . . . . . . . . . . . .  19
     6.5  The Care-of Keygen Token Option  . . . . . . . . . . . . .  20
     6.6  Status Codes . . . . . . . . . . . . . . . . . . . . . . .  20
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  21
   8.   Performance Considerations . . . . . . . . . . . . . . . . .  22
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  22
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  23
     10.1   Normative References . . . . . . . . . . . . . . . . . .  23
     10.2   Informative References . . . . . . . . . . . . . . . . .  23
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  25
   A.   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  25
   B.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  25
        Intellectual Property and Copyright Statements . . . . . . .  26

















Vogt, et al.            Expires September 7, 2006               [Page 2]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


1.  Introduction

   This document describes a new and enhanced route optimization (RO)
   security mechanism for Mobile IPv6 [6], based on providing a home
   address ownership proof via Cryptographically Generated Addresses
   (CGAs) [10].  This document uses also a new care-of address-
   verification procedure, Credit-Based Authorization (CBA) [17], to
   protect against redirection-based flooding attacks.

   The main goals of this protocol are the reduction of the signaling
   load and the handoff delay times.  In addition, the protocol offers
   additional security benefits.

   This document is a complete specification of an optional, alternative
   mechanism to the standard scheme, and can be applied independently of
   other specifications.

   This rest of this document is structured as follows.  Section 2
   discusses the performance of the base Mobile IPv6 route optimization
   mechanisms, Section 3 introduces the concept of CGAs, and Section 4
   explains how CBA operates.  Section 5 gives an overview of our new
   mechanism and describes its design rationale.  Section 6 describes
   detailed message formats.  Finally, Section 7 and Section 8 analyze
   the security and performance properties of the mechanism.

2.  Efficiency of Base Mobile IPv6

   This section discusses the efficiency of the base Mobile IPv6 route
   optimization mechanisms defined in RFC [6].

   Note that when evaluating the impact of signaling on performance, one
   should take into account the whole stack and not inspect just one
   layer or task.  For instance, when a mobile node actually moves, the
   Mobile IPv6 signaling has to be compared to the link layer signaling,
   access control and authentication signaling, and IPv6 tasks such as
   router discovery, neighbor discovery, and duplicate address
   detection.  Such other signaling introduces delays, in many cases
   significantly larger delays than exists in Mobile IPv6.  In this
   document we ignore these other delays, however, and concentrate on
   making the mobility signaling as efficient as possible.  But given
   this, an improvement of, say, 50% in mobility signaling may become
   just 10% unless other delays are also addressed.  Other optimization
   work is ongoing in other parts of the stack, however.

   The performance of the base route optimization mechanism can be
   evaluated according to its impact on handover delay, the amount of
   bandwidth it uses per movement, the amount of bandwidth it uses when
   not moving, and the overhead it causes for payload traffic.  These



Vogt, et al.            Expires September 7, 2006               [Page 3]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   are discussed in the following:

   Payload traffic overhead

      The primary reason for using route optimization is to avoid
      routing all traffic through a home agent.  We assume that this
      benefit is significant, particularly when two mobile nodes
      communicate with each other.  However, an overhead is associated
      both with packets sent via bidirectional tunneling (tunnel) and
      directly (options for carrying home addresses).  A more detailed
      analysis of the benefits and drawbacks are outside the scope of
      this document, however, as we concentrate on the signaling aspects
      only.

   Latency

      Basic home registration introduces a latency of zero to one
      roundtrips before payload traffic can flow, depending on which
      direction of traffic is looked at and whether the mobile node
      chooses to wait for an acknowledgement.

      With route optimization, the combined latency is one to three
      roundtrips, depending again on the direction of packets and
      waiting for acknowledgements.

      More specifically, RFC 3775 allows mobile nodes to send data
      packets after having sent the home registration Binding Update
      message.  (If the Binding Update message is lost or packets get
      reordered, the data packets can be lost as well.  But this may
      happen in any case.)

      Home agents and correspondent nodes can start to send data packets
      once they have sent the Binding Acknowledgement.  The overall
      latency until inbound traffic can start flow to the mobile is
      therefore at least 1.5 roundtrips.

      RFC 3775 assumes also that the home and care-of tests are run in
      parallel.  Some implementations may perform poorly, however.  We
      have seen implementations that do not run the home and care-of
      tests in parallel, resulting in an overall delay of 3.5 to 4
      roundtrips.  But even when parallelism is employed, the latency
      across the two different paths can be different.  When two mobile
      nodes are located close to each other, the home test exchange
      typically takes longer than the rest of the messaging.







Vogt, et al.            Expires September 7, 2006               [Page 4]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   Bandwidth usage upon movement

      As discussed in [11], one full run of the return routability and
      binding update procedures is about 376 bytes.  Assuming relatively
      infrequent movements, for instance, every half hour, this
      corresponds to about 1.7 bits/second average bandwidth usage.

      The situation changes when more frequent movements are assumed.
      Using a cell size of 100 meters and the speed of 120 km/h, there
      will be one movement every 3 seconds.  This amounts to a constant
      route optimization-related signaling of about 1,000 bits/second.
      This can be compared to a highly compressed voice stream which
      typically have a rate about 10,000 to 30,000 bits/second.

   Bandwidth usage when not moving

      Base specification requires a periodic return routability test and
      the re-establishment of the binding at the correspondent node.
      This results in an average bandwidth of about 7 bits/second, if
      performed every seven minutes as required in RFC 3775.  While this
      is an insignificant bandwidth for nodes that are actually
      communicating, it can still represent a burden for hosts that just
      have the bindings ready for a possible packet but are not
      currently communicating.  This can be problematic for hosts in
      standby mode, for instance.

   In summary, setting up the route optimization requires some signaling
   and causes some latency.  The latency issue is perhaps more critical
   than the amount of signaling.  This is because internet-wide RTTs are
   typically much longer (some hundreds of milliseconds) than desired
   latencies for real-time applications such as voice over IP (tens of
   milliseconds).  On the other hand, frequent signaling can also be a
   substantial burden on low-powered mobile nodes, particularly if they
   wish to stay in sleep mode for long periods of time.

3.  Overview of CGA

   As described in [10], 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.



Vogt, et al.            Expires September 7, 2006               [Page 5]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


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

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



Vogt, et al.            Expires September 7, 2006               [Page 6]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


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



Vogt, et al.            Expires September 7, 2006               [Page 7]

Internet-Draft         CGA and CBA for Mobile IPv6            March 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 1: 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.

5.  Protocol

   This section discusses first the requirements of the protocol and its
   design rationale.  An overview of the signaling is given after this,
   followed by the rules regarding the cryptographic calculations and a
   discussion of behaviour during simultaneous movements of two mobile
   nodes.

5.1  Requirements

   The desired characteristics of the protocol involve as small latency
   as possible upon movements, and the avoidance of signaling for non-
   moving hosts.  Other things being equal, a protocol which uses the
   smallest amount of bandwidth for signaling should be chosen.

   The security requirements for the protocol are discussed in more



Vogt, et al.            Expires September 7, 2006               [Page 8]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   depth below:

   o  Attackers should not be able to redirect communication flows of
      legitimate hosts to themselves, at least not beyond what is
      already possible in plain IPv6.  This requirement applies both to
      ongoing and future communication flows.

   o  Attackers should not be able to redirect communication flows to
      third parties.  Otherwise, denial-of-service vulnerabilities
      exist; while such vulnerabilities already exist in the current
      Internet, we would like to avoid amplification possibilities
      introduced through mobility mechanisms.

      Note that this requirement applies even to attackers who are
      themselves parties in a legitimate communication with another
      node.

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


5.2  Design Rationale

   The design of the protocol follows the same principles as in the
   original return routability protocol, but adds the following
   mechanisms in order to make it more efficient:

   CGA

      CGA provides more assurance about the correctness of claimed
      address than the pure use of routing paths.  This makes it
      possible to have a significant decrease in the signaling
      frequency.

      In addition, the public keys used in the CGA technique allow
      certain data to be communicated privately between the nodes, which
      makes some of our other techniques possible.

      This technique is taken from appeared originally in [20] and in
      [19].

   Semi-permanent security associations

      CGA alone is not very efficient, due to its reliance public key
      computations and its need for relatively long messages.  We employ
      semi-permanent security associations, created with the help of the
      CGA public keys.  After an initial CGA exchange, this makes



Vogt, et al.            Expires September 7, 2006               [Page 9]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


      subsequent signaling efficient.

      This technique appeared originally in [14].

   Minimal address testing

      CGA is unable to guarantee that a particular address is actually
      reachable at a given prefix.  For this reason there is a need for
      both home and care-of address tests.  However, due to the higher
      security of the CGA technique we can make these test much less
      frequent.

      The home address test is necessary, because otherwise a malicious
      mobile node could create a CGA for the victim network prefix,
      request a stream of packets to its current location from a public
      server, and then let the binding expire.  The result would be a
      flooding attack against the victim network.  In order to avoid
      this, we require an initial home address test at the same time as
      the CGA technique is applied.  Signaling on subsequent movements
      does not need to repeat this test, however.

      This technique appeared originally in [14].

   Credit-Based Authorization

      Base Mobile IPv6 verifies the correctness of a mobile node's
      care-of address through a reachability test.  Without further
      precautions, it is important to complete testing a care-of address
      before data packets are sent to that address, so that flooding
      attacks can be prevented.  However, a "blocking" care-of-address
      test typically has detrimental impacts on handoff efficiency.

      The protocol defined in this document uses Credit-Based
      Authorization to parallelize care-of-address tests with regular
      communications and thus reduces handoff latency.  Credit-Based
      Authorization allows correspondent nodes to start sending data
      packets care-of address even when this address is still
      unverified.

      This technique appeared originally in [17].

   Sequence Numbers

      In Secure Neighbor Discovery (SEND) [8], CGA has been applied
      using time stamps.  However, this requires that the mobile nodes
      have somewhat accurate clocks.  In our application the concept of
      sequence numbers is more appropriate.  Regular Mobile IPv6
      sequence numbers are used even though the number space may be



Vogt, et al.            Expires September 7, 2006              [Page 10]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


      small compared to the relatively long lifetime of a semi-permanent
      security association.  However, rekeying through a full initial
      CGA exchange results in an ability to use the same numbers again.


5.3  Overview of Signaling

   The protocol consists of two individually applicable optimizations
   for the home and care-of address tests.  The home address test
   optimization requires an additional initial establishment phase.  For
   convenience, this overview shows both optimizations applied together.

   The initial phase can be rerun at any time, if either node loses its
   state, but it should be rerun at least once every 24 hours.

   The following figure shows the signaling diagram for the initial
   contact.  The options shown MUST be included in the messages, where
   conformance to this document is claimed.

   1a. MN to CN   (via HA): Home Address Test Init
   1b. MN to CN (directly): Care-of Address Test Init
   2a. CN to MN   (via HA): Home Address Test
   2b. CN to MN (directly): Care-of Address Test
   3.  MN to CN (directly): Binding Update
                            + CGA Parameters + ... + CGA Parameters
                            + SIG + NI + BAD
   4.  CN to MN (directly): Binding Acknowledgment
                            + SKey + BAD

       (The mobile node may start sending payload packets in parallel
       with Step 3.  The correspondent node may start sending payload
       packets in parallel with Step 4.)


   Steps 1a, 1b, 2a, and 2b execute the standard return routability
   procedure from RFC 3775, ensuring that the home and care-of addresses
   are reachable.  It is also needed in order to guard against CPU
   consumption attacks against CGA RSA computations.  Steps 2a and 2b
   provide keygen tokens which are used to construct a Kbm according to
   the usual RFC 3775 rules.

   Step 3 is the usual Binding Update message with additional options
   for the mobile node's CGA Parameters, including the public key, and
   signature.  At the same time, these three options tell the
   correspondent node that the mobile node supports this optimization.
   The Binding Authorization Data option is calculated using the
   standard RFC 3775 rules.  A correspondent node that does not
   implement the optimization will simply fallback to a regular route



Vogt, et al.            Expires September 7, 2006              [Page 11]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   optimization mechanism.

   Otherwise, in Step 4, the correspondent node returns the semi-
   permanent security association key in the SKey option, encrypted with
   the mobile node's public key.

   As a result of the initial procedure, the following state has been
   established in both nodes:

   o  A standard Binding Cache Entry with a care-of address in state
      VERIFIED.  The lifetime of the binding is not as limited as it is
      in standard Mobile IPv6.  The maximum allowed lifetime is 24
      hours.

   o  A semi-permanent security association with a key, Kbmperm.

   o  The public keys and other parameters (see [10]) associated with
      the addresses.

   Security-wise, we know that the parties own their addresses (via
   CGA), and we have some assurance that they are currently at the
   locations they claim to be (via address tests).  Henceforth, the two
   endpoints MUST silently discard any Binding Update or Acknowledgement
   message not signed with the Kbmperm or with an incorrect Mobile IPv6
   sequence number, unless the message is a valid Binding Update message
   that contains CGA Parameters options.  Binding Update messages with
   CGA Parameter options are used to re-initialize the state in the
   correspondent node.

   Note that the initial phase serves to bootstrap the optimizations
   described in this document, but is not optimized itself.  When it is
   desired that the optimizations described in this document are
   immediately effective, the initial phase MAY be proactively
   performed, without having to perform it upon first movement and
   possibly causing delay for payload packet transmission.

   The following figure shows the signaling diagram for subsequent
   movements.













Vogt, et al.            Expires September 7, 2006              [Page 12]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   1. MN to CN (directly): Binding Update + CTI + BAD
   2. CN to MN (directly): Binding Acknowledgment + CKGT + BAD
   3. MN to CN (directly): Binding Update + BAD
   4. CN to MN (directly): Binding Acknowledgment + BAD

      (The mobile node may start sending payload packets in
      parallel with step 1. The correspondent node may start
      sending payload packets, subject to credit limitations
      (cf. Section 5.4), in parallel with step 2. If no credit
      is available, the correspondent node may start sending
      payload packets in parallel with step 4.)


   Steps 1 through 2 implement an "early" Binding Update, where the
   Care-of Test Init (CTI) option instructs the correspondent node to
   re-direct the traffic to the mobile node's new care-of address.  This
   request can be honored only if the mobile node has sufficient credit,
   however (cf. Section 5.4).  The Binding Authorization Data option is
   calculated in these messages using the key Kbmperm.

   Steps 1 and 2 have also another purpose, namely to request the
   correspondent node to send a care-of keygen token to the mobile node
   using the Care-of Keygen Token (CKGT) option.  This provides the same
   functionality as separate Care-of Test Init and Care-of Test
   messages, but reduces the number of messages sent.

   Step 3 and 4 are the final Binding Update and Acknowledgement
   messages.  They are authenticated via Kbmperm' defined as
   HMAC_SHA1(care-of keygen token | Kbmperm).  The correspondent node
   MUST use the sequence number sent in the Binding Update message to
   prevent against replay attacks that use past Binding Update messages.

   Security-wise, at this point we know that we are still talking
   between the same nodes as during the initial contact, since the
   Kbmperm is not known to outsiders.  We have also verified the care-of
   address, to prevent malicious packet redirection.

5.4  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



Vogt, et al.            Expires September 7, 2006              [Page 13]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


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





























Vogt, et al.            Expires September 7, 2006              [Page 14]

Internet-Draft         CGA and CBA for Mobile IPv6            March 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 5: Sending Packets with Credit-Based Authorization



5.5  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



Vogt, et al.            Expires September 7, 2006              [Page 15]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   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.

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

5.7  Simultaneous Movements

   As specified in RFC 3775 [6], 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.

6.  Option Formats and Status Codes

6.1  The CGA Parameters Option

   Options of this type are used to carry the mobile node's public key



Vogt, et al.            Expires September 7, 2006              [Page 16]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   and the CGA parameters needed by the correspondent node to check the
   validity of the mobile node's CGA.  RFC 3775 [6] 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 [10].  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 [10].  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.


6.2  The Shared Key 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



Vogt, et al.            Expires September 7, 2006              [Page 17]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   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 5.6.  The length of Kbmperm value is 20 octets
      (before encryption or padding possibly involved [5]).


6.3  The Signature (SIG) 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.

   The option format is as follows:







Vogt, et al.            Expires September 7, 2006              [Page 18]

Internet-Draft         CGA and CBA for Mobile IPv6            March 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  | 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.


6.4  The 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 |
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+









Vogt, et al.            Expires September 7, 2006              [Page 19]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option = 0.


6.5  The Care-of Keygen Token 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.


6.6  Status Codes

   The following new Status codes are allocated:

   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



Vogt, et al.            Expires September 7, 2006              [Page 20]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


      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.


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

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



Vogt, et al.            Expires September 7, 2006              [Page 21]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   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.

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

9.  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 [2].
   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



Vogt, et al.            Expires September 7, 2006              [Page 22]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


   [10] 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 [6].  This document also allocates a new Status code value.

10.  References

10.1  Normative References

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

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

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

   [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]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
        RFC 3447, February 2003.

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

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

10.2  Informative References

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

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

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

   [11]  Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding



Vogt, et al.            Expires September 7, 2006              [Page 23]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


         Lifetime Extension",
         draft-arkko-mipv6-binding-lifetime-extension-00 (work in
         progress), May 2004.

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

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

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

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

   [16]  Vogt, C., "Early Binding Updates for Mobile IPv6",
         draft-vogt-mip6-early-binding-updates-00 (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]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
         IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress),
         April 2004.

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

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











Vogt, et al.            Expires September 7, 2006              [Page 24]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


Authors' Addresses

   Christian Vogt
   Institute of Telematics
   Universitaet Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe
   Germany

   Email: chvogt@tm.uka.de


   Jari Arkko
   Ericsson Research NomadicLab
   FI-02420 Jorvas
   Finland

   Email: jari.arkko@ericsson.com


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

   Email: wassim.haddad@ericsson.com

Appendix A.  Contributors

   The authors would like to acknowledge that this document consists
   largely of material from [13] and [17] and the contributions of their
   authors, including Lila Madour, Francis Dupont, Roland Bless, Mark
   Doll and Tobias Kuefner.

Appendix B.  Acknowledgments

   The authors would like to thank Pekka Nikander, Tuomas Aura, Greg
   O'Shea, Mike Roe, Gabriel Montenegro, and Vesa Torvinen for
   interesting discussions around CGA.  The authors would also like to
   acknowledge that [15] pioneered the work in the use of CGA for Mobile
   IPv6.

   Finally, we would like to thank Greg Daley, Samita Chakrabarti,
   Marcelo Bagnulo, Suresh Krishnan and Mohan Parthasarathy for their
   review and comments on earlier versions of this document.





Vogt, et al.            Expires September 7, 2006              [Page 25]

Internet-Draft         CGA and CBA for Mobile IPv6            March 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.





Vogt, et al.            Expires September 7, 2006              [Page 26]

Internet-Draft         CGA and CBA for Mobile IPv6            March 2006


Acknowledgment

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















































Vogt, et al.            Expires September 7, 2006              [Page 27]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/