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

Versions: 00

Network Working Group                                            C. Vogt
Internet-Draft                               Universitaet Karlsruhe (TH)
Expires: August 18, 2006                                        J. Arkko
                                            Ericsson Research NomadicLab
                                                       February 14, 2006


  Credit-Based Authorization for Concurrent Reachability Verification
                  draft-vogt-mobopts-simple-cba-00.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 August 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Mobility and multi-homing protocols enable multi-addressed nodes to
   redirect ongoing communication sessions from one IP address to
   another.  Most of these protocols verify a multi-addressed node's
   reachability at a claimed new IP address in order to prevent
   redirection-based flooding attacks.  In view of reduced protocol
   latencies, such verification is preferably performed concurrently,
   i.e., while packets are already being sent to the new IP address.



Vogt & Arkko             Expires August 18, 2006                [Page 1]

Internet-Draft         Credit-Based Authorization          February 2006


   This document defines Credit-Based Authorization, a technique that
   facilitates concurrent reachability verification without compromise
   of security.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Detailed Specification . . . . . . . . . . . . . . . . . . . .  7
     4.1   IP Address States  . . . . . . . . . . . . . . . . . . . .  7
     4.2   Handling Payload Packets . . . . . . . . . . . . . . . . .  8
     4.3   Credit Aging . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     5.1   Conventional Types of Flooding . . . . . . . . . . . . . . 12
     5.2   Redirection-Based Flooding . . . . . . . . . . . . . . . . 13
     5.3   Protection against Redirection-Based Flooding  . . . . . . 13
     5.4   Alternatives to Credit-Based Authorization . . . . . . . . 14
     5.5   Alternatives to Credit Aging . . . . . . . . . . . . . . . 15
   6.  Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1   Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2   Informative References . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 19

























Vogt & Arkko             Expires August 18, 2006                [Page 2]

Internet-Draft         Credit-Based Authorization          February 2006


1.  Introduction

   Mobility and multi-homing protocols enable multi-addressed nodes to
   redirect ongoing communication sessions from one IP address to
   another, be it for the purpose of mobility support, recovery from a
   failure upstream in the network, network renumbering, or a DHCP lease
   expiry.  Many of these protocols operate end to end, and it is a
   multi-addressed node's responsibility to inform its correspondent
   node(s) when it changes IP connectivity.

   An undesired implication of end-to-end packet redirection is that,
   when a correspondent node learns that a multi-addressed peer has a
   new IP address, it does not necessarily know whether the peer is
   actually reachable at that IP address.  In fact, a malicious peer may
   intentionally give a false IP address in order to cause a packet
   flood on the victim located there [6].  Likewise, viral software may
   have compromised the peer, programming it to redirect packets to a
   specific victim.  Such redirection-based flooding is particularly
   serious due to its potential for high amplification:  It is generally
   sufficient for the attacker to spoof small acknowledgments so that
   the correspondent node's instance of the transport protocol continues
   to send larger data packets to the victim.  Similar means for
   amplification are today possible only through distributed denial-of-
   service attacks.

   Most mobility and multi-homing protocols mitigate the threat of
   redirection-based flooding by checking a multi-addressed node's
   reachability at a new IP address before data packets are sent to that
   IP address.  For this, the correspondent node sends an unguessable
   number to the new IP address and waits for this number to be echoed
   by the multi-addressed peer.  In its basic form, reachability
   verification requires the correspondent node to refrain from sending
   packets to the new IP address until the multi-addressed node is known
   to be present at that address.  This causes undesired delays,
   however, which have been shown [7] to compromise the quality of real-
   time applications such as VoIP, video conferencing, and multi-player
   games, and to cause adverse reactions of TCP's retransmission and
   congestion-avoidance mechanisms.  Concurrent reachability
   verification has been proposed as an optimization, but additional
   protection is necessary during the phase when packets are sent to a
   new IP address while it is yet unverified.

   This document specifies a mechanism, Credit-Based Authorization, that
   facilitates secure and concurrent reachability verification.  The
   mechanism is fully transparent to the multi-addressed node.  In
   particular, it does not introduce any signaling between the peers.





Vogt & Arkko             Expires August 18, 2006                [Page 3]

Internet-Draft         Credit-Based Authorization          February 2006


