< draft-ietf-shim6-hba-04.txt   draft-ietf-shim6-hba-05.txt >
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Standards Track October 2007 Intended status: Standards Track December 22, 2007
Expires: April 3, 2008 Expires: June 24, 2008
Hash Based Addresses (HBA) Hash Based Addresses (HBA)
draft-ietf-shim6-hba-04 draft-ietf-shim6-hba-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 3, 2008. This Internet-Draft will expire on June 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo describes a mechanism to provide a secure binding between This memo describes a mechanism to provide a secure binding between
the multiple addresses with different prefixes available to a host the multiple addresses with different prefixes available to a host
within a multihomed site. The main idea is that information about within a multihomed site. This mechanism employs either
the multiple prefixes is included within the addresses themselves. Cryptographically Generated Addresses (CGAs) or a new variant of the
This is achieved by generating the interface identifiers of the same theme that uses the same format in the addresses. The main idea
addresses of a host as hashes of the available prefixes and a random in the new variant is that information about the multiple prefixes is
number. Then, the multiple addresses are generated by prepending the included within the addresses themselves. This is achieved by
different prefixes to the generated interface identifiers. The generating the interface identifiers of the addresses of a host as
result is a set of addresses, called Hash Based Addresses (HBAs), hashes of the available prefixes and a random number. Then, the
that are inherently bound. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Motivations for the HBA design . . . . . . . . . . . . . . 6 3.3. Motivations for the HBA design . . . . . . . . . . . . . . 6
4. Cryptographic Generated Addresses (CGA) compatibility 4. Cryptographic Generated Addresses (CGA) compatibility
considerations . . . . . . . . . . . . . . . . . . . . . . . . 6 considerations . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . . 8 5. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . . 8
6. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . . 9 6. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . . 9
7. HBA verification . . . . . . . . . . . . . . . . . . . . . . . 12 7. HBA verification . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Verification that a particular HBA address corresponds 7.1. Verification that a particular HBA address corresponds
to a given CGA Parameter Data Structure . . . . . . . . . 12 to a given CGA Parameter Data Structure . . . . . . . . . 12
7.2. Verification that a particular HBA address belongs tto 7.2. Verification that a particular HBA address belongs to
the HBA set associated to a given CGA Parameter Data the HBA set associated to a given CGA Parameter Data
Structure . . . . . . . . . . . . . . . . . . . . . . . . 12 Structure . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Example of HBA application to a multihoming scenario . . . . . 14 8. Example of HBA application to a multihoming scenario . . . . . 14
8.1. Dynamic Address Set Support . . . . . . . . . . . . . . . 17 8.1. Dynamic Address Set Support . . . . . . . . . . . . . . . 17
9. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 18 9. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Security considerations . . . . . . . . . . . . . . . . . . . 18 11. Security considerations . . . . . . . . . . . . . . . . . . . 19
11.1. Security considerations when using HBAs in the shim6 11.1. Security considerations when using HBAs in the Shim6
protocol . . . . . . . . . . . . . . . . . . . . . . . . . 20 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 22 11.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 23
11.3. Interaction with IPSec. . . . . . . . . . . . . . . . . . 22 11.3. SHA-1 Dependency Considerations. . . . . . . . . . . . . . 23
11.4. SHA-1 Dependency Considerations. . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Changes from draft-ietf-shim6-hba-03 to 14.1. Changes from draft-ietf-shim6-hba-04 to
draft-ietf-multi6-hba-04 . . . . . . . . . . . . . . . . . 23 draft-ietf-multi6-hba-05 . . . . . . . . . . . . . . . . . 24
14.2. Changes from draft-ietf-shim6-hba-02 to 14.2. Changes from draft-ietf-shim6-hba-03 to
draft-ietf-multi6-hba-03 . . . . . . . . . . . . . . . . . 23 draft-ietf-multi6-hba-04 . . . . . . . . . . . . . . . . . 24
14.3. Changes from draft-ietf-shim6-hba-01 to 14.3. Changes from draft-ietf-shim6-hba-02 to
draft-ietf-multi6-hba-02 . . . . . . . . . . . . . . . . . 24 draft-ietf-multi6-hba-03 . . . . . . . . . . . . . . . . . 24
14.4. Changes from draft-ietf-shim6-hba-00 to 14.4. Changes from draft-ietf-shim6-hba-01 to
draft-ietf-multi6-hba-01 . . . . . . . . . . . . . . . . . 24 draft-ietf-multi6-hba-02 . . . . . . . . . . . . . . . . . 25
14.5. Changes from draft-ietf-multi6-hba-00 to 14.5. Changes from draft-ietf-shim6-hba-00 to
draft-ietf-shim6-hba-00 . . . . . . . . . . . . . . . . . 24 draft-ietf-multi6-hba-01 . . . . . . . . . . . . . . . . . 25
14.6. Changes from draft-bagnulo-multi6dt-hba-00 to 14.6. Changes from draft-ietf-multi6-hba-00 to
draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . . 24 draft-ietf-shim6-hba-00 . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.7. Changes from draft-bagnulo-multi6dt-hba-00 to
15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27 15.2. Informative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
In order to preserve inter-domain routing system scalability, IPv6 In order to preserve inter-domain routing system scalability, IPv6
sites obtain addresses from their Internet Service Providers. Such sites obtain addresses from their Internet Service Providers. Such
addressing strategy significantly reduces the amount of routes in the addressing strategy significantly reduces the amount of routes in the
global routing tables, since each ISP only announces routes to its global routing tables, since each ISP only announces routes to its
own address blocks, rather than announcing one route per customer own address blocks, rather than announcing one route per customer
site. However, this addressing scheme implies that multihomed sites site. However, this addressing scheme implies that multihomed sites
will obtain multiple prefixes, one per ISP. Moreover, since each ISP will obtain multiple prefixes, one per ISP. Moreover, since each ISP
skipping to change at page 4, line 27 skipping to change at page 4, line 27
established communication needs to be routed through different ISPs established communication needs to be routed through different ISPs
during its lifetime, addresses with different prefixes will have to during its lifetime, addresses with different prefixes will have to
be used. Changing the address used to carry packets of an be used. Changing the address used to carry packets of an
established communication exposes the communication to numerous established communication exposes the communication to numerous
attacks, as described in [11], so security mechanisms are required to attacks, as described in [11], so security mechanisms are required to
provide the required protection to the involved parties. This memo provide the required protection to the involved parties. This memo
describes a tool that can be used to provide protection against some describes a tool that can be used to provide protection against some
of the potential attacks, in particular against future / premeditated of the potential attacks, in particular against future / premeditated
attacks (a.k.a. time shifting attacks in [12]). attacks (a.k.a. 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 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 addresses that will be used by the mobile node are not known a
priori, the multiple addresses available to a host within the priori, the multiple addresses available to a host within the
multihomed site are pre-defined and known in advance in most of 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 cases. The mechanism proposed in this memo employs either
address set stability, and provides a secure binding between all the Cryptographically Generated Addresses (CGAs) [2] or a new variant of
addresses of a node in a multihomed site. The mechanism does so the same theme that uses the same format in the addresses. The new
without requiring the usage of public key cryptography, providing a variant, Hash Based Address (HBA), takes advantage of the address set
cost efficient alternative to public key cryptography based schemes. 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.
This memo describes a mechanism to provide a secure binding between For the purposes of the Shim6 protocol, the other characteristics of
the multiple addresses with different prefixes available to a host the CGAs and HBAs are similar. Both can be generated by the host
within a multihomed site. The main idea is that information about itself without any reliance on external infrastructure. Both employ
the multiple prefixes is included within the addresses themselves. the same format of addresses and same format of data fed to generate
This is achieved by generating the interface identifiers of the the addresses. It is not required that all interface identifiers of
addresses of a host as hashes of the available prefixes and a random a node's addresses are equal, preserving some degree of privacy
number. Then, the multiple addresses are obtained by prepending the through changes in the addresses used during the communications.
different prefixes to the generated interface identifiers. The
result is a set of addresses, called Hash Based Addresses (HBAs), The main idea in HBAs is that information about the multiple prefixes
that are inherently bound. A cost efficient mechanism is available is included within the addresses themselves. This is achieved by
to determine if two addresses belong to the same set, since given the generating the interface identifiers of the addresses of a host as
prefix set and the additional parameters used to generate the HBA, a hashes of the available prefixes and a random number. Then, the
single hash operation is enough to verify if an HBA belongs to a multiple addresses are obtained by prepending the different prefixes
given HBA set. No public key operations are involved in the to the generated interface identifiers. The result is a set of
verification process. In addition, it should also be noted that it addresses that are inherently bound. A cost efficient mechanism is
is not required that all interface identifiers of the addresses of an available to determine if two addresses belong to the same set, since
HBA set are equal, preserving some degree of privacy through changes given the prefix set and the additional parameters used to generate
in the addresses used during the communications. the HBA, a single hash operation is enough to verify if an HBA
belongs to a given HBA set.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[1]." document are to be interpreted as described in RFC 2119."
3. Overview 3. Overview
3.1. Threat Model 3.1. Threat Model
The threat analysis for the multihoming problem is described in The threat analysis for the multihoming problem is described in [11].
[11].This analysis basically identifies attacks based on redirection This analysis basically identifies attacks based on redirection of
of packets by a malicious attacker towards addresses that do not packets by a malicious attacker towards addresses that do not belong
belong to the multihomed node. There are essentially two type of to the multihomed node. There are essentially two type of
redirection attacks: communication hijacking and flooding attacks. redirection attacks: communication hijacking and flooding attacks.
communication hijacking attacks are about an attacker stealing on- communication hijacking attacks are about an attacker stealing on-
going and/or future communications from a victim. Flooding attacks going and/or future communications from a victim. Flooding attacks
are about redirecting the traffic generated by a legitimate source are about redirecting the traffic generated by a legitimate source
towards a third party, flooding it. The HBA solution provides full towards a third party, flooding it. The HBA solution provides full
protection against the communication hijacking attacks and limited protection against the communication hijacking attacks. The Shim6
protection against flooding attacks. Residual threats are described protocol [9] protects against flooding attacks. Residual threats are
in the security considerations section. described in the security considerations section.
3.2. Overview 3.2. Overview
The basic goal of the HBA mechanism is to securely bind together The basic goal of the HBA mechanism is to securely bind together
multiple IPv6 addresses that belong to the same multihomed host. multiple IPv6 addresses that belong to the same multihomed host.
This allows rerouting of traffic without worrying that the This allows rerouting of traffic without worrying that the
communication is being redirected to an attacker. The technique that communication is being redirected to an attacker. The technique that
is used is to include a hash of the permitted prefixes in the low is used is to include a hash of the permitted prefixes in the low
order bits of the IPv6 address. order bits of the IPv6 address.
So, eliding some details, say the available prefixes are A, B, C, and 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) D, the host would generate a prefix list P consisting of (A,B,C,D)
and a random number M. Then it would generate the new addresses: and a random number called Modifier M. Then it would generate the new
addresses:
A || H(M || A || P) A || H(M || A || P)
B || H(M || B || P) B || H(M || B || P)
C || H(M || C || P) C || H(M || C || P)
D || H(M || D || P) D || H(M || D || P)
Thus, given one valid address out of the group and the prefix list P Thus, given one valid address out of the group and the prefix list P
and the random number M it is possible to determine whether another and the random Modifier M it is possible to determine whether another
address is part of the group by computing the hash and checking address is part of the group by computing the hash and checking
against the low order bits. against the low order bits.
3.3. Motivations for the HBA design 3.3. Motivations for the HBA design
The design of the HBA technique was driven by the following The design of the HBA technique was driven by the following
considerations: considerations:
First of all, the goal of HBA is to provide a secure binding between First of all, the goal of HBA is to provide a secure binding between
the IPv6 address used as identifier by the upper layer protocols and the IPv6 address used as identifier by the upper layer protocols and
the alternative locators available in the multihomed node, so that the alternative locators available in the multihomed node, so that
redirection attacks are prevented. redirection attacks are prevented.
Second, in order to achieve such protection, the selected approach Second, in order to achieve such protection, the selected approach
was to include security information in the identifer itself, instead was to include security information in the identifier itself, instead
of relying in third trusted parties to secure the binding, such as of relying in third trusted parties to secure the binding, such as
the ones based on repositories or Public Key Infrastructure. This the ones based on repositories or Public Key Infrastructure. This
decision was driven by deployment considerations i.e. the cost of decision was driven by deployment considerations i.e. the cost of
deploying the third trusted party infrastucture. deploying the trusted third party infrastructure.
Third, application support considerations described in [16] resulted Third, application support considerations described in [16] resulted
in selecting routable IPv6 addresses to be used as identifiers. in selecting routable IPv6 addresses to be used as identifiers.
Hence, security information is stuffed within the interface Hence, security information is stuffed within the interface
identifier part of the IPv6 address. identifier part of the IPv6 address.
Fourth, performance considerations as described in [17] motivated the Fourth, performance considerations as described in [17] motivated the
usage of a hash based approach as oposed to a public key based usage of a hash based approach as opposed to a public key based
approach based on pure Cryptographic Generated Addresses (CGA), in approach based on pure Cryptographic Generated Addresses (CGA), in
order to avoid imposing the performance of public key operations for order to avoid imposing the performance of public key operations for
every communication in multihomed environments. The HBA appraoch every communication in multihomed environments. The HBA approach
presented in this document presents a cheaper alternative that is presented in this document presents a cheaper alternative that is
attractive to many common usage cases. Note that the HBA approach attractive to many common usage cases. Note that the HBA approach
and the CGA approaches are not mutually exclusive and that it is and the CGA approaches are not mutually exclusive and that it is
possible to generate addresses that are both CGA and HBA providing possible to generate addresses that are both valid CGA and HBA
the benefits of both approaches if needed. addresses providing the benefits of both approaches if needed.
4. Cryptographic Generated Addresses (CGA) compatibility considerations 4. Cryptographic Generated Addresses (CGA) compatibility considerations
As described in previous section, the HBA technique uses the As described in previous section, the HBA technique uses the
interface identifier part of the IPv6 address to encode information interface identifier part of the IPv6 address to encode information
about the multiple prefixes available to a multihomed host. However, about the multiple prefixes available to a multihomed host. However,
the interface identifier is also used to carry cryptographic the interface identifier is also used to carry cryptographic
information when Cryptographic Generated Addresses (CGA) [2] are information when Cryptographic Generated Addresses (CGA) [2] are
used. Therefore, conflicting usages of the interface identifier bits used. Therefore, conflicting usages of the interface identifier bits
may result if this is not taken into account during the HBA design. may result if this is not taken into account during the HBA design.
skipping to change at page 7, line 4 skipping to change at page 7, line 14
4. Cryptographic Generated Addresses (CGA) compatibility considerations 4. Cryptographic Generated Addresses (CGA) compatibility considerations
As described in previous section, the HBA technique uses the As described in previous section, the HBA technique uses the
interface identifier part of the IPv6 address to encode information interface identifier part of the IPv6 address to encode information
about the multiple prefixes available to a multihomed host. However, about the multiple prefixes available to a multihomed host. However,
the interface identifier is also used to carry cryptographic the interface identifier is also used to carry cryptographic
information when Cryptographic Generated Addresses (CGA) [2] are information when Cryptographic Generated Addresses (CGA) [2] are
used. Therefore, conflicting usages of the interface identifier bits used. Therefore, conflicting usages of the interface identifier bits
may result if this is not taken into account during the HBA design. may result if this is not taken into account during the HBA design.
There are at least two valid reasons to provide CGA-HBA There are at least two valid reasons to provide CGA-HBA
compatibility: compatibility:
First, the current Secure Neighbor Discovery specification [3] uses First, the current Secure Neighbor Discovery (SeND) specification [3]
the CGAs defined in [2] to prove address ownership. If HBAs are not uses the CGAs defined in [2] to prove address ownership. If HBAs are
compatible with CGAs, then nodes using HBAs for multihoming wouldn't not compatible with CGAs, then nodes using HBAs for multihoming
be able to do Secure Neighbor Discovery using the same addresses (at wouldn't be able to do Secure Neighbor Discovery using the same
least the parts of SeND that require CGAs). This would imply that addresses (at least the parts of SeND that require CGAs). This would
nodes would have to choose between security (from SeND) and fault imply that nodes would have to choose between security (from SeND)
tolerance (from shim6). In addition to SeND, there are other and fault tolerance (from IPv6 multihoming support provided by the
protocols that are considering to benefit from the advantages offered Shim6 protocol [9]). In addition to SeND, there are other protocols
by the CGA scheme, such as mobility support protocols [13]. Those that are considering to benefit from the advantages offered by the
protocols would also become incompatible with HBAs if HBAs are not CGA scheme, such as mobility support protocols [13]. Those protocols
compatible with CGAs. could not be used with HBAs if HBAs are not compatible with CGAs.
Second, CGAs provide additional features that cannot be achieved Second, CGAs provide additional features that cannot be achieved
using only HBAs. In particular, because of its own nature, the HBA using only HBAs. In particular, because of its own nature, the HBA
technique only supports a predetermined prefix set that is known at technique only supports a predetermined prefix set that is known at
the time of the generation of the HBA set. No additions of new the time of the generation of the HBA set. No additions of new
prefixes to this original set are supported after the HBA set prefixes to this original set are supported after the HBA set
generation. In most of the cases relevant for site multihoming, this 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 a problem because the prefix set available to a multihomed set
is not very dynamic. New prefixes may be added in a multihomed site 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 when a new ISP is available, but the timing of those events are
skipping to change at page 8, line 14 skipping to change at page 8, line 23
CGA and the prefix-set information of an HBA. The CGA specification CGA and the prefix-set information of an HBA. The CGA specification
already considers the possibility of including additional information already considers the possibility of including additional information
into the CGA generation process through the usage of Extension Fields into the CGA generation process through the usage of Extension Fields
in the CGA Parameter Data Structure. It is then possible to define a 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 Multi-Prefix Extension for CGA so that the prefix set information is
included in the interface identifier generation process. included in the interface identifier generation process.
Even though a CGA compatible approach is adopted, it should be noted Even though a CGA compatible approach is adopted, it should be noted
that HBAs and CGAs are different concepts. In particular, the CGA is 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 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 a prefix set. This means that a public key is not required to
to generate an HBA. Because of that, we define three different types generate an HBA-only address. Because of that, we define three
of addresses: different types of addresses:
- CGA-only addresses: These are addresses generated as specified in - CGA-only addresses: These are addresses generated as specified in
[2] without including the Multi-Prefix Extension. They are bound [2] without including the Multi-Prefix Extension. They are bound
to a public key and to a single prefix (contained in the basic CGA to a public key and to a single prefix (contained in the basic CGA
Parameter Data Structure). These addresses can be used for SeND Parameter Data Structure). These addresses can be used for SeND
[3] and if used for multihoming, their application will have to be [3] and if used for multihoming, their application will have to be
based on the public key usage. based on the public key usage.
- CGA/HBA addresses: These addresses are CGAs that include the - CGA/HBA addresses: These addresses are CGAs that include the
Multi-Prefix Extension in the CGA Parameters Data Structure used Multi-Prefix Extension in the CGA Parameters Data Structure used
for their generation. These addresses are bound to a public key for their generation. These addresses are bound to a public key
and a prefix set and they provide both CGA and HBA and a prefix set and they provide both CGA and HBA
functionalities. They can be used for SeND as defined in [3] and functionalities. They can be used for SeND as defined in [3] and
for any usage defined for HBA (such as a shim6 protocol) for any usage defined for HBA (such as a Shim6 protocol)
- HBA-only addresses: These addresses are bound to a prefix set but - HBA-only addresses: These addresses are bound to a prefix set but
they are not bound to a public key. Because CGA compatibility, they are not bound to a public key. Because HBAs are compatible
the CGA Parameter Data Structure will be used for their with CGA, the CGA Parameter Data Structure will be used for their
generation, but a random nonce will be included in the Public Key generation, but a random nonce will be included in the Public Key
field instead of a public key. These addresses can be used for field instead of a public key. These addresses can be used for
HBA based multihoming protocols, but they cannot be used for SeND. HBA based multihoming protocols, but they cannot be used for SeND.
5. Multi-Prefix Extension for CGA 5. Multi-Prefix Extension for CGA
The Multi-Prefix Extension has the following TLV format as defined in The Multi-Prefix Extension has the following TLV format as defined in
[8] : [8] :
0 1 2 3 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 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 | | Extension Type | Extension Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved | |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 10, line 12 skipping to change at page 10, line 15
2. For other Sec values, RFC4982 [10] has defined a CGA SEC registry 2. For other Sec values, RFC4982 [10] has defined a CGA SEC registry
which will contain the specifications used to generate CGAs. The which will contain the specifications used to generate CGAs. The
generation procedures defined in such specifications must be used for generation procedures defined in such specifications must be used for
Sec values other than 0,1 or 2. Sec values other than 0,1 or 2.
The CGA generation process has three inputs: a 64-bit subnet prefix, 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 a public key (encoded in DER as an ASN.1 structure of the type
SubjectPublicKeyInfo), and the security parameter Sec. SubjectPublicKeyInfo), and the security parameter Sec.
The main difference between the CGA generation and the HBA generation 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 is that while a CG A can be generated independently, all the HBAs of
given HBA set have to be generated using the same parameters, which 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 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 in a coordinated fashion. In this memo, we will describe a mechanism
to generate all the addresses of a given HBA set. The generation 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 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, based in the CGA generation process defined in [2]. More precisely,
the HBA set generation process will be defined as a sequence of the HBA set generation process will be defined as a sequence of
lightly modified CGA generations. lightly modified CGA generations.
The changes required in the CGA generation process when generating a The changes required in the CGA generation process when generating a
single HBA are the following: First, the Multi-Prefix Extension has single HBA are the following: First, the Multi-Prefix Extension has
to be included in the CGA Parameters Data Structure. Second, in the to be included in the CGA Parameters Data Structure. Second, in the
case that the address being generated is an HBA-only address, a 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 random nonce will have to be used as input instead of a valid public
key. For backward compatibility issues with pure CGAs, the random key. For backwards compatibility issues with pure CGAs, the random
nonce must be encoded as a public key as defined in [2]. In 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 particular, the random nonce MUST be formatted as a DER-encoded ASN.1
structure of the type SubjectPublicKeyInfo, defined in the Internet structure of the type SubjectPublicKeyInfo, defined in the Internet
X.509 certificate profile [5]. The algorithm identifier must be X.509 certificate profile [5]. The algorithm identifier MUST be
rsaEncryption, which is 1.2.840.113549.1.1.1, and the random nonce 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 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. 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 resulting HBA-set generation process is the following:
The inputs to the HBA generation process are: The inputs to the HBA generation process are:
o A vector of n 64-bit prefixes o A vector of n 64-bit prefixes
o A Sec parameter, and o A Sec parameter, and
o In the case of the generation of a set of HBA/CGA addresses a 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 public key is also provided as input (not required when generating
HBA-only addresses) HBA-only addresses)
The output of the HBA generation process are: The output of the HBA generation process are:
o An HBA-set o An HBA-set
o their respective CGA Parameters Data Structures o their respective CGA Parameters Data Structures
The steps of the HBA-set generation process are: The steps of the HBA-set generation process are:
1. Multi-Prefix Extension generation. Generate the Multi-Prefix 1. Multi-Prefix Extension generation. Generate the Multi-Prefix
Extension with the format defined in section 3. Include the Extension with the format defined in section 5. Include the
vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext 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 Len field value is (n*8 + 4). If a public key is provided, then
the P flag is set. Otherwise, the P flag is reset. 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 2. Modifier generation. Generate a Modifier as a random or
pseudorandom 128-bit value. If a public key has not been provided 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 as an input, generate the Extended Modifier as a 384-bit random or
pseudorandom value. Encode the Extended Modifier value as a RSA pseudorandom value. Encode the Extended Modifier value as a RSA
key in a DER-encoded ASN.1 structure of the type key in a DER-encoded ASN.1 structure of the type
SubjectPublicKeyInfo defined in the Internet X.509 certificate SubjectPublicKeyInfo defined in the Internet X.509 certificate
profile [5]. profile [5].
3. Concatenate from left to right the Modifier, 9 zero octets, the 3. Concatenate from left to right the Modifier, 9 zero octets, the
skipping to change at page 11, line 31 skipping to change at page 11, line 34
key was provided) and the Multi-Prefix Extension. Execute the key was provided) and the Multi-Prefix Extension. Execute the
SHA-1 algorithm on the concatenation. Take the 112 leftmost bits SHA-1 algorithm on the concatenation. Take the 112 leftmost bits
of the SHA-1 hash value. The result is Hash2. of the SHA-1 hash value. The result is Hash2.
4. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are 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, all zero (or if Sec=0), continue with step (5). Otherwise,
increment the modifier by one and go back to step (3). increment the modifier by one and go back to step (3).
5. Set the 8-bit collision count to zero. 5. Set the 8-bit collision count to zero.
6. For i=1 to n do 6. For i=1 to n (number of prefixes) do
6.1. Concatenate from left to right the final Modifier value, 6.1. Concatenate from left to right the final Modifier value,
Prefix[i], the collision count, the encoded public key or the Prefix[i], the collision count, the encoded public key or the
encoded Extended Modifier (if no public key was provided) and encoded Extended Modifier (if no public key was provided) and
the Multi-Prefix Extension. Execute the SHA-1 algorithm on the the Multi-Prefix Extension. Execute the SHA-1 algorithm on the
concatenation. Take the 64 leftmost bits of the SHA-1 hash concatenation. Take the 64 leftmost bits of the SHA-1 hash
value. The result is Hash1[i]. value. The result is Hash1[i].
6.2. Form an interface identifier from Hash1[i] by writing the 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 value of Sec into the three leftmost bits and by setting bits 6
skipping to change at page 12, line 29 skipping to change at page 12, line 29
The following procedure is only valid for Sec values of 0, 1 and 2. The following procedure is only valid for Sec values of 0, 1 and 2.
For other Sec values, RFC4982 [10] has defined a CGA SEC registry For other Sec values, RFC4982 [10] has defined a CGA SEC registry
which will contain the specifications used to verify CGAs. The which will contain the specifications used to verify CGAs. The
verification procedures defined in such specifications must be used verification procedures defined in such specifications must be used
for Sec values other than 0,1 or 2. for Sec values other than 0,1 or 2.
7.1. Verification that a particular HBA address corresponds to a given 7.1. Verification that a particular HBA address corresponds to a given
CGA Parameter Data Structure CGA Parameter Data Structure
HBAs are constructed as a CGA Extension, so a properly formated HBA HBAs are constructed as a CGA Extension, so a properly formatted HBA
and its correspondent CGA Parameter Data Structure will successfully and its correspondent CGA Parameter Data Structure will successfully
finish the verification process described in section 5 of [2]. Such finish the verification process described in section 5 of [2]. Such
verification is useful when the goal is the verification of the verification is useful when the goal is the verification of the
binding between the public key and the HBA. binding between the public key and the HBA.
7.2. Verification that a particular HBA address belongs tto the HBA set 7.2. Verification that a particular HBA address belongs to the HBA set
associated to a given CGA Parameter Data Structure associated to a given CGA Parameter Data Structure
For multihoming applications, it is also relevant to verify if a For multihoming applications, it is also relevant to verify if a
given HBA address belongs to a certain HBA set. An HBA set is given HBA address belongs to a certain HBA set. An HBA set is
identified by a CGA Parameter Data structure that contains a Multi- identified by a CGA Parameter Data structure that contains a Multi-
Prefix Extension. So, it is then needed to verify if an HBA belongs Prefix Extension. So, we need to verify if a given HBA belongs to
to the HBA set defined by a CGA Parameter Data Structure. It should the HBA set defined by a CGA Parameter Data Structure. It should be
be noted that it may be needed to verify if an HBA belongs to the HBA noted that we may need to verify if an HBA belongs to the HBA set
set defined by the CGA Parameter Data Structure of another HBA of the 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 set. If this is the case, HBAs will fail to pass the CGA
[2] will fail, because the prefix included in the Subnet Prefix field verification process defined in [2], because the prefix included in
of the CGA Parameter Data Structure will not match with the one of the Subnet Prefix field of the CGA Parameter Data Structure will not
the HBA that is being verified. However, this doesn't mean that this match the prefix of the HBA that is being verified. To verify if an
HBA does not belong to the HBA set. In order to address this issue, HBA belongs to an HBA set associated with another HBA, verify that
it is only required to verify that the HBA prefix is included in the HBA prefix is included in the prefix set defined in the Multi-
prefix set defined in the Multi-Prefix Extension, and if this is the Prefix Extension, and if this is the case, then substitute the prefix
case, then substitute the prefix included in the Subnet Prefix field included in the Subnet Prefix field by the prefix of the HBA, and
by the prefix of the HBA, and then perform the CGA verification then perform the CGA verification process defined in [2].
process defined in [2].
So, the process to verify that an HBA belongs to an HBA set So, the process to verify that an HBA belongs to an HBA set
determined by a CGA Parameter Data Structure is called HBA determined by a CGA Parameter Data Structure is called HBA
verification and it is the following: verification and it is the following:
The inputs to the HBA verification process are: The inputs to the HBA verification process are:
o An HBA o An HBA
o A CGA Parameter Data Structure o A CGA Parameter Data Structure
The steps of the HBA verification process are the following: The steps of the HBA verification process are the following:
skipping to change at page 13, line 37 skipping to change at page 13, line 37
Multi-Prefix Extension) as inputs. The steps of the process are Multi-Prefix Extension) as inputs. The steps of the process are
included below, extracted from [2] included below, extracted from [2]
2.1. Check that the collision count in the CGA Parameters Data 2.1. Check that the collision count in the CGA Parameters Data
Structure is 0, 1 or 2. The CGA verification fails if the Structure is 0, 1 or 2. The CGA verification fails if the
collision count is out of the valid range. collision count is out of the valid range.
2.2. Check that the subnet prefix in the CGA Parameters Data 2.2. Check that the subnet prefix in the CGA Parameters Data
Structure is equal to the subnet prefix (i.e., the leftmost 64 Structure is equal to the subnet prefix (i.e., the leftmost 64
bits) of the address. The CGA verification fails if the prefix bits) of the address. The CGA verification fails if the prefix
values differ. [Note: This step is trivially successful values differ. [Note: This step always succeeds because of the
because step 1] action taken in step 1]
2.3. Execute the SHA-1 algorithm on the CGA Parameters Data 2.3. Execute the SHA-1 algorithm on the CGA Parameters Data
Structure. Take the 64 leftmost bits of the SHA-1 hash value. Structure. Take the 64 leftmost bits of the SHA-1 hash value.
The result is Hash1. The result is Hash1.
2.4. Compare Hash1 with the interface identifier (i.e., the 2.4. Compare Hash1 with the interface identifier (i.e., the
rightmost 64 bits) of the address. Differences in the three 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) 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 are ignored. If the 64-bit values differ (other than in the
five ignored bits), the CGA verification fails. five ignored bits), the CGA verification fails.
skipping to change at page 15, line 29 skipping to change at page 15, line 29
\ / \ /
\ / \ /
+---------------------+ +---------------------+
| multihomed site | | multihomed site |
| PA::/nA | | PA::/nA |
| PB::/nB +------+ | | PB::/nB +------+ |
| |Host1 | | | |Host1 | |
| +------+ | | +------+ |
+---------------------+ +---------------------+
We assume that both Host1 and Host2 support the shim6 protocol. We assume that both Host1 and Host2 support the Shim6 protocol.
Host2 in not located in a multihomed site, so there is no need for it 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 to create HBAs (it must be able to verify them though, in order to
support the shim6 protocol, as we will describe next.) support the Shim6 protocol, as we will describe next.)
Host1 is located in the multihomed site, so it will generate its 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- 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 set generation process as detailed in Section 6 of this memo. The
inputs of the HBA-set generation process will be: a prefix vector 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 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. 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 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 can also illustrate how a renumbering event can be supported when
HBA/CGA addresses are used (see the sub-section referring to dynamic HBA/CGA addresses are used (see the sub-section referring to dynamic
address set support). So, after executing the HBA-set generation address set support). So, after executing the HBA-set generation
process, Host1 will have: an HBA-set consisting in two addresses i.e. 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 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 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 different but both contain information about the prefix set available
in the multihomed site. in the multihomed site.
We will next consider a communication between Host1 and Host2. We will next consider a communication between Host1 and Host2.
Assume that both ISPs of the multihomed site are working properly, so Assume that both ISPs of the multihomed site are working properly, so
any of the available addresses in Host1 can be used for the any of the available addresses in Host1 can be used for the
communication. Suppose then that the communication is established communication. Suppose then that the communication is established
using PA:LA:iidA and IPHost2 for Host1 and Host2 respectively. So 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 far, no special Shim6 support has been required, and PA:LA:iidA is
used as any other global IP address. used as any other global IP address.
Suppose that at a certain moment one of the hosts involved in the Suppose that at a certain moment one of the hosts involved in the
communication decides that multihoming support is required in this communication decides that multihoming support is required in this
communication (this basically means that one of the hosts involved in communication (this basically means that one of the hosts involved in
the communication desires enhanced fault tolerance capabilities for the communication desires enhanced fault tolerance capabilities for
this communication, so that if an outage occurs, the communication this communication, so that if an outage occurs, the communication
can be rehomed to an alternative provider). can be re-homed to an alternative provider).
At this moment, the shim6 protocol Host-Pair Context establishment At this moment, the Shim6 protocol Host-Pair Context establishment
exchange will be perfomed between the two hosts (see [9].). In this exchange will be performed between the two hosts (see [9].). In this
exchange, Host1 will send CGA_PDS_A to Host2. exchange, Host1 will send CGA_PDS_A to Host2.
After the reception of CGA_PDS_A, Host2 will verify that the received After the reception of CGA_PDS_A, Host2 will verify that the received
CGA Parameter Data Structure corresponds to the address being used in CGA Parameter Data Structure corresponds to the address being used in
the communication PA:LA:iidA. This means that Host2 will execute the the communication PA:LA:iidA. This means that Host2 will execute the
HBA verification process described in Section 5 of this memo with PA: 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 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 succeed since the CGA Parameter Data Structure and the addresses used
in the verification match. in the verification match.
As long as there are no outages affecting the communication path As long as there are no outages affecting the communication path
through ISPA, packets will continue flowing. If a failure affects through ISPA, packets will continue flowing. If a failure affects
the path through ISPA, Host1 will attempt to re-home the the path through ISPA, Host1 will attempt to re-home the
communication to an alternative address i.e. PB:LB:iidB. For that, communication to an alternative address i.e. PB:LB:iidB. For that,
after detecting the outage, Host1 will inform Host2 about the after detecting the outage, Host1 will inform Host2 about the
alternative address. Host2 will verify that the new address belongs alternative address. Host2 will verify that the new address belongs
skipping to change at page 17, line 6 skipping to change at page 17, line 6
prevention in the Security Considerations section of this memo). prevention in the Security Considerations section of this memo).
Once the new address is verified, it can be used as an alternative Once the new address is verified, it can be used as an alternative
locator to re-home the communication, while preserving the original locator to re-home the communication, while preserving the original
address (PA:LA:iidA) as an identifier for the upper layers. This address (PA:LA:iidA) as an identifier for the upper layers. This
means that following packets will be addressed to/from this new means that following packets will be addressed to/from this new
address. Note that no additional HBA verification is required for address. Note that no additional HBA verification is required for
the following packets, since the new valid address can be stored in the following packets, since the new valid address can be stored in
Host2. Host2.
Eventually, the communication will end and the associated shim6
context information will be discarded.
In this example, only the HBA capabilities of the Host1 addresses In this example, only the HBA capabilities of the Host1 addresses
were used. In other words, neither the public key included in the were used. In other words, neither the public key included in the
CGA Parameter Data Structure nor its correspondent private key was CGA Parameter Data Structure nor its correspondent private key was
used in the protocol. In the following section we will consider a used in the protocol. In the following section we will consider a
case where its usage is required. case where its usage is required.
8.1. Dynamic Address Set Support 8.1. Dynamic Address Set Support
In the previous section we have presented the mechanisms that allow a In the previous section we have presented the mechanisms that allow a
host to use different addresses of a pre-determined set to exchange host to use different addresses of a pre-determined set to exchange
skipping to change at page 17, line 48 skipping to change at page 17, line 45
be noted that the HBA mechanism described in the previous section be noted that the HBA mechanism described in the previous section
cannot be used to verify this new address, since this address does 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 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 moment of the generation of the HBA set). This means that
alternative verification mechanisms will be needed. alternative verification mechanisms will be needed.
In order to verify this new address, CGA capabilities of PA:LA:iidA 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 are used. Note that the same address is used, only that the
verification mechanism is different. So, if Host1 wants to use PC: verification mechanism is different. So, if Host1 wants to use PC:
LC:addC to exchange packets in the established communication, it will LC:addC to exchange packets in the established communication, it will
use message of the shim6 protocol, conveying the new address, PC:LC: use the UPDATE message defined in the Shim6 protocol [9], conveying
addC, and this message will be signed using the private key the new address, PC:LC:addC, and this message will be signed using
corresponding to the public key contained in CGA_PDS_A. When Host2 the private key corresponding to the public key contained in
receives the message, it will verify the signature using the public CGA_PDS_A. When Host2 receives the message, it will verify the
key contained in the CGA Parameter Data Structure associated with the signature using the public key contained in the CGA Parameter Data
address used for establishing the communication i.e. CGA_PDS_A and Structure associated with the address used for establishing the
PA:LA:iidA respectively. Once that the signature is verified, the communication i.e. CGA_PDS_A and PA:LA:iidA respectively. Once that
new address (PC:LC:addC) can be used in the communication. 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 t 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 the inclusion of a new prefix in
the prefix set. Moreover, since HBA addresses need to be generated
locally, once that 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 9. DNS considerations
HBA sets can be generated using any prefix set. Actually, the only HBA sets can be generated using any prefix set. Actually, the only
particularity of the HBA is that they contain information about the particularity of the HBA is that they contain information about the
prefix set in the interface identifier part of the address in 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 form of a hash, but no assumption about the properties of prefixes
used for the HBA generation is made. This basically means that used for the HBA generation is made. This basically means that
depending on the prefixes used for the HBA set generation, it may or depending on the prefixes used for the HBA set generation, it may or
may not be recommended to publish the resulting (HBA) addresses in may not be recommended to publish the resulting (HBA) addresses in
the DNS. For instance, when ULA prefixes [18] are included in the the DNS. For instance, when ULA prefixes [18] are included in the
HBA generation process specific DNS considerations related to the HBA generation process specific DNS considerations related to the
local nature of the ULA should be taken into account and proper local nature of the ULA should be taken into account and proper
reccomendations related to publishing such prefixes in the DNS should recommendations related to publishing such prefixes in the DNS should
followed. followed. Moreover, a given host can have among its addresses 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 are 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 are indistinguishable from other IPv6 addresses in their
format, an initiator will not be able to distinguish by merely
looking at the 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 In addition, it should be noted that the actual HBA values are a
result of the HBA generation procedure meaning that they cannot be result of the HBA generation procedure meaning that they cannot be
arbitrarily chosen. This has an implication with respect to DNS arbitrarily chosen. This has an implication with respect to DNS
management, because the party that generates the HBA address set management, because the party that generates the HBA address set
needs to convey the address information to the DNS manager, so that needs to convey the address information to the DNS manager, so that
the addresses are published and not the other way round. The the addresses are published and not the other way round. The
situation is similar to regular CGA addresses and even to the case situation is similar to regular CGA addresses and even to the case
where stateless address autoconfiguration is used. 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 10. IANA considerations
This document defines a new CGA Extension, the Multi-Prefix This document defines a new CGA Extension, the Multi-Prefix
Extension. This extension has been assigned the CGA Extension Type Extension. This extension has been assigned the CGA Extension Type
value TBD (IANA). value TBD (IANA).
To be removed prior publication: The 0x12 value is recommended for To be removed prior publication: The 0x12 value is recommended for
trials whil IANA does not assign the value. We request IANA to trials while IANA does not assign the value. We request IANA to
assign the 0x12 value, in order not to impose changes on existent assign the 0x12 value, in order not to impose changes on existent
implemntations. implementations.
11. Security considerations 11. Security considerations
The goal of HBAs is to create a group of addresses that are securely The goal of HBAs is to create a group of addresses that are securely
bound, so that they can be used interchangeably when communicating bound, so that they can be used interchangeably when communicating
with a node. If there is no secure binding between the different 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 addresses of a node, a number of attacks are enabled, as described in
[11]. In particular, it would possible for an attacker to redirect [11]. In particular, it would possible for an attacker to redirect
the communications of a victim to an address selected by the the communications of a victim to an address selected by the
attacker, hijacking the communication. When using HBAs, only the attacker, hijacking the communication. When using HBAs, only the
skipping to change at page 19, line 42 skipping to change at page 20, line 30
in the Multi-Prefix Extension and other extensions. In any case, in 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 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 brute force attack, which implies the generation of multiple HBA sets
with different parameters (for instance with a different Modifier) with different parameters (for instance with a different Modifier)
until the desired conditions are meet. The expected number of times until the desired conditions are meet. The expected number of times
that the generation process will have to be repeated until the that the generation process will have to be repeated until the
desired HBA set is found is exponentially related with the number of desired HBA set is found is exponentially related with the number of
bits containing hash information included in the interface identifier bits containing hash information included in the interface identifier
of the HBA. Since 59 of the 64 bits of 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 contain hash bits, then the expected number of generations that will
have to be performed by the attacker are O(2^59). 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 increasing The protection against brute force attacks can be improved increasing
the Sec parameter. A non zero Sec parameter implies that steps 3-4 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 of the generation process will be repeated O(2^(16*Sec)) times
(expected number of times). If we assimilate the cost of repeating (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 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 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 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 values, Sec protection mechanisms will be defined by the
specifications pointed by the CGA SEC registry defined in RFC 4982 specifications pointed by the CGA SEC registry defined in RFC 4982
[10]. [10].
11.1. Security considerations when using HBAs in the shim6 protocol 11.1. Security considerations when using HBAs in the Shim6 protocol
In this section we will analyze the security provided by HBAs in the In this section we will analyze the security provided by HBAs in the
context of a shim6 protocol as described in section 6 of this memo. 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- First of all, it must be noted that HBAs cannot prevent man-in-the-
middle (hereafter MITM) attacks. This means, that in the scenario middle (hereafter MITM) attacks. This means, that in the scenario
described in Section 6, if an attacker is located along the path described in Section 8, if an attacker is located along the path
between Host1 and Host2 during the lifetime of the communication, the between Host1 and Host2 during the lifetime of the communication, the
attacker will be able to change the addresses used for the attacker will be able to change the addresses used for the
communication. This means that he will be able to change the communication. This means that he will be able to change the
addresses used in the communication, adding or removing prefixes at addresses used in the communication, adding or removing prefixes at
his will. However, the attacker must make sure that the CGA his will. However, the attacker must make sure that the CGA
Parameter Data Structure and the HBA set is changed accordingly. Parameter Data Structure and the HBA set is changed accordingly.
This essentially means that the attacker will have to change the This essentially means that the attacker will have to change the
interface identifier part of the addresses involved, since a change interface identifier part of the addresses involved, since a change
in the prefix set will result in different interface identifiers of in the prefix set will result in different interface identifiers of
the addresses of the HBA set, unless the appropriate Modifier value the addresses of the HBA set, unless the appropriate Modifier value
skipping to change at page 20, line 50 skipping to change at page 21, line 43
If the attacker is not on-path when the initial CGA Parameter Data If the attacker is not on-path when the initial CGA Parameter Data
Structure is exchanged, his only possibility to launch a redirection Structure is exchanged, his only possibility to launch a redirection
attack is to fake the signature of the message for adding new attack is to fake the signature of the message for adding new
addresses using CGA capabilities of the addresses. This implies addresses using CGA capabilities of the addresses. This implies
discovering the public key used in the CGA Parameter Data Structure discovering the public key used in the CGA Parameter Data Structure
and then cracking the key pair, which doesn't seem feasible. So in 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- order to launch a redirection attack, the attacker needs to be on-
path when the CGA Parameter Data Structure is exchanged, so he can path when the CGA Parameter Data Structure is exchanged, so he can
modify it. Now, in order to launch the redirection attack, the 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 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 Parameter Data Structure. We have seen in the previous section that
there are two possible approaches for this: there are two possible approaches for this:
1. Find the right Modifier value, so that the address initially used 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 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 this attack is O(2(59+16*Sec)) iterations of the generation
process, so it is deemed unfeasible process, so it is deemed unfeasible
2. Use any Modifier value, so that the address initially used in the 2. Use any Modifier value, so that the address initially used in the
communication is probably not included in the HBA set. In this communication is probably not included in the HBA set. In this
case, the attacker must remain on-path, since he needs to rewrite case, the attacker must remain on-path, since he needs to rewrite
the address carried in the packets (if not the endpoints will the address carried in the packets (if not the endpoints will
notice a change in the address used in the communication). This notice a change in the address used in the communication). This
essentially means that the attacker cannot launch a time-shifted essentially means that the attacker cannot launch a time-shifted
attack, but he must be a full time man-in-the-middle. attack, but he must be a full time man-in-the-middle.
So, the conclusion is that HBAs provide protection against time- So, the conclusion is that HBAs provide protection against time-
shifted attacks shifted attacks
HBAs do not provide complete protection against flooding 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 very difficult to launch a flooding attack towards However, HBAs make very difficult to launch a flooding attack towards
a specific address. It is possible though, to launch a flooding a specific address. It is possible though, to launch a flooding
attack against a prefix. 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 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 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 P:iid. The attack would consist in establishing a communication with
a server S and requesting a heavy flow from it. Then simply redirect 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 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 attack the attacker needs to generate an HBA set including P and PX
in the prefix set and that the resulting HBA set contains P:iid. In in the prefix set and that the resulting HBA set contains P:iid. In
order to do this, the attacker needs to find the appropriate Modifier order to do this, the attacker needs to find the appropriate Modifier
value. The expected number of attempts required to find such value. The expected number of attempts required to find such
skipping to change at page 22, line 7 skipping to change at page 23, line 7
target address is not assigned to any host, the flow will flood 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 access link of the target site, and the site access router will also
suffer the overload. Such attack cannot be prevented using HBAs, suffer the overload. Such attack cannot be prevented using HBAs,
since the attacker can easily generate an HBA set using his own since the attacker can easily generate an HBA set using his own
prefix and the target network prefix. In order to prevent such prefix and the target network prefix. In order to prevent such
attacks, additional mechanisms are required, such as reachability attacks, additional mechanisms are required, such as reachability
tests. tests.
11.2. Privacy Considerations 11.2. Privacy Considerations
HBAs can be used as RFC 3041 [7] addresses. If a node wants to use 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 temporary addresses, it will need to periodically generate new HBA
sets. The effort required for this operation depends on the Sec 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 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 is similar to the cost of generating a random number i.e. one
iteration of the HBA set generation procedure. However, if Sec>0, iteration of the HBA set generation procedure. However, if Sec>0,
then the cost of generating an HBA set is significantly increased, then the cost of generating an HBA set is significantly increased,
since it required O(2(16*Sec)) iterations of the generation process. since it required O(2(16*Sec)) iterations of the generation process.
In this case, depending on the frequency of address change required, In this case, depending on the frequency of address change required,
the support for RFC 3041 address may be more expensive. the support for RFC 4941 address may be more expensive.
11.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). The actual verification procedure is outside the
scope of this specification.
11.4. SHA-1 Dependency Considerations. 11.3. SHA-1 Dependency Considerations.
Recent attacks on currently used hash functions have motivated a Recent attacks on currently used hash functions have motivated a
considerable amount of concern in the Internet community. The considerable amount of concern in the Internet community. The
recommended approach [14] [15] to deal with this issue is first to recommended approach [14] [15] to deal with this issue is first to
analyze the impact of these attacks on the different Internet analyze the impact of these attacks on the different Internet
protocols that use hash functions and second to make sure that the protocols that use hash functions and second to make sure that the
different Internet protocols that use hash functions are capable of different Internet protocols that use hash functions are capable of
migrating to an alternative (more secure) hash function without a migrating to an alternative (more secure) hash function without a
major disruption in the Internet operation. major disruption in the Internet operation.
skipping to change at page 23, line 14 skipping to change at page 24, line 6
13. Acknowledgments 13. Acknowledgments
The initial discussion about HBA benefited from contributions from The initial discussion about HBA benefited from contributions from
Alberto Garcia-Martinez, Tuomas Aura and Arturo Azcorra. Alberto Garcia-Martinez, Tuomas Aura and Arturo Azcorra.
The HBA-set generation and HBA verification processes described in The HBA-set generation and HBA verification processes described in
this document contain several steps extracted from [2]. this document contain several steps extracted from [2].
Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka
Savola, Brian Carpenter, Eric Rescorla, Robin Whittle and Sam Hartman Savola, Brian Carpenter, Eric Rescorla, Robin Whittle, Matthijs
have reviewed this document and provided valuable comments. Mekking, Hannes Tschofenig, Spencer Dawkins, Lars Eggert, Tim Polk,
Peter Koch, Niclas Comstedt and Sam Hartman have reviewed this
document and provided valuable comments.
The text included in section 2.2 Overview was provided by Eric The text included in section 3.2 Overview was provided by Eric
Rescorla. Rescorla.
We would also like to thanks Francis Dupont for providing the first We would also like to thanks Francis Dupont for providing the first
implementation of HBA implementation of HBA
14. Change Log 14. Change Log
To be removed prior publication To be removed prior publication
14.1. Changes from draft-ietf-shim6-hba-03 to draft-ietf-multi6-hba-04 14.1. Changes from draft-ietf-shim6-hba-04 to draft-ietf-multi6-hba-05
addressed comments from reviews from Matthijs Mekking, Hannes
Tschofenig, Spencer Dawkins, Sam Hartman, Lars Eggert, Tim Polk, Jari
Arkko
14.2. Changes from draft-ietf-shim6-hba-03 to draft-ietf-multi6-hba-04
Reworded the definition of the P flag Reworded the definition of the P flag
Changed IANA considerations to include a request to IANA to assign Changed IANA considerations to include a request to IANA to assign
the trial value. the trial value.
Updated HBA generation and verification process to make coheret with Updated HBA generation and verification process to make coherent with
rfc4982 rfc4982
Updated the sha1 consideration section to make it coherent with Updated the sha1 consideration section to make it coherent with
rfc4982 rfc4982
Updated the DNS consideration section to include an explicit Updated the DNS consideration section to include an explicit
references to ULAs and added a section about DNS managemnt of HBAs references to ULAs and added a section about DNS management of HBAs
Editorial changes Editorial changes
Updatred references Updatred references
14.2. Changes from draft-ietf-shim6-hba-02 to draft-ietf-multi6-hba-03 14.3. Changes from draft-ietf-shim6-hba-02 to draft-ietf-multi6-hba-03
added terminology section added terminology section
updated references updated references
14.3. Changes from draft-ietf-shim6-hba-01 to draft-ietf-multi6-hba-02 14.4. Changes from draft-ietf-shim6-hba-01 to draft-ietf-multi6-hba-02
A new section SHA-1 Dependency Considerations has been added in the A new section SHA-1 Dependency Considerations has been added in the
Security Considerations Section (addressing Eric Rescorla (SecDir) Security Considerations Section (addressing Eric Rescorla (SecDir)
comment) comment)
A new Overview section containing a Threat model subsection, a A new Overview section containing a Threat model subsection, a
general description subsection and a motivations subsection has been general description subsection and a motivations subsection has been
added (addressing Eric Rescorla (SecDir) comment) added (addressing Eric Rescorla (SecDir) comment)
Modified section of HBA verification in order to improve readability Modified section of HBA verification in order to improve readability
14.4. Changes from draft-ietf-shim6-hba-00 to draft-ietf-multi6-hba-01 14.5. Changes from draft-ietf-shim6-hba-00 to draft-ietf-multi6-hba-01
Changed the format of the Multi-Prefix extension to make it compliant Changed the format of the Multi-Prefix extension to make it compliant
with the generic TLV format proposed for CGA extensions with the generic TLV format proposed for CGA extensions
Added IANA considerations section Added IANA considerations section
Added DNS considerations section Added DNS considerations section
14.5. Changes from draft-ietf-multi6-hba-00 to draft-ietf-shim6-hba-00 14.6. Changes from draft-ietf-multi6-hba-00 to draft-ietf-shim6-hba-00
Editorial changes Editorial changes
14.6. Changes from draft-bagnulo-multi6dt-hba-00 to 14.7. Changes from draft-bagnulo-multi6dt-hba-00 to
draft-ietf-multi6-hba-00 draft-ietf-multi6-hba-00
Added "Example of HBA application to a multihoming scenario" section Added "Example of HBA application to a multihoming scenario" section
Added Privacy Considerations section Added Privacy Considerations section
Added flooding attacks comments in the Security Considerations Added flooding attacks comments in the Security Considerations
section section
Added the Multi-Prefix extension in step 6.1 of the HBA-set Added the Multi-Prefix extension in step 6.1 of the HBA-set
skipping to change at page 25, line 31 skipping to change at page 26, line 31
Certificate and Certificate Revocation List (CRL) Profile", Certificate and Certificate Revocation List (CRL) Profile",
RFC 3279, April 2002. RFC 3279, April 2002.
[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing [6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless [7] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
Address Autoconfiguration in IPv6", RFC 3041, January 2001. for Stateless Address Autoconfiguration in IPv6", RFC 4941,
September 2007.
[8] Bagnulo, M. and J. Arkko, "Cryptographically Generated [8] Bagnulo, M. and J. Arkko, "Cryptographically Generated
Addresses (CGA) Extension Field Format", RFC 4581, Addresses (CGA) Extension Field Format", RFC 4581,
October 2006. October 2006.
[9] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim [9] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim
Protocol for IPv6", draft-ietf-shim6-proto-08 (work in Protocol for IPv6", draft-ietf-shim6-proto-08 (work in
progress), April 2007. progress), April 2007.
[10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms [10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms
skipping to change at page 25, line 52 skipping to change at page 27, line 4
[10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms [10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms
in Cryptographically Generated Addresses (CGAs)", RFC 4982, in Cryptographically Generated Addresses (CGAs)", RFC 4982,
July 2007. July 2007.
15.2. Informative References 15.2. Informative References
[11] Nordmark, E., "Threats relating to IPv6 multihoming solutions", [11] Nordmark, E., "Threats relating to IPv6 multihoming solutions",
RFC 4218, October 2005. RFC 4218, October 2005.
[12] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [12] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP version 6 Route Optimization Security Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[13] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying [13] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Cryptographically Generated Addresses to Optimize MIPv6 (CGA- Optimization for Mobile IPv6", RFC 4866, May 2007.
OMIPv6)", draft-haddad-mip6-cga-omipv6-04 (work in progress),
June 2004.
[14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes [14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005. in Internet Protocols", RFC 4270, November 2005.
[15] Bellovin, S. and E. Rescorla, "Deploying a new hash algorithm", [15] Bellovin, S. and E. Rescorla, "Deploying a new hash algorithm",
2005 September. 2005 September.
[16] Nordmark, E., "Multi6 Application Referral Issues", [16] Nordmark, E., "Multi6 Application Referral Issues",
draft-nordmark-multi6dt-refer-00 (work in progress), draft-nordmark-multi6dt-refer-00 (work in progress),
October 2004. October 2004.
[17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient [17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient
Security for IPv6 Multihoming.", ACM Computer Communications Security for IPv6 Multihoming.", ACM Computer Communications
Review Vol 35 n 2, April 2005. Review Vol 35 n 2, April 2005.
[18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. 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 Author's Address
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6249500 Phone: 34 91 6249500
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
 End of changes. 80 change blocks. 
187 lines changed or deleted 246 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/