Network Working Group M. Bagnulo
Internet-Draft UC3M
Expires: January 12, 2006 July 11, 2005
Hash Based Addresses (HBA)
draft-ietf-shim6-hba-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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. The main idea 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 generated by prepending the
different prefixes to the generated interface identifiers. The
result is a set of addresses, called Hash Based Addresses (HBAs),
Bagnulo Expires January 12, 2006 [Page 1]
Internet-Draft HBA July 2005
that are inherently bound.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CGA compatibility considerations . . . . . . . . . . . . . . 5
3. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . 7
4. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . 9
5. HBA verification . . . . . . . . . . . . . . . . . . . . . . 12
6. Example of HBA application to a multihoming scenario . . . . 15
6.1 Dynamic Address Set Support . . . . . . . . . . . . . . . 17
7. Security considerations . . . . . . . . . . . . . . . . . . 19
7.1 Security considerations when using HBAs in a multi6
protocol . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2 Privacy Considerations . . . . . . . . . . . . . . . . . . 22
7.3 Interaction with IPSec. . . . . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1 Changes from draft-bagnulo-multi6dt-hba-00 to
draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1 Normative References . . . . . . . . . . . . . . . . . . 26
11.2 Informative References . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 28
Bagnulo Expires January 12, 2006 [Page 2]
Internet-Draft HBA July 2005
1. Introduction
In order to preserve inter-domain routing system scalability, IPv6
sites obtain addresses from their Internet Service Providers. Such
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 [6], 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 (a.k.a. time shifting attacks in [7]).
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 takes advantage of this
address set stability, and provides a secure binding between all the
addresses of a node in a multihomed site. The mechanism does so
without requiring the usage of public key cryptography, providing a
cost efficient alternative to public key cryptography based schemes.
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. The main idea 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, called Hash Based Addresses (HBAs),
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. No public key operations are involved in the
verification process. In addition, it should also be noted that it
is not required that all interface identifiers of the addresses of an
Bagnulo Expires January 12, 2006 [Page 3]
Internet-Draft HBA July 2005
HBA set are equal, preserving some degree of privacy through changes
in the addresses used during the communications.
Bagnulo Expires January 12, 2006 [Page 4]
Internet-Draft HBA July 2005
2. CGA compatibility considerations
As described in 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 [1] 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 specification [2] uses
the CGAs defined in [1] 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 multi6). In addition to SeND, there are other
protocols that are considering to benefit from the advantages offered
by the CGA scheme, such as mobility support protocols [8]. Those
protocols would also become incompatible 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 than 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 are
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
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
Bagnulo Expires January 12, 2006 [Page 5]
Internet-Draft HBA July 2005
communication.
So, because of the aforementioned reasons, it is a goal of the HBA
design to define HBAs in a way that they are compatible with CGAs as
defined in [1] and their usages described in [2] (Consequently, to
understand the rest of this note, the reader should be familiar with
the CGA specification defined in [1]). 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 a HBA is inherently bound to
a prefix set. This means that a public key is not strictly required
to generate an HBA. Because of that, we define three different types
of addresses:
- CGA-only addresses: These are addresses generated as specified in
[1] 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
[2] and 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 Parameters 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 [2] and for any usage
defined for HBA (such as a multi6 protocol)
- HBA-only addresses: These addresses are bound to a prefix set but
they are not bound to a public key. Because CGA compatibility,
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 Expires January 12, 2006 [Page 6]
Internet-Draft HBA July 2005
3. Multi-Prefix Extension for CGA
The format of the Multi-Prefix Extension is the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext Type | Ext Len |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[n] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext Type: 8-bit identifier of the Multi-Prefix Extension (TBD IANA)
(Meanwhile, the 0x12 value is recommended for trails)
Ext Len: 8-bit unsigned integer. Length of the Extension in 8-octet
units, 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 if a additional Modifier
bits are included in the CGA Parameter Data Structure.
Reserved: 15-bit reserved field. MUST be initialized to zero, and
ignored upon receipt..
Bagnulo Expires January 12, 2006 [Page 7]
Internet-Draft HBA July 2005
Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n.
Bagnulo Expires January 12, 2006 [Page 8]
Internet-Draft HBA July 2005
4. HBA-Set Generation
The HBA generation process is based on the CGA generation process
defined in section 4 of [1]. The goal is to require the minimum
amount of changes to the CGA generation process.
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 [1]. 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 Parameters Data Structure. Second, in the
case that the address being generated is an HBA-only address, a
random nonce (encoded in DER as an ASN.1 structure of the type
SubjectPublicKeyInfo) will have to be used as input instead of a
valid public key.
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
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 Parameters Data Structures
The steps of the HBA-set generation process are:
Bagnulo Expires January 12, 2006 [Page 9]
Internet-Draft HBA July 2005
1. Multi-Prefix Extension generation. Generate the Multi-Prefix
Extension with the format defined in section 3. Include the
vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext
Len field value is (n*8). If a public key is provided, then the P
flag is set. Otherwise, the P flag is reset.
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 a RSA
key in a DER-encoded ASN.1 structure of the type
SubjectPublicKeyInfo defined in the Internet X.509 certificate
profile [3].
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 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 Expires January 12, 2006 [Page 10]
Internet-Draft HBA July 2005
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 [4].
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 Parameters 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 [1]]
Bagnulo Expires January 12, 2006 [Page 11]
Internet-Draft HBA July 2005
5. HBA verification
HBAs are constructed as a CGA Extension, so a properly formated HBA
and its correspondent CGA Parameter Data Structure will successfully
finish the verification process described in section 5 of [1]. Such
verification is useful when the goal is the verification of the
binding between the public key and the HBA.
However, for multihoming applications, it is also relevant to verify
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, it is then needed to verify if an HBA belongs
to the HBA set defined by a CGA Parameter Data Structure. It should
be noted that it may be needed 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, the CGA verification process as defined in
[1] will fail, because the prefix included in the Subnet Prefix field
of the CGA Parameter Data Structure will not match with the one of
the HBA that is being verified. However, this not means that this
HBA does not belong to the HBA set. In order to address this issue,
it is only required to verify that the HBA prefix is included in
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 [1].
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 An 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.
Bagnulo Expires January 12, 2006 [Page 12]
Internet-Draft HBA July 2005
2. Run the verification process described in section 5 of [1] 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 [1]
2.1. Check that the collision count in the CGA Parameters 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 Parameters 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 is trivially successful
because step 1]
2.3. Execute the SHA-1 algorithm on the CGA Parameters 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,
and 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 Parameters 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.
Bagnulo Expires January 12, 2006 [Page 13]
Internet-Draft HBA July 2005
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.)
Bagnulo Expires January 12, 2006 [Page 14]
Internet-Draft HBA July 2005
6. Example of HBA application to a multihoming scenario
In this section, we will describe a possible application of the HBA
technique to IPv6 multi-homing.
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 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 pre available prefix. The resulting
configuration is depicted in the next figure.
+-------+
| Host2 |
|IPHost2|
+-------+
|
|
(Internet)
/ \
/ \
+------+ +------+
| ISPA | | ISPB |
| | | |
+------+ +------+
| |
\ /
\ /
+---------------------+
| multihomed site |
| PA::/nA |
| PB::/nB +------+ |
| |Host1 | |
| +------+ |
+---------------------+
We assume that both Host1 and Host2 support the multi6 protocol.
Host2 in not located in a multihomed site, so there is no need for
him to create HBAs (it must be able to verify them though, in order
to support the multi6 protocol, as we will describe next.)
Bagnulo Expires January 12, 2006 [Page 15]
Internet-Draft HBA July 2005
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 4 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.
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 multi6 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 rehomed to an alternative provider).
At this moment, the capabilities detection protocol will be executed,
in order to verify that both ends support the multi6 protocol (see
[10].). Once that multi6 support is confirmed, additional parameters
will be exchanged, like a context tag for identifying packets that
belong to this communication (see [9].). In addition, 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 5 of this memo with PA:
LA:iidA and CGA_PDS_A as inputs. (The exact moment of this
verification depends on the details of the multi6 protocol). 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
Bagnulo Expires January 12, 2006 [Page 16]
Internet-Draft HBA July 2005
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. For that,
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. For that, 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) ad identifier for the upper layers. This 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.
Eventually, the communication will end and the associated multi6
context information will be discarded.
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.
6.1 Dynamic Address Set Support
In the previous section we have presented the mechanisms that allow a
host to use different addresses of a pre-determined set to exchange
packets of a communication. The set of addresses involved was pre-
determined 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 situation
is for instance 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
Bagnulo Expires January 12, 2006 [Page 17]
Internet-Draft HBA July 2005
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 message of the multi6 protocol, 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 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.
Bagnulo Expires January 12, 2006 [Page 18]
Internet-Draft HBA July 2005
7. 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
[6]. It particular, it would 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 well, pre-determined 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 than A.
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 Parameters 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.
(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).
The protection against brute force attacks can be improved increasing
Bagnulo Expires January 12, 2006 [Page 19]
Internet-Draft HBA July 2005
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)).
7.1 Security considerations when using HBAs in a multi6 protocol
In this section we will analyze the security provided by HBAs in the
context of a multi6 protocol as described in section 6 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 6, 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 don'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 future attacks [6], (a.k.a. time
shifting attacks in [7]. 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
Bagnulo Expires January 12, 2006 [Page 20]
Internet-Draft HBA July 2005
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 Strcutre. We have seen in the previous section that
there are two possible approaches for this:
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 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,
However, HBAs make very difficult to launch a flooding attack towards
a specific address. It is possible though, to launch a flooding
attack against a prefix.
Suppose that an attacker has easy access to a prefix PX::/nX and that
he wants to launch a flooding attack to a host located in the address
P:iid. The attack would consist in establishing a communication with
a server S and requesting a heavy flow from it. Then simply redirect
the flow to P:iid, flooding the target. In order to perform this
attack the attacker need to generate an HBA set including P and PX in
the prefix set and that the resulting HBA set contains P:iid. In
order to do this, the attacker need 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 element 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,
since the attacker can easily generate an HBA set using his own
Bagnulo Expires January 12, 2006 [Page 21]
Internet-Draft HBA July 2005
prefix and the target network prefix. In order to prevent such
attacks, additional mechanisms are required, such as reachability
tests.
7.2 Privacy Considerations
HBAs can be used as RFC 3041 [5]. 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 3041 address may be more expensive.
7.3 Interaction with IPSec.
In the case that both IPSec and CGA/HBA address are used
simultaneously, it is possible that two public keys are available in
a node, one for IPSec and another one for the CGA/HBA operation. In
this case, an improved security can be achieved by verifying that the
keys are related somehow, (in particular if the same key is used for
both purposes).
Bagnulo Expires January 12, 2006 [Page 22]
Internet-Draft HBA July 2005
8. Contributors
This document was originally produced of a MULTI6 design team
consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo
Braun, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret
Wasserman, and Jukka Ylitalo.
Bagnulo Expires January 12, 2006 [Page 23]
Internet-Draft HBA July 2005
9. 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 [1].
Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka Savola and
Brian Carpenter have reviewed this document and provided valuable
comments.
We would also like to thanks Francis Dupont (ENST) for providing the
first implementation of HBA
Bagnulo Expires January 12, 2006 [Page 24]
Internet-Draft HBA July 2005
10. Change Log
10.1 Changes from draft-bagnulo-multi6dt-hba-00 to
draft-ietf-multi6-hba-00
Added "Example of HBA application to a multihoming scenario" section
Added Privacy Considerations section
Added flooding attacks comments in the Security Considerations
section
Added the Multi-Prefix extension in step 6.1 of the HBA-set
generation process
Added the Security considerations when using HBAs in a multi6
protocol sub-section in the Security Considerations section
Added Ext type value recommended for trials
Changed the name of the draft
Some rewording
Bagnulo Expires January 12, 2006 [Page 25]
Internet-Draft HBA July 2005
11. References
11.1 Normative References
[1] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004.
[2] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
(work in progress), July 2004.
[3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280, April 2002.
[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[5] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
11.2 Informative References
[6] Nordmark, E., "Threats relating to IPv6 multihoming solutions",
draft-ietf-multi6-multihoming-threats-01 (work in progress),
September 2004.
[7] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-01 (work in
progress), July 2004.
[8] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying
Cryptographically Generated Addresses to Optimize MIPv6 (CGA-
OMIPv6)", draft-haddad-mip6-cga-omipv6-02 (work in progress),
June 2004.
[9] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
draft-nordmark-multi6dt-shim-00 (work in progress),
October 2004.
[10] Bagnulo, M. and J. Arkko, "Functional decomposition of the M6
protocol", draft-bagnulo-multi6dt-functional-dec-00 (work in
progress), October 2004.
Bagnulo Expires January 12, 2006 [Page 26]
Internet-Draft HBA July 2005
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 Expires January 12, 2006 [Page 27]
Internet-Draft HBA July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bagnulo Expires January 12, 2006 [Page 28]