2.  Terminology

   Multi-addressed node
      A mobile or multi-homed node whoose IP address may change.

   Correspondent node
      A multi-addressed node's peer, which may itself be mobile or
      multi-homed.

   Mobility protocol
      A protocol for mobility management executed between a mobile node
      and a correspondent node.  Examples are Mobile IPv6 [5] or the
      mobility extensions [3] of the Host Identity Protocol [2].

   Multi-homing protocol
      A protocol for multi-homing management executed between a multi-
      homed node and a correspondent node.  An example for a site multi-
      homing protocol is the Level 3 Multihoming Shim protocol [4].

   Binding
      The internal state at the correspondent node tying some form of
      identity of a multi-addressed node to the IP address(es) that the
      multi-addressed node uses at a particular time.

   Binding update
      The process of adding a new IP address to a binding or removing an
      existing IP address from a binding.

   Verified IP address
      An IP address at which the multi-addressed node that claims the
      address has been shown to be reachable.

   Unverified IP address
      An IP address for which no reachability verification has yet been
      accomplished.

   Credit
      The number of bytes that a correspondent node has recently
      received from a multi-addressed node.  The correspondent node uses
      the credit to determine how much data it can securely send to an
      unverified IP address of the multi-addressed node.

   Credit counter
      A variable, maintained by the correspondent node, that shows a
      particular multi-addressed node's current credit.

   Credit aging




Vogt & Arkko             Expires August 18, 2006                [Page 4]

Internet-Draft         Credit-Based Authorization          February 2006


      A function that gradually reduces a multi-addressed node's credit
      over time.

   Flooding attack
      A variant of a denial-of-service attack that is characterized by a
      victim being bombarded with unwanted packets at a rate that the
      victim, and possibly the victim's access network, cannot handle.

   Amplification
      The ratio between the data volume that the victim of a flooding
      attack is exposed to and the data volume that the attacker itself
      generates.



3.  Overview

   Concurrent reachability verification requires protection against
   spoofed unverified IP addresses and redirection-based flooding
   attacks.  Credit-Based Authorization is a technique that provides
   such protection based on the following three hypotheses:

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

   2.  An attacker can always cause unamplified flooding by generating
       bogus packets itself and sending them to its victim directly.

   3.  Consequently, the additional effort required to set up a
       redirection-based flooding attack pays off for the attacker only
       if amplification can 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
   IP address of a multi-addressed peer by the data that the
   correspondent node has recently received from that peer.  A
   redirection-based flooding attack thus becomes no more attractive
   than pure direct flooding, where the attacker itself sends bogus
   packets to the victim.  It is actually less attractive given that the
   attacker needs to maintain a context for mobility or multi-homing
   management in order to coordinate the redirection.







Vogt & Arkko             Expires August 18, 2006                [Page 5]

Internet-Draft         Credit-Based Authorization          February 2006


      multi-addressed node      correspondent node
               |                        |
               |                        |
    IP address |--data----------------->| credit += size(data)
      verified |                        |
               |--data----------------->| credit += size(data)
               |<-----------------data--| don't change credit
               |                        |
    IP address + IP address changes     |
    unverified |<-----------------data--| credit -= size(data)
               |--data----------------->| credit += size(data)
               |<-----------------data--| credit -= size(data)
               |                        |
               |<-----------------data--| credit -= size(data)
               |                        X credit < size(data) ==> drop!
               |                        |
    IP address |                        |
      verified |<-----------------data--| don't change credit
               |                        |

                       Figure 1: Credit Maintenance

   Figure 1 illustrates the specifics of Credit-Based Authorization for
   an exemplifying exchange of data packets:  The correspondent node
   measures the bytes received from the multi-addressed node.  These
   bytes are called the multi-addressed node's "credit" and are kept by
   the correspondent node in a "credit counter".  When the multi-
   addressed node changes IP connectivity and registers a new IP
   address, the correspondent node labels this address UNVERIFIED first.
   Packets may be sent to an unverified IP address as long as the packet
   sizes do not exceed the currently available credit.  For each such
   packet, the correspondent node reduces the credit counter by the
   packet size.  The multi-addressed node's reachability at the new IP
   address is meanwhile verified.  Once the verification concludes, the
   correspondent node relabels the new IP address from UNVERIFIED to
   VERIFIED.  Packets can then be sent to the address without
   restrictions.  When insufficient credit is left while the IP address
   is still in UNVERIFIED state, the correspondent node stops sending
   further packets to the address until the verification completes.  The
   correspondent node may drop these packets or buffer them for later
   transmission after the IP address has changed to VERIFIED state.
   Figure 1 does not show signaling packets from a mobility or multi-
   homing protocol.

   The correspondent node ensures that the multi-addressed node's
   acquired credit gradually decreases over time.  This "credit aging"
   prevents the multi-addressed node from building up credit over a long
   time.  A malicious node with a slow Internet connection could



