RFC5206 日本語訳
5206 End-Host Mobility and Multihoming with the Host IdentityProtocol. P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. April 2008. (Format: TXT=99430 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Nikander
Request for Comments: 5206 Ericsson Research NomadicLab
Category: Experimental T. Henderson, Ed.
The Boeing Company
C. Vogt
J. Arkko
Ericsson Research NomadicLab
April 2008
Nikanderがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5206年のエリクソン研究NomadicLabカテゴリ: 実験的なT.ヘンダーソン、エドボーイング社C.フォークトJ.ArkkoエリクソンはNomadicLab2008年4月に研究されます。
End-Host Mobility and Multihoming with the Host Identity Protocol
ホストアイデンティティプロトコルがある終わりホストの移動性とマルチホーミング
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.
このドキュメントはHost Identityプロトコル(HIP)と移動性とマルチホーミング拡大を定義します。 明確に、このドキュメントはクールなメッセージのためのクールなホストがそれに達するかもしれない代替アドレスに関して同輩に通知するのを許容する一般的な「ロケータ」パラメタを定義します。 また、このドキュメントはHIPホストの移動性のために手順の要素を定義します--ホストがダイナミックに、それがパケットを受けるのに使用する第一のロケータを変える過程。 また、終わりホストマルチホーミングを支持するのに同じLOCATORパラメタを使用できますが、詳細手順書はさらなる研究に発たれます。
Table of Contents
目次
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8
3.1.3. Multihoming Overview . . . . . . . . . . . . . . . . . 8
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 9
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Host Multihoming . . . . . . . . . . . . . . . . . . . 11
3.2.4. Site Multihoming . . . . . . . . . . . . . . . . . . . 13
3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 14
3.2.6. Combined Mobility and Multihoming . . . . . . . . . . 14
1. 序論と範囲. . . . . . . . . . . . . . . . . . . . 2 2。 用語とコンベンション. . . . . . . . . . . . . . . . . 4 3。 モデル. . . . . . . . . . . . . . . . . . . . . . . . 5 3.1について議定書の中で述べてください。 環境. . . . . . . . . . . . . . . . . . 5 3.1.1を操作します。 ロケータ. . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2。 移動性概観. . . . . . . . . . . . . . . . . . 8 3.1.3。 マルチホーミング概観. . . . . . . . . . . . . . . . . 8 3.2。 概観. . . . . . . . . . . . . . . . . . . . 9 3.2.1について議定書の中で述べてください。 1SA組(Rekeyingがありません).93.2.2がある移動性。 ただ一つのSA組(モバイルに開始しているRekey). . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3がある移動性。 マルチホーミング. . . . . . . . . . . . . . . . . . . 11 3.2.4を接待してください。 サイトマルチホーミング. . . . . . . . . . . . . . . . . . . 13 3.2.5。 二元的なホストマルチホーミング. . . . . . . . . . . . . . . . 14 3.2.6。 結合した移動性とマルチホーミング. . . . . . . . . . 14
Nikander, et al. Experimental [Page 1] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[1ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
3.2.7. Using LOCATORs across Addressing Realms . . . . . . . 14
3.2.8. Network Renumbering . . . . . . . . . . . . . . . . . 15
3.2.9. Initiating the Protocol in R1 or I2 . . . . . . . . . 15
3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 16
3.3.1. Address Verification . . . . . . . . . . . . . . . . . 16
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 17
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 18
3.3.4. Interaction with Security Associations . . . . . . . . 18
4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 21
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 23
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 23
4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 24
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Locator Data Structure and Status . . . . . . . . . . . . 24
5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 25
5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 28
5.4. Verifying Address Reachability . . . . . . . . . . . . . . 30
5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 31
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 32
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 32
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 35
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 36
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 36
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 36
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative references . . . . . . . . . . . . . . . . . . . 38
9.2. Informative references . . . . . . . . . . . . . . . . . . 38
3.2.7. 分野. . . . . . . 14 3.2.8を記述することの向こう側にロケータを使用します。 番号を付け替え. . . . . . . . . . . . . . . . . 15 3.2る.9をネットワークでつないでください。 R1かI2. . . . . . . . . 15 3.3のプロトコルを開始します。 他の問題. . . . . . . . . . . . . . . . . . . 16 3.3.1。 検証. . . . . . . . . . . . . . . . . 16 3.3.2を記述してください。 クレジットベースの認可. . . . . . . . . . . . . . 17 3.3.3。 都合のよいロケータ. . . . . . . . . . . . . . . . . . 18 3.3.4。 セキュリティ関係. . . . . . . . 18 4との相互作用。 ロケータパラメタ形式. . . . . . . . . . . . . . . . . . . 21 4.1。 交通タイプと都合のよいロケータ. . . . . . . . . . . . 23 4.2。 ロケータタイプとロケータ. . . . . . . . . . . . . . . . . 23 4.3。 含まれているロケータ. . . . . . . . . . . 24 5でパケットをアップデートしてください。 規則. . . . . . . . . . . . . . . . . . . . . . . 24 5.1を処理します。 ロケータデータ構造と状態. . . . . . . . . . . . 24 5.2。 ロケータ. . . . . . . . . . . . . . . . . . . . . 25 5.3を送ります。 取り扱いはロケータ. . . . . . . . . . . . . . . . 28 5.4を受けました。 アドレスの可到達性. . . . . . . . . . . . . . 30 5.5について確かめます。 都合のよいロケータ. . . . . . . . . . . . . . 31 5.6を変えます。 クレジットベースの認可. . . . . . . . . . . . . . . . 32 5.6.1。 有効搭載量パケット. . . . . . . . . . . . . . . 32 5.6.2を扱います。 年をと. . . . . . . . . . . . . . . . . . . . . 33 6ることを掛けてください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 34 6.1。 ものまねは.356.2を攻撃します。 サービス不能攻撃. . . . . . . . . . . . . . . . 36 6.2.1。 フラッディング攻撃. . . . . . . . . . . . . . . . . . . 36 6.2.2。 コンピュータのメモリ/疲労困憊DoSは.366.3を攻撃します。 Mixed展開環境. . . . . . . . . . . . . . . 37 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 37 8。 作者と承認. . . . . . . . . . . . . . . . . 38 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 38 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 38
1. Introduction and Scope
1. 序論と範囲
The Host Identity Protocol [RFC4423] (HIP) supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities. When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) are instead bound to representations of these host identities, and the IP addresses are only used for packet forwarding. However, each host must also know at least one IP address at which its peers are reachable. Initially, these IP addresses are the ones used during the HIP base exchange [RFC5201].
Host Identityプロトコル[RFC4423](HIP)はインターネットワーキング層(IPv4とIPv6)からトランスポート層(TCP、UDPなど)の公衆/秘密鍵組を使用することによって衝撃を吸収する構造をサポートします、IPアドレスの代わりに、ホストのアイデンティティとして。 ホストがHIPを使用すると、付加プロトコル副層(例えば、トランスポート層ソケットとEncapsulating Security有効搭載量(超能力)セキュリティAssociations(SAs))は代わりにこれらのホストのアイデンティティの表現に縛られます、そして、IPアドレスはパケット推進に使用されるだけです。 しかしながら、また、各ホストは同輩が届いている少なくとも1つのIPアドレスを知らなければなりません。 初めは、これらのIPアドレスはHIP塩基置換[RFC5201]の間に使用されるものです。
Nikander, et al. Experimental [Page 2] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[2ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. There are potentially many variations of mobility and multihoming possible. The scope of this document encompasses messaging and elements of procedure for basic network-level mobility and simple multihoming, leaving more complicated scenarios and other variations for further study. More specifically:
そのようなデカップリングの1つの結果はネットワーク層の移動性とホストマルチホーミングの新しい解決が可能であるということです。 移動性とマルチホーミングの可能な潜在的に多くの変化があります。 このドキュメントの範囲は基本的なネットワークレベルの移動性と簡単なマルチホーミングのために手順のメッセージングと要素を包含します、より複雑なシナリオと他の変化をさらなる研究に発って。 より明確に:
This document defines a generalized LOCATOR parameter for use in
HIP messages. The LOCATOR parameter allows a HIP host to notify a
peer about alternate addresses at which it is reachable. The
LOCATORs may be merely IP addresses, or they may have additional
multiplexing and demultiplexing context to aid the packet handling
in the lower layers. For instance, an IP address may need to be
paired with an ESP Security Parameter Index (SPI) so that packets
are sent on the correct SA for a given address.
このドキュメントはHIPメッセージにおける使用のための一般化されたLOCATORパラメタを定義します。 LOCATORパラメタで、HIPホストはそれが届いている代替アドレスに関して同輩に通知できます。 LOCATORsは単にIPアドレスであるかもしれませんかそれらには下層でパケット取り扱いを支援する追加マルチプレクシングと逆多重化文脈があるかもしれません。 例えば、IPアドレスは、与えられたアドレスのために正しいSAにパケットを送るように超能力Security Parameter Index(SPI)と対にされる必要があるかもしれません。
This document also specifies the messaging and elements of
procedure for end-host mobility of a HIP host -- the sequential
change in the preferred IP address used to reach a host. In
particular, message flows to enable successful host mobility,
including address verification methods, are defined herein.
また、このドキュメントはHIPホストの終わりホストの移動性に手順のメッセージングと要素を指定します--都合のよいIPアドレスにおける連続した変化は以前はよくホストに届いていました。 特に、アドレス検査方法を含むうまくいっているホストの移動性を可能にするメッセージ流れはここに定義されます。
However, while the same LOCATOR parameter is intended to support
host multihoming (parallel support of a number of addresses), and
experimentation is encouraged, detailed elements of procedure for
host multihoming are left for further study.
しかしながら、同じLOCATORパラメタがホストマルチホーミング(多くのアドレスの平行なサポート)を支持することを意図して、実験は奨励されますが、ホストマルチホーミングのための手順の詳細な要素はさらなる研究に残されます。
While HIP can potentially be used with transports other than the ESP transport format [RFC5202], this document largely assumes the use of ESP and leaves other transport formats for further study.
超能力輸送形式[RFC5202]以外の輸送と共にHIPを潜在的に使用できますが、このドキュメントは、超能力の使用を主に仮定して、さらなる研究のために他の輸送を形式に残します。
There are a number of situations where the simple end-to-end readdressing functionality is not sufficient. These include the initial reachability of a mobile host, location privacy, simultaneous mobility of both hosts, and some modes of NAT traversal. In these situations, there is a need for some helper functionality in the network, such as a HIP rendezvous server [RFC5204]. Such functionality is out of the scope of this document. We also do not consider localized mobility management extensions (i.e., mobility management techniques that do not involve directly signaling the correspondent node); this document is concerned with end-to-end mobility. Finally, making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document.
多くの状況が簡単な機能性にあて名を書き直させる終わりから終わりが十分でないところにあります。 これらはモバイルホストの初期の可到達性を含んでいます、位置のプライバシー、ホストとNAT縦断のいくつかの方法の両方の同時の移動性。 これらの状況に、ネットワークには何らかのアシスタントの機能性の必要があります、HIPランデブーサーバ[RFC5204]のように。 このドキュメントの範囲の外にそのような機能性はあります。 また、私たちは、局所化された移動性が管理拡大(すなわち、直接通信員ノードに合図することを伴わない移動性管理技術)であると考えません。 このドキュメントは終わりから終わりへの移動性に関係があります。 最終的に、基本的なIPの移動性をトランスポート層に透明にすると、意味はService(QoS)の輸送輻輳制御、経路MTU選択、およびQualityの適切な応答に持たれています。 このドキュメントの範囲の外にトランスポート層移動性引き金、およびHIPの移動性かマルチホーミングアドレス変化への適切な輸送応答があります。
Nikander, et al. Experimental [Page 3] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[3ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
2. Terminology and Conventions
2. 用語とコンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
LOCATOR. The name of a HIP parameter containing zero or more Locator
fields. This parameter's name is distinguished from the Locator
fields embedded within it by the use of all capital letters.
ロケータ。 ゼロを含むHIPパラメタかLocatorがさばく以上の名前。 このパラメタの名前はそれの中ですべての大文字の使用で埋め込まれたLocator分野と区別されます。
Locator. A name that controls how the packet is routed through the
network and demultiplexed by the end host. It may include a
concatenation of traditional network addresses such as an IPv6
address and end-to-end identifiers such as an ESP SPI. It may
also include transport port numbers or IPv6 Flow Labels as
demultiplexing context, or it may simply be a network address.
ロケータ。 パケットがどうネットワークを通して発送されて、終わりのホストによって反多重送信されるかを制御する名前。 それはIPv6アドレスなどの伝統的ネットワークアドレスと終わりから終わりへのESP SPIなどの識別子の連結を含むかもしれません。 また、それは逆多重化文脈として輸送のポートナンバーかIPv6 Flow Labelsを含むかもしれませんか、それが単にネットワーク・アドレスであるかもしれません。
Address. A name that denotes a point-of-attachment to the network.
The two most common examples are an IPv4 address and an IPv6
address. The set of possible addresses is a subset of the set of
possible locators.
アドレス。 ネットワークに接着点を指示する名前。 2つの最も一般的な例が、IPv4アドレスとIPv6アドレスです。 可能なアドレスのセットは可能なロケータのセットの部分集合です。
Preferred locator. A locator on which a host prefers to receive
data. With respect to a given peer, a host always has one active
Preferred locator, unless there are no active locators. By
default, the locators used in the HIP base exchange are the
Preferred locators.
都合のよいロケータ。 ホストがデータを受け取るのを好むロケータ。 与えられた同輩に関して、アクティブなロケータがないのがない場合、ホストはいつも1つのアクティブなPreferredロケータを持っています。 デフォルトで、HIP塩基置換に使用されるロケータはPreferredロケータです。
Credit Based Authorization. A host must verify a mobile or
multihomed peer's reachability at a new locator. Credit-Based
Authorization authorizes the peer to receive a certain amount of
data at the new locator before the result of such verification is
known.
クレジットは認可を基礎づけました。 ホストは新しいロケータで可動の、または、「マルチ-家へ帰」っている同輩の可到達性について確かめなければなりません。 そのような検証の結果が知られている前にベースのクレジットAuthorizationは、同輩が新しいロケータにおける、あるデータ量を受け取るのを認可します。
Nikander, et al. Experimental [Page 4] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[4ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
3. Protocol Model
3. プロトコルモデル
This section is an overview; more detailed specification follows this section.
このセクションは概観です。 より詳細な仕様はこのセクションに従います。
3.1. Operating Environment
3.1. 操作環境
The Host Identity Protocol (HIP) [RFC5201] is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities, and establishing security associations (SAs) for the ESP transport format [RFC5202] and possibly other protocols in the future.
Host Identityプロトコル(HIP)[RFC5201]は、主要な設立とパラメタ交渉プロトコルです。 第一の利用は、将来超能力輸送形式[RFC5202]とことによると他のプロトコルのために、ホストのアイデンティティに基づくホストメッセージを認証して、セキュリティ協会(SAs)を設立するものです。
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ | | | | | +------------+ | | +------------+ | | | キー| | ヒップ| | キー| | | | 管理| <。+-----------------------+->。| 管理| | | | 過程| | | | 過程| | | +------------+ | | +------------+ | | ^ | | ^ | | | | | | | | v| | v| | +------------+ | | +------------+ | | | IPsec| | 超能力| | IPsec| | | | スタック| <。+-----------------------+->。| スタック| | | | | | | | | | | +------------+ | | +------------+ | | | | | | | | | | 創始者| | 応答者| +--------------------+ +--------------------+
Figure 1: HIP Deployment Model
図1: クールな展開モデル
The general deployment model for HIP is shown above, assuming operation in an end-to-end fashion. This document specifies extensions to the HIP protocol to enable end-host mobility and basic multihoming. In summary, these extensions to the HIP base protocol enable the signaling of new addressing information to the peer in HIP messages. The messages are authenticated via a signature or keyed hash message authentication code (HMAC) based on its Host Identity. This document specifies the format of this new addressing (LOCATOR) parameter, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for a concurrent address verification mechanism.
終わりから終わりへのファッションで操作を仮定して、HIPの一般的な展開モデルは上で見せられます。 このドキュメントは、終わりホストの移動性と基本的なマルチホーミングを可能にするためにHIPプロトコルに拡大を指定します。 概要では、HIPベースプロトコルへのこれらの拡大は新しいアドレス指定情報のシグナリングをHIPメッセージの同輩に可能にします。 Host Identityに基づく署名か合わせられた細切れ肉料理メッセージ確認コード(HMAC)でメッセージは認証されます。 このドキュメントはこの新しいアドレシング(LOCATOR)パラメタの形式、基本的なホストの移動性を可能にするためにこのパラメタを送って、処理するための手順、および同時発生のアドレス検査メカニズムのための手順を指定します。
Nikander, et al. Experimental [Page 5] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[5ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
---------
| TCP | (sockets bound to HITs)
---------
|
---------
----> | ESP | {HIT_s, HIT_d} <-> SPI
| ---------
| |
---- ---------
| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
---- ---------
|
---------
| IP |
---------
--------- | TCP| (HITsに縛られたソケット) --------- | --------- ---->| 超能力| _sを打ってくださいといって、当たってください、<->SPI| --------- | | ---- --------- | MH|、-、>、| ヒップ| SPI、_sを打ってくださいといって、当たってください、<->、IP_s、IP、SPI---- --------- | --------- | IP| ---------
Figure 2: Architecture for HIP Mobility and Multihoming (MH)
図2: クールな移動性とマルチホーミングのための構造(MH)
Figure 2 depicts a layered architectural view of a HIP-enabled stack using the ESP transport format. In HIP, upper-layer protocols (including TCP and ESP in this figure) are bound to Host Identity Tags (HITs) and not IP addresses. The HIP sublayer is responsible for maintaining the binding between HITs and IP addresses. The SPI is used to associate an incoming packet with the right HITs. The block labeled "MH" is introduced below.
図2は、超能力輸送形式を使用することでHIPによって可能にされたスタックの層にされた建築視点について表現します。 HIPでは、上側の層のプロトコル(この図におけるTCPと超能力を含んでいる)はIPアドレスではなく、Host Identity Tags(HITs)に縛られます。 HIP副層はHITsとIPアドレスの間の結合を維持するのに原因となります。 SPIは、入って来るパケットを右のHITsに関連づけるのに使用されます。 "MH"とラベルされたブロックは以下で紹介されます。
Consider first the case in which there is no mobility or multihoming, as specified in the base protocol specification [RFC5201]. The HIP base exchange establishes the HITs in use between the hosts, the SPIs to use for ESP, and the IP addresses (used in both the HIP signaling packets and ESP data packets). Note that there can only be one such set of bindings in the outbound direction for any given packet, and the only fields used for the binding at the HIP layer are the fields exposed by ESP (the SPI and HITs). For the inbound direction, the SPI is all that is required to find the right host context. ESP rekeying events change the mapping between the HIT pair and SPI, but do not change the IP addresses.
最初に、移動性かマルチホーミングが全くベースプロトコル仕様で指定されるようにない場合[RFC5201]を考えてください。 HIP塩基置換はホストの間で使用中のHITsを設立します、超能力、およびIPにアドレスを使用するSPIs(HIPシグナリングパケットと超能力データ・パケットの両方では、使用されます)。 どんな与えられたパケットのための外国行きの方向にはもそのようなセットの1つの結合があることができるだけであって、HIP層での結合に使用される唯一の分野が超能力(SPIとHITs)によって露出された分野であることに注意してください。 本国行きの指示に関しては、SPIは正しいホスト文脈を見つけるのに必要であるすべてです。 超能力「再-合わせ」る出来事は、HIT組とSPIの間でマッピングを変えますが、IPアドレスは変えません。
Consider next a mobility event, in which a host is still single-homed but moves to another IP address. Two things must occur in this case. First, the peer must be notified of the address change using a HIP UPDATE message. Second, each host must change its local bindings at the HIP sublayer (new IP addresses). It may be that both the SPIs and IP addresses are changed simultaneously in a single UPDATE; the protocol described herein supports this. However, simultaneous movement of both hosts, notification of transport layer protocols of the path change, and procedures for possibly traversing middleboxes are not covered by this document.
次に、移動性出来事であり、アドレスがホストがどれであるかを、まだシングル家へ帰っていますが、別のIPに動いていると考えてください。 2つのものがこの場合現れなければなりません。 まず最初に、HIP UPDATEメッセージを使用するアドレス変化について同輩に通知しなければなりません。 2番目に、各ホストはHIP副層(新しいIPアドレス)で局所束縛を変えなければなりません。 多分、同時に、独身のUPDATEでSPIsとIPアドレスの両方を変えます。 ここに説明されたプロトコルはこれを支持します。 しかしながら、両方のホストの同時の運動、経路変化のトランスポート層プロトコルの通知、およびことによるとmiddleboxesを横断するための手順はこのドキュメントで含まれていません。
Nikander, et al. Experimental [Page 6] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[6ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
Finally, consider the case when a host is multihomed (has more than one globally routable address) and has multiple addresses available at the HIP layer as alternative locators for fault tolerance. Examples include the use of (possibly multiple) IPv4 and IPv6 addresses on the same interface, or the use of multiple interfaces attached to different service providers. Such host multihoming generally necessitates that a separate ESP SA is maintained for each interface in order to prevent packets that arrive over different paths from falling outside of the ESP anti-replay window [RFC4303]. Multihoming thus makes it possible that the bindings shown on the right side of Figure 2 are one to many (in the outbound direction, one HIT pair to multiple SPIs, and possibly then to multiple IP addresses). However, only one SPI and address pair can be used for any given packet, so the job of the "MH" block depicted above is to dynamically manipulate these bindings. Beyond locally managing such multiple bindings, the peer-to-peer HIP signaling protocol needs to be flexible enough to define the desired mappings between HITs, SPIs, and addresses, and needs to ensure that UPDATE messages are sent along the right network paths so that any HIP-aware middleboxes can observe the SPIs. This document does not specify the "MH" block, nor does it specify detailed elements of procedure for how to handle various multihoming (perhaps combined with mobility) scenarios. The "MH" block may apply to more general problems outside of HIP. However, this document does describe a basic multihoming case (one host adds one address to its initial address and notifies the peer) and leave more complicated scenarios for experimentation and future documents.
ホストが「マルチ-家へ帰」って(1つ以上にアドレスをグローバルに発送可能させます)、耐障害性のための代替のロケータとしてHIP層で利用可能な複数のアドレスを持っているときには最終的に、ケースを考えてください。 例が同じインタフェースに関する(ことによると複数)のIPv4とIPv6アドレスの使用を含んでいるか、または複数のインタフェースの使用は異なったサービスプロバイダーに付きました。 一般に、そのようなホストマルチホーミングはそれを必要とします。別々のESP SAは、異なった経路の上で到着するパケットが超能力反再生ウィンドウ[RFC4303]の外に落ちるのを防ぐために各インタフェースに維持されます。 マルチホーミングで、その結果、図2の右側に示された結合が多く(複数のSPIsと、そして、ことによるとそして、複数のIPアドレスへの外国行きの指示の1HIT組)への1つであることは可能になります。 上に表現された"MH"ブロックの仕事はしかしながら、どんな与えられたパケットにも1SPIとアドレス組しか使用できないのでダイナミックにこれらの結合を操ることです。 局所的にそのような複数の結合を管理することを超えて、ピアツーピアHIPシグナリングプロトコルは、HITsと、SPIsと、アドレスの間の必要なマッピングを定義するほどフレキシブルであることが必要であり、どんなHIP意識しているmiddleboxesもSPIsを観測できるようにUPDATEメッセージが正しいネットワーク経路に沿って送られるのを保証する必要があります。 このドキュメントは"MH"ブロックを指定しません、そして、それはどう様々なマルチホーミング(恐らく移動性に結合される)シナリオを扱うかに手順の詳細な要素を指定しません。 "MH"ブロックはヒップの外で、より一般的な問題に適用されるかもしれません。 しかしながら、このドキュメントは、基本的なマルチホーミングケース(1人のホストが、1つのアドレスを初期のアドレスに追加して、同輩に通知する)について説明して、実験と将来のドキュメントにより複雑なシナリオを残します。
3.1.1. Locator
3.1.1. ロケータ
This document defines a generalization of an address called a "locator". A locator specifies a point-of-attachment to the network but may also include additional end-to-end tunneling or per-host demultiplexing context that affects how packets are handled below the logical HIP sublayer of the stack. This generalization is useful because IP addresses alone may not be sufficient to describe how packets should be handled below HIP. For example, in a host multihoming context, certain IP addresses may need to be associated with certain ESP SPIs to avoid violating the ESP anti-replay window. Addresses may also be affiliated with transport ports in certain tunneling scenarios. Locators may simply be traditional network addresses. The format of the locator fields in the LOCATOR parameter is defined in Section 4.
このドキュメントは「ロケータ」と呼ばれるアドレスの一般化を定義します。 ロケータは、ネットワークに接着点を指定しますが、また、パケットがスタックの論理的なHIP副層の下でどう扱われるかに影響する終わりから終わりへの追加トンネリングか1ホストあたりの逆多重化文脈を含むかもしれません。 IPアドレスだけがパケットがHIPの下でどう扱われるべきであるかを説明するために十分でないかもしれないので、この一般化は役に立ちます。 例えば、ホストマルチホーミング文脈では、あるIPアドレスは、超能力反再生ウィンドウに違反するのを避けるのに、ある超能力SPIsに関連している必要があるかもしれません。 また、アドレスはあるトンネリングシナリオで輸送ポートに加わられるかもしれません。 ロケータは単に伝統的ネットワークアドレスであるかもしれません。 LOCATORパラメタのロケータ分野の書式はセクション4で定義されます。
Nikander, et al. Experimental [Page 7] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[7ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
3.1.2. Mobility Overview
3.1.2. 移動性概観
When a host moves to another address, it notifies its peer of the new address by sending a HIP UPDATE packet containing a LOCATOR parameter. This UPDATE packet is acknowledged by the peer. For reliability in the presence of packet loss, the UPDATE packet is retransmitted as defined in the HIP protocol specification [RFC5201]. The peer can authenticate the contents of the UPDATE packet based on the signature and keyed hash of the packet.
ホストが別のアドレスに移るとき、LOCATORパラメタを含むHIP UPDATEパケットを送ることによって、それは新しいアドレスについて同輩に通知します。 このUPDATEパケットは同輩によって承認されます。 パケット損失の面前で信頼性において、UPDATEパケットはHIPプロトコル仕様[RFC5201]に基づき定義されるように再送されます。 同輩は署名に基づくUPDATEパケットのコンテンツとパケットの合わせられた細切れ肉料理を認証できます。
When using ESP Transport Format [RFC5202], the host may at the same time decide to rekey its security association and possibly generate a new Diffie-Hellman key; all of these actions are triggered by including additional parameters in the UPDATE packet, as defined in the base protocol specification [RFC5201] and ESP extension [RFC5202].
超能力Transport Format[RFC5202]を使用するとき、ホストは、同時に、セキュリティ協会についてrekeyに決めて、ことによると新しいディフィー-ヘルマンキーを発生させるかもしれません。 これらの動作のすべてがUPDATEパケットに追加パラメタを含んでいることによって、引き起こされます、ベースプロトコル仕様[RFC5201]と超能力拡大[RFC5202]で定義されるように。
When using ESP (and possibly other transport modes in the future), the host is able to receive packets that are protected using a HIP created ESP SA from any address. Thus, a host can change its IP address and continue to send packets to its peers without necessarily rekeying. However, the peers are not able to send packets to these new addresses before they can reliably and securely update the set of addresses that they associate with the sending host. Furthermore, mobility may change the path characteristics in such a manner that reordering occurs and packets fall outside the ESP anti-replay window for the SA, thereby requiring rekeying.
超能力(そして、未来のことによると他の交通機関)を使用するとき、ホストは保護されて、HIPを使用するとESP SAがどんなアドレスからも作成されたということであるパケットを受けることができます。 したがって、ホストは、IPアドレスを変えて、必ず「再-合わせ」るというわけではなくてパケットを同輩に送り続けることができます。 しかしながら、確かにしっかりとそれらが送付ホストに関連づけるアドレスのセットをアップデートできる前に同輩はこれらの新しいアドレスにパケットを送ることができません。 その上、移動性はSAのために再命令が起こって、パケットが超能力反再生ウィンドウをそらせるくらいの方法における経路特性を変えるかもしれません、その結果、「再-合わせ」るのが必要です。
3.1.3. Multihoming Overview
3.1.3. マルチホーミング概観
A related operational configuration is host multihoming, in which a host has multiple locators simultaneously rather than sequentially, as in the case of mobility. By using the LOCATOR parameter defined herein, a host can inform its peers of additional (multiple) locators at which it can be reached, and can declare a particular locator as a "preferred" locator. Although this document defines a basic mechanism for multihoming, it does not define detailed policies and procedures, such as which locators to choose when more than one pair is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC3484]), and the implications of multihoming on transport protocols and ESP anti-replay windows. Additional definitions of HIP-based multihoming are expected to be part of future documents.
関連する操作上の構成はホストマルチホーミングです、移動性に関するケースのように。(ホストは連続するというよりむしろ同時に、それで複数のロケータを持っています)。 ここに定義されたLOCATORパラメタを使用することによって、ホストは、それに達することができる追加している(複数の)ロケータについて同輩に知らせることができて、「都合のよい」ロケータとして特定のロケータを宣言できます。 このドキュメントはマルチホーミングのために基本的機構を定義しますが、それはトランスポート・プロトコルと超能力反再生ウィンドウの上でマルチホーミングの1組以上が手があいているとき、どのロケータを選んだらよいかや同時の移動性の操作や、マルチホーミングや、ソースアドレス選択方針([RFC3484]で指定されたものを超えた)や、含意などの詳細な方針と手順を定義しません。 HIPベースのマルチホーミングの追加定義は将来のドキュメントの一部であると予想されます。
Nikander, et al. Experimental [Page 8] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[8ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
3.2. Protocol Overview
3.2. プロトコル概観
In this section, we briefly introduce a number of usage scenarios for HIP mobility and multihoming. These scenarios assume that HIP is being used with the ESP transform [RFC5202], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC5201]. However, for the (relatively) uninitiated reader, it is most important to keep in mind that in HIP the actual payload traffic is protected with ESP, and that the ESP SPI acts as an index to the right host-to-host context. More specification details are found later in Section 4 and Section 5.
このセクションでは、私たちはHIPの移動性とマルチホーミングのために簡潔に多くの用法シナリオを紹介します。 これらのシナリオは、HIPが超能力変換[RFC5202]と共に使用されていると仮定します、他のシナリオが将来、定義されるかもしれませんが。 これらの用法シナリオを理解するために、読者は少なくともHIPプロトコル仕様[RFC5201]に最少量で詳しいはずです。 しかしながら、(比較的、)、未経験の読者、HIPでは、実際のペイロード交通が超能力で保護されて、ESP SPIがインデックスとしてホストからホストへの正しい文脈に機能するのを覚えておくのは最も重要です。 よりその他の仕様の詳細が後でセクション4とセクション5で見つけられます。
The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Both of the hosts therefore have one incoming and one outgoing SA. Further, each SA uses the same pair of IP addresses, which are the ones used in the base exchange.
以下のシナリオは、2人のホストが互いと共にただ一つのHIP塩基置換を終了したと仮定します。 したがって、ホストの両方には、1入って来るSAと1出発しているSAがあります。 さらに、各SAはIPアドレスの同じ組を使用します。(アドレスは塩基置換に使用されるものです)。
The readdressing protocol is an asymmetric protocol where a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. The majority of the packets on which the LOCATOR parameters are expected to be carried are UPDATE packets. However, some implementations may want to experiment with sending LOCATOR parameters also on other packets, such as R1, I2, and NOTIFY.
あて名を書き直すプロトコルは可動の、または、「マルチ-家へ帰」っているホストが同輩ホストに受け取ったことを知らせさせるIPの変化が影響を受けるSPIsに記述する非対称のプロトコルです。 あて名を書き直す交換は、HIPが交換する存在のときに背負われるように設計されています。 LOCATORパラメタが運ばれると予想されるパケットの大部分がUPDATEパケットです。 しかしながら、いくつかの実現が他のパケットに関しても送付LOCATORパラメタを実験したがっているかもしれません、R1や、I2や、NOTIFYなどのように。
The scenarios below at times describe addresses as being in either an ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a host, newly-learned addresses of the peer must be verified before put into active service, and addresses removed by the peer are put into a deprecated state. Under limited conditions described below (Section 5.6), an UNVERIFIED address may be used. The addressing states are defined more formally in Section 5.1.
時には下のシナリオは、アドレスがACTIVE、VERIFIED、またはDEPRECATEDが述べるどちらかにあると記述します。 ホストの見解から、現役、および推奨しない状態に入れた状態で同輩によって外されたアドレスに入れる前に同輩の新たに学術的なアドレスについて確かめなければなりません。 (セクション5.6)の下で説明された限られた条件のもとでは、UNVERIFIEDアドレスは使用されるかもしれません。 アドレシング州はセクション5.1で、より正式に定義されます。
Hosts that use link-local addresses as source addresses in their HIP handshakes may not be reachable by a mobile peer. Such hosts SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR parameter.
ソースアドレスとして彼らのHIP握手にリンクローカルのアドレスを使用するホストは可動の同輩で届いていないかもしれません。 SHOULDが初期の握手かLOCATORパラメタでグローバルに発送可能なアドレスを提供するそのようなホスト。
3.2.1. Mobility with a Single SA Pair (No Rekeying)
3.2.1. 1SA組がある移動性(Rekeyingがありません)
A mobile host must sometimes change an IP address bound to an interface. The change of an IP address might be needed due to a change in the advertised IPv6 prefixes on the link, a reconnected PPP link, a new DHCP lease, or an actual movement to another subnet. In order to maintain its communication context, the host must inform its peers about the new IP address. This first example considers the
モバイルホストは時々インタフェースに縛られたIPアドレスを変えなければなりません。 IPアドレスの変化がリンク、再接続したPPPリンク、新しいDHCPリース、または別のサブネットへの実際の運動のときに広告を出しているIPv6接頭語における変化のため必要であるかもしれません。 コミュニケーション文脈を維持するために、ホストは新しいIPアドレスに関して同輩に知らせなければなりません。 この最初の例は考えます。
Nikander, et al. Experimental [Page 9] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[9ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
case in which the mobile host has only one interface, IP address, a single pair of SAs (one inbound, one outbound), and no rekeying occurs on the SAs. We also assume that the new IP addresses are within the same address family (IPv4 or IPv6) as the first address. This is the simplest scenario, depicted in Figure 3.
モバイルホストが、あるインタフェース、IPだけに扱わせるコネをケースに入れてください、1組のSAs、(1つ、本国行き、1、外国行き、)、「再-合わせ」ることはSAsに起こりません。 また、私たちは、最初のアドレスと同じアドレスファミリー(IPv4かIPv6)の中に新しいIPアドレスがあると思います。 これは図3に表現される中で最も簡単なシナリオです。
Mobile Host Peer Host
モバイルホストの同輩ホスト
UPDATE(ESP_INFO, LOCATOR, SEQ)
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
(超能力_インフォメーション、ロケータ、SEQ)をアップデートしてください。----------------------------------->アップデート(超能力_インフォメーション、SEQ、ACKは_要求を反映する)<。----------------------------------- (ACK、エコー_応答)をアップデートしてください。----------------------------------->。
Figure 3: Readdress without Rekeying, but with Address Check
図3: Rekeying、アドレスで、チェックにあて名を書き直させてください。
The steps of the packet processing are as follows:
パケット処理のステップは以下の通りです:
1. The mobile host is disconnected from the peer host for a brief
period of time while it switches from one IP address to another.
Upon obtaining a new IP address, the mobile host sends a LOCATOR
parameter to the peer host in an UPDATE message. The UPDATE
message also contains an ESP_INFO parameter containing the values
of the old and new SPIs for a security association. In this
case, the OLD SPI and NEW SPI parameters both are set to the
value of the preexisting incoming SPI; this ESP_INFO does not
trigger a rekeying event but is instead included for possible
parameter-inspecting middleboxes on the path. The LOCATOR
parameter contains the new IP address (Locator Type of "1",
defined below) and a locator lifetime. The mobile host waits for
this UPDATE to be acknowledged, and retransmits if necessary, as
specified in the base specification [RFC5201].
1. モバイルホスト簡潔な期間の間、同輩ホストから切断されます1つのIPアドレスから別のものに切り換えている間。 新しいIPアドレスを得ると、モバイルホストはUPDATEメッセージの同輩ホストにLOCATORパラメタを送ります。 また、UPDATEメッセージはセキュリティ協会のための古くて新しいSPIsの値を含む超能力_INFOパラメタを含んでいます。 この場合、OLD SPIとパラメタのNEW SPI両方が、先在の入って来るSPIの値に用意ができています。 この超能力_INFOは「再-合わせ」るイベントの引き金となりませんが、経路の可能なパラメタを点検するmiddleboxesのために代わりに含まれています。 LOCATORパラメタが新しいIPアドレスを含んでいる、(ロケータType、「1インチ、以下で定義されて、ロケータ生涯、」 モバイルホストは、このUPDATEが承認されるのを待っていて、必要なら、再送します、基礎仕様[RFC5201]で指定されるように。
2. The peer host receives the UPDATE, validates it, and updates any
local bindings between the HIP association and the mobile host's
destination address. The peer host MUST perform an address
verification by placing a nonce in the ECHO_REQUEST parameter of
the UPDATE message sent back to the mobile host. It also
includes an ESP_INFO parameter with the OLD SPI and NEW SPI
parameters both set to the value of the preexisting incoming SPI,
and sends this UPDATE (with piggybacked acknowledgment) to the
mobile host at its new address. The peer MAY use the new address
immediately, but it MUST limit the amount of data it sends to the
address until address verification completes.
2. 同輩ホストは、HIP協会とモバイルホストの送付先アドレスの間でUPDATEを受けて、それを有効にして、どんな局所束縛もアップデートします。 同輩ホストは、モバイルホストに送り返されたUPDATEメッセージのECHO_REQUESTパラメタに一回だけを置くことによって、アドレス検査を実行しなければなりません。 それは、また、パラメタがともに先在の入って来るSPIの値に設定するOLD SPIとNEW SPIと共に超能力_INFOパラメタを含めて、新しいアドレスのモバイルホストにこのUPDATEを送ります(便乗している承認で)。 同輩はすぐに、新しいアドレスを使用するかもしれませんが、それは検証が完成するアドレスまで送るデータ量をアドレスに制限しなければなりません。
Nikander, et al. Experimental [Page 10] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[10ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
3. The mobile host completes the readdress by processing the UPDATE
ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer
host receives this ECHO_RESPONSE, it considers the new address to
be verified and can put the address into full use.
3. モバイルホストが完成する、UPDATE ACKを処理して、一回だけを反響することによって、ECHOで_RESPONSEにあて名を書き直させてください。 同輩ホストがいったんこのECHO_RESPONSEを受け取ると、それは、新しいアドレスが確かめられると考えて、完全利用にアドレスを入れることができます。
While the peer host is verifying the new address, the new address is marked as UNVERIFIED in the interim, and the old address is DEPRECATED. Once the peer host has received a correct reply to its UPDATE challenge, it marks the new address as ACTIVE and removes the old address.
同輩ホストが新しいアドレスについて確かめている間、新しいアドレスはその間UNVERIFIEDとしてマークされます、そして、旧住所はDEPRECATEDです。 同輩ホストがいったん正しい回答をUPDATE挑戦に受け取ると、それは、ACTIVEとして新しいアドレスにマークして、旧住所を取り除きます。
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey)
3.2.2. 1SA組がある移動性(モバイルに開始しているRekey)
The mobile host may decide to rekey the SAs at the same time that it notifies the peer of the new address. In this case, the above procedure described in Figure 3 is slightly modified. The UPDATE message sent from the mobile host includes an ESP_INFO with the OLD SPI set to the previous SPI, the NEW SPI set to the desired new SPI value for the incoming SA, and the KEYMAT Index desired. Optionally, the host may include a DIFFIE_HELLMAN parameter for a new Diffie- Hellman key. The peer completes the request for a rekey as is normally done for HIP rekeying, except that the new address is kept as UNVERIFIED until the UPDATE nonce challenge is received as described above. Figure 4 illustrates this scenario.
モバイルホストはそれが新しいアドレスについて同輩に通知するのと同時にSAsについてrekeyに決めるかもしれません。 この場合、図3で説明された上の手順はわずかに変更されます。 モバイルホストから送られたUPDATEメッセージはOLD SPIセットがある超能力_INFOを前のSPIに含んでいます、とNEW SPIが入って来るSAのために必要な新しいSPI値に設定して、KEYMAT Indexは望んでいました。 任意に、ホストは新しいディフィーヘルマンキーのためのディフィー_ヘルマンパラメタを入れるかもしれません。 同輩は通常、HIP rekeyingのために行われるrekeyを求める要求を終了します、UPDATEの一回だけの挑戦が上で説明されるように受け取られているまで新しいアドレスがUNVERIFIEDとして保管されるのを除いて。 図4はこのシナリオを例証します。
Mobile Host Peer Host
モバイルホストの同輩ホスト
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
(超能力_インフォメーション、ロケータ、SEQ[ディフィー_ヘルマン])をアップデートしてください。----------------------------------->アップデート(超能力_インフォメーション、SEQ、ACKは_要求を反映します[ディフィー_ヘルマン])<。----------------------------------- (ACK、エコー_応答)をアップデートしてください。----------------------------------->。
Figure 4: Readdress with Mobile-Initiated Rekey
図4: モバイルに開始されることで、Rekeyにあて名を書き直させてください。
3.2.3. Host Multihoming
3.2.3. ホストマルチホーミング
A (mobile or stationary) host may sometimes have more than one interface or global address. The host may notify the peer host of the additional interface or address by using the LOCATOR parameter. To avoid problems with the ESP anti-replay window, a host SHOULD use a different SA for each interface or address used to receive packets from the peer host when multiple locator pairs are being used simultaneously rather than sequentially.
(モバイルか静止する)のホストには、1つ以上のインタフェースかグローバルアドレスが時々あるかもしれません。 LOCATORパラメタを使用することによって、ホストは追加インタフェースかアドレスについて同輩ホストに通知するかもしれません。 超能力反再生ウィンドウ、ホストSHOULDに関する問題を避けるには、複数のロケータ組が連続するというよりむしろ同時に使用される予定であるとき同輩ホストからパケットを受けるのに使用される各インタフェースかアドレスに異なったSAを使用してください。
Nikander, et al. Experimental [Page 11] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[11ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
When more than one locator is provided to the peer host, the host SHOULD indicate which locator is preferred (the locator on which the host prefers to receive traffic). By default, the addresses used in the base exchange are preferred until indicated otherwise.
1つ以上のロケータを同輩ホストに提供するとき、ホストSHOULDは、どのロケータが好まれるかを(ホストがトラフィックを受けるのを好むロケータ)示します。 デフォルトで、塩基置換に使用されるアドレスは別の方法で示されるまで好まれます。
In the multihoming case, the sender may also have multiple valid locators from which to source traffic. In practice, a HIP association in a multihoming configuration may have both a preferred peer locator and a preferred local locator, although rules for source address selection should ultimately govern the selection of the source locator based on the destination locator.
また、マルチホーミング場合では、送付者はトラフィックの出典を明示する複数の有効なロケータを持っているかもしれません。 実際には、マルチホーミング構成のHIP協会には、都合のよい同輩ロケータと都合のよい地方のロケータの両方があるかもしれません、ソースアドレス選択のための規則は結局、目的地ロケータに基づくソースロケータの選択を治めるべきですが。
Although the protocol may allow for configurations in which there is an asymmetric number of SAs between the hosts (e.g., one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is RECOMMENDED that inbound and outbound SAs be created pairwise between hosts. When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should be also rekeyed at that time. Although asymmetric SA configurations might be experimented with, their usage may constrain interoperability at this time. However, it is recommended that implementations attempt to support peers that prefer to use non-paired SAs. It is expected that this section and behavior will be modified in future revisions of this protocol, once the issue and its implications are better understood.
プロトコルはホストの間にSAsの非対称の数がある構成を考慮するかもしれませんが(例えば、1人のホストが2つのインタフェースと2本国行きのSAsを持っています、同輩は1つのインタフェースと1本国行きのSAを持っていますが)、本国行きの、そして、外国行きのSAsがホストの間の作成された対状であることはRECOMMENDEDです。 また、その時「再-合わせ」られて、超能力_INFOがいつ特定の外国行きのSA、対応する本国行きのSAがそうするべきであるrekeyに到着するかは、そうです。 非対称のSA構成は実験されるかもしれませんが、それらの用法はこのとき、相互運用性を抑制するかもしれません。 しかしながら、実装が、非対にされたSAsを使用するのを好む同輩をサポートするのを試みるのは、お勧めです。 このセクションと振舞いがこのプロトコルの今後の改正で変更されると予想されます、問題とその含意がいったん理解されているほうがよいと。
Consider the case between two hosts, one single-homed and one multihomed. The multihomed host may decide to inform the single- homed host about its other address. It is RECOMMENDED that the multihomed host set up a new SA pair for use on this new address. To do this, the multihomed host sends a LOCATOR with an ESP_INFO, indicating the request for a new SA by setting the OLD SPI value to zero, and the NEW SPI value to the newly created incoming SPI. A Locator Type of "1" is used to associate the new address with the new SPI. The LOCATOR parameter also contains a second Type "1" locator, that of the original address and SPI. To simplify parameter processing and avoid explicit protocol extensions to remove locators, each LOCATOR parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). The multihomed host waits for an ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. As in the mobility case, the peer host must perform an address verification before actively using the new address. Figure 5 illustrates this scenario.
1歳の2人のホストの間のケースがシングル家へ帰って、1つが「マルチ-家へ帰」ったと考えてください。 「マルチ-家へ帰」っているホストは、シングルを知らせるのが家へ帰ったと決めるかもしれません。他のアドレスに関するホスト。 「マルチ-家へ帰」っているホストがこの新しいアドレスにおける使用のために新しいSA組にセットしたのは、RECOMMENDEDです。 これをするために、「マルチ-家へ帰」っているホストは超能力_INFOとLOCATORを送ります、OLD SPI値をゼロにセットして、新たに作成された入って来るSPIにNEW SPI値をセットすることによって新しいSAを求める要求を示して。 「1インチは新しいアドレスを新しいSPIに関連づけるのに使用される」Locator Type。 また、LOCATORパラメタは第2のTypeを含んでいます。「1インチロケータ、オリジナルのアドレスとSPIのもの。」 ロケータを取り除くためにパラメタ処理を簡素化して、明白なプロトコル拡大を避けるために、それぞれのLOCATORパラメタは接続(ホストのための本国行きのロケータとSPIsの完全なリスト)のときに使用中のすべてのロケータを記載しなければなりません。 「マルチ-家へ帰」っているホストはそれ自身のUPDATEの同輩とACKから超能力_INFO(新しい外国行きのSA)を待ちます。 移動性ケースのように、活発に新しいアドレスを使用する前に、同輩ホストはアドレス検査を実行しなければなりません。 図5はこのシナリオを例証します。
Nikander, et al. Experimental [Page 12] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[12ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
Multi-homed Host Peer Host
マルチ、家へ帰り、ホスト同輩ホスト
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
(超能力_インフォメーション、ロケータ、SEQ[ディフィー_ヘルマン])をアップデートしてください。----------------------------------->アップデート(超能力_インフォメーション、SEQ、ACKは_要求を反映します[ディフィー_ヘルマン])<。----------------------------------- (ACK、エコー_応答)をアップデートしてください。----------------------------------->。
Figure 5: Basic Multihoming Scenario
図5: 基本的なマルチホーミングシナリオ
In multihoming scenarios, it is important that hosts receiving UPDATEs associate them correctly with the destination address used in the packet carrying the UPDATE. When processing inbound LOCATORs that establish new security associations on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR as the local address to which the LOCATOR plus ESP_INFO is targeted. This is because hosts may send UPDATEs with the same (locator) IP address to different peer addresses -- this has the effect of creating multiple inbound SAs implicitly affiliated with different peer source addresses.
マルチホーミングシナリオでは、UPDATEsを受け取るホストがUPDATEを運びながら正しくパケットで使用される送付先アドレスに彼らを関連づけるのは、重要です。 複数のアドレスとのインタフェースに新しいセキュリティ協会を設立する本国行きのLOCATORsを処理するとき、ホストはLOCATORプラス超能力_INFOが狙うローカルアドレスとしてLOCATORを含むUPDATEの送付先アドレスを使用します。 これはホストが同じ(ロケータ)IPアドレスがあるUPDATEsを異なった同輩アドレスに送るかもしれないからです--これで、それとなく複数の本国行きのSAsを作成するという効果に異なった同輩ソースアドレスに加わります。
3.2.4. Site Multihoming
3.2.4. サイトマルチホーミング
A host may have an interface that has multiple globally routable IP addresses. Such a situation may be a result of the site having multiple upper Internet Service Providers, or just because the site provides all hosts with both IPv4 and IPv6 addresses. The host should stay reachable at all or any subset of the currently available global routable addresses, independent of how they are provided.
ホストには、複数のグローバルに発送可能なIPアドレスを持っているインタフェースがあるかもしれません。 そのような状況は、サイトには複数の上側のインターネットサービスプロバイダがある結果であるかサイトがIPv4とIPv6アドレスの両方をすべてのホストに提供するので、まさしく結果であるかもしれません。 ホストは現在利用可能なグローバルな発送可能アドレスのすべてかどんな部分集合でも届くままであるべきです、どうそれらを提供するかの如何にかかわらず。
This case is handled the same as if there were different IP addresses, described above in Section 3.2.3. Note that a single interface may experience site multihoming while the host itself may have multiple interfaces.
まるで上でセクション3.2.3で説明された異なったIPアドレスがあるかのように本件は同じように扱われます。 ホスト自身には複数のインタフェースがあるかもしれない間単一のインタフェースがサイトマルチホーミングを経験するかもしれないことに注意してください。
Note that a host may be multihomed and mobile simultaneously, and that a multihomed host may want to protect the location of some of its interfaces while revealing the real IP address of some others.
ホスト同時に、「マルチ-家へ帰」ってモバイルであるかもしれなく、「マルチ-家へ帰」っているホストが何人かの他のものの本当のIPアドレスを明らかにしている間インタフェースのいくつかの位置を保護したがっているかもしれないことに注意してください。
This document does not presently specify additional site multihoming extensions to HIP; further alignment with the IETF shim6 working group may be considered in the future.
このドキュメントは現在、追加サイトマルチホーミング拡大をHIPに指定しません。 IETF shim6ワーキンググループとのさらなる整列は将来、考えられるかもしれません。
Nikander, et al. Experimental [Page 13] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[13ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
3.2.5. Dual host multihoming
3.2.5. 二元的なホストマルチホーミング
Consider the case in which both hosts would like to add an additional address after the base exchange completes. In Figure 6, consider that host1, which used address addr1a in the base exchange to set up SPI1a and SPI2a, wants to add address addr1b. It would send an UPDATE with LOCATOR (containing the address addr1b) to host2, using destination address addr2a, and a new set of SPIs would be added between hosts 1 and 2 (call them SPI1b and SPI2b -- not shown in the figure). Next, consider host2 deciding to add addr2b to the relationship. Host2 must select one of host1's addresses towards which to initiate an UPDATE. It may choose to initiate an UPDATE to addr1a, addr1b, or both. If it chooses to send to both, then a full mesh (four SA pairs) of SAs would exist between the two hosts. This is the most general case; it often may be the case that hosts primarily establish new SAs only with the peer's Preferred locator. The readdressing protocol is flexible enough to accommodate this choice.
両方のホストが交換が完成するベースの後に追加アドレスを加えたがっている場合を考えてください。 図6では、host1(SPI1aとSPI2aをセットアップするのに塩基置換にアドレスaddr1aを使用した)がアドレスaddr1bを加えたがっていると考えてください。 それはhost2へのLOCATOR(アドレスaddr1bを含んでいる)とUPDATE、使用の目的地アドレスaddr2aを送るでしょう、そして、SPIsの新しいセットはホスト1と2の間で加えられるでしょう(彼らをSPI1bとSPI2b--図で目立たないと呼んでください)。 次に、関係にaddr2bを加えると決めるhost2を考えてください。 Host2はUPDATEを開始するhost1のアドレスの1つを選択しなければなりません。 それは、addr1a、addr1b、または両方にUPDATEを開始するのを選ぶかもしれません。 両方に発信するのを選ぶなら、SAsの完全なメッシュ(4SA組)は2人のホストの間に存在しているでしょう。 これは最も一般的なそうです。 しばしばホストが単に同輩のPreferredロケータで主として新しいSAsを設立するのは、事実であるかもしれません。 あて名を書き直すプロトコルはこの選択に対応するほどフレキシブルです。
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
-<SPI1a----SPI2a->host1、<>addr1a<。--->addr2a<>host2>-SPI2a----SPI1a-<、-
addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair)
addr1b<。--->addr2a(2番目のSA組)addr1a<。--->addr2b(3番目のSA組)addr1b<。--->addr2b(4番目のSA組)
Figure 6: Dual Multihoming Case in Which Each Host Uses LOCATOR to
Add a Second Address
図6: 各ホストが第2のアドレスを加えるのにロケータを使用する二元的なマルチホーミング場合
3.2.6. Combined Mobility and Multihoming
3.2.6. 結合した移動性とマルチホーミング
It looks likely that in the future, many mobile hosts will be simultaneously mobile and multihomed, i.e., have multiple mobile interfaces. Furthermore, if the interfaces use different access technologies, it is fairly likely that one of the interfaces may appear stable (retain its current IP address) while some other(s) may experience mobility (undergo IP address change).
多くのモバイルホストが将来、同時にモバイルで「マルチ-家へ帰」られそうであって、すなわち、複数のモバイルインタフェースを持ってください。 その上、インタフェースが異なったアクセス技術を使用するなら、ある他の(s)は移動性(IPアドレス変化をする)を経験するかもしれませんが、インタフェースの1つは安定しているようにかなり見えそうです(現在のIPアドレスを保有してください)。
The use of LOCATOR plus ESP_INFO should be flexible enough to handle most such scenarios, although more complicated scenarios have not been studied so far.
LOCATORと超能力_INFOの使用はそのようなほとんどのシナリオを扱うほどフレキシブルであるべきです、より複雑なシナリオが今までのところ、研究されていませんが。
3.2.7. Using LOCATORs across Addressing Realms
3.2.7. 分野に演説することの向こう側にロケータを使用します。
It is possible for HIP associations to migrate to a state in which both parties are only using locators in different addressing realms. For example, the two hosts may initiate the HIP association when both
どの双方に状態にわたるか協会は異なったアドレシング分野でロケータを使用しているだけです。HIPにおいて、両方であるときに、例えば、2人のホストがHIP協会を開始するのは、可能です。
Nikander, et al. Experimental [Page 14] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[14ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
are using IPv6 locators, then one host may loose its IPv6 connectivity and obtain an IPv4 address. In such a case, some type of mechanism for interworking between the different realms must be employed; such techniques are outside the scope of the present text. The basic problem in this example is that the host readdressing to IPv4 does not know a corresponding IPv4 address of the peer. This may be handled (experimentally) by possibly configuring this address information manually or in the DNS, or the hosts exchange both IPv4 and IPv6 addresses in the locator.
IPv6を使用するのが、ロケータであり、次に、1人のホストが、IPv6の接続性を発射して、IPv4アドレスを得るかもしれません。 このような場合には、異なった分野の間の織り込むタイプのメカニズムを使わなければなりません。 現在のテキストの範囲の外にそのようなテクニックがあります。 この例の基本的問題はIPv4へのホストのあて名を書き直すのが同輩の対応するIPv4アドレスを知らないということです。 これがことによると手動でこのアドレス情報を構成する近く、または、DNSで(実験的に)扱われるかもしれませんか、またはホストはロケータでIPv4とIPv6アドレスの両方を交換します。
3.2.8. Network Renumbering
3.2.8. ネットワークの番号を付け替えること
It is expected that IPv6 networks will be renumbered much more often than most IPv4 networks. From an end-host point of view, network renumbering is similar to mobility.
IPv6ネットワークがほとんどのIPv4ネットワークよりはるかにしばしば番号を付け替えられると予想されます。 終わりホスト観点から、ネットワークの番号を付け替えるのは移動性と同様です。
3.2.9. Initiating the Protocol in R1 or I2
3.2.9. R1かI2のプロトコルを開始します。
A Responder host MAY include a LOCATOR parameter in the R1 packet that it sends to the Initiator. This parameter MUST be protected by the R1 signature. If the R1 packet contains LOCATOR parameters with a new Preferred locator, the Initiator SHOULD directly set the new Preferred locator to status ACTIVE without performing address verification first, and MUST send the I2 packet to the new Preferred locator. The I1 destination address and the new Preferred locator may be identical. All new non-preferred locators must still undergo address verification once the base exchange completes.
ResponderホストはそれがInitiatorに送るR1パケットでLOCATORパラメタを入れるかもしれません。 R1署名でこのパラメタを保護しなければなりません。 R1パケットが新しいPreferredロケータがあるLOCATORパラメタを含んでいるなら、Initiator SHOULDは直接最初にアドレス検査を実行しないで新しいPreferredロケータを状態ACTIVEに設定して、新しいPreferredロケータにI2パケットを送らなければなりません。 I1送付先アドレスと新しいPreferredロケータは同じであるかもしれません。 新しい非都合のよいロケータがまだ受けなければならないすべてが、かつて検証が交換が完成するベースであると扱います。
Initiator Responder
創始者応答者
R1 with LOCATOR
<-----------------------------------
record additional addresses
change responder address
I2 sent to newly indicated preferred address
----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally, later verification of non-preferred locators)
ロケータ<とR1----------------------------------- 変化応答者アドレスI2が新たに示された都合のよいアドレスに送った追加アドレスを記録してください。----------------------------------->(通常、処理する)R2<。----------------------------------- (通常非都合のよいロケータの後の検証を処理します)
Figure 7: LOCATOR Inclusion in R1
図7: R1でのロケータ包含
An Initiator MAY include one or more LOCATOR parameters in the I2 packet, independent of whether or not there was a LOCATOR parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR parameters, the Responder MUST still send the R2 packet to the source address of the I2. The new
InitiatorはI2パケットの1つ以上のLOCATORパラメタを含むかもしれません、LOCATORパラメタがR1にあったかどうかの如何にかかわらず。 I2署名でこれらのパラメタを保護しなければなりません。 I2パケットがLOCATORパラメタを含んでも、ResponderはまだR2パケットをI2のソースアドレスに送らなければなりません。 新しさ
Nikander, et al. Experimental [Page 15] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[15ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
Preferred locator SHOULD be identical to the I2 source address. If the I2 packet contains LOCATOR parameters, all new locators must undergo address verification as usual, and the ESP traffic that subsequently follows should use the Preferred locator.
ロケータSHOULDが好んだ、I2ソースアドレスと同じにしてください。 I2パケットがLOCATORパラメタを含んでいるなら、すべての新しいロケータが通常通りのアドレス検査を受けなければなりません、そして、次に続く超能力トラフィックはPreferredロケータを使用するべきです。
Initiator Responder
創始者応答者
I2 with LOCATOR
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)
ロケータがあるI2-----------------------------------R2がI2<のソースアドレスに送った>(通常、処理する)の記録的な追加アドレス----------------------------------- (通常、処理します)
Figure 8: LOCATOR Inclusion in I2
エイト環: I2でのロケータ包含
The I1 and I2 may be arriving from different source addresses if the LOCATOR parameter is present in R1. In this case, implementations simultaneously using multiple pre-created R1s, indexed by Initiator IP addresses, may inadvertently fail the puzzle solution of I2 packets due to a perceived puzzle mismatch. See, for instance, the example in Appendix A of [RFC5201]. As a solution, the Responder's puzzle indexing mechanism must be flexible enough to accommodate the situation when R1 includes a LOCATOR parameter.
LOCATORパラメタがR1に存在しているなら、I1とI2は異なったソースアドレスから到着しているかもしれません。 この場合、同時にInitiator IPアドレスによって索引をつけられた複数のあらかじめ作成されたR1sを使用する実装は知覚されたパズルミスマッチのためうっかりI2パケットのパズル溶液に失敗するかもしれません。 例えば、[RFC5201]のAppendix Aの例を見てください。 R1がLOCATORパラメタを含んでいるとき、ソリューションとして、Responderのパズルインデックスメカニズムは状況を収容するほどフレキシブルでなければなりません。
3.3. Other Considerations
3.3. 他の問題
3.3.1. Address Verification
3.3.1. アドレス検査
When a HIP host receives a set of locators from another HIP host in a LOCATOR, it does not necessarily know whether the other host is actually reachable at the claimed addresses. In fact, a malicious peer host may be intentionally giving bogus addresses in order to cause a packet flood towards the target addresses [RFC4225]. Likewise, viral software may have compromised the peer host, programming it to redirect packets to the target addresses. Thus, the HIP host must first check that the peer is reachable at the new address.
HIPホストがLOCATORの別のHIPホストから1セットのロケータを受けるとき、それは、もう片方のホストに実際に要求されたアドレスで届いているかどうかを必ず知っているというわけではありません。 事実上、悪意がある同輩ホストは、あて先アドレス[RFC4225]に向かってパケット洪水を引き起こすために故意ににせのアドレスを与えているかもしれません。 同様に、あて先アドレスにパケットを向け直すようにそれにプログラムして、ウイルス性のソフトウェアは同輩ホストに感染したかもしれません。 したがって、HIPホストは、最初に、同輩に新しいアドレスで届いているのをチェックしなければなりません。
An additional potential benefit of performing address verification is to allow middleboxes in the network along the new path to obtain the peer host's inbound SPI.
アドレス検査を実行する追加潜在的利益は新しい経路に沿ったネットワークにおけるmiddleboxesが同輩ホストの本国行きのSPIを入手するのを許容することです。
Address verification is implemented by the challenger sending some piece of unguessable information to the new address, and waiting for some acknowledgment from the Responder that indicates reception of the information at the new address. This may include the exchange of
アドレス検査は何らかの「蹄-可能」情報を新しいアドレスに送って、新しいアドレスで情報のレセプションを示すResponderから何らかの承認を待っている挑戦者によって実装されます。 これは交換を含むかもしれません。
Nikander, et al. Experimental [Page 16] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[16ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
a nonce, or the generation of a new SPI and observation of data arriving on the new SPI.
一回だけか、新しいSPIの世代と新しいSPIで到着するデータの観測。
3.3.2. Credit-Based Authorization
3.3.2. クレジットベースの承認
Credit-Based Authorization (CBA) allows a host to securely use a new locator even though the peer's reachability at the address embedded in the locator has not yet been verified. This is accomplished based on the following three hypotheses:
ロケータに埋め込まれたアドレスの同輩の可到達性はまだ確かめられていませんが、ベースのクレジットAuthorization(CBA)はホストに新しいロケータをしっかりと使用させます。 これは以下の3つの仮説に基づいて達成されます:
1. A flooding attacker typically seeks to somehow multiply the
packets it generates for the purpose of its attack because
bandwidth is an ample resource for many victims.
1. 帯域幅が多くの犠牲者への十分なリソースであるので、氾濫攻撃者はどうにかそれが攻撃の目的のために生成するパケットを通常掛けようとします。
2. An attacker can often cause unamplified flooding by sending
packets to its victim, either by directly addressing the victim
in the packets, or by guiding the packets along a specific path
by means of an IPv6 Routing header, if Routing headers are not
filtered by firewalls.
2. 攻撃者はパケットを犠牲者に送るか、パケットで直接犠牲者に演説するか、またはIPv6ルート設定ヘッダーによって特定の経路に沿ってパケットを動かすことによって、非増幅された氾濫をしばしば引き起こす場合があります、ルート設定ヘッダーがファイアウォールによってフィルターにかけられないなら。
3. Consequently, the additional effort required to set up a
redirection-based flooding attack (without CBA and return
routability checks) would pay off for the attacker only if
amplification could be obtained this way.
3. その結果、この道に増幅を得ることができる場合にだけ、リダイレクションベースのフラッディング攻撃(CBAとリターンroutabilityチェックのない)をセットアップするのに必要である追加取り組みは攻撃者にうまく行くでしょうに。
On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents amplifications. This is accomplished by limiting the data a host can send to an unverified address of a peer by the data recently received from that peer. Redirection-based flooding attacks thus become less attractive than, for example, pure direct flooding, where the attacker itself sends bogus packets to the victim.
第一に悪意があるパケットリダイレクションを排除するよりむしろこのベースでは、ベースのCredit Authorizationは補足説明を防ぎます。 これは、最近その同輩から受け取られたデータでホストが送ることができるデータを同輩の非検証されたアドレスに制限することによって、達成されます。 その結果、リダイレクションベースのフラッディング攻撃は例えば、純粋なダイレクト氾濫ほど魅力的でなくなります、攻撃者自身がにせのパケットを犠牲者に送るところで。
Figure 9 illustrates Credit-Based Authorization: Host B measures the amount of data recently received from peer A and, when A readdresses, sends packets to A's new, unverified address as long as the sum of the packet sizes does not exceed the measured, received data volume. When insufficient credit is left, B stops sending further packets to A until A's address becomes ACTIVE. The address changes may be due to mobility, multihoming, or any other reason. Not shown in Figure 9 are the results of credit aging (Section 5.6.2), a mechanism used to dampen possible time-shifting attacks.
図9はベースのCredit Authorizationを例証します: そして、ホストBが最近同輩Aから受け取られたデータ量を測定する、Aがあて名を書き直させるいつ、パケットサイズの合計が測定(受信データボリューム)を超えていない限り、Aの新しくて、非検証されたアドレスにパケットを送るか。 不十分なクレジットがそうときに、左では、AのアドレスがACTIVEになるまで、Bは、一層のパケットをAに送るのを止めます。 アドレス変化は移動性、マルチホーミング、またはいかなる他の理由のためであるかもしれません。 図9に示されていないのは、クレジットが年をとるという結果(セクション5.6.2)(可能なタイム・シフト攻撃を湿らせるのに使用されるメカニズム)です。
Nikander, et al. Experimental [Page 17] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[17ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
+-------+ +-------+
| A | | B |
+-------+ +-------+
| |
address |------------------------------->| credit += size(packet)
ACTIVE | |
|------------------------------->| credit += size(packet)
|<-------------------------------| do not change credit
| |
+ address change |
+ address verification starts |
address |<-------------------------------| credit -= size(packet)
UNVERIFIED |------------------------------->| credit += size(packet)
|<-------------------------------| credit -= size(packet)
| |
|<-------------------------------| credit -= size(packet)
| X credit < size(packet)
| | => do not send packet!
+ address verification concludes |
address | |
ACTIVE |<-------------------------------| do not change credit
| |
+-------+ +-------+ | A| | B| +-------+ +-------+ | | アドレス|------------------------------->| クレジット+=サイズ(パケット)ACTIVE| | |------------------------------->| クレジット+=サイズ(パケット)|<-------------------------------| クレジットを変えないでください。| | + アドレス変化| +アドレス検査始め| アドレス|<-------------------------------| クレジット-=サイズ(パケット)UNVERIFIED|------------------------------->| クレジット+=サイズ(パケット)|<-------------------------------| クレジット-=サイズ(パケット)| | |<-------------------------------| クレジット-=サイズ(パケット)| Xクレジット<サイズ(パケット)| | =>はパケットを送りません! + 検証が終える演説| アドレス| | アクティブ|<-------------------------------| クレジットを変えないでください。| |
Figure 9: Readdressing Scenario
図9: シナリオにあて名を書き直させます。
3.3.3. Preferred Locator
3.3.3. 都合のよいロケータ
When a host has multiple locators, the peer host must decide which to use for outbound packets. It may be that a host would prefer to receive data on a particular inbound interface. HIP allows a particular locator to be designated as a Preferred locator and communicated to the peer (see Section 4).
ホストが複数のロケータを持っているとき、同輩ホストは、外国行きのパケットにどれを使用したらよいかを決めなければなりません。 多分、ホストは、特定の本国行きのインタフェースに関するデータを受け取るのを好むでしょう。 HIPは、特定のロケータがPreferredロケータとして指定されて、同輩に伝えられるのを許容します(セクション4を見てください)。
In general, when multiple locators are used for a session, there is the question of using multiple locators for failover only or for load-balancing. Due to the implications of load-balancing on the transport layer that still need to be worked out, this document assumes that multiple locators are used primarily for failover. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator.
複数のロケータがセッションに使用されるとき、一般に、フェイルオーバーだけかロードバランシングに複数のロケータを使用する問題があります。 まだ解決される必要があるトランスポート層の負荷分散の含意のため、このドキュメントは、複数のロケータが主としてフェイルオーバーに使用されると仮定します。実装はICMP相互作用、可到達性チェック、またはロケータの失敗を検出する他の手段を使用するかもしれません。
3.3.4. Interaction with Security Associations
3.3.4. セキュリティ関係との相互作用
This document specifies a new HIP protocol parameter, the LOCATOR parameter (see Section 4), that allows the hosts to exchange information about their locator(s) and any changes in their locator(s). The logical structure created with LOCATOR parameters
このドキュメントは新しいHIPプロトコルパラメタ、ホストが彼らのロケータとそれらのロケータにおけるどんな変化に関しても情報交換できるLOCATORパラメタ(セクション4を見る)を指定します。 LOCATORパラメタで作成された論理構造
Nikander, et al. Experimental [Page 18] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[18ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
has three levels: hosts, Security Associations (SAs) indexed by Security Parameter Indices (SPIs), and addresses.
3つのレベルを持っています: ホスト、Security Associations(SAs)はSecurity Parameter Indices(SPIs)、およびアドレスで索引をつけました。
The relation between these levels for an association constructed as defined in the base specification [RFC5201] and ESP transform [RFC5202] is illustrated in Figure 10.
[RFC5201]と超能力が変える基礎仕様[RFC5202]に基づき定義されるように組み立てられた協会のためのこれらのレベルの関係は図10で例証されます。
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
-<SPI1a----SPI2a->host1、<>addr1a<。--->addr2a<>host2>-SPI2a----SPI1a-<、-
Figure 10: Relation between Hosts, SPIs,
and Addresses (Base Specification)
図10: ホスト(SPIs)とアドレスとの関係(基礎仕様)
In Figure 10, host1 and host2 negotiate two unidirectional SAs, and each host selects the SPI value for its inbound SA. The addresses addr1a and addr2a are the source addresses that the hosts use in the base HIP exchange. These are the "preferred" (and only) addresses conveyed to the peer for use on each SA. That is, although packets sent to any of the hosts' interfaces may be accepted on the inbound SA, the peer host in general knows of only the single destination address learned in the base exchange (e.g., for host1, it sends a packet on SPI2a to addr2a to reach host2), unless other mechanisms exist to learn of new addresses.
図10では、host1とhost2は2単方向SAsを交渉します、そして、各ホストは本国行きのSAのためにSPI値を選択します。 アドレスのaddr1aとaddr2aはホストがベースHIP交換に使用するソースアドレスです。 これらは各SAにおける使用のために同輩に伝えられた「都合のよい」(単に)アドレスです。 すなわち、本国行きのSAでホストのインタフェースのいずれにも送られたパケットを受け入れるかもしれませんが、一般に、同輩ホストは塩基置換で学習されたただ一つの送付先アドレスだけを知っています(例えば、host1に関して、それはhost2に達するようにSPI2aの上のパケットをaddr2aに送ります)、他のメカニズムが新しいアドレスを知るために存在していないなら。
In general, the bindings that exist in an implementation corresponding to this document can be depicted as shown in Figure 11. In this figure, a host can have multiple inbound SPIs (and, not shown, multiple outbound SPIs) associated with another host. Furthermore, each SPI may have multiple addresses associated with it. These addresses that are bound to an SPI are not used to lookup the incoming SA. Rather, the addresses are those that are provided to the peer host, as hints for which addresses to use to reach the host on that SPI. The LOCATOR parameter is used to change the set of addresses that a peer associates with a particular SPI.
一般に、図11に示されるようにこのドキュメントに対応する実現で存在する結合について表現できます。 この図では、ホストは別のホストに関連している複数の本国行きのSPIs(そして、複数の外国行きのSPIs示されないで、)を持つことができます。 その上、各SPIには、それに関連している複数のアドレスがあるかもしれません。 SPIへのバウンドがあるということであるこれらのアドレスは入って来るSAをルックアップに使用しませんでした。 むしろ、アドレスは同輩ホストに提供されるものです、どのアドレスがそのSPIの上のホストに届くのに使用するヒントとして。 LOCATORパラメタは、同輩が特定のSPIに関連づけるアドレスのセットを変えるのに使用されます。
Nikander, et al. Experimental [Page 19] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[19ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
address11
/
SPI1 - address12
/
/ address21
host -- SPI2 <
\ address22
\
SPI3 - address31
\
address32
address11 / SPI1--address12 / / address21ホスト--SPI2<\address22\SPI3--address31\address32
Figure 11: Relation between Hosts, SPIs, and Addresses (General Case)
図11: ホスト(SPIs)とアドレスとの関係(一般ケース)
A host may establish any number of security associations (or SPIs) with a peer. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing. For example, if the host needs to change its addresses on SPI2, it is likely that both address21 and address22 will simultaneously become obsolete. In a typical case, such SPIs may correspond with physical interfaces; see below. Note, however, that especially in the case of site multihoming, one of the addresses may become unreachable while the other one still works. In the typical case, however, this does not require the host to inform its peers about the situation, since even the non-working address still logically exists.
ホストは同輩とのいろいろなセキュリティ仲間(または、SPIs)を設立するかもしれません。 同輩がいる複数のSPIsを持つ主な目的はアドレスを運命共有を経験しそうな収集に分類することです。 例えば、ホストが、SPI2で住所を変更する必要があると、address21とaddress22の両方が同時に、時代遅れになりそうでしょう。 典型的な場合では、そのようなSPIsは物理インターフェースに対応するかもしれません。 以下を見てください。 注意、しかしながら、もう片方である間、特にサイトマルチホーミングの場合では、アドレスの1つが手が届かなくなるかもしれないのはまだ働いています。 しかしながら、典型的な場合では、これは、ホストが状況に関して同輩に知らせるのを必要としません、非働くアドレスさえまだ論理的に存在しているので。
A basic property of HIP SAs is that the inbound IP address is not used to lookup the incoming SA. Therefore, in Figure 11, it may seem unnecessary for address31, for example, to be associated only with SPI3 -- in practice, a packet may arrive to SPI1 via destination address address31 as well. However, the use of different source and destination addresses typically leads to different paths, with different latencies in the network, and if packets were to arrive via an arbitrary destination IP address (or path) for a given SPI, the reordering due to different latencies may cause some packets to fall outside of the ESP anti-replay window. For this reason, HIP provides a mechanism to affiliate destination addresses with inbound SPIs, when there is a concern that anti-replay windows might be violated. In this sense, we can say that a given inbound SPI has an "affinity" for certain inbound IP addresses, and this affinity is communicated to the peer host. Each physical interface SHOULD have a separate SA, unless the ESP anti-replay window is loose.
HIP SAsの基礎特性は本国行きのIPアドレスがそうであるということです。入って来るSAをルックアップに使用しませんでした。 したがって、例えば、図11では、SPI3だけに関連しているようにaddress31に不要に思えるかもしれません--実際には、パケットはまた、送付先アドレスaddress31を通してSPI1に到着するかもしれません。 しかしながら、異なったソースと送付先アドレスの使用はネットワークで異なった潜在がある異なった経路に通常つながります、そして、与えられたSPIのための任意の送付先IPアドレス(または、経路)でパケットが到着するつもりであったなら、異なった潜在への再命令支払われるべきもので、いくつかのパケットが超能力反再生ウィンドウの外に落ちるかもしれません。 この理由で、HIPは送付先アドレスに本国行きのSPIsに加わるためにメカニズムを提供します、反再生ウィンドウが違反されるかもしれないという関心があるとき。 この意味で、私たちは、与えられた本国行きのSPIには、ある本国行きのIPアドレスのための「親近感」があると言うことができます、そして、この親近感は同輩ホストに伝えられます。 各物理インターフェースSHOULDには、超能力反再生ウィンドウがゆるくない場合、別々のSAがあります。
Moreover, even when the destination addresses used for a particular SPI are held constant, the use of different source interfaces may also cause packets to fall outside of the ESP anti-replay window, since the path traversed is often affected by the source address or
またはそのうえ、また、特定のSPIに使用される送付先アドレスが一定であるとして保持さえされるとき、異なったソースのインタフェースの使用で、パケットは超能力反再生ウィンドウの外に落ちるかもしれません、横断された経路がしばしばソースアドレスで影響を受けるので。
Nikander, et al. Experimental [Page 20] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[20ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
interface used. A host has no way to influence the source interface on which a peer sends its packets on a given SPI. A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI. For this reason, a host may find it useful to change its SPI or at least reset its ESP anti-replay window when the peer host readdresses.
使用されていた状態で、連結してください。 ホストには、同輩が与えられたSPIにパケットを送るソースのインタフェースに影響を及ぼす方法が全くありません。 特定の送付先IPアドレスとSPIに発信するとき、ホストSHOULDは一貫して同じソースのインタフェースとアドレスを使用します。 この理由で、同輩ホストであるときに、ホストは、SPIを変えるのが役に立つのがわかるか、または超能力反再生ウィンドウを少なくともリセットするかもしれません。あて名を書き直します。
An address may appear on more than one SPI. This creates no ambiguity since the receiver will ignore the IP addresses during SA lookup anyway. However, this document does not specify such cases.
アドレスは1SPIに現れるかもしれません。 受信機がSAルックアップの間、とにかくIPアドレスを無視するので、これはあいまいさを全く作成しません。 しかしながら、このドキュメントはそのような場合を指定しません。
When the LOCATOR parameter is sent in an UPDATE packet, then the receiver will respond with an UPDATE acknowledgment. When the LOCATOR parameter is sent in an R1 or I2 packet, the base exchange retransmission mechanism will confirm its successful delivery. LOCATORs may experimentally be used in NOTIFY packets; in this case, the recipient MUST consider the LOCATOR as informational and not immediately change the current preferred address, but can test the additional locators when the need arises. The use of the LOCATOR in a NOTIFY message may not be compatible with middleboxes.
UPDATEパケットでLOCATORパラメタを送ると、受信機はUPDATE承認で応じるでしょう。 R1かI2パケットでLOCATORパラメタを送るとき、塩基置換「再-トランスミッション」メカニズムはうまくいっている配送を確認するでしょう。 LOCATORsはNOTIFYパケットで実験的に使用されるかもしれません。 この場合、受取人は、LOCATORが情報であるとみなして、すぐに現在の都合のよいアドレスを変えてはいけませんが、必要性が起こると、追加ロケータを検査できます。 NOTIFYメッセージにおけるLOCATORの使用はmiddleboxesと互換性がないかもしれません。
4. LOCATOR Parameter Format
4. ロケータパラメタ形式
The LOCATOR parameter is a critical parameter as defined by [RFC5201]. It consists of the standard HIP parameter Type and Length fields, plus zero or more Locator sub-parameters. Each Locator sub- parameter contains a Traffic Type, Locator Type, Locator Length, Preferred locator bit, Locator Lifetime, and a Locator encoding. A LOCATOR containing zero Locator fields is permitted but has the effect of deprecating all addresses.
[RFC5201]によって定義されるようにLOCATORパラメタは臨界パラメータです。 それは標準のHIPパラメタTypeとLength分野か、プラスゼロか、より多くのLocatorサブパラメタから成ります。 それぞれのLocatorサブパラメタはTraffic Type、Locator Type、Locator Length、Preferredロケータビット、Locator Lifetime、およびLocatorコード化を含んでいます。 Locator分野を全く含まないLOCATORは受入れられますが、すべてのアドレスを非難するという効果を持っています。
Nikander, et al. Experimental [Page 21] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[21ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 交通タイプ| ロケータタイプ| ロケータの長さ| 予約されます。|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ロケータ生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ロケータ| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 交通タイプ| ロケータタイプ| ロケータの長さ| 予約されます。|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ロケータ生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ロケータ| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: LOCATOR Parameter Format
図12: ロケータパラメタ形式
Type: 193
以下をタイプしてください。 193
Length: Length in octets, excluding Type and Length fields, and
excluding padding.
長さ: 八重奏、TypeとLength分野を除いた詰め物およびを除いた長さ。
Traffic Type: Defines whether the locator pertains to HIP signaling,
user data, or both.
交通タイプ: ロケータがHIPシグナリング、利用者データ、または両方に関するか否かに関係なく、定義します。
Locator Type: Defines the semantics of the Locator field.
ロケータタイプ: Locator分野の意味論を定義します。
Locator Length: Defines the length of the Locator field, in units of
4-byte words (Locators up to a maximum of 4*255 octets are
supported).
ロケータの長さ: ユニットの4バイトの単語(ロケータ最大最大4*255八重奏は支持される)でLocator分野の長さを定義します。
Reserved: Zero when sent, ignored when received.
予約される: 受け取ると無視して、送ると、ゼロに合わせます。
Nikander, et al. Experimental [Page 22] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[22ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
P: Preferred locator. Set to one if the locator is preferred for
that Traffic Type; otherwise, set to zero.
P: 都合のよいロケータ。 ロケータがそのTraffic Typeのために好まれるなら、1つにセットしてください。 さもなければ、ゼロにセットしてください。
Locator Lifetime: Locator lifetime, in seconds.
ロケータ生涯: 秒のロケータ生涯。
Locator: The locator whose semantics and encoding are indicated by
the Locator Type field. All Locator sub-fields are integral
multiples of four octets in length.
ロケータ: 意味論とコード化がLocator Type分野によって示されるロケータ。 すべてのLocatorサブ分野が長さが4つの八重奏の整数倍です。
The Locator Lifetime indicates how long the following locator is expected to be valid. The lifetime is expressed in seconds. Each locator MUST have a non-zero lifetime. The address is expected to become deprecated when the specified number of seconds has passed since the reception of the message. A deprecated address SHOULD NOT be used as a destination address if an alternate (non-deprecated) is available and has sufficient scope.
Locator Lifetimeは、どれくらい長い間以下のロケータが有効であると予想されるかを示します。 寿命は秒に言い表されます。 各ロケータには、非ゼロ寿命がなければなりません。 メッセージのレセプション以来秒の指定された数が終わっているとき、アドレスが推奨しなくなると予想されます。 推奨しないアドレスSHOULD NOTは補欠(非推奨しない)が手があくなら送付先アドレスとして使用されて、十分な範囲を持っています。
4.1. Traffic Type and Preferred Locator
4.1. 交通タイプと都合のよいロケータ
The following Traffic Type values are defined:
以下のTraffic Type値は定義されます:
0: Both signaling (HIP control packets) and user data.
0: シグナリング(HIPコントロールパケット)と利用者データの両方。
1: Signaling packets only.
1: パケットだけに合図します。
2: Data packets only.
2: データ・パケット専用。
The "P" bit, when set, has scope over the corresponding Traffic Type. That is, when a "P" bit is set for Traffic Type "2", for example, it means that the locator is preferred for data packets. If there is a conflict (for example, if the "P" bit is set for an address of Type "0" and a different address of Type "2"), the more specific Traffic Type rule applies (in this case, "2"). By default, the IP addresses used in the base exchange are Preferred locators for both signaling and user data, unless a new Preferred locator supersedes them. If no locators are indicated as preferred for a given Traffic Type, the implementation may use an arbitrary locator from the set of active locators.
「P」ビットで、設定されると、対応する交通の上の範囲はタイプされます。 すなわち、「P」ビットが交通タイプに設定されるとき、「2インチに、例えば、データ・パケットのためにロケータが好まれることを意味します」。 闘争がある、(「P」ビットが例えばタイプのアドレスに設定される、「0インチとタイプの異なったアドレス、「2インチ)、 より特定の交通タイプ規則が適用される、(この場合、「2インチ)」 デフォルトで、塩基置換に使用されるIPアドレスはシグナリングと利用者データの両方のためのPreferredロケータです、新しいPreferredロケータがそれらに取って代わらない場合。 ロケータが全く与えられたTraffic Typeのために好まれるように示されないなら、実現はアクティブなロケータのセットから任意のロケータを使用するかもしれません。
4.2. Locator Type and Locator
4.2. ロケータタイプとロケータ
The following Locator Type values are defined, along with the associated semantics of the Locator field:
以下のLocator Type値はLocator分野の関連意味論と共に定義されます:
Nikander, et al. Experimental [Page 23] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[23ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291]
(128 bits long). This locator type is defined primarily for non-
ESP-based usage.
0: IPv6アドレスかIPv6のIPv4形式IPv4は[RFC4291](長さ128ビットの)を記述します。 このロケータタイプは主として超能力ベースの非用法のために定義されます。
1: The concatenation of an ESP SPI (first 32 bits) followed by an
IPv6 address or an IPv4-in-IPv6 format IPv4 address (an
additional 128 bits). This IP address is defined primarily for
ESP-based usage.
1: IPv6アドレスかIPv6のIPv4形式IPv4アドレス(追加128ビット)でESP SPI(最初に32ビット)の連結は続きました。 このIPアドレスは主として超能力ベースの用法のために定義されます。
4.3. UPDATE Packet with Included LOCATOR
4.3. 含まれているロケータでパケットをアップデートしてください。
A number of combinations of parameters in an UPDATE packet are possible (e.g., see Section 3.2). In this document, procedures are defined only for the case in which one LOCATOR and one ESP_INFO parameter is used in any HIP packet. Furthermore, the LOCATOR SHOULD list all of the locators that are active on the HIP association (including those on SAs not covered by the ESP_INFO parameter). Any UPDATE packet that includes a LOCATOR parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The relationship between the announced Locators and any ESP_INFO parameters present in the packet is defined in Section 5.2. The sending of multiple LOCATOR and/or ESP_INFO parameters is for further study; receivers may wish to experiment with supporting such a possibility.
UPDATEパケットのパラメタの多くの組み合わせが可能です(例えば、セクション3.2を見てください)。 本書では、手順はどんなHIPパケットでもLOCATORと1つの超能力_INFOパラメタがどれであるかで使用されるケースのためだけに定義されます。 その上、LOCATOR SHOULDはHIP協会(超能力_INFOパラメタで覆われなかったSAsの上のそれらを含んでいる)でアクティブなロケータのすべてを記載します。 LOCATORパラメタSHOULDを含んでいるどんなUPDATEパケットもHMACとHIP_SIGNATUREパラメタの両方を含んでいます。 パケットの現在の発表されたLocatorsとどんな超能力_INFOパラメタとの関係もセクション5.2で定義されます。 さらなる研究には複数のLOCATOR、そして/または、超能力_INFOパラメタの発信があります。 受信機はそのような可能性を支持するのに実験したがっているかもしれません。
5. Processing Rules
5. 処理規則
This section describes rules for sending and receiving the LOCATOR parameter, testing address reachability, and using Credit-Based Authorization (CBA) on UNVERIFIED locators.
このセクションはLOCATORパラメタを送って、受け取るための規則について説明します、アドレスの可到達性をテストして、UNVERIFIEDロケータの上でベースのCredit Authorization(CBA)を使用して。
5.1. Locator Data Structure and Status
5.1. ロケータデータ構造と状態
In a typical implementation, each outgoing locator is represented by a piece of state that contains the following data:
典型的な実現では、それぞれの出発しているロケータは以下のデータを含む1つの州によって表されます:
o the actual bit pattern representing the locator,
o ロケータを表す実際のビット・パターン
o the lifetime (seconds),
o 生涯(秒)
o the status (UNVERIFIED, ACTIVE, DEPRECATED),
o 状態(UNVERIFIED、ACTIVE、DEPRECATED)
o the Traffic Type scope of the locator, and
o そしてロケータのTraffic Type範囲。
o whether the locator is preferred for any particular scope.
o ロケータは何か特定の範囲として好まれるのであるかどうか
Nikander, et al. Experimental [Page 24] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[24ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
The status is used to track the reachability of the address embedded within the LOCATOR parameter:
状態はLOCATORパラメタの中で埋め込まれたアドレスの可到達性を追跡するのに使用されます:
UNVERIFIED indicates that the reachability of the address has not
been verified yet,
UNVERIFIEDは、アドレスの可到達性がまだ確かめられていないのを示します。
ACTIVE indicates that the reachability of the address has been
verified and the address has not been deprecated,
ACTIVEは、アドレスの可到達性が確かめられて、アドレスが非難されていないのを示します。
DEPRECATED indicates that the locator lifetime has expired.
DEPRECATEDは、ロケータ寿命が期限が切れたのを示します。
The following state changes are allowed:
以下の州の変化は許容されています:
UNVERIFIED to ACTIVE The reachability procedure completes
successfully.
UNVERIFIED、ACTIVEへの手順が首尾よく完成する可到達性。
UNVERIFIED to DEPRECATED The locator lifetime expires while the
locator is UNVERIFIED.
UNVERIFIED、DEPRECATEDに、ロケータはUNVERIFIEDですが、ロケータ寿命は期限が切れます。
ACTIVE to DEPRECATED The locator lifetime expires while the locator
is ACTIVE.
ACTIVE、DEPRECATEDに、ロケータはACTIVEですが、ロケータ寿命は期限が切れます。
ACTIVE to UNVERIFIED There has been no traffic on the address for
some time, and the local policy mandates that the address
reachability must be verified again before starting to use it
again.
しばらくUNVERIFIED ThereへのACTIVEは住所における交通ではありません、そして、ローカルの方針は再びそれを使用し始める前に再びアドレスの可到達性について確かめなければならないのを強制します。
DEPRECATED to UNVERIFIED The host receives a new lifetime for the
locator.
ホストのUNVERIFIEDへのDEPRECATEDはロケータのために新しい生涯を得ます。
A DEPRECATED address MUST NOT be changed to ACTIVE without first verifying its reachability.
最初に可到達性について確かめないで、DEPRECATEDアドレスはACTIVEに変わってはいけません。
Note that the state of whether or not a locator is preferred is not necessarily the same as the value of the Preferred bit in the Locator sub-parameter received from the peer. Peers may recommend certain locators to be preferred, but the decision on whether to actually use a locator as a preferred locator is a local decision, possibly influenced by local policy.
ロケータが好まれるかどうかに関する状態が必ず同輩から受け取られたLocatorサブパラメタのPreferredビットの価値と同じであるというわけではないことに注意してください。 同輩は、あるロケータが好まれることを勧めるかもしれませんが、実際に都合のよいロケータとしてロケータを使用するかどうかに関する決定はローカルの方針でことによると影響を及ぼされたローカルの決定です。
5.2. Sending LOCATORs
5.2. 送付ロケータ
The decision of when to send LOCATORs is basically a local policy issue. However, it is RECOMMENDED that a host send a LOCATOR whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. Rapidly sending LOCATORs that force the peer to change the preferred address SHOULD be avoided.
いつLOCATORsを送るかに関する決定は基本的にローカルの政策問題です。 しかしながら、活動的なHIP協会にIPアドレスの変化を使用中に認めて、変化が少なくとも数秒間続くと仮定するときはいつも、ホストがLOCATORを送るのは、RECOMMENDEDです。 急速に、同輩がやむを得ず都合のよいアドレスSHOULDを変えるLOCATORsを送って、避けられてください。
Nikander, et al. Experimental [Page 25] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[25ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
When a host decides to inform its peers about changes in its IP addresses, it has to decide how to group the various addresses with SPIs. The grouping should consider also whether middlebox interaction requires sending the same LOCATOR in separate UPDATEs on different paths. Since each SPI is associated with a different Security Association, the grouping policy may also be based on ESP anti-replay protection considerations. In the typical case, simply basing the grouping on actual kernel level physical and logical interfaces may be the best policy. Grouping policy is outside of the scope of this document.
ホストが、IPアドレスにおける変化に関して同輩に知らせると決めると、それはSPIsと共に様々なアドレスを分類する方法を決めなければなりません。 また、組分けは、middlebox相互作用が、異なった経路の別々のUPDATEsで同じLOCATORを送るのを必要とするかどうか考えるべきです。 それぞれのSPIが異なったSecurity Associationに関連しているので、また、組分け方針は超能力反反復操作による保護問題に基づくかもしれません。 典型的な場合では、単に組分けをカーネルの実際のレベル物理的で論理的なインタフェースに基礎づけるのは、最善の策であるかもしれません。 方針を分類するのがこのドキュメントの範囲の外にあります。
Note that the purpose of announcing IP addresses in a LOCATOR is to provide connectivity between the communicating hosts. In most cases, tunnels or virtual interfaces such as IPsec tunnel interfaces or Mobile IP home addresses provide sub-optimal connectivity. Furthermore, it should be possible to replace most tunnels with HIP based "non-tunneling", therefore making most virtual interfaces fairly unnecessary in the future. Therefore, virtual interfaces SHOULD NOT be announced in general. On the other hand, there are clearly situations where tunnels are used for diagnostic and/or testing purposes. In such and other similar cases announcing the IP addresses of virtual interfaces may be appropriate.
LOCATORのIPアドレスを発表する目的が交信しているホストの間に接続性を提供することであることに注意してください。 多くの場合、IPsecトンネルのインタフェースかモバイルIPホームアドレスなどのトンネルか仮想インターフェースがサブ最適の接続性を提供します。 その上、ほとんどのトンネルをHIPのベースの「非トンネリング」に取り替えるのは可能であるべきです、したがって、大部分将来かなり不要な仮想インターフェースにします。 したがって、仮想インターフェースSHOULD NOT、一般に、発表されてください。 他方では、明確に、状況がトンネルが病気の特徴に使用される、そして/または、目的をテストしているところにあります。 そのようなものと他の類例では、仮想インターフェースのIPアドレスを発表するのは適切であるかもしれません。
Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs. Link-local addresses MAY be announced to peers that are known to be neighbors on the same link, such as when the IP destination address of a peer is also link-local. The announcement of link-local addresses in this case is a policy decision; link-local addresses used as Preferred locators will create reachability problems when the host moves to another link. In any case, link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link.
ホストはLOCATORsで放送かマルチキャストアドレスを発表してはいけません。 リンクローカルのアドレスは同じリンクの上の隣人であることが知られている同輩に発表されるかもしれません、また同輩の受信者IPアドレスもリンクローカルである時のように。 この場合、リンクローカルのアドレスの発表は政策決定です。 ホストが別のものに移るとき、Preferredロケータが可到達性問題を生じさせるので使用されるリンクローカルのアドレスはリンクされます。 どのような場合でも、その同輩が同じリンクの上にいるのが知られない場合、リンクローカルのアドレスを同輩に発表してはいけません。
Once the host has decided on the groups and assignment of addresses to the SPIs, it creates a LOCATOR parameter that serves as a complete representation of the addresses and affiliated SPIs intended for active use. We now describe a few cases introduced in Section 3.2. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that separate the HIP control plane from data plane traffic). Other mobility and multihoming cases are possible but are left for further experimentation.
ホストがいったんアドレスのグループと課題をSPIsに決めると、それはアドレスと系列SPIsの完全表記が能動的使用のために意図したように役立つLOCATORパラメタを作成します。 私たちは現在、セクション3.2で紹介されたいくつかのケースについて説明します。 私たちは、各ロケータのためのTraffic Typeが「0インチ(交通タイプのための他の値はデータ空輸とクールな制御飛行機を切り離すドキュメントで指定されるかもしれない)」に用意ができていると思います。 他の移動性とマルチホーミングケースは、可能ですが、さらなる実験に残されます。
1. Host mobility with no multihoming and no rekeying. The mobile
host creates a single UPDATE containing a single ESP_INFO with a
single LOCATOR parameter. The ESP_INFO contains the current
value of the SPI in both the OLD SPI and NEW SPI fields. The
LOCATOR contains a single Locator with a "Locator Type" of "1";
1. マルチホーミングといいえが全く「再-合わせ」られていなく、移動性を接待してください。 モバイルホストはただ一つのLOCATORパラメタがある独身の超能力_INFOを含む独身のUPDATEを作成します。 超能力_INFOはOLD SPIとNEW SPI分野の両方のSPIの現行価値を含んでいます。 LOCATORは「1インチ」の「ロケータタイプ」がある独身のLocatorを含んでいます。
Nikander, et al. Experimental [Page 26] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[26ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
the SPI must match that of the ESP_INFO. The Preferred bit
SHOULD be set and the "Locator Lifetime" is set according to
local policy. The UPDATE also contains a SEQ parameter as usual.
This packet is retransmitted as defined in the HIP protocol
specification [RFC5201]. The UPDATE should be sent to the peer's
preferred IP address with an IP source address corresponding to
the address in the LOCATOR parameter.
SPIは_超能力INFOのものに合わなければなりません。 設定されて、PreferredはSHOULDに噛み付きました。ローカルの方針によると、「ロケータ生涯」は設定されます。 また、UPDATEは通常通りのSEQパラメタを含んでいます。 このパケットはHIPプロトコル仕様[RFC5201]に基づき定義されるように再送されます。 アドレスに対応するIPソースアドレスがLOCATORパラメタにある状態で、同輩の都合のよいIPアドレスにUPDATEを送るべきです。
2. Host mobility with no multihoming but with rekeying. The mobile
host creates a single UPDATE containing a single ESP_INFO with a
single LOCATOR parameter (with a single address). The ESP_INFO
contains the current value of the SPI in the OLD SPI and the new
value of the SPI in the NEW SPI, and a KEYMAT Index as selected
by local policy. Optionally, the host may choose to initiate a
Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter.
The LOCATOR contains a single Locator with "Locator Type" of "1";
the SPI must match that of the NEW SPI in the ESP_INFO.
Otherwise, the steps are identical to the case in which no
rekeying is initiated.
2. マルチホーミング、「再-合わせ」ることで移動性を接待してください。 モバイルホストはただ一つのLOCATORパラメタ(ただ一つのアドレスがある)がある独身の超能力_INFOを含む独身のUPDATEを作成します。 超能力_INFOはOLD SPIのSPIの現行価値とローカルの方針によって選択されるNEW SPI、およびKEYMAT IndexのSPIの新しい値を含んでいます。 任意に、ホストは、ディフィー_ヘルマンパラメタを含んでいることによってディフィーヘルマンrekeyを開始するのを選ぶかもしれません。 LOCATORは「1インチ」の「ロケータタイプ」がある独身のLocatorを含んでいます。 SPIは_超能力INFOでNEW SPIのものに合わなければなりません。 さもなければ、ステップは「再-合わせ」ないことが開始される場合と同じです。
3. Host multihoming (addition of an address). We only describe the
simple case of adding an additional address to a (previously)
single-homed, non-mobile host. The host SHOULD set up a new SA
pair between this new address and the preferred address of the
peer host. To do this, the multihomed host creates a new inbound
SA and creates a new SPI. For the outgoing UPDATE message, it
inserts an ESP_INFO parameter with an OLD SPI field of "0", a NEW
SPI field corresponding to the new SPI, and a KEYMAT Index as
selected by local policy. The host adds to the UPDATE message a
LOCATOR with two Type "1" Locators: the original address and SPI
active on the association, and the new address and new SPI being
added (with the SPI matching the NEW SPI contained in the
ESP_INFO). The Preferred bit SHOULD be set depending on the
policy to tell the peer host which of the two locators is
preferred. The UPDATE also contains a SEQ parameter and
optionally a DIFFIE_HELLMAN parameter, and follows rekeying
procedures with respect to this new address. The UPDATE message
SHOULD be sent to the peer's Preferred address with a source
address corresponding to the new locator.
3. マルチホーミング(アドレスの添加)をホスティングしてください。 非モバイルホスト、私たちはaへの追加アドレスが(以前に)シングル家へ帰ったと言い足す簡単なケースについて説明するだけです。 ホストSHOULDは同輩ホストのこの新しいアドレスと都合のよいアドレスの間に新しいSA組を設立します。 「マルチ-家へ帰」っているホストは、これをするために、新しい本国行きのSAを作成して、新しいSPIを作成します。 送信するUPDATEメッセージに関しては、それは「0インチ、新しいSPIに対応する新しいSPI分野、およびローカルの方針によって選択されるKEYMATインデックス」のOLD SPI分野で超能力_INFOパラメタを挿入します。 ホストが2Typeと共にUPDATEメッセージにLOCATORを追加する、「1インチのロケータ:」 加えられるオリジナルのアドレス、協会でアクティブなSPI、新しいアドレス、および新しいSPI(SPIが_超能力INFOに含まれたNEW SPIに合っている)。 Preferredは言うために方針に依存するセットが同輩ホストであったならSHOULDに噛み付きました(2つのロケータについて好まれます)。 また、UPDATEは任意にSEQパラメタを含んでいます。ディフィー_ヘルマンパラメタ、およびこの新しいアドレスに関して手順を「再-合わせ」る尾行。 UPDATEはSHOULDを通信させます。新しいロケータに対応するソースアドレスがある同輩のPreferredアドレスに送ってください。
The sending of multiple LOCATORs, locators with Locator Type "0", and multiple ESP_INFO parameters is for further study. Note that the inclusion of LOCATOR in an R1 packet requires the use of Type "0" locators since no SAs are set up at that point.
複数のLOCATORs、Locator Typeがあるロケータの発信、「0インチ、さらなる研究には複数の超能力_インフォメーションパラメタがある、」 R1パケットでのLOCATORの包含がTypeの「SAsがないの以来の0インチのロケータはその時、設定している」使用を必要とすることに注意してください。
Nikander, et al. Experimental [Page 27] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[27ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
5.3. Handling Received LOCATORs
5.3. 取り扱いはロケータを受けました。
A host SHOULD be prepared to receive a LOCATOR parameter in the following HIP packets: R1, I2, UPDATE, and NOTIFY.
以下のHIPパケットにLOCATORパラメタを受け取るために準備されていて、AはSHOULDを接待します: R1(I2)はアップデートして、通知します。
This document describes sending both ESP_INFO and LOCATOR parameters in an UPDATE. The ESP_INFO parameter is included when there is a need to rekey or key a new SPI, and is otherwise included for the possible benefit of HIP-aware middleboxes. The LOCATOR parameter contains a complete map of the locators that the host wishes to make or keep active for the HIP association.
このドキュメントは、超能力_INFOとLOCATORの両方にUPDATEのパラメタを送ると説明します。 含まれていて、rekeyにおいてそこの時が必要性であるかキーが新しいSPIであるということです。別の方法で、超能力_INFOパラメタは、HIP意識しているmiddleboxesの可能な利益のために含まれています。 LOCATORパラメタはホストがHIP協会にアクティブに作りたいか、または保ちたがっているロケータの完全な地図を含んでいます。
In general, the processing of a LOCATOR depends upon the packet type in which it is included. Here, we describe only the case in which ESP_INFO is present and a single LOCATOR and ESP_INFO are sent in an UPDATE message; other cases are for further study. The steps below cover each of the cases described in Section 5.2.
一般に、LOCATORの処理はそれが含まれているパケットタイプに頼っています。 ここで、私たちは超能力_INFOが現在である場合だけについて説明します、そして、UPDATEメッセージで独身のLOCATORと超能力_INFOを送ります。 さらなる研究には他のケースがあります。 それぞれに関するケースがセクション5.2で説明したカバーの下のステップ。
The processing of ESP_INFO and LOCATOR parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR parameters. A host SHOULD first process the ESP_INFO before the LOCATOR, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type "1" locator will only contain a reference to the new SPI.
超能力_INFOとLOCATORパラメタの処理は、モジュールであり、複数の超能力_INFO、そして/または、複数のLOCATORパラメタの包含に今後の一般化を支持することを意図します。 ホストSHOULDは最初にLOCATORの前で_超能力INFOを処理します、超能力_INFOが新しいSPI値を含むかもしれないので。存在SPIに写像されています、Typeである間、「1インチのロケータは新しいSPIの参照を含むだけでしょう」。
When a host receives a validated HIP UPDATE with a LOCATOR and ESP_INFO parameter, it processes the ESP_INFO as follows. The ESP_INFO parameter indicates whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of middleboxes. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter:
ホストがLOCATORと超能力_INFOパラメタがある有効にされたHIP UPDATEを受け取るとき、それは_以下の超能力INFOを処理します。 超能力_INFOパラメタは、SAが「再-合わせ」られるか、作成されるか、非難されるか、またはmiddleboxesの利益のためにただ特定されているかを示します。 ホストは超能力_INFOパラメタのOLD SPIとNEW SPI値を調べます:
1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both
correspond to an existing SPI, the ESP_INFO is gratuitous
(provided for middleboxes) and no rekeying is necessary.
1. (「再-合わせ」ないこと) OLD SPIがNEW SPIと等しく、両方が既存のSPIに対応しているなら、超能力_INFOは無料です、そして、(middleboxesに備えます)「再-合わせ」るのは必要ではありません。
2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW
SPI is a different non-zero value, the existing SA is being
rekeyed and the host follows HIP ESP rekeying procedures by
creating a new outbound SA with an SPI corresponding to the NEW
SPI, with no addresses bound to this SPI. Note that locators in
the LOCATOR parameter will reference this new SPI instead of the
old SPI.
2. (「再-合わせ」ること) OLD SPIが、既存のSPIとNEW SPIが異なった非ゼロ値であることを示すなら、既存のSAは「再-合わせ」られています、そして、ホストはこのSPIへの制限されていた状態でアドレスなしでNEW SPIに対応するSPIと新しい外国行きのSAを作成するのによる手順を「再-合わせ」るHIP ESPの後をつけます。 LOCATORパラメタのロケータが古いSPIの代わりにこの新しいSPIに参照をつけることに注意してください。
3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new
non-zero value, then a new SA is being requested by the peer.
This case is also treated like a rekeying event; the receiving
host must create a new SA and respond with an UPDATE ACK.
3. (新しいSA) OLD SPI値がゼロであり、NEW SPIが新しい非ゼロ値であるなら、新しいSAは同輩によって要求されています。 また、本件は「再-合わせ」る出来事のように扱われます。 受信ホストは、新しいSAを作成して、UPDATE ACKと共に応じなければなりません。
Nikander, et al. Experimental [Page 28] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[28ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
4. (deprecating the SA) If the OLD SPI indicates an existing SPI and
the NEW SPI is zero, the SA is being deprecated and all locators
uniquely bound to the SPI are put into the DEPRECATED state.
4. (SAを非難します) OLD SPIが既存のSPIを示して、NEW SPIがゼロである、SAが推奨しないことであり、すべてがロケータであるなら、唯一SPIにDEPRECATED状態に入れた状態でバウンドしてください。
If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped.
上のケースのいずれも適用されないなら、プロトコル誤りは発生しました、そして、UPDATEの処理は止められます。
Next, the locators in the LOCATOR parameter are processed. For each locator listed in the LOCATOR parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it may be allowed that the host runs HIP with itself.
次に、LOCATORパラメタのロケータは処理されます。 LOCATORパラメタに記載された各ロケータがないかどうかそこにアドレスが法的なユニキャストかanycastアドレスであることをチェックしてください。 すなわち、アドレスは、放送かマルチキャストアドレスであるはずがありません。 いくつかの実現がローカル・ホストを示すアドレスを受け入れるかもしれないことに注意してください、ホストがそれ自体でHIPを走らせるのが許容されるかもしれないので。
The below assumes that all locators are of Type "1" with a Traffic Type of "0"; other cases are for further study.
以下が、すべてのロケータがTypeのものであると仮定する、「「0インチ」の交通タイプがある1インチ さらなる研究には他のケースがあります。
For each Type "1" address listed in the LOCATOR parameter, the host checks whether the address is already bound to the SPI indicated. If the address is already bound, its lifetime is updated. If the status of the address is DEPRECATED, the status is changed to UNVERIFIED. If the address is not already bound, the address is added, and its status is set to UNVERIFIED. Mark all addresses corresponding to the SPI that were NOT listed in the LOCATOR parameter as DEPRECATED.
各Typeがないかどうか、「アドレスが既に示されたSPIに縛られるか否かに関係なく、ホストは、1インチのアドレスがロケータパラメタに記載したのをチェックします」。 アドレスが既に制限されているなら、生涯をアップデートします。 アドレスの状態がDEPRECATEDであるなら、状態はUNVERIFIEDに変わります。 アドレスが既に縛られないなら、アドレスは加えられます、そして、状態はUNVERIFIEDに設定されます。 すべてのアドレスがDEPRECATEDとしてLOCATORパラメタに記載されなかったSPIに対応しているとマークしてください。
As a result, at the end of processing, the addresses listed in the LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR parameter have a state of DEPRECATED.
その結果、処理の終わりにLOCATORパラメタに記載されたアドレスはUNVERIFIEDの州かACTIVEのどちらかを持っています、そして、LOCATORパラメタに記載されなかった古いSAに関するどんな旧住所にも、DEPRECATEDの州があります。
Once the host has processed the locators, if the LOCATOR parameter contains a new Preferred locator, the host SHOULD initiate a change of the Preferred locator. This requires that the host first verifies reachability of the associated address, and only then changes the Preferred locator; see Section 5.5.
LOCATORパラメタが新しいPreferredロケータを含むならホストがいったんロケータを処理すると、ホストSHOULDはPreferredロケータの変化を起こします。 これは、ホストが最初に関連アドレスの可到達性について確かめるのを必要とします、そして、Preferredロケータはその時、変化するだけです。 セクション5.5を見てください。
If a host receives a locator with an unsupported Locator Type, and when such a locator is also declared to be the Preferred locator for the peer, the host SHOULD send a NOTIFY error with a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field containing the locator(s) that the receiver failed to process. Otherwise, a host MAY send a NOTIFY error if a (non-preferred) locator with an unsupported Locator Type is received in a LOCATOR parameter.
ホストがサポートされないLocator Typeと共にロケータを受けて、また、そのようなロケータが同輩のためのPreferredロケータであると宣言されるとき、ホストSHOULDはLOCATOR_TYPE_UNSUPPORTEDのNotify Message TypeとのNOTIFY誤りを送ります、Notification Data分野が受信機が処理しなかったロケータを含んでいて。 さもなければ、LOCATORパラメタにサポートされないLocator Typeがある(非都合のよい)のロケータを受け取るなら、ホストはNOTIFY誤りを送るかもしれません。
Nikander, et al. Experimental [Page 29] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[29ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
5.4. Verifying Address Reachability
5.4. アドレスの可到達性について確かめます。
A host MUST verify the reachability of an UNVERIFIED address. The status of a newly learned address MUST initially be set to UNVERIFIED unless the new address is advertised in a R1 packet as a new Preferred locator. A host MAY also want to verify the reachability of an ACTIVE address again after some time, in which case it would set the status of the address to UNVERIFIED and reinitiate address verification.
ホストはUNVERIFIEDアドレスの可到達性について確かめなければなりません。 新しいアドレスが新しいPreferredロケータとしてR1パケットの広告に掲載されない場合、初めは、新たに学習されたアドレスの状態をUNVERIFIEDに設定しなければなりません。 また、ホストはいつか後に再びACTIVEアドレスの可到達性について確かめたがっているかもしれません、その場合、それがUNVERIFIEDと再開始アドレス検査にアドレスの状態を設定するでしょう。
A host typically starts the address-verification procedure by sending a nonce to the new address. For example, when the host is changing its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD be random and the value MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE. However, if the host is not changing its SPI, it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent to the new address. A host MAY also use other message exchanges as confirmation of the address reachability.
ホストは、新しいアドレスに一回だけを送ることによって、アドレス検査手順を通常始めます。 例えば、SPIを変えて、_同輩へのINFO、NEW SPI値のSHOULDを超能力に送って、ホストがそうであるときには無作為にしてください、そして、値はrekeying UPDATEで送られたECHO_REQUESTにコピーされてもよいです。 しかしながら、ホストがSPIを変えていないなら、それはまだ新しいアドレスに送られたUPDATEメッセージのECHO_REQUESTパラメタを使用しているかもしれません。 また、ホストはアドレスの可到達性の確認として他の交換処理を使用するかもしれません。
Note that in the case of receiving a LOCATOR in an R1 and replying with an I2 to the new address in the LOCATOR, receiving the corresponding R2 is sufficient proof of reachability for the Responder's preferred address. Since further address verification of such an address can impede the HIP-base exchange, a host MUST NOT separately verify reachability of a new Preferred locator that was received on an R1.
R1でLOCATORを受けて、I2と共にLOCATORで新しいアドレスに関して返答する場合では、対応するR2を受けるのが、Responderの都合のよいアドレスのための可到達性の十分な証拠であることに注意してください。 そのようなアドレスのさらなるアドレス検査がHIP-塩基置換を妨害する場合があるので、ホストは別々にR1に受け取られた新しいPreferredロケータの可到達性について確かめてはいけません。
In some cases, it MAY be sufficient to use the arrival of data on a newly advertised SA as implicit address reachability verification as depicted in Figure 13, instead of waiting for the confirmation via a HIP packet. In this case, a host advertising a new SPI as part of its address reachability check SHOULD be prepared to receive traffic on the new SA.
いくつかの場合、図13に表現される暗黙のアドレス可到達性検証として新たに広告を出したSAにおけるデータの到着を使用するのは十分であるかもしれません、HIPパケットを通して確認を待つことの代わりに。 この場合新しいSAでトラフィックを受けるために準備されていて、アドレスの可到達性チェックSHOULDの一部として新しいSPIの広告を出すホスト。
Mobile host Peer host
モバイルホストのPeerホスト
prepare incoming SA
NEW SPI in ESP_INFO (UPDATE)
<-----------------------------------
switch to new outgoing SA
data on new SA
----------------------------------->
mark address ACTIVE
超能力_INFO(UPDATE)<に入って来るSA NEW SPIを用意してください。----------------------------------- 新しいSAに関する新しい送信するSAデータに切り替わってください。----------------------------------->マークアドレスACTIVE
Figure 13: Address Activation Via Use of a New SA
図13: 新しいSAの使用を通したアドレス起動
When address verification is in progress for a new Preferred locator, the host SHOULD select a different locator listed as ACTIVE, if one
アドレス検査が新しいPreferredロケータにおいて進行しているとき、ホストSHOULDはACTIVEとして記載された異なったロケータを選択します、1であるなら
Nikander, et al. Experimental [Page 30] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[30ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
such locator is available, to continue communications until address verification completes. Alternatively, the host MAY use the new Preferred locator while in UNVERIFIED status to the extent Credit- Based Authorization permits. Credit-Based Authorization is explained in Section 5.6. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE.
そのようなロケータは、検証が完成するアドレスまでコミュニケーションを続けるために利用可能です。 あるいはまた、CreditがAuthorizationを基礎づけたという範囲への状態がUNVERIFIEDで可能にしている間、ホストは新しいPreferredロケータを使用するかもしれません。 ベースのクレジットAuthorizationはセクション5.6で説明されます。 アドレス検査がいったん成功すると、新しいPreferredロケータの状態はACTIVEに変化します。
5.5. Changing the Preferred Locator
5.5. 都合のよいロケータを変えます。
A host MAY want to change the Preferred outgoing locator for different reasons, e.g., because traffic information or ICMP error messages indicate that the currently used preferred address may have become unreachable. Another reason may be due to receiving a LOCATOR parameter that has the "P" bit set.
ホストは様々な理由でPreferredの出発しているロケータを変えたがっているかもしれません、例えば、道路交通情報かICMPエラーメッセージが、現在中古の都合のよいアドレスが手が届かなくなったかもしれないのを示すので。 別の理由は「P」ビットを設定するLOCATORパラメタを受け取るためであるかもしれません。
To change the Preferred locator, the host initiates the following procedure:
Preferredロケータを変えるために、ホストは以下の手順に着手します:
1. If the new Preferred locator has ACTIVE status, the Preferred
locator is changed and the procedure succeeds.
1. 新しいPreferredロケータにACTIVE状態がいるなら、Preferredロケータを変えます、そして、手順は成功します。
2. If the new Preferred locator has UNVERIFIED status, the host
starts to verify its reachability. The host SHOULD use a
different locator listed as ACTIVE until address verification
completes if one such locator is available. Alternatively, the
host MAY use the new Preferred locator, even though in UNVERIFIED
status, to the extent Credit-Based Authorization permits. Once
address verification succeeds, the status of the new Preferred
locator changes to ACTIVE and its use is no longer governed by
Credit-Based Authorization.
2. 新しいPreferredロケータにUNVERIFIED状態がいるなら、ホストは可到達性について確かめ始めます。 ホストSHOULDはそのようなロケータの1つが利用可能であるならACTIVEとして検証が完成するアドレスまで記載された異なったロケータを使用します。 あるいはまた、ベースのCredit AuthorizationはUNVERIFIED状態で範囲に可能にしますが、ホストは新しいPreferredロケータを使用するかもしれません。 アドレス検査がいったん成功すると、ACTIVEとその使用への新しいPreferredロケータ変化の状態はもうベースのCredit Authorizationによって決定されません。
3. If the peer host has not indicated a preference for any address,
then the host picks one of the peer's ACTIVE addresses randomly
or according to policy. This case may arise if, for example,
ICMP error messages that deprecate the Preferred locator arrive,
but the peer has not yet indicated a new Preferred locator.
3. 同輩ホストがどんなアドレスのための優先も示していないなら、無作為か方針によると、ホストは同輩のACTIVEアドレスの1つを選びます。 例えば、Preferredロケータを非難するICMPエラーメッセージが到着しますが、同輩がまだ新しいPreferredロケータを示していないなら、本件は起こるかもしれません。
4. If the new Preferred locator has DEPRECATED status and there is
at least one non-deprecated address, the host selects one of the
non-deprecated addresses as a new Preferred locator and
continues. If the selected address is UNVERIFIED, the address
verification procedure described above will apply.
4. 新しいPreferredロケータにはDEPRECATED状態がいて、少なくとも1つの非推奨しないアドレスがあれば、ホストは、新しいPreferredロケータとして非推奨しないアドレスの1つを選定して、続きます。 選択されたアドレスがUNVERIFIEDであるなら、上で説明されたアドレス検査手順は適用されるでしょう。
Nikander, et al. Experimental [Page 31] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[31ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
5.6. Credit-Based Authorization
5.6. クレジットベースの承認
To prevent redirection-based flooding attacks, the use of a Credit- Based Authorization (CBA) approach is mandatory when a host sends data to an UNVERIFIED locator. The following algorithm meets the security considerations for prevention of amplification and time- shifting attacks. Other forms of credit aging, and other values for the CreditAgingFactor and CreditAgingInterval parameters in particular, are for further study, and so are the advanced CBA techniques specified in [CBA-MIPv6].
ホストがUNVERIFIEDロケータにデータを送るとき、リダイレクションベースのフラッディング攻撃を防ぐために、CreditのベースのAuthorization(CBA)アプローチの使用は義務的です。 以下のアルゴリズムは、増幅と時間の防止のために攻撃を移行させながら、セキュリティ問題を満たします。 さらなる研究には他のフォームのクレジットの年をとること、および特にCreditAgingFactorとCreditAgingIntervalパラメタのための他の値があります、そして、[CBA-MIPv6]で指定された高度なCBAのテクニックもそうです。
5.6.1. Handling Payload Packets
5.6.1. 取り扱い有効搭載量パケット
A host maintains a "credit counter" for each of its peers. Whenever a packet arrives from a peer, the host SHOULD increase that peer's credit counter by the size of the received packet. When the host has a packet to be sent to the peer, and when the peer's Preferred locator is listed as UNVERIFIED and no alternative locator with status ACTIVE is available, the host checks whether it can send the packet to the UNVERIFIED locator. The packet SHOULD be sent if the value of the credit counter is higher than the size of the outbound packet. If the credit counter is too low, the packet MUST be discarded or buffered until address verification succeeds. When a packet is sent to a peer at an UNVERIFIED locator, the peer's credit counter MUST be reduced by the size of the packet. The peer's credit counter is not affected by packets that the host sends to an ACTIVE locator of that peer.
ホストは同輩各人のために「クレジットカウンタ」を維持します。 パケットが同輩から到着するときはいつも、容認されたパケットのサイズに従って、ホストSHOULDはその同輩のクレジットカウンタを増強します。 ホストが同輩に送られるパケットを持って、UNVERIFIEDにもかかわらず、状態ACTIVEがあるどんな代替のロケータも利用可能でないように同輩のPreferredロケータが記載されているとき、ホストは、それがUNVERIFIEDロケータにパケットを送ることができるかどうかチェックします。 パケットSHOULD、クレジットカウンタの値が外国行きのパケットのサイズより高いなら、送ってください。 クレジットカウンタが低過ぎるなら、アドレス検査が成功するまで、パケットを捨てられなければならないか、またはバッファリングしなければなりません。 UNVERIFIEDロケータの同輩にパケットを送るとき、パケットのサイズで同輩のクレジットカウンタを減少させなければなりません。 同輩のクレジットカウンタはホストがその同輩のACTIVEロケータに送るパケットで影響を受けません。
Figure 14 depicts the actions taken by the host when a packet is received. Figure 15 shows the decision chain in the event a packet is sent.
図14はパケットが受け取られているときホストによって取られた行動について表現します。 図15は、パケットが送られるのをイベントにおける決定チェーンに示します。
Inbound
packet
|
| +----------------+ +---------------+
| | Increase | | Deliver |
+-----> | credit counter |-------------> | packet to |
| by packet size | | application |
+----------------+ +---------------+
本国行きのパケット| | +----------------+ +---------------+ | | 増加| | 配送してください。| +----->| クレジットカウンタ|、-、-、-、-、-、-、-、-、-、-、-、--、>| パケット| | パケットサイズに従って| | アプリケーション| +----------------+ +---------------+
Figure 14: Receiving Packets with Credit-Based Authorization
図14: クレジットベースの承認でパケットを受けます。
Nikander, et al. Experimental [Page 32] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[32ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
Outbound
packet
| _________________
| / \ +---------------+
| / Is the preferred \ No | Send packet |
+-----> | destination address |-------------> | to preferred |
\ UNVERIFIED? / | address |
\_________________/ +---------------+
|
| Yes
|
v
_________________
/ \ +---------------+
/ Does an ACTIVE \ Yes | Send packet |
| destination address |-------------> | to ACTIVE |
\ exist? / | address |
\_________________/ +---------------+
|
| No
|
v
_________________
/ \ +---------------+
/ Credit counter \ No | |
| >= |-------------> | Drop packet |
\ packet size? / | |
\_________________/ +---------------+
|
| Yes
|
v
+---------------+ +---------------+
| Reduce credit | | Send packet |
| counter by |----------------> | to preferred |
| packet size | | address |
+---------------+ +---------------+
外国行きのパケット| _________________ | / \ +---------------+ | /は都合のよい\ノーです。| パケットを送ってください。| +----->| 送付先アドレス|、-、-、-、-、-、-、-、-、-、-、-、--、>| 都合のよさ| \UNVERIFIED? / | アドレス| \_________________/ +---------------+ | | はい| v_________________ / \ +---------------+ /はアクティブな\はいをします。| パケットを送ってください。| | 送付先アドレス|、-、-、-、-、-、-、-、-、-、-、-、--、>| 能動態に| \は存在していますか? / | アドレス| \_________________/ +---------------+ | | いいえ| v_________________ / \ +---------------+/クレジットカウンタ\ノー| | | >= |、-、-、-、-、-、-、-、-、-、-、-、--、>| パケットを下げてください。| \パケットサイズ? / | | \_________________/ +---------------+ | | はい| +に対して---------------+ +---------------+ | クレジットを減少させてください。| | パケットを送ってください。| | 反対してください。|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 都合のよさ| | パケットサイズ| | アドレス| +---------------+ +---------------+
Figure 15: Sending Packets with Credit-Based Authorization
図15: クレジットベースの承認がある送付パケット
5.6.2. Credit Aging
5.6.2. クレジットの年をとること
A host ensures that the credit counters it maintains for its peers gradually decrease over time. Such "credit aging" prevents a malicious peer from building up credit at a very slow speed and using this, all at once, for a severe burst of redirected packets.
ホストは、それが同輩のために徐々に維持するクレジットカウンタが時間がたつにつれて減少するのを保証します。 そのような「クレジットの年をとる」ので、悪意がある同輩は、非常に遅い速度でクレジットを確立して、向け直されたパケットの厳しい炸裂にこれを一気に使用できません。
Nikander, et al. Experimental [Page 33] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[33ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
Credit aging may be implemented by multiplying credit counters with a factor, CreditAgingFactor (a fractional value less than one), in fixed time intervals of CreditAgingInterval length. Choosing appropriate values for CreditAgingFactor and CreditAgingInterval is important to ensure that a host can send packets to an address in state UNVERIFIED even when the peer sends at a lower rate than the host itself. When CreditAgingFactor or CreditAgingInterval are too small, the peer's credit counter might be too low to continue sending packets until address verification concludes.
クレジットの年をとることは要素でクレジットカウンタを掛けることによって、実装されるかもしれません、CreditAgingFactor(断片的な値1未満)、CreditAgingIntervalの長さの一定時間間隔で。 CreditAgingFactorとCreditAgingIntervalのための適切な値を選ぶのは、同輩がホスト自身より低レートで発信さえするとき、ホストが州のUNVERIFIEDのアドレスにパケットを送ることができるのを保証するために重要です。 CreditAgingFactorかCreditAgingIntervalが小さ過ぎるときに、同輩のクレジットカウンタはアドレス検査が終わるまでパケットを送り続けることができないくらい低いかもしれません。
The parameter values proposed in this document are as follows:
本書では提案されたパラメタ値は以下の通りです:
CreditAgingFactor 7/8
CreditAgingInterval 5 seconds
5秒のCreditAgingFactor7/8CreditAgingInterval
These parameter values work well when the host transfers a file to the peer via a TCP connection and the end-to-end round-trip time does not exceed 500 milliseconds. Alternative credit-aging algorithms may use other parameter values or different parameters, which may even be dynamically established.
ホストがTCP接続でファイルを同輩に移すとき、これらのパラメタ値はうまくいきます、そして、終わりから終わりへの往復の時間は500人のミリセカンドを超えていません。 代替のクレジットを古いアルゴリズムは他のパラメタ値か異なったパラメタを使用するかもしれません。(パラメタはダイナミックに確立さえされるかもしれません)。
6. Security Considerations
6. セキュリティ問題
The HIP mobility mechanism provides a secure means of updating a host's IP address via HIP UPDATE packets. Upon receipt, a HIP host cryptographically verifies the sender of an UPDATE, so forging or replaying a HIP UPDATE packet is very difficult (see [RFC5201]). Therefore, security issues reside in other attack domains. The two we consider are malicious redirection of legitimate connections as well as redirection-based flooding attacks using this protocol. This can be broken down into the following:
HIP移動性メカニズムはHIP UPDATEパケットを通してホストのIPアドレスをアップデートする安全な手段を提供します。 領収書では、したがって、鍛造して、HIPホストが暗号でUPDATEの送付者について確かめるか、またはHIP UPDATEパケットを再演するのは非常に難しいです([RFC5201]を見てください)。 したがって、安全保障問題は他の攻撃ドメインにあります。 2は私たちが、考えるこのプロトコルを使用するリダイレクションベースのフラッディング攻撃と同様に正統の接続の悪意があるリダイレクションです。 これは以下へ砕けている場合があります:
Impersonation attacks
ものまね攻撃
- direct conversation with the misled victim
- ミスリードされた犠牲者とのダイレクト会話
- man-in-the-middle attack
- 介入者攻撃
DoS attacks
DoS攻撃
- flooding attacks (== bandwidth-exhaustion attacks)
- フラッディング攻撃(=帯域幅疲労困憊攻撃)
* tool 1: direct flooding
* ツール1: ダイレクト氾濫
* tool 2: flooding by zombies
* ツール2: ゾンビによる氾濫
* tool 3: redirection-based flooding
* ツール3: リダイレクションベースの氾濫
Nikander, et al. Experimental [Page 34] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[34ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
- memory-exhaustion attacks
- メモリ疲労困憊攻撃
- computational-exhaustion attacks
- コンピュータの疲労困憊攻撃
We consider these in more detail in the following sections.
私たちはさらに詳細に以下のセクションでこれらを考えます。
In Section 6.1 and Section 6.2, we assume that all users are using HIP. In Section 6.3 we consider the security ramifications when we have both HIP and non-HIP users. Security considerations for Credit- Based Authorization are discussed in [SIMPLE-CBA].
セクション6.1とセクション6.2では、私たちは、すべてのユーザがHIPを使用していると思います。 HIPと非HIPユーザの両方があるとき、セクション6.3では、私たちは、セキュリティが分岐であると考えます。 [SIMPLE-CBA]でCreditのベースのAuthorizationのためのセキュリティ問題について議論します。
6.1. Impersonation Attacks
6.1. ものまね攻撃
An attacker wishing to impersonate another host will try to mislead its victim into directly communicating with them, or carry out a man- in-the-middle (MitM) attack between the victim and the victim's desired communication peer. Without mobility support, both attack types are possible only if the attacker resides on the routing path between its victim and the victim's desired communication peer, or if the attacker tricks its victim into initiating the connection over an incorrect routing path (e.g., by acting as a router or using spoofed DNS entries).
別のホストをまねたがっている攻撃者は、犠牲者と犠牲者の必要なコミュニケーション同輩の間に直接彼らとコミュニケートするのに犠牲者をミスリードしようとするか、または中央の男性(MitM)攻撃を行おうとするでしょう。 移動性サポートがなければ、攻撃者が犠牲者と犠牲者の必要なコミュニケーション同輩の間のルーティング経路に単に住んでいるか、または攻撃者が、不正確なルーティング経路の上で犠牲者が接続を開始するようにだますなら(例えば、ルータとして機能するか、または偽造しているDNSエントリーを使用することによって)、両方の攻撃タイプは可能です。
The HIP extensions defined in this specification change the situation in that they introduce an ability to redirect a connection (like IPv6), both before and after establishment. If no precautionary measures are taken, an attacker could misuse the redirection feature to impersonate a victim's peer from any arbitrary location. The authentication and authorization mechanisms of the HIP base exchange [RFC5201] and the signatures in the UPDATE message prevent this attack. Furthermore, ownership of a HIP association is securely linked to a HIP HI/HIT. If an attacker somehow uses a bug in the implementation or weakness in some protocol to redirect a HIP connection, the original owner can always reclaim their connection (they can always prove ownership of the private key associated with their public HI).
接続(IPv6のような)を向け直す能力を導入するので、HIP拡張子はこの仕様書変更で状況を定義しました、ともに設立の前後に。 予防策を全く取らないなら、攻撃者はどんな任意の位置からも犠牲者の同輩をまねるリダイレクションの特徴を誤用するかもしれません。 HIP塩基置換[RFC5201]とUPDATEメッセージにおける署名の認証と承認メカニズムはこの攻撃を防ぎます。 その上、HIP協会の所有権はしっかりとHIP HI/HITにリンクされます。 攻撃者がHIP接続を向け直すのに何らかのプロトコルの実装か弱点にバグをどうにか使用するなら、最初の所有者はいつも彼らの接続を取り戻すことができます(彼らは、いつも秘密鍵の所有権がそれらの公共のHIに関連していると立証できます)。
MitM attacks are always possible if the attacker is present during the initial HIP base exchange and if the hosts do not authenticate each other's identities. However, once the opportunistic base exchange has taken place, even a MitM cannot steal the HIP connection anymore because it is very difficult for an attacker to create an UPDATE packet (or any HIP packet) that will be accepted as a legitimate update. UPDATE packets use HMAC and are signed. Even when an attacker can snoop packets to obtain the SPI and HIT/HI, they still cannot forge an UPDATE packet without knowledge of the secret keys.
攻撃者が初期のHIP塩基置換の間、出席していて、ホストが互いのアイデンティティを認証しないなら、MitM攻撃はいつも可能です。 しかしながら、便宜主義的な塩基置換がいったん起こると、攻撃者が正統のアップデートとして認められるUPDATEパケット(または、どんなHIPパケットも)を作成するのが、非常に難しいので、MitMさえそれ以上HIP接続を横取りできません。 UPDATEパケットは、HMACを使用して、署名されます。 攻撃者がSPIとHIT/HIを入手するためにパケットについて詮索さえできるとき、それらは秘密鍵に関する知識なしでUPDATEパケットをまだ鍛造できません。
Nikander, et al. Experimental [Page 35] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[35ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
6.2. Denial-of-Service Attacks
6.2. サービス不能攻撃
6.2.1. Flooding Attacks
6.2.1. フラッディング攻撃
The purpose of a denial-of-service attack is to exhaust some resource of the victim such that the victim ceases to operate correctly. A denial-of-service attack can aim at the victim's network attachment (flooding attack), its memory, or its processing capacity. In a flooding attack, the attacker causes an excessive number of bogus or unwanted packets to be sent to the victim, which fills their available bandwidth. Note that the victim does not necessarily need to be a node; it can also be an entire network. The attack basically functions the same way in either case.
サービス不能攻撃の目的が犠牲者の何らかのリソースを枯渇させることであるので、犠牲者は、正しく作動するのをやめます。 サービス不能攻撃は犠牲者のネットワーク付属(フラッディング攻撃)、メモリ、またはその処理容量を目的とすることができます。 フラッディング攻撃では、攻撃者は過度の数のにせの、または、求められていないパケットを犠牲者に送らせます。(その犠牲者は、それらの利用可能な帯域幅をいっぱいにします)。 犠牲者が、必ずノードである必要であるというわけではないことに注意してください。 また、それは全体のネットワークであるかもしれません。 攻撃はどちらの場合でも基本的に同じように機能します。
An effective DoS strategy is distributed denial of service (DDoS). Here, the attacker conventionally distributes some viral software to as many nodes as possible. Under the control of the attacker, the infected nodes, or "zombies", jointly send packets to the victim. With such an 'army', an attacker can take down even very high bandwidth networks/victims.
効果的なDoS戦略は分散型サービス拒否(DDoS)です。 ここで、攻撃者は慣習上できるだけ多くのノードに何らかのウイルス性のソフトウェアを分配します。 攻撃者、感染したノード、または「ゾンビ」のコントロールの下では、共同でパケットを犠牲者に送ってください。 そのような'軍隊'と共に攻撃者はまさしくその高帯域ネットワーク/犠牲者さえ降ろすことができます。
With the ability to redirect connections, an attacker could realize a DDoS attack without having to distribute viral code. Here, the attacker initiates a large download from a server, and subsequently redirects this download to its victim. The attacker can repeat this with multiple servers. This threat is mitigated through reachability checks and credit-based authorization. Both strategies do not eliminate flooding attacks per se, but they preclude: (i) their use from a location off the path towards the flooded victim; and (ii) any amplification in the number and size of the redirected packets. As a result, the combination of a reachability check and credit-based authorization lowers a HIP redirection-based flooding attack to the level of a direct flooding attack in which the attacker itself sends the flooding traffic to the victim.
接続を向け直す能力で、ウイルス性のコードを分配する必要はなくて、攻撃者はDDoS攻撃をわかることができました。 ここで、攻撃者は、サーバから大きいダウンロードを開始して、次に、このダウンロードを犠牲者に向け直します。 攻撃者は複数のサーバでこれを繰り返すことができます。 この脅威は可到達性チェックとクレジットベースの承認を通して緩和されます。 両方の戦略はそういうものとしてフラッディング攻撃を排除しませんが、彼らは以下を排除します。 (i) 水につかっている犠牲者に向かった経路の位置からの彼らの使用。 そして、向け直されたパケットの数とサイズにおけるどんな(ii)増幅。 その結果、可到達性チェックとクレジットベースの承認の組み合わせは攻撃者自身が氾濫トラフィックを犠牲者に送るダイレクトフラッディング攻撃のレベルにHIPのリダイレクションベースのフラッディング攻撃を下ろします。
6.2.2. Memory/Computational-Exhaustion DoS Attacks
6.2.2. コンピュータのメモリ/疲労困憊DoS攻撃
We now consider whether or not the proposed extensions to HIP add any new DoS attacks (consideration of DoS attacks using the base HIP exchange and updates is discussed in [RFC5201]). A simple attack is to send many UPDATE packets containing many IP addresses that are not flagged as preferred. The attacker continues to send such packets until the number of IP addresses associated with the attacker's HI crashes the system. Therefore, there SHOULD be a limit to the number of IP addresses that can be associated with any HI. Other forms of memory/computationally exhausting attacks via the HIP UPDATE packet are handled in the base HIP document [RFC5201].
私たちは、現在、HIPへの提案された拡大が何か新しいDoS攻撃を加えるかどうか([RFC5201]でベースHIP交換とアップデートを使用するDoS攻撃の考慮について議論します)考えます。 簡単な攻撃は好まれるように旗を揚げられない多くのIPアドレスを含む多くのUPDATEパケットを送ることです。 攻撃者は、攻撃者のHIに関連しているIPアドレスの数がシステムを墜落させるまでそのようなパケットを送り続けています。 したがってと、そこ、SHOULD、どんなHIにも関連づけることができるIPアドレスの数への限界になってください。 HIP UPDATEパケットを通した他の形式の計算上メモリ/消耗している攻撃はベースHIPドキュメント[RFC5201]で扱われます。
Nikander, et al. Experimental [Page 36] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[36ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
A central server that has to deal with a large number of mobile clients may consider increasing the SA lifetimes to try to slow down the rate of rekeying UPDATEs or increasing the cookie difficulty to slow down the rate of attack-oriented connections.
多くのモバイルクライアントに対応しなければならないセントラルサーバーは、rekeying UPDATEsのレートを減速させようとするためにSA生涯を増強するか、または攻撃指向の接続の速度を減速させるためにクッキー困難を増強すると考えるかもしれません。
6.3. Mixed Deployment Environment
6.3. Mixed展開環境
We now assume an environment with both HIP and non-HIP aware hosts. Four cases exist.
私たちは現在、HIPと非HIPの意識しているホストの両方がある環境を仮定します。 4つのケースが存在しています。
1. A HIP host redirects its connection onto a non-HIP host. The
non-HIP host will drop the reachability packet, so this is not a
threat unless the HIP host is a MitM that could somehow respond
successfully to the reachability check.
1. HIPホストは非HIPホストに接続を向け直します。 非HIPホストが可到達性パケットを下げるので、HIPホストがどうにか首尾よく可到達性チェックに応じることができたMitMでないなら、これは脅威ではありません。
2. A non-HIP host attempts to redirect their connection onto a HIP
host. This falls into IPv4 and IPv6 security concerns, which are
outside the scope of this document.
2. 非HIPホストは、HIPホストに彼らの接続を向け直すのを試みます。 これはIPv4とIPv6安全上の配慮になります。(このドキュメントの範囲の外にそれは、あります)。
3. A non-HIP host attempts to steal a HIP host's session (assume
that Secure Neighbor Discovery is not active for the following).
The non-HIP host contacts the service that a HIP host has a
connection with and then attempts to change its IP address to
steal the HIP host's connection. What will happen in this case
is implementation dependent but such a request should fail by
being ignored or dropped. Even if the attack were successful,
the HIP host could reclaim its connection via HIP.
3. 非HIPホストは、HIPホストのセッションを横取りするのを試みます(以下には、Secure Neighborディスカバリーがアクティブでないと仮定してください)。 非HIPホストは、HIPホストが接続がいるサービスに連絡して、次に、HIPホストの接続を横取りするためにIPアドレスを変えるのを試みます。 何が起こるかは、この場合実装に依存していますが、無視されるか、または下げられることによって、そのような要求は失敗するべきです。 攻撃がうまくいったとしても、HIPホストはHIPを通して接続を取り戻すことができるでしょうに。
4. A HIP host attempts to steal a non-HIP host's session. A HIP
host could spoof the non-HIP host's IP address during the base
exchange or set the non-HIP host's IP address as its preferred
address via an UPDATE. Other possibilities exist, but a simple
solution is to prevent the use of HIP address check information
to influence non-HIP sessions.
4. HIPホストは、非HIPホストのセッションを横取りするのを試みます。 HIPホストは、塩基置換の間、非HIPホストのIPアドレスを偽造するか、または都合のよいアドレスとしてUPDATEを通して非HIPホストのIPアドレスを設定できました。 他の可能性は存在していますが、簡単なソリューションは非HIPセッションに影響を及ぼすためにHIPアドレス検査情報の使用を防ぐことです。
7. IANA Considerations
7. IANA問題
This document defines a LOCATOR parameter for the Host Identity Protocol [RFC5201]. This parameter is defined in Section 4 with a Type of 193.
このドキュメントはHost Identityプロトコル[RFC5201]のためのLOCATORパラメタを定義します。 このパラメタは193のTypeと共にセクション4で定義されます。
This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message Type as defined in the Host Identity Protocol specification [RFC5201]. This parameter is defined in Section 5.3 with a value of 46.
また、このドキュメントはHost Identityプロトコル仕様[RFC5201]に基づき定義されるようにLOCATOR_TYPE_UNSUPPORTED Notify Message Typeを定義します。 このパラメタは46の値でセクション5.3で定義されます。
Nikander, et al. Experimental [Page 37] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[37ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
8. Authors and Acknowledgments
8. 作者と承認
Pekka Nikander and Jari Arkko originated this document, and Christian Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Perkins contributed the initial draft of the security section. Petri Jokela was a co-author of the initial individual submission.
ペッカNikanderとヤリArkkoはこのドキュメントを溯源しました、そして、クリスチャンのフォークトとトーマス・ヘンダーソン(エディタ)は後で共著者として加わりました。 グレッグ・パーキンスはセキュリティ部の初期の草稿を寄付しました。 ペトリJokelaは初期の個々の服従の共著者でした。
The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document.
作者はドキュメントへの多くの改良についてミカKomu、ミカ甲佐、ジェフAhrenholz、およびジャン・メレンに感謝します。
9. References
9. 参照
9.1. Normative references
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4423] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)のアーキテクチャ」、RFC4423)は2006がそうするかもしれません。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201,
April 2008.
[RFC5201]マスコウィッツ、R.、Nikander、P.、Jokela、P.、エド、T.ヘンダーソン、「ホストアイデンティティプロトコル」、RFC5201、4月2008日
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
ESP Transport Format with the Host Identity Protocol
(HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、マスコウィッツ、R.、およびP.Nikander、「ホストアイデンティティプロトコル(クールな)がある超能力輸送形式を使用します」、RFC5202(2008年4月)。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol
(HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] LaganierとJ.とL.エッゲルト、「ホストのアイデンティティのプロトコルの(クール)のランデブー拡大」、RFC5204、2008年4月。
9.2. Informative references
9.2. 有益な参照
[CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for
Mobile IPv6 Early Binding Updates", Work in Progress,
February 2005.
[CBA-MIPv6] 「モバイルIPv6事前バインディングアップデートのためのクレジットベースの承認」というフォークト、C.、およびJ.Arkkoは進歩、2005年2月に働いています。
Nikander, et al. Experimental [Page 38] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[38ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
E. Nordmark, "Mobile IP Version 6 Route Optimization
Security Design Background", RFC 4225, December 2005.
[RFC4225] Nikander、P.、Arkko、J.、香気、T.、モンテネグロ、G.、およびE.Nordmark、「モバイルIPバージョン6経路最適化セキュリティはバックグラウンドを設計します」、RFC4225、2005年12月。
[SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for
Concurrent Reachability Verification", Work
in Progress, February 2006.
[簡単なCBA] 「同時発生の可到達性検証のためのクレジットベースの承認」というフォークト、C.、およびJ.Arkkoは進歩、2006年2月に働いています。
Authors' Addresses
作者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペッカ・Nikanderエリクソン研究NomadicLab JORVASフィン-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
以下に電話をしてください。 +358 9 299 1 メール: pekka.nikander@nomadiclab.com
Thomas R. Henderson (editor) The Boeing Company P.O. Box 3707 Seattle, WA USA
トーマスR.ヘンダーソン(エディタ)ボーイング社P.O. Box3707ワシントンシアトル(米国)
EMail: thomas.r.henderson@boeing.com
メール: thomas.r.henderson@boeing.com
Christian Vogt Ericsson Research NomadicLab Hirsalantie 11 JORVAS FIN-02420 FINLAND
クリスチャンのフォークトエリクソン研究NomadicLab Hirsalantie11JORVASフィン-02420フィンランド
Phone: EMail: christian.vogt@ericsson.com
以下に電話をしてください。 メール: christian.vogt@ericsson.com
Jari Arkko Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ヤリ・Arkkoエリクソン研究NomadicLab JORVASフィン-02420フィンランド
Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com
以下に電話をしてください。 +358 40 5079256はメールされます: jari.arkko@ericsson.com
Nikander, et al. Experimental [Page 39] RFC 5206 HIP Mobility and Multihoming April 2008
Nikander、他 実験的な[39ページ]RFC5206のクールな移動性とマルチホーミング2008年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Nikander, et al. Experimental [Page 40]
Nikander、他 実験的[40ページ]
一覧
スポンサーリンク
