SlideShare a Scribd company logo
1 of 6
Download to read offline
p. 1
<HIP 関連資料>
株式会社テリロジー
新美竹男
はじめに、
ホスト ID とロケータの分離というしくみは、十数年前から国内の研究機構とか大学で、
新世代ネットワークの仕組みとして研究論文が出された。ただ、残念ながら今なお普及の
域には達していない。その理由の1つにこのしくみを商用化しているマルチベンダーの市
場での台頭がなく、唯一 HIP 対応ベンダーとして米国 Tempered 社が産業分野で孤軍奮
闘している。HIP(Host Identity Protocol)を学習するには、まず HIP の基盤となる“ホス
ト ID とロケータ”を理解が必要である。
ホスト ID-ロケータ分離(Identifier-locator split)とは
インターネットパケットの IP データグラム(IP datagram)ルーティングは、パケットの宛
先 IP アドレスにネットワークプレフィックス(Prefix)を付加する。インターネットルータ
ーが個々の IP アドレスのネクストホップを要求することは実用的ではないと云われている。
何故なら、これによってルーティングテーブルが過度に肥大化し、メモリコストが増し、ル
ックアップが遅くなってしまうからである。そのため、IP アドレスはアグリゲートされ、
基本的に地理的に近いエリアに集約配置されている。そして現在、IP アドレスはインター
ネットトポロジーでホストロケータの役割を果たしている。
ホスト ID(Identifier)は、
インターネット接続環境でホストロケータ変更される可能性があ
るにもかかわらず、一意であることを他の通信エンティティに通知している。DNS の名前
解決のしくみは、広く用いられている ID(識別子)タイプの 1 つである。インターネットの
黎明期には、ホストロケータは固定しており、そのため IP アドレスをホスト ID として用
いることができた。
ただ、
現在のインターネットアーキテクチャでは、
図 1.に示すように、
ホスト ID とロケータ(ホストの場所を示す)の両方としての IP アドレスの役割が混在して
いる。ただ、この考えはもはや有効でなくなった。何故ならば、ホストは、モバイルとかマ
ルチホームにまでインターネット利用が広がっているからである。個別のインタネットサ
ービスが必要に応じ独自ソケットを適用しているが、エンドポイントのホスト ID はそのイ
ンターフェイスの IP アドレスに直接接続されているのが現状である。
p. 2
図1.ホストのロケーションと ID はインターネットで結合
現在、
ホストの多くは、
共通の DHCP プールから払い出された IPv4 アドレス、
または NAT
によって割り当てられた一時的なプライベート IPv4 アドレスを使用している。従って、IP
アドレスを堅牢なホスト ID として用いることが難しい。
例えば、特定の IPv4 アドレスをスパムメッセージだとしてブラックリストに登録すると、
実際には、後で DHCP から払い出された同じアドレスを受信したホストを無効にしたり、
NAT で同じパブリック IPv4 アドレスを使用する多数のホストを阻止したりしてしまう。
そこで、登場するのが HIP アーキテクチャの基盤である“ホスト ID とロケータ分離”のしく
みである。従来のインターネット接続では、ホスト ID(“誰が通信しているのか”)とネッ
トワークトポロジーでのロケータ(“どこから通信しているか”)を同じ IP アドレスで示し
ているため、ユビキタスネットワークの柔軟なニーズ対応には難しいと考えられた。
そこで、ホスト ID とネットワークトポロジーのロケータを分離して識別するしくみを“ホ
スト ID/ロケータ分離(Host ID/Locator Split)”と呼んでいる。ID として Host Identity
(HI) 及び Host Identity Tag(HIT)を用い、ロケータとしては IP アドレスを用いる。
そして、ホスト ID を認証するにはセキュアなメカニズムが不可欠である。
HIP アーキテクチャでは、自己生成の公開鍵(public key)と秘密鍵(private key)のペアが
ホスト ID になり、これら鍵交換によってセキュアな認証(authentication)が行われる。
図 2.は、ソケットとネットワーク IP アドレス間に設定のホスト ID を示す。この図で分か
るように、ソケットはロケータではなくホスト ID にバインドされる。
尚、同一 ID に関連付けられた複数のロケータが存在するケースも出てくる。
ここでは、ロケータとしての IP アドレスは、ソケットを変更せずに動的に追加/変更でき
る。
p. 3
図2.インターネットホストのロケーションと ID の分離
1 つのホストは複数の ID を持つことができる。“セルフアサート(Self-assert)”型未公開ホ
スト ID は、信頼できる匿名通信(anonymous communication)に適している。ピアホスト
は、
新しい接続が以前と同じホストからのものであることを確実に確認できる。
ホスト ID、
PKI(public key infrastructure:公開鍵暗号基盤)、X.509 証明書(certificate)、または
PGP(Pretty Good Privacy)によってアサートされたホスト ID を用いて、ホストは認証さ
れる。
同じ秘密鍵を持つホストグループ間では ID を共有でき,このようなホストは、
例えば、
マル
チキャストグループとか、他の分散オペレーションに適用される。
~インターネットアーキテクチャの HIP
上述の通り、インターネットの世界では、IP プロトコルがルーティング可能な業界標準の
ネットワークレイヤプロトコルであった。
そして、
そのシンプルなしくみのおかげで、
IP プ
ロトコルは、イーサネット(IEEE 802.3)、無線 LAN(IEEE 802.11)、トークンリング
(IEEE 802.2)など、様々なリンクテクノロジーで利用が広がって行った。
一方、IP 上での複数のトランスポートプロトコルとして TCP および UDP も又広く使用さ
れてきた。現在、トランスポートプロトコルを用いたアプリケーションは多く、最も一般的
なものは HTTP、SMTP、および FTP がある。結果としてインターネットのプロトコルスタ
ックモデルは、図 3 に示す砂時計のようなしくみに似ている。この図を見ると、IP はスタ
ックの最も狭い部分であり、インターネットの“ウエスト”と呼ばれることもある。
インターネットアーキテクチャの主な問題は、ネットワークレイヤとトランスポートレイ
ヤ間の密な結合であり、この中で TCP は IP アドレスを含む仮想ヘッダー(pseudo
header)を使用していることである。
p. 4
図3.IP が Internet プロトコルスタックのウエスト
ネットワークススタックに基づく OSI モデルでは、異なるプロトコルレイヤが相互に分離
されている。
但し、このモデルはインターネットプロトコルでは実現されていない。ご存知の通り、イン
ターネットは急速に拡大しており、現在、IPv4/IPv6 デュアルスタックの IP ネットワーク
では両バージョンの IP プロトコルを同時にルーティングする必要がある。しかし、従来の
IPv4 のみの HIP アプリケーションを新しい IPv6 アプリケーションと相互運用するという
課題が生じている(最新の RFC7401 では可能となった)。HIP アーキテクチャでも図 4 に
示すように、今までのインターネット砂時計モデルになっている。又、HIP は今までの IP
に取って代わるインターネットプロトコルスタックの新しいウエストになっている。
図 4. HIP は IP スタックの新しい“ウエスト”になる
現在のインターネットのもう 1 つの問題は、DoS 攻撃(Denial of Service attack)である。
TCP 接続のセッション確立中に、サーバは、SYN パケットに対して SYN-ACK パケットで
応答した後、
TCP のプロトコルコントロールブロック(PCB)をアロケーションするが、
その
p. 5
段階では、サーバは、SYN パケットが SYN 送信元 IP アドレスと同じホストから到着する
とは限らない。このエクスプロイト(exploit)攻撃では、適度な数のホストがサーバを SYN
メッセージでいっぱいにし、サーバのメモリやそのシステムリソースを使い果たしてしま
う可能性が出てくる。
HIP の暗号化パズル(注を参照)では、統計的にかなりのコンピュータリソースを必要とす
るハッシュ関数を逆変換して改善している。
図 5.は現在の IP スタック構造を示している。
図 6.に示すように、
HIP はネットワークレイ
ヤとトランスポートレイヤの間のサブレイヤ(“3.5”レイヤ)に定義される。そこで、アプリ
ケーションとトランスポートプロトコルは、メッセージで Host Identity Tag(HIT:注を参
照)を使用する。HIP サブレイヤは、パケットをネットワークレイヤに渡す前に、HIT を宛
先の最適 IP アドレスに内部的にマップする。 その後のパケット送信は、通常の IP スタッ
クと同じパターンに従う。
p. 6
(注)HIP で使用する用語:
・“HI”とはホスト ID で、ホストの ID を表す署名アルゴリズムの公開鍵。 HIP では、ホスト
はその HI に属する秘密鍵を使用して署名を作成することにより、その身元を証明する。
・“HIT”とは、IPv6 形式の HI の省略形で、HI をハッシュすることによって生成される。
・“パズル”とは、HIP プロトコルのホスト間で Initiator に相対する Responder を多数のサ
ービス拒否の脅威から保護する HIP パズルメカニズム。
出典:
1. Andrei Gurtov,Helsinki Institute for Information Technology(HIIT), Finland:
“HOST IDENTITY PROTOCOL(HIP)” published by A John & Sons,Ltd.
2. https://www.tempered.io/airwall/host-identity-protocol/
3. https://tex2e.github.io/rfc-translater/html/rfc7401.html