Vogt & Arkko             Expires August 18, 2006                [Page 6]

Internet-Draft         Credit-Based Authorization          February 2006


   otherwise provision for a burst of redirected packets which does not
   relate to its own upstream capacity.

   Credit-Based Authorization does not require support from the multi-
   addressed node and does not introduce any signaling between the
   peers.  A faithful multi-addressed node, communicating with a
   correspondent node in a typical manner, automatically earns credit
   for sending packets to the correspondent node.  It neither needs to
   understand that Credit-Based Authorization is effective at the
   correspondent node, nor does it have to have an idea of how much
   credit it has at a particular point in time.



4.  Detailed Specification

   Credit-Based Authorization requires a correspondent node to store the
   state of each multi-addressed node's IP address(es), maintain a
   credit counter for each multi-addressed node, and execute an
   exponential aging function on each credit counter.  This is explained
   in detail in the following.


4.1  IP Address States

   Mobility and multi-homing protocols typically require a correspondent
   node to bind a multi-addressed node's changing IP address to some
   form of identity of the multi-addressed node.  E.g., in Mobile IPv6
   [5], this "binding" is between a mobile node's home address and
   current care-of address.  In the mobility extensions [3] of the Host
   Identity Protocol [2], the multi-addressed node's current locators
   are bound to a Host Identity Tag. Credit-Based Authorization in
   addition requires the correspondent node to associate each IP address
   with a state, VERIFIED or UNVERIFIED, in order to be able to
   determine whether or not packets sent to the multi-addressed node's
   current IP address are subject to credit limitations.

   When a multi-addressed node changes its point of IP attachment and
   configures a new IP address, a "binding update" is initiated in order
   to inform the correspondent node of that new IP address.  The new IP
   address is initially set to UNVERIFIED state at the correspondent
   node.  The multi-addressed node may start to send packets from the
   new IP address as soon as it has dispatched the signaling message(s)
   that the mobility or multi-homing protocol provides for the binding
   update.  However, packets that the correspondent node may sent to an
   IP address in UNVERIFIED state are subject to the limitations
   specified in Section 4.2.




Vogt & Arkko             Expires August 18, 2006                [Page 7]

Internet-Draft         Credit-Based Authorization          February 2006


   At some time after the multi-addressed node has sent the signaling
   message(s) for the binding update, the mobility or multi-homing
   protocol initiates reachability verification for the new IP address
   and conveys the result to the correspondent node.

   If reachability verification confirms that the multi-addressed node
   is present at the new IP address, the correspondent node changes the
   state of this address from UNVERIFIED to VERIFIED.  Any limits
   imposed on packets that the correspondent node sends to the new IP
   address do no longer apply as of then.

   If the outcome of reachability verification is that the multi-
   addressed node is not reachable at the new IP address, the
   correspondent node MUST stop sending packets to that IP address.
   However, the correspondent node MAY keep the unverified IP address
   within the binding and continue to accept packets that the multi-
   addressed node sends from the IP address.  This is reasonable given
   that reachability verification may fail for reasons outside the
   influence of the multi-addressed node, e.g., due to packet loss on
   the path between the multi-addressed node and the correspondent node.
   It is the responsibility of the mobility or multi-homing protocol to
   repeat reachability verification an appropriate number of times in
   case of failure.


4.2  Handling Payload Packets

   A correspondent node maintains a credit counter for each multi-
   addressed node it communicates with.  All IP addresses within a
   binding, both verified and unverified ones, map to the same credit
   counter.  New credit counters are initialized to zero.




















Vogt & Arkko             Expires August 18, 2006                [Page 8]

