[要約] 要約：RFC 6538は、Host Identity Protocol（HIP）の実験結果を報告するものであり、HIPの機能とパフォーマンスに関する詳細な情報を提供しています。 目的：このRFCの目的は、HIPの実装と展開に関する情報を提供し、ネットワークセキュリティとモビリティの改善に寄与することです。
Internet Research Task Force (IRTF) T. Henderson
Request for Comments: 6538 The Boeing Company
Category: Informational A. Gurtov
ISSN: 2070-1721 University of Oulu
March 2012
The Host Identity Protocol (HIP) Experiment Report
ホストIDプロトコル（HIP）実験レポート
Abstract
概要
This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures.
このドキュメントは、研究、関連する実験、および研究グループによって完了したデザインから学んだ集合的な経験と教訓を文書化するIRTFホストIDアイデンティティプロトコル（HIP）研究グループのレポートです。このドキュメントは、ホストプロトコルスタック、インターネットインフラストラクチャ、およびアプリケーションに股関節を追加することの意味を要約しています。ネットワークオペレーターの視点と、股関節実験のリストも提示されています。このレポートの一部は、他のネットワークオーバーレイベースのアーキテクチャや、代替ネットワークアーキテクチャの展開を試みる試みにも関連する場合があります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the IRTF HIP Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のIRTF HIP研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6538.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6538で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書の公開。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. What is HIP? ...............................................3
1.2. Terminology ................................................4
1.3. Scope ......................................................4
1.4. Organization ...............................................5
2. Host Stack Implications .........................................6
2.1. Modifications to TCP/IP Stack Implementations ..............6
2.1.1. ESP Implementation Extensions .......................8
2.2. User-Space Implementations .................................9
2.3. Issues Common to Both Implementation Approaches ............9
2.3.1. User-Space Handling of HITs .........................9
2.3.2. Opportunistic Mode .................................10
2.3.3. Resolving HITs to Addresses ........................12
2.3.4. IPsec Management API Extensions ....................12
2.3.5. Transport Protocol Issues ..........................12
2.3.6. Legacy NAT Traversal ...............................14
2.3.7. Local Management of Host Identity Namespace ........14
2.3.8. Interactions with Host Firewalls ...................15
2.4. IPv4 versus IPv6 Issues ...................................15
2.5. What Have Early Adopters Learned from Experience? .........16
3. Infrastructure Implications ....................................17
3.1. Impact on DNS .............................................17
3.2. HIP-Aware Middleboxes .....................................17
3.3. HIT Resolution Infrastructure .............................18
3.4. Rendezvous Servers ........................................18
3.5. Hybrid DNS-DHT Resolution .................................19
4. Application Implications .......................................20
4.1. Non-Intrusive HIP Insertion ...............................20
4.2. Referrals .................................................20
4.3. Latency ...................................................21
5. Network Operator's Perspective .................................21
5.1. Management of the Host Identity Namespace .................21
5.2. Use of ESP Encryption .....................................22
5.3. Access Control Lists Based on HITs ........................22
5.4. Firewall Issues ...........................................23
6. User Privacy Issues ............................................24
7. Experimental Basis of This Report ..............................25
8. Related Work on ID-Locator Split ...............................27
9. Security Considerations ........................................28
10. Acknowledgments ...............................................28
11. Informative References ........................................29
This document summarizes the work and experiences of the IRTF's Host Identity Protocol research group (HIP-RG) in the 2004-2009 time frame. The HIP-RG was chartered to explore the possible benefits and consequences of deploying the Host Identity Protocol architecture [RFC4423] in the Internet and to explore extensions to HIP.
このドキュメントは、2004年から2009年の時間枠におけるIRTFのホストIDプロトコル研究グループ（HIP-RG）の作業と経験をまとめたものです。HIP-RGは、インターネットでホストIDプロトコルアーキテクチャ[RFC4423]を展開することの可能な利点と結果を調査し、股関節への拡張を探求するためにチャーターされました。
This document was developed over several years as the main charter item for the HIP research group, and it has received inputs and reviews from most of the active research group participants. There is research group consensus to publish it.
この文書は、数年にわたって股関節研究グループの主要なチャーターアイテムとして開発され、アクティブな研究グループの参加者のほとんどからインプットとレビューを受け取りました。それを公開するための研究グループのコンセンサスがあります。
The Host Identity Protocol architecture introduces a new namespace, the "host identity" namespace, to the Internet architecture. The express purpose of this new namespace is to allow for the decoupling of identifiers (host identities) and locators (IP addresses) at the internetworking layer of the architecture. The contributors to HIP have expected that HIP will enable alternative solutions for several of the Internet's challenging technical problems, including potentially host mobility, host multihoming, site multihoming, IPv6 transition, NAT traversal, and network-level security. Although there have been many architectural proposals to decouple identifiers and locators over the past 20 years, HIP is one of the most actively developed proposals in this area [book.gurtov].
ホストIDプロトコルアーキテクチャは、インターネットアーキテクチャに新しい名前空間「ホストID」名前空間を紹介します。この新しい名前空間の明示的な目的は、アーキテクチャのインターネットワークレイヤーで識別子（ホストID）とロケーター（IPアドレス）の分離を可能にすることです。股関節への貢献者は、HIPが、ホストのモビリティ、ホストのマルチホーム、サイトマルチホミング、IPv6トランジション、NATトラバーサル、ネットワークレベルのセキュリティなど、インターネットの挑戦的な技術的問題のいくつかの代替ソリューションを可能にすることを期待しています。過去20年間に識別子とロケーターを切り離すための多くの建築提案がありましたが、HIPはこの分野で最も積極的に開発された提案の1つです[book.gurtov]。
The Host Identity Protocol itself provides a rapid exchange of host identities (public keys) between hosts and uses a Diffie-Hellman key exchange that is compliant with Sigma ("SIGn-and-MAc") to establish shared secrets between such endpoints [RFC5201]. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the-Middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP) [RFC4303], it provides encryption and/or authentication protection for upper-layer protocols such as TCP and UDP, while enabling continuity of communications across network-layer address changes.
ホストIDプロトコル自体は、ホスト間のホストID（パブリックキー）の迅速な交換を提供し、Sigma（「Sign-and-Mac」）に準拠したDiffie-Hellmanキー交換を使用して、そのようなエンドポイント間の共有秘密を確立します[RFC5201]。このプロトコルは、サービス拒否（DOS）および中間者（MITM）攻撃に耐性があるように設計されており、カプセル化されたセキュリティペイロード（ESP）[RFC4303]などの別の適切なセキュリティプロトコルと一緒に使用すると、、TCPやUDPなどの上層層プロトコルの暗号化および/または認証保護を提供しながら、ネットワーク層アドレスの変更全体で通信の連続性を可能にします。
A number of Experimental RFC specifications were published by the IETF's HIP working group, including the HIP base protocol [RFC5201], ESP encapsulation [RFC5202], registration extensions [RFC5203], HIP rendezvous servers [RFC5204], DNS resource records [RFC5205], and mobility management [RFC5206]. Host identities are represented as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843] in Internet protocols. Additionally, the research group published one RFC on requirements for traversing NATs and firewalls [RFC5207]
IETFの股関節ワーキンググループによって、多くの実験RFC仕様が発行されました。これには、HIPベースプロトコル[RFC5201]、ESPカプセル化[RFC5202]、登録拡張[RFC5203]、股関節ランデブーサーバー[RFC5204]、DNSリソース記録[RFC5205]、およびモビリティ管理[RFC5206]。ホストのアイデンティティは、インターネットプロトコルでオーバーレイルーティング可能な暗号化ハッシュ識別子（蘭）[RFC4843]として表されます。さらに、研究グループは、NATとファイアウォールを横断するための要件に関する1つのRFCを公開しました[RFC5207]
and the working group later published specification text for legacy NAT traversal [RFC5770]. As of this writing, work has commenced on moving the above specifications to Standards Track status.
ワーキンググループは、後にレガシーNAT Traversal [RFC5770]の仕様テキストを公開しました。この執筆時点で、上記の仕様を標準の追跡ステータスに移動する作業が開始されました。
The terms used in this document are defined elsewhere in various documents. In particular, readers are suggested to review Section 3 of [RFC4423] for a listing of HIP-specific terminology.
このドキュメントで使用される用語は、さまざまなドキュメントの他の場所で定義されています。特に、股関節固有の用語のリストについては、[RFC4423]のセクション3をレビューすることをお勧めします。
The research group has been tasked with producing an "experiment report" documenting the collective experiences and lessons learned from other studies, related experimentation, and designs completed by the research group. The question of whether the basic identifier-locator split assumption is valid falls beyond the scope of this research group. When indicated by its studies, the HIP-RG can suggest extensions and modifications to the protocol and architecture. It has also been in scope for the RG to study, in a wider sense, what the consequences and effects that wide-scale adoption of any type of separation of the identifier and locator roles of IP addresses is likely to have.
研究グループは、研究グループによって完了した他の研究、関連する実験、および設計から学んだ集団的経験と教訓を文書化する「実験レポート」を作成することを任されています。基本的な識別子ロケーターの分割仮定が有効であるかどうかの問題は、この研究グループの範囲を超えて低下します。その研究で示されると、HIP-RGはプロトコルとアーキテクチャの拡張と変更を提案できます。また、RGが、IPアドレスの識別子とロケーターの役割のあらゆるタイプの分離の幅広い採用の結果と影響をより広く研究することも範囲にあります。
During the period of time when the bulk of this report was drafted (2004-2009), several research projects and open source software projects were formed to study HIP. These projects have been developing software enabling HIP to be interoperable according to the Experimental RFCs as well as supporting extensions not yet specified by RFCs.
このレポートの大部分が起草された期間（2004年から2009年）に、いくつかの研究プロジェクトとオープンソースソフトウェアプロジェクトが形成され、股関節が研究されました。これらのプロジェクトは、実験的なRFCに従って股関節を相互運用できるようにするソフトウェアを開発しており、RFCSでまだ指定されていない拡張機能をサポートしています。
The research group has been most active in two areas. First and foremost, the research group has studied extensions to HIP that went beyond the scope and charter of the IETF HIP working group and the set of RFCs (RFC 5201-5206) initially published in April 2008. Some of this work (NAT traversal, certificate formats for HIP, legacy application support, and a native sockets API for HIP) ultimately flowed into the IETF HIP working group upon its recharter in 2008. Other extensions (e.g., HIP in the Internet Indirection Infrastructure (i3) overlay, use of distributed hash tables for HIT-based (Host Identity Tag) lookups, mobile router extensions, etc.) are either still being worked on in the research group or have been abandoned. Most of the energy of the research group during this time period has been in studying extensions of HIPs or the application of HIP to new problem domains (such as the Internet of Things). Second, the research group has discussed the progress and outcome of the implementations and experiments conducted so far, as well as discussing perspectives from different participants (end users,
研究グループは、2つの分野で最も活動しています。何よりもまず、研究グループは、2008年4月に最初に公開されたIETF HIPワーキンググループとRFCSのセット（RFC 5201-5206）の範囲とチャーターを超えた股関節への拡張を研究しました。股関節、レガシーアプリケーションサポート、および股関節のネイティブソケットAPIの証明書形式）は、最終的に2008年にリチャター時にIETFヒップワーキンググループに流れました。ヒットベースの（ホストIDタグ）ルックアップ、モバイルルーター拡張など）のハッシュテーブルは、研究グループでまだ取り組んでいるか、放棄されています。この期間中の研究グループのほとんどのエネルギーは、股関節の拡張または新しい問題ドメイン（モノのインターネットなど）への股関節の適用の研究にありました。第二に、研究グループは、これまでに実施された実装と実験の進捗と結果について議論し、さまざまな参加者からの視点について議論しました（エンドユーザー、
operators, enterprises) on HIP deployment. It is this latter category of work (and not the extensions to HIP) on which this report is focused.
股関節展開に関するオペレーター、エンタープライズ）。このレポートに焦点が当てられているのは、この後者のカテゴリの作業（股関節への拡張ではありません）です。
Finally, the research group was chartered to study, but did not rigorously study (due to lack of inputs), the following issues:
最後に、研究グループは研究するためにチャーターされましたが、以下の問題については、厳密に研究しませんでした（入力が不足しているため）。
o Objective comparisons of HIP with other mechanisms (although the research group did hold some discussions concerning the relation of HIP to other efforts such as the End-Middle-End (EME) research group, the Routing research group (RRG), and shim6-based protocols).
o 股関節と他のメカニズムとの客観的比較（ただし、研究グループは、股関節のエンドミドルエンド（EME）研究グループ、ルーティング研究グループ（RRG）、SHIM6ベースの研究グループなどの他の取り組みとの関係に関するいくつかの議論を行いましたが、プロトコル）。
o Large scale deployments (thousands of hosts or greater).
o 大規模な展開（何千ものホスト以上）。
o Exploration of whether introducing an identity-locator mechanism would be architecturally sound, deployed at wide scale.
o ID-Locatorメカニズムを導入するかどうかの調査は、広く展開されているアーキテクチャにサウンドになるでしょう。
o Changes to the HIP baseline architecture and protocol or other identity-locator separation architectures.
o ヒップベースラインアーキテクチャとプロトコルまたはその他のID-Locator分離アーキテクチャの変更。
In this report, we summarize the collective experience of early implementers and adopters of HIP, organized as follows:
このレポートでは、以下のように組織された初期の実装者と股関節の採用者の集合的な経験を要約します。
o Section 2 describes the implications of supporting HIP on an end host.
o セクション2では、エンドホストの股関節をサポートすることの意味について説明します。
o Section 3 covers a number of issues regarding the deployment of and interaction with network infrastructure, including middlebox traversal, name resolution, Access Control Lists (ACLs), and HIP infrastructure such as rendezvous servers.
o セクション3では、ミドルボックストラバーサル、名前解像度、アクセス制御リスト（ACLS）、ランデブーサーバーなどの股関節インフラストラクチャなど、ネットワークインフラストラクチャの展開と相互作用に関する多くの問題について説明します。
Whereas the two previous sections focus on the implementation and deployment of the network plumbing to make HIP work, the next three focus on the impact on users and operators of the network.
以前の2つのセクションでは、ネットワーク配管の実装と展開に焦点を当てて股関節を機能させますが、次の3つはネットワークのユーザーとオペレーターへの影響に焦点を当てています。
o Section 4 examines how the support of HIP in the host and network infrastructure affects applications; whether and how HIP provides benefits or drawbacks to HIP-enabled and legacy applications.
o セクション4では、ホストおよびネットワークインフラストラクチャにおける股関節のサポートがアプリケーションにどのように影響するかを調べます。HIPが股関節対応およびレガシーアプリケーションに利益または欠点を提供するかどうか、および方法。
o Section 5 provides an operator's perspective on HIP deployment.
o セクション5では、股関節の展開に関するオペレーターの視点を説明します。
o Section 6 discusses user privacy issues.
o セクション6では、ユーザーのプライバシーの問題について説明します。
In closing, in Section 7, we list the experimental activities and research that have contributed to this report, and in Section 8 we briefly summarize related work.
最後に、セクション7に、このレポートに貢献した実験活動と研究をリストし、セクション8では、関連する作業を簡単に要約します。
HIP is primarily an extension to the TCP/IP stack of Internet hosts, and, in this section, we summarize some experiences that several implementation groups have encountered in developing this extension. Our discussion here draws on experience of implementers in adding HIP to general-purpose computing platforms such as laptops, desktops, servers, and PDAs. There are two primary ways to support HIP on such an end host. The first is to make changes to the kernel implementation to directly support the decoupling of identifier and locator. Although this type of modification has data throughput performance benefits, it is also the more challenging to deploy. The second approach is to implement all HIP processing in the user-space and configure the kernel to route packets through user-space for HIP processing.
HIPは主にインターネットホストのTCP/IPスタックの拡張機能であり、このセクションでは、この拡張機能の開発でいくつかの実装グループが遭遇したいくつかの経験を要約します。ここでの私たちの議論は、ラップトップ、デスクトップ、サーバー、PDAなどの汎用コンピューティングプラットフォームにヒップを追加する際の実装者の経験に基づいています。このようなエンドホストで腰をサポートする2つの主要な方法があります。1つ目は、識別子とロケーターのデカップリングを直接サポートするために、カーネルの実装を変更することです。このタイプの変更にはデータスループットのパフォーマンスの利点がありますが、展開するのはより困難です。2番目のアプローチは、すべての股関節処理をユーザースペースに実装し、カーネルを構成して、股関節処理のためにユーザースペースを介してパケットをルーティングすることです。
The following public HIP implementations are known and actively maintained:
次の公開股関節の実装が既知であり、積極的に維持されています。
o HIP4BSD (http://www.hip4inter.net) -- FreeBSD kernel modifications and user-space keying daemon;
o hip4bsd（http://www.hip4inter.net） - freebsdカーネルの変更とユーザー空間キーイングデーモン。
o HIPL (http://hipl.hiit.fi) -- Linux kernel and user-space implementation;
o Hipl（http://hipl.hiit.fi） - Linuxカーネルとユーザー空間の実装。
o OpenHIP (http://www.openhip.org) -- User-space keying daemon and packet processing for Linux, Windows XP/Vista/7, and Apple OS X.
o オープンシップ（http://www.openhip.org） - Linux、Windows XP/Vista/7、およびApple OS Xのユーザー空間キーイングデーモンおよびパケット処理。
In the following, we first describe issues specific to the way in which HIP is added to a stack, then we discuss general issues surrounding both implementation approaches.
以下では、最初に股関節がスタックに追加される方法に固有の問題を説明し、次に両方の実装アプローチを取り巻く一般的な問題について説明します。
In this section, we focus on the support of HIP assuming the following:
このセクションでは、以下を仮定して、股関節のサポートに焦点を当てています。
o HIP is implemented by directly changing the TCP/IP stack implementation.
o HIPは、TCP/IPスタックの実装を直接変更することにより実装されます。
o Applications (using the sockets API) are unaware of HIP.
o アプリケーション（Sockets APIを使用）は、股関節を知りません。
A HIP implementation typically consists of a key management process that coordinates with an IPsec-extended stack, as shown in Figure 1. In practice, HIP has been implemented entirely in the user-space, entirely in the kernel, or as a hybrid with a user-space key management process and a kernel-level ESP.
通常、股関節の実装は、図1に示すように、IPSECが拡張したスタックと調整する主要な管理プロセスで構成されています。ユーザースペースのキー管理プロセスとカーネルレベルのESP。
+--------------------+ +--------------------+
| | | |
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec- | | ESP | | IPsec- | |
| | Extended | | | | Extended | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP Deployment Model
図1：股関節展開モデル
Figure 2 summarizes the main implementation impact of supporting HIP, and is discussed further in subsequent sections. To enable HIP natively in an implementation requires extensions to the key management interface (here depicted as PF_KEY API [RFC2367]) with the security association database (SAD) and security policy database (SPD). It also requires changes to the ESP implementation itself to support BEET-mode (Bound End-to-End Tunnel) processing [BEET-MODE], extensions to the name resolution library, and (in the future) interactions with transport protocols to respond correctly to mobility and multihoming events [TCP-RLCI].
図2は、股関節をサポートする主な実装の影響をまとめたものであり、後続のセクションでさらに説明します。実装で股関節をネイティブに有効にするには、セキュリティ協会データベース（SAD）およびセキュリティポリシーデータベース（SPD）を使用して、主要な管理インターフェイス（ここではPF_KEY API [RFC2367]として描写される）への拡張が必要です。また、BEETモード（バインドエンドツーエンドトンネル）処理[BEET-MODE]、名前解像度ライブラリへの拡張、および（将来）輸送プロトコルとの相互作用をサポートするために、ESP実装自体の変更が必要です。モビリティおよびマルチホームイベント[TCP-RLCI]。
|-----------------------|
-------- | ---------- ----------
| HIP |-- ----| App v6 | | App v4 |
-------- | | ---------- ----------
| | | | HIT | LSI
| ------------ | AF_INET6 | AF_INET
| | resolver | | |
| ------------ | sockets API | user-space
--|-------------------|-------------------------------
| sockets and | | kernel
| PF_KEY API --------- |
|-------------> |TCP/UDP|<-----------
| ---------
| |
---------- ---------
| SAD/SPD|<-----> | ESP | {HIT_s, HIT_d} <-> SPI
---------- --------- {HIT_s, HIT_d, SPI} <-> {IP_s,IP_d,SPI}
|
---------
| IP |
---------
Figure 2: Overview of Typical Implementation Changes to Support HIP
図2：股関節をサポートするための典型的な実装の変更の概要
Legacy applications can continue to use the standard AF_INET6 (for IPv6) and AF_INET (for IPv4) sockets API. IPv6 applications bind directly to a Host Identity Tag (HIT), which is a part of IPv6 address space reserved for ORCHIDs. IPv4 applications bind to a Local Scope Identifier (LSI) that has significance only within a host; the HIP layer translates from LSIs and HITs to the IP addresses that are still used underneath for HIP base exchange.
レガシーアプリケーションは、標準のAF_INET6（IPv6の場合）およびAF_INET（IPv4の場合）Sockets APIを引き続き使用できます。IPv6アプリケーションは、オーキッド用に予約されているIPv6アドレススペースの一部であるホストIDタグ（HIT）に直接バインドします。IPv4アプリケーションは、ホスト内でのみ有意性を持つローカルスコープ識別子（LSI）にバインドします。股関節層は、LSISから翻訳され、ヒップベース交換のためにまだ使用されているIPアドレスにヒットします。
HIP uses a Bound End-to-End Tunnel (BEET) mode of ESP operation, which mixes tunnel-mode semantics with transport-mode syntax. BEET is not supported by all operating system distributions at present, so kernel modifications might be needed to obtain true kernel support using existing IPsec code. At the time of writing, the BEET mode has been adopted to vanilla Linux and FreeBSD kernels.
HIPは、トンネルモードセマンティクスとトランスポートモード構文を混合するESP操作のバインドエンドツーエンドトンネル（ビート）モードを使用します。BEETは現在、すべてのオペレーティングシステム分布によってサポートされていないため、既存のIPSECコードを使用して真のカーネルサポートを取得するには、カーネルの変更が必要になる場合があります。執筆時点で、ビートモードはバニラLinuxとFreeBSDカーネルに採用されています。
The HIPL project has contributed an IPsec BEET patch for the Linux kernel. The kernel-level support could potentially allow all Linux implementations of HIP to run in the user-space and use a common interface towards the kernel.
HIPLプロジェクトは、LinuxカーネルのIPSECビートパッチに寄与しました。カーネルレベルのサポートにより、股関節のすべてのLinux実装がユーザースペースで実行され、カーネルに向けて共通のインターフェイスを使用できるようになる可能性があります。
One inconvenience experienced in current Linux IPsec implementation (due to the native IPsec implementation, not HIP specifically) is a loss of the first data packet that triggers the HIP association establishment. Instead, this packet should be cached and transmitted after the association is established.
現在のLinux IPSECの実装で経験された不便の1つは（具体的には股関節ではなく、ネイティブIPSECの実装により）であり、股関節協会の確立をトリガーする最初のデータパケットの損失です。代わりに、このパケットは、協会が確立された後にキャッシュされ、送信する必要があります。
HIP can be implemented entirely in the user-space, an approach that is essential for supporting HIP on hosts for which operating system modifications are not possible. Even on modifiable operating systems, there is often a significant deployment advantage in deploying HIP only as a user-space implementation. All three open-source implementations provide user-space implementations and binary packages (RPMs, DEBs, self-extracting installers) typical of application deployment on the target systems.
HIPは完全にユーザー空間に実装できます。これは、オペレーティングシステムの変更が不可能なホストの股関節をサポートするために不可欠なアプローチです。変更可能なオペレーティングシステムでさえ、ユーザースペースの実装としてのみ股関節を展開することに大きな展開の利点があることがよくあります。3つのオープンソースの実装はすべて、ユーザースペースの実装とバイナリパッケージ（RPM、DEB、自己抽出インストーラー）がターゲットシステムで典型的なアプリケーションの展開を提供します。
When HIP is deployed in the user-space, some technique is necessary to identify packets that require HIP processing and divert them to the user-space for such processing and to re-inject them into the stack for further transport protocol processing. A commonly used technique is to deploy a virtual device in the kernel such as a network tap (TAP) device, although operating systems may provide other means for diverting packets to user-space. Routing or packet filtering rules must be applied to divert the right packets to these devices.
ヒップがユーザー空間に展開される場合、股関節処理を必要とするパケットを識別し、そのような処理のためにユーザースペースに迂回し、さらに輸送プロトコル処理のためにスタックに再注入するには、いくつかの手法が必要です。一般的に使用される手法は、ネットワークタップ（TAP）デバイスなどのカーネルに仮想デバイスを展開することですが、オペレーティングシステムはパケットをユーザースペースに迂回させる他の手段を提供する場合があります。ルーティングまたはパケットフィルタリングルールを適用して、これらのデバイスに適切なパケットを迂回する必要があります。
As an example, the user-space implementation may install a route that directs all packets with destination addresses corresponding to HITs or LSIs to such a virtual device. In the user-space daemon, the ESP header and possibly the UDP header is applied, an outer IP address replaces the HIT, and the packet is re-sent to the kernel. In the reverse direction, a socket associated to ESP or a UDP port number may be used to receive ESP-protected packets. HIP signaling packets themselves may be sent and received by a raw socket bound to the HIP number or UDP port when UDP encapsulation is used.
例として、ユーザースペースの実装は、ヒットまたはLSIに対応する宛先アドレスをそのような仮想デバイスに向けて、すべてのパケットを指示するルートをインストールする場合があります。ユーザースペースデーモンでは、ESPヘッダーと場合によってはUDPヘッダーが適用され、外側のIPアドレスがヒットに置き換えられ、パケットがカーネルに再セントされます。逆方向には、ESPまたはUDPポート番号に関連付けられたソケットを使用して、ESP保護されたパケットを受け取ることができます。股関節シグナリングパケット自体は、UDPカプセル化を使用すると、股関節番号またはUDPポートにバインドされた生のソケットによって送信および受信される場合があります。
Much initial experimentation with HIP has involved using HITs directly in IPv6 socket calls, without any resolution infrastructure to learn the HIT based on, for example, a domain name, or to resolve the IP address. To experiment with HIP using HITs requires a priori HIT exchange, in the absence of a resolution service. Manual exchange of HITs has been a major inconvenience for experimentation. It can be overcome via 1) opportunistic HIP mode (RFC 5201, Section
股関節の多くの初期実験では、IPv6ソケットコールでヒットを直接使用することが含まれています。たとえば、ドメイン名に基づいてヒットを学習したり、IPアドレスを解決したりするための解像度インフラストラクチャがありません。ヒットを使用して股関節を試すには、解決サービスがない場合、先験的なヒット交換が必要です。ヒットの手動交換は、実験にとって大きな不便でした。1）日和見股関節モード（RFC 5201、セクションを介して克服できます
4.1.6), 2) storing HITs in DNS AAAA entries and looking them up by domain name, 3) name resolution service for HITs such as OpenDHT [RFC6537], 4) an ad hoc HIT exchange service to populate files on each machine, or 5) support for DNS extensions described in RFC 5205.
4.1.6）、2）DNS AAAAエントリにヒットを保存し、ドメイン名でそれらを調べる、3）OPENDHT [RFC6537]などのヒットの名前解像度サービス、4）各マシンのファイルを入力するアドホックヒット交換サービス、または5）RFC 5205で説明されているDNS拡張機能のサポート。
Over time, support for these techniques has varied. The HIPL project has experimented with all of them. OpenHIP lacks support for option 2, and HIP4BSD lacks support for options 1 and 3.
時間が経つにつれて、これらの技術のサポートはさまざまです。Hiplプロジェクトはそれらすべてを実験しました。オープンシップにはオプション2のサポートがなく、HIP4BSDにはオプション1および3のサポートがありません。
Implementing opportunistic HIP mode in a clean way is challenging, as HITs need to be known when an application binds or connects to a socket. Approach 2 has been difficult in practice due to resistance of sysadmins to include AAAA entries for HITs in the DNS server, and is a non-standards-compliant use of the resource record. Approach 3 is being progressed with two independent implementations of a HIP-OpenDHT interface. At the moment, the easiest way for enabling experimentation appears to be approach 4 when a shell script based on Secure SHell (SSH) and Secure Copy (SCP) can connect to a peer machine and copy HITs to the local configuration files. However, this approach is not scalable or secure for the long run. HIPL developers have had positive experiences with alternative 5.
アプリケーションがソケットにバインドまたは接続するときにヒットを知る必要があるため、日和見ヒップモードをクリーンな方法で実装することは困難です。SysadminsがDNSサーバーのヒットのAAAAエントリを含めることが抵抗があるため、アプローチ2は実際には困難であり、リソースレコードの非標準に準拠した使用です。アプローチ3は、HIP-Opendhtインターフェイスの2つの独立した実装で進行中です。現時点では、実験を可能にする最も簡単な方法は、セキュアシェル（SSH）とセキュアコピー（SCP）に基づいたシェルスクリプトがピアマシンに接続してローカル構成ファイルにヒットをコピーできる場合、アプローチ4であるように見えます。ただし、このアプローチは、長期的にはスケーラブルでも安全でもありません。Hipl開発者は、代替の肯定的な経験を積んでいます5。
In opportunistic mode, the Initiator starts a base exchange without knowledge of the Responder's HIT. The main advantage of the opportunistic mode is that it does not require additional lookup infrastructure for HIs [RFC5205] [RFC6537].
日和見モードでは、イニシエーターはレスポンダーのヒットを知らずに基本交換を開始します。日和見モードの主な利点は、彼の[RFC5205] [RFC6537]に追加のルックアップインフラストラクチャを必要としないことです。
The opportunistic mode also has a few disadvantages. First, the Initiator may not identify the Responder uniquely just based on the IP address in the presence of private address realms [RFC5770]. Second, the Initiator has to settle for a "leap of faith"; that is, assume there is no man-in-the-middle attack. However, this can be partially mitigated by using certificates at the Responder side [RFC6253] or by prompting the user using a graphical interface to explicitly accept the connection [paper.usable-security].
また、日和見モードにはいくつかの欠点があります。第一に、イニシエーターは、プライベートアドレスの領域[RFC5770]の存在下でのIPアドレスに基づいて、レスポンダーを一意に識別できない場合があります。第二に、イニシエーターは「信仰の飛躍」に落ち着かなければなりません。つまり、中間の攻撃がないと仮定します。ただし、これは、レスポンダー側[RFC6253]で証明書を使用するか、グラフィカルインターフェイスを使用して接続[Paper.Usable-Security]を明示的に受け入れることにより、部分的に軽減できます。
The opportunistic mode requires only minor changes in the state machine of the Responder and small changes for the Initiator [paper.leap-of-faith]. While the Responder can just select a suitable HIT upon receiving the first HIP base exchange packet (known as an "I1") without a predefined HIT for the Responder, the Initiator should be more careful in processing the first packet from the Responder, known as the "R1". For example, the Initiator should make sure that it can disambiguate simultaneously initiated opportunistic base exchanges from each other.
日和見モードでは、レスポンダーの状態マシンのわずかな変更と、イニシエーターの小さな変更のみが必要です[Paper.Leap-of Faith]。レスポンダーは、レスポンダーの事前定義されたヒットなしで最初の股関節ベース交換パケット（「i1」と呼ばれる）を受信すると適切なヒットを選択できますが、イニシエーターは、レスポンダーからの最初のパケットの処理をより注意する必要があります。「R1」。たとえば、イニシエーターは、互いに日和見的なベース交換を同時に開始することができることを確認する必要があります。
In the context of the HIPL project, the opportunistic mode has been successfully applied at the HIP layer for service registration [RFC5203]. HIP4BSD implemented opportunistic mode successfully with small modifications to the FreeBSD socket layer to support opportunistic mode. However, the Linux implementation was more challenging, as described below.
HIPLプロジェクトのコンテキストでは、日和見モードは、サービス登録のために股関節層で正常に適用されています[RFC5203]。HIP4BSDは、日和見モードをサポートするために、FreeBSDソケットレイヤーをわずかに変更して、日和見モードを正常に実装しました。ただし、以下で説明するように、Linuxの実装はより困難でした。
The HIPL project experimented with opportunistic mode by interposing a shim at two different layers. In the first approach, an API-based shim was implemented to capture socket calls from the application. This was somewhat complicated to implement and explicitly enabling an individual application (or groups of applications) to use the opportunistic mode was required. In the second approach [paper.leap-of-faith], the shim was placed between the network and transport layers. Upon successful base exchange, the shim translated IP-based packet flows to HIT-based packet flows by re-injecting the translated packets back to the networking stack.
Hiplプロジェクトは、2つの異なる層でシムを挿入することにより、日和見モードを実験しました。最初のアプローチでは、アプリケーションからソケット呼び出しをキャプチャするためにAPIベースのSHIMが実装されました。これは、個々のアプリケーション（またはアプリケーションのグループ）が日和見モードを使用することを実装し、明示的に有効にすることを明示的に有効にすることが幾分複雑でした。2番目のアプローチ[Paper.leap-offaith]では、シムはネットワーク層と輸送層の間に配置されました。ベース交換が成功すると、シムはIPベースのパケットを翻訳して、翻訳されたパケットをネットワークスタックに戻すことにより、ヒットベースのパケットフローをフローします。
Unless bypassed for DNS, both of the opportunistic mode implementation approaches in HIPL subjected the application(s) to undergo opportunistic mode procedures also for DNS requests. Both approaches also implemented an optional "fall back" to non-HIP base connectivity if the peer did not support HIP. The detection of peer support for HIP was based on timeouts. To avoid timeouts completely and to reduce the delay to a single Round-Trip Time (RTT) for TCP, the project also experimented with TCP-specific extensions [thesis.bishaj].
DNSをバイパスしない限り、HIPLの日和見モードの実装アプローチの両方が、アプリケーションをDNS要求に対して日和見モードの手順を受けるようにしました。どちらのアプローチも、ピアが股関節をサポートしていない場合、オプションの「フォールバック」を非ヒップベース接続に実装しました。股関節のピアサポートの検出は、タイムアウトに基づいていました。タイムアウトを完全に回避し、TCPの1回の往復時間（RTT）までの遅延を減らすために、プロジェクトはTCP固有の拡張を実験しました[Thesis.bishaj]。
The OpenHIP project experimented with opportunistic mode through the use of an opportunistic (-o) option. For the Responder, this option determines whether or not HIP accepts I1s received with a zeroed receiver's HIT. On the Initiator's side, this option allows one to configure a name and LSI in the known Host Identities file. When the HIT field is missing, an I1 is sent with a zeroed receiver's HIT. The LSI is needed by an IPv4 application to trigger the association. Note that, normally, the LSI used is based on the bottom 24 bits of the HIT, but in the case of opportunistic mode, the HIT is unknown; thus, the LSI may differ from the HIT.
オープンシッププロジェクトは、日和見（-O）オプションを使用して日和見モードを実験しました。応答者の場合、このオプションは、股関節がゼロのレシーバーのヒットで受信したI1を受け入れるかどうかを決定します。イニシエーター側では、このオプションを使用すると、既知のホストIDファイルで名前とLSIを構成できます。ヒットフィールドが欠落している場合、i1はゼロのレシーバーのヒットで送信されます。LSIは、AssociationをトリガーするためにIPv4アプリケーションによって必要です。通常、使用されるLSIはヒットの下位24ビットに基づいているが、日和見モードの場合、ヒットは不明であることに注意してください。したがって、LSIはヒットと異なる場合があります。
As a summary of the opportunistic mode experimentation, it is possibly best suited for HIP-aware applications. Either it can be used by HIP itself in registration extensions or by native HIP applications [RFC6317]. This way, the inherent security trade-offs of the opportunistic mode are explicitly visible to the user through the HIP-aware application.
日和見モードの実験の概要として、ヒップアウェアアプリケーションに最適な可能性があります。登録拡張またはネイティブの股関節アプリケーション[RFC6317]で使用できるようにすることができます。これにより、日和見モードの固有のセキュリティトレードオフは、ヒップアウェアアプリケーションを通じてユーザーに明示的に表示されます。
When HIP is used in opportunistic mode, the Initiator does not know the Responder's HIT, but it does know its IP address. In most other cases, however, the kernel or applications may know the HITs and not the IP addresses; in these cases, an IP address resolution step for HITs must take place.
股関節が日和見モードで使用される場合、イニシエーターはレスポンダーのヒットを知りませんが、IPアドレスを知っています。ただし、他のほとんどの場合、カーネルまたはアプリケーションは、IPアドレスではなくヒットを知っている場合があります。これらの場合、ヒットのIPアドレス解決ステップが行われなければなりません。
A few techniques have been experimented with. First, OpenDHT can also use HITs as keys for IP address records. Second, work by Ponomarev has shown that the reverse DNS tree may be used for reverse lookups of the ORCHID space [HIT2IP]. Third, the need for resolution may trigger some type of HIP bootstrap message, similar in some sense to an Address Resolution Protocol (ARP) message (to resolve the HIT). The bootstrap (BOS) packet used to be present in the early revisions of the HIP base specifications, but it was removed from the final specifications due to insufficient interest at the time. The HIPL implementation currently sends an I1 to a link broadcast IP address if it doesn't know the IP address of the peer. It has triggered warnings in some Windows hosts running antivirus software that classified broadcasts with unknown protocol number as intrusion attempts. The utility of this technique is limited to the local link.
いくつかのテクニックが実験されています。まず、OpendhtはIPアドレスレコードのキーとしてヒットを使用することもできます。第二に、Ponomarevによる作業は、逆DNSツリーがラン空間の逆検索に使用される可能性があることを示しています[HIT2IP]。第三に、解像度の必要性は、ある意味で、ある意味でアドレス解像度プロトコル（ARP）メッセージ（ヒットを解決するため）と同様に、何らかのタイプのヒップブートストラップメッセージをトリガーする場合があります。ブートストラップ（BOS）パケットは、以前はヒップベース仕様の初期改訂に存在していましたが、当時の関心が不十分なため、最終仕様から削除されました。HIPL実装は現在、ピアのIPアドレスがわからない場合、I1をリンクブロードキャストIPアドレスに送信します。一部のWindowsホストでは、プロトコル数が不明なブロードキャストを侵入の試みとして分類するWindowsホストの一部で警告がトリガーされています。この手法の有用性は、ローカルリンクに限定されています。
A generic key management API for IP security is known as PF_KEY API [RFC2367]. PK_KEY is a socket protocol family that can be used by trusted applications to access the IPsec key engine in the operating system. Users of this interface typically need sysadmin privileges.
IPセキュリティの一般的なキー管理APIは、PF_KEY API [RFC2367]として知られています。PK_KEYは、オペレーティングシステムのIPSECキーエンジンにアクセスするために、信頼できるアプリケーションで使用できるソケットプロトコルファミリです。このインターフェイスのユーザーは通常、Sysadmin特権が必要です。
HIP-related extensions to the PF_KEY interface define a new protocol IPPROTO_HIP. Their main functionality is replacing the TCP and UDP checksum with a HIP-compatible checksum (because the transport pseudoheader is based on HITs) in incoming and outgoing packets. Recent Linux kernel versions do not require patching for these extensions.
PF_KEYインターフェイスへの股関節関連拡張機能は、新しいプロトコルIPProTO_HIPを定義します。それらの主な機能は、着信パケットと発信パケットのTCPおよびUDPチェックサムを股関節互換チェックサム（トランスポート擬似ヘッダーがヒットに基づいているため）に置き換えることです。最近のLinuxカーネルバージョンでは、これらの拡張機能にパッチする必要はありません。
When an application triggers a HIP base exchange through the transport protocol, the first data packet can be lost unless the HIP and IPsec implementation is able to buffer the packet until the base exchange completes and IPsec SAs are set up. The loss of the data packet when it is a TCP SYN packet results in TCP timeout [RFC6298] that unnecessarily delays the application. A loss of a UDP packet can cause even longer timeouts in applications. Therefore, it was found to be important for HIP implementations to support the
アプリケーションがトランスポートプロトコルを介して股関節ベース交換をトリガーすると、股関節とIPSECの実装がベース交換が完了し、IPSEC SASがセットアップされるまでパケットをバッファリングできない限り、最初のデータパケットを失う可能性があります。TCP Synパケットである場合のデータパケットの損失により、TCPタイムアウト[RFC6298]がアプリケーションを不必要に遅延させます。UDPパケットを失うと、アプリケーションでさらに長いタイムアウトが発生する可能性があります。したがって、股関節の実装がサポートすることが重要であることがわかった
buffering of the packet. On the other hand, if the HIP base exchange or UPDATE takes longer than 1 second, which is the case on lightweight devices, a spurious timeout can occur at the transport layer. The HIP implementation could prevent this scenario by manipulating timeout values at the transport layer or, alternatively, dropping the original or retransmitted duplicate packet.
パケットのバッファリング。一方、股関節のベース交換または更新が1秒以上かかる場合、これは軽量デバイスの場合である場合、輸送層でスプリアスタイムアウトが発生する可能性があります。股関節の実装は、輸送層でタイムアウト値を操作するか、あるいは元のまたは再送信された重複パケットを削除することにより、このシナリオを防ぐことができます。
The multihoming support in [RFC5206] is intended for the purpose of failover, when a host starts using an alternative locator when a current locator fails. However, a host could used this multihoming support for load balancing across different locators. Multihoming in this manner could potentially cause issues with transport protocol congestion control and loss detection mechanisms. However, no experimental results from using HIP multihoming in this capacity have been reported.
[RFC5206]のマルチホームサポートは、現在のロケーターが故障したときにホストが代替ロケーターの使用を開始したときに、フェイルオーバーの目的を目的としています。ただし、ホストは、さまざまなロケーター間の負荷分散にこのマルチホームサポートを使用できます。この方法でのマルチホームは、輸送プロトコルの混雑制御と損失検出メカニズムの問題を引き起こす可能性があります。ただし、この能力で股関節マルチホームを使用したことによる実験結果は報告されていません。
The use of paths with different characteristics can also impact the estimate of a retransmission timer at the sender's transport layer. TCP uses a smoothed average of the path's Round-Trip Time and its variation as the estimate for a retransmission timeout. After the retransmission timer expires, the sender retransmits all outstanding packets in go-back-N fashion.
異なる特性を持つパスの使用は、送信者の輸送層での再送信タイマーの推定にも影響を与える可能性があります。TCPは、再送信タイムアウトの推定として、パスの往復時間とその変動の平均平均を使用します。再送信タイマーの有効期限が切れた後、送信者はGo-Back-Nファッションですべての未解決のパケットを再送信します。
When multihoming is used for simultaneous data transmission from several locators, there can easily be scenarios when the retransmission timeout does not correspond to the actual value. When packets simply experience different RTT, its variation is high, which sets the retransmission timeout value unnecessarily high. When packets are lost, the sender waits excessively long before retransmitting. Fortunately, modern TCP implementations deploying Selective Acknowledgments (SACKs) and Limited Transmit are not relying on retransmission timeouts except when most outstanding packets are lost.
複数のロケーターからの同時データ送信にマルチホミングが使用される場合、再送信タイムアウトが実際の値に対応しない場合、シナリオが簡単に存在する可能性があります。パケットが異なるRTTを単に経験すると、その変動が高く、再送信タイムアウト値が不必要に高くなります。パケットが失われると、送信者は再送信されるまでずっと待ちます。幸いなことに、最新のTCP実装は、選択的な謝辞（SACK）と限られた送信を展開し、ほとんどの未解決のパケットが失われた場合を除き、再送信のタイムアウトに依存していません。
Load balancing among several paths requires some estimate of each path's capacity. The TCP congestion control algorithm assumes that all packets flow along the same path. To perform load balancing, the HIP layer can attempt to estimate parameters such as the delay, bandwidth, and loss rate of each path. A HIP scheduler could then distribute packets among the paths according to their capacity and delay, to maximize overall utilization and minimize reordering. The design of the scheduler is a topic of current research work; none are reported to exist. Different network paths can have different Maximum Transmission Unit (MTU) sizes. Transport protocols perform MTU discovery typically only in the beginning of a connection. As HIP hides mobility from the transport layer, it can happen that packets on the new path get fragmented without knowledge of the transport protocol. To solve this problem, the HIP layer could
いくつかのパス間のロードバランスには、各パスの容量の推定値が必要です。TCP混雑制御アルゴリズムは、すべてのパケットが同じパスに沿って流れることを前提としています。負荷分散を実行するために、股関節層は、各パスの遅延、帯域幅、損失率などのパラメーターを推定しようとします。股関節スケジューラは、容量と遅延に応じてパスにパケットを配布して、全体的な利用を最大化し、並べ替えを最小限に抑えることができます。スケジューラの設計は、現在の研究作業のトピックです。存在すると報告されていません。異なるネットワークパスは、異なる最大伝送ユニット（MTU）サイズを持つことができます。輸送プロトコルは、通常、接続の開始時にのみMTU発見を実行します。股関節が輸送層から移動度を隠すと、新しいパス上のパケットが輸送プロトコルの知識なしに断片化されることが起こります。この問題を解決するために、股関節層が可能です
inform the transport layer of mobility events. Protocols to support such notifications to the transport layer have been proposed to the IETF in the past, including transport triggers [TRIGTRAN], lightweight mobility detection and response (LMDR) [LMDR], and TCP response to connectivity change [TCP-RLCI].
モビリティイベントの輸送層を通知します。輸送層へのこのような通知をサポートするプロトコルは、輸送トリガー[Trigtran]、軽量モビリティ検出および応答（LMDR）[LMDR]、および接続変化[TCP-RLCI]に対するTCP応答など、過去にIETFに提案されています。
Legacy NAT traversal for outbound-initiated connections to a publicly addressed Responder has been implemented by all three HIP implementations; two (HIPL and HIP4BSD) implement Interactive Connectivity Establishment (ICE) techniques [RFC5770] for inbound NAT traversal. It has also been reported that the use of Teredo [RFC4380] over HIP was simpler than the modifications required for ICE techniques because Teredo effectively manifests itself as a routable, virtual locator to the system. UDP encapsulation is now the default mode of HIP operation for OpenHIP's IPv4 HIP implementation. Finding an IPv6 NAT implementation for experiments has been difficult. In addition, the initial implementations of NAT traversal for HIP based on ICE techniques proved to be complicated to implement or integrate, and a native NAT traversal mode is now under development for HIP [NAT-TRAVERSAL]. NAT traversal is expected to be a major mode of HIP operation in the future.
公開されたレスポンダーへのアウトバウンド開始接続のレガシーNATトラバーサルは、3つの股関節実装すべてによって実装されています。2つの（HiplおよびHip4BSD）インバウンドNATトラバーサルのためのインタラクティブ接続確立（ICE）テクニック[RFC5770]を実装します。また、Teredoがシステムのルーティング可能な仮想ロケーターとして効果的に現れているため、Teredo [RFC4380]を股関節に介して必要な変更よりも単純であると報告されています。UDPカプセル化は、OpenipのIPv4 HIP実装のヒップ操作のデフォルトモードになりました。実験用のIPv6 NAT実装を見つけることは困難です。さらに、ICE技術に基づいた股関節のNATトラバーサルの初期実装は、実装または統合が複雑であることが判明し、ネイティブNATトラバーサルモードは現在、股関節[NAT-Traversal]のために開発中です。NATトラバーサルは、将来の股関節操作の主要なモードになると予想されます。
One issue not being addressed by some experimental implementations is how to perform source HIT selection across possibly multiple host identities (some may be unpublished). This is akin to source address selection for transport sockets. How much HIP policy to expose to users is a user interface issue. Default or automatic configuration guesses might have undesirable privacy implications for the user.
いくつかの実験的な実装で対処されていない問題の1つは、複数のホストIDでソースヒット選択を実行する方法です（一部は未発表の場合があります）。これは、輸送ソケットのソースアドレス選択に似ています。ユーザーにどの程度ヒップポリシーを公開するかは、ユーザーインターフェイスの問題です。デフォルトまたは自動構成の推測は、ユーザーにとって望ましくないプライバシーの影響を与える可能性があります。
Helsinki University of Technology (TKK, now Aalto) has implemented an extension of the native HIP API to control multiple host identities [thesis.karlsson]. A problem with Linux routing and multiple identities was discovered by the HIPL development group. As Linux routing is based on longest prefix match, having multiple HITs on virtual devices is problematic from the viewpoint of access control because the stack selects the source HIT based on the destination HIT. A coarse-grained solution for this is to terminate the longest prefix match for ORCHIDs in the Linux networking statck. However, a more fine-grained solution tries to return a source HIT matching to the algorithm used for generating the destination HIT in order to facilitate compatibility with new algorithms standardized in the future.
ヘルシンキ工科大学（TKK、現在のAalto）は、複数のホストID [Thesis.Karlsson]を制御するために、ネイティブのHIP APIの拡張を実装しています。Linuxルーティングと複数のIDの問題が、Hipl Development Groupによって発見されました。Linuxルーティングは最長のプレフィックスマッチに基づいているため、スタックが宛先ヒットに基づいてソースヒットを選択するため、仮想デバイスで複数のヒットを持つことはアクセス制御の観点から問題です。このための粗粒のソリューションは、LinuxネットワーキングSTATCKのオーキッドの最長のプレフィックスマッチを終了することです。ただし、より微調整されたソリューションは、将来標準化された新しいアルゴリズムとの互換性を容易にするために、宛先ヒットを生成するために使用されるアルゴリズムに一致するソースヒットを返しようとします。
There are security and privacy issues with storing private keys securely on a host. Current implementations simply store private keys in a file that is readable only by applications with root privileges. This may not be a sufficient level of protection, as keys could be read directly from the disk or, e.g., some application with a set-user-id flag. Keys may be stored on a trusted platform module (TPM), but there are no reported HIP experiments with such a configuration. In a Boeing pilot project, temporary certificates were generated from a key on a USB SIM chip and used in the HIP base exchange. Use of certificates in HIP requires extensions to the HIP specifications [RFC6253]. Another option is encrypting keys on disks and keeping a passkey in memory (like in Secure Socket Layer (SSL) certificates on servers, that ask for a password when booting Linux).
ホストにプライベートキーを安全に保存することには、セキュリティとプライバシーの問題があります。現在の実装は、ルート特権を持つアプリケーションでのみ読み取ることができるファイルにプライベートキーを保存するだけです。キーはディスクから直接読み取ることができるため、またはセットユーザーフラグを備えたいくつかのアプリケーションを読み取ることができるため、これは十分なレベルの保護ではないかもしれません。キーは、信頼できるプラットフォームモジュール（TPM）に保存される場合がありますが、そのような構成を伴う股関節実験は報告されていません。ボーイングパイロットプロジェクトでは、USB SIMチップのキーから一時的な証明書が生成され、HIPベース交換で使用されました。股関節で証明書を使用するには、股関節仕様の拡張が必要です[RFC6253]。別のオプションは、ディスク上のキーを暗号化し、パスキーをメモリに保持することです（Linuxを起動するときにパスワードを要求するサーバー上のセキュアソケットレイヤー（SSL）証明書など）。
HIP is presently an experimental protocol, and some default firewall configuration scripts on popular Linux distributions do not permit the HIP number. Determining which rules to modify without compromising other policies can be tricky; the default rule set on a previous SuSE Linux distribution was discovered to contain over one hundred rules. Moreover, it may be the case that the end user has no control over the firewall settings, if administered by an enterprise IT department. However, the use of HIP over UDP has alleviated some of these concerns. When using HIP over UDP, the firewall needs to allow outbound UDP packets and responses to them.
HIPは現在、実験的なプロトコルであり、人気のLinux分布に関するいくつかのデフォルトのファイアウォール構成スクリプトでは、股関節数を許可しません。他のポリシーを損なうことなく変更するルールを決定することは難しい場合があります。以前のSuse Linux分布に設定されたデフォルトのルールには、100を超えるルールが含まれていることが発見されました。さらに、エンタープライズIT部門で管理されている場合、エンドユーザーがファイアウォール設定を制御できない場合があります。ただし、UDPを介した股関節の使用は、これらの懸念の一部を軽減しています。UDPで股関節を使用する場合、ファイアウォールはアウトバウンドUDPパケットとそれらへの応答を許可する必要があります。
HIP has been oriented towards IPv6 deployment, but all implementations have also added support for IPv4. HIP supports IPv6 applications well, as the HITs are used from the general IPv6 address space using the ORCHID prefix. HITs are statistically unique, although they are not routable at the IP layer. Therefore, a mapping between HITs and routable IP addresses is necessary at the HIP layer, unless an overlay network or broadcast technique is available to route packets based on HITs.
HIPはIPv6の展開に向けられていますが、すべての実装もIPv4のサポートを追加しています。HIPは、Orchidプレフィックスを使用して一般的なIPv6アドレス空間からヒットが使用されるため、IPv6アプリケーションをよくサポートします。ヒットは統計的に一意ですが、IPレイヤーではルーティングできません。したがって、ヒットに基づいてパケットをルーティングするためにオーバーレイネットワークまたはブロードキャスト手法を使用できない限り、ヒットレイヤーではヒットとルーティング可能なIPアドレスの間のマッピングが必要です。
For IPv4 applications, a 32-bit Local Scope Identifier (LSI) is necessary at the sockets API. The LSI is an alias for a host identity and is only meaningful within one host. Note that an IPv4 address may be used as an LSI if it is configured to refer to a particular host identity on a given host, or LSIs may be drawn from an unallocated IPv4 address range, but lack of coordination on the LSI space may hinder implementation portability.
IPv4アプリケーションの場合、Sockets APIで32ビットローカルスコープ識別子（LSI）が必要です。LSIはホストIDのエイリアスであり、1つのホスト内でのみ意味があります。特定のホストの特定のホストIDを参照するように構成されている場合、IPv4アドレスはLSIとして使用される可能性があることに注意してください。または、LSIが未割り当てのIPv4アドレス範囲から描画される場合がありますが、LSI空間の調整の欠如は実装を妨げる可能性があります。移植性。
HIP makes it possible to use IPv6 applications over the IPv4 network and vice versa. This has been called "interfamily operation" (flexibility between different address families) and is enabled by the fact that the transport pseudoheader is always based on HITs regardless of whether the application or the underlying network path is based on IPv4. All three open source HIP implementations have demonstrated some form of interfamily handoff support. The interfamily portion of the BEET patch in the Linux kernel was found more difficult to complete compared with the single-family processing.
HIPは、IPv4ネットワークでIPv6アプリケーションを使用することを可能にし、その逆も同様です。これは「インターファミリー操作」（異なるアドレスファミリ間の柔軟性）と呼ばれており、アプリケーションまたは基礎となるネットワークパスがIPv4に基づいているかどうかに関係なく、輸送擬似ヘッダーが常にヒットに基づいているという事実によって有効になっています。3つのオープンソースの股関節実装はすべて、何らかの形の授業間ハンドオフサポートを実証しています。Linuxカーネルのビートパッチの施設間部分は、単一家族処理と比較して完了するのがより困難であることがわかりました。
HIP also provides the potential to perform cross-family support, whereby one side of a transport session is IPv6 based and another is IPv4 based [paper.handovers].
HIPはまた、輸送セッションの片側がIPv6ベースであり、別の側がIPv4ベース[Paper.Handovers]であるため、家族を横断するサポートを実行する可能性も提供します。
Implementing HIP in current stacks or as overlays on unmodified stacks has generally been successful. Below are some caveats and open issues.
現在のスタックに股関節を実装するか、変更されていないスタックのオーバーレイとして一般的に成功しています。以下は、いくつかの警告と未解決の問題です。
Experimental results comparing a kernel versus user-space HIP implementations in terms of performance and DoS resilience would be useful. If the kernel implementation is shown to perform significantly better than the user-space implementation, it may be a sufficient justification to incorporate HIP within the kernel. However, experiences on general purpose laptops and servers suggests that for typical client use of HIP, user-space implementations perform adequately.
パフォーマンスとDOS回復力の観点からカーネルとユーザースペースの股関節の実装を比較する実験結果が役立ちます。カーネルの実装がユーザースペースの実装よりも大幅に優れていることが示されている場合、カーネルに股関節を組み込むのに十分な正当化である可能性があります。ただし、汎用のラップトップとサーバーでの経験は、股関節の典型的なクライアントの使用のために、ユーザー空間の実装が適切に機能することを示唆しています。
Although the HIPL kernel-based keying implementation was submitted to the Linux kernel development process, the implementation was not accepted. The kernel developers felt that since Mobile IP (MIP) and the Internet Key Exchange Protocol (IKE) are implemented as user-space signaling daemons in Linux, that should be the approach for HIP, too. Furthermore, the kernel patch was somewhat big, affecting the kernel in many places and having several databases. The Linux kernel maintainers did eventually accept the BEET patch.
Hipl Kernelベースのキーイング実装はLinuxカーネル開発プロセスに提出されましたが、実装は受け入れられませんでした。カーネル開発者は、モバイルIP（MIP）とインターネットキーエクスチェンジプロトコル（IKE）がLinuxのユーザースペースシグナリングデーモンとして実装されているため、これも股関節のアプローチであると感じていました。さらに、カーネルパッチはやや大きく、多くの場所でカーネルに影響を与え、いくつかのデータベースを持っています。Linuxカーネルメンテナーは、最終的にビートパッチを受け入れました。
Some users have been explicitly asking about the coexistence of HIP with other VPN and Mobile IP software. On Windows, VPN clients tend to install their own versions of TAP drivers that might conflict with the driver used by the OpenHIP implementation. There may also be issues due to lack of coordination leading to unintended HIP-over-VPN sessions or lack of coordination of the ESP Security Parameter Index (SPI) space. However, these types of conflicts are only speculation
一部のユーザーは、他のVPNおよびモバイルIPソフトウェアとの股関節の共存について明示的に尋ねています。Windowsでは、VPNクライアントは、オープンシップの実装で使用されるドライバーと競合する可能性のあるタップドライバーの独自のバージョンをインストールする傾向があります。また、意図しないヒップオーバーVPNセッションやESPセキュリティパラメーターインデックス（SPI）スペースの調整の欠如につながる調整の欠如のために問題がある場合もあります。ただし、これらのタイプの紛争は推測にすぎません
and were not reported to the research group; only some positive reports of HIP and VPN software properly coexisting have been reported by the HIPL group.
研究グループに報告されませんでした。HIPとVPNソフトウェアの適切な共存のいくつかの肯定的な報告のみが、Hipl Groupによって報告されています。
With legacy applications, LSI support is important because IPv6 is not widely used in applications. The main issues in getting applications to work well over HIP have been related to bugs in the implementations themselves, or latency related issues (such as TCP timeouts due to Linux IPsec implementation). There have been no major obstacles encountered in practice, and there has also been some experience in using HIP with native applications [paper.p2psip].
Legacyアプリケーションでは、IPv6はアプリケーションで広く使用されていないため、LSIサポートが重要です。アプリケーションを股関節でうまく機能させることの主な問題は、実装自体のバグ、または遅延関連の問題（Linux IPSECの実装によるTCPタイムアウトなど）に関連しています。実際には大きな障害が発生することはなく、ネイティブアプリケーションで股関節を使用した経験もありました[Paper.P2PSIP]。
This section focuses on the deployment of infrastructure to support HIP hosts.
このセクションでは、ヒップホストをサポートするインフラストラクチャの展開に焦点を当てています。
HIP DNS extensions [RFC5205] were developed by NEC Eurolabs and contributed to OpenHIP and were also developed by the HIPL project, both for the BIND9 DNS server. Legacy applications do not query for HIP resource records, but DNS proxies (local resolvers) interpose themselves in the resolution path and can query for HI records. The BIND 9 deployment for HIPL uses binary blob format to store the HIP resource records; this means that no changes to the DNS server are required.
HIP DNS拡張[RFC5205]はNEC Eurolabsによって開発され、Openipに貢献し、BIND9 DNSサーバーの両方でHiplプロジェクトによって開発されました。レガシーアプリケーションは股関節リソースレコードをクエリするのではありませんが、DNSプロキシ（ローカルリゾルバー）は解像度パスに干渉し、HIレコードをクエリすることができます。HiplのBind 9展開は、バイナリBLOB形式を使用して、股関節リソースレコードを保存します。これは、DNSサーバーに変更が不要であることを意味します。
There have been no studies reported on the impact of changes based on [RFC5205] to HIP on the existing DNS. There have been some studies on using DNS to store HITs in the reverse tree [HIT2IP].
[RFC5205]に基づく変化が既存のDNSに股関節に陥ったことの影響に関する研究は報告されていません。DNSを使用してリバースツリーにヒットを保存することに関するいくつかの研究がありました[HIT2IP]。
A design of a HIP registration protocol for architectured NATs (NATs that are HIP aware and use HIP identifiers to distinguish between hosts) has been completed and published as RFC 5204. Performance measurement results with a prototype are available, but experimentation on a wide scale is still missing. RFC 5207 provides a problem statement for HIP-aware NATs and middleboxes [RFC5207].
アーキテクテッドNAT（股関節を認識し、股関節識別子を使用してホストを区別するNAT）の股関節登録プロトコルの設計が完了し、RFC 5204として公開されました。まだ見つかっていない。RFC 5207は、股関節を認識したNATとミドルボックスの問題声明を提供します[RFC5207]。
As argued by Aura, et al. [paper.hipanalysis], the encryption of the Initiator Host Identity (HI) prevents policy-based NAT and firewall support, and middlebox authentication, for HIP. The catch is that when the HI is encrypted, middleboxes in the network cannot verify the signature of the second base exchange packet from the Initiator
オーラが議論したように、他[Paper.hipanalysis]、イニシエーターホストID（HI）の暗号化は、股関節のポリシーベースのNATおよびファイアウォールサポート、およびミドルボックス認証を防ぎます。キャッチは、HIが暗号化された場合、ネットワーク内のミドルボックスがイニシエーターからの2番目のベース交換パケットの署名を確認できないということです。
(I2) and, thus, cannot safely create a state for the HIP association. On the other hand, if the HI is not encrypted, a stateful middlebox can process the I2 and create protocol state for the session.
（i2）したがって、股関節関連の状態を安全に作成することはできません。一方、HIが暗号化されていない場合、ステートフルミドルボックスはi2を処理し、セッションのプロトコル状態を作成できます。
OpenDHT HIT-to-IP address resolution has been implemented by Aalborg University, Denmark, Helsinki Institute for Information Technology for HIPL, and by Boeing for OpenHIP [RFC6537].
Opendht Hit-to-IPアドレスの解決は、Helsinki Institute for HiplのAalborg University、Helsinki Institute for Hipl、およびBoeing for Openip [RFC6537]によって実装されています。
The prototype of the Host Identity Indirection Infrastructure (Hi3) has been implemented using OpenHIP and HIPL. A set of 25 i3 servers was running on PlanetLab for several years. While a PlanetLab account is required to run the servers, anybody could openly use the provided service.
ホストIDの間接インフラストラクチャ（HI3）のプロトタイプは、オープンシップとHiplを使用して実装されています。25のI3サーバーのセットが数年間PlanetLabで実行されていました。Serversを実行するにはPlanetLabアカウントが必要ですが、誰でも提供されたサービスを公然と使用できます。
The main idea of Hi3 is to transmit HIP control packets using the i3 system as a lookup and rendezvous service, while transmitting data packets efficiently end-to-end using IPsec. Performance measurements were conducted comparing the association setup latency, throughput, and RTT of Hi3 with plain IP, HIP, and i3 [paper.hi3].
HI3の主な考え方は、I3システムを使用してルックアップおよびランデブーサービスとして使用して、股関節制御パケットを送信し、IPSECを使用してデータパケットをエンドツーエンドで効率的に送信することです。パフォーマンス測定は、HI3の関連性のレイテンシ、スループット、およびRTTを平易なIP、股関節、およびI3と比較して実施しました[Paper.Hi3]。
One difficulty has been with debugging the i3 system. In some cases, the messages did not traverse i3 correctly, due to its distributed nature and lack of tracing tools. Making the system work has been challenging. Further, since the original research work was done, the i3 servers have gone offline.
1つの難しさが、i3システムのデバッグです。場合によっては、その分散された性質とトレースツールの欠如のために、メッセージはi3を正しく通過しませんでした。システムを機能させることは困難です。さらに、元の研究作業が行われたため、i3サーバーはオフラインになりました。
NATs and firewalls have been a major disturbance in Hi3 experiments. Many networks did not allow incoming UDP packets to go through, therefore, preventing messages from i3 servers to reach the client.
NATとファイアウォールは、HI3実験の大きな妨害でした。多くのネットワークでは、着信UDPパケットが通過することを許可していなかったため、i3サーバーからのメッセージがクライアントに到達するのを防ぎました。
So far, the Hi3 system has been evaluated on a larger scale only analytically. The problem is that running a larger number of clients to create a sufficient load for the server is difficult. A cluster on the order of a hundred Linux servers is needed for this purpose. Contacts to a State Supercomputer Centre in Finland have not been successful so far. A possible option is to use one of the existing Emulab installations, e.g., in Utah, for these tests.
これまでのところ、HI3システムは、分析的にのみ大規模に評価されてきました。問題は、サーバーに十分な負荷を作成するために多くのクライアントを実行することが困難であることです。この目的のために、100のLinuxサーバーのオーダーのクラスターが必要です。フィンランドの州のスーパーコンピューターセンターへの連絡先は、これまで成功していません。考えられるオプションは、これらのテストには、既存のEMULABインストールの1つを使用することです。
A rendezvous server (RVS) [RFC5204] has been implemented by HIIT for HIPL, and an implementation also exists for OpenHIP. The concept has been extended to a relay server in [RFC5770]. Initial experimentation with the HIPL implementation produced the following observations:
Rendezvous Server（RVS）[RFC5204]がHIITのためにHIITによって実装されており、実装もオープンシップのために存在します。この概念は、[RFC5770]のリレーサーバーに拡張されています。Hipl実装を使用した最初の実験により、次の観察結果が生成されました。
o RVS may be better than dynamic DNS updates for hosts that change their address rapidly.
o RVは、アドレスを迅速に変更するホストの動的DNS更新よりも優れている場合があります。
o Registration of a HIP host to RVS costs a base exchange.
o RVSの股関節ホストの登録には、基本交換がかかります。
o UPDATE and CLOSE packets sent through rendezvous servers is advised; RVS handling of UPDATE messages can typically solve the double jump [MULTI-HOMED] mobility problem.
o Rendezvousサーバーを介して送信されるパケットを更新および閉じることをお勧めします。RVSアップデートメッセージの処理は、通常、ダブルジャンプ[マルチホーム]モビリティの問題を解決できます。
The following advanced concepts need further study:
次の高度な概念にはさらなる研究が必要です。
o Multiple RVSs per host for fault tolerance (e.g., one rendezvous node crashes) and an algorithm for selecting the best RVS.
o 障害トレランスのためのホストあたりの複数のRVS（たとえば、1つのランデブーノードがクラッシュする）と、最適なRVを選択するためのアルゴリズム。
o Load balancing. An RVS server could distribute I1s to different Responders if the Responder's identity is shared or opportunistic HIP is used.
o ロードバランシング。RVSサーバーは、Responderの身元が共有されているか、日和見股関節が使用されている場合、I1を異なるレスポンダーに配布できます。
o Offering a rendezvous service in a P2P fashion by HIP hosts.
o ヒップホストによるP2Pファッションでランデブーサービスを提供します。
In addition to pure DNS and pure DHT HIP name resolution, a hybrid approach combining the standard DNS interface for clients with last-hop DHT resolution was developed. The idea is that the benefits of DNS solution (wide deployment, support for legacy applications) could be combined with advantages of DHT (fault tolerance, efficiency in handling flat data keys). The DHT is typically run internally by the organization managing the last-hop DNS zone and the DNS server. That way, the HITs belonging to that organization could be stored locally by the organization that improves deployability of the resolution system. However, organizations could also share a DHT between themselves or connect their DNS servers to a publicly available DHT, such as OpenDHT. The benefit of running a DHT on a local server cluster compared to a geographically spread DHT is higher performance due to decreased internal DHT latencies.
純粋なDNSと純粋なDHTヒップ名の解像度に加えて、最終ホップDHT解像度を持つクライアントの標準DNSインターフェイスを組み合わせたハイブリッドアプローチが開発されました。アイデアは、DNSソリューションの利点（幅広い展開、レガシーアプリケーションのサポート）は、DHT（フォールトトレランス、フラットデータキーの処理の効率）の利点と組み合わせることができるということです。DHTは通常、最終ホップDNSゾーンとDNSサーバーを管理する組織によって内部的に実行されます。そうすれば、その組織に属するヒットは、解像度システムの展開性を向上させる組織によってローカルに保存される可能性があります。ただし、組織は自分自身の間でDHTを共有したり、DNSサーバーをOpenDHTなどの公開されているDHTに接続することもできます。地理的に広がるDHTと比較してローカルサーバークラスターでDHTを実行する利点は、内部DHTレイテンシの減少により、より高いパフォーマンスです。
The system was prototyped by modifying the BIND DNS server to redirect the queries for HITs to a DHT server. The interface was implemented in XML according to specifications [RFC6537]. The system is completely backward compatible to legacy applications since the standard DNS resolver interface is used.
このシステムは、BIND DNSサーバーを変更して、ヒットのクエリをDHTサーバーにリダイレクトすることによりプロトタイプ化されました。インターフェイスは、仕様[RFC6537]に従ってXMLに実装されました。標準のDNSリゾルバーインターフェイスが使用されているため、システムはレガシーアプリケーションと完全に後方互換性があります。
Performance of the system was evaluated by performing a rapid sequence of requests for querying and updating the HIT-to-IP address mapping. The request rate was varied from 1 to 200 requests per second. The average latency of one query request was less than 50 ms and the secured updated latency less than 100 ms with a low request
システムのパフォーマンスは、HIT-To-IPアドレスマッピングのクエリと更新のための一連のリクエストを実行することにより、評価されました。要求率は、1秒あたり1〜200のリクエストに変化しました。1つのクエリリクエストの平均レイテンシは50ミリ秒未満であり、保護された更新されたレイテンシは100ミリ秒未満で、リクエストが低いため
rate. However, the delay was increasing exponentially with the request rate, reaching 1 second for 200 requests per second (update rate 0) and almost 2 seconds (update rate 0.5). Furthermore, the maximum delay exceeded the mean by several times.
レート。ただし、リクエストレートとともに遅延は指数関数的に増加し、200秒あたり200リクエスト（更新レート0）とほぼ2秒（更新レート0.5）で1秒に達しました。さらに、最大遅延は平均を数回超えました。
Based on experiments, a multi-processor system could handle more than 1000 queries per second. The latencies are dominated by the DHT resolution delay, and the DNS component is rather small. This is explained by the relative inefficiency of used DHT implementation (Bamboo) and could be definitely improved in the future.
実験に基づいて、マルチプロセッサシステムは1秒あたり1000以上のクエリを処理できます。レイテンシはDHT解像度の遅延によって支配され、DNSコンポーネントはかなり小さいです。これは、使用済みのDHT実装（竹）の相対的な非効率性によって説明されており、将来的には間違いなく改善される可能性があります。
In a deployed HIP environment, applications may be HIP aware or HIP unaware. RFC 5338 [RFC5338] describes various techniques to allow HIP to support unmodified applications. Some additional application considerations are listed below.
展開された股関節環境では、アプリケーションは股関節を認識したり、股関節に気付かない場合があります。RFC 5338 [RFC5338]は、HIPが変更されていないアプリケーションをサポートできるようにするさまざまな手法を説明しています。いくつかの追加のアプリケーションに関する考慮事項を以下に示します。
One way to support legacy applications that use dynamic linking is to dynamically interpose a modified resolver library. Using HIPL, several legacy applications were shown to work without changes using dynamic re-linking of the resolver library. For example, the Firefox web browser successfully worked with an Apache web server. The re-linking just requires configuring an LD_PRELOAD system variable that can be performed in a user shell profile file or as a start-up wrapper for an application. This provides the user with fine-grained policy control over which applications use HIP, which could alternately be considered a benefit or a drawback depending on whether the user is burdened with such policy choices. The technique was also found to be sensitive to loading LD_PRELOAD twice, in which case the order of linking dynamic libraries must be coded carefully.
動的リンクを使用するレガシーアプリケーションをサポートする1つの方法は、変更されたリゾルバーライブラリに動的に干渉することです。Hiplを使用して、いくつかのレガシーアプリケーションが、リゾルバーライブラリの動的な再リンクを使用して変更せずに機能することが示されました。たとえば、Firefox WebブラウザーはApache Webサーバーで正常に機能しました。再リンクには、ユーザーシェルプロファイルファイルで実行できるLD_PRELOADシステム変数またはアプリケーションの起動ラッパーとして実行できるLD_PRELOADシステム変数を構成する必要があります。これにより、ユーザーは、どのアプリケーションが股関節を使用しているかについてのきめ細かいポリシー制御を提供します。これは、ユーザーがそのようなポリシーの選択に負担をかけられているかどうかに応じて、交互に利益または欠点と見なすことができます。この手法は、LD_PRELOADの2回のロードに敏感であることがわかったため、動的ライブラリをリンクする順序は慎重にコード化する必要があります。
Another method for transparently using HIP, which has no reported implementation experience, is via local application proxies (e.g., squid web proxy) that are modified to be HIP aware. Discussion of proxies for HIP is a current focus of research group activities [HIPRG-PROXIES].
実装エクスペリエンスが報告されていない股関節を透過的に使用する別の方法は、HIPを認識するように変更されるローカルアプリケーションプロキシ（例：Squid Webプロキシ）を介してです。股関節のプロキシの議論は、研究グループ活動の現在の焦点です[HIPRG-Proxies]。
A concern that FTP would not work due to the problem of application referrals, i.e., passing the IP address within application messages, was discovered not to be a problem for FTP in practice. It is shown to work well both in the passive and active modes [paper.namespace]. It remains an open question how big problem referrals really are in
アプリケーションの紹介の問題のためにFTPが機能しないという懸念、つまり、アプリケーションメッセージ内でIPアドレスを渡すことは、実際にはFTPの問題ではないことが発見されました。パッシブモードとアクティブモードの両方でうまく機能することが示されています[Paper.NamesPace]。問題の紹介が実際にどれほど大きな問題になっているかは未解決の質問のままです
the practice. At least, they do not seem used for the client side because they are behind NATs, and, therefore, client addresses are unsuitable as referrals.
練習。少なくとも、クライアント側にはNATの背後にあるため、クライアント側には使用されていないようであるため、クライアントアドレスは紹介として不適切です。
Some applications may be sensitive to additional RTTs or processing due to HIP resolutions or the protocol itself. For instance, page load speed for web browsers is a critical metric for browser designers. Some applications or deployments may not wish to trade application speed for the security and mobility management that HIP offers.
一部のアプリケーションは、股関節解像度またはプロトコル自体による追加のRTTまたは処理に敏感になる場合があります。たとえば、Webブラウザーのページロード速度は、ブラウザーデザイナーにとって重要なメトリックです。一部のアプリケーションまたは展開は、HIPが提供するセキュリティおよびモビリティ管理のためにアプリケーション速度を取引することを望まない場合があります。
There is no known deployment of HIP by a data service provider. However, some issues regarding HIP have been brought to the HIP research group by a network provider and are summarized below and in [HIP-OPERATORS].
データサービスプロバイダーによる股関節の既知の展開はありません。ただし、股関節に関するいくつかの問題は、ネットワークプロバイダーによって股関節研究グループにもたらされており、[股関節術]の以下と[股関節術]にまとめられています。
When a network operator deploys HIP for its customers, several issues with management of host identities arise. The operator may prefer to generate the host identity itself rather than let each host create the identities. Several factors can create such a need. Public-private key generation is a demanding operation that can take tens of seconds on a lightweight device, such as a mobile phone. After generating a host identity, the operator can immediately insert it into its own AAA databases and network firewalls. This way, the users would not need to be concerned with technical details of host identity management.
ネットワークオペレーターが顧客のためにHIPを展開すると、ホストIDの管理に関するいくつかの問題が発生します。オペレーターは、各ホストがIDを作成できるようにするのではなく、ホストのアイデンティティ自体を生成することを好む場合があります。いくつかの要因がそのようなニーズを生み出すことができます。官民キージェネレーションは、携帯電話などの軽量デバイスで数秒かかることができる厳しい操作です。ホストIDを生成した後、オペレーターはすぐに独自のAAAデータベースとネットワークファイアウォールに挿入できます。これにより、ユーザーはホストID管理の技術的な詳細に関心を持つ必要はありません。
The operator may use a Public Key Infrastructure (PKI) to certify host identities of its customers. Then, it uses the private key of an operator's Certificate Authority (CA) to sign the public key of its customers. This way, third parties possessing the public key of the CA can verify the customer's host identity and use this information, e.g., for admission control to infrastructure. Such practice raises the security level of HIP when self-generated host identities are used.
オペレーターは、公開キーインフラストラクチャ（PKI）を使用して、顧客のホストIDを認定することができます。次に、オペレーターの認証局（CA）の秘密鍵を使用して、顧客の公開鍵に署名します。これにより、CAの公開鍵を所有する第三者は、顧客のホストIDを検証し、インフラストラクチャへの入場管理のためにこの情報を使用できます。このような実践は、自己生成されたホストのアイデンティティが使用されると、股関節のセキュリティレベルを上げます。
When the operator is using neither PKI nor DNS Security (DNSSEC) host names, the problem of securely exchanging host identities remains. When HIP is used in opportunistic mode, a man-in-the-middle can still intercept the exchange and replace the host identities with its own.
オペレーターがPKIまたはDNSセキュリティ（DNSSEC）のホスト名のいずれも使用していない場合、ホストIDを安全に交換する問題は残ります。股関節が日和見モードで使用される場合、中間の男は引き続き交換を傍受し、ホストのアイデンティティを独自のアイデンティティに置き換えることができます。
For instance, the signaling provided by SIP could be used to deliver host identities if it were secured by existing mechanisms in the operator's network.
たとえば、SIPによって提供されるシグナリングは、オペレーターのネットワーク内の既存のメカニズムによって保護されている場合、ホストのアイデンティティを提供するために使用できます。
The research group has discussed whether operators can provide "value-added" services and priority, and comply with wiretapping laws, if all sessions are encrypted. This is not so much a HIP issue as a general end-to-end encryption issue.
研究グループは、すべてのセッションが暗号化されている場合、オペレーターが「付加価値のある」サービスと優先順位を提供し、盗聴法に準拠できるかどうかを議論しました。これは、一般的なエンドツーエンドの暗号化の問題ほどヒップな問題ではありません。
The processing power of mobile devices also must be considered. One study evaluated the use of HIP and ESP on lightweight devices (Nokia N770 Internet Tablets having 200 MHz processors) [paper.mobiarch]. The overhead of using ESP on such a platform was found to be tolerable, about 30% in terms of throughput. With a bulk TCP transfer over WiFi, transfer without HIP was producing 4.86 Mbps, while over ESP security associations set up by HIP it was 3.27 Mbps. A lightweight HIP base exchange for this purpose is being developed at the time of this writing [HIP-DEX].
モバイルデバイスの処理能力も考慮する必要があります。ある研究では、軽量デバイス（Nokia N770インターネットタブレット200 MHzプロセッサを備えたNokia N770インターネットタブレット）での股関節とESPの使用を評価しました[Paper.Mobiarch]。このようなプラットフォームでESPを使用するオーバーヘッドは、スループットの点で約30％であることが許容可能であることがわかりました。WiFiを介したバルクTCP転送により、股関節なしでの転送は4.86 Mbpsを生成しましたが、ESPセキュリティ協会が股関節で設定されているため、3.27 Mbpsでした。この目的のための軽量のヒップベース交換は、この執筆時点で開発されています[HIP-DEX]。
It is also possible to use HIP in a NULL encryption configuration if one of SHA1 or MD5 authentication are used.
SHA1またはMD5認証のいずれかが使用される場合、ヌル暗号化構成で股関節を使用することもできます。
A firewall typically separates an organization's network from the rest of the Internet. An Access Control List (ACL) specifies packet forwarding policies in the firewall. Current firewalls can filter out packets based on IP addresses, transport protocol, and port values. These values are often unprotected in data packets and can be spoofed by an attacker. By trying out common well-known ports and a range of IP addresses, an attacker can often penetrate the firewall defenses.
通常、ファイアウォールは、組織のネットワークを他のインターネットから分離します。アクセス制御リスト（ACL）は、ファイアウォールのパケット転送ポリシーを指定します。現在のファイアウォールは、IPアドレス、輸送プロトコル、およびポート値に基づいてパケットをフィルタリングできます。これらの値は、多くの場合、データパケットでは保護されておらず、攻撃者によってスプーフィングできます。よく知られている一般的なポートとさまざまなIPアドレスを試してみることで、攻撃者はしばしばファイアウォール防御に浸透する可能性があります。
Furthermore, legacy firewalls often disallow IPsec traffic and drop HIP control packets. HIP allows ACLs to be protected based on packet exchanges that may be authenticated by middleboxes. However, HITs are not aggregatable, so HIT-based ACLs may be longer in length (due to an inability to group hosts with a single entry) and harder to deal with by human users (due to the length of the HIT compared with an IPv4 or IPv6 prefix).
さらに、レガシーファイアウォールは、多くの場合、IPSECトラフィックを禁止し、ヒップコントロールパケットをドロップします。HIPを使用すると、中間ボックスで認証される可能性のあるパケット交換に基づいてACLを保護できます。ただし、ヒットは集約できないため、ヒットベースのACLの長さは長く（ホストを単一のエントリでグループ化できないため）、人間のユーザーが対処するのが難しい場合があります（IPv4と比較してヒットの長さが原因でまたはIPv6プレフィックス）。
Additionally, operators would like to grant access to the clients from domains such as example.com regardless of their current locators or HITs. This is difficult without a forward confirmed reverse DNS to use for non-repudiation purposes.
さらに、オペレーターは、現在のロケーターやヒットに関係なく、example.comなどのドメインからクライアントにアクセスを許可したいと考えています。これは、繰り返された逆DNSが非和解目的で使用することがなければ困難です。
Helsinki University of Technology (TKK, now Aalto) has implemented a HIP firewall based on Linux iptables [paper.firewall] that operates in user-space.
ヘルシンキ工科大学（TKK、現在のAalto）は、ユーザー空間で動作するLinux Iptables [Paper.firewall]に基づいたHIPファイアウォールを実装しました。
In general, firewalls can be stateless, filtering packets based only on the ACL, and stateful, following and remembering packet flows. Stateless firewalls are simple to implement but provide only coarse-grained protection. However, their performance can be efficient since packet processing requires little memory or CPU resources. A stateful firewall determines if a packet belongs to an existing flow or starts a new flow. A flow identifier combines information from several protocol headers to classify packets. A firewall removes the state when the flow terminates (e.g., a TCP connection is closed) or after a timeout. A firewall can drop suspicious packets that fail a checksum or contain sequence numbers outside of the current sliding window.
一般に、ファイアウォールはステートレスであり、ACLのみに基づいてパケットをフィルタリングし、Packetフローをフォローして記憶しています。ステートレスファイアウォールは簡単に実装できますが、粗粒の保護のみを提供します。ただし、パケット処理にはメモリまたはCPUリソースがほとんど必要ないため、パフォーマンスは効率的です。ステートフルファイアウォールは、パケットが既存のフローに属しているか、新しいフローを開始するかどうかを判断します。フロー識別子は、いくつかのプロトコルヘッダーからの情報を組み合わせて、パケットを分類します。ファイアウォールは、フローが終了するときに状態を削除します（たとえば、TCP接続が閉じられている）またはタイムアウト後。ファイアウォールは、チェックサムに失敗する疑わしいパケットをドロップしたり、現在のスライディングウィンドウの外側にシーケンス番号を含めることができます。
A transparent firewall does not require that hosts within the protected network register or even know of the existence of the firewall. An explicit firewall requires registration and authentication of the hosts.
透明なファイアウォールでは、保護されたネットワークレジスタ内のホストやファイアウォールの存在を知ることさえ必要としません。明示的なファイアウォールには、ホストの登録と認証が必要です。
A HIP-aware firewall operating in the middle identifies flows using HITs of communicating hosts, as well as SPI values and IP addresses. The firewall must link together the HIP base exchange and subsequent IPsec ESP data packets. During the base exchange, the firewall learns the SPI values from I2 and R2 packets. Then, the firewall only allows ESP packets with a known SPI value and arriving from the same IP address as during the base exchange. If the host changes its location and the IP address, the firewall, if still on the path, learns about the changes by following the mobility update packets.
中央で動作するヒップアウェアファイアウォールは、通信ホストのヒット、およびSPI値とIPアドレスを使用してフローを識別します。ファイアウォールは、ヒップベース交換とその後のIPSEC ESPデータパケットをリンクする必要があります。基本交換中、ファイアウォールはI2およびR2パケットからSPI値を学習します。次に、ファイアウォールは、既知のSPI値を持つESPパケットのみを許可し、基本交換中と同じIPアドレスから到着します。ホストがその位置とIPアドレスを変更した場合、ファイアウォールは、パス上にある場合は、モビリティ更新パケットに従って変更について学びます。
It is possible to implement a stateless, end-host-based firewall to reuse existing higher-layer mechanisms such as access control lists in the system. In this mode of operation, HITs would be used in the access control lists, and while the base exchange might complete, ESP is not passed to the transport layer unless the HITs are allowed in the access control list.
ステートレスのエンドホストベースのファイアウォールを実装して、システム内のアクセス制御リストなどの既存の高層メカニズムを再利用することができます。この操作モードでは、アクセス制御リストでヒットが使用され、ベース交換が完了する可能性がありますが、ESPはアクセス制御リストでヒットが許可されない限り、輸送層に渡されません。
A HIP host can register to an explicit firewall using the usual procedure [RFC5203]. The registration enables the host and the firewall to authenticate each other. In a common case, where the Initiator and Responder hosts are located behind different firewalls, the Initiator may need to first register with its own firewall, and afterward, with the Responder's firewall.
HIPホストは、通常の手順[RFC5203]を使用して、明示的なファイアウォールに登録できます。登録により、ホストとファイアウォールがお互いを認証することができます。イニシエーターとレスポンダーのホストが異なるファイアウォールの後ろに配置されている一般的なケースでは、イニシエーターは最初に独自のファイアウォールに、その後レスポンダーのファイアウォールで登録する必要があります。
Some researchers have suggested that a firewall for security-critical environments should get involved in the base exchange and UPDATE procedures with middlebox-injected echo requests. Otherwise, the firewall can be circumvented with replay attacks if there is a compromised node within the network that the firewall is trying to protect [HIP-MIDDLE].
一部の研究者は、セキュリティ批判的な環境のファイアウォールは、ミドルボックスが注入されたエコーリクエストを使用して、基本交換および更新手順に関与することを提案しています。それ以外の場合、ファイアウォールが[ヒップミドル]を保護しようとしているというネットワーク内に侵害されたノードがある場合、リプレイ攻撃でファイアウォールを回避できます。
Using public keys for identifying hosts creates a privacy problem as third parties can determine the source host even if attached to a different location in the network. Various transactions of the host could be linked together if the host uses the same public key. Furthermore, using a static IP address also allows linking of transactions of the host. Multiplexing multiple hosts behind a single NAT or using short address leases from DHCP can reduce the problem of user tracking. However, IPv6 addresses could reduce the occurrence of NAT translation and cause additional privacy issues related to the use of Media Access Control (MAC) addresses in IPv6 address autoconfiguration. HIP does provide for the use of anonymous (unpublished) HITs in cases in which the Initiator prefers to remain anonymous, but the Responder must be willing to accept sessions from anonymous peers.
ホストを識別するためにパブリックキーを使用すると、ネットワーク内の別の場所に接続されている場合でも、第三者がソースホストを決定できるため、プライバシー問題が作成されます。ホストが同じ公開キーを使用している場合、ホストのさまざまなトランザクションをリンクすることができます。さらに、静的IPアドレスを使用すると、ホストのトランザクションをリンクできます。単一のNATの背後にある複数のホストを多重化するか、DHCPからの短いアドレスリースを使用すると、ユーザー追跡の問題が軽減されます。ただし、IPv6アドレスは、NAT翻訳の発生を減らし、IPv6アドレスAutoconfigurationでメディアアクセス制御（MAC）アドレスの使用に関連する追加のプライバシーの問題を引き起こす可能性があります。HIPは、イニシエーターが匿名のままであることを好む場合に、匿名（未発表）ヒットの使用を提供しますが、レスポンダーは匿名のピアからのセッションを受け入れる必要があります。
With mutual authentication, the HIP Initiator should not have to reveal its identity (public key) to either a passive adversary or an active attacker. The HIP Initiator can authenticate the Responder's R1 packet before encrypting its host identity with the Diffie-Hellman-generated keying material and sending it in the I2 packet. The authentication step upon receiving an R1 defeats the active attacker (impersonator) of the Responder, and the act of encrypting the identity defeats the passive adversary. Since the Responder sends its public key unencrypted in the first reply message (R1) to the Initiator, the Responder's identity will be revealed to third-party on-path eavesdroppers. However, if the Responder authenticates the Initiator and performs access controls before sending the R1, the Responder can avoid disclosing its public key to an active attacker.
相互認証により、股関節イニシエーターは、受動的な敵またはアクティブな攻撃者のいずれかに対してそのアイデンティティ（公開鍵）を明らかにする必要はありません。HIPイニシエーターは、ホストのアイデンティティをDiffie-Hellmanで生成したキーイング材料とともに暗号化し、i2パケットに送信する前に、ResponderのR1パケットを認証できます。R1を受信する際の認証ステップは、レスポンダーのアクティブな攻撃者（なりすまし者）を打ち負かし、アイデンティティを暗号化する行為は受動的な敵を打ち負かします。Responderは、最初の返信メッセージ（R1）で暗号化されていない公開鍵をイニシエーターに送信するため、ResponderのIDはサードパーティのオンパス盗聴者に明らかになります。ただし、R1を送信する前にレスポンダーがイニシエーターを認証し、アクセスコントロールを実行する場合、レスポンダーは公開鍵をアクティブな攻撃者に開示することを避けることができます。
DNS records can provide information combining host identity and location information, the host public key, and host IP address. Therefore, identity and location privacy are related and should be treated in an integrated approach. The goal of the BLIND is to provide a framework for identity and location privacy [paper.blind] [HIP-PRIVACY]. The identity protection is achieved by hiding the actual public keys from third parties so that only the trusted hosts can recognize the keys. Location privacy is achieved by integrating traffic forwarding with NAT translation and decoupling host identities from locators. The use of random IP and MAC addresses
DNSレコードは、ホストのIDと位置情報、ホスト公開キー、ホストIPアドレスを組み合わせた情報を提供できます。したがって、アイデンティティとロケーションのプライバシーは関連しており、統合されたアプローチで扱う必要があります。盲人の目標は、アイデンティティと場所のプライバシーのフレームワークを提供することです[Paper.Blind] [HIP-PRIVACY]。アイデンティティ保護は、信頼できるホストのみがキーを認識できるように、実際のパブリックキーを第三者から隠すことによって達成されます。場所のプライバシーは、トラフィックの転送をNAT翻訳と統合し、ロケーターからのホストIDを切り離すことで達成されます。ランダムIPおよびMACアドレスの使用
also reduces the issue of location privacy shifting the focus to protecting host identifiers from third parties. This approach is, by its very nature, incompatible with middlebox authentication.
また、ホスト識別子を第三者から保護することに焦点を移す場所のプライバシーの問題を減らします。このアプローチは、その性質上、Middlebox認証と互換性がありません。
To prevent revealing the identity, the host public key and its hash (HIT) can be encrypted with a secret key known beforehand to both Initiator and Responder. However, this is a requirement that cannot be easily implemented in practice. The BLIND framework provides protection from active and passive attackers using a modified HIP base exchange. If the host avoids storing its public keys in the reverse DNS or DHT repository, the framework achieves full location and identity privacy.
アイデンティティを明らかにするのを防ぐために、ホストの公開キーとそのハッシュ（ヒット）は、事前にイニシエーターとレスポンダーの両方に知られている秘密の鍵で暗号化できます。ただし、これは実際には簡単に実装できない要件です。ブラインドフレームワークは、修正された股関節ベース交換を使用して、アクティブおよびパッシブ攻撃者からの保護を提供します。ホストがパブリックキーを逆DNSまたはDHTリポジトリに保存することを避けた場合、フレームワークは完全な場所とアイデンティティのプライバシーを実現します。
An alternative approach to reducing privacy threats of persistent identifiers is to replace them with short-lived identifiers that are changed regularly to prevent user tracking. Furthermore, identifiers must be changed simultaneously at all protocol layers; otherwise, an adversary could still link the new identifier by looking at an identifier at another protocol layer that remained the same after the change. The HIP privacy architecture that simultaneously changes identifiers on MAC, IP, and HIP/IPsec layers was developed at Helsinki University of Technology (TKK, now Aalto) [thesis.takkinen]. HIP could be extended in the future to allow active sessions to migrate identities.
永続的な識別子のプライバシーの脅威を減らすための代替アプローチは、ユーザーの追跡を防ぐために定期的に変更される短命の識別子に置き換えることです。さらに、すべてのプロトコル層で識別子を同時に変更する必要があります。それ以外の場合、敵は、変更後も同じままの別のプロトコル層の識別子を調べることにより、新しい識別子をリンクできます。MAC、IP、およびHIP/IPSECレイヤーの識別子を同時に変更するHIPプライバシーアーキテクチャは、ヘルシンキ工科大学（TKK、現在のAalto）[Thesis.takkinen]で開発されました。アクティブなセッションがアイデンティティを移行できるように、将来股関節を拡張することができます。
This report is derived from reported experiences and research results of early adopters, implementers, and research activities. In particular, a number of implementations have been in development since 2002 (Section 2).
このレポートは、早期採用者、実装者、および研究活動の報告された経験と研究結果から導き出されます。特に、2002年以来、多くの実装が開発されています（セクション2）。
One production-level deployment of HIP has been reported. Boeing has described how it uses HIP to build Layer 2 VPNs over untrusted wireless networks [HIPLS]. This use case is not a traditional end-host-based use of HIP, but rather, it is one that uses HIP-aware middleboxes to create ESP tunnels on-demand between provider-edge (PE) devices.
股関節の1つの生産レベルの展開が報告されています。Boeingは、股関節を使用して、信頼できないワイヤレスネットワーク[Hipls]上にレイヤー2 VPNを構築する方法を説明しています。このユースケースは、股関節の従来のエンドホストベースの使用ではなく、股関節を認識しているミドルボックスを使用して、プロバイダーエッジ（PE）デバイス間でESPトンネルをオンデマンドで作成するものです。
The InfraHIP II project is deploying HIP infrastructure (test servers, rendezvous and relay servers) in the public Internet.
Infrahip IIプロジェクトは、パブリックインターネットに股関節インフラストラクチャ（テストサーバー、ランデブー、リレーサーバー）を展開しています。
The following is a possibly incomplete list of past and current research activities related to HIP.
以下は、股関節に関連する過去および現在の研究活動の不完全なリストです。
o Boeing Research & Technology (J. Ahrenholz, O. Brewer, J. Fang, T. Henderson, D. Mattes, J. Meegan, R. Paine, S. Venema, OpenHIP implementation, Secure Mobile Architecture)
o ボーイングリサーチ＆テクノロジー（J.アフレンホルツ、O。ブリューワー、J。ファン、T。ヘンダーソン、D。マテス、J。ミーガン、R。ペイン、S。ベネマ、オープンシップ実装、安全なモバイルアーキテクチャ））
o NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP implementation)
o Nomadiclab、Ericsson（P。Jokela、P。Nikander、J。Melen。BSDHIP実装）
o Helsinki Institute for Information Technology (HIIT) (A. Gurtov, M. Komu, A. Pathak, D. Beltrami. HIPL, legacy NAT traversal, firewall, i3, native API)
o Helsinki Institute for Information Technology（HIIT）（A。Gurtov、M。Komu、A。Pathak、D。Beltrami。
o Helsinki University of Technology (TKK, now Aalto) (Janne Lindqvist, Niklas Karlsson, Laura Takkinen, and Essi Vehmersalo. HIP security and firewalls, multiple identities, and privacy management)
o ヘルシンキ工科大学（TKK、現在のアールト）（Janne Lindqvist、Niklas Karlsson、Laura Takkinen、およびEssiVehmersalo。HIPセキュリティとファイアウォール、複数のアイデンティティ、プライバシー管理）
o University of California, Berkeley (A. Joseph, HIP proxy implementation)
o カリフォルニア大学バークレー校（A.ジョセフ、ヒッププロキシ実装）
o Laboratory of Computer Architecture and Networks, Polytechnic School of University of Sao Paulo, Brazil (T. Carvalho, HIP measurements, Hi3)
o ブラジル、サンパウロ大学のポリテクニックスクール、ブラジルのポリテクニック学校（T.カルヴァリョ、HI3）
o Telecom Italia (M. Morelli, comparing existing HIP implementations)
o Telecom Italia（M。Morelli、既存の股関節の実装の比較）
o NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS implementation, DNS, NAT traversal)
o Nec Heidelberg（L。Eggert、M。Esteban、V。Schmitt RVS実装、DNS、NAT Traversalに取り組んでいます）
o University of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP registration protocol)
o ハンブルク・ハルバーグ大学（M.シャンムガム、A。ナガラジャン、股関節登録プロトコル）
o University of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP-OpenDHT)
o Tuebingen大学（K. Wehrle、T。LebenslaufがHi3またはHip-Opendhtに取り組む）
o University of Parma (UNIPR), Department of Information Engineering Parma, Italy. (N. Fedotova, HIP for P2P)
o パルマ大学（UNIPR）、イタリアの情報工学部パルマ学科。（N. Fedotova、p2pの股関節）
o Siemens (H. Tschofenig, HIP middleboxes)
o Siemens（H。Tschofenig、HIP Middleboxes）
o Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per Toft, HIP evaluation project, OpenDHT-HIP interface)
o デンマーク（Aalborg University、Lars Roost、Gustav Haraldsson、Per Toft、Hip Aveluation Project、Opendht-Hipインターフェイス）
o Microsoft Research, Cambridge (T. Aura, HIP analysis)
o Microsoft Research、ケンブリッジ（T. Aura、HIP分析）
o MIT (H. Balakrishnan. Delegation-Oriented Architecture)
o MIT（H。Balakrishnan。代表団指向のアーキテクチャ）
o Huawei (D. Zhang, X. Xu, hierarchical HIP architecture, HIP proxy, key revocation)
o Huawei（D。Zhang、X。Xu、階層股関節アーキテクチャ、ヒッププロキシ、キー取り消し）
This section briefly summarizes the related work on the ID-locator split with particular focus on recent IETF and IRTF activity. In the academic research community, several related proposals were explored prior to the founding of this research group, such as the Internet Indirection Infrastructure (i3) [paper.i3], IPNL [paper.layered], DataRouter [paper.datarouter], Network Pointers [paper.netpointers], FARA [paper.fara], and TRIAD [paper.triad].
このセクションでは、最近のIETFおよびIRTFアクティビティに特に焦点を当てたID-Locator分割に関する関連する作業を簡単にまとめます。学術研究コミュニティでは、インターネット間接インフラストラクチャ（I3）[Paper.I3]、IPNL [Paper.layered]、Datarouter [Paper.Datarouter]、ネットワークなど、この研究グループの設立前にいくつかの関連提案が調査されました。ポインター[Paper.NetPointers]、Fara [Paper.Fara]、およびTriad [Paper.Triad]。
The topic of whether a new namespace is needed for the Internet has been controversial. The Namespace Research Group (NSRG) at the IRTF was not able to reach consensus on the issue, nor even to publish a final report. Yet, there seems to be little disagreement that, for many scenarios, some level of indirection from network name to network location is essential or highly desirable to provide adequate service. Mobile IP [RFC6275] is one example that reuses an existing namespace for host naming. Since Mobile IP was finalized, many new variants to providing this indirection have been suggested. Even prior to Mobile IP, the IETF has published informational documents describing architectures separating network name and location, including the work of Jerome Saltzer [RFC1498] and Nimrod [RFC1992].
インターネットに新しい名前空間が必要かどうかのトピックは議論の余地があります。IRTFの名前空間研究グループ（NSRG）は、この問題に関するコンセンサスに達することも、最終レポートを公開することさえできませんでした。しかし、多くのシナリオで、ネットワーク名からネットワークの場所へのある程度の間接的なレベルが適切なサービスを提供するために不可欠または非常に望ましいという意見の相違はほとんどないようです。モバイルIP [RFC6275]は、ホストの命名用に既存の名前空間を再利用する1つの例です。モバイルIPが確定して以来、この間接を提供するための多くの新しいバリアントが提案されています。モバイルIPの前でさえ、IETFは、Jerome Saltzer [RFC1498]やNimrod [RFC1992]の作品を含むネットワーク名と場所を分離するアーキテクチャを説明する情報文書を公開してきました。
Most recently, there have been standardization and development efforts in the IETF and IRTF as follows:
最近では、次のようにIETFとIRTFで標準化と開発の取り組みがありました。
o The Site Multihoming in IPv6 (multi6) WG documented the ways that multihoming is currently implemented in IPv4 networks and evaluated several approaches for advanced multihoming. The security threats and impact on transport protocols were covered during the evaluation. The work continued in another WG, Site Multihoming by IPv6 Intermediation (shim6), which is focusing on specifications of one selected approach [RFC5533]. Shim6 uses the approach of inserting a shim layer between the IP and the transport layers that hides effects of changes in the set of available addresses. The applications are using one active address that supports referrals. Shim6 relies on cryptographically generated IPv6 addresses to solve the address ownership problem. HIP and shim6 are architecturally similar and use a common format for control packets. HIP specifications define only simple multihoming scenarios leaving such important issues as interface selection untouched. Shim6 offers complementary functionality that can be reused in HIP [REAP4HIP]. The OpenHIP implementation integrates HIP and shim6 protocols in the same framework, with the goal of allowing HIP to reuse the shim6 failure detection protocol. Furthermore, HIP and shim6 socket APIs have been jointly designed [RFC6317] [RFC6316].
o IPv6（Multi6）WGのサイトMultihomingは、Multihomingが現在IPv4ネットワークで実装されている方法を文書化し、高度なマルチホームのためのいくつかのアプローチを評価しました。輸送プロトコルへのセキュリティの脅威と影響は、評価中にカバーされました。この作業は、1つの選択されたアプローチの仕様に焦点を当てているIPv6中間化（SHIM6）によってマルチホミングの別のWGで続きました[RFC5533]。 SHIM6は、利用可能なアドレスのセットの変化の効果を隠すIPとトランスポート層の間にシム層を挿入するアプローチを使用します。アプリケーションは、紹介をサポートする1つのアクティブアドレスを使用しています。 SHIM6は、アドレスの所有権の問題を解決するために、暗号化されたIPv6アドレスに依存しています。 HIPとSHIM6はアーキテクチャに似ており、制御パケットに共通形式を使用しています。股関節仕様は、インターフェイスの選択が触れられないような重要な問題を残す単純なマルチホームシナリオのみを定義します。 SHIM6は、股関節[Reap4hip]で再利用できる補完的な機能を提供します。オープンシップの実装は、HIPとSHIM6プロトコルを同じフレームワークに統合し、HIPがSHIM6障害検出プロトコルを再利用できるようにすることを目標としています。さらに、股関節とSHIM6ソケットAPIは共同で設計されています[RFC6317] [RFC6316]。
o The IRTF Routing Research Group (RRG) has explored a class of solutions to the global routing scalability problem that involve either separation of the existing IP address space into those used for identifiers and locators as in LISP [LISP] and Six/One Router [SIX-ONE] and those advocating a fuller separation of these roles including ILNP [ILNP] and RANGI [RANGI].
o IRTFルーティングリサーチグループ（RRG）は、LISP [LISP]および6/Oneルーターのように識別子およびロケーターに使用されるものへの既存のIPアドレススペースを分離するかのいずれかを含むグローバルルーティングスケーラビリティ問題のソリューションのクラスを調査しました[6つ-one]およびILNP [ILNP]およびRangi [Rangi]を含むこれらの役割の完全な分離を提唱する人々。
o The End-Middle-End research group considered the potential for an explicit signaling and policy control plane for middleboxes and endpoints [EME]; at a joint meeting at IETF 69, the HIP and EME research groups discussed whether the EME framework could help HIP with middlebox traversal.
o エンドミドルエンドの研究グループは、ミドルボックスとエンドポイント[EME]の明示的なシグナル伝達およびポリシー制御プレーンの可能性を検討しました。IETF 69での共同会議で、HIPとEMEの研究グループは、EMEフレームワークがミドルボックストラバーサルで股関節に役立つかどうかを議論しました。
o The IETF Multipath TCP working group is developing mechanisms to simultaneously use multiple paths in a regular TCP session. The MPTCP solution aims to solve the multihoming problem also addressed by HIP but by solving it for TCP specifically.
o IETFマルチパスTCPワーキンググループは、通常のTCPセッションで複数のパスを同時に使用するメカニズムを開発しています。MPTCPソリューションは、股関節でも対処されているマルチホームの問題を解決することを目的としていますが、特にTCPのためにそれを解決します。
o The Unmanaged Internet Protocol bears several similarities to the HIP architecture, such as the focus on identifiers that are not centrally managed that are also based on a cryptographic hash of a node's public key [thesis.ford].
o 管理されていないインターネットプロトコルには、ノードの公開鍵の暗号化ハッシュにも基づいた中央に管理されていない識別子に焦点を当てるなど、股関節アーキテクチャといくつかの類似点があります[Thesis.ford]。
o Apple Back To My Mac service provides secure connections between hosts using IPsec between a pair of host identifiers. However, the host identifier is reported to be an IPv6 Unique Local Addressing (ULA) address rather than a HIP identifier [RFC6281].
o Appleに戻るMACサービスは、ホスト識別子のペア間のIPSECを使用して、ホスト間の安全な接続を提供します。ただし、ホスト識別子は、股関節識別子[RFC6281]ではなく、IPv6一意のローカルアドレス（ULA）アドレスであると報告されています。
Although the HIP research group has not formally tried to compare HIP with other ID-locator split approaches, such discussions have occurred on other lists such as the Routing research group mailing list, and a comparison of HIP's mobility management solution with other approaches was published in [MOBILITY-COMPARISON].
HIP研究グループは、HIPと他のID-Locatorスプリットアプローチを正式に比較しようとしていませんが、そのような議論はルーティングリサーチグループメーリングリストなどの他のリストで発生しており、HIPのモビリティ管理ソリューションと他のアプローチの比較が公開されました。[Mobility-Comparsison]。
This document is an informational survey of HIP-related research and experience. Space precludes a full accounting of all security issues associated with the approaches surveyed here, but the individually referenced documents may discuss security considerations for their respective protocol component. HIP security considerations for the base HIP protocol can be found in Section 8 of [RFC5201].
この文書は、股関節関連の研究と経験に関する情報調査です。Spaceは、ここで調査されたアプローチに関連するすべてのセキュリティ問題の完全な会計を排除しますが、個別に参照されたドキュメントは、それぞれのプロトコルコンポーネントのセキュリティ上の考慮事項を議論する場合があります。ベース股関節プロトコルの股関節セキュリティに関する考慮事項は、[RFC5201]のセクション8に記載されています。
Miika Komu, Pekka Nikander, Ari Keranen, and Jeff Ahrenholz have provided helpful comments on earlier draft versions of this document. Miika Komu also contributed the section on opportunistic mode. We also thank Dacheng Zhang for contributions on hierarchical HIP architectures and the Crypto Forum Research Group (Adam Back and Paul Hoffman) for clarification of Diffie-Hellman privacy properties.
Miika Komu、Pekka Nikander、Ari Keranen、およびJeff Ahrenholzは、このドキュメントの以前のドラフトバージョンについて有益なコメントを提供しています。Miika Komuは、日和見モードのセクションも貢献しました。また、Dacheng Zhangは、階層的な股関節アーキテクチャと、Diffie-Hellmanプライバシープロパティの明確化についてCrypto Forum Research Group（Adam Back and Paul Hoffman）についての貢献に感謝します。
[BEET-MODE] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel (BEET) mode for ESP", Work in Progress, August 2008.
[Beet-Mode] Nikander、P。およびJ. Melen、「ESP用のバインドエンドツーエンドトンネル（ビート）モード」、2008年8月、進行中の作業。
[EME] Francis, P., Guha, S., Brim, S., and M. Shore, "An EME Signaling Protocol Design", Work in Progress, April 2007.
[EME] Francis、P.、Guha、S.、Brim、S.、およびM. Shore、「EME Signaling Protocol Design」、Progress、2007年4月。
[HIP-DEX] Moskowitz, R., "HIP Diet EXchange (DEX)", Work in Progress, March 2011.
[HIP-DEX] Moskowitz、R。、「Hip Diet Exchange（DEX）」、2011年3月の作業。
[HIP-MIDDLE] Hummen, R., Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, October 2011.
[Hip-Middle] Hummen、R.、Heer、T.、Wehrle、K。、およびM. Komu、「ヒップミドルボックスのエンドホスト認証」、2011年10月の作業。
[HIP-OPERATORS] Dietz, T., Brunner, M., Papadoglou, N., Raptis, V., and K. Kypris, "Issues of HIP in an Operators Networks", Work in Progress, October 2005.
[ヒップオペレーター] Dietz、T.、Brunner、M.、Papadoglou、N.、Raptis、V。、およびK. Kypris、「オペレーターネットワークの股関節の問題」、2005年10月の作業。
[HIP-PRIVACY] Zhang, D. and M. Komu, "An Extension of HIP Base Exchange to Support Identity Privacy", Work in Progress, July 2011.
[HIP-PRIVACY] Zhang、D。およびM. Komu、「身元のプライバシーをサポートするためのヒップベース交換の延長」、2011年7月に進行中の作業。
[HIPLS] Henderson, T., Venema, S., and D. Mattes, "HIP-based Virtual Private LAN Service (HIPLS)", Work in Progress, September 2011.
[Hipls] Henderson、T.、Venema、S。、およびD. Mattes、「HIPベースの仮想プライベートLANサービス（Hipls）」、2011年9月、Work in Progress。
[HIPRG-PROXIES] Zhang, D., Xu, X., Yao, J., and Z. Cao, "Investigation in HIP Proxies", Work in Progress, October 2011.
[Hiprg-Proxies] Zhang、D.、Xu、X.、Yao、J。、およびZ. Cao、「股関節委員の調査」、2011年10月の進行中。
[HIT2IP] Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags Data in DNS", Work in Progress, July 2009.
[HIT2IP] Ponomarev、O。およびA. Gurtov、「DNSのホストIDタグデータの埋め込み」、2009年7月の作業。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, July 2011.
[ILNP] Atkinson、R。、「ILNP Operations of Operations」、2011年7月に進行中の作業。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, November 2011.
[Lisp] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator/ID Separation Protocol（LISP）」、Work in Progress、2011年11月。
[LMDR] Swami, Y., Le, K., and W. Eddy, "Lightweight Mobility Detection and Response (LMDR) Algorithm for TCP", Work in Progress, February 2006.
[LMDR] Swami、Y.、Le、K。、およびW. Eddy、「TCPの軽量モビリティ検出および応答（LMDR）アルゴリズム」、2006年2月の作業進行中。
[MOBILITY-COMPARISON] Thaler, D., "A Comparison of IP Mobility-Related Protocols", Work in Progress, October 2006.
[Mobility-Comparsison] Thaler、D。、「IPモビリティ関連のプロトコルの比較」、2006年10月、進行中の作業。
[MULTI-HOMED] Huitema, C., "Multi-homed TCP", Work in Progress, May 1995.
[Multi-Homed] Huitema、C。、「Multi-Homed TCP」、1995年5月、進行中の作業。
[NAT-TRAVERSAL] Keranen, A. and J. Melen, "Native NAT Traversal Mode for the Host Identity Protocol", Work in Progress, January 2011.
[NAT-Traversal] Keranen、A。およびJ. Melen、「ホストIDプロトコルのネイティブNATトラバーサルモード」、2011年1月、進行中の作業。
[RANGI] Xu, X., "Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, August 2010.
[Rangi] Xu、X。、「次世代インターネット（Rangi）のルーティングアーキテクチャ」、2010年8月の作業。
[REAP4HIP] Oliva, A. and M. Bagnulo, "Fault tolerance configurations for HIP multihoming", Work in Progress, July 2007.
[Reap4hip] Oliva、A。およびM. Bagnulo、「股関節マルチホミングのためのフォールトトレランス構成」、2007年7月、進行中の作業。
[RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993.
[RFC1498] Saltzer、J。、「ネットワーク目的地の命名と結合について」、RFC 1498、1993年8月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992] Castineyra、I.、Chiappa、N。、およびM. Steenstrup、「Nimrod Routing Architecture」、RFC 1992、1996年8月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367] McDonald、D.、Metz、C。、およびB. Phan、「PF_KEY Key Management API、バージョン2」、RFC 2367、1998年7月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「ホストアイデンティティプロトコル（HIP）アーキテクチャ」、RFC 4423、2006年5月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J。、およびF. Dupont、「オーバーレイのルーティング可能な暗号ハッシュ識別子（蘭）のIPv6プレフィックス」、RFC 4843、2007年4月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、Moskowitz、R。、およびP. Nikander、「ホストIDプロトコル（HIP）を使用したセキュリティペイロード（ESP）輸送形式を使用して」、RFC 5202、2008年4月。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203] Laganier、J.、Koponen、T。、およびL. Eggert、「Host Identity Protocol（HIP）登録拡張」、RFC 5203、2008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J。およびL. Eggert、「ホストアイデンティティプロトコル（HIP）Rendezvous Extension」、RFC 5204、2008年4月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205] Nikander、P。およびJ. Laganier、「ホストIDプロトコル（HIP）ドメイン名システム（DNS）拡張機能」、RFC 5205、2008年4月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Nikander、P.、Henderson、T.、Vogt、C。、およびJ. Arkko、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207] Stiemerling、M.、Quittek、J。、およびL. Eggert、「Nat and Firewall Traversal Issus of Host Identity Protocol（HIP）Communication」、RFC 5207、2008年4月。
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008.
[RFC5338] Henderson、T.、Nikander、P。、およびM. Komu、「ホストIDプロトコルをレガシーアプリケーションで使用」、RFC 5338、2008年9月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmark、E。およびM. Bagnulo、「SHIM6：IPv6のレベル3マルチホミングシムプロトコル」、RFC 5533、2009年6月。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
[RFC5770] Komu、M.、Henderson、T.、Tschofenig、H.、Melen、J。、およびA. Keranen、 "基本ホストIdentity Identity Protocol（Hip）ネットワークアドレス翻訳者の横断の拡張"、RFC 5770、2010年4月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253] Heer、T。およびS. Varjonen、「ホストIDプロトコル証明書」、RFC 6253、2011年5月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、ed。、Johnson、D。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 6275、2011年7月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281] Cheshire、S.、Zhu、Z.、Wakikawa、R。、およびL. Zhang、「AppleのBack to My Mac（BTMM）サービスを理解する」、RFC 6281、2011年6月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「TCPの再送信タイマーのコンピューティング」、RFC 6298、2011年6月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316] Komu、M.、Bagnulo、M.、Slavov、K。、およびS. Sugimoto、「Sockets Application Program Interface（API）Multihoming Shim for RFC 6316、2011年7月。
[RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
[RFC6317] Komu、M。およびT. Henderson、「ホストIDプロトコルの基本ソケットインターフェイス拡張（HIP）」、RFC 6317、2011年7月。
[RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash Table Interface", RFC 6537, February 2012.
[RFC6537] Ahrenholz、J。、「ホストIDプロトコル分散ハッシュテーブルインターフェイス」、RFC 6537、2012年2月。
[SIX-ONE] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[Six-one] Vogt、C。、「Six/One：IPv6でのルーティングとアドレス指定のためのソリューション」、2009年10月、進行中の作業。
[TCP-RLCI] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., and K. Le, "TCP Response to Lower-Layer Connectivity-Change Indications", Work in Progress, February 2008.
[TCP-RLCI] Schuetz、S.、Koutsianas、N.、Eggert、L.、Eddy、W.、Swami、Y.、およびK. Le、「低層接続の選択指標に対するTCP応答」、進捗、2008年2月。
[TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework and Requirements for TRIGTRAN", Work in Progress, February 2003.
[Trigtran] Dawkins、S.、Williams、C。、およびA. Yegin、「Trigtranのフレームワークと要件」、2003年2月に進行中の作業。
[book.gurtov] Gurtov, A., "Host Identity Protocol (HIP): Towards the Secure Mobile Internet", ISBN 978-0-470-99790-1, Wiley and Sons, (Hardcover, p 332), June 2008.
[Book.Gurtov] Gurtov、A。、「ホストアイデンティティプロトコル（HIP）：安全なモバイルインターネットに向けて」、ISBN 978-0-470-99790-1、Wiley and Sons、（Hardcover、p 332）、2008年6月。
[paper.blind] Ylitalo, J. and P. Nikander, "BLIND: A complete identity protection framework for end-points", Proc. of the Twelfth International Workshop on Security Protoc ols, April 2004.
[Paper.Blind] Ylitalo、J。およびP. Nikander、「ブラインド：エンドポイントの完全なアイデンティティ保護フレームワーク」、Proc。2004年4月、セキュリティプロトックOLSに関する第12回国際ワークショップの。
[paper.datarouter] Touch, J. and V. Pingali, "DataRouter: A Network-Layer Service for Application-Layer Forwarding", Proceedings of International Workshop on Active Networks (IWAN), May 2003.
[Paper.Datarouter] Touch、J。and V. Pingali、「Datarouter：Application-Layer Forwardingのネットワークレイヤーサービス」、2003年5月、Active Networks（IWAN）に関する国際ワークショップの議事録。
[paper.fara] Clark, D., Braden, R., Falk, A., and V. Pingali, "FARA: Reorganizing the Addressing Architecture", Proceedings of ACM SIGCOMM FDNA Workshop, August 2003.
[Paper.fara] Clark、D.、Braden、R.、Falk、A。、およびV. Pingali、「ファラ：アドレス指定アーキテクチャの再編成」、ACM Sigcomm FDNAワークショップの議事録、2003年8月。
[paper.firewall] Lindqvist, J., Vehmersalo, E., Komu, M., and J. Manner, "Enterprise Network Packet Filtering for Mobile Cryptographic Identities", International Journal of Handheld Computing Research (IJHCR), Volume 1, Issue 1, Pages 79-94, January 2010.
[Paper.firewall] Lindqvist、J.、Vehmersalo、E.、Komu、M。、およびJ. Mather、「モバイル暗号化のためのエンタープライズネットワークパケットフィルタリング」、International Journal of Handheld Computing Research（IJHCR）、Volume 1、Issue1、79〜94ページ、2010年1月。
[paper.handovers] Varjonen, S., Komu, M., and A. Gurtov, "Secure and Efficient IPv4/IPv6 Handovers Using Host-Based Identifier-Locator Split", Proceedings of the 17th International Conference Software, Telecommunications, and Computer Networks, September 2009.
[Paper.Handovers] Varjonen、S.、Komu、M。、およびA. Gurtov、「ホストベースの識別子ロケータースプリットを使用した安全で効率的なIPv4/IPv6ハンドオーバー」、第17回国際会議ソフトウェアの議事録、電気通信、コンピューターの議事録ネットワーク、2009年9月。
[paper.hi3] Gurtov, A., Korzon, D., Lukyanenko, A., and P. Nikander, "Hi3: An Efficient and Secure Networking Architecture for Mobile Hosts", Computer communication, 31 (2008), p. 2457- 2467, <http://www.cs.helsinki.fi/u/gurtov/papers/ comcom_hi3.pdf>.
[Paper.hi3] Gurtov、A.、Korzon、D.、Lukyanenko、A。、およびP. Nikander、「Hi3：モバイルホスト向けの効率的で安全なネットワーキングアーキテクチャ」、Computer Communication、31（2008）、p。2457-2467、<http://www.cs.helsinki.fi/u/gurtov/papers/ comcom_hi3.pdf>。
[paper.hipanalysis] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP Base Exchange Protocol", Proc. of the 10th Australasian Conference on Information Security and Privacy (ACISP), July 2005.
[Paper.hipanalysis] Aura、T.、Nagarajan、A。、およびA. Gurtov、「Hip Base Exchange Protocolの分析」、Proc。2005年7月、情報セキュリティとプライバシーに関する第10回オーストラリア会議（ACISP）。
[paper.i3] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S. Surana, "Internet Indirection Infrastructure (i3)", Proceedings of ACM SIGCOMM, August 2002.
[Paper.I3] Stoica、I.、Adkins、D.、Zhuang、S.、Shenker、S。、およびS. Surana、「インターネット間接インフラストラクチャ（I3）」、ACM Sigcommの議事録、2002年8月。
[paper.layered] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker, S., Stoica, I., and M. Walfish, "A Layered Naming Architecture for the Internet", Proceedings of ACM SIGCOMM, August 2004.
[Paper.layered] Balakrishnan、H.、Lakshminarayanan、K.、Ratnasamy、S.、Shenker、S.、Stoica、I。、およびM. Walfish、「インターネットの階層化された命名アーキテクチャ」、ACM Sigcommの議事録、2004年8月。
[paper.leap-of-faith] Komu, M. and J. Lindqvist, "Leap-of-faith security is enough for IP mobility", Proceedings of the 6th IEEE Conference on Consumer Communications and Networking Conference (CCNC 09), 2009.
[Paper。。
[paper.mobiarch] Khurri, A., Vorobyeva, E., and A. Gurtov, "Performance of Host Identity Protocol on Lightweight Hardware", Proceedings of ACM MobiArch, August 2007.
[Paper.Mobiarch] Khurri、A.、Vorobyeva、E。、およびA. Gurtov、「Lightweight HardwareでのホストIDプロトコルのパフォーマンス」、ACM Mobiarchの議事録、2007年8月。
[paper.namespace] Komu, M., Tarkoma, S., Kangasharju, J., and A. Gurtov, "Applying a Cryptographic Namespace to Applications", Proc. of First International ACM Workshop on Dynamic Interconnection of Networks, September 2005.
[Paper.NamesPace] Komu、M.、Tarkoma、S.、Kangasharju、J。、およびA. Gurtov、「暗号化された名前空間のアプリケーションへの適用」、Proc。2005年9月、ネットワークの動的相互接続に関するFirst International ACMワークショップの。
[paper.netpointers] Tschudin, C. and R. Gold, "Network pointers", ACM SIGCOMM Computer Communications Review, Vol. 33, Issue 1, January 2003.
[Paper.netpointers] Tschudin、C。and R. Gold、「ネットワークポインター」、ACM Sigcomm Computer Communications Review、Vol。33、第1号、2003年1月。
[paper.p2psip] Koskela, J., Heikkila, J., and A. Gurtov, "A secure P2P SIP system with SPAM prevention", ACM Mobile Computer Communications Review, July 2009.
[Paper.P2PSIP] Koskela、J.、Heikkila、J。、およびA. Gurtov、「Spam Preventionを備えた安全なP2P SIPシステム」、ACMモバイルコンピューターコミュニケーションレビュー、2009年7月。
[paper.triad] Cheriton, D. and M. Gritter, "TRIAD: A New Next-Generation Internet Architecture", July 2000, <http://www-dsg.stanford.edu/triad/triad.ps.gz>.
[Paper.triad] Cheriton、D。and M. Gritter、「Triad：A New Next-Generation Internet Architecture」、2000年7月、<http://www-dsg.stanford.edu/triad/triad.ps.gz>。
[paper.usable-security] Karvone, K., Komu, M., and A. Gurtov, "Usable Security Management with Host Identity Protocol", Proc. of the IEEE/ACS International Conference on Computer Systems and Applications, May 2009.
[Paper.Usable-Security] Karvone、K.、Komu、M。、およびA. Gurtov、「ホストIDプロトコルを使用した使用可能なセキュリティ管理」、Proc。2009年5月、コンピューターシステムおよびアプリケーションに関するIEEE/ACS国際会議の。
[thesis.bishaj] Bishaj, B., "Efficient Leap of Faith Security with Host Identity Protocol", Master thesis, Helsinki University of Technology, June 2008.
[Thesis.bishaj] Bishaj、B。、「ホストアイデンティティプロトコルを使用した信仰の安全性の効率的な飛躍」、マスター論文、ヘルシンキ工科大学、2008年6月。
[thesis.ford] Ford, B., "UIA: A Global Connectivity Architecture for Mobile Personal Devices", Doctoral thesis, Massachusetts Institute of Technology, September 2008.
[Thesis.Ford] Ford、B。、「UIA：モバイルパーソナルデバイス向けのグローバル接続アーキテクチャ」、博士論文、マサチューセッツ工科大学、2008年9月。
[thesis.karlsson] Karlsson, N., "Enabling Multiple Host Identities on Linux", Master thesis, Helsinki University of Technology, September 2005.
[Thesis.Karlsson] Karlsson、N。、「Linuxで複数のホストIDを可能にする」、Master論文、ヘルシンキ工科大学、2005年9月。
[thesis.takkinen] Takkinen, L., "Host Identity Protocol Privacy Management", Master thesis, March 2006, <http://www.tml.tkk.fi/~anttiyj/Laura-Privacy.pdf>.
[Thesis.Takkinen] Takkinen、L。、「ホストIDプロトコルプライバシー管理」、マスター論文、2006年3月、<http://www.tml.tkk.fi/~anttiyj/laura-privacy.pdf>。
Authors' Addresses
著者のアドレス
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA
トーマス・ヘンダーソンボーイングカンパニーP.O.ボックス3707シアトル、ワシントンアメリカ
EMail: thomas.r.henderson@boeing.com
Andrei Gurtov University of Oulu Centre for Wireless Communications CWC P.O. Box 4500 FI-90014 University of Oulu Finland
アンドレイ・ガルトフ・オブ・ウル大学ワイヤレス通信センターCWC P.O.Box 4500 FI-90014オールフィンランド大学
EMail: gurtov@ee.oulu.fi