More Related Content

What's hot

What's hot (20)

SecurityIoTLT#1 IoTx無線のセキュリティ
SecurityIoTLT#1 IoTx無線のセキュリティSecurityIoTLT#1 IoTx無線のセキュリティ
SecurityIoTLT#1 IoTx無線のセキュリティ
 
NW-JAWS 勉強会#1 [LT] 閉域閉域もう飽きたよ
NW-JAWS 勉強会#1 [LT] 閉域閉域もう飽きたよNW-JAWS 勉強会#1 [LT] 閉域閉域もう飽きたよ
NW-JAWS 勉強会#1 [LT] 閉域閉域もう飽きたよ
 
2021年度ShowNet ゼロトラストモデルによる次世代セキュリティアーキテクチャ_ShowNet2021 seminar
2021年度ShowNet ゼロトラストモデルによる次世代セキュリティアーキテクチャ_ShowNet2021 seminar2021年度ShowNet ゼロトラストモデルによる次世代セキュリティアーキテクチャ_ShowNet2021 seminar
2021年度ShowNet ゼロトラストモデルによる次世代セキュリティアーキテクチャ_ShowNet2021 seminar
 
IoTSecJP Tokyo#4とあるセキュリティ会社の無線通信セキュリティ診断
IoTSecJP Tokyo#4とあるセキュリティ会社の無線通信セキュリティ診断IoTSecJP Tokyo#4とあるセキュリティ会社の無線通信セキュリティ診断
IoTSecJP Tokyo#4とあるセキュリティ会社の無線通信セキュリティ診断
 