Internet-Draft         Credit-Based Authorization          February 2006


    inbound    ___________________
     packet   |                   |
       |      |   locate peer's   |
       '----> |    binding and    |
              |   credit counter  |
              '___________________'
                        |
                        |
                        |
                        v
               ___________________                ___________________
              |                   |              |                   |
              |     increase      |              |  deliver packet   |
              |  credit counter   |------------> |  to application   |
              |  by packet size   |              |                   |
              '___________________'              '___________________'

                     Figure 2: Inbound Packet Handling

   When the correspondent node receives a packet from a multi-addressed
   node (cf. Figure 2), and the packet's IPv6 Source Address is
   currently bound to the multi-addressed node, the correspondent node
   SHOULD increase that multi-addressed node's credit counter by the
   size of the received packet.  In particular, it does not matter
   whether the state of the packet's IPv6 Source Address is VERIFIED or
   UNVERIFIED.

























Vogt & Arkko             Expires August 18, 2006                [Page 9]

Internet-Draft         Credit-Based Authorization          February 2006


    outbound   ___________________
     packet   |                   |
       |      |   locate peer's   |
       '----> |    binding and    |
              |   credit counter  |
              '___________________'
                        |
                        |
                        |
                        v
                 _______________                  ___________________
                /               \                |                   |
              /   IP address in   \     yes      |    send packet    |
             |    VERIFIED state   |-----------> |  to IP address in |
              \      exists?      /              |   VERIFIED state  |
                \_______________/                '___________________'
                        |
                        | no
                        |
                        v
                 _______________                  ___________________
                /               \                |                   |
              /   IP address in   \     no       |  drop or buffer   |
             |   UNVERIFIED state  |-----------> |    the packet     |
              \      exists?      /              |                   |
                \_______________/                '___________________'
                        |
                        | yes
                        |
                        v
                 _______________                  ___________________
                /               \                |                   |
              /   credit counter  \      no      |  drop or buffer   |
             |          >=         |-----------> |    the packet     |
              \    packet size?   /              |                   |
                \_______________/                '___________________'
                        |
                        | yes
                        |
                        v
               ___________________                ___________________
              |                   |              |                   |
              |      reduce       |              |    send packet    |
              |  credit counter   |------------> |  to IP address in |
              |  by packet size   |              |  UNVERIFIED state |
              '___________________'              '___________________'

                    Figure 3: Outbound Packet Handling



Vogt & Arkko             Expires August 18, 2006               [Page 10]

Internet-Draft         Credit-Based Authorization          February 2006


   When the correspondent node has a packet for the multi-addressed node
   (cf. Figure 3), it SHOULD send the packet to an IP address in
   VERIFIED state if such an address exists in the multi-addressed
   node's binding.  In case no IP address currently bound to the multi-
   addressed node is in VERIFIED state, the correspondent node selects
   an IP address in UNVERIFIED state provided that such an address is
   available.  If an unverified IP address exists, the correspondent
   node checks to see whether it can send the packet to that address:
   In case the value of the credit counter is higher than the size of
   the packet or equal to it, the correspondent node reduces the credit
   counter by the packet size and sends the packet to the unverified IP
   address.  If the credit counter is too low, the packet MUST be
   discarded or buffered until reachability verification succeeds.
   Should the mobility or multi-homing protocol support a stable IP
   address via which the multi-addressed node is permanently reachable,
   possibly through a sub-optimal routing path, the correspondent node
   may also send the packets to that stable IP address until the multi-
   addressed node becomes again directly reachable through a verified IP
   address.  A Mobile IPv6 home address is an example of such a stable
   IP address.


4.3  Credit Aging

   The correspondent node ensures that all credit counters maintained
   for its multi-addressed peers gradually decrease over time.  For
   this, it multiplies each credit counter with a factor,
   CreditAgingFactor, of less than one in fixed time intervals of
   CreditAgingInterval length.  Such credit aging prevents a malicious
   peer with poor uplink capacity from building up credit at a very slow
   speed and using this, all at once, for a burst of redirected packets.
   At the same time, credit aging naturally limits the rate at which the
   correspondent node can durably sent to an IP address in UNVERIFIED
   state.

   Choosing appropriate values for CreditAgingFactor and
   CreditAgingInterval is important to facilitate applications where the
   correspondent node sends at a higher rate than the multi-addressed
   node.  If CreditAgingFactor or CreditAgingInterval are too small, the
   credit counter might be too low to allow for packets being sent to an
   unverified IP address.  The values specified in this document work
   well when the host transfers a file to the peer via a TCP connection
   and the end-to-end round-trip time does not exeed 500 milliseconds.








