[要約] RFC 5535は、ハッシュベースのアドレス（HBA）に関する標準化された仕様です。その目的は、ハッシュ関数を使用してアドレスを生成し、ネットワークのセキュリティとプライバシーを向上させることです。
Network Working Group M. Bagnulo
Request for Comments: 5535 UC3M
Category: Standards Track June 2009
Hash-Based Addresses (HBA)
ハッシュベースのアドレス（HBA）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other.
このメモは、マルチホームサイト内のホストが利用できるさまざまな接頭辞を使用して、複数のアドレス間に安全なバインディングを提供するメカニズムを説明しています。このメカニズムは、暗号化されたアドレス（CGA）またはアドレスで同じ形式を使用する同じテーマの新しいバリアントのいずれかを採用しています。新しいバリアントの主なアイデアは、複数のプレフィックスに関する情報がアドレス自体に含まれていることです。これは、使用可能なプレフィックスのハッシュとしてホストのアドレスのインターフェイス識別子を生成することによって達成されます。次に、複数のアドレスが生成されたインターフェイス識別子に異なるプレフィックスを準備することにより生成されます。結果は、Hashベースのアドレス（HBA）と呼ばれるアドレスのセットで、本質的に互いにバインドされています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................4
3.1. Threat Model ...............................................4
3.2. Overview ...................................................4
3.3. Motivations for the HBA Design .............................5
4. Cryptographic Generated Addresses (CGAs) Compatibility
Considerations ..................................................6
5. Multi-Prefix Extension for CGA ..................................8
6. HBA-Set Generation ..............................................9
7. HBA Verification ...............................................11
7.1. Verification That a Particular HBA Address
Corresponds to a Given CGA Parameter Data Structure .......11
7.2. Verification That a Particular HBA Address Belongs to the
HBA Set Associated with a Given CGA Parameter Data
Structure .................................................11
8. Example of HBA Application in a Multihoming Scenario ...........13
8.1. Dynamic Address Set Support ...............................16
9. DNS Considerations .............................................17
10. IANA Considerations ...........................................18
11. Security Considerations .......................................18
11.1. Security Considerations When Using HBAs in the
Shim6 Protocol ...........................................20
11.2. Privacy Considerations ...................................22
11.3. SHA-1 Dependency Considerations ..........................22
11.4. DoS Attack Considerations ................................22
12. Contributors ..................................................23
13. Acknowledgments ...............................................23
14. References ....................................................24
14.1. Normative References .....................................24
14.2. Informative References ...................................24
In order to preserve inter-domain routing system scalability, IPv6 sites obtain addresses from their Internet Service Providers (ISPs). Such an addressing strategy significantly reduces the amount of routes in the global routing tables, since each ISP only announces routes to its own address blocks, rather than announcing one route per customer site. However, this addressing scheme implies that multihomed sites will obtain multiple prefixes, one per ISP. Moreover, since each ISP only announces its own address block, a multihomed site will be reachable through a given ISP if the ISP prefix is contained in the destination address of the packets. This means that, if an established communication needs to be routed through different ISPs during its lifetime, addresses with different prefixes will have to be used. Changing the address used to carry packets of an established communication exposes the communication to numerous attacks, as described in [11], so security mechanisms are required to provide the required protection to the involved parties. This memo describes a tool that can be used to provide protection against some of the potential attacks, in particular against future/ premeditated attacks (aka time shifting attacks in [12]).
ドメイン間ルーティングシステムのスケーラビリティを保持するために、IPv6サイトはインターネットサービスプロバイダー（ISP）からアドレスを取得します。このようなアドレス指定戦略は、各ISPが顧客サイトごとに1つのルートを発表するのではなく、独自のアドレスブロックへのルートのみを発表するため、グローバルルーティングテーブルのルートの量を大幅に削減します。ただし、このアドレス指定スキームは、マルチホームのサイトがISPごとに1つのプレフィックスを取得することを意味します。さらに、各ISPは独自のアドレスブロックのみを発表するため、ISPのプレフィックスがパケットの宛先アドレスに含まれている場合、特定のISPを介してマルチホームサイトに到達可能になります。これは、確立された通信を寿命の間に異なるISPを通じてルーティングする必要がある場合、異なるプレフィックスを持つアドレスを使用する必要があることを意味します。確立された通信のパケットを運ぶために使用される住所を変更すると、[11]で説明されているように、コミュニケーションが多数の攻撃にさらされるため、関係者に必要な保護を提供するためにセキュリティメカニズムが必要です。このメモでは、潜在的な攻撃のいくつか、特に将来/計画的攻撃に対する保護を提供するために使用できるツールを説明しています（[12]での攻撃の時間を変える）。
This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site.
このメモは、マルチホームサイト内のホストが利用できるさまざまな接頭辞を使用して、複数のアドレス間に安全なバインディングを提供するメカニズムを説明しています。
It should be noted that, as opposed to the mobility case where the addresses that will be used by the mobile node are not known a priori, the multiple addresses available to a host within the multihomed site are pre-defined and known in advance in most of the cases. The mechanism proposed in this memo employs either Cryptographically Generated Addresses (CGAs) [2] or a new variant of the same theme that uses the same format in the addresses. The new variant, Hash-Based Address (HBA), takes advantage of the address set stability. In either case, a secure binding between the addresses of a node in a multihomed site can be provided. CGAs employ public key cryptography and can deal with changing address sets. HBAs employ only symmetric key cryptography, and have smaller computational requirements.
モバイルノードで使用されるアドレスが先験的に不明なモビリティケースとは対照的に、マルチホームサイト内のホストが利用できる複数のアドレスは、ほとんどの場合、ほとんどの場合に事前に定義されており、ケースの。このメモで提案されているメカニズムは、暗号化されたアドレス（CGA）[2]またはアドレスで同じ形式を使用する同じテーマの新しいバリアントのいずれかを採用しています。新しいバリアントであるハッシュベースのアドレス（HBA）は、アドレスセットの安定性を活用しています。どちらの場合でも、マルチホームサイトのノードのアドレス間の安全なバインディングを提供できます。CGAは公開キーの暗号を採用しており、アドレスセットの変更に対処できます。HBAは対称的なキー暗号のみを採用しており、計算要件が小さくなります。
For the purposes of the Shim6 protocol, the other characteristics of the CGAs and HBAs are similar. Both can be generated by the host itself without any reliance on external infrastructure. Both employ the same format of addresses and same format of data fed to generate the addresses. It is not required that all interface identifiers of a node's addresses be equal, preserving some degree of privacy through changes in the addresses used during the communications.
SHIM6プロトコルの目的のために、CGAとHBAの他の特性は類似しています。どちらも、外部インフラストラクチャに依存せずにホスト自体によって生成できます。どちらも同じ形式のアドレスと同じ形式のデータを使用して、アドレスを生成します。ノードのアドレスのすべてのインターフェイス識別子が等しく、通信中に使用されるアドレスの変更を通じてある程度のプライバシーを維持することは必須ではありません。
The main idea in HBAs is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are obtained by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses that are inherently bound. A cost-efficient mechanism is available to determine if two addresses belong to the same set, since given the prefix set and the additional parameters used to generate the HBA, a single hash operation is enough to verify if an HBA belongs to a given HBA set.
HBASの主なアイデアは、複数のプレフィックスに関する情報がアドレス自体に含まれていることです。これは、使用可能なプレフィックスのハッシュとしてホストのアドレスのインターフェイス識別子を生成することによって達成されます。次に、複数のアドレスが、生成されたインターフェイス識別子に異なるプレフィックスを準備することにより取得されます。結果は、本質的にバインドされたアドレスのセットです。プレフィックスセットとHBAを生成するために使用される追加のパラメーターが与えられているため、2つのアドレスが同じセットに属するかどうかを判断するために、費用効率の高いメカニズムが利用可能です。HBAが特定のHBAセットに属しているかどうかを確認するのに十分です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
The threat analysis for the multihoming problem is described in [11]. This analysis basically identifies attacks based on redirection of packets by a malicious attacker towards addresses that do not belong to the multihomed node. There are essentially two types of redirection attacks: communication hijacking and flooding attacks. Communication hijacking attacks are about an attacker stealing on-going and/or future communications from a victim. Flooding attacks are about redirecting the traffic generated by a legitimate source towards a third party, flooding it. The HBA solution provides full protection against the communication hijacking attacks. The Shim6 protocol [9] protects against flooding attacks. Residual threats are described in the "Security Considerations" section.
マルチホーム問題の脅威分析は[11]で説明されています。この分析は、基本的に、マルチホームノードに属さないアドレスに対する悪意のある攻撃者によるパケットのリダイレクトに基づいて攻撃を識別します。基本的に2種類のリダイレクト攻撃があります。通信ハイジャックと洪水攻撃です。コミュニケーションのハイジャック攻撃は、攻撃者が被害者から進行中および/または将来のコミュニケーションを盗むことです。洪水攻撃とは、正当な情報源によって生成されたトラフィックを第三者に向けてリダイレクトすることであり、それを洪水にします。HBAソリューションは、通信ハイジャック攻撃に対する完全な保護を提供します。SHIM6プロトコル[9]は、洪水攻撃から保護します。残留脅威については、「セキュリティ上の考慮事項」セクションに記載されています。
The basic goal of the HBA mechanism is to securely bind together multiple IPv6 addresses that belong to the same multihomed host. This allows rerouting of traffic without worrying that the communication is being redirected to an attacker. The technique that is used is to include a hash of the permitted prefixes in the low-order bits of the IPv6 address.
HBAメカニズムの基本的な目標は、同じマルチホームホストに属する複数のIPv6アドレスを安全に結合することです。これにより、コミュニケーションが攻撃者にリダイレクトされていることを心配することなく、トラフィックを再ルーティングできます。使用される手法は、IPv6アドレスの低次ビットに許可されたプレフィックスのハッシュを含めることです。
So, eliding some details, say the available prefixes are A, B, C, and D, the host would generate a prefix list P consisting of (A,B,C,D) and a random number called Modifier M. Then it would generate the new addresses: A || H(M || A || P)
したがって、いくつかの詳細を排除すると、利用可能なプレフィックスがA、B、C、およびDであると言います。ホストは、（a、b、c、d）とモディファイヤーMと呼ばれるランダム数で構成されるプレフィックスリスト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 and the random Modifier M it is possible to determine whether another address is part of the group by computing the hash and checking against the low-order bits.
したがって、グループから1つの有効なアドレスが与えられ、プレフィックスリストPとランダム修飾子Mが与えられた場合、別のアドレスがハッシュを計算して低次ビットに対してチェックすることにより、グループの一部であるかどうかを判断できます。
The design of the HBA technique was driven by the following considerations:
HBA技術の設計は、次の考慮事項によって推進されました。
First of all, the goal of HBA is to provide a secure binding between the IPv6 address used as an identifier by the upper-layer protocols and the alternative locators available in the multihomed node so that redirection attacks are prevented.
まず、HBAの目標は、上層層プロトコルによって識別子として使用されるIPv6アドレスと、マルチホームノードで利用可能な代替ロケーターの間に安全なバインディングを提供することです。
Second, in order to achieve such protection, the selected approach was to include security information in the identifier itself, instead of relying on third trusted parties to secure the binding, such as the ones based on repositories or Public Key Infrastructure. This decision was driven by deployment considerations, i.e., the cost of deploying the trusted third-party infrastructure.
第二に、そのような保護を達成するために、選択されたアプローチは、リポジトリや公開インフラストラクチャに基づくものなど、拘束力を保護するために第三の信頼できる当事者に頼るのではなく、識別子自体にセキュリティ情報を含めることでした。この決定は、展開の考慮事項、つまり信頼できるサードパーティインフラストラクチャを展開するコストによって推進されました。
Third, application support considerations described in [16] resulted in selecting routable IPv6 addresses to be used as identifiers. Hence, security information is stuffed within the interface identifier part of the IPv6 address.
第三に、[16]で説明されているアプリケーションサポートの考慮事項により、識別子として使用されるルーティング可能なIPv6アドレスを選択しました。したがって、セキュリティ情報は、IPv6アドレスのインターフェイス識別子部分に詰め込まれます。
Fourth, performance considerations as described in [17] motivated the usage of a hash-based approach as opposed to a public-key-based approach based on pure Cryptographic Generated Addresses (CGA), in order to avoid imposing the performance of public key operations for every communication in multihomed environments. The HBA approach presented in this document presents a cheaper alternative that is attractive to many common usage cases. Note that the HBA approach and the CGA approaches are not mutually exclusive and that it is possible to generate addresses that are both valid CGA and HBA addresses providing the benefits of both approaches if needed.
第4に、[17]で説明されているパフォーマンスの考慮事項は、公開キー操作のパフォーマンスを妨げないように、純粋な暗号化アドレス（CGA）に基づくパブリックキーベースのアプローチとは対照的に、ハッシュベースのアプローチの使用を動機付けました。多目的環境でのすべての通信。このドキュメントに示されているHBAアプローチは、多くの一般的な使用法にとって魅力的な安価な代替品を提示します。HBAアプローチとCGAアプローチは相互に排他的ではなく、必要に応じて両方のアプローチの利点を提供する有効なCGAとHBAアドレスの両方であるアドレスを生成することが可能であることに注意してください。
As described in the previous section, the HBA technique uses the interface identifier part of the IPv6 address to encode information about the multiple prefixes available to a multihomed host. However, the interface identifier is also used to carry cryptographic information when Cryptographic Generated Addresses (CGAs) [2] are used. Therefore, conflicting usages of the interface identifier bits may result if this is not taken into account during the HBA design. There are at least two valid reasons to provide CGA-HBA compatibility:
前のセクションで説明したように、HBA手法では、IPv6アドレスのインターフェイス識別子部分を使用して、マルチホームのホストが利用できる複数のプレフィックスに関する情報をエンコードします。ただし、界面識別子は、暗号化されたアドレス（CGA）[2]が使用されるときに暗号化情報を運ぶためにも使用されます。したがって、HBA設計中にこれが考慮されない場合、インターフェイス識別子ビットの矛盾する使用が生じる場合があります。CGA-HBAの互換性を提供するには、少なくとも2つの正当な理由があります。
First, the current Secure Neighbor Discovery (SeND) specification [3] uses the CGAs defined in [2] to prove address ownership. If HBAs are not compatible with CGAs, then nodes using HBAs for multihoming wouldn't be able to do Secure Neighbor Discovery using the same addresses (at least the parts of SeND that require CGAs). This would imply that nodes would have to choose between security (from SeND) and fault tolerance (from IPv6 multihoming support provided by the Shim6 protocol [9]). In addition to SeND, there are other protocols that are considered to benefit from the advantages offered by the CGA scheme, such as mobility support protocols [13]. Those protocols could not be used with HBAs if HBAs are not compatible with CGAs.
まず、現在の安全な近隣発見（送信）仕様[3]は、[2]で定義されているCGAを使用して、住所の所有権を証明します。HBAがCGAと互換性がない場合、MultihomingにHBAを使用してノードは同じアドレスを使用して安全な近隣発見を行うことができません（少なくともCGAを必要とする送信部品）。これは、ノードがセキュリティ（送信から）と障害トレランス（SHIM6プロトコル[9]によって提供されるIPv6マルチホームサポートから）を選択する必要があることを意味します。送信に加えて、モビリティサポートプロトコルなど、CGAスキームが提供する利点から利益を得ると考えられる他のプロトコルがあります[13]。HBAがCGAと互換性がない場合、これらのプロトコルはHBAで使用できませんでした。
Second, CGAs provide additional features that cannot be achieved using only HBAs. In particular, because of its own nature, the HBA technique only supports a predetermined prefix set that is known at the time of the generation of the HBA set. No additions of new prefixes to this original set are supported after the HBA set generation. In most of the cases relevant for site multihoming, this is not a problem because the prefix set available to a multihomed set is not very dynamic. New prefixes may be added in a multihomed site when a new ISP is available, but the timing of those events are rarely in the same time scale as the lifetime of established communications. It is then enough for many situations that the new prefix is not available for established communications and that only new communications benefit from it. However, in the case that such functionality is required, it is possible to use CGAs to provide it. This approach clearly requires that HBA and CGA approaches be compatible. If this is the case, it then would be possible to create HBA/CGA addresses that support CGA and HBA functionality simultaneously. The inputs to the HBA/CGA generation process will be both a prefix set and a public key. In this way, a node that has established a communication using one address of the CGA/HBA set can tell its peer to use the HBA verification when one of the addresses of its HBA/CGA set is used as locator in the communication or to use CGA (public-/private-key-based) verification when a new address that does not belong to the HBA/CGA set is used as locator in the communication.
第二に、CGAはHBAのみを使用して達成できない追加機能を提供します。特に、それ自体の性質のため、HBA技術は、HBAセットの生成時に知られている所定のプレフィックスセットのみをサポートしています。HBAセットの生成後、このオリジナルセットへの新しいプレフィックスの追加はサポートされていません。ほとんどの場合、サイトのマルチホミングに関連する場合、マルチホームセットで使用できるプレフィックスセットはあまり動的ではないため、これは問題ではありません。新しいISPが利用可能な場合、マルチホームサイトに新しいプレフィックスが追加される場合がありますが、これらのイベントのタイミングが確立された通信の寿命と同じ時間尺度ではめったにありません。多くの状況では、新しい接頭辞が確立された通信に利用できず、新しい通信のみがそれから利益を得ることができます。ただし、そのような機能が必要な場合、CGAを使用してそれを提供することができます。このアプローチでは、HBAとCGAのアプローチが互換性があることを明らかに必要とします。この場合、CGAとHBAの機能を同時にサポートするHBA/CGAアドレスを作成することが可能です。HBA/CGA生成プロセスへの入力は、プレフィックスセットと公開キーの両方になります。このように、CGA/HBAセットの1つのアドレスを使用して通信を確立したノードは、HBA/CGAセットのアドレスの1つが通信または使用のロケーターとして使用される場合、HBA検証を使用するようにピアに指示できます。CGA（Public/Private-Keyベース）検証HBA/CGAセットに属さない新しいアドレスが通信のロケーターとして使用される場合。
So, because of the aforementioned reasons, it is a goal of the HBA design to define HBAs in such a way that they are compatible with CGAs as defined in [2] and their usages described in [3] (consequently, to understand the rest of this note, the reader should be familiar with the CGA specification defined in [2]). This means that it must be possible to generate addresses that are both an HBA and a CGA, i.e., that the interface identifier contains cryptographic information of CGA and the prefix-set information of an HBA. The CGA specification already considers the possibility of including additional information into the CGA generation process through the usage of Extension Fields in the CGA Parameter Data Structure. It is then possible to define a Multi-Prefix extension for CGA so that the prefix set information is included in the interface identifier generation process.
したがって、前述の理由により、HBAの設計の目標は、[2]で定義されているCGAと[3]で説明されている使用法（結果として、残りを理解するために、CGAと互換性があるようにHBAを定義することが目標です。このメモのうち、読者は[2]で定義されているCGA仕様に精通している必要があります。これは、HBAとCGAの両方のアドレスを生成することが可能であることを意味します。つまり、インターフェイス識別子にはCGAの暗号化情報とHBAのプレフィックスセット情報が含まれていることを意味します。CGA仕様は、CGAパラメーターデータ構造の拡張フィールドの使用を通じて、CGA生成プロセスに追加情報を含める可能性をすでに考慮しています。その後、CGAのマルチプレフィックス拡張機能を定義して、プレフィックスセット情報がインターフェイス識別子生成プロセスに含まれるようにすることができます。
Even though a CGA compatible approach is adopted, it should be noted that HBAs and CGAs are different concepts. In particular, the CGA is inherently bound to a public key, while an HBA is inherently bound to a prefix set. This means that a public key is not required to generate an HBA-only address. Because of that, we define three different types of addresses:
CGA互換のアプローチが採用されていても、HBAとCGAは異なる概念であることに注意する必要があります。特に、CGAは本質的に公開キーに結合され、HBAは本質的にプレフィックスセットにバインドされます。これは、HBAのみのアドレスを生成するために公開キーが必要ないことを意味します。そのため、3つの異なるタイプのアドレスを定義します。
- CGA-only addresses: These are addresses generated as specified in [2] without including the Multi-Prefix extension. They are bound to a public key and to a single prefix (contained in the basic CGA Parameter Data Structure). These addresses can be used for SeND [3]; if used for multihoming, their application will have to be based on the public key usage.
- CGAのみのアドレス：これらは、[2]でMulti-Prefix拡張機能を含めることなく[2]で指定されているように生成されたアドレスです。それらは、公開キーと単一のプレフィックス（基本的なCGAパラメーターデータ構造に含まれる）にバインドされています。これらのアドレスは、送信に使用できます[3]。マルチホミングに使用する場合、それらのアプリケーションは公開キーの使用に基づいている必要があります。
- CGA/HBA addresses: These addresses are CGAs that include the Multi-Prefix extension in the CGA Parameter Data Structure used for their generation. These addresses are bound to a public key and a prefix set and they provide both CGA and HBA functionalities. They can be used for SeND as defined in [3] and for any usage defined for HBA (such as a Shim6 protocol).
- CGA/HBAアドレス：これらのアドレスは、生成に使用されるCGAパラメーターデータ構造のマルチプレフィックス拡張機能を含むCGAです。これらのアドレスは、公開キーとプレフィックスセットにバインドされており、CGAとHBAの両方の機能を提供します。[3]で定義されているように送信し、HBA（SHIM6プロトコルなど）で定義されている使用法に使用できます。
- HBA-only addresses: These addresses are bound to a prefix set but they are not bound to a public key. Because HBAs are compatible with CGA, the CGA Parameter Data Structure will be used for their generation, but a random nonce will be included in the Public Key field instead of a public key. These addresses can be used for HBA-based multihoming protocols, but they cannot be used for SeND.
- HBAのみのアドレス：これらのアドレスはプレフィックスセットにバインドされていますが、公開キーにバインドされていません。HBAはCGAと互換性があるため、CGAパラメーターデータ構造はその世代に使用されますが、ランダムなノンセは公開キーではなく公開キーフィールドに含まれます。これらのアドレスは、HBAベースのマルチホームプロトコルに使用できますが、送信には使用できません。
The Multi-Prefix extension has the following TLV format as defined in [8]:
Multi-Prefix拡張機能には、[8]で定義されている次のTLV形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type | Extension Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[n] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext Type: 16-bit type identifier of the Multi-Prefix extension (see the "IANA Considerations" section).
extタイプ：マルチプレフィックス拡張機能の16ビットタイプ識別子（「IANA考慮事項」セクションを参照）。
Ext Len: 16-bit unsigned integer. Length of the Extension in octets, not including the first 4 octets.
ext len：16ビットの符号なし整数。最初の4オクテットを含まないオクテットの延長の長さ。
P flag: Set if a public key is included in the Public Key field of the CGA Parameter Data Structure, reset otherwise.
Pフラグ：CGAパラメーターデータ構造の公開キーフィールドに公開キーが含まれている場合は、それ以外の場合はリセットされます。
Reserved: 31-bit reserved field. MUST be initialized to zero, and ignored upon receipt.
予約済み：31ビット予約フィールド。ゼロに初期化し、受領時に無視する必要があります。
Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n.
プレフィックス[1 ... n]：64ビットプレフィックスのベクトル、1からnの番号。
The HBA generation process is based on the CGA generation process defined in Section 4 of [2]. The goal is to require the minimum amount of changes to the CGA generation process. It should be noted that the following procedure is only valid for Sec values of 0, 1, and 2. For other Sec values, RFC 4982 [10] has defined a CGA SEC registry that will contain the specifications used to generate CGAs. The generation procedures defined in such specifications must be used for Sec values other than 0, 1, or 2.
HBA生成プロセスは、[2]のセクション4で定義されているCGA生成プロセスに基づいています。目標は、CGA生成プロセスに最小限の変更量を要求することです。次の手順は、0、1、および2のSEC値に対してのみ有効であることに注意する必要があります。他のSEC値については、RFC 4982 [10]がCGAを生成するために使用される仕様を含むCGA SECレジストリを定義しています。このような仕様で定義されている生成手順は、0、1、または2以外のSEC値に使用する必要があります。
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.
CGA生成プロセスには、64ビットサブネットプレフィックス、公開キー（derにエンコードされたasn.1 subjectpublickeyinfoの構造）、およびセキュリティパラメーター秒の3つの入力があります。
The main difference between the CGA generation and the HBA generation is that while a CGA can be generated independently, all the HBAs of a given HBA set have to be generated using the same parameters, which implies that the generation of the addresses of an HBA set will occur in a coordinated fashion. In this memo, we will describe a mechanism to generate all the addresses of a given HBA set. The generation process of each one of the HBA address of an HBA set will be heavily based in the CGA generation process defined in [2]. More precisely, the HBA set generation process will be defined as a sequence of lightly modified CGA generations.
CGA生成とHBA生成の主な違いは、CGAを独立して生成できる一方で、特定のHBAセットのすべてのHBAを同じパラメーターを使用して生成する必要があることです。これは、HBAセットのアドレスの生成を意味することです調整された方法で発生します。このメモでは、特定のHBAセットのすべてのアドレスを生成するメカニズムについて説明します。HBAセットのHBAアドレスのそれぞれの生成プロセスは、[2]で定義されているCGA生成プロセスに大きく基づいています。より正確には、HBAセット生成プロセスは、軽く変更されたCGA世代のシーケンスとして定義されます。
The changes required in the CGA generation process when generating a single HBA are the following: First, the Multi-Prefix extension has to be included in the CGA Parameter Data Structure. Second, in the case that the address being generated is an HBA-only address, a random nonce will have to be used as input instead of a valid public key. For backwards compatibility issues with pure CGAs, the random nonce MUST be encoded as a public key as defined in [2]. In particular, the random nonce MUST be formatted as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, defined in the Internet X.509 certificate profile [5]. The algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the random nonce MUST be formatted by using the RSAPublicKey type as specified in Section 2.3.1 of RFC 3279 [4]. The random nonce length is 384 bits.
単一のHBAを生成するときにCGA生成プロセスに必要な変更は次のとおりです。まず、Multi-Prefix拡張機能をCGAパラメーターデータ構造に含める必要があります。第二に、生成されているアドレスがHBAのみのアドレスである場合、ランダムなノンセを有効な公開キーの代わりに入力として使用する必要があります。純粋なCGAとの逆方向の互換性の問題の場合、ランダムな非CEは[2]で定義されているように公開キーとしてエンコードする必要があります。特に、インターネットX.509証明書プロファイル[5]で定義されている型件名PublicKeyInfoのderエンコードされたasn.1構造としてランダムノンセをフォーマットする必要があります。アルゴリズム識別子は、1.2.840.113549.1.1.1であるrSaeCryptionでなければならず、RFC 3279 [4]のセクション2.3.1で指定されているRSapublickeyタイプを使用して、ランダムなNonCEをフォーマットする必要があります。ランダムなノンセの長さは384ビットです。
The resulting HBA-set generation process is the following:
結果のHBAセット生成プロセスは次のとおりです。
The inputs to the HBA generation process are:
HBA生成プロセスへの入力は次のとおりです。
o A vector of n 64-bit prefixes,
o n 64ビットプレフィックスのベクトル、
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).
o SECパラメーター、およびHBA/CGAアドレスのセットの生成の場合は、公開キーも入力として提供されます（HBAのみのアドレスを生成する場合は必要ありません）。
The output of the HBA generation process are:
HBA生成プロセスの出力は次のとおりです。
o An HBA-set
o HBAセット
o their respective CGA Parameter Data Structures
o それぞれのCGAパラメーターデータ構造
The steps of the HBA-set generation process are:
HBAセット生成プロセスの手順は次のとおりです。
1. Multi-Prefix extension generation. Generate the Multi-Prefix extension with the format defined in Section 5. Include the vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext Len field value is (n*8 + 4). If a public key is provided, then the P flag is set to one. Otherwise, the P flag is set to zero.
1. マルチプレフィックス拡張生成。セクション5で定義された形式でMulti-Prefix拡張機能を生成します。プレフィックス[1 ... n]フィールドにn 64ビットプレフィックスのベクトルを含めます。ext lenフィールド値は（n*8 4）です。公開キーが提供されている場合、Pフラグは1に設定されます。それ以外の場合、Pフラグはゼロに設定されています。
2. Modifier generation. Generate a Modifier as a random or pseudorandom 128-bit value. If a public key has not been provided as an input, generate the Extended Modifier as a 384-bit random or pseudorandom value. Encode the Extended Modifier value as an RSA key in a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [5].
2. 修飾子生成。ランダムまたは擬似ランダム128ビット値として修飾子を生成します。公開キーが入力として提供されていない場合は、拡張修飾子を384ビットのランダムまたは擬似ランダム値として生成します。インターネットX.509証明書プロファイル[5]で定義されている型subjectPublicKeyInfoのderエンコードされたasn.1構造のRSAキーとして拡張修飾子値をエンコードします。
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.
3. 修飾子、9ゼロオクテット、エンコードされた公開キーまたはエンコードされた拡張修飾子（公開キーが提供されていない場合）、およびマルチプレフィックス拡張機能を連結します。連結時にSHA-1アルゴリズムを実行します。SHA-1ハッシュ値の112の左端ビットを取ります。結果は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).
4. Hash2の16秒の左端ビットをゼロと比較します。それらがすべてゼロの場合（またはSEC = 0の場合）、ステップ（5）を続行します。それ以外の場合は、修飾子を1つずつ増やして、ステップ（3）に戻ります。
5. Set the 8-bit collision count to zero.
5. 8ビットの衝突カウントをゼロに設定します。
6. For i=1 to n (number of prefixes) do:
6. i = 1からn（接頭辞の数）は次のとおりです。
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].
6.1. 左から右に連結して、最終的な修飾子値、プレフィックス[i]、衝突カウント、エンコードされた公開キーまたはエンコードされた拡張修飾子（公開キーが提供されていない場合）、およびマルチプレフィックス拡張機能を連結します。連結時にSHA-1アルゴリズムを実行します。SHA-1ハッシュ値の64の左端ビットを取ります。結果はHash1 [i]です。
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.2. SECの値を3つの左端ビットに書き込み、ビット6と7（つまり、「u」と「g」ビット）を両方ともゼロに設定することにより、Hash1 [i]からインターフェイス識別子を形成します。
6.3. Generate address HBA[i] by concatenating Prefix[i] and the 64-bit interface identifier to form a 128-bit IPv6 address with the subnet prefix to the left and interface identifier to the right as in a standard IPv6 address [6].
6.3. 標準のIPv6アドレス[6]のように、左側にサブネットプレフィックスと右側のインターフェイス識別子を備えた128ビットIPv6アドレスを形成して、プレフィックス[i]と64ビットインターフェイス識別子を連結してアドレスHBA [i]を生成します。
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.4. 必要に応じて、重複するアドレス検出を実行します。アドレス衝突が検出された場合、衝突カウントを1つずつ増加させてステップに戻ります（6）。ただし、3回の衝突の後、エラーを停止して報告します。
6.5. Form the CGA Parameter Data Structure that corresponds to HBA[i] by concatenating from left to right the final Modifier value, Prefix[i], the final collision count value, the encoded public key or the encoded Extended Modifier, and the Multi-Prefix extension.
6.5. 最終的な修飾子値、プレフィックス[i]、最終衝突カウント値、エンコードされた公開キーまたはエンコードされた拡張修飾子、およびマルチプレフィックスを左から右に連結することにより、HBA [i]に対応するCGAパラメーターデータ構造を形成します拡大。
Note: most of the steps of the process are taken from [2].
注：プロセスのほとんどの手順は[2]から取得されます。
The following procedure is only valid for Sec values of 0, 1, and 2. For other Sec values, RFC 4982 [10] has defined a CGA SEC registry that will contain the specifications used to verify CGAs. The verification procedures defined in such specifications must be used for Sec values other than 0,1, or 2.
次の手順は、0、1、および2のSEC値に対してのみ有効です。他のSEC値について、RFC 4982 [10]は、CGAの検証に使用される仕様を含むCGA SECレジストリを定義しています。このような仕様で定義されている検証手順は、0,1以外のSEC値に使用する必要があります。
HBAs are constructed as a CGA Extension, so a properly formatted HBA and its correspondent CGA Parameter Data Structure will successfully finish the verification process described in Section 5 of [2]. Such verification is useful when the goal is the verification of the binding between the public key and the HBA.
HBAはCGA拡張機能として構築されるため、適切にフォーマットされたHBAとその特派員CGAパラメーターデータ構造は、[2]のセクション5で説明されている検証プロセスを正常に完了します。このような検証は、目標が公開鍵とHBA間のバインディングの検証である場合に役立ちます。
For multihoming applications, it is also relevant that the receiver of the HBA information verifies if a given HBA address belongs to a certain HBA set. An HBA set is identified by a CGA Parameter Data structure that contains a Multi-Prefix extension. So, the receiver needs to verify if a given HBA belongs to the HBA set defined by a CGA Parameter Data Structure. It should be noted that the receiver may need to verify if an HBA belongs to the HBA set defined by the CGA Parameter Data Structure of another HBA of the set. If this is the case, HBAs will fail to pass the CGA verification process defined in [2], because the prefix included in the Subnet Prefix field of the CGA Parameter Data Structure will not match the prefix of the HBA that is being verified. To verify if an HBA belongs to an HBA set associated with another HBA, verify that the HBA prefix is included in the prefix set defined in the Multi-Prefix extension, and if this is the case, then substitute the prefix included in the Subnet Prefix field by the prefix of the HBA, and then perform the CGA verification process defined in [2].
マルチホームアプリケーションの場合、特定のHBAアドレスが特定のHBAセットに属している場合、HBA情報の受信者が検証されることも関連しています。HBAセットは、マルチプレフィックス拡張機能を含むCGAパラメーターデータ構造によって識別されます。したがって、受信者は、特定のHBAがCGAパラメーターデータ構造によって定義されたHBAセットに属しているかどうかを確認する必要があります。HBAがセットの別のHBAのCGAパラメーターデータ構造によって定義されたHBAセットに属しているかどうかを受信者が確認する必要があることに注意する必要があります。この場合、HBAは[2]で定義されているCGA検証プロセスに合格しません。これは、CGAパラメーターデータ構造のサブネットプレフィックスフィールドに含まれるプレフィックスが検証されているHBAのプレフィックスと一致しないためです。HBAが別のHBAに関連付けられたHBAセットに属しているかどうかを確認するには、HBAプレフィックスがMulti-Prefix拡張機能で定義されているプレフィックスセットに含まれていることを確認します。HBAのプレフィックスでフィールドを使用し、[2]で定義されているCGA検証プロセスを実行します。
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:
したがって、HBAがCGAパラメーターデータ構造によって決定されるHBAセットに属していることを確認するプロセスは、HBA検証と呼ばれ、次のとおりです。
The inputs to the HBA verification process are:
HBA検証プロセスへの入力は次のとおりです。
o An HBA
o HBA
o A CGA Parameter Data Structure
o CGAパラメーターデータ構造
The steps of the HBA verification process are the following:
HBA検証プロセスの手順は次のとおりです。
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.
1. 64ビットHBAプレフィックスがMulti-Prefix拡張機能のプレフィックスセットに含まれていることを確認します。含まれていない場合、検証は失敗します。含まれている場合は、64ビットHBAプレフィックスでCGAパラメーターデータ構造のサブネットプレフィックスフィールドに含まれるプレフィックスを交換します。
2. Run the verification process described in Section 5 of [2] with the HBA and the new CGA Parameters Data Structure (including the Multi-Prefix extension) as inputs. The steps of the process are included below, extracted from [2]:
2. [2]のセクション5で説明されている検証プロセスを、HBAおよび新しいCGAパラメーターデータ構造（マルチプリフィックス拡張機能を含む）を入力として実行します。プロセスの手順は、[2]から抽出された以下に含まれています。
2.1. Check that the collision count in the CGA Parameter Data Structure is 0, 1, or 2. The CGA verification fails if the collision count is out of the valid range.
2.1. CGAパラメーターデータ構造の衝突カウントが0、1、または2であることを確認します。CGA検証は、衝突カウントが有効な範囲外である場合、失敗します。
2.2. Check that the subnet prefix in the CGA Parameter Data Structure is equal to the subnet prefix (i.e., the leftmost 64 bits) of the address. The CGA verification fails if the prefix values differ. Note: This step always succeeds because of the action taken in step 1.
2.2. CGAパラメーターデータ構造のサブネットプレフィックスが、アドレスのサブネットプレフィックス（つまり、左端64ビット）に等しいことを確認してください。接頭辞の値が異なる場合、CGA検証は失敗します。注：このステップは、ステップ1で行われたアクションのために常に成功します。
2.3. Execute the SHA-1 algorithm on the CGA Parameter Data Structure. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1.
2.3. CGAパラメーターデータ構造でSHA-1アルゴリズムを実行します。SHA-1ハッシュ値の64の左端ビットを取ります。結果は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.4. Hash1を、アドレスのインターフェイス識別子（つまり、右端の64ビット）と比較します。3つの左端のビットとビット6と7（つまり、「u」と「g」ビット）の違いは無視されます。64ビットの値が異なる場合（5つの無視されたビット以外）、CGA検証は失敗します。
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.5. アドレスの64ビットインターフェイス識別子の3つの左端のビットからセキュリティパラメーターSECをお読みください。（SECは署名されていない3ビット整数です。）
2.6. Concatenate from left to right the Modifier, 9 zero octets, the public key, and any extension fields (in this case, the Multi-Prefix extension will be included, at least) that follow the public key in the CGA Parameter Data Structure. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2.
2.6. CGAパラメーターデータ構造の公開キーに従うモディファイア、9ゼロオクテット、公開キー、および任意の拡張フィールド（この場合、マルチプレフィックス拡張機能が含まれます）を連結します。連結時にSHA-1アルゴリズムを実行します。SHA-1ハッシュ値の112の左端ビットを取ります。結果はhash2です。
2.7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one of them is non-zero, the CGA verification fails. Otherwise, the verification succeeds. (If Sec=0, the CGA verification never fails at this step.)
2.7. Hash2の16秒の左端ビットをゼロと比較します。それらのいずれかがゼロではない場合、CGA検証は失敗します。そうでなければ、検証は成功します。（SEC = 0の場合、このステップでCGAの検証が失敗することはありません。）
In this section, we will describe a possible application of the HBA technique to IPv6 multihoming.
このセクションでは、HBA技術のIPv6マルチホームへの適用の可能性について説明します。
We will consider the following scenario: a multihomed site obtains Internet connectivity through two providers: ISPA and ISPB. Each provider has delegated a prefix to the multihomed site (PrefA::/nA and PrefB::/nb, respectively). In order to benefit from multihoming, the hosts within the multihomed site will configure multiple IP addresses, one per available prefix. The resulting configuration is depicted in the next figure.
次のシナリオを検討します。マルチホームサイトは、ISPAとISPBの2つのプロバイダーを通じてインターネット接続を取得します。各プロバイダーは、マルチホームサイト（それぞれfrefa ::/naおよびprefb ::/nb）にプレフィックスを委任しました。マルチホームの恩恵を受けるために、マルチホームサイト内のホストは、利用可能なプレフィックスごとに複数のIPアドレスを構成します。結果の構成は、次の図に示されています。
+-------+
| Host2 |
|IPHost2|
+-------+
|
|
(Internet)
/ \
/ \
+------+ +------+
| ISPA | | ISPB |
| | | |
+------+ +------+
| |
\ /
\ /
+---------------------+
| multihomed site |
| PA::/nA |
| PB::/nB +------+ |
| |Host1 | |
| +------+ |
+---------------------+
We assume that both Host1 and Host2 support the Shim6 protocol.
HOST1とHOST2の両方がSHIM6プロトコルをサポートしていると仮定します。
Host2 is not located in a multihomed site, so there is no need for it to create HBAs (it must be able to verify them though, in order to support the Shim6 protocol, as we will describe next).
host2はマルチホームのサイトにないため、HBAを作成する必要はありません（ただし、SHIM6プロトコルをサポートするために、次に説明するように、それらを検証できる必要があります）。
Host1 is located in the multihomed site, so it will generate its addresses as HBAs. In order to do that, it needs to execute the HBA-set generation process as detailed in Section 6 of this memo. The inputs of the HBA-set generation process will be: a prefix vector containing the two prefixes available in its link, i.e., PA:LA::/64 and PB:LB::/64, a Sec parameter value, and optionally a public key. In this case, we will assume that a public key is provided so that we can also illustrate how a renumbering event can be supported when HBA/CGA addresses are used (see the sub-section referring to dynamic address set support). So, after executing the HBA-set generation process, Host1 will have: an HBA-set consisting in two addresses, i.e., PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data Structures, i.e., CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are different but both contain information about the prefix set available in the multihomed site.
Host1はマルチホームサイトにあるため、HBASとしてアドレスを生成します。そのためには、このメモのセクション6で詳述されているように、HBAセット生成プロセスを実行する必要があります。HBAセット生成プロセスの入力は次のとおりです。リンクで使用可能な2つのプレフィックスを含むプレフィックスベクトル、つまりPA：LA ::/64およびPB：LB ::/64、SECパラメーター値、およびオプションでは公開鍵。この場合、HBA/CGAアドレスが使用されているときに変更されるイベントをサポートする方法を説明できるように、公開キーが提供されると仮定します（動的アドレスセットサポートを参照するサブセクションを参照）。したがって、HBAセット生成プロセスを実行した後、Host1は次のとおりです。つまり、PA：LA：IIDAおよびPB：LB：IIDBは、それぞれのCGAパラメーターデータ構造、つまりCGA_PDS_AおよびCGA_PDS_BBBBを使用して、PA：LA：IIDAおよびPB：IIDBを使用します。。IIDAとIIDBは異なっていますが、どちらもマルチホームサイトで使用可能なプレフィックスセットに関する情報が含まれています。
We will next consider a communication between Host1 and Host2. Assume that both ISPs of the multihomed site are working properly, so any of the available addresses in Host1 can be used for the communication. Suppose then that the communication is established using PA:LA:iidA and IPHost2 for Host1 and Host2, respectively. So far, no special Shim6 support has been required, and PA:LA:iidA is used as any other global IP address.
次に、Host1とHost2の間の通信を検討します。マルチホームサイトの両方のISPが適切に機能しているため、HOST1で利用可能なアドレスのいずれかを通信に使用できると仮定します。それから、通信がPa：la：iidaおよびiphost2をそれぞれHost1とHost2のIPHOST2を使用して確立すると仮定します。これまでのところ、特別なSHIM6サポートは必要ありません。PA：LA：IIDAは、他のグローバルIPアドレスとして使用されています。
Suppose that at a certain moment, one of the hosts involved in the communication decides that multihoming support is required in this communication (this basically means that one of the hosts involved in the communication desires enhanced fault-tolerance capabilities for this communication, so that if an outage occurs, the communication can be re-homed to an alternative provider).
特定の瞬間に、コミュニケーションに関与するホストの1人がこのコミュニケーションでマルチホームサポートが必要であると決定するとします（これは基本的に、コミュニケーションに関与するホストの1つがこの通信のための断層トレランス能力を強化することを意味します。停止が発生し、通信を代替プロバイダーに再ホームすることができます）。
At this moment, the Shim6 protocol Host-Pair Context establishment exchange will be performed between the two hosts (see [9]). In this exchange, Host1 will send CGA_PDS_A to Host2.
現時点では、SHIM6プロトコルホストペアコンテキスト確立交換が2つのホスト間で実行されます（[9]を参照）。この交換では、Host1はCGA_PDS_AをHOST2に送信します。
After the reception of CGA_PDS_A, Host2 will verify that the received CGA Parameter Data Structure corresponds to the address being used in the communication PA:LA:iidA. This means that Host2 will execute the HBA verification process described in Section 7 of this memo with PA: LA:iidA and CGA_PDS_A as inputs. In this case, the verification will succeed since the CGA Parameter Data Structure and the addresses used in the verification match.
CGA_PDS_Aの受信後、HOST2は、受信したCGAパラメーターデータ構造が通信PA：LA：IIDAで使用されているアドレスに対応することを確認します。これは、HOST2がこのメモのセクション7で説明したHBA検証プロセスをPA：LA：IIDAおよびCGA_PDS_Aを入力として実行することを意味します。この場合、CGAパラメーターデータ構造と検証マッチで使用されているアドレスから検証が成功します。
As long as there are no outages affecting the communication path through ISPA, packets will continue flowing. If a failure affects the path through ISPA, Host1 will attempt to re-home the communication to an alternative address, i.e., PB:LB:iidB. In order to accomplish this, after detecting the outage, Host1 will inform Host2 about the alternative address. Host2 will verify that the new address belongs to the HBA set of the initial address. In order to accomplish this, Host2 will execute the HBA verification process with the CGA Parameter Data Structure of the original address (i.e., CGA_PDS_A) and the new address (i.e., PB:LB:iidB) as inputs. The verification process will succeed because PB:LB::/64 has been included in the Multi-Prefix extension during the HBA-set generation process. Additional verifications may be required to prevent flooding attacks (see the comments about flooding attacks prevention in the Security Considerations section of this memo).
ISPAを介した通信パスに影響を与える停止がない限り、パケットは流れ続けます。障害がISPAを介したパスに影響を与える場合、HOST1は通信を代替アドレス、つまりPB：LB：IIDBに再生しようとします。これを達成するために、停止を検出した後、Host1はHost2に代替アドレスについて通知します。Host2は、新しいアドレスが初期アドレスのHBAセットに属していることを確認します。これを達成するために、HOST2は、元のアドレス（つまり、CGA_PDS_A）のCGAパラメーターデータ構造と新しいアドレス（すなわち、PB：LB：IIDB）を入力として実行するHBA検証プロセスを実行します。PB：LB ::/64がHBA-SET生成プロセス中にマルチプレフィックス拡張に含まれているため、検証プロセスが成功します。洪水攻撃を防ぐために追加の検証が必要になる場合があります（このメモのセキュリティに関する考慮事項の洪水攻撃防止に関するコメントを参照してください）。
Once the new address is verified, it can be used as an alternative locator to re-home the communication, while preserving the original address (PA:LA:iidA) as an identifier for the upper layers. This 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.
新しいアドレスが検証されると、通信を再生するための代替ロケーターとして使用でき、元のアドレス（PA：LA：IIDA）を上層層の識別子として保存できます。これは、この新しいアドレスとの間で、次のパケットが対処されることを意味します。新しい有効なアドレスをHOST2に保存できるため、次のパケットには追加のHBA検証は必要ないことに注意してください。
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.
この例では、HOST1アドレスのHBA機能のみが使用されました。言い換えれば、CGAパラメーターデータ構造に含まれる公開鍵も、プロトコルで使用されていません。次のセクションでは、その使用が必要な場合を検討します。
In the previous section, we have presented the mechanisms that allow a host to use different addresses of a predetermined set to exchange packets of a communication. The set of addresses involved was predetermined and known when the communication was initiated. To achieve such functionality, only HBA functionalities of the addresses were needed. In this section, we will explore the case where the goal is to exchange packets using additional addresses that were not known when the communication was established. An example of such a situation is when a new prefix is available in a site after a renumbering event. In this case, the hosts that have the new address available may want to use it in communications that were established before the renumbering event. In this case, HBA functionalities of the addresses are not enough and CGA capabilities are to be used.
前のセクションでは、ホストが通信のパケットを交換するために所定のセットの異なるアドレスを使用できるようにするメカニズムを提示しました。関係するアドレスのセットは事前に決められ、コミュニケーションが開始されたときに知られていました。このような機能を達成するには、アドレスのHBA機能のみが必要でした。このセクションでは、通信が確立されたときに知られていない追加のアドレスを使用してパケットを交換することが目標である場合を調査します。このような状況の例は、変更イベントの後に新しい接頭辞がサイトで利用可能になったときです。この場合、利用可能な新しいアドレスを持っているホストは、変更イベントの前に確立されたコミュニケーションでそれを使用したい場合があります。この場合、アドレスのHBA機能は十分ではなく、CGA機能を使用する必要があります。
Consider then the previous case of the communication between Host1 and Host2. Suppose that the communication is up and running, as described earlier. Host1 is using PA:LA:iidA and Host2 is using IPHost2 to exchange packets. Now suppose that a new address, PC:LC: addC is available in Host1. Note that this address is just a regular IPv6 address, and it is neither an HBA nor a CGA. Host1 wants to use this new address in the existent communication with Host2. It should be noted that the HBA mechanism described in the previous section cannot be used to verify this new address, since this address does not belong to the HBA set (since the prefix was not available at the moment of the generation of the HBA set). This means that alternative verification mechanisms will be needed.
次に、Host1とhost2の間の通信の以前のケースを検討してください。前述のように、通信が稼働していると仮定します。host1はPa：la：iidaとhost2を使用しています。Host2はiphost2を使用してパケットを交換しています。ここで、新しいアドレス、PC：LC：ADDCがHOST1で利用可能であると仮定します。このアドレスは通常のIPv6アドレスであり、HBAでもCGAでもないことに注意してください。host1は、host2との存在する通信でこの新しいアドレスを使用したいと考えています。このアドレスはHBAセットに属していないため、前のセクションで説明したHBAメカニズムをこの新しいアドレスを検証するために使用できないことに注意する必要があります（HBAセットの生成時にプレフィックスは使用できなかったため）。これは、代替検証メカニズムが必要になることを意味します。
In order to verify this new address, CGA capabilities of PA:LA:iidA are used. Note that the same address is used, only that the verification mechanism is different. So, if Host1 wants to use PC: LC:addC to exchange packets in the established communication, it will use the UPDATE message defined in the Shim6 protocol [9], conveying the new address, PC:LC:addC, and this message will be signed using the private key corresponding to the public key contained in CGA_PDS_A. When Host2 receives the message, it will verify the 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.
この新しいアドレスを検証するために、PA：LA：IIDAのCGA機能が使用されます。同じアドレスが使用されていることに注意してください。検証メカニズムが異なることのみであることに注意してください。したがって、HOST1がPC：LC：ADDCを使用して確立された通信を交換する場合、SHIM6プロトコル[9]で定義された更新メッセージを使用し、新しいアドレス、PC：LC：ADDC、およびこのメッセージを伝達します。CGA_PDS_Aに含まれる公開キーに対応する秘密鍵を使用して署名されます。HOST2がメッセージを受信すると、通信の確立に使用されるアドレス、つまりCGA_PDS_AおよびPA：LA：IIDAにそれぞれ使用されるアドレスに関連付けられているCGAパラメーターデータ構造に含まれる公開キーを使用して、署名を検証します。署名が検証されると、新しいアドレス（PC：LC：ADDC）を通信で使用できます。
In any case, a renumbering event has an impact on a site that is using the HBA technique. In particular, the new prefix added will not be included in the existing HBA set, so it is only possible to use the new prefix with the existing HBA set if CGA capabilities are used. While this is acceptable for the short term, in the long run, the site will need to renumber its HBA addresses. In order to do that, it will need to re-generate the HBA sets assigned to hosts including the new prefix in the prefix set, which will result in different addresses, not only because we need to add a new address with the new prefix, but also because the addresses with the existing prefixes will also change because of the inclusion of a new prefix in the prefix set. Moreover, since HBA addresses need to be generated locally, once these are generated after the renumbering event, the new address information needs to be conveyed to the DNS manager in case that such address information is to be published in the DNS (see DNS considerations section for more details).
いずれにせよ、変更イベントは、HBA技術を使用しているサイトに影響を与えます。特に、追加された新しいプレフィックスは既存のHBAセットには含まれていないため、CGA機能が使用されている場合は、既存のHBAセットで新しいプレフィックスを使用することのみが可能です。これは短期的には受け入れられますが、長期的には、サイトはHBAアドレスを変更する必要があります。そのためには、プレフィックスセットの新しいプレフィックスを含むホストに割り当てられたHBAセットを再生成する必要があります。これにより、新しいプレフィックスに新しいアドレスを追加する必要があるためだけでなく、異なるアドレスが生成されます。ただし、プレフィックスセットに新しいプレフィックスが含まれているため、既存のプレフィックスを使用したアドレスも変更されるためです。さらに、HBAアドレスをローカルに生成する必要があるため、変更イベントの後にこれらが生成されると、そのようなアドレス情報がDNSに公開される場合に備えて、新しいアドレス情報をDNSマネージャーに伝える必要があります（DNS考慮事項セクションを参照詳細については）。
HBA sets can be generated using any prefix set. Actually, the only particularity of the HBA is that they contain information about the prefix set in the interface identifier part of the address in the form of a hash, but no assumption about the properties of prefixes used for the HBA generation is made. This basically means that depending on the prefixes used for the HBA set generation, it may or may not be recommended to publish the resulting (HBA) addresses in the DNS. For instance, when Unique Local Address (ULA) prefixes [18] are included in the HBA generation process, specific DNS considerations related to the local nature of the ULA should be taken into account and proper recommendations related to publishing such prefixes in the DNS should followed. Moreover, among its addresses, a given host can have some HBAs and some other IPv6 addresses. The consequence from this is that only HBA addresses will be bound together by the HBA technique, while other addresses would not be bound to the HBA set. This would basically mean that if one of the other addresses is used for initiating a Shim6 communication, it won't be possible to use the HBA technique to bind the address used with the HBA set. Furthermore, since HBA addresses are indistinguishable from other IPv6 addresses in their format, an initiator will not be able to distinguish, by merely looking at the 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.
HBAセットは、任意のプレフィックスセットを使用して生成できます。実際、HBAの唯一の特異性は、ハッシュの形でアドレスのインターフェイス識別子部分に設定されたプレフィックスセットに関する情報が含まれていることですが、HBA生成に使用されるプレフィックスの特性に関する仮定は行われません。これは、基本的に、HBAセットの生成に使用されるプレフィックスによって、DNSで結果の（HBA）アドレスを公開することをお勧めする場合と推奨される場合があります。たとえば、一意のローカルアドレス（ULA）プレフィックス[18]がHBA生成プロセスに含まれる場合、ULAのローカル性に関連する特定のDNS考慮事項を考慮に入れる必要があり、DNSのそのようなプレフィックスの公開に関連する適切な推奨事項を考慮する必要があります。続いて。さらに、そのアドレスの中で、特定のホストにはHBAおよびその他のIPv6アドレスを持つことができます。これからの結果は、HBAアドレスのみがHBA技術によって結合され、他のアドレスはHBAセットにバインドされないことです。これは基本的に、他のアドレスの1つがSHIM6通信の開始に使用された場合、HBA技術を使用してHBAセットで使用されるアドレスを結合することができないことを意味します。さらに、HBAアドレスは形式の他のIPv6アドレスと区別できないため、イニシエーターは、単にHBAセットに属し、どのアドレスに属しているかを見るだけでは、代替手段を見ることができません。必要なイニシエーターは、DNSに非HBAアドレスの存在下で通信を確立するためにHBAのみを使用することになっています。
In addition, it should be noted that the actual HBA values are a result of the HBA generation procedure, meaning that they cannot be arbitrarily chosen. This has an implication with respect to DNS management, because the party that generates the HBA address set needs to convey the address information to the DNS manager, so that the addresses are published and not the other way around. The situation is similar to regular CGA addresses and even to the case where stateless address autoconfiguration is used. In order to do that, it is possible to use Dynamic DNS updates [19] or other proprietary tools. A similar consideration applies when the host wants to publish reverse-DNS entries. Since the host needs to generate its HBA addresses, it will need to convey the address information to the DNS manager so the proper reverse-DNS entry is populated in case it is needed. It should be noted that neither the Shim6 protocol nor the HBA technique rely on the reverse DNS for its proper functioning and the general reasons for requiring reverse-DNS population apply as for any other regular IPv6 address.
さらに、実際のHBA値はHBA生成手順の結果であることに注意する必要があります。つまり、任意に選択することはできません。これは、HBAアドレスセットを生成する当事者がアドレス情報をDNSマネージャーに伝える必要があり、アドレスが公開され、その逆ではないため、DNS管理に関して意味があります。状況は、定期的なCGAアドレス、さらにはステートレスアドレスの自動構成が使用される場合でも似ています。そのためには、動的なDNS更新[19]またはその他の独自のツールを使用することができます。ホストがリバースDNSエントリを公開したい場合、同様の考慮事項が適用されます。ホストはHBAアドレスを生成する必要があるため、アドレス情報をDNSマネージャーに伝える必要があるため、必要な場合に適切な逆DNSエントリが入力されます。SHIM6プロトコルもHBA技術も、適切な機能を逆DNSに依存していないこと、および他の通常のIPv6アドレスに逆DNS集団を要求する一般的な理由が適用されないことに注意する必要があります。
This document defines a new CGA Extension, the Multi-Prefix extension. This extension has been assigned the CGA Extension Type value 0x0012.
このドキュメントでは、新しいCGA拡張機能であるMulti-Prefix拡張機能を定義します。この拡張機能には、CGA拡張タイプの値0x0012が割り当てられています。
The goal of HBAs is to create a group of addresses that are securely bound, so that they can be used interchangeably when communicating with a node. If there is no secure binding between the different addresses of a node, a number of attacks are enabled, as described in [11]. In particular, it would be possible for an attacker to redirect the communications of a victim to an address selected by the attacker, hijacking the communication. When using HBAs, only the addresses belonging to an HBA set can be used interchangeably, limiting the addresses that can be used to redirect the communication to a predetermined set that belongs to the original node involved in the communication. So, when using HBAs, a node that is communicating using address A can redirect the communication to a new address B if and only if B belongs to the same HBA set as A.
HBAの目標は、ノードと通信するときに交換可能に使用できるように、安全にバインドされたアドレスのグループを作成することです。ノードの異なるアドレス間に安全なバインディングがない場合、[11]で説明されているように、多くの攻撃が有効になります。特に、攻撃者が被害者の通信を攻撃者が選択した住所への通信をリダイレクトし、コミュニケーションをハイジャックすることが可能です。HBAを使用する場合、HBAセットに属するアドレスのみを同じ意味で使用でき、通信を使用して通信をリダイレクトして通信に関与する元のノードに属する所定のセットにリダイレクトできます。したがって、HBAを使用する場合、アドレスAを使用して通信しているノードは、BがAと同じHBAセットに属している場合にのみ、新しいアドレスBに通信をリダイレクトできます。
This means that if an attacker wants to redirect communications addressed to address HBA1 to an alternative address IPX, the attacker will need to create a CGA Parameter Data Structure that generates an HBA set that contains both HBA1 and IPX.
つまり、攻撃者がアドレス指定された通信をリダイレクトしてHBA1を代替アドレスIPXにアドレス指定したい場合、攻撃者はHBA1とIPXの両方を含むHBAセットを生成するCGAパラメーターデータ構造を作成する必要があることを意味します。
In order to generate the required HBA set, the attacker needs to find a CGA Parameter Data Structure that fulfills the following conditions:
必要なHBAセットを生成するために、攻撃者は次の条件を満たすCGAパラメーターデータ構造を見つける必要があります。
o the prefix of HBA1 and the prefix of IPX are included in the Multi-Prefix extension.
o HBA1の接頭辞とIPXのプレフィックスは、Multi-Prefix拡張機能に含まれています。
o HBA1 is included in the HBA set generated.
o HBA1は、生成されたHBAセットに含まれています。
Note: this assumes that it is acceptable for the attacker to redirect HBA1 to any address of the prefix of IPX.
注：これは、攻撃者がIPXのプレフィックスのアドレスにHBA1をリダイレクトすることが許容できると仮定します。
The remaining fields that can be changed at will by the attacker in order to meet the above conditions are: the Modifier, other prefixes in the Multi-Prefix extension, and other extensions. In any case, in order to obtain the desired HBA set, the attacker will have to use a brute-force attack, which implies the generation of multiple HBA sets with different parameters (for instance with a different Modifier) until the desired conditions are meet. The expected number of times that the generation process will have to be repeated until the desired HBA set is found is exponentially related with the number of bits containing hash information included in the interface identifier of the HBA. Since 59 of the 64 bits of the interface identifier contain hash bits, then the expected number of generations that will have to be performed by the attacker are O(2^59). Note: We assume brute force is the best attack against HBA/CGAs. Also, note that the assumption that the Sec tool defined in [2] multiplies the attack factor holds for brute-force attacks but may not hold for other attack classes.
上記の条件を満たすために攻撃者によって自由に変更できる残りのフィールドは、修飾子、マルチプリフィックス拡張機能の他のプレフィックス、およびその他の拡張機能です。いずれにせよ、目的のHBAセットを取得するために、攻撃者はブルートフォース攻撃を使用する必要があります。これは、目的の条件が満たされるまで、異なるパラメーター（例えば異なる修飾子を持つ）を持つ複数のHBAセットの生成を意味します。。目的のHBAセットが見つかるまで生成プロセスを繰り返す必要がある予想回数は、HBAの界面識別子に含まれるハッシュ情報を含むBITの数と指数関数的に関連しています。界面識別子の64ビットのうち59がハッシュビットを含むため、攻撃者が実行する必要がある世代の予想数はO（2^59）です。注：Brute ForceはHBA/CGAに対する最良の攻撃であると仮定します。また、[2]で定義されているSECツールが攻撃係数がブルートフォース攻撃に保持されるが、他の攻撃クラスでは保持されない可能性があるという仮定に注意してください。
The protection against brute-force attacks can be improved by increasing the Sec parameter. A non-zero Sec parameter implies that steps 3-4 of the generation process will be repeated O(2^(16*Sec)) times (expected number of times). If we assimilate the cost of repeating the steps 3-4 to the cost of generating the HBA address, we can estimate the number of times that the generation is to be repeated in O(2^(59+16*Sec)), in the case of Sec values of 1 and 2. For other Sec values, Sec protection mechanisms will be defined by the specifications pointed by the CGA SEC registry defined in RFC 4982 [10].
Brute-Force攻撃に対する保護は、SECパラメーターを増やすことで改善できます。ゼロ以外のSECパラメーターは、生成プロセスのステップ3〜4がo（2^（16*秒））繰り返されることを意味します（予想される回数）。ステップ3-4をHBAアドレスの生成コストに繰り返すコストを同化すると、発電がO（2^（59 16*秒））で繰り返される回数を推定できます。1および2のSEC値の場合、他のSEC値の場合、SEC保護メカニズムは、RFC 4982 [10]で定義されているCGA SECレジストリによって指摘された仕様によって定義されます。
In this section, we will analyze the security provided by HBAs in the context of a Shim6 protocol as described in Section 8 of this memo.
このセクションでは、このメモのセクション8で説明されているSHIM6プロトコルのコンテキストで、HBAが提供するセキュリティを分析します。
First of all, it must be noted that HBAs cannot prevent man-in-the-middle (hereafter MITM) attacks. This means that in the scenario described in Section 8, if an attacker is located along the path between Host1 and Host2 during the lifetime of the communication, the attacker will be able to change the addresses used for the communication. This means that he will be able to change the addresses used in the communication, adding or removing prefixes at his will. However, the attacker must make sure that the CGA Parameter Data Structure and the HBA set is changed accordingly. This essentially means that the attacker will have to change the interface identifier part of the addresses involved, since a change in the prefix set will result in different interface identifiers of the addresses of the HBA set, unless the appropriate Modifier value is used (which would require O(2(59+16*Sec)) attempts). So, HBA doesn't provide MITM attacks protection, but a MITM attacker will have to change the address used in the communication in order to change the prefix set valid for the communication.
まず第一に、HBAは中間（以下MITM）攻撃を防ぐことができないことに注意する必要があります。これは、セクション8で説明されているシナリオで、攻撃者がコミュニケーションの寿命の間にHOST1とHOST2の間のパスに沿って配置されている場合、攻撃者は通信に使用されるアドレスを変更できることを意味します。これは、彼がコミュニケーションで使用されるアドレスを変更したり、彼の遺言でプレフィックスを追加または削除することができることを意味します。ただし、攻撃者は、CGAパラメーターデータ構造とHBAセットがそれに応じて変更されることを確認する必要があります。これは本質的に、攻撃者が関係するアドレスのインターフェイス識別子部分を変更する必要があることを意味します。プレフィックスセットの変更は、適切な修飾子値が使用されない限り、HBAセットのアドレスの異なるインターフェイス識別子をもたらすためです（O（2（59 16*秒））試行が必要です）。したがって、HBAはMITM攻撃保護を提供しませんが、MITM攻撃者は、通信に有効なプレフィックスセットを変更するために、通信で使用されるアドレスを変更する必要があります。
HBAs provide protection against time shifting attacks [11], [12]. In the multihoming context, an attacker would perform a time shifted attack in the following way: an attacker placed along the path of the communication will modify the packets to include an additional address as a valid address for the communication. Then the attacker would leave the on-path location, but the effects of the attack would remain (i.e., the address would still be considered as a valid address for that communication). Next we will present how HBAs can be used to prevent such attacks.
HBAは、攻撃の時間シフトに対する保護を提供します[11]、[12]。マルチホームのコンテキストでは、攻撃者は次の方法で時間シフト攻撃を実行します。通信のパスに沿って配置された攻撃者は、パケットを変更して、通信の有効なアドレスとして追加のアドレスを含めるようになります。その後、攻撃者はパス上の場所を離れますが、攻撃の効果は残ります（つまり、住所はまだそのコミュニケーションの有効なアドレスと見なされます）。次に、HBAを使用してそのような攻撃を防ぐ方法を説明します。
If the attacker is not on-path when the initial CGA Parameter Data Structure is exchanged, his only possibility to launch a redirection attack is to fake the signature of the message for adding new addresses using CGA capabilities of the addresses. This implies discovering the public key used in the CGA Parameter Data Structure and then cracking the key pair, which doesn't seem feasible. So in order to launch a redirection attack, the attacker needs to be on-path when the CGA Parameter Data Structure is exchanged, so he can modify it. Now, in order to launch the redirection attack, the attacker needs to add his own prefix in the prefix set of the CGA Parameter Data Structure. We have seen in the previous section that there are two possible approaches for this: 1. Find the right Modifier value, so that the address initially used in the communication is contained in the new HBA set. The cost of this attack is O(2(59+16*Sec)) iterations of the generation process, so it is deemed unfeasible.
最初のCGAパラメーターデータ構造が交換されたときに攻撃者がパス上にいない場合、リダイレクト攻撃を開始する彼の唯一の可能性は、アドレスのCGA機能を使用して新しいアドレスを追加するためのメッセージの署名を偽造することです。これは、CGAパラメーターデータ構造で使用されている公開キーを発見し、キーペアをクラックすることを意味しますが、これは実行不可能に思えます。したがって、リダイレクト攻撃を開始するには、CGAパラメーターデータ構造が交換されるときに攻撃者がパス上にいる必要があるため、変更できます。次に、リダイレクト攻撃を開始するために、攻撃者はCGAパラメーターデータ構造のプレフィックスセットに独自のプレフィックスを追加する必要があります。前のセクションでは、これには2つの可能なアプローチがあることがわかりました。1。通信で最初に使用されるアドレスが新しいHBAセットに含まれるように、適切な修飾子値を見つけます。この攻撃のコストは、生成プロセスのo（2（59 16*秒））反復であるため、実行不可能と見なされます。
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.
2. モディファイア値を使用して、通信で最初に使用されているアドレスがおそらくHBAセットに含まれていないようにします。この場合、攻撃者はパケットに掲載されたアドレスを書き換える必要があるため、攻撃者はパスで留まる必要があります（そうでない場合、エンドポイントは通信で使用されるアドレスの変更に気付きます）。これは本質的に、攻撃者が時間シフト攻撃を開始できないことを意味しますが、彼はフルタイムの中間の男でなければなりません。
So, the conclusion is that HBAs provide protection against time shifted attacks
したがって、HBAは時間シフト攻撃に対する保護を提供するという結論です
HBAs do not provide complete protection against flooding attacks, and, as a result, the SHIM6 protocol has other means to deal with them. However, HBAs make it very difficult to launch a flooding attack towards a specific address. It is possible though, to launch a flooding attack against a prefix. And of course, the protection that HBA offers applies only to nodes that employ it; HBA provides no solution for general-purpose flooding-attack protection for other nodes.
HBAは、洪水攻撃に対する完全な保護を提供しておらず、その結果、SHIM6プロトコルにはそれらに対処する他の手段があります。ただし、HBAは、特定の住所に向けて洪水攻撃を開始することを非常に困難にしています。ただし、プレフィックスに対する洪水攻撃を開始することが可能です。そしてもちろん、HBAが提供する保護は、それを採用するノードにのみ適用されます。HBAは、他のノードの汎用洪水攻撃保護のソリューションを提供しません。
Suppose that an attacker has easy access to a prefix PX::/nX and that he wants to launch a flooding attack on a host located in the address P:iid. The attack would consist of establishing communication with a server S and requesting a heavy flow from it. Then simply redirecting the flow to P:iid, flooding the target. In order to perform this attack, the attacker needs to generate an HBA set including P and PX in the prefix set, and be sure that the resulting HBA set contains P:iid. In order to do this, the attacker needs to find the appropriate Modifier value. The expected number of attempts required to find such Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can conclude that such attack is not feasible.
攻撃者がプレフィックスPX ::/NXに簡単にアクセスし、アドレスP：IIDにあるホストに洪水攻撃を開始したいとしているとします。攻撃は、サーバーとの通信を確立し、そこからの大量の流れを要求することで構成されます。次に、単にフローをP：IIDにリダイレクトし、ターゲットにあふれます。この攻撃を実行するには、攻撃者はプレフィックスセットにPとPXを含むHBAセットを生成し、結果のHBAセットにP：IIDが含まれていることを確認する必要があります。これを行うには、攻撃者は適切な修飾子値を見つける必要があります。前述のように、そのような修飾子値を見つけるために必要な試行回数はO（2（59 16*秒））です。したがって、そのような攻撃は実行不可能ではないと結論付けることができます。
However, the target of a flooding attack is not limited to specific hosts, but it can also be launched against other elements of the infrastructure, such as router or access links. In order to do that, the attacker can establish a communication with a server S and request a download of a heavy flow. Then, the attacker redirects the communication to any address of the target network. Even if the target address is not assigned to any host, the flow will flood the access link of the target site, and the site access router will also suffer the overload. Such attack cannot be prevented using HBAs, since the attacker can easily generate an HBA set using his own prefix and the target network prefix. In order to prevent such attacks, additional mechanisms are required, such as reachability tests.
ただし、洪水攻撃の目標は特定のホストに限定されませんが、ルーターやアクセスリンクなど、インフラストラクチャの他の要素に対しても起動することもできます。それを行うために、攻撃者はサーバーSとの通信を確立し、重いフローのダウンロードを要求できます。次に、攻撃者は通信をターゲットネットワークの任意のアドレスにリダイレクトします。ターゲットアドレスがホストに割り当てられていない場合でも、フローはターゲットサイトのアクセスリンクにあふれ、サイトアクセスルーターも過負荷になります。攻撃者は自分のプレフィックスとターゲットネットワークプレフィックスを使用してHBAセットを簡単に生成できるため、HBAを使用してこのような攻撃を防ぐことはできません。このような攻撃を防ぐために、到達可能性テストなど、追加のメカニズムが必要です。
HBAs can be used as RFC 4941 [7] addresses. If a node wants to use temporary addresses, it will need to periodically generate new HBA sets. The effort required for this operation depends on the Sec parameter value. If Sec=0, then the cost of generating a new HBA set is similar to the cost of generating a random number, i.e., one iteration of the HBA set generation procedure. However, if Sec>0, then the cost of generating an HBA set is significantly increased, since it required O(2(16*Sec)) iterations of the generation process. In this case, depending on the frequency of address change required, the support for RFC 4941 address may be more expensive.
HBAは、RFC 4941 [7]アドレスとして使用できます。ノードが一時的なアドレスを使用する場合、新しいHBAセットを定期的に生成する必要があります。この操作に必要な努力は、SECパラメーター値によって異なります。SEC = 0の場合、新しいHBAセットを生成するコストは、乱数を生成するコスト、つまりHBAセット生成手順の1回の反復に似ています。ただし、SEC> 0の場合、生成プロセスのO（2（16*SEC））反復が必要なため、HBAセットを生成するコストが大幅に増加します。この場合、必要なアドレス変更の頻度に応じて、RFC 4941アドレスのサポートはより高価になる可能性があります。
Recent attacks on currently used hash functions have motivated a considerable amount of concern in the Internet community. The recommended approach [14] [15] to deal with this issue is first to analyze the impact of these attacks on the different Internet protocols that use hash functions, and second to make sure that the different Internet protocols that use hash functions are capable of migrating to an alternative (more secure) hash function without a major disruption in the Internet operation.
現在使用されているハッシュ機能に対する最近の攻撃により、インターネットコミュニティでかなりの懸念が動機付けられています。この問題に対処するための推奨されるアプローチ[14] [15]は、最初にハッシュ関数を使用するさまざまなインターネットプロトコルに対するこれらの攻撃の影響を分析することです。インターネット運用を大きな混乱なしに、代替（より安全な）ハッシュ機能に移行します。
The aforementioned analysis for CGAs and their extensions (including HBAs) is performed in RFC 4982 [10]. The conclusion of the analysis is that the security of the protocols using CGAs and their extensions are not affected by the recently available attacks against hash functions. In spite of that, the CGA specification [2] was updated by RFC 4982 [10] to enable the support of alternative hash functions.
CGAとその拡張（HBAを含む）の前述の分析は、RFC 4982で実行されます[10]。分析の結論は、CGAを使用したプロトコルのセキュリティとその拡張機能が、ハッシュ関数に対する最近利用可能な攻撃の影響を受けないということです。それにもかかわらず、CGA仕様[2]はRFC 4982 [10]によって更新され、代替ハッシュ関数のサポートが可能になりました。
In order to use the HBA technique, the owner of the HBA set must inform its peer about the CGA Parameter Data Structure in order to allow the peer to verify that the different HBAs belong to the same HBA set. Such information must then be stored by the peer to verify alternative addresses in the future. This can be a vector for DoS attacks, since the peer must commit resources (in this particular case memory) to be able to use the HBA technique for address verification. It is then possible for an attacker to launch a DoS attack by conveying HBA information to a victim, imposing on the victim to use memory for storing HBA related state, and eventually running out of memory for other genuine operations. In order to prevent such an attack, protocols that use the HBA technique should implement proper DoS prevention techniques.
HBA技術を使用するために、HBAセットの所有者は、異なるHBAが同じHBAセットに属していることをピアが確認できるようにするために、CGAパラメーターデータ構造についてピアに通知する必要があります。そのような情報は、将来の代替アドレスを検証するために、ピアによって保存する必要があります。これは、DOS攻撃のベクトルになる可能性があります。なぜなら、ピアは（この特定のケースメモリで）リソースをコミットして、アドレス検証にHBA手法を使用できるようにする必要があるためです。その後、攻撃者がHBA情報を被害者に伝え、被害者にHBA関連状態を保存するために記憶を使用するように課すことにより、DOS攻撃を開始することが可能です。このような攻撃を防ぐために、HBA技術を使用するプロトコルは、適切なDOS予防技術を実装する必要があります。
For instance, the Shim6 protocol [9] includes a 4-way handshake to establish the Shim6 context and, in particular, to establish the HBA-related state. In this 4-way handshake, the receiver remains stateless during the first 2 messages, while the initiator must keep state throughout the exchange of the 4 messages so that the cost of the context establishment is higher in memory terms for the initiator (i.e., the potential attacker) than for the receiver (i.e., the potential victim). In addition to that, the 4-way handshake prevents the usage of spoofed addresses from off-path attacker, since the initiator must be able to receive information through the address it has used as source address, enabling the tracking of the location from which the attack was launched.
たとえば、SHIM6プロトコル[9]には、SHIM6コンテキストを確立するための4ウェイハンドシェイク、特にHBA関連状態を確立するための4方向の握手が含まれています。この4ウェイハンドシェイクでは、受信者は最初の2つのメッセージの間はステートレスのままですが、イニシエーターは4つのメッセージの交換全体で状態を維持する必要があります。潜在的な攻撃者）レシーバー（つまり、潜在的な犠牲者）よりも。それに加えて、4ウェイの握手は、パス攻撃者からのスプーフィングされたアドレスの使用を防ぎます。イニシエーターは、ソースアドレスとして使用したアドレスを介して情報を受け取ることができ、そこからの追跡が可能な場所の追跡を可能にする必要があるため攻撃が開始されました。
This document was originally produced by a MULTI6 design team consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret Wasserman, and Jukka Ylitalo.
このドキュメントは、もともと（アルファベット順）で構成されるMulti6設計チームによって作成されました。JariArkko、Marcelo Bagnulo、Iljitsch Van Beijnum、Geoff Huston、Erik Nordmark、Margaret Wasserman、Jukka Ylitalo。
The initial discussion about HBA benefited from contributions from Alberto Garcia-Martinez, Tuomas Aura, and Arturo Azcorra.
HBAに関する最初の議論は、アルベルト・ガルシア・マルティネス、トゥオマス・オーラ、アルトゥーロ・アズコラからの貢献の恩恵を受けました。
The HBA-set generation and HBA verification processes described in this document contain several steps extracted from [2].
このドキュメントで説明されているHBAセット生成およびHBA検証プロセスには、[2]から抽出されたいくつかのステップが含まれています。
Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka Savola, Brian Carpenter, Eric Rescorla, Robin Whittle, Matthijs Mekking, Hannes Tschofenig, Spencer Dawkins, Lars Eggert, Tim Polk, Peter Koch, Niclas Comstedt, David Ward, and Sam Hartman have reviewed this document and provided valuable comments.
Jari Arkko、Matthew Ford、Francis Dupont、Mohan Parthasarathy、Pekka Savola、Brian Carpenter、Eric Rescorla、Robin Whittle、Matthijs Mekking、Hannes Tschofenig、Spencer Dawkins、Lars Eggert、Tim Polk、Peter Koch、Niclas comstedteHartmanはこの文書をレビューし、貴重なコメントを提供しました。
The text included in Section 3.2 was provided by Eric Rescorla.
セクション3.2に含まれるテキストは、Eric Rescorlaによって提供されました。
The author would also like to thank Francis Dupont for providing the first implementation of HBA.
著者はまた、HBAの最初の実装を提供してくれたFrancis Dupontに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2] オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[3] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[4] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[4] Bassham、L.、Polk、W。、およびR. Housley、「インターネットのアルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3279、2002年4月。
[5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[5] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC5280、2008年5月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[6] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[7] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[7] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[8] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
[8] Bagnulo、M。およびJ. Arkko、「暗号化されたアドレス（CGA）拡張フィールド形式」、RFC 4581、2006年10月。
[9] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[9] Nordmark、E。and M. Bagnulo、「Shim6：IPv6用のレベル3マルチホミングシムプロトコル」、RFC 5533、2009年6月。
[10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, July 2007.
[10] Bagnulo、M。およびJ. Arkko、「暗号化されたアドレス（CGA）での複数のハッシュアルゴリズムのサポート」、RFC 4982、2007年7月。
[11] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[11] Nordmark、E。およびT. Li、「IPv6マルチホームソリューションに関連する脅威」、RFC 4218、2005年10月。
[12] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[12] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4225、2005年12月。
[13] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[13] Arkko、J.、Vogt、C。、およびW. Haddad、「モバイルIPv6の強化されたルート最適化」、RFC 4866、2007年5月。
[14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[14] Hoffman、P。and B. Schneier、「インターネットプロトコルにおける暗号化に対する攻撃」、RFC 4270、2005年11月。
[15] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", 2005 September.
[15] Bellovin、S。およびE. Rescorla、「新しいハッシュアルゴリズムの展開」、2005年9月。
[16] Nordmark, E., "Multi6 Application Referral Issues", Work in Progress, October 2004.
[16] Nordmark、E。、「Multi6 Application紹介の問題」、2004年10月、進行中の作業。
[17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient Security for IPv6 Multihoming", ACM Computer Communications Review Vol 35 n 2, April 2005.
[17] Bagnulo、M.、Garcia-Martinez、A。、およびA. Azcorra、「IPv6 Multihomingの効率的なセキュリティ」、ACMコンピューター通信レビューVol 35 N 2、2005年4月。
[18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[18] Hinden、R。and B. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[19] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[19] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
Author's Address
著者の連絡先
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
Marcelo Bagnulo Universidad Carlos III de Madrid av。Universidad 30 Leganes、Madrid 28911スペイン
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es