    Network Working Group                                         M. Bagnulo
    Request for Comments: 5535                                          UC3M
    Category: Standards Track                                      June 2009

                           Hash-Based Addresses (HBA)

    Status of This Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (c) 2009 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents in effect on the date of
       publication of this document (http://trustee.ietf.org/license-info).
       Please review these documents carefully, as they describe your rights
       and restrictions with respect to this document.

       This document may contain material from IETF Documents or IETF
       Contributions published or made publicly available before November
       10, 2008.  The person(s) controlling the copyright in some of this
       material may not have granted the IETF Trust the right to allow
       modifications of such material outside the IETF Standards Process.
       Without obtaining an adequate license from the person(s) controlling
       the copyright in such materials, this document may not be modified
       outside the IETF Standards Process, and derivative works of it may
       not be created outside the IETF Standards Process, except to format
       it for publication as an RFC or to translate it into languages other
       than English.

    Abstract

       This memo describes a mechanism to provide a secure binding between
       the multiple addresses with different prefixes available to a host
       within a multihomed site.  This mechanism employs either
       Cryptographically Generated Addresses (CGAs) or a new variant of the
       same theme that uses the same format in the addresses.  The main idea
       in the new variant is that information about the multiple prefixes is
       included within the addresses themselves.  This is achieved by
       generating the interface identifiers of the addresses of a host as

    Bagnulo                     Standards Track                     [Page 1]

    RFC 5535                          HBA                          June 2009

       hashes of the available prefixes and a random number.  Then, the
       multiple addresses are generated by prepending the different prefixes
       to the generated interface identifiers.  The result is a set of
       addresses, called Hash-Based Addresses (HBAs), that are inherently
       bound to each other.

    Table of Contents

       1. Introduction ....................................................3
       2. Terminology .....................................................4
       3. Overview ........................................................4
          3.1. Threat Model ...............................................4
          3.2. Overview ...................................................4
          3.3. Motivations for the HBA Design .............................5
       4. Cryptographic Generated Addresses (CGAs) Compatibility
          Considerations ..................................................6
       5. Multi-Prefix Extension for CGA ..................................8
       6. HBA-Set Generation ..............................................9
       7. HBA Verification ...............................................11
          7.1. Verification That a Particular HBA Address
               Corresponds to a Given CGA Parameter Data Structure .......11
          7.2. Verification That a Particular HBA Address Belongs to the
               HBA Set Associated with a Given CGA Parameter Data
               Structure .................................................11
       8. Example of HBA Application in a Multihoming Scenario ...........13
          8.1. Dynamic Address Set Support ...............................16
       9. DNS Considerations .............................................17
       10. IANA Considerations ...........................................18
       11. Security Considerations .......................................18
          11.1. Security Considerations When Using HBAs in the
                Shim6 Protocol ...........................................20
          11.2. Privacy Considerations ...................................22
          11.3. SHA-1 Dependency Considerations ..........................22
          11.4. DoS Attack Considerations ................................22
       12. Contributors ..................................................23
       13. Acknowledgments ...............................................23
       14. References ....................................................24
          14.1. Normative References .....................................24
          14.2. Informative References ...................................24

    Bagnulo                     Standards Track                     [Page 2]

    RFC 5535                          HBA                          June 2009

    1.  Introduction

       In order to preserve inter-domain routing system scalability, IPv6
       sites obtain addresses from their Internet Service Providers (ISPs).
       Such an addressing strategy significantly reduces the amount of
       routes in the global routing tables, since each ISP only announces
       routes to its own address blocks, rather than announcing one route
       per customer site.  However, this addressing scheme implies that
       multihomed sites will obtain multiple prefixes, one per ISP.
       Moreover, since each ISP only announces its own address block, a
       multihomed site will be reachable through a given ISP if the ISP
       prefix is contained in the destination address of the packets.  This
       means that, if an established communication needs to be routed
       through different ISPs during its lifetime, addresses with different
       prefixes will have to be used.  Changing the address used to carry
       packets of an established communication exposes the communication to
       numerous attacks, as described in [11], so security mechanisms are
       required to provide the required protection to the involved parties.
       This memo describes a tool that can be used to provide protection
       against some of the potential attacks, in particular against future/
       premeditated attacks (aka time shifting attacks in [12]).

       This memo describes a mechanism to provide a secure binding between
       the multiple addresses with different prefixes available to a host
       within a multihomed site.

       It should be noted that, as opposed to the mobility case where the
       addresses that will be used by the mobile node are not known a
       priori, the multiple addresses available to a host within the
       multihomed site are pre-defined and known in advance in most of the
       cases.  The mechanism proposed in this memo employs either
       Cryptographically Generated Addresses (CGAs) [2] or a new variant of
       the same theme that uses the same format in the addresses.  The new
       variant, Hash-Based Address (HBA), takes advantage of the address set
       stability.  In either case, a secure binding between the addresses of
       a node in a multihomed site can be provided.  CGAs employ public key
       cryptography and can deal with changing address sets.  HBAs employ
       only symmetric key cryptography, and have smaller computational
       requirements.

       For the purposes of the Shim6 protocol, the other characteristics of
       the CGAs and HBAs are similar.  Both can be generated by the host
       itself without any reliance on external infrastructure.  Both employ
       the same format of addresses and same format of data fed to generate
       the addresses.  It is not required that all interface identifiers of
       a node's addresses be equal, preserving some degree of privacy
       through changes in the addresses used during the communications.

    Bagnulo                     Standards Track                     [Page 3]

    RFC 5535                          HBA                          June 2009

       The main idea in HBAs is that information about the multiple prefixes
       is included within the addresses themselves.  This is achieved by
       generating the interface identifiers of the addresses of a host as
       hashes of the available prefixes and a random number.  Then, the
       multiple addresses are obtained by prepending the different prefixes
       to the generated interface identifiers.  The result is a set of
       addresses that are inherently bound.  A cost-efficient mechanism is
       available to determine if two addresses belong to the same set, since
       given the prefix set and the additional parameters used to generate
       the HBA, a single hash operation is enough to verify if an HBA
       belongs to a given HBA set.

    2.  Terminology

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in RFC 2119 [1].

    3.  Overview

    3.1.  Threat Model

       The threat analysis for the multihoming problem is described in [11].
       This analysis basically identifies attacks based on redirection of
       packets by a malicious attacker towards addresses that do not belong
       to the multihomed node.  There are essentially two types of
       redirection attacks: communication hijacking and flooding attacks.
       Communication hijacking attacks are about an attacker stealing on-
       going and/or future communications from a victim.  Flooding attacks
       are about redirecting the traffic generated by a legitimate source
       towards a third party, flooding it.  The HBA solution provides full
       protection against the communication hijacking attacks.  The Shim6
       protocol [9] protects against flooding attacks.  Residual threats are
       described in the "Security Considerations" section.

    3.2.  Overview

       The basic goal of the HBA mechanism is to securely bind together
       multiple IPv6 addresses that belong to the same multihomed host.
       This allows rerouting of traffic without worrying that the
       communication is being redirected to an attacker.  The technique that
       is used is to include a hash of the permitted prefixes in the
       low-order bits of the IPv6 address.

       So, eliding some details, say the available prefixes are A, B, C, and
       D, the host would generate a prefix list P consisting of (A,B,C,D)
       and a random number called Modifier M.  Then it would generate the
       new addresses:

    Bagnulo                     Standards Track                     [Page 4]

    RFC 5535                          HBA                          June 2009

       A || H(M || A || P)

       B || H(M || B || P)

       C || H(M || C || P)

       D || H(M || D || P)

       Thus, given one valid address out of the group and the prefix list P
       and the random Modifier M it is possible to determine whether another
       address is part of the group by computing the hash and checking
       against the low-order bits.

    3.3.  Motivations for the HBA Design

       The design of the HBA technique was driven by the following
       considerations:

       First of all, the goal of HBA is to provide a secure binding between
       the IPv6 address used as an identifier by the upper-layer protocols
       and the alternative locators available in the multihomed node so that
       redirection attacks are prevented.

       Second, in order to achieve such protection, the selected approach
       was to include security information in the identifier itself, instead
       of relying on third trusted parties to secure the binding, such as
       the ones based on repositories or Public Key Infrastructure.  This
       decision was driven by deployment considerations, i.e., the cost of
       deploying the trusted third-party infrastructure.

       Third, application support considerations described in [16] resulted
       in selecting routable IPv6 addresses to be used as identifiers.
       Hence, security information is stuffed within the interface
       identifier part of the IPv6 address.

       Fourth, performance considerations as described in [17] motivated the
       usage of a hash-based approach as opposed to a public-key-based
       approach based on pure Cryptographic Generated Addresses (CGA), in
       order to avoid imposing the performance of public key operations for
       every communication in multihomed environments.  The HBA approach
       presented in this document presents a cheaper alternative that is
       attractive to many common usage cases.  Note that the HBA approach
       and the CGA approaches are not mutually exclusive and that it is
       possible to generate addresses that are both valid CGA and HBA
       addresses providing the benefits of both approaches if needed.

    Bagnulo                     Standards Track                     [Page 5]

    RFC 5535                          HBA                          June 2009

    4.  Cryptographic Generated Addresses (CGAs) Compatibility
        Considerations

       As described in the previous section, the HBA technique uses the
       interface identifier part of the IPv6 address to encode information
       about the multiple prefixes available to a multihomed host.  However,
       the interface identifier is also used to carry cryptographic
       information when Cryptographic Generated Addresses (CGAs) [2] are
       used.  Therefore, conflicting usages of the interface identifier bits
       may result if this is not taken into account during the HBA design.
       There are at least two valid reasons to provide CGA-HBA
       compatibility:

       First, the current Secure Neighbor Discovery (SeND) specification [3]
       uses the CGAs defined in [2] to prove address ownership.  If HBAs are
       not compatible with CGAs, then nodes using HBAs for multihoming
       wouldn't be able to do Secure Neighbor Discovery using the same
       addresses (at least the parts of SeND that require CGAs).  This would
       imply that nodes would have to choose between security (from SeND)
       and fault tolerance (from IPv6 multihoming support provided by the
       Shim6 protocol [9]).  In addition to SeND, there are other protocols
       that are considered to benefit from the advantages offered by the CGA
       scheme, such as mobility support protocols [13].  Those protocols
       could not be used with HBAs if HBAs are not compatible with CGAs.

       Second, CGAs provide additional features that cannot be achieved
       using only HBAs.  In particular, because of its own nature, the HBA
       technique only supports a predetermined prefix set that is known at
       the time of the generation of the HBA set.  No additions of new
       prefixes to this original set are supported after the HBA set
       generation.  In most of the cases relevant for site multihoming, this
       is not a problem because the prefix set available to a multihomed set
       is not very dynamic.  New prefixes may be added in a multihomed site
       when a new ISP is available, but the timing of those events are
       rarely in the same time scale as the lifetime of established
       communications.  It is then enough for many situations that the new
       prefix is not available for established communications and that only
       new communications benefit from it.  However, in the case that such
       functionality is required, it is possible to use CGAs to provide it.
       This approach clearly requires that HBA and CGA approaches be
       compatible.  If this is the case, it then would be possible to create
       HBA/CGA addresses that support CGA and HBA functionality
       simultaneously.  The inputs to the HBA/CGA generation process will be
       both a prefix set and a public key.  In this way, a node that has
       established a communication using one address of the CGA/HBA set can
       tell its peer to use the HBA verification when one of the addresses

    Bagnulo                     Standards Track                     [Page 6]

    RFC 5535                          HBA                          June 2009

       of its HBA/CGA set is used as locator in the communication or to use
       CGA (public-/private-key-based) verification when a new address that
       does not belong to the HBA/CGA set is used as locator in the
       communication.

       So, because of the aforementioned reasons, it is a goal of the HBA
       design to define HBAs in such a way that they are compatible with
       CGAs as defined in [2] and their usages described in [3]
       (consequently, to understand the rest of this note, the reader should
       be familiar with the CGA specification defined in [2]).  This means
       that it must be possible to generate addresses that are both an HBA
       and a CGA, i.e., that the interface identifier contains cryptographic
       information of CGA and the prefix-set information of an HBA.  The CGA
       specification already considers the possibility of including
       additional information into the CGA generation process through the
       usage of Extension Fields in the CGA Parameter Data Structure.  It is
       then possible to define a Multi-Prefix extension for CGA so that the
       prefix set information is included in the interface identifier
       generation process.

       Even though a CGA compatible approach is adopted, it should be noted
       that HBAs and CGAs are different concepts.  In particular, the CGA is
       inherently bound to a public key, while an HBA is inherently bound to
       a prefix set.  This means that a public key is not required to
       generate an HBA-only address.  Because of that, we define three
       different types of addresses:

       -  CGA-only addresses:  These are addresses generated as specified in
          [2] without including the Multi-Prefix extension.  They are bound
          to a public key and to a single prefix (contained in the basic CGA
          Parameter Data Structure).  These addresses can be used for SeND
          [3]; if used for multihoming, their application will have to be
          based on the public key usage.

       -  CGA/HBA addresses:  These addresses are CGAs that include the
          Multi-Prefix extension in the CGA Parameter Data Structure used
          for their generation.  These addresses are bound to a public key
          and a prefix set and they provide both CGA and HBA
          functionalities.  They can be used for SeND as defined in [3] and
          for any usage defined for HBA (such as a Shim6 protocol).

       -  HBA-only addresses:  These addresses are bound to a prefix set but
          they are not bound to a public key.  Because HBAs are compatible
          with CGA, the CGA Parameter Data Structure will be used for their
          generation, but a random nonce will be included in the Public Key
          field instead of a public key.  These addresses can be used for
          HBA-based multihoming protocols, but they cannot be used for SeND.

    Bagnulo                     Standards Track                     [Page 7]

    RFC 5535                          HBA                          June 2009

    5.  Multi-Prefix Extension for CGA

       The Multi-Prefix extension has the following TLV format as defined in
       [8]:

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Extension Type        |   Extension Data Length       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |P|                         Reserved                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                           Prefix[1]                           +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                           Prefix[2]                           +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         .                               .                               .
         .                               .                               .
         .                               .                               .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                           Prefix[n]                           +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Ext Type:  16-bit type identifier of the Multi-Prefix extension (see
          the "IANA Considerations" section).

       Ext Len:  16-bit unsigned integer.  Length of the Extension in
          octets, not including the first 4 octets.

       P flag:  Set if a public key is included in the Public Key field of
          the CGA Parameter Data Structure, reset otherwise.

       Reserved:  31-bit reserved field.  MUST be initialized to zero, and
          ignored upon receipt.

       Prefix[1...n]:  Vector of 64-bit prefixes, numbered 1 to n.

    Bagnulo                     Standards Track                     [Page 8]

    RFC 5535                          HBA                          June 2009

    6.  HBA-Set Generation

       The HBA generation process is based on the CGA generation process
       defined in Section 4 of [2].  The goal is to require the minimum
       amount of changes to the CGA generation process.  It should be noted
       that the following procedure is only valid for Sec values of 0, 1,
       and 2.  For other Sec values, RFC 4982 [10] has defined a CGA SEC
       registry that will contain the specifications used to generate CGAs.
       The generation procedures defined in such specifications must be used
       for Sec values other than 0, 1, or 2.

       The CGA generation process has three inputs: a 64-bit subnet prefix,
       a public key (encoded in DER as an ASN.1 structure of the type
       SubjectPublicKeyInfo), and the security parameter Sec.

       The main difference between the CGA generation and the HBA generation
       is that while a CGA can be generated independently, all the HBAs of a
       given HBA set have to be generated using the same parameters, which
       implies that the generation of the addresses of an HBA set will occur
       in a coordinated fashion.  In this memo, we will describe a mechanism
       to generate all the addresses of a given HBA set.  The generation
       process of each one of the HBA address of an HBA set will be heavily
       based in the CGA generation process defined in [2].  More precisely,
       the HBA set generation process will be defined as a sequence of
       lightly modified CGA generations.

       The changes required in the CGA generation process when generating a
       single HBA are the following: First, the Multi-Prefix extension has
       to be included in the CGA Parameter Data Structure.  Second, in the
       case that the address being generated is an HBA-only address, a
       random nonce will have to be used as input instead of a valid public
       key.  For backwards compatibility issues with pure CGAs, the random
       nonce MUST be encoded as a public key as defined in [2].  In
       particular, the random nonce MUST be formatted as a DER-encoded ASN.1
       structure of the type SubjectPublicKeyInfo, defined in the Internet
       X.509 certificate profile [5].  The algorithm identifier MUST be
       rsaEncryption, which is 1.2.840.113549.1.1.1, and the random nonce
       MUST be formatted by using the RSAPublicKey type as specified in
       Section 2.3.1 of RFC 3279 [4].  The random nonce length is 384 bits.

       The resulting HBA-set generation process is the following:

       The inputs to the HBA generation process are:

       o  A vector of n 64-bit prefixes,

       o  A Sec parameter, and

    Bagnulo                     Standards Track                     [Page 9]

    RFC 5535                          HBA                          June 2009

       o  In the case of the generation of a set of HBA/CGA addresses, a
          public key is also provided as input (not required when generating
          HBA-only addresses).

       The output of the HBA generation process are:

       o  An HBA-set

       o  their respective CGA Parameter Data Structures

       The steps of the HBA-set generation process are:

       1. Multi-Prefix extension generation.  Generate the Multi-Prefix
          extension with the format defined in Section 5.  Include the
          vector of n 64-bit prefixes in the Prefix[1...n] fields.  The Ext
          Len field value is (n*8 + 4).  If a public key is provided, then
          the P flag is set to one.  Otherwise, the P flag is set to zero.

       2. Modifier generation.  Generate a Modifier as a random or
          pseudorandom 128-bit value.  If a public key has not been provided
          as an input, generate the Extended Modifier as a 384-bit random or
          pseudorandom value.  Encode the Extended Modifier value as an RSA
          key in a DER-encoded ASN.1 structure of the type
          SubjectPublicKeyInfo defined in the Internet X.509 certificate
          profile [5].

       3. Concatenate from left to right the Modifier, 9 zero octets, the
          encoded public key or the encoded Extended Modifier (if no public
          key was provided), and the Multi-Prefix extension.  Execute the
          SHA-1 algorithm on the concatenation.  Take the 112 leftmost bits
          of the SHA-1 hash value.  The result is Hash2.

       4. Compare the 16*Sec leftmost bits of Hash2 with zero.  If they are
          all zero (or if Sec=0), continue with step (5).  Otherwise,
          increment the Modifier by one and go back to step (3).

       5. Set the 8-bit collision count to zero.

       6. For i=1 to n (number of prefixes) do:

          6.1.  Concatenate from left to right the final Modifier value,
             Prefix[i], the collision count, the encoded public key or the
             encoded Extended Modifier (if no public key was provided), and
             the Multi-Prefix extension.  Execute the SHA-1 algorithm on the
             concatenation.  Take the 64 leftmost bits of the SHA-1 hash
             value.  The result is Hash1[i].

    Bagnulo                     Standards Track                    [Page 10]

    RFC 5535                          HBA                          June 2009

          6.2.  Form an interface identifier from Hash1[i] by writing the
             value of Sec into the three leftmost bits and by setting bits 6
             and 7 (i.e., the "u" and "g" bits) both to zero.

          6.3.  Generate address HBA[i] by concatenating Prefix[i] and the
             64-bit interface identifier to form a 128-bit IPv6 address with
             the subnet prefix to the left and interface identifier to the
             right as in a standard IPv6 address [6].

          6.4.  Perform duplicate address detection if required.  If an
             address collision is detected, increment the collision count by
             one and go back to step (6).  However, after three collisions,
             stop and report the error.

          6.5.  Form the CGA Parameter Data Structure that corresponds to
             HBA[i] by concatenating from left to right the final Modifier
             value, Prefix[i], the final collision count value, the encoded
             public key or the encoded Extended Modifier, and the Multi-
             Prefix extension.

       Note: most of the steps of the process are taken from [2].

    7.  HBA Verification

       The following procedure is only valid for Sec values of 0, 1, and 2.
       For other Sec values, RFC 4982 [10] has defined a CGA SEC registry
       that will contain the specifications used to verify CGAs.  The
       verification procedures defined in such specifications must be used
       for Sec values other than 0,1, or 2.

    7.1.  Verification That a Particular HBA Address Corresponds to a Given
          CGA Parameter Data Structure

       HBAs are constructed as a CGA Extension, so a properly formatted HBA
       and its correspondent CGA Parameter Data Structure will successfully
       finish the verification process described in Section 5 of [2].  Such
       verification is useful when the goal is the verification of the
       binding between the public key and the HBA.

    7.2.  Verification That a Particular HBA Address Belongs to the HBA Set
          Associated with a Given CGA Parameter Data Structure

       For multihoming applications, it is also relevant that the receiver
       of the HBA information verifies if a given HBA address belongs to a
       certain HBA set.  An HBA set is identified by a CGA Parameter Data
       structure that contains a Multi-Prefix extension.  So, the receiver
       needs to verify if a given HBA belongs to the HBA set defined by a
       CGA Parameter Data Structure.  It should be noted that the receiver

    Bagnulo                     Standards Track                    [Page 11]

    RFC 5535                          HBA                          June 2009

       may need to verify if an HBA belongs to the HBA set defined by the
       CGA Parameter Data Structure of another HBA of the set.  If this is
       the case, HBAs will fail to pass the CGA verification process defined
       in [2], because the prefix included in the Subnet Prefix field of the
       CGA Parameter Data Structure will not match the prefix of the HBA
       that is being verified.  To verify if an HBA belongs to an HBA set
       associated with another HBA, verify that the HBA prefix is included
       in the prefix set defined in the Multi-Prefix extension, and if this
       is the case, then substitute the prefix included in the Subnet Prefix
       field by the prefix of the HBA, and then perform the CGA verification
       process defined in [2].

       So, the process to verify that an HBA belongs to an HBA set
       determined by a CGA Parameter Data Structure is called HBA
       verification and it is the following:

       The inputs to the HBA verification process are:

       o  An HBA

       o  A CGA Parameter Data Structure

       The steps of the HBA verification process are the following:

       1. Verify that the 64-bit HBA prefix is included in the prefix set of
          the Multi-Prefix extension.  If it is not included, the
          verification fails.  If it is included, replace the prefix
          contained in the Subnet Prefix field of the CGA Parameter Data
          Structure by the 64-bit HBA prefix.

       2. Run the verification process described in Section 5 of [2] with
          the HBA and the new CGA Parameters Data Structure (including the
          Multi-Prefix extension) as inputs.  The steps of the process are
          included below, extracted from [2]:

          2.1.  Check that the collision count in the CGA Parameter Data
             Structure is 0, 1, or 2.  The CGA verification fails if the
             collision count is out of the valid range.

          2.2.  Check that the subnet prefix in the CGA Parameter Data
             Structure is equal to the subnet prefix (i.e., the leftmost 64
             bits) of the address.  The CGA verification fails if the prefix
             values differ.  Note: This step always succeeds because of the
             action taken in step 1.

    Bagnulo                     Standards Track                    [Page 12]

    RFC 5535                          HBA                          June 2009

          2.3.  Execute the SHA-1 algorithm on the CGA Parameter Data
             Structure.  Take the 64 leftmost bits of the SHA-1 hash value.
             The result is Hash1.

          2.4.  Compare Hash1 with the interface identifier (i.e., the
             rightmost 64 bits) of the address.  Differences in the three
             leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits)
             are ignored.  If the 64-bit values differ (other than in the
             five ignored bits), the CGA verification fails.

          2.5.  Read the security parameter Sec from the three leftmost bits
             of the 64-bit interface identifier of the address.  (Sec is an
             unsigned 3-bit integer.)

          2.6.  Concatenate from left to right the Modifier, 9 zero octets,
             the public key, and any extension fields (in this case, the
             Multi-Prefix extension will be included, at least) that follow
             the public key in the CGA Parameter Data Structure.  Execute
             the SHA-1 algorithm on the concatenation.  Take the 112
             leftmost bits of the SHA-1 hash value.  The result is Hash2.

          2.7.  Compare the 16*Sec leftmost bits of Hash2 with zero.  If any
             one of them is non-zero, the CGA verification fails.
             Otherwise, the verification succeeds.  (If Sec=0, the CGA
             verification never fails at this step.)

    8.  Example of HBA Application in a Multihoming Scenario

       In this section, we will describe a possible application of the HBA
       technique to IPv6 multihoming.

       We will consider the following scenario: a multihomed site obtains
       Internet connectivity through two providers: ISPA and ISPB.  Each
       provider has delegated a prefix to the multihomed site (PrefA::/nA
       and PrefB::/nb, respectively).  In order to benefit from multihoming,
       the hosts within the multihomed site will configure multiple IP
       addresses, one per available prefix.  The resulting configuration is
       depicted in the next figure.

    Bagnulo                     Standards Track                    [Page 13]

    RFC 5535                          HBA                          June 2009

                      +-------+
                      | Host2 |
                      |IPHost2|
                      +-------+
                          |
                          |
                      (Internet)
                       /      \
                      /        \
                +------+      +------+
                | ISPA |      | ISPB |
                |      |      |      |
                +------+      +------+
                   |             |
                    \            /
                     \          /
                +---------------------+
                | multihomed site     |
                | PA::/nA             |
                | PB::/nB    +------+ |
                |            |Host1 | |
                |            +------+ |
                +---------------------+

       We assume that both Host1 and Host2 support the Shim6 protocol.

       Host2 is not located in a multihomed site, so there is no need for it
       to create HBAs (it must be able to verify them though, in order to
       support the Shim6 protocol, as we will describe next).

       Host1 is located in the multihomed site, so it will generate its
       addresses as HBAs.  In order to do that, it needs to execute the
       HBA-set generation process as detailed in Section 6 of this memo.
       The inputs of the HBA-set generation process will be: a prefix vector
       containing the two prefixes available in its link, i.e., PA:LA::/64
       and PB:LB::/64, a Sec parameter value, and optionally a public key.
       In this case, we will assume that a public key is provided so that we
       can also illustrate how a renumbering event can be supported when
       HBA/CGA addresses are used (see the sub-section referring to dynamic
       address set support).  So, after executing the HBA-set generation
       process, Host1 will have: an HBA-set consisting in two addresses,
       i.e., PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter
       Data Structures, i.e., CGA_PDS_A and CGA_PDS_B.  Note that iidA and
       iidB are different but both contain information about the prefix set
       available in the multihomed site.

    Bagnulo                     Standards Track                    [Page 14]

    RFC 5535                          HBA                          June 2009

       We will next consider a communication between Host1 and Host2.
       Assume that both ISPs of the multihomed site are working properly, so
       any of the available addresses in Host1 can be used for the
       communication.  Suppose then that the communication is established
       using PA:LA:iidA and IPHost2 for Host1 and Host2, respectively.  So
       far, no special Shim6 support has been required, and PA:LA:iidA is
       used as any other global IP address.

       Suppose that at a certain moment, one of the hosts involved in the
       communication decides that multihoming support is required in this
       communication (this basically means that one of the hosts involved in
       the communication desires enhanced fault-tolerance capabilities for
       this communication, so that if an outage occurs, the communication
       can be re-homed to an alternative provider).

       At this moment, the Shim6 protocol Host-Pair Context establishment
       exchange will be performed between the two hosts (see [9]).  In this
       exchange, Host1 will send CGA_PDS_A to Host2.

       After the reception of CGA_PDS_A, Host2 will verify that the received
       CGA Parameter Data Structure corresponds to the address being used in
       the communication PA:LA:iidA.  This means that Host2 will execute the
       HBA verification process described in Section 7 of this memo with PA:
       LA:iidA and CGA_PDS_A as inputs.  In this case, the verification will
       succeed since the CGA Parameter Data Structure and the addresses used
       in the verification match.

       As long as there are no outages affecting the communication path
       through ISPA, packets will continue flowing.  If a failure affects
       the path through ISPA, Host1 will attempt to re-home the
       communication to an alternative address, i.e., PB:LB:iidB.  In order
       to accomplish this, after detecting the outage, Host1 will inform
       Host2 about the alternative address.  Host2 will verify that the new
       address belongs to the HBA set of the initial address.  In order to
       accomplish this, Host2 will execute the HBA verification process with
       the CGA Parameter Data Structure of the original address (i.e.,
       CGA_PDS_A) and the new address (i.e., PB:LB:iidB) as inputs.  The
       verification process will succeed because PB:LB::/64 has been
       included in the Multi-Prefix extension during the HBA-set generation
       process.  Additional verifications may be required to prevent
       flooding attacks (see the comments about flooding attacks prevention
       in the Security Considerations section of this memo).

       Once the new address is verified, it can be used as an alternative
       locator to re-home the communication, while preserving the original
       address (PA:LA:iidA) as an identifier for the upper layers.  This

    Bagnulo                     Standards Track                    [Page 15]

    RFC 5535                          HBA                          June 2009

       means that following packets will be addressed to/from this new
       address.  Note that no additional HBA verification is required for
       the following packets, since the new valid address can be stored in
       Host2.

       In this example, only the HBA capabilities of the Host1 addresses
       were used.  In other words, neither the public key included in the
       CGA Parameter Data Structure nor its correspondent private key was
       used in the protocol.  In the following section, we will consider a
       case where its usage is required.

    8.1.  Dynamic Address Set Support

       In the previous section, we have presented the mechanisms that allow
       a host to use different addresses of a predetermined set to exchange
       packets of a communication.  The set of addresses involved was
       predetermined and known when the communication was initiated.  To
       achieve such functionality, only HBA functionalities of the addresses
       were needed.  In this section, we will explore the case where the
       goal is to exchange packets using additional addresses that were not
       known when the communication was established.  An example of such a
       situation is when a new prefix is available in a site after a
       renumbering event.  In this case, the hosts that have the new address
       available may want to use it in communications that were established
       before the renumbering event.  In this case, HBA functionalities of
       the addresses are not enough and CGA capabilities are to be used.

       Consider then the previous case of the communication between Host1
       and Host2.  Suppose that the communication is up and running, as
       described earlier.  Host1 is using PA:LA:iidA and Host2 is using
       IPHost2 to exchange packets.  Now suppose that a new address, PC:LC:
       addC is available in Host1.  Note that this address is just a regular
       IPv6 address, and it is neither an HBA nor a CGA.  Host1 wants to use
       this new address in the existent communication with Host2.  It should
       be noted that the HBA mechanism described in the previous section
       cannot be used to verify this new address, since this address does
       not belong to the HBA set (since the prefix was not available at the
       moment of the generation of the HBA set).  This means that
       alternative verification mechanisms will be needed.

       In order to verify this new address, CGA capabilities of PA:LA:iidA
       are used.  Note that the same address is used, only that the
       verification mechanism is different.  So, if Host1 wants to use PC:
       LC:addC to exchange packets in the established communication, it will
       use the UPDATE message defined in the Shim6 protocol [9], conveying
       the new address, PC:LC:addC, and this message will be signed using
       the private key corresponding to the public key contained in
       CGA_PDS_A.  When Host2 receives the message, it will verify the

    Bagnulo                     Standards Track                    [Page 16]

    RFC 5535                          HBA                          June 2009

       signature using the public key contained in the CGA Parameter Data
       Structure associated with the address used for establishing the
       communication, i.e., CGA_PDS_A and PA:LA:iidA, respectively.  Once
       that the signature is verified, the new address (PC:LC:addC) can be
       used in the communication.

       In any case, a renumbering event has an impact on a site that is
       using the HBA technique.  In particular, the new prefix added will
       not be included in the existing HBA set, so it is only possible to
       use the new prefix with the existing HBA set if CGA capabilities are
       used.  While this is acceptable for the short term, in the long run,
       the site will need to renumber its HBA addresses.  In order to do
       that, it will need to re-generate the HBA sets assigned to hosts
       including the new prefix in the prefix set, which will result in
       different addresses, not only because we need to add a new address
       with the new prefix, but also because the addresses with the existing
       prefixes will also change because of the inclusion of a new prefix in
       the prefix set.  Moreover, since HBA addresses need to be generated
       locally, once these are generated after the renumbering event, the
       new address information needs to be conveyed to the DNS manager in
       case that such address information is to be published in the DNS (see
       DNS considerations section for more details).

    9.  DNS Considerations

       HBA sets can be generated using any prefix set.  Actually, the only
       particularity of the HBA is that they contain information about the
       prefix set in the interface identifier part of the address in the
       form of a hash, but no assumption about the properties of prefixes
       used for the HBA generation is made.  This basically means that
       depending on the prefixes used for the HBA set generation, it may or
       may not be recommended to publish the resulting (HBA) addresses in
       the DNS.  For instance, when Unique Local Address (ULA) prefixes [18]
       are included in the HBA generation process, specific DNS
       considerations related to the local nature of the ULA should be taken
       into account and proper recommendations related to publishing such
       prefixes in the DNS should followed.  Moreover, among its addresses,
       a given host can have some HBAs and some other IPv6 addresses.  The
       consequence from this is that only HBA addresses will be bound
       together by the HBA technique, while other addresses would not be
       bound to the HBA set.  This would basically mean that if one of the
       other addresses is used for initiating a Shim6 communication, it
       won't be possible to use the HBA technique to bind the address used
       with the HBA set.  Furthermore, since HBA addresses are
       indistinguishable from other IPv6 addresses in their format, an
       initiator will not be able to distinguish, by merely looking at the

    Bagnulo                     Standards Track                    [Page 17]

    RFC 5535                          HBA                          June 2009

       different addresses, which ones belong to the HBA set and which ones
       do not, so alternative means would be required the initiator is
       supposed to use only HBA for establishing communications in the
       presence of non-HBA addresses in the DNS.

       In addition, it should be noted that the actual HBA values are a
       result of the HBA generation procedure, meaning that they cannot be
       arbitrarily chosen.  This has an implication with respect to DNS
       management, because the party that generates the HBA address set
       needs to convey the address information to the DNS manager, so that
       the addresses are published and not the other way around.  The
       situation is similar to regular CGA addresses and even to the case
       where stateless address autoconfiguration is used.  In order to do
       that, it is possible to use Dynamic DNS updates [19] or other
       proprietary tools.  A similar consideration applies when the host
       wants to publish reverse-DNS entries.  Since the host needs to
       generate its HBA addresses, it will need to convey the address
       information to the DNS manager so the proper reverse-DNS entry is
       populated in case it is needed.  It should be noted that neither the
       Shim6 protocol nor the HBA technique rely on the reverse DNS for its
       proper functioning and the general reasons for requiring reverse-DNS
       population apply as for any other regular IPv6 address.

    10.  IANA Considerations

       This document defines a new CGA Extension, the Multi-Prefix
       extension.  This extension has been assigned the CGA Extension Type
       value 0x0012.

    11.  Security Considerations

       The goal of HBAs is to create a group of addresses that are securely
       bound, so that they can be used interchangeably when communicating
       with a node.  If there is no secure binding between the different
       addresses of a node, a number of attacks are enabled, as described in
       [11].  In particular, it would be possible for an attacker to
       redirect the communications of a victim to an address selected by the
       attacker, hijacking the communication.  When using HBAs, only the
       addresses belonging to an HBA set can be used interchangeably,
       limiting the addresses that can be used to redirect the communication
       to a predetermined set that belongs to the original node involved in
       the communication.  So, when using HBAs, a node that is communicating
       using address A can redirect the communication to a new address B if
       and only if B belongs to the same HBA set as A.

    Bagnulo                     Standards Track                    [Page 18]

    RFC 5535                          HBA                          June 2009

       This means that if an attacker wants to redirect communications
       addressed to address HBA1 to an alternative address IPX, the attacker
       will need to create a CGA Parameter Data Structure that generates an
       HBA set that contains both HBA1 and IPX.

       In order to generate the required HBA set, the attacker needs to find
       a CGA Parameter Data Structure that fulfills the following
       conditions:

       o  the prefix of HBA1 and the prefix of IPX are included in the
          Multi-Prefix extension.

       o  HBA1 is included in the HBA set generated.

       Note: this assumes that it is acceptable for the attacker to redirect
       HBA1 to any address of the prefix of IPX.

       The remaining fields that can be changed at will by the attacker in
       order to meet the above conditions are: the Modifier, other prefixes
       in the Multi-Prefix extension, and other extensions.  In any case, in
       order to obtain the desired HBA set, the attacker will have to use a
       brute-force attack, which implies the generation of multiple HBA sets
       with different parameters (for instance with a different Modifier)
       until the desired conditions are meet.  The expected number of times
       that the generation process will have to be repeated until the
       desired HBA set is found is exponentially related with the number of
       bits containing hash information included in the interface identifier
       of the HBA.  Since 59 of the 64 bits of the interface identifier
       contain hash bits, then the expected number of generations that will
       have to be performed by the attacker are O(2^59).  Note: We assume
       brute force is the best attack against HBA/CGAs.  Also, note that the
       assumption that the Sec tool defined in [2] multiplies the attack
       factor holds for brute-force attacks but may not hold for other
       attack classes.

       The protection against brute-force attacks can be improved by
       increasing the Sec parameter.  A non-zero Sec parameter implies that
       steps 3-4 of the generation process will be repeated O(2^(16*Sec))
       times (expected number of times).  If we assimilate the cost of
       repeating the steps 3-4 to the cost of generating the HBA address, we
       can estimate the number of times that the generation is to be
       repeated in O(2^(59+16*Sec)), in the case of Sec values of 1 and 2.
       For other Sec values, Sec protection mechanisms will be defined by
       the specifications pointed by the CGA SEC registry defined in RFC
       4982 [10].

    Bagnulo                     Standards Track                    [Page 19]

    RFC 5535                          HBA                          June 2009

    11.1.  Security Considerations When Using HBAs in the Shim6 Protocol

       In this section, we will analyze the security provided by HBAs in the
       context of a Shim6 protocol as described in Section 8 of this memo.

       First of all, it must be noted that HBAs cannot prevent
       man-in-the-middle (hereafter MITM) attacks.  This means that in the
       scenario described in Section 8, if an attacker is located along the
       path between Host1 and Host2 during the lifetime of the
       communication, the attacker will be able to change the addresses used
       for the communication.  This means that he will be able to change the
       addresses used in the communication, adding or removing prefixes at
       his will.  However, the attacker must make sure that the CGA
       Parameter Data Structure and the HBA set is changed accordingly.
       This essentially means that the attacker will have to change the
       interface identifier part of the addresses involved, since a change
       in the prefix set will result in different interface identifiers of
       the addresses of the HBA set, unless the appropriate Modifier value
       is used (which would require O(2(59+16*Sec)) attempts).  So, HBA
       doesn't provide MITM attacks protection, but a MITM attacker will
       have to change the address used in the communication in order to
       change the prefix set valid for the communication.

       HBAs provide protection against time shifting attacks [11], [12].  In
       the multihoming context, an attacker would perform a time shifted
       attack in the following way: an attacker placed along the path of the
       communication will modify the packets to include an additional
       address as a valid address for the communication.  Then the attacker
       would leave the on-path location, but the effects of the attack would
       remain (i.e., the address would still be considered as a valid
       address for that communication).  Next we will present how HBAs can
       be used to prevent such attacks.

       If the attacker is not on-path when the initial CGA Parameter Data
       Structure is exchanged, his only possibility to launch a redirection
       attack is to fake the signature of the message for adding new
       addresses using CGA capabilities of the addresses.  This implies
       discovering the public key used in the CGA Parameter Data Structure
       and then cracking the key pair, which doesn't seem feasible.  So in
       order to launch a redirection attack, the attacker needs to be
       on-path when the CGA Parameter Data Structure is exchanged, so he can
       modify it.  Now, in order to launch the redirection attack, the
       attacker needs to add his own prefix in the prefix set of the CGA
       Parameter Data Structure.  We have seen in the previous section that
       there are two possible approaches for this:

    Bagnulo                     Standards Track                    [Page 20]

    RFC 5535                          HBA                          June 2009

       1. Find the right Modifier value, so that the address initially used
          in the communication is contained in the new HBA set.  The cost of
          this attack is O(2(59+16*Sec)) iterations of the generation
          process, so it is deemed unfeasible.

       2. Use any Modifier value, so that the address initially used in the
          communication is probably not included in the HBA set.  In this
          case, the attacker must remain on-path, since he needs to rewrite
          the address carried in the packets (if not, the endpoints will
          notice a change in the address used in the communication).  This
          essentially means that the attacker cannot launch a time shifted
          attack, but he must be a full-time man-in-the-middle.

       So, the conclusion is that HBAs provide protection against time
       shifted attacks

       HBAs do not provide complete protection against flooding attacks,
       and, as a result, the SHIM6 protocol has other means to deal with
       them.  However, HBAs make it very difficult to launch a flooding
       attack towards a specific address.  It is possible though, to launch
       a flooding attack against a prefix.  And of course, the protection
       that HBA offers applies only to nodes that employ it; HBA provides no
       solution for general-purpose flooding-attack protection for other
       nodes.

       Suppose that an attacker has easy access to a prefix PX::/nX and that
       he wants to launch a flooding attack on a host located in the address
       P:iid.  The attack would consist of establishing communication with a
       server S and requesting a heavy flow from it.  Then simply
       redirecting the flow to P:iid, flooding the target.  In order to
       perform this attack, the attacker needs to generate an HBA set
       including P and PX in the prefix set, and be sure that the resulting
       HBA set contains P:iid.  In order to do this, the attacker needs to
       find the appropriate Modifier value.  The expected number of attempts
       required to find such Modifier value is O(2(59+16*Sec)), as presented
       earlier.  So, we can conclude that such attack is not feasible.

       However, the target of a flooding attack is not limited to specific
       hosts, but it can also be launched against other elements of the
       infrastructure, such as router or access links.  In order to do that,
       the attacker can establish a communication with a server S and
       request a download of a heavy flow.  Then, the attacker redirects the
       communication to any address of the target network.  Even if the
       target address is not assigned to any host, the flow will flood the
       access link of the target site, and the site access router will also
       suffer the overload.  Such attack cannot be prevented using HBAs,

    Bagnulo                     Standards Track                    [Page 21]

    RFC 5535                          HBA                          June 2009

       since the attacker can easily generate an HBA set using his own
       prefix and the target network prefix.  In order to prevent such
       attacks, additional mechanisms are required, such as reachability
       tests.

    11.2.  Privacy Considerations

       HBAs can be used as RFC 4941 [7] addresses.  If a node wants to use
       temporary addresses, it will need to periodically generate new HBA
       sets.  The effort required for this operation depends on the Sec
       parameter value.  If Sec=0, then the cost of generating a new HBA set
       is similar to the cost of generating a random number, i.e., one
       iteration of the HBA set generation procedure.  However, if Sec>0,
       then the cost of generating an HBA set is significantly increased,
       since it required O(2(16*Sec)) iterations of the generation process.
       In this case, depending on the frequency of address change required,
       the support for RFC 4941 address may be more expensive.

    11.3.  SHA-1 Dependency Considerations

       Recent attacks on currently used hash functions have motivated a
       considerable amount of concern in the Internet community.  The
       recommended approach [14] [15] to deal with this issue is first to
       analyze the impact of these attacks on the different Internet
       protocols that use hash functions, and second to make sure that the
       different Internet protocols that use hash functions are capable of
       migrating to an alternative (more secure) hash function without a
       major disruption in the Internet operation.

       The aforementioned analysis for CGAs and their extensions (including
       HBAs) is performed in RFC 4982 [10].  The conclusion of the analysis
       is that the security of the protocols using CGAs and their extensions
       are not affected by the recently available attacks against hash
       functions.  In spite of that, the CGA specification [2] was updated
       by RFC 4982 [10] to enable the support of alternative hash functions.

    11.4.  DoS Attack Considerations

       In order to use the HBA technique, the owner of the HBA set must
       inform its peer about the CGA Parameter Data Structure in order to
       allow the peer to verify that the different HBAs belong to the same
       HBA set.  Such information must then be stored by the peer to verify
       alternative addresses in the future.  This can be a vector for DoS
       attacks, since the peer must commit resources (in this particular
       case memory) to be able to use the HBA technique for address
       verification.  It is then possible for an attacker to launch a DoS
       attack by conveying HBA information to a victim, imposing on the
       victim to use memory for storing HBA related state, and eventually

    Bagnulo                     Standards Track                    [Page 22]

    RFC 5535                          HBA                          June 2009

       running out of memory for other genuine operations.  In order to
       prevent such an attack, protocols that use the HBA technique should
       implement proper DoS prevention techniques.

       For instance, the Shim6 protocol [9] includes a 4-way handshake to
       establish the Shim6 context and, in particular, to establish the HBA-
       related state.  In this 4-way handshake, the receiver remains
       stateless during the first 2 messages, while the initiator must keep
       state throughout the exchange of the 4 messages so that the cost of
       the context establishment is higher in memory terms for the initiator
       (i.e., the potential attacker) than for the receiver (i.e., the
       potential victim).  In addition to that, the 4-way handshake prevents
       the usage of spoofed addresses from off-path attacker, since the
       initiator must be able to receive information through the address it
       has used as source address, enabling the tracking of the location
       from which the attack was launched.

    12.  Contributors

       This document was originally produced by a MULTI6 design team
       consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo,
       Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret
       Wasserman, and Jukka Ylitalo.

    13.  Acknowledgments

       The initial discussion about HBA benefited from contributions from
       Alberto Garcia-Martinez, Tuomas Aura, and Arturo Azcorra.

       The HBA-set generation and HBA verification processes described in
       this document contain several steps extracted from [2].

       Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka
       Savola, Brian Carpenter, Eric Rescorla, Robin Whittle, Matthijs
       Mekking, Hannes Tschofenig, Spencer Dawkins, Lars Eggert, Tim Polk,
       Peter Koch, Niclas Comstedt, David Ward, and Sam Hartman have
       reviewed this document and provided valuable comments.

       The text included in Section 3.2 was provided by Eric Rescorla.

       The author would also like to thank Francis Dupont for providing the
       first implementation of HBA.

    Bagnulo                     Standards Track                    [Page 23]

    RFC 5535                          HBA                          June 2009

    14.  References

    14.1.  Normative References

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

       [2]   Aura, T., "Cryptographically Generated Addresses (CGA)",
             RFC 3972, March 2005.

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

       [4]   Bassham, L., Polk, W., and R. Housley, "Algorithms and
             Identifiers for the Internet X.509 Public Key Infrastructure
             Certificate and Certificate Revocation List (CRL) Profile",
             RFC 3279, April 2002.

       [5]   Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
             R., and W. Polk, "Internet X.509 Public Key Infrastructure
             Certificate and Certificate Revocation List (CRL) Profile",
             RFC 5280, May 2008.

       [6]   Hinden, R. and S. Deering, "IP Version 6 Addressing
             Architecture", RFC 4291, February 2006.

       [7]   Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
             for Stateless Address Autoconfiguration in IPv6", RFC 4941,
             September 2007.

       [8]   Bagnulo, M. and J. Arkko, "Cryptographically Generated
             Addresses (CGA) Extension Field Format", RFC 4581,
             October 2006.

       [9]   Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
             Protocol for IPv6", RFC 5533, June 2009.

       [10]  Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms
             in Cryptographically Generated Addresses (CGAs)", RFC 4982,
             July 2007.

    14.2.  Informative References

       [11]  Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming
             Solutions", RFC 4218, October 2005.

    Bagnulo                     Standards Track                    [Page 24]

    RFC 5535                          HBA                          June 2009

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

       [13]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
             Optimization for Mobile IPv6", RFC 4866, May 2007.

       [14]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
             in Internet Protocols", RFC 4270, November 2005.

       [15]  Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm",
             2005 September.

       [16]  Nordmark, E., "Multi6 Application Referral Issues", Work
             in Progress, October 2004.

       [17]  Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient
             Security for IPv6 Multihoming", ACM Computer Communications
             Review Vol 35 n 2, April 2005.

       [18]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
             Addresses", RFC 4193, October 2005.

       [19]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
             Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
             April 1997.

    Author's Address

       Marcelo Bagnulo
       Universidad Carlos III de Madrid
       Av. Universidad 30
       Leganes, Madrid  28911
       SPAIN

       Phone: 34 91 6249500
       EMail: marcelo@it.uc3m.es
       URI:   http://www.it.uc3m.es

    Bagnulo                     Standards Track                    [Page 25]