Vogt & Arkko             Expires August 18, 2006               [Page 11]

Internet-Draft         Credit-Based Authorization          February 2006


5.  Security Considerations

   Essentially three types of flooding attacks are already possible in
   today's Internet:  direct attacks, reflection attacks, and
   distributed attacks.  The following analysis compares these attack
   types with those that could become possible by the introduction of
   mobility and multi-homing support if no preventive measures are
   taken.  The power of a flooding attack is thereby measured by its
   potential for amplification.  It is shown that the new attack types
   would facilitate much higher amplification than conventional attack
   types, and that a combination of concurrent reachability verification
   and Credit-Based Authorization can neutralize this disadvantage.


5.1  Conventional Types of Flooding

   In a direct flooding attack, the attacker simply generates the
   flooding packets and sends them to the victim by itself.  Direct
   flooding attacks are an inherent vulnerability of the Internet
   architecture given that the routing infrastructure delivers packets
   independently of whether they have actually been requested by the
   recipient.  Firewalls mitigate the issue to some extent in that they
   block undesired traffic at some point close to the end of the routing
   path.  The flooding packets are thus screened from a victim node.  On
   the other hand, the flooding packets may still exhaust downstream
   capacities of an entire network.  Firewalls are generally unsuitable
   to prevent this.  Inverse firewalls at the attacker's side screen the
   undesired traffic close to the source, but most likely an attacker
   can choose a location where inverse firewalling is not performed.

   In an indirect reflection attack, the attacker tricks a third node,
   the reflection point, into sending packets to the victim.  The
   attacker typically uses a known protocol vulnerability to make the
   reflection point generate these packets [12].  One example is that
   the attacker sends ICMP Echo Request packets, with the IPv6 Source
   Address fields set to the victim's IP address, to the reflection
   point.  The reflection point, in turn, sends ICMP Echo Reply packets
   "back" to the victim.  Another example is that the attacker sends TCP
   SYN packets, again with false source addresses, to the reflection
   point, which in turn sends TCP SYN-ACK packets to someone who does
   not expect these packets.  Since most TCP servers are configured so
   that they resend a TCP SYN packet multiple times when failing to
   receive an acknowledgment, this reflection attack can even produce
   small amplification.  As the examples show, reflection attacks are
   generally characterized by the attacker sending packets with spoofed
   IPv6 Source Address fields.  The amplification possible through
   reflection is generally rather limited, however, since most protocols
   refrain from sending large amounts of data to an address before some



Vogt & Arkko             Expires August 18, 2006               [Page 12]

Internet-Draft         Credit-Based Authorization          February 2006


   assurance has been obtained that there is indeed a node willing to
   accept packets at the other end.

   Distributed flooding attacks provide more significant amplification.
   Here, the attacker takes over control of other nodes by compromising
   them with viral software, which it typically distributes by
   conventional means.  The infected nodes are then programmed to
   jointly send packets to the victim.  Typically, the attack proceeds
   automatically, and the attacker itself does not send itself packets
   to the victim.  Distributed flooding attacks are of a different
   quality than the flooding attacks described afore because they
   generally exploit implementation vulnerabilities in operating systems
   rather than vulnerabilities in standard networking protocols.


5.2  Redirection-Based Flooding

   Redirection-based flooding attacks are a fourth attack type, which
   mobility and multi-homing protocols could introduce if they fail to
   provide appropriate protection.  In such an attack, the perpetrator
   requests a server to transmit a large file, e.g., a video, and
   subsequently misuses a mobility or multi-homing protocol to redirect
   this download to the IP address of its victim.  The transport
   protocol may require the attacker to spoof acknowledgment on behalf
   of the victim.  But since the acknowledgments are typically smaller
   in size and number than the data packets that the server generates,
   the amplification in this attack can be much higher than in the
   discussed ICMP and TCP flooding attacks.

   Today's transport protocols were developed for an Internet where
   nodes use stable IP addresses, hence most of them perform
   reachability verification, if at all, only at some early stage during
   connection establishment.  E.g., TCP requires the receiver to obtain
   a random 32-bit sequence number during the initial handshake.
   Mobility and multi-homing protocols defeat the purpose of such
   reachability verification as they introduce the ability to redirect
   packets subsequently to the initial handshake.  Referring to the
   example of the TCP download, the attacker could execute the initial
   handshake procedure via its own IP address, and use the sequence
   number obtained that way to spoof acknowledgments after it has
   redirected the session to the IP address of its victim.