IoTSecJP_Version5.0_LTEデバイスのセキュリティ診断3ステップ
IoTSecJP_Version5.0_LTEデバイスのセキュリティ診断3ステップIoTSecJP_Version5.0_LTEデバイスのセキュリティ診断3ステップ
IoTSecJP_Version5.0_LTEデバイスのセキュリティ診断3ステップ
 
Hyperledger Fabric Private Chaincodeについて
Hyperledger Fabric Private ChaincodeについてHyperledger Fabric Private Chaincodeについて
Hyperledger Fabric Private Chaincodeについて
 
持続的成長可能なIoTソリューションのご提案(Japanese)
持続的成長可能なIoTソリューションのご提案(Japanese)持続的成長可能なIoTソリューションのご提案(Japanese)
持続的成長可能なIoTソリューションのご提案(Japanese)
 
安心して利用できるパブリッククラウド、安全に利用するパブリッククラウド
安心して利用できるパブリッククラウド、安全に利用するパブリッククラウド安心して利用できるパブリッククラウド、安全に利用するパブリッククラウド
安心して利用できるパブリッククラウド、安全に利用するパブリッククラウド
 
IoTプラットフォーム正式版リリース記者説明会
IoTプラットフォーム正式版リリース記者説明会IoTプラットフォーム正式版リリース記者説明会
IoTプラットフォーム正式版リリース記者説明会
 
FIWARE勉強会 20190913
FIWARE勉強会 20190913FIWARE勉強会 20190913
FIWARE勉強会 20190913
 
セキュリティ動向 2018
セキュリティ動向 2018セキュリティ動向 2018
セキュリティ動向 2018
 
ファイブソリューションズデベロッパーネットワーク
ファイブソリューションズデベロッパーネットワークファイブソリューションズデベロッパーネットワーク
ファイブソリューションズデベロッパーネットワーク
 
NW-JAWS 勉強会#2 [LT] あの日したLTの内容を僕らはもう覚えていない
NW-JAWS 勉強会#2 [LT] あの日したLTの内容を僕らはもう覚えていないNW-JAWS 勉強会#2 [LT] あの日したLTの内容を僕らはもう覚えていない
NW-JAWS 勉強会#2 [LT] あの日したLTの内容を僕らはもう覚えていない
 
