summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5535.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5535.txt')
-rw-r--r--doc/rfc/rfc5535.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc5535.txt b/doc/rfc/rfc5535.txt
new file mode 100644
index 0000000..dd7f9af
--- /dev/null
+++ b/doc/rfc/rfc5535.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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]
+