5.3  Protection against Redirection-Based Flooding

   Most mobility and multi-homing protocols execute an IP-layer
   reachability check as a protection against redirection-based flooding
   whenever a node changes its IP address.  Given that the delay of such



Vogt & Arkko             Expires August 18, 2006               [Page 13]

Internet-Draft         Credit-Based Authorization          February 2006


   a check can have a noticable impact on applications, a
   straightforward strategy is to execute reachability verification
   concurrently while packets are already being sent to the new IP
   address.  This requires additional protection for the phase during
   which packets are sent to the new IP address although the validity of
   that IP address is still questionable.  Credit-Based Authorization
   provides this protection in that it limits the impact of such
   redirection to what could also be accomplished---with much less
   coordinative effort---through a direct flooding attack.
   Specifically, the combination of concurrent reachability verification
   and Credit-Based Authorization does not prevent malicious redirection
   per se, but it prevents its use from a location off the path towards
   the flooded victim as well as any amplification in the quantity of
   redirected packets.  As a result, a redirection-based flooding attack
   becomes as effective as a direct flooding attack.


5.4  Alternatives to Credit-Based Authorization

   There are alternatives to Credit-Based Authorization which can
   protect against misuse of mobility or multi-homing protocols for
   redirection-based flooding attacks.  One alternative is to perform
   reachability verification in a concurrent way only with nodes from a
   trusted community.  Mobility and multi-homing protocols usually
   authenticate a node during a binding update, providing a way for
   secure identification.  The correspondent node can thus decide
   whether or not to use the new IP address before the result of
   reachability verification becomes known.  For instance, the
   correspondent node may be a corporate server which grants concurrent
   reachability verification exlusively to nodes from the corporate
   network.

   Mobility and multi-homing protocols that use the IPv6 Source Address
   field to signal a new IP address to the correspondent node may rely
   on ingress filtering [11] to be enforced within the multi-addressed
   nodes' networks.  Ingress filtering is a function that routers may
   execute to prevent packets with spoofed source addresses from leaving
   a network.  The natural crux with ingress filtering, however, is that
   the correspondent node in general does not know whether or not
   ingress filtering has been performed on packets received from a
   particular multi-addressed node.  Furthermore, the granularity of
   ingress filtering decreases with the distance between the access
   network and the router that executes it.  In an optimal case, ingress
   filtering is directly applied in the first-hop router.  But even then
   may an attacker use a false IPv6 Source Address as long as the
   network prefix is correct.

   A third alternative to Credit-Based Authorization is to identify and



Vogt & Arkko             Expires August 18, 2006               [Page 14]

Internet-Draft         Credit-Based Authorization          February 2006


   blacklist malicious nodes based on their observed behavior.  Credit-
   Based Authorization is a proactive strategy, whereas behavior-based
   blacklisting is a reactive one.  The advantage of a reactive approach
   is that a faithful multi-addressed node does not need to invest
   effort (i.e., collect credit) in order to be able to receive packets
   at an unverified IP address.  This can accommodate a multi-addressed
   node having trouble to collect sufficient credit---be it because its
   IP address changes too frequently, or because its application
   generates too little data.  On the other hand, a reactive approach by
   definition fails to prevent misuse of concurrent reachability
   verification in advance.  What it can do is contain the damage of
   such misuse and punish the perpetrator.  Punishment depends on an
   administrative relationship between the multi-addressed node and the
   correspondent node, however, and such a relationship may not exist.
   finally, behavior-based blacklisting requires a heuristic to
   determine what behavior is considered "ill".  Yet choosing the right
   heuristic is far from trivial.  An inappropriate heuristic may punish
   a faithful mobile node or overlook an evil one.


5.5  Alternatives to Credit Aging

   Credit-Based Authorization uses exponential aging to slowly reduce
   collected credit over time.  An alternative to exponential aging
   would be a constant upper bound on the credit.  However, such a limit
   would allow an attacker to acquire credit at a very slow speed,
   possibly through a slow Internet connection, and to use this credit
   quickly for a burst of packets redirected to a victim.  Collected
   credit may also be kept for a long time before it is eventually used.
   This would allow the attacker to build up credit at multiple
   correspondent nodes one after another.  Finally, a constant limit
   would be insensitive to throughput conditions on the path between the
   multi-addressed node and the correspondent node.  A limit for a low-
   bandwidth connection is certainly inappropriate for a high-bandwidth
   connection, and vice versa.  Exponential aging does not have these
   disadvantages and was thus considered a more appropriate approach
   than limiting a mobile node's credit by a constant upper bound.