Cisco Connect Japan 2014:企業向け無線 LAN インフラの最新動向と最新ソリューションのご紹介
Cisco Connect Japan 2014:企業向け無線 LAN インフラの最新動向と最新ソリューションのご紹介Cisco Connect Japan 2014:企業向け無線 LAN インフラの最新動向と最新ソリューションのご紹介
Cisco Connect Japan 2014:企業向け無線 LAN インフラの最新動向と最新ソリューションのご紹介
 
【Interop Tokyo 2016】 30年の実績と経験!シスコ スイッチ最新機能と伝統機能をご紹介
【Interop Tokyo 2016】 30年の実績と経験!シスコ スイッチ最新機能と伝統機能をご紹介【Interop Tokyo 2016】 30年の実績と経験!シスコ スイッチ最新機能と伝統機能をご紹介
【Interop Tokyo 2016】 30年の実績と経験!シスコ スイッチ最新機能と伝統機能をご紹介
 
Yakocloud digitalization 151219
Yakocloud digitalization 151219Yakocloud digitalization 151219
Yakocloud digitalization 151219
 
IIJ Technical DAY 2019 ~ 安全なデジタル通貨流通を支えるアーキテクチャとエンジニアリング
IIJ Technical DAY 2019 ~ 安全なデジタル通貨流通を支えるアーキテクチャとエンジニアリングIIJ Technical DAY 2019 ~ 安全なデジタル通貨流通を支えるアーキテクチャとエンジニアリング
IIJ Technical DAY 2019 ~ 安全なデジタル通貨流通を支えるアーキテクチャとエンジニアリング
 
クラウド基盤技術の変遷とオーケストレーションの進化
クラウド基盤技術の変遷とオーケストレーションの進化クラウド基盤技術の変遷とオーケストレーションの進化
クラウド基盤技術の変遷とオーケストレーションの進化
 
LoRaWAN技術最新動向 とTTIビジネスモデル
LoRaWAN技術最新動向 とTTIビジネスモデルLoRaWAN技術最新動向 とTTIビジネスモデル
LoRaWAN技術最新動向 とTTIビジネスモデル
 
IDCFクラウドで、WordPressサイト構築!
IDCFクラウドで、WordPressサイト構築!IDCFクラウドで、WordPressサイト構築!
IDCFクラウドで、WordPressサイト構築!
 

Similar to Hip関連資料 ホストid ロケータ分離(identifier-locator split)とは (6)

rosjp10 itとrt(ネットワーク技術と時々、仮想化) 株式会社インテック
rosjp10 itとrt(ネットワーク技術と時々、仮想化) 株式会社インテックrosjp10 itとrt(ネットワーク技術と時々、仮想化) 株式会社インテック
rosjp10 itとrt(ネットワーク技術と時々、仮想化) 株式会社インテック
 
ACRiウェビナー_ChipTip Technology様ご講演資料
ACRiウェビナー_ChipTip Technology様ご講演資料ACRiウェビナー_ChipTip Technology様ご講演資料
ACRiウェビナー_ChipTip Technology様ご講演資料
 
Free Hardware and Open Processes | フリー・ハードウェアとオープン・プロセス
Free Hardware and Open Processes | フリー・ハードウェアとオープン・プロセスFree Hardware and Open Processes | フリー・ハードウェアとオープン・プロセス
Free Hardware and Open Processes | フリー・ハードウェアとオープン・プロセス
 
IETF89 HTTP関連WG報告 #isocjp
IETF89 HTTP関連WG報告 #isocjpIETF89 HTTP関連WG報告 #isocjp
IETF89 HTTP関連WG報告 #isocjp
 
『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説
『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説
『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説
 
はじめてのWeb of Things
はじめてのWeb of ThingsはじめてのWeb of Things
はじめてのWeb of Things
 