6.  Protocol Constants

         CreditAgingFactor        7/8
         CreditAgingInterval      5 seconds







Vogt & Arkko             Expires August 18, 2006               [Page 15]

Internet-Draft         Credit-Based Authorization          February 2006


7.  Acknowledgment

   The necessity for a mechanism to prevent or discourage misuse of
   concurrent reachability verification for amplified redirection-based
   flooding attacks was sparked by a fruitful discussion on the MIP6 and
   MOBOPTS mailing lists.  Credit-Based Authorization was developed as a
   candidate solution, and a first presentation was given at the 59th
   IETF meeting in Seoul, Republic of Korea.  For their interest and
   valuable feedback, the authors thank the MIP6 and MOBOPTS
   communities, in particular Roland Bless, Mark Doll, Francis Dupont,
   Gregory Daley, Lars Eggert, James Kempf, Rajeev Koodli, Tobias
   Kuefner, Marco Liebsch, Gabriel Montenegro, Nick (Sharkey) Moore,
   Pekka Nikander, Erik Nordmark, Charles Perkins, and Kilian Weniger
   (listed in alphabetical order).  Thanks are also due to the
   development team of the Kame-Shisa Mobile IPv6 implementation.



8.  References

8.1  Normative References

   [1]  Vogt, C., "Early Binding Updates for Mobile IPv6",
        draft-vogt-mobopts-early-binding-updates (work in progress)
        (work in progress).

8.2  Informative References

   [2]   Moskowitz, R., Nikander, P., Jokela, P., and T. R., "Host
         Identity Protocol", IETF Internet Draft
         draft-ietf-hip-base-04.txt (work in progress), October 2005.

   [3]   Henderson, T., "End-Host Mobility and Multihoming with the Host
         Identity Protocol", IETF Internet Draft
         draft-ietf-hip-mm-02.txt (work in progress), July 2005.

   [4]   Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
         protocol", IETF Internet Draft draft-ietf-shim6-proto-03.txt
         (work in progress), December 2005.

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

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




Vogt & Arkko             Expires August 18, 2006               [Page 16]

Internet-Draft         Credit-Based Authorization          February 2006


   [7]   Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
         IPv6", To appear in the proceedings of the IEEE Wireless
         Communications and Networking Conference, IEEE, April 2006.

   [8]   Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
         Nordmark, "Mobile IP version 6 Route Optimization Security
         Design Background", draft-ietf-mip6-ro-sec (work in progress)
         (work in progress).

   [9]   Aura, T., Roe, M., and J. Arkko, "Security of Internet Location
         Management",  In Proceedings of the 18th Annual Computer
         Security Applications Conference, Las Vegas, Nevada, USA.,
         December 2002.

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

   [11]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", RFC 2827, May 2000.

   [12]  Paxson, V., "An Analysis of Using Reflectors for Distributed
         Denial-of-Service Attacks",  Computer Communication Review
         31(3)., July 2001.

   [13]  Anderson, R., "Why Information Security is Hard -- An Economic
         Perspective",  In Proceedings of the 17th Annual Computer
         Security Applications Conference, New Orleans, Louisiana, USA.,
         December 2001.

   [14]  Perkins, C., "Precomputable Binding Management Key Kbm for
         Mobile IPv6", draft-ietf-mip6-precfgkbm (work in progress)
         (work in progress).


Authors' Addresses

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

   Email: chvogt@tm.uka.de




Vogt & Arkko             Expires August 18, 2006               [Page 17]

Internet-Draft         Credit-Based Authorization          February 2006


   Jari Arkko
   Ericsson Research NomadicLab
   FI-02420 Jorvas
   Finland

   Email: jari.arkko@ericsson.com













































Vogt & Arkko             Expires August 18, 2006               [Page 18]

Internet-Draft         Credit-Based Authorization          February 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.


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.


Acknowledgment

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




Vogt & Arkko             Expires August 18, 2006               [Page 19]


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