Hip関連資料 ホストid ロケータ分離(identifier-locator split)とは

  • 1. p. 1 <HIP 関連資料> 株式会社テリロジー 新美竹男 はじめに、 ホスト ID とロケータの分離というしくみは、十数年前から国内の研究機構とか大学で、 新世代ネットワークの仕組みとして研究論文が出された。ただ、残念ながら今なお普及の 域には達していない。その理由の1つにこのしくみを商用化しているマルチベンダーの市 場での台頭がなく、唯一 HIP 対応ベンダーとして米国 Tempered 社が産業分野で孤軍奮 闘している。HIP(Host Identity Protocol)を学習するには、まず HIP の基盤となる“ホス ト ID とロケータ”を理解が必要である。 ホスト ID-ロケータ分離(Identifier-locator split)とは インターネットパケットの IP データグラム(IP datagram)ルーティングは、パケットの宛 先 IP アドレスにネットワークプレフィックス(Prefix)を付加する。インターネットルータ ーが個々の IP アドレスのネクストホップを要求することは実用的ではないと云われている。 何故なら、これによってルーティングテーブルが過度に肥大化し、メモリコストが増し、ル ックアップが遅くなってしまうからである。そのため、IP アドレスはアグリゲートされ、 基本的に地理的に近いエリアに集約配置されている。そして現在、IP アドレスはインター ネットトポロジーでホストロケータの役割を果たしている。 ホスト ID(Identifier)は、 インターネット接続環境でホストロケータ変更される可能性があ るにもかかわらず、一意であることを他の通信エンティティに通知している。DNS の名前 解決のしくみは、広く用いられている ID(識別子)タイプの 1 つである。インターネットの 黎明期には、ホストロケータは固定しており、そのため IP アドレスをホスト ID として用 いることができた。 ただ、 現在のインターネットアーキテクチャでは、 図 1.に示すように、 ホスト ID とロケータ(ホストの場所を示す)の両方としての IP アドレスの役割が混在して いる。ただ、この考えはもはや有効でなくなった。何故ならば、ホストは、モバイルとかマ ルチホームにまでインターネット利用が広がっているからである。個別のインタネットサ ービスが必要に応じ独自ソケットを適用しているが、エンドポイントのホスト ID はそのイ ンターフェイスの IP アドレスに直接接続されているのが現状である。
  • 2. p. 2 図1.ホストのロケーションと ID はインターネットで結合 現在、 ホストの多くは、 共通の DHCP プールから払い出された IPv4 アドレス、 または NAT によって割り当てられた一時的なプライベート IPv4 アドレスを使用している。従って、IP アドレスを堅牢なホスト ID として用いることが難しい。 例えば、特定の IPv4 アドレスをスパムメッセージだとしてブラックリストに登録すると、 実際には、後で DHCP から払い出された同じアドレスを受信したホストを無効にしたり、 NAT で同じパブリック IPv4 アドレスを使用する多数のホストを阻止したりしてしまう。 そこで、登場するのが HIP アーキテクチャの基盤である“ホスト ID とロケータ分離”のしく みである。従来のインターネット接続では、ホスト ID(“誰が通信しているのか”)とネッ トワークトポロジーでのロケータ(“どこから通信しているか”)を同じ IP アドレスで示し ているため、ユビキタスネットワークの柔軟なニーズ対応には難しいと考えられた。 そこで、ホスト ID とネットワークトポロジーのロケータを分離して識別するしくみを“ホ スト ID/ロケータ分離(Host ID/Locator Split)”と呼んでいる。ID として Host Identity (HI) 及び Host Identity Tag(HIT)を用い、ロケータとしては IP アドレスを用いる。 そして、ホスト ID を認証するにはセキュアなメカニズムが不可欠である。 HIP アーキテクチャでは、自己生成の公開鍵(public key)と秘密鍵(private key)のペアが ホスト ID になり、これら鍵交換によってセキュアな認証(authentication)が行われる。 図 2.は、ソケットとネットワーク IP アドレス間に設定のホスト ID を示す。この図で分か るように、ソケットはロケータではなくホスト ID にバインドされる。 尚、同一 ID に関連付けられた複数のロケータが存在するケースも出てくる。 ここでは、ロケータとしての IP アドレスは、ソケットを変更せずに動的に追加/変更でき る。
  • 3. p. 3 図2.インターネットホストのロケーションと ID の分離 1 つのホストは複数の ID を持つことができる。“セルフアサート(Self-assert)”型未公開ホ スト ID は、信頼できる匿名通信(anonymous communication)に適している。ピアホスト は、 新しい接続が以前と同じホストからのものであることを確実に確認できる。 ホスト ID、 PKI(public key infrastructure:公開鍵暗号基盤)、X.509 証明書(certificate)、または PGP(Pretty Good Privacy)によってアサートされたホスト ID を用いて、ホストは認証さ れる。 同じ秘密鍵を持つホストグループ間では ID を共有でき,このようなホストは、 例えば、 マル チキャストグループとか、他の分散オペレーションに適用される。 ~インターネットアーキテクチャの HIP 上述の通り、インターネットの世界では、IP プロトコルがルーティング可能な業界標準の ネットワークレイヤプロトコルであった。 そして、 そのシンプルなしくみのおかげで、 IP プ ロトコルは、イーサネット(IEEE 802.3)、無線 LAN(IEEE 802.11)、トークンリング (IEEE 802.2)など、様々なリンクテクノロジーで利用が広がって行った。 一方、IP 上での複数のトランスポートプロトコルとして TCP および UDP も又広く使用さ れてきた。現在、トランスポートプロトコルを用いたアプリケーションは多く、最も一般的 なものは HTTP、SMTP、および FTP がある。結果としてインターネットのプロトコルスタ ックモデルは、図 3 に示す砂時計のようなしくみに似ている。この図を見ると、IP はスタ ックの最も狭い部分であり、インターネットの“ウエスト”と呼ばれることもある。 インターネットアーキテクチャの主な問題は、ネットワークレイヤとトランスポートレイ ヤ間の密な結合であり、この中で TCP は IP アドレスを含む仮想ヘッダー(pseudo header)を使用していることである。
  • 4. p. 4 図3.IP が Internet プロトコルスタックのウエスト ネットワークススタックに基づく OSI モデルでは、異なるプロトコルレイヤが相互に分離 されている。 但し、このモデルはインターネットプロトコルでは実現されていない。ご存知の通り、イン ターネットは急速に拡大しており、現在、IPv4/IPv6 デュアルスタックの IP ネットワーク では両バージョンの IP プロトコルを同時にルーティングする必要がある。しかし、従来の IPv4 のみの HIP アプリケーションを新しい IPv6 アプリケーションと相互運用するという 課題が生じている(最新の RFC7401 では可能となった)。HIP アーキテクチャでも図 4 に 示すように、今までのインターネット砂時計モデルになっている。又、HIP は今までの IP に取って代わるインターネットプロトコルスタックの新しいウエストになっている。 図 4. HIP は IP スタックの新しい“ウエスト”になる 現在のインターネットのもう 1 つの問題は、DoS 攻撃(Denial of Service attack)である。 TCP 接続のセッション確立中に、サーバは、SYN パケットに対して SYN-ACK パケットで 応答した後、 TCP のプロトコルコントロールブロック(PCB)をアロケーションするが、 その
  • 5. p. 5 段階では、サーバは、SYN パケットが SYN 送信元 IP アドレスと同じホストから到着する とは限らない。このエクスプロイト(exploit)攻撃では、適度な数のホストがサーバを SYN メッセージでいっぱいにし、サーバのメモリやそのシステムリソースを使い果たしてしま う可能性が出てくる。 HIP の暗号化パズル(注を参照)では、統計的にかなりのコンピュータリソースを必要とす るハッシュ関数を逆変換して改善している。 図 5.は現在の IP スタック構造を示している。 図 6.に示すように、 HIP はネットワークレイ ヤとトランスポートレイヤの間のサブレイヤ(“3.5”レイヤ)に定義される。そこで、アプリ ケーションとトランスポートプロトコルは、メッセージで Host Identity Tag(HIT:注を参 照)を使用する。HIP サブレイヤは、パケットをネットワークレイヤに渡す前に、HIT を宛 先の最適 IP アドレスに内部的にマップする。 その後のパケット送信は、通常の IP スタッ クと同じパターンに従う。
  • 6. p. 6 (注)HIP で使用する用語: ・“HI”とはホスト ID で、ホストの ID を表す署名アルゴリズムの公開鍵。 HIP では、ホスト はその HI に属する秘密鍵を使用して署名を作成することにより、その身元を証明する。 ・“HIT”とは、IPv6 形式の HI の省略形で、HI をハッシュすることによって生成される。 ・“パズル”とは、HIP プロトコルのホスト間で Initiator に相対する Responder を多数のサ ービス拒否の脅威から保護する HIP パズルメカニズム。 出典: 1. Andrei Gurtov,Helsinki Institute for Information Technology(HIIT), Finland: “HOST IDENTITY PROTOCOL(HIP)” published by A John & Sons,Ltd. 2. https://www.tempered.io/airwall/host-identity-protocol/ 3. https://tex2e.github.io/rfc-translater/html/rfc